Kubernetes 文档的这一部分包含教程。 每个教程展示了如何完成一个比单个任务更大的目标。 通常一个教程有几个部分，每个部分都有一系列步骤。在浏览每个教程之前， 你可能希望将标准化术语表页面添加到书签，供以后参考。
如果你要编写教程，请参阅内容页面类型 以获取有关教程页面类型的信息。
本教程向你展示如何使用 Minikube 在 Kubernetes 上运行一个应用示例。 教程提供了容器镜像，使用 NGINX 来对所有请求做出回应。
本教程假设你已经安装了 minikube。
有关安装说明，请参阅 minikube start。
你还需要安装 kubectl。
有关安装说明，请参阅安装工具。
minikube start
打开 Kubernetes 仪表板。你可以通过两种不同的方式执行此操作：
打开一个新的终端，然后运行：
# 启动一个新的终端，并保持此命令运行。
minikube dashboard
现在，切换回运行 minikube start 的终端。
dashboard 命令启用仪表板插件，并在默认的 Web 浏览器中打开代理。
你可以在仪表板上创建 Kubernetes 资源，例如 Deployment 和 Service。
如果你以 root 用户身份在环境中运行， 请参见使用 URL 打开仪表板。
默认情况下，仪表板只能从内部 Kubernetes 虚拟网络中访问。
dashboard 命令创建一个临时代理，使仪表板可以从 Kubernetes 虚拟网络外部访问。
要停止代理，请运行 Ctrl+C 退出该进程。仪表板仍在运行中。
命令退出后，仪表板仍然在 Kubernetes 集群中运行。
你可以再次运行 dashboard 命令创建另一个代理来访问仪表板。
如果你不想 Minikube 为你打开 Web 浏览器，可以使用 --url 标志运行仪表板命令。
minikube 会输出一个 URL，你可以在你喜欢的浏览器中打开该 URL。
打开一个新的终端，然后运行：
# 启动一个新的终端，并保持此命令运行。
minikube dashboard --url
现在，切换回运行 minikube start 的终端。
Kubernetes Pod 是由一个或多个为了管理和联网而绑定在一起的容器构成的组。本教程中的 Pod 只有一个容器。 Kubernetes Deployment 检查 Pod 的健康状况，并在 Pod 中的容器终止的情况下重新启动新的容器。 Deployment 是管理 Pod 创建和扩展的推荐方法。
使用 kubectl create 命令创建管理 Pod 的 Deployment。该 Pod 根据提供的 Docker
镜像运行容器。
# 运行包含 Web 服务器的测试容器镜像
kubectl create deployment hello-node --image=registry.k8s.io/e2e-test-images/agnhost:2.39 -- /agnhost netexec --http-port=8080
查看 Deployment：
kubectl get deployments
输出结果类似于这样：
NAME READY UP-TO-DATE AVAILABLE AGE
hello-node 1/1 1 1 1m
查看 Pod：
kubectl get pods
输出结果类似于这样：
NAME READY STATUS RESTARTS AGE
hello-node-5f76cf6ccf-br9b5 1/1 Running 0 1m
查看集群事件：
kubectl get events
查看 kubectl 配置：
kubectl config view
有关 kubectl 命令的更多信息，请参阅 kubectl 概述。
默认情况下，Pod 只能通过 Kubernetes 集群中的内部 IP 地址访问。
要使得 hello-node 容器可以从 Kubernetes 虚拟网络的外部访问，你必须将 Pod
暴露为 Kubernetes Service。
使用 kubectl expose 命令将 Pod 暴露给公网：
kubectl expose deployment hello-node --type=LoadBalancer --port=8080
这里的 --type=LoadBalancer 参数表明你希望将你的 Service 暴露到集群外部。
测试镜像中的应用程序代码仅监听 TCP 8080 端口。
如果你用 kubectl expose 暴露了其它的端口，客户端将不能访问其它端口。
查看你创建的 Service：
kubectl get services
输出结果类似于这样:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
hello-node LoadBalancer 10.108.144.78 <pending> 8080:30369/TCP 21s
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 23m
对于支持负载均衡器的云服务平台而言，平台将提供一个外部 IP 来访问该服务。
在 Minikube 上，LoadBalancer 使得服务可以通过命令 minikube service 访问。
运行下面的命令：
minikube service hello-node
这将打开一个浏览器窗口，为你的应用程序提供服务并显示应用的响应。
Minikube 有一组内置的插件， 可以在本地 Kubernetes 环境中启用、禁用和打开。
列出当前支持的插件：
minikube addons list
输出结果类似于这样：
addon-manager: enabled
dashboard: enabled
default-storageclass: enabled
efk: disabled
freshpod: disabled
gvisor: disabled
helm-tiller: disabled
ingress: disabled
ingress-dns: disabled
logviewer: disabled
metrics-server: disabled
nvidia-driver-installer: disabled
nvidia-gpu-device-plugin: disabled
registry: disabled
registry-creds: disabled
storage-provisioner: enabled
storage-provisioner-gluster: disabled
启用插件，例如 metrics-server：
minikube addons enable metrics-server
输出结果类似于这样：
The 'metrics-server' addon is enabled
查看通过安装该插件所创建的 Pod 和 Service：
kubectl get pod,svc -n kube-system
输出结果类似于这样：
NAME READY STATUS RESTARTS AGE
pod/coredns-5644d7b6d9-mh9ll 1/1 Running 0 34m
pod/coredns-5644d7b6d9-pqd2t 1/1 Running 0 34m
pod/metrics-server-67fb648c5 1/1 Running 0 26s
pod/etcd-minikube 1/1 Running 0 34m
pod/influxdb-grafana-b29w8 2/2 Running 0 26s
pod/kube-addon-manager-minikube 1/1 Running 0 34m
pod/kube-apiserver-minikube 1/1 Running 0 34m
pod/kube-controller-manager-minikube 1/1 Running 0 34m
pod/kube-proxy-rnlps 1/1 Running 0 34m
pod/kube-scheduler-minikube 1/1 Running 0 34m
pod/storage-provisioner 1/1 Running 0 34m
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/metrics-server ClusterIP 10.96.241.45 <none> 80/TCP 26s
service/kube-dns ClusterIP 10.96.0.10 <none> 53/UDP,53/TCP 34m
service/monitoring-grafana NodePort 10.99.24.54 <none> 80:30002/TCP 26s
service/monitoring-influxdb ClusterIP 10.111.169.94 <none> 8083/TCP,8086/TCP 26s
禁用 metrics-server：
minikube addons disable metrics-server
输出结果类似于这样：
metrics-server was successfully disabled
现在可以清理你在集群中创建的资源：
kubectl delete service hello-node
kubectl delete deployment hello-node
停止 Minikube 集群：
minikube stop
可选地，删除 Minikube 虚拟机（VM）：
# 可选的
minikube delete
如果你还想使用 Minikube 进一步学习 Kubernetes，那就不需要删除 Minikube。
本教程介绍了 Kubernetes 集群编排系统的基础知识。每个模块包含关于 Kubernetes 主要特性和概念的一些背景信息，并包括一个在线互动教程。这些互动教程让你可以自己管理一个简单的集群及其容器化应用程序。
使用互动教程，你可以学习：
教程 Katacoda 在你的浏览器中运行一个虚拟终端，在浏览器中运行 Minikube，这是一个可在任何地方小规模本地部署的 Kubernetes 集群。不需要安装任何软件或进行任何配置；每个交互性教程都直接从你的网页浏览器上运行。
通过现代的 Web 服务，用户希望应用程序能够 24/7 全天候使用，开发人员希望每天可以多次发布部署新版本的应用程序。 容器化可以帮助软件包达成这些目标，使应用程序能够以简单快速的方式发布和更新，而无需停机。Kubernetes 帮助你确保这些容器化的应用程序在你想要的时间和地点运行，并帮助应用程序找到它们需要的资源和工具。Kubernetes 是一个可用于生产的开源平台，根据 Google 容器集群方面积累的经验，以及来自社区的最佳实践而设计。
了解 Kubernetes 集群并使用 Minikube 创建一个简单的集群。
Kubernetes 协调一个高可用计算机集群，每个计算机作为独立单元互相连接工作。 Kubernetes 中的抽象允许你将容器化的应用部署到集群，而无需将它们绑定到某个特定的独立计算机。为了使用这种新的部署模型，应用需要以将应用与单个主机分离的方式打包：它们需要被容器化。与过去的那种应用直接以包的方式深度与主机集成的部署模型相比，容器化应用更灵活、更可用。 Kubernetes 以更高效的方式跨集群自动分发和调度应用容器。 Kubernetes 是一个开源平台，并且可应用于生产环境。
一个 Kubernetes 集群包含两种类型的资源:
Kubernetes 是一个生产级别的开源平台，可协调在计算机集群内和跨计算机集群的应用容器的部署（调度）和执行.
Master 负责管理整个集群。 Master 协调集群中的所有活动，例如调度应用、维护应用的所需状态、应用扩容以及推出新的更新。
Node 是一个虚拟机或者物理机，它在 Kubernetes 集群中充当工作机器的角色 每个Node都有 Kubelet , 它管理 Node 而且是 Node 与 Master 通信的代理。 Node 还应该具有用于处理容器操作的工具，例如 Docker 或 rkt 。处理生产级流量的 Kubernetes 集群至少应具有三个 Node，因为如果一个 Node 出现故障其对应的 etcd 成员和控制平面实例都会丢失，并且冗余会受到影响。 你可以通过添加更多控制平面节点来降低这种风险 。
Master 管理集群，Node 用于托管正在运行的应用。
在 Kubernetes 上部署应用时，你告诉 Master 启动应用容器。 Master 就编排容器在集群的 Node 上运行。 Node 使用 Master 暴露的 Kubernetes API 与 Master 通信。终端用户也可以使用 Kubernetes API 与集群交互。
Kubernetes 既可以部署在物理机上也可以部署在虚拟机上。你可以使用 Minikube 开始部署 Kubernetes 集群。 Minikube 是一种轻量级的 Kubernetes 实现，可在本地计算机上创建 VM 并部署仅包含一个节点的简单集群。 Minikube 可用于 Linux ， macOS 和 Windows 系统。Minikube CLI 提供了用于引导集群工作的多种操作，包括启动、停止、查看状态和删除。在本教程里，你可以使用预装有 Minikube 的在线终端进行体验。
既然你已经知道 Kubernetes 是什么，让我们转到在线教程并启动我们的第一个 Kubernetes 集群！
一旦运行了 Kubernetes 集群，就可以在其上部署容器化应用程序。 为此，你需要创建 Kubernetes Deployment 配置。Deployment 指挥 Kubernetes 如何创建和更新应用程序的实例。创建 Deployment 后，Kubernetes master 将应用程序实例调度到集群中的各个节点上。
创建应用程序实例后，Kubernetes Deployment 控制器会持续监视这些实例。 如果托管实例的节点关闭或被删除，则 Deployment 控制器会将该实例替换为集群中另一个节点上的实例。 这提供了一种自我修复机制来解决机器故障维护问题。
在没有 Kubernetes 这种编排系统之前，安装脚本通常用于启动应用程序，但它们不允许从机器故障中恢复。通过创建应用程序实例并使它们在节点之间运行， Kubernetes Deployments 提供了一种与众不同的应用程序管理方法。
Deployment 负责创建和更新应用程序的实例
你可以使用 Kubernetes 命令行界面 Kubectl 创建和管理 Deployment。Kubectl 使用 Kubernetes API 与集群进行交互。在本单元中，你将学习创建在 Kubernetes 集群上运行应用程序的 Deployment 所需的最常见的 Kubectl 命令。
创建 Deployment 时，你需要指定应用程序的容器镜像以及要运行的副本数。你可以稍后通过更新 Deployment 来更改该信息; 模块 5 和 6 讨论了如何扩展和更新 Deployments。
应用程序需要打包成一种受支持的容器格式，以便部署在 Kubernetes 上
对于我们的第一次部署，我们将使用打包在 Docker 容器中的 Node.js 应用程序。 要创建 Node.js 应用程序并部署 Docker 容器，请按照 你好 Minikube 教程.
现在你已经了解了 Deployment 的内容，让我们转到在线教程并部署我们的第一个应用程序！
在模块 2创建 Deployment 时, Kubernetes 添加了一个 Pod 来托管你的应用实例。Pod 是 Kubernetes 抽象出来的，表示一组一个或多个应用程序容器（如 Docker），以及这些容器的一些共享资源。这些资源包括:
Pod 为特定于应用程序的“逻辑主机”建模，并且可以包含相对紧耦合的不同应用容器。例如，Pod 可能既包含带有 Node.js 应用的容器，也包含另一个不同的容器，用于提供 Node.js 网络服务器要发布的数据。Pod 中的容器共享 IP 地址和端口，始终位于同一位置并且共同调度，并在同一工作节点上的共享上下文中运行。
Pod是 Kubernetes 平台上的原子单元。 当我们在 Kubernetes 上创建 Deployment 时，该 Deployment 会在其中创建包含容器的 Pod （而不是直接创建容器）。每个 Pod 都与调度它的工作节点绑定，并保持在那里直到终止（根据重启策略）或删除。 如果工作节点发生故障，则会在集群中的其他可用工作节点上调度相同的 Pod。
Pod 是一组一个或多个应用程序容器（例如 Docker），包括共享存储（卷), IP 地址和有关如何运行它们的信息。
一个 pod 总是运行在 工作节点。工作节点是 Kubernetes 中的参与计算的机器，可以是虚拟机或物理计算机，具体取决于集群。每个工作节点由主节点管理。工作节点可以有多个 pod ，Kubernetes 主节点会自动处理在集群中的工作节点上调度 pod 。 主节点的自动调度考量了每个工作节点上的可用资源。
每个 Kubernetes 工作节点至少运行:
如果它们紧耦合并且需要共享磁盘等资源，这些容器应在一个 Pod 中编排。
在模块 2,你使用了 Kubectl 命令行界面。 你将继续在第3单元中使用它来获取有关已部署的应用程序及其环境的信息。 最常见的操作可以使用以下 kubectl 命令完成：
你可以使用这些命令查看应用程序的部署时间，当前状态，运行位置以及配置。
现在我们了解了有关集群组件和命令行的更多信息，让我们来探索一下我们的应用程序。
工作节点是 Kubernetes 中的负责计算的机器，可能是VM或物理计算机，具体取决于集群。多个 Pod 可以在一个工作节点上运行。
Kubernetes Pod 是转瞬即逝的。 Pod 实际上拥有 生命周期。 当一个工作 Node 挂掉后, 在 Node 上运行的 Pod 也会消亡。 ReplicaSet 会自动地通过创建新的 Pod 驱动集群回到目标状态，以保证应用程序正常运行。 换一个例子，考虑一个具有3个副本数的用作图像处理的后端程序。这些副本是可替换的; 前端系统不应该关心后端副本，即使 Pod 丢失或重新创建。也就是说，Kubernetes 集群中的每个 Pod (即使是在同一个 Node 上的 Pod )都有一个唯一的 IP 地址，因此需要一种方法自动协调 Pod 之间的变更，以便应用程序保持运行。
Kubernetes 中的服务(Service)是一种抽象概念，它定义了 Pod 的逻辑集和访问 Pod 的协议。Service 使从属 Pod 之间的松耦合成为可能。 和其他 Kubernetes 对象一样, Service 用 YAML (更推荐) 或者 JSON 来定义. Service 下的一组 Pod 通常由 LabelSelector (请参阅下面的说明为什么你可能想要一个 spec 中不包含selector的服务)来标记。
尽管每个 Pod 都有一个唯一的 IP 地址，但是如果没有 Service ，这些 IP 不会暴露在集群外部。Service 允许你的应用程序接收流量。Service 也可以用在 ServiceSpec 标记type的方式暴露
<NodeIP>:<NodePort> 从集群外部访问 Service。是 ClusterIP 的超集。externalName指定)公开 Service。不使用代理。这种类型需要kube-dns的v1.7或更高版本。更多关于不同 Service 类型的信息可以在使用源 IP 教程。 也请参阅 连接应用程序和 Service 。
另外，需要注意的是有一些 Service 的用例没有在 spec 中定义selector。 一个没有selector创建的 Service 也不会创建相应的端点对象。这允许用户手动将服务映射到特定的端点。没有 selector 的另一种可能是你严格使用type: ExternalName来标记。
Kubernetes 的 Service 是一个抽象层，它定义了一组 Pod 的逻辑集，并为这些 Pod 支持外部流量暴露、负载平衡和服务发现。
Service 通过一组 Pod 路由通信。Service 是一种抽象，它允许 Pod 死亡并在 Kubernetes 中复制，而不会影响应用程序。在依赖的 Pod (如应用程序中的前端和后端组件)之间进行发现和路由是由Kubernetes Service 处理的。
Service 匹配一组 Pod 是使用 标签(Label)和选择器(Selector), 它们是允许对 Kubernetes 中的对象进行逻辑操作的一种分组原语。标签(Label)是附加在对象上的键/值对，可以以多种方式使用:
你也可以在创建 Deployment 的同时用 --expose创建一个 Service 。
标签(Label)可以在创建时或之后附加到对象上。他们可以随时被修改。现在使用 Service 发布我们的应用程序并添加一些 Label 。
在之前的模块中，我们创建了一个 Deployment，然后通过 Service让其可以开放访问。Deployment 仅为跑这个应用程序创建了一个 Pod。 当流量增加时，我们需要扩容应用程序满足用户需求。
扩缩 是通过改变 Deployment 中的副本数量来实现的。
在运行 kubectl run 命令时，你可以通过设置 --replicas 参数来设置 Deployment 的副本数。
扩展 Deployment 将创建新的 Pods，并将资源调度请求分配到有可用资源的节点上，收缩 会将 Pods 数量减少至所需的状态。Kubernetes 还支持 Pods 的自动缩放，但这并不在本教程的讨论范围内。将 Pods 数量收缩到0也是可以的，但这会终止 Deployment 上所有已经部署的 Pods。
运行应用程序的多个实例需要在它们之间分配流量。服务 (Service)有一种负载均衡器类型，可以将网络流量均衡分配到外部可访问的 Pods 上。服务将会一直通过端点来监视 Pods 的运行，保证流量只分配到可用的 Pods 上。
扩缩是通过改变 Deployment 中的副本数量来实现的。
一旦有了多个应用实例，就可以没有宕机地滚动更新。我们将会在下面的模块中介绍这些。现在让我们使用在线终端来体验一下应用程序的扩缩过程。
用户希望应用程序始终可用，而开发人员则需要每天多次部署它们的新版本。在 Kubernetes 中，这些是通过滚动更新（Rolling Updates）完成的。 滚动更新 允许通过使用新的实例逐步更新 Pod 实例，零停机进行 Deployment 更新。新的 Pod 将在具有可用资源的节点上进行调度。
在前面的模块中，我们将应用程序扩展为运行多个实例。这是在不影响应用程序可用性的情况下执行更新的要求。默认情况下，更新期间不可用的 pod 的最大值和可以创建的新 pod 数都是 1。这两个选项都可以配置为（pod）数字或百分比。 在 Kubernetes 中，更新是经过版本控制的，任何 Deployment 更新都可以恢复到以前的（稳定）版本。
滚动更新允许通过使用新的实例逐步更新 Pod 实例从而实现 Deployments 更新，停机时间为零。
与应用程序扩展类似，如果 Deployment 是公开的，服务将在更新期间仅对可用的 pod 进行负载均衡。可用 Pod 是应用程序用户可用的实例。
滚动更新允许以下操作：
如果 Deployment 是公开的，则服务将仅在更新期间对可用的 pod 进行负载均衡。
在下面的交互式教程中，我们将应用程序更新为新版本，并执行回滚。
在本教程中，你会学到如何以及为什么要实现外部化微服务应用配置。 具体来说，你将学习如何使用 Kubernetes ConfigMaps 和 Secrets 设置环境变量， 然后在 MicroProfile config 中使用它们。
在 Kubernetes 中，为 docker 容器设置环境变量有几种不同的方式，比如： Dockerfile、kubernetes.yml、Kubernetes ConfigMaps、和 Kubernetes Secrets。 在本教程中，你将学到怎么用后两个方式去设置你的环境变量，而环境变量的值将注入到你的微服务里。 使用 ConfigMaps 和 Secrets 的一个好处是他们能在多个容器间复用， 比如赋值给不同的容器中的不同环境变量。
ConfigMaps 是存储非机密键值对的 API 对象。 在互动教程中，你会学到如何用 ConfigMap 来保存应用名字。 ConfigMap 的更多信息，你可以在这里找到文档。
Secrets 尽管也用来存储键值对，但区别于 ConfigMaps 的是：它针对机密/敏感数据，且存储格式为 Base64 编码。 secrets 的这种特性使得它适合于存储证书、密钥、令牌，上述内容你将在交互教程中实现。 Secrets 的更多信息，你可以在这里找到文档。
外部化应用配置之所以有用处，是因为配置常常根据环境的不同而变化。 为了实现此功能，我们用到了 Java 上下文和依赖注入（Contexts and Dependency Injection, CDI）、MicroProfile 配置。 MicroProfile config 是 MicroProfile 的功能特性， 是一组开放 Java 技术，用于开发、部署云原生微服务。
CDI 提供一套标准的依赖注入能力，使得应用程序可以由相互协作的、松耦合的 beans 组装而成。 MicroProfile Config 为 app 和微服务提供从各种来源，比如应用、运行时、环境，获取配置参数的标准方法。 基于来源定义的优先级，属性可以自动的合并到单独一组应用可以通过 API 访问到的属性。 CDI & MicroProfile 都会被用在互动教程中， 用来从 Kubernetes ConfigMaps 和 Secrets 获得外部提供的属性，并注入应用程序代码中。
很多开源框架、运行时支持 MicroProfile Config。 对于整个互动教程，你都可以使用开放的库、灵活的开源 Java 运行时，去构建并运行云原生的 apps 和微服务。 然而，任何 MicroProfile 兼容的运行时都可以用来做替代品。
这篇文档基于配置 Pod 以使用 ConfigMap 这个任务，提供了一个使用 ConfigMap 来配置 Redis 的真实案例。
你必须拥有一个 Kubernetes 的集群，同时你的 Kubernetes 集群必须带有 kubectl 命令行工具。 建议在至少有两个节点的集群上运行本教程，且这些节点不作为控制平面主机。 如果你还没有集群，你可以通过 Minikube 构建一个你自己的集群，或者你可以使用下面任意一个 Kubernetes 工具构建：
要获知版本信息，请输入
kubectl version.kubectl 1.14 及以上的版本。按照下面的步骤，使用 ConfigMap 中的数据来配置 Redis 缓存。
首先创建一个配置模块为空的 ConfigMap：
cat <<EOF >./example-redis-config.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: example-redis-config
data:
redis-config: ""
EOF
应用上面创建的 ConfigMap 以及 Redis pod 清单：
kubectl apply -f example-redis-config.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/pods/config/redis-pod.yaml
检查 Redis pod 清单的内容，并注意以下几点：
spec.volumes[1] 创建一个名为 config 的卷。spec.volumes[1].items[0] 下的 key 和 path 会将来自 example-redis-config
ConfigMap 中的 redis-config 密钥公开在 config 卷上一个名为 redis.conf 的文件中。config 卷被 spec.containers[0].volumeMounts[1] 挂载在 /redis-master。这样做的最终效果是将上面 example-redis-config 配置中 data.redis-config
的数据作为 Pod 中的 /redis-master/redis.conf 公开。
apiVersion: v1
kind: Pod
metadata:
name: redis
spec:
containers:
- name: redis
image: redis:5.0.4
command:
- redis-server
- "/redis-master/redis.conf"
env:
- name: MASTER
value: "true"
ports:
- containerPort: 6379
resources:
limits:
cpu: "0.1"
volumeMounts:
- mountPath: /redis-master-data
name: data
- mountPath: /redis-master
name: config
volumes:
- name: data
emptyDir: {}
- name: config
configMap:
name: example-redis-config
items:
- key: redis-config
path: redis.conf
检查创建的对象：
kubectl get pod/redis configmap/example-redis-config
你应该可以看到以下输出：
NAME READY STATUS RESTARTS AGE
pod/redis 1/1 Running 0 8s
NAME DATA AGE
configmap/example-redis-config 1 14s
回顾一下，我们在 example-redis-config ConfigMap 保留了空的 redis-config 键：
kubectl describe configmap/example-redis-config
你应该可以看到一个空的 redis-config 键：
Name: example-redis-config
Namespace: default
Labels: <none>
Annotations: <none>
Data
====
redis-config:
使用 kubectl exec 进入 pod，运行 redis-cli 工具检查当前配置：
kubectl exec -it redis -- redis-cli
查看 maxmemory：
127.0.0.1:6379> CONFIG GET maxmemory
它应该显示默认值 0：
1) "maxmemory"
2) "0"
同样，查看 maxmemory-policy：
127.0.0.1:6379> CONFIG GET maxmemory-policy
它也应该显示默认值 noeviction：
1) "maxmemory-policy"
2) "noeviction"
现在，向 example-redis-config ConfigMap 添加一些配置：
apiVersion: v1
kind: ConfigMap
metadata:
name: example-redis-config
data:
redis-config: |
maxmemory 2mb
maxmemory-policy allkeys-lru
应用更新的 ConfigMap:
kubectl apply -f example-redis-config.yaml
确认 ConfigMap 已更新：
kubectl describe configmap/example-redis-config
你应该可以看到我们刚刚添加的配置：
Name: example-redis-config
Namespace: default
Labels: <none>
Annotations: <none>
Data
====
redis-config:
----
maxmemory 2mb
maxmemory-policy allkeys-lru
通过 kubectl exec 使用 redis-cli 再次检查 Redis Pod，查看是否已应用配置：
kubectl exec -it redis -- redis-cli
查看 maxmemory：
127.0.0.1:6379> CONFIG GET maxmemory
它保持默认值 0：
1) "maxmemory"
2) "0"
同样，maxmemory-policy 保留为默认设置 noeviction：
127.0.0.1:6379> CONFIG GET maxmemory-policy
返回：
1) "maxmemory-policy"
2) "noeviction"
配置值未更改，因为需要重新启动 Pod 才能从关联的 ConfigMap 中获取更新的值。 让我们删除并重新创建 Pod：
kubectl delete pod redis
kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/pods/config/redis-pod.yaml
现在，最后一次重新检查配置值：
kubectl exec -it redis -- redis-cli
查看 maxmemory：
127.0.0.1:6379> CONFIG GET maxmemory
现在，它应该返回更新后的值 2097152：
1) "maxmemory"
2) "2097152"
同样，maxmemory-policy 也已更新：
127.0.0.1:6379> CONFIG GET maxmemory-policy
现在它反映了期望值 allkeys-lru：
1) "maxmemory-policy"
2) "allkeys-lru"
删除创建的资源，清理你的工作：
kubectl delete pod/redis configmap/example-redis-config
本教程仅适用于新集群。
Pod 安全准入（PSA）在 v1.23 及更高版本默认启用，
因为它已进阶为 Beta。
Pod 安全准入是在创建 Pod 时应用
Pod 安全标准的准入控制器。
本教程将向你展示如何在集群级别实施 baseline Pod 安全标准，
该标准将标准配置应用于集群中的所有名字空间。
要将 Pod 安全标准应用于特定名字空间， 请参阅在名字空间级别应用 Pod 安全标准。
如果你正在运行 v1.26 以外的 Kubernetes 版本， 请查阅该版本的文档。
在你的工作站中安装以下内容：
本教程演示了你可以对完全由你控制的 Kubernetes 集群所配置的内容。 如果你正在学习如何为一个无法配置控制平面的托管集群配置 Pod 安全准入， 请参阅在名字空间级别应用 Pod 安全标准。
Pod 安全准入
允许你使用以下模式应用内置的
Pod 安全标准：
enforce、audit 和 warn。
要收集信息以便选择最适合你的配置的 Pod 安全标准，请执行以下操作：
创建一个没有应用 Pod 安全标准的集群：
kind create cluster --name psa-wo-cluster-pss
输出类似于：
Creating cluster "psa-wo-cluster-pss" ...
✓ Ensuring node image (kindest/node:v1.26.0) 🖼
✓ Preparing nodes 📦
✓ Writing configuration 📜
✓ Starting control-plane 🕹️
✓ Installing CNI 🔌
✓ Installing StorageClass 💾
Set kubectl context to "kind-psa-wo-cluster-pss"
You can now use your cluster with:
kubectl cluster-info --context kind-psa-wo-cluster-pss
Thanks for using kind! 😊
将 kubectl 上下文设置为新集群：
kubectl cluster-info --context kind-psa-wo-cluster-pss
输出类似于：
Kubernetes control plane is running at https://127.0.0.1:61350
CoreDNS is running at https://127.0.0.1:61350/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
获取集群中的名字空间列表：
kubectl get ns
输出类似于：
NAME STATUS AGE
default Active 9m30s
kube-node-lease Active 9m32s
kube-public Active 9m32s
kube-system Active 9m32s
local-path-storage Active 9m26s
使用 --dry-run=server 来了解应用不同的 Pod 安全标准时会发生什么：
Privileged
kubectl label --dry-run=server --overwrite ns --all \
pod-security.kubernetes.io/enforce=privileged
输出类似于：
namespace/default labeled
namespace/kube-node-lease labeled
namespace/kube-public labeled
namespace/kube-system labeled
namespace/local-path-storage labeled
Baseline
kubectl label --dry-run=server --overwrite ns --all \
pod-security.kubernetes.io/enforce=baseline
输出类似于：
namespace/default labeled
namespace/kube-node-lease labeled
namespace/kube-public labeled
Warning: existing pods in namespace "kube-system" violate the new PodSecurity enforce level "baseline:latest"
Warning: etcd-psa-wo-cluster-pss-control-plane (and 3 other pods): host namespaces, hostPath volumes
Warning: kindnet-vzj42: non-default capabilities, host namespaces, hostPath volumes
Warning: kube-proxy-m6hwf: host namespaces, hostPath volumes, privileged
namespace/kube-system labeled
namespace/local-path-storage labeled
Restricted
kubectl label --dry-run=server --overwrite ns --all \
pod-security.kubernetes.io/enforce=restricted
输出类似于：
namespace/default labeled
namespace/kube-node-lease labeled
namespace/kube-public labeled
Warning: existing pods in namespace "kube-system" violate the new PodSecurity enforce level "restricted:latest"
Warning: coredns-7bb9c7b568-hsptc (and 1 other pod): unrestricted capabilities, runAsNonRoot != true, seccompProfile
Warning: etcd-psa-wo-cluster-pss-control-plane (and 3 other pods): host namespaces, hostPath volumes, allowPrivilegeEscalation != false, unrestricted capabilities, restricted volume types, runAsNonRoot != true
Warning: kindnet-vzj42: non-default capabilities, host namespaces, hostPath volumes, allowPrivilegeEscalation != false, unrestricted capabilities, restricted volume types, runAsNonRoot != true, seccompProfile
Warning: kube-proxy-m6hwf: host namespaces, hostPath volumes, privileged, allowPrivilegeEscalation != false, unrestricted capabilities, restricted volume types, runAsNonRoot != true, seccompProfile
namespace/kube-system labeled
Warning: existing pods in namespace "local-path-storage" violate the new PodSecurity enforce level "restricted:latest"
Warning: local-path-provisioner-d6d9f7ffc-lw9lh: allowPrivilegeEscalation != false, unrestricted capabilities, runAsNonRoot != true, seccompProfile
namespace/local-path-storage labeled
从前面的输出中，你会注意到应用 privileged Pod 安全标准不会显示任何名字空间的警告。
然而，baseline 和 restricted 标准都有警告，特别是在 kube-system 名字空间中。
在本节中，你将以下 Pod 安全标准应用于最新（latest）版本：
enforce 模式下的 baseline 标准。warn 和 audit 模式下的 restricted 标准。baseline Pod 安全标准提供了一个方便的中间立场，能够保持豁免列表简短并防止已知的特权升级。
此外，为了防止 kube-system 中的 Pod 失败，你将免除该名字空间应用 Pod 安全标准。
在你自己的环境中实施 Pod 安全准入时，请考虑以下事项：
根据应用于集群的风险状况，更严格的 Pod 安全标准（如 restricted）可能是更好的选择。
对 kube-system 名字空间进行赦免会允许 Pod 在其中以 privileged 模式运行。
对于实际使用，Kubernetes 项目强烈建议你应用严格的 RBAC 策略来限制对 kube-system 的访问，
遵循最小特权原则。
创建一个配置文件，Pod 安全准入控制器可以使用该文件来实现这些 Pod 安全标准：
mkdir -p /tmp/pss
cat <<EOF > /tmp/pss/cluster-level-pss.yaml
apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: PodSecurity
configuration:
apiVersion: pod-security.admission.config.k8s.io/v1
kind: PodSecurityConfiguration
defaults:
enforce: "baseline"
enforce-version: "latest"
audit: "restricted"
audit-version: "latest"
warn: "restricted"
warn-version: "latest"
exemptions:
usernames: []
runtimeClasses: []
namespaces: [kube-system]
EOF
在创建集群时配置 API 服务器使用此文件：
cat <<EOF > /tmp/pss/cluster-config.yaml
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
kubeadmConfigPatches:
- |
kind: ClusterConfiguration
apiServer:
extraArgs:
admission-control-config-file: /etc/config/cluster-level-pss.yaml
extraVolumes:
- name: accf
hostPath: /etc/config
mountPath: /etc/config
readOnly: false
pathType: "DirectoryOrCreate"
extraMounts:
- hostPath: /tmp/pss
containerPath: /etc/config
# optional: if set, the mount is read-only.
# default false
readOnly: false
# optional: if set, the mount needs SELinux relabeling.
# default false
selinuxRelabel: false
# optional: set propagation mode (None, HostToContainer or Bidirectional)
# see https://kubernetes.io/docs/concepts/storage/volumes/#mount-propagation
# default None
propagation: None
EOF
如果你在 macOS 上使用 Docker Desktop 和 KinD，
你可以在菜单项 Preferences > Resources > File Sharing
下添加 /tmp 作为共享目录。
创建一个使用 Pod 安全准入的集群来应用这些 Pod 安全标准：
kind create cluster --name psa-with-cluster-pss --config /tmp/pss/cluster-config.yaml
输出类似于：
Creating cluster "psa-with-cluster-pss" ...
✓ Ensuring node image (kindest/node:v1.26.0) 🖼
✓ Preparing nodes 📦
✓ Writing configuration 📜
✓ Starting control-plane 🕹️
✓ Installing CNI 🔌
✓ Installing StorageClass 💾
Set kubectl context to "kind-psa-with-cluster-pss"
You can now use your cluster with:
kubectl cluster-info --context kind-psa-with-cluster-pss
Have a question, bug, or feature request? Let us know! https://kind.sigs.k8s.io/#community 🙂
将 kubectl 指向集群
kubectl cluster-info --context kind-psa-with-cluster-pss
输出类似于：
Kubernetes control plane is running at https://127.0.0.1:63855
CoreDNS is running at https://127.0.0.1:63855/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
在 default 名字空间下创建一个 Pod：
cat <<EOF > /tmp/pss/nginx-pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: nginx
spec:
containers:
- image: nginx
name: nginx
ports:
- containerPort: 80
EOF
在集群中创建 Pod：
kubectl apply -f https://k8s.io/examples/security/example-baseline-pod.yaml
这个 Pod 正常启动，但输出包含警告：
Warning: would violate PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "nginx" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "nginx" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "nginx" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "nginx" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")
pod/nginx created
现在通过运行以下命令删除你上面创建的集群：
kind delete cluster --name psa-with-cluster-pss
kind delete cluster --name psa-wo-cluster-pss
本教程仅适用于新集群。
Pod 安全准入（PSA）在 v1.23 及更高版本默认启用，
因为它升级到测试版（beta）。
Pod 安全准入是在创建 Pod 时应用
Pod 安全标准的准入控制器。
在本教程中，你将应用 baseline Pod 安全标准，每次一个名字空间。
你还可以在集群级别一次将 Pod 安全标准应用于多个名称空间。 有关说明，请参阅在集群级别应用 Pod 安全标准。
在你的工作站中安装以下内容：
按照如下方式创建一个 KinD 集群：
kind create cluster --name psa-ns-level
输出类似于：
Creating cluster "psa-ns-level" ...
✓ Ensuring node image (kindest/node:v1.26.0) 🖼
✓ Preparing nodes 📦
✓ Writing configuration 📜
✓ Starting control-plane 🕹️
✓ Installing CNI 🔌
✓ Installing StorageClass 💾
Set kubectl context to "kind-psa-ns-level"
You can now use your cluster with:
kubectl cluster-info --context kind-psa-ns-level
Not sure what to do next? 😅 Check out https://kind.sigs.k8s.io/docs/user/quick-start/
将 kubectl 上下文设置为新集群：
kubectl cluster-info --context kind-psa-ns-level
输出类似于：
Kubernetes control plane is running at https://127.0.0.1:50996
CoreDNS is running at https://127.0.0.1:50996/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
创建一个名为 example 的新名字空间：
kubectl create ns example
输出类似于：
namespace/example created
使用内置 Pod 安全准入所支持的标签在此名字空间上启用 Pod 安全标准。 在这一步中，我们将根据最新版本（默认值）对基线 Pod 安全标准发出警告。
kubectl label --overwrite ns example \
pod-security.kubernetes.io/warn=baseline \
pod-security.kubernetes.io/warn-version=latest
你可以使用标签在任何名字空间上配置多个 Pod 安全标准检查。
以下命令将强制（enforce） 执行基线（baseline）Pod 安全标准，
但根据最新版本（默认值）对受限（restricted）Pod 安全标准执行警告（warn）和审核（audit）。
kubectl label --overwrite ns example \
pod-security.kubernetes.io/enforce=baseline \
pod-security.kubernetes.io/enforce-version=latest \
pod-security.kubernetes.io/warn=restricted \
pod-security.kubernetes.io/warn-version=latest \
pod-security.kubernetes.io/audit=restricted \
pod-security.kubernetes.io/audit-version=latest
在 example 名字空间中创建一个基线 Pod：
kubectl apply -n example -f https://k8s.io/examples/security/example-baseline-pod.yaml
Pod 确实启动正常；输出包括一条警告信息。例如：
Warning: would violate PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "nginx" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "nginx" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "nginx" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "nginx" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")
pod/nginx created
在 default 名字空间中创建一个基线 Pod：
kubectl apply -n default -f https://k8s.io/examples/security/example-baseline-pod.yaml
输出类似于：
pod/nginx created
Pod 安全标准实施和警告设置仅被应用到 example 名字空间。
以上 Pod 安全标准仅被应用到 example 名字空间。
你可以在没有警告的情况下在 default 名字空间中创建相同的 Pod。
现在通过运行以下命令删除你上面创建的集群：
kind delete cluster --name psa-ns-level
运行一个 shell 脚本 一次执行所有前面的步骤。
enforce 模式下应用 baseline Pod 安全标准，
同时在 warn 和 audit 模式下应用 restricted Pod 安全标准。Kubernetes v1.4 [beta]AppArmor 是一个 Linux 内核安全模块， 它补充了基于标准 Linux 用户和组的权限，将程序限制在一组有限的资源中。 AppArmor 可以配置为任何应用程序减少潜在的攻击面，并且提供更加深入的防御。 它通过调整配置文件进行配置，以允许特定程序或容器所需的访问， 如 Linux 权能字、网络访问、文件权限等。 每个配置文件都可以在 强制（enforcing） 模式（阻止访问不允许的资源）或 投诉（complain） 模式（仅报告冲突）下运行。
AppArmor 可以通过限制允许容器执行的操作， 和/或通过系统日志提供更好的审计来帮助你运行更安全的部署。 但是，重要的是要记住 AppArmor 不是灵丹妙药， 只能做部分事情来防止应用程序代码中的漏洞。 提供良好的限制性配置文件，并从其他角度强化你的应用程序和集群非常重要。
确保：
Kubernetes 版本至少是 v1.4 —— AppArmor 在 Kubernetes v1.4 版本中才添加了对 AppArmor 的支持。 早于 v1.4 版本的 Kubernetes 组件不知道新的 AppArmor 注解并且将会 默认忽略 提供的任何 AppArmor 设置。 为了确保你的 Pod 能够得到预期的保护，必须验证节点的 Kubelet 版本：
kubectl get nodes -o=jsonpath=$'{range .items[*]}{@.metadata.name}: {@.status.nodeInfo.kubeletVersion}\n{end}'
gke-test-default-pool-239f5d02-gyn2: v1.4.0
gke-test-default-pool-239f5d02-x1kf: v1.4.0
gke-test-default-pool-239f5d02-xwux: v1.4.0
AppArmor 内核模块已启用 —— 要使 Linux 内核强制执行 AppArmor 配置文件，
必须安装并且启动 AppArmor 内核模块。默认情况下，有几个发行版支持该模块，
如 Ubuntu 和 SUSE，还有许多发行版提供可选支持。要检查模块是否已启用，请检查
/sys/module/apparmor/parameters/enabled 文件：
cat /sys/module/apparmor/parameters/enabled
Y
如果 Kubelet 包含 AppArmor 支持（>= v1.4）， 但是内核模块未启用，它将拒绝运行带有 AppArmor 选项的 Pod。
Ubuntu 携带了许多没有合并到上游 Linux 内核中的 AppArmor 补丁， 包括添加附加钩子和特性的补丁。Kubernetes 只在上游版本中测试过，不承诺支持其他特性。
配置文件已加载 —— 通过指定每个容器都应使用的 AppArmor 配置文件，
AppArmor 会被应用到 Pod 上。如果指定的任何配置文件尚未加载到内核，
Kubelet（>= v1.4）将拒绝 Pod。
通过检查 /sys/kernel/security/apparmor/profiles 文件，
可以查看节点加载了哪些配置文件。例如:
ssh gke-test-default-pool-239f5d02-gyn2 "sudo cat /sys/kernel/security/apparmor/profiles | sort"
apparmor-test-deny-write (enforce)
apparmor-test-audit-write (enforce)
docker-default (enforce)
k8s-nginx (enforce)
有关在节点上加载配置文件的详细信息，请参见使用配置文件设置节点。
只要 Kubelet 版本包含 AppArmor 支持(>=v1.4)， 如果不满足这些先决条件，Kubelet 将拒绝带有 AppArmor 选项的 Pod。 你还可以通过检查节点就绪状况消息来验证节点上的 AppArmor 支持（尽管这可能会在以后的版本中删除）：
kubectl get nodes -o=jsonpath='{range .items[*]}{@.metadata.name}: {.status.conditions[?(@.reason=="KubeletReady")].message}{"\n"}{end}'
gke-test-default-pool-239f5d02-gyn2: kubelet is posting ready status. AppArmor enabled
gke-test-default-pool-239f5d02-x1kf: kubelet is posting ready status. AppArmor enabled
gke-test-default-pool-239f5d02-xwux: kubelet is posting ready status. AppArmor enabled
AppArmor 目前处于 Beta 阶段，因此选项以注解形式设定。 一旦 AppArmor 支持进入正式发布阶段，注解将被替换为一阶的资源字段 （更多详情参见升级到 GA 的途径）。
AppArmor 配置文件是按 逐个容器 的形式来设置的。 要指定用来运行 Pod 容器的 AppArmor 配置文件，请向 Pod 的 metadata 添加注解：
container.apparmor.security.beta.kubernetes.io/<container_name>: <profile_ref>
<container_name> 的名称是配置文件所针对的容器的名称，<profile_def> 则设置要应用的配置文件。
<profile_ref> 可以是以下取值之一：
runtime/default 应用运行时的默认配置localhost/<profile_name> 应用在主机上加载的名为 <profile_name> 的配置文件unconfined 表示不加载配置文件有关注解和配置文件名称格式的详细信息，请参阅 API 参考。
Kubernetes AppArmor 强制执行机制首先检查所有先决条件都已满足， 然后将所选的配置文件转发到容器运行时进行强制执行。 如果未满足先决条件，Pod 将被拒绝，并且不会运行。
要验证是否应用了配置文件，可以在容器创建事件中查找所列出的 AppArmor 安全选项：
kubectl get events | grep Created
22s 22s 1 hello-apparmor Pod spec.containers{hello} Normal Created {kubelet e2e-test-stclair-node-pool-31nt} Created container with docker id 269a53b202d3; Security:[seccomp=unconfined apparmor=k8s-apparmor-example-deny-write]
你还可以通过检查容器的 proc attr，直接验证容器的根进程是否以正确的配置文件运行：
kubectl exec <pod_name> -- cat /proc/1/attr/current
k8s-apparmor-example-deny-write (enforce)
本例假设你已经设置了一个集群使用 AppArmor 支持。
首先，我们需要将要使用的配置文件加载到节点上。配置文件拒绝所有文件写入：
#include <tunables/global>
profile k8s-apparmor-example-deny-write flags=(attach_disconnected) {
#include <abstractions/base>
file,
# 拒绝所有文件写入
deny /** w,
}
由于我们不知道 Pod 将被调度到哪里，我们需要在所有节点上加载配置文件。 在本例中，我们将使用 SSH 来安装概要文件， 但是在使用配置文件设置节点中讨论了其他方法。
NODES=(
# 你的节点的可通过 SSH 访问的域名
gke-test-default-pool-239f5d02-gyn2.us-central1-a.my-k8s
gke-test-default-pool-239f5d02-x1kf.us-central1-a.my-k8s
gke-test-default-pool-239f5d02-xwux.us-central1-a.my-k8s)
for NODE in ${NODES[*]}; do ssh $NODE 'sudo apparmor_parser -q <<EOF
#include <tunables/global>
profile k8s-apparmor-example-deny-write flags=(attach_disconnected) {
#include <abstractions/base>
file,
# Deny all file writes.
deny /** w,
}
EOF'
done
接下来，我们将运行一个带有拒绝写入配置文件的简单 “Hello AppArmor” Pod：
apiVersion: v1
kind: Pod
metadata:
name: hello-apparmor
annotations:
# 告知 Kubernetes 去应用 AppArmor 配置 "k8s-apparmor-example-deny-write"。
# 请注意，如果节点上运行的 Kubernetes 不是 1.4 或更高版本，此注解将被忽略。
container.apparmor.security.beta.kubernetes.io/hello: localhost/k8s-apparmor-example-deny-write
spec:
containers:
- name: hello
image: busybox:1.28
command: [ "sh", "-c", "echo 'Hello AppArmor!' && sleep 1h" ]
kubectl create -f ./hello-apparmor.yaml
如果我们查看 Pod 事件，我们可以看到 Pod 容器是用 AppArmor 配置文件 “k8s-apparmor-example-deny-write” 所创建的：
kubectl get events | grep hello-apparmor
14s 14s 1 hello-apparmor Pod Normal Scheduled {default-scheduler } Successfully assigned hello-apparmor to gke-test-default-pool-239f5d02-gyn2
14s 14s 1 hello-apparmor Pod spec.containers{hello} Normal Pulling {kubelet gke-test-default-pool-239f5d02-gyn2} pulling image "busybox"
13s 13s 1 hello-apparmor Pod spec.containers{hello} Normal Pulled {kubelet gke-test-default-pool-239f5d02-gyn2} Successfully pulled image "busybox"
13s 13s 1 hello-apparmor Pod spec.containers{hello} Normal Created {kubelet gke-test-default-pool-239f5d02-gyn2} Created container with docker id 06b6cd1c0989; Security:[seccomp=unconfined apparmor=k8s-apparmor-example-deny-write]
13s 13s 1 hello-apparmor Pod spec.containers{hello} Normal Started {kubelet gke-test-default-pool-239f5d02-gyn2} Started container with docker id 06b6cd1c0989
我们可以通过检查该配置文件的 proc attr 来验证容器是否实际使用该配置文件运行：
kubectl exec hello-apparmor -- cat /proc/1/attr/current
k8s-apparmor-example-deny-write (enforce)
最后，我们可以看到，如果我们尝试通过写入文件来违反配置文件会发生什么：
kubectl exec hello-apparmor -- touch /tmp/test
touch: /tmp/test: Permission denied
error: error executing remote command: command terminated with non-zero exit code: Error executing in Docker Container: 1
最后，让我们看看如果我们试图指定一个尚未加载的配置文件会发生什么：
kubectl create -f /dev/stdin <<EOF
apiVersion: v1
kind: Pod
metadata:
name: hello-apparmor-2
annotations:
container.apparmor.security.beta.kubernetes.io/hello: localhost/k8s-apparmor-example-allow-write
spec:
containers:
- name: hello
image: busybox:1.28
command: [ "sh", "-c", "echo 'Hello AppArmor!' && sleep 1h" ]
EOF
pod/hello-apparmor-2 created
kubectl describe pod hello-apparmor-2
Name: hello-apparmor-2
Namespace: default
Node: gke-test-default-pool-239f5d02-x1kf/
Start Time: Tue, 30 Aug 2016 17:58:56 -0700
Labels: <none>
Annotations: container.apparmor.security.beta.kubernetes.io/hello=localhost/k8s-apparmor-example-allow-write
Status: Pending
Reason: AppArmor
Message: Pod Cannot enforce AppArmor: profile "k8s-apparmor-example-allow-write" is not loaded
IP:
Controllers: <none>
Containers:
hello:
Container ID:
Image: busybox
Image ID:
Port:
Command:
sh
-c
echo 'Hello AppArmor!' && sleep 1h
State: Waiting
Reason: Blocked
Ready: False
Restart Count: 0
Environment: <none>
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from default-token-dnz7v (ro)
Conditions:
Type Status
Initialized True
Ready False
PodScheduled True
Volumes:
default-token-dnz7v:
Type: Secret (a volume populated by a Secret)
SecretName: default-token-dnz7v
Optional: false
QoS Class: BestEffort
Node-Selectors: <none>
Tolerations: <none>
Events:
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
23s 23s 1 {default-scheduler } Normal Scheduled Successfully assigned hello-apparmor-2 to e2e-test-stclair-node-pool-t1f5
23s 23s 1 {kubelet e2e-test-stclair-node-pool-t1f5} Warning AppArmor Cannot enforce AppArmor: profile "k8s-apparmor-example-allow-write" is not loaded
注意 Pod 呈现 Pending 状态，并且显示一条有用的错误信息：
Pod Cannot enforce AppArmor: profile "k8s-apparmor-example-allow-write" is not loaded。
还用相同的消息记录了一个事件。
Kubernetes 目前不提供任何本地机制来将 AppArmor 配置文件加载到节点上。 有很多方法可以设置配置文件，例如：
调度程序不知道哪些配置文件加载到哪个节点上，因此必须将全套配置文件加载到每个节点上。 另一种方法是为节点上的每个配置文件（或配置文件类）添加节点标签， 并使用节点选择器确保 Pod 在具有所需配置文件的节点上运行。
如果你不希望 AppArmor 在集群上可用，可以通过命令行标志禁用它：
--feature-gates=AppArmor=false
禁用时，任何包含 AppArmor 配置文件的 Pod 都将导致验证失败，且返回 “Forbidden” 错误。
即使此 Kubernetes 特性被禁用，运行时仍可能强制执行默认配置文件。 当 AppArmor 升级为正式版 (GA) 时，禁用 AppArmor 功能的选项将被删除。
获得正确指定的 AppArmor 配置文件可能是一件棘手的事情。幸运的是，有一些工具可以帮助你做到这一点：
aa-genprof 和 aa-logprof
通过监视应用程序的活动和日志并准许它所执行的操作来生成配置文件规则。
AppArmor 文档提供了进一步的指导。想要调试 AppArmor 的问题，你可以检查系统日志，查看具体拒绝了什么。
AppArmor 将详细消息记录到 dmesg，
错误通常可以在系统日志中或通过 journalctl 找到。
更多详细信息参见 AppArmor 失败。
指定容器将使用的配置文件：
container.apparmor.security.beta.kubernetes.io/<container_name>，
其中 <container_name> 与 Pod 中某容器的名称匹配。
可以为 Pod 中的每个容器指定单独的配置文件。runtime/default：指默认运行时配置文件。localhost/<profile_name>：按名称引用加载到节点（localhost）上的配置文件。unconfined：这相当于为容器禁用 AppArmor。任何其他配置文件引用格式无效。
其他资源：
Kubernetes v1.19 [stable]Seccomp 代表安全计算（Secure Computing）模式，自 2.6.12 版本以来，一直是 Linux 内核的一个特性。 它可以用来沙箱化进程的权限，限制进程从用户态到内核态的调用。 Kubernetes 能使你自动将加载到 节点上的 seccomp 配置文件应用到你的 Pod 和容器。
识别你的工作负载所需要的权限是很困难的。在本篇教程中， 你将了解如何将 seccomp 配置文件加载到本地的 Kubernetes 集群中， 如何将它们应用到 Pod，以及如何开始制作只为容器进程提供必要的权限的配置文件。
为了完成本篇教程中的所有步骤，你必须安装 kind 和 kubectl。
本篇教程演示的某些示例仍然是 Beta 状态（自 v1.25 起），另一些示例则仅使用 seccomp 正式发布的功能。 你应该确保，针对你使用的版本， 正确配置了集群。
本篇教程也使用了 curl 工具来下载示例到你的计算机上。
你可以使用其他自己偏好的工具来自适应这些步骤。
无法将 seccomp 配置文件应用于在容器的 securityContext 中设置了 privileged: true 的容器。
特权容器始终以 Unconfined 的方式运行。
这些配置文件的内容将在稍后进行分析，
现在先将它们下载到名为 profiles/ 的目录中，以便将它们加载到集群中。
{
"defaultAction": "SCMP_ACT_LOG"
}{
"defaultAction": "SCMP_ACT_ERRNO"
}{
"defaultAction": "SCMP_ACT_ERRNO",
"architectures": [
"SCMP_ARCH_X86_64",
"SCMP_ARCH_X86",
"SCMP_ARCH_X32"
],
"syscalls": [
{
"names": [
"accept4",
"epoll_wait",
"pselect6",
"futex",
"madvise",
"epoll_ctl",
"getsockname",
"setsockopt",
"vfork",
"mmap",
"read",
"write",
"close",
"arch_prctl",
"sched_getaffinity",
"munmap",
"brk",
"rt_sigaction",
"rt_sigprocmask",
"sigaltstack",
"gettid",
"clone",
"bind",
"socket",
"openat",
"readlinkat",
"exit_group",
"epoll_create1",
"listen",
"rt_sigreturn",
"sched_yield",
"clock_gettime",
"connect",
"dup2",
"epoll_pwait",
"execve",
"exit",
"fcntl",
"getpid",
"getuid",
"ioctl",
"mprotect",
"nanosleep",
"open",
"poll",
"recvfrom",
"sendto",
"set_tid_address",
"setitimer",
"writev"
],
"action": "SCMP_ACT_ALLOW"
}
]
}执行这些命令：
mkdir ./profiles
curl -L -o profiles/audit.json https://k8s.io/examples/pods/security/seccomp/profiles/audit.json
curl -L -o profiles/violation.json https://k8s.io/examples/pods/security/seccomp/profiles/violation.json
curl -L -o profiles/fine-grained.json https://k8s.io/examples/pods/security/seccomp/profiles/fine-grained.json
ls profiles
你应该看到在最后一步的末尾列出有三个配置文件：
audit.json fine-grained.json violation.json
为简单起见，kind 可用来创建加载了 seccomp 配置文件的单节点集群。 Kind 在 Docker 中运行 Kubernetes，因此集群的每个节点都是一个容器。 这允许将文件挂载到每个容器的文件系统中，类似于将文件加载到节点上。
apiVersion: kind.x-k8s.io/v1alpha4
kind: Cluster
nodes:
- role: control-plane
extraMounts:
- hostPath: "./profiles"
containerPath: "/var/lib/kubelet/seccomp/profiles"下载该示例 kind 配置，并将其保存到名为 kind.yaml 的文件中：
curl -L -O https://k8s.io/examples/pods/security/seccomp/kind.yaml
你可以通过设置节点的容器镜像来设置特定的 Kubernetes 版本。 有关此类配置的更多信息， 参阅 kind 文档中节点小节。 本篇教程假定你正在使用 Kubernetes v1.26。
作为 Beta 特性，你可以将 Kubernetes
配置为使用容器运行时默认首选的配置文件，
而不是回退到 Unconfined。
如果你想尝试，请在继续之前参阅
启用使用 RuntimeDefault 作为所有工作负载的默认 seccomp 配置文件。
有了 kind 配置后，使用该配置创建 kind 集群：
kind create cluster --config=kind.yaml
新的 Kubernetes 集群准备就绪后，找出作为单节点集群运行的 Docker 容器：
docker ps
你应该看到输出中名为 kind-control-plane 的容器正在运行。
输出类似于：
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
6a96207fed4b kindest/node:v1.18.2 "/usr/local/bin/entr…" 27 seconds ago Up 24 seconds 127.0.0.1:42223->6443/tcp kind-control-plane
如果观察该容器的文件系统，
你应该会看到 profiles/ 目录已成功加载到 kubelet 的默认 seccomp 路径中。
使用 docker exec 在 Pod 中运行命令：
# 将 6a96207fed4b 更改为你从 “docker ps” 看到的容器 ID
docker exec -it 6a96207fed4b ls /var/lib/kubelet/seccomp/profiles
audit.json fine-grained.json violation.json
你已验证这些 seccomp 配置文件可用于在 kind 中运行的 kubelet。
RuntimeDefault 作为所有工作负载的默认 seccomp 配置文件Kubernetes v1.25 [beta]要使用 Seccomp（安全计算模式）配置文件来设定默认值，你必须要在启用 SeccompDefault
特性门控的情况下运行 kubelet
（这是默认值）。
你还必须显式地启用每个节点的默认行为，以及相应的
--seccomp-default 命令行标志。两者必须同时启用才能使用该特性。
如果启用，kubelet 将会默认使用 RuntimeDefault seccomp 配置文件，
（这一配置文明是由容器运行时定义的），而不是使用 Unconfined（禁用 seccomp）模式。
默认的配置文件旨在提供一组限制性较强且能保留工作负载功能的安全默认值。
不同容器运行时及其不同发布版本之间的默认配置文件可能有所不同，
例如在比较来自 CRI-O 和 containerd 的配置文件时。
启用该功能既不会更改 Kubernetes securityContext.seccompProfile API 字段，
也不会添加已弃用的工作负载注解。
这为用户提供了随时回滚的可能性，而且无需实际更改工作负载配置。
crictl inspect
之类的工具可用于验证容器正在使用哪个 seccomp 配置文件。
与其他工作负载相比，某些工作负载可能需要更少的系统调用限制。
这意味着即使使用 RuntimeDefault 配置文件，它们也可能在运行时失败。
要应对此类故障，你可以：
Unconfined。SeccompDefault 特性。还要确保工作负载被调度到禁用该特性的节点上。如果你将此特性引入到类似的生产集群中， Kubernetes 项目建议你在部分节点上启用此特性门控， 然后在整个集群范围内推出更改之前，测试工作负载执行情况。
你可以在相关的 Kubernetes 增强提案（KEP） 中找到可能的升级和降级策略的更详细信息: 默认启用 Seccomp。
Kubernetes 1.26 允许你配置 Seccomp 配置文件，
当 Pod 的规约未定义特定的 Seccomp 配置文件时应用该配置文件。
这是一个 Beta 特性，默认启用相应的 SeccompDefault 特性门控。
但是，你仍然需要为要使用它的每个节点启用此默认设置。
如果你正在运行 Kubernetes 1.26
集群并希望启用该特性，请使用 --seccomp-default 命令行参数运行 kubelet，
或通过 kubelet 配置文件启用。
要在 kind 启用特性门控，
请确保 kind 提供所需的最低 Kubernetes 版本，
并在 kind 配置中
启用了 SeccompDefault 特性：
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
featureGates:
SeccompDefault: true
nodes:
- role: control-plane
image: kindest/node:v1.23.0@sha256:49824ab1727c04e56a21a5d8372a402fcd32ea51ac96a2706a12af38934f81ac
kubeadmConfigPatches:
- |
kind: JoinConfiguration
nodeRegistration:
kubeletExtraArgs:
seccomp-default: "true"
- role: worker
image: kindest/node:v1.23.0@sha256:49824ab1727c04e56a21a5d8372a402fcd32ea51ac96a2706a12af38934f81ac
kubeadmConfigPatches:
- |
kind: JoinConfiguration
nodeRegistration:
kubeletExtraArgs:
feature-gates: SeccompDefault=true
seccomp-default: "true"
如果集群已就绪，则运行一个 Pod：
kubectl run --rm -it --restart=Never --image=alpine alpine -- sh
现在应该附加了默认的 seccomp 配置文件。
这可以通过使用 docker exec 为 kind 上的容器运行 crictl inspect 来验证：
docker exec -it kind-worker bash -c \
'crictl inspect $(crictl ps --name=alpine -q) | jq .info.runtimeSpec.linux.seccomp'
{
"defaultAction": "SCMP_ACT_ERRNO",
"architectures": ["SCMP_ARCH_X86_64", "SCMP_ARCH_X86", "SCMP_ARCH_X32"],
"syscalls": [
{
"names": ["..."]
}
]
}
大多数容器运行时都提供了一组合理的、默认被允许或默认被禁止的系统调用。
你可以通过将 Pod 或容器的安全上下文中的 seccomp 类型设置为 RuntimeDefault
来为你的工作负载采用这些默认值。
如果你已经启用了 SeccompDefault 特性门控，
只要没有指定其他 seccomp 配置文件，那么 Pod 就会使用 RuntimeDefault seccomp 配置文件。
否则，默认值为 Unconfined。
这是一个 Pod 的清单，它要求其所有容器使用 RuntimeDefault seccomp 配置文件：
apiVersion: v1
kind: Pod
metadata:
name: default-pod
labels:
app: default-pod
spec:
securityContext:
seccompProfile:
type: RuntimeDefault
containers:
- name: test-container
image: hashicorp/http-echo:0.2.3
args:
- "-text=just made some more syscalls!"
securityContext:
allowPrivilegeEscalation: false创建此 Pod：
kubectl apply -f https://k8s.io/examples/pods/security/seccomp/ga/default-pod.yaml
kubectl get pod default-pod
此 Pod 应该显示为已成功启动：
NAME READY STATUS RESTARTS AGE
default-pod 1/1 Running 0 20s
最后，你看到一切正常之后，请清理：
kubectl delete pod default-pod --wait --now
首先，将 audit.json 配置文件应用到新的 Pod 上，该配置文件将记录进程的所有系统调用。
这是该 Pod 的清单：
apiVersion: v1
kind: Pod
metadata:
name: audit-pod
labels:
app: audit-pod
spec:
securityContext:
seccompProfile:
type: Localhost
localhostProfile: profiles/audit.json
containers:
- name: test-container
image: hashicorp/http-echo:0.2.3
args:
- "-text=just made some syscalls!"
securityContext:
allowPrivilegeEscalation: false已弃用的 seccomp 注解 seccomp.security.alpha.kubernetes.io/pod（针对整个 Pod）和
container.seccomp.security.alpha.kubernetes.io/[name]（针对单个容器）
将随着未来 Kubernetes 的发布而被删除。
请在可能的情况下使用原生 API 字段而不是注解。
从 Kubernetes v1.25 开始，kubelet 不再支持这些注解， 也不再支持在静态 Pod 中使用注解，并且当创建带有 seccomp 字段的 Pod 时不再自动填充 seccomp 注解。 从注释中自动填充 seccomp 字段的特性，将计划在未来的版本中删除。
在集群中创建 Pod：
kubectl apply -f https://k8s.io/examples/pods/security/seccomp/ga/audit-pod.yaml
此配置文件不限制任何系统调用，因此 Pod 应该成功启动。
kubectl get pod/audit-pod
NAME READY STATUS RESTARTS AGE
audit-pod 1/1 Running 0 30s
为了能够与容器暴露的端点交互， 创建一个 NodePort 类型的 Service， 允许从 kind 控制平面容器内部访问端点。
kubectl expose pod audit-pod --type NodePort --port 5678
检查 Service 在节点上分配的端口。
kubectl get service audit-pod
输出类似于：
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
audit-pod NodePort 10.111.36.142 <none> 5678:32373/TCP 72s
现在，你可以使用 curl 从 kind 控制平面容器内部访问该端点，位于该服务所公开的端口上。
使用 docker exec 在属于该控制平面容器的容器中运行 curl 命令：
# 将 6a96207fed4b 更改为你从 “docker ps” 看到的控制平面容器 ID
docker exec -it 6a96207fed4b curl localhost:32373
just made some syscalls!
你可以看到该进程正在运行，但它实际上进行了哪些系统调用？
因为这个 Pod 在本地集群中运行，你应该能够在 /var/log/syslog 中看到它们。
打开一个新的终端窗口并 tail 来自 http-echo 的调用的输出：
tail -f /var/log/syslog | grep 'http-echo'
你应该已经看到了一些由 http-echo 进行的系统调用的日志，
如果你在控制平面容器中 curl 端点，你会看到更多的写入。
例如：
Jul 6 15:37:40 my-machine kernel: [369128.669452] audit: type=1326 audit(1594067860.484:14536): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=29064 comm="http-echo" exe="/http-echo" sig=0 arch=c000003e syscall=51 compat=0 ip=0x46fe1f code=0x7ffc0000
Jul 6 15:37:40 my-machine kernel: [369128.669453] audit: type=1326 audit(1594067860.484:14537): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=29064 comm="http-echo" exe="/http-echo" sig=0 arch=c000003e syscall=54 compat=0 ip=0x46fdba code=0x7ffc0000
Jul 6 15:37:40 my-machine kernel: [369128.669455] audit: type=1326 audit(1594067860.484:14538): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=29064 comm="http-echo" exe="/http-echo" sig=0 arch=c000003e syscall=202 compat=0 ip=0x455e53 code=0x7ffc0000
Jul 6 15:37:40 my-machine kernel: [369128.669456] audit: type=1326 audit(1594067860.484:14539): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=29064 comm="http-echo" exe="/http-echo" sig=0 arch=c000003e syscall=288 compat=0 ip=0x46fdba code=0x7ffc0000
Jul 6 15:37:40 my-machine kernel: [369128.669517] audit: type=1326 audit(1594067860.484:14540): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=29064 comm="http-echo" exe="/http-echo" sig=0 arch=c000003e syscall=0 compat=0 ip=0x46fd44 code=0x7ffc0000
Jul 6 15:37:40 my-machine kernel: [369128.669519] audit: type=1326 audit(1594067860.484:14541): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=29064 comm="http-echo" exe="/http-echo" sig=0 arch=c000003e syscall=270 compat=0 ip=0x4559b1 code=0x7ffc0000
Jul 6 15:38:40 my-machine kernel: [369188.671648] audit: type=1326 audit(1594067920.488:14559): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=29064 comm="http-echo" exe="/http-echo" sig=0 arch=c000003e syscall=270 compat=0 ip=0x4559b1 code=0x7ffc0000
Jul 6 15:38:40 my-machine kernel: [369188.671726] audit: type=1326 audit(1594067920.488:14560): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=29064 comm="http-echo" exe="/http-echo" sig=0 arch=c000003e syscall=202 compat=0 ip=0x455e53 code=0x7ffc0000
通过查看每一行的 syscall= 条目，你可以开始了解 http-echo 进程所需的系统调用。
虽然这些不太可能包含它使用的所有系统调用，但它可以作为此容器的 seccomp 配置文件的基础。
在转到下一部分之前清理该 Pod 和 Service：
kubectl delete service audit-pod --wait
kubectl delete pod audit-pod --wait --now
出于演示目的，将配置文件应用于不允许任何系统调用的 Pod 上。
此演示的清单是：
apiVersion: v1
kind: Pod
metadata:
name: violation-pod
labels:
app: violation-pod
spec:
securityContext:
seccompProfile:
type: Localhost
localhostProfile: profiles/violation.json
containers:
- name: test-container
image: hashicorp/http-echo:0.2.3
args:
- "-text=just made some syscalls!"
securityContext:
allowPrivilegeEscalation: false尝试在集群中创建 Pod：
kubectl apply -f https://k8s.io/examples/pods/security/seccomp/ga/violation-pod.yaml
Pod 创建，但存在问题。 如果你检查 Pod 状态，你应该看到它没有启动。
kubectl get pod/violation-pod
NAME READY STATUS RESTARTS AGE
violation-pod 0/1 CrashLoopBackOff 1 6s
如上例所示，http-echo 进程需要相当多的系统调用。
这里 seccomp 已通过设置 "defaultAction": "SCMP_ACT_ERRNO" 被指示为在发生任何系统调用时报错。
这是非常安全的，但消除了做任何有意义的事情的能力。
你真正想要的是只给工作负载它们所需要的权限。
在转到下一部分之前清理该 Pod：
kubectl delete pod violation-pod --wait --now
如果你看一看 fine-grained.json 配置文件，
你会注意到第一个示例的 syslog 中看到的一些系统调用，
其中配置文件设置为 "defaultAction": "SCMP_ACT_LOG"。
现在的配置文件设置 "defaultAction": "SCMP_ACT_ERRNO",
但在 "action": "SCMP_ACT_ALLOW" 块中明确允许一组系统调用。
理想情况下，容器将成功运行，并且你看到没有消息发送到 syslog。
此示例的清单是：
apiVersion: v1
kind: Pod
metadata:
name: fine-pod
labels:
app: fine-pod
spec:
securityContext:
seccompProfile:
type: Localhost
localhostProfile: profiles/fine-grained.json
containers:
- name: test-container
image: hashicorp/http-echo:0.2.3
args:
- "-text=just made some syscalls!"
securityContext:
allowPrivilegeEscalation: false在你的集群中创建 Pod：
kubectl apply -f https://k8s.io/examples/pods/security/seccomp/ga/fine-pod.yaml
kubectl get pod fine-pod
此 Pod 应该显示为已成功启动：
NAME READY STATUS RESTARTS AGE
fine-pod 1/1 Running 0 30s
打开一个新的终端窗口并使用 tail 来监视提到来自 http-echo 的调用的日志条目：
# 你计算机上的日志路径可能与 “/var/log/syslog” 不同
tail -f /var/log/syslog | grep 'http-echo'
接着，使用 NodePort Service 公开 Pod：
kubectl expose pod fine-pod --type NodePort --port 5678
检查节点上的 Service 分配了什么端口：
kubectl get service fine-pod
输出类似于：
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
fine-pod NodePort 10.111.36.142 <none> 5678:32373/TCP 72s
使用 curl 从 kind 控制平面容器内部访问端点：
# 将 6a96207fed4b 更改为你从 “docker ps” 看到的控制平面容器 ID
docker exec -it 6a96207fed4b curl localhost:32373
just made some syscalls!
你应该在 syslog 中看不到任何输出。
这是因为配置文件允许所有必要的系统调用，并指定如果调用列表之外的系统调用应发生错误。
从安全角度来看，这是一种理想的情况，但需要在分析程序时付出一些努力。
如果有一种简单的方法可以在不需要太多努力的情况下更接近这种安全性，那就太好了。
在转到下一部分之前清理该 Pod 和服务：
kubectl delete service fine-pod --wait
kubectl delete pod fine-pod --wait --now
你可以了解有关 Linux seccomp 的更多信息：
此页面显示如何创建公开外部 IP 地址的 Kubernetes 服务对象。
kubectl 与 Kubernetes API 服务器通信。有关说明，请参阅云供应商文档。在集群中运行 Hello World 应用程序：
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app.kubernetes.io/name: load-balancer-example
name: hello-world
spec:
replicas: 5
selector:
matchLabels:
app.kubernetes.io/name: load-balancer-example
template:
metadata:
labels:
app.kubernetes.io/name: load-balancer-example
spec:
containers:
- image: gcr.io/google-samples/node-hello:1.0
name: hello-world
ports:
- containerPort: 8080
kubectl apply -f https://k8s.io/examples/service/load-balancer-example.yaml
前面的命令创建一个 Deployment 对象和一个关联的 ReplicaSet 对象。 ReplicaSet 有五个 Pods， 每个都运行 Hello World 应用程序。
显示有关 Deployment 的信息：
kubectl get deployments hello-world
kubectl describe deployments hello-world
显示有关 ReplicaSet 对象的信息：
kubectl get replicasets
kubectl describe replicasets
创建公开 Deployment 的 Service 对象：
kubectl expose deployment hello-world --type=LoadBalancer --name=my-service
显示有关 Service 的信息：
kubectl get services my-service
输出类似于：
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
my-service LoadBalancer 10.3.245.137 104.198.205.71 8080/TCP 54s
type=LoadBalancer 服务由外部云服务提供商提供支持，本例中不包含此部分，
详细信息请参考此页
如果外部 IP 地址显示为 <pending>，请等待一分钟再次输入相同的命令。
显示有关 Service 的详细信息：
kubectl describe services my-service
输出类似于：
Name: my-service
Namespace: default
Labels: app.kubernetes.io/name=load-balancer-example
Annotations: <none>
Selector: app.kubernetes.io/name=load-balancer-example
Type: LoadBalancer
IP: 10.3.245.137
LoadBalancer Ingress: 104.198.205.71
Port: <unset> 8080/TCP
NodePort: <unset> 32377/TCP
Endpoints: 10.0.0.6:8080,10.0.1.6:8080,10.0.1.7:8080 + 2 more...
Session Affinity: None
Events: <none>
记下服务公开的外部 IP 地址（LoadBalancer Ingress)。
在本例中，外部 IP 地址是 104.198.205.71。还要注意 Port 和 NodePort 的值。
在本例中，Port 是 8080，NodePort 是 32377。
在前面的输出中，你可以看到服务有几个端点： 10.0.0.6:8080、10.0.1.6:8080、10.0.1.7:8080 和另外两个， 这些都是正在运行 Hello World 应用程序的 Pod 的内部地址。 要验证这些是 Pod 地址，请输入以下命令：
kubectl get pods --output=wide
输出类似于：
NAME ... IP NODE
hello-world-2895499144-1jaz9 ... 10.0.1.6 gke-cluster-1-default-pool-e0b8d269-1afc
hello-world-2895499144-2e5uh ... 10.0.1.8 gke-cluster-1-default-pool-e0b8d269-1afc
hello-world-2895499144-9m4h1 ... 10.0.0.6 gke-cluster-1-default-pool-e0b8d269-5v7a
hello-world-2895499144-o4z13 ... 10.0.1.7 gke-cluster-1-default-pool-e0b8d269-1afc
hello-world-2895499144-segjf ... 10.0.2.5 gke-cluster-1-default-pool-e0b8d269-cpuc
使用外部 IP 地址（LoadBalancer Ingress）访问 Hello World 应用程序:
curl http://<external-ip>:<port>
其中 <external-ip> 是你的服务的外部 IP 地址（LoadBalancer Ingress），
<port> 是你的服务描述中的 port 的值。
如果你正在使用 minikube，输入 minikube service my-service
将在浏览器中自动打开 Hello World 应用程序。
成功请求的响应是一条问候消息：
Hello Kubernetes!
要删除 Service，请输入以下命令：
kubectl delete services my-service
要删除正在运行 Hello World 应用程序的 Deployment、ReplicaSet 和 Pod，请输入以下命令：
kubectl delete deployment hello-world
进一步了解使用 Service 连接到应用。
本教程向你展示如何使用 Kubernetes 和 Docker 构建和部署一个简单的 (非面向生产的) 多层 Web 应用程序。本例由以下组件组成：
你必须拥有一个 Kubernetes 的集群，同时你的 Kubernetes 集群必须带有 kubectl 命令行工具。 建议在至少有两个节点的集群上运行本教程，且这些节点不作为控制平面主机。 如果你还没有集群，你可以通过 Minikube 构建一个你自己的集群，或者你可以使用下面任意一个 Kubernetes 工具构建：
你的 Kubernetes 服务器版本必须不低于版本 v1.14. 要获知版本信息，请输入kubectl version.留言板应用程序使用 Redis 存储数据。
下面包含的清单文件指定了一个 Deployment 控制器，该控制器运行一个 Redis Pod 副本。
# 来源：https://cloud.google.com/kubernetes-engine/docs/tutorials/guestbook
apiVersion: apps/v1
kind: Deployment
metadata:
name: redis-leader
labels:
app: redis
role: leader
tier: backend
spec:
replicas: 1
selector:
matchLabels:
app: redis
template:
metadata:
labels:
app: redis
role: leader
tier: backend
spec:
containers:
- name: leader
image: "docker.io/redis:6.0.5"
resources:
requests:
cpu: 100m
memory: 100Mi
ports:
- containerPort: 6379在下载清单文件的目录中启动终端窗口。
从 redis-leader-deployment.yaml 文件中应用 Redis Deployment：
kubectl apply -f https://k8s.io/examples/application/guestbook/redis-leader-deployment.yaml
查询 Pod 列表以验证 Redis Pod 是否正在运行：
kubectl get pods
响应应该与此类似：
NAME READY STATUS RESTARTS AGE
redis-leader-fb76b4755-xjr2n 1/1 Running 0 13s
运行以下命令查看 Redis Deployment 中的日志：
kubectl logs -f deployment/redis-leader
留言板应用程序需要往 Redis 中写数据。因此，需要创建 Service 来转发 Redis Pod 的流量。Service 定义了访问 Pod 的策略。
# 来源：https://cloud.google.com/kubernetes-engine/docs/tutorials/guestbook
apiVersion: v1
kind: Service
metadata:
name: redis-leader
labels:
app: redis
role: leader
tier: backend
spec:
ports:
- port: 6379
targetPort: 6379
selector:
app: redis
role: leader
tier: backend使用下面的 redis-leader-service.yaml 文件创建 Redis的服务：
kubectl apply -f https://k8s.io/examples/application/guestbook/redis-leader-service.yaml
查询服务列表验证 Redis 服务是否正在运行：
kubectl get service
响应应该与此类似：
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.0.0.1 <none> 443/TCP 1m
redis-leader ClusterIP 10.103.78.24 <none> 6379/TCP 16s
这个清单文件创建了一个名为 redis-leader 的 Service，其中包含一组
与前面定义的标签匹配的标签，因此服务将网络流量路由到 Redis Pod 上。
尽管 Redis 领导者只有一个 Pod，你可以通过添加若干 Redis 跟随者来将其配置为高可用状态， 以满足流量需求。
# 来源：https://cloud.google.com/kubernetes-engine/docs/tutorials/guestbook
apiVersion: apps/v1
kind: Deployment
metadata:
name: redis-follower
labels:
app: redis
role: follower
tier: backend
spec:
replicas: 2
selector:
matchLabels:
app: redis
template:
metadata:
labels:
app: redis
role: follower
tier: backend
spec:
containers:
- name: follower
image: gcr.io/google_samples/gb-redis-follower:v2
resources:
requests:
cpu: 100m
memory: 100Mi
ports:
- containerPort: 6379应用下面的 redis-follower-deployment.yaml 文件创建 Redis Deployment：
kubectl apply -f https://k8s.io/examples/application/guestbook/redis-follower-deployment.yaml
通过查询 Pods 列表，验证两个 Redis 跟随者副本在运行：
kubectl get pods
响应应该类似于这样：
NAME READY STATUS RESTARTS AGE
redis-follower-dddfbdcc9-82sfr 1/1 Running 0 37s
redis-follower-dddfbdcc9-qrt5k 1/1 Running 0 38s
redis-leader-fb76b4755-xjr2n 1/1 Running 0 11m
Guestbook 应用需要与 Redis 跟随者通信以读取数据。 为了让 Redis 跟随者可被发现，你必须创建另一个 Service。
# 来源：https://cloud.google.com/kubernetes-engine/docs/tutorials/guestbook
apiVersion: v1
kind: Service
metadata:
name: redis-follower
labels:
app: redis
role: follower
tier: backend
spec:
ports:
# 此服务应使用的端口
- port: 6379
selector:
app: redis
role: follower
tier: backend应用如下所示 redis-follower-service.yaml 文件中的 Redis Service：
kubectl apply -f https://k8s.io/examples/application/guestbook/redis-follower-service.yaml
查询 Service 列表，验证 Redis 服务在运行：
kubectl get service
响应应该类似于这样：
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 3d19h
redis-follower ClusterIP 10.110.162.42 <none> 6379/TCP 9s
redis-leader ClusterIP 10.103.78.24 <none> 6379/TCP 6m10s
清单文件创建了一个名为 redis-follower 的 Service，该 Service
具有一些与之前所定义的标签相匹配的标签，因此该 Service 能够将网络流量路由到
Redis Pod 之上。
现在你有了一个为 Guestbook 应用配置的 Redis 存储处于运行状态， 接下来可以启动 Guestbook 的 Web 服务器了。 与 Redis 跟随者类似，前端也是使用 Kubernetes Deployment 来部署的。
Guestbook 应用使用 PHP 前端。该前端被配置成与后端的 Redis 跟随者或者 领导者服务通信，具体选择哪个服务取决于请求是读操作还是写操作。 前端对外暴露一个 JSON 接口，并提供基于 jQuery-Ajax 的用户体验。
# 来源：https://cloud.google.com/kubernetes-engine/docs/tutorials/guestbook
apiVersion: apps/v1
kind: Deployment
metadata:
name: frontend
spec:
replicas: 3
selector:
matchLabels:
app: guestbook
tier: frontend
template:
metadata:
labels:
app: guestbook
tier: frontend
spec:
containers:
- name: php-redis
image: gcr.io/google_samples/gb-frontend:v5
env:
- name: GET_HOSTS_FROM
value: "dns"
resources:
requests:
cpu: 100m
memory: 100Mi
ports:
- containerPort: 80应用来自 frontend-deployment.yaml 文件的前端 Deployment：
kubectl apply -f https://k8s.io/examples/application/guestbook/frontend-deployment.yaml
查询 Pod 列表，验证三个前端副本正在运行：
kubectl get pods -l app=guestbook -l tier=frontend
响应应该与此类似：
NAME READY STATUS RESTARTS AGE
frontend-85595f5bf9-5tqhb 1/1 Running 0 47s
frontend-85595f5bf9-qbzwm 1/1 Running 0 47s
frontend-85595f5bf9-zchwc 1/1 Running 0 47s
应用的 Redis 服务只能在 Kubernetes 集群中访问，因为服务的默认类型是
ClusterIP。
ClusterIP 为服务指向的 Pod 集提供一个 IP 地址。这个 IP 地址只能在集群中访问。
如果你希望访客能够访问你的 Guestbook，你必须将前端服务配置为外部可见的，
以便客户端可以从 Kubernetes 集群之外请求服务。
然而即便使用了 ClusterIP，Kubernetes 用户仍可以通过
kubectl port-forward 访问服务。
一些云提供商，如 Google Compute Engine 或 Google Kubernetes Engine，
支持外部负载均衡器。如果你的云提供商支持负载均衡器，并且你希望使用它，
只需取消注释 type: LoadBalancer。
# 来源：https://cloud.google.com/kubernetes-engine/docs/tutorials/guestbook
apiVersion: v1
kind: Service
metadata:
name: frontend
labels:
app: guestbook
tier: frontend
spec:
# 如果你的集群支持，请取消注释以下内容以自动为前端服务创建一个外部负载均衡 IP。
# type: LoadBalancer
#type: LoadBalancer
ports:
# 此服务应使用的端口
- port: 80
selector:
app: guestbook
tier: frontend应用来自 frontend-service.yaml 文件中的前端服务：
kubectl apply -f https://k8s.io/examples/application/guestbook/frontend-service.yaml
查询 Service 列表以验证前端服务正在运行:
kubectl get services
响应应该与此类似：
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
frontend ClusterIP 10.97.28.230 <none> 80/TCP 19s
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 3d19h
redis-follower ClusterIP 10.110.162.42 <none> 6379/TCP 5m48s
redis-leader ClusterIP 10.103.78.24 <none> 6379/TCP 11m
kubectl port-forward 查看前端服务运行以下命令将本机的 8080 端口转发到服务的 80 端口。
kubectl port-forward svc/frontend 8080:80
响应应该与此类似：
Forwarding from 127.0.0.1:8080 -> 80
Forwarding from [::1]:8080 -> 80
LoadBalancer 查看前端服务如果你部署了 frontend-service.yaml，需要找到用来查看 Guestbook 的 IP 地址。
运行以下命令以获取前端服务的 IP 地址。
kubectl get service frontend
响应应该与此类似：
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
frontend LoadBalancer 10.51.242.136 109.197.92.229 80:32372/TCP 1m
尝试通过输入消息并点击 Submit 来添加一些留言板条目。 你所输入的消息会在前端显示。这一消息表明数据被通过你之前所创建的 Service 添加到 Redis 存储中。
你可以根据需要执行伸缩操作，这是因为服务器本身被定义为使用一个 Deployment 控制器的 Service。
运行以下命令扩展前端 Pod 的数量：
kubectl scale deployment frontend --replicas=5
查询 Pod 列表验证正在运行的前端 Pod 的数量：
kubectl get pods
响应应该类似于这样：
NAME READY STATUS RESTARTS AGE
frontend-85595f5bf9-5df5m 1/1 Running 0 83s
frontend-85595f5bf9-7zmg5 1/1 Running 0 83s
frontend-85595f5bf9-cpskg 1/1 Running 0 15m
frontend-85595f5bf9-l2l54 1/1 Running 0 14m
frontend-85595f5bf9-l9c8z 1/1 Running 0 14m
redis-follower-dddfbdcc9-82sfr 1/1 Running 0 97m
redis-follower-dddfbdcc9-qrt5k 1/1 Running 0 97m
redis-leader-fb76b4755-xjr2n 1/1 Running 0 108m
运行以下命令缩小前端 Pod 的数量：
kubectl scale deployment frontend --replicas=2
查询 Pod 列表验证正在运行的前端 Pod 的数量：
kubectl get pods
响应应该类似于这样：
NAME READY STATUS RESTARTS AGE
frontend-85595f5bf9-cpskg 1/1 Running 0 16m
frontend-85595f5bf9-l9c8z 1/1 Running 0 15m
redis-follower-dddfbdcc9-82sfr 1/1 Running 0 98m
redis-follower-dddfbdcc9-qrt5k 1/1 Running 0 98m
redis-leader-fb76b4755-xjr2n 1/1 Running 0 109m
删除 Deployments 和服务还会删除正在运行的 Pod。 使用标签用一个命令删除多个资源。
运行以下命令以删除所有 Pod、Deployment 和 Service。
kubectl delete deployment -l app=redis
kubectl delete service -l app=redis
kubectl delete deployment frontend
kubectl delete service frontend
响应应该是：
deployment.apps "redis-follower" deleted
deployment.apps "redis-leader" deleted
deployment.apps "frontend" deleted
service "frontend" deleted
查询 Pod 列表，确认没有 Pod 在运行：
kubectl get pods
响应应该是：
No resources found in default namespace.
本教程介绍了如何使用 StatefulSet 来管理应用。 演示了如何创建、删除、扩容/缩容和更新 StatefulSet 的 Pod。
在开始本教程之前，你应该熟悉以下 Kubernetes 的概念：
本教程假设你的集群被配置为动态制备 PersistentVolume 卷。 如果没有这样配置，在开始本教程之前，你需要手动准备 2 个 1 GiB 的存储卷。
StatefulSet 旨在与有状态的应用及分布式系统一起使用。然而在 Kubernetes 上管理有状态应用和分布式系统是一个宽泛而复杂的话题。 为了演示 StatefulSet 的基本特性，并且不使前后的主题混淆，你将会使用 StatefulSet 部署一个简单的 Web 应用。
在阅读本教程后，你将熟悉以下内容：
作为开始，使用如下示例创建一个 StatefulSet。它和
StatefulSet 概念中的示例相似。
它创建了一个 Headless Service
nginx 用来发布 StatefulSet web 中的 Pod 的 IP 地址。
apiVersion: v1
kind: Service
metadata:
name: nginx
labels:
app: nginx
spec:
ports:
- port: 80
name: web
clusterIP: None
selector:
app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: web
spec:
serviceName: "nginx"
replicas: 2
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: registry.k8s.io/nginx-slim:0.8
ports:
- containerPort: 80
name: web
volumeMounts:
- name: www
mountPath: /usr/share/nginx/html
volumeClaimTemplates:
- metadata:
name: www
spec:
accessModes: [ "ReadWriteOnce" ]
resources:
requests:
storage: 1Gi
下载上面的例子并保存为文件 web.yaml。
你需要使用两个终端窗口。在第一个终端中，使用
kubectl get
来监视 StatefulSet 的 Pod 的创建情况。
kubectl get pods -w -l app=nginx
在另一个终端中，使用 kubectl apply
来创建定义在 web.yaml 中的 Headless Service 和 StatefulSet。
kubectl apply -f web.yaml
service/nginx created
statefulset.apps/web created
上面的命令创建了两个 Pod，每个都运行了一个 NginX Web 服务器。
获取 nginx Service：
kubectl get service nginx
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
nginx ClusterIP None <none> 80/TCP 12s
然后获取 web StatefulSet，以验证两者均已成功创建：
kubectl get statefulset web
NAME DESIRED CURRENT AGE
web 2 1 20s
对于一个拥有 n 个副本的 StatefulSet，Pod 被部署时是按照 {0..n-1} 的序号顺序创建的。
在第一个终端中使用 kubectl get 检查输出。这个输出最终将看起来像下面的样子。
kubectl get pods -w -l app=nginx
NAME READY STATUS RESTARTS AGE
web-0 0/1 Pending 0 0s
web-0 0/1 Pending 0 0s
web-0 0/1 ContainerCreating 0 0s
web-0 1/1 Running 0 19s
web-1 0/1 Pending 0 0s
web-1 0/1 Pending 0 0s
web-1 0/1 ContainerCreating 0 0s
web-1 1/1 Running 0 18s
请注意，直到 web-0 Pod 处于 Running（请参阅
Pod 阶段）
并 Ready（请参阅 Pod 状况中的
type）状态后，web-1 Pod 才会被启动。
要配置分配给 StatefulSet 中每个 Pod 的整数序号， 请参阅起始序号。
StatefulSet 中的每个 Pod 拥有一个唯一的顺序索引和稳定的网络身份标识。
获取 StatefulSet 的 Pod：
kubectl get pods -l app=nginx
NAME READY STATUS RESTARTS AGE
web-0 1/1 Running 0 1m
web-1 1/1 Running 0 1m
如同 StatefulSet 概念中所提到的，
StatefulSet 中的每个 Pod 拥有一个具有黏性的、独一无二的身份标志。
这个标志基于 StatefulSet
控制器分配给每个
Pod 的唯一顺序索引。
Pod 名称的格式为 <statefulset 名称>-<序号索引>。
web StatefulSet 拥有两个副本，所以它创建了两个 Pod：web-0 和 web-1。
每个 Pod 都拥有一个基于其顺序索引的稳定的主机名。使用
kubectl exec
在每个 Pod 中执行 hostname：
for i in 0 1; do kubectl exec "web-$i" -- sh -c 'hostname'; done
web-0
web-1
使用 kubectl run
运行一个提供 nslookup 命令的容器，该命令来自于 dnsutils 包。
通过对 Pod 的主机名执行 nslookup，你可以检查这些主机名在集群内部的 DNS 地址：
kubectl run -i --tty --image busybox:1.28 dns-test --restart=Never --rm
这将启动一个新的 Shell。在新 Shell 中运行：
# 在 dns-test 容器 Shell 中运行以下命令
nslookup web-0.nginx
输出类似于：
Server: 10.0.0.10
Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local
Name: web-0.nginx
Address 1: 10.244.1.6
nslookup web-1.nginx
Server: 10.0.0.10
Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local
Name: web-1.nginx
Address 1: 10.244.2.6
（现在可以退出容器 Shell：exit）
headless service 的 CNAME 指向 SRV 记录（记录每个 Running 和 Ready 状态的 Pod）。 SRV 记录指向一个包含 Pod IP 地址的记录表项。
在一个终端中监视 StatefulSet 的 Pod：
kubectl get pod -w -l app=nginx
在另一个终端中使用
kubectl delete
删除 StatefulSet 中所有的 Pod：
kubectl delete pod -l app=nginx
pod "web-0" deleted
pod "web-1" deleted
等待 StatefulSet 重启它们，并且两个 Pod 都变成 Running 和 Ready 状态：
kubectl get pod -w -l app=nginx
NAME READY STATUS RESTARTS AGE
web-0 0/1 ContainerCreating 0 0s
NAME READY STATUS RESTARTS AGE
web-0 1/1 Running 0 2s
web-1 0/1 Pending 0 0s
web-1 0/1 Pending 0 0s
web-1 0/1 ContainerCreating 0 0s
web-1 1/1 Running 0 34s
使用 kubectl exec 和 kubectl run 查看 Pod 的主机名和集群内部的 DNS 表项。
首先，查看 Pod 的主机名：
for i in 0 1; do kubectl exec web-$i -- sh -c 'hostname'; done
web-0
web-1
然后，运行：
kubectl run -i --tty --image busybox:1.28 dns-test --restart=Never --rm
这将启动一个新的 Shell。在新 Shell 中，运行：
# 在 dns-test 容器 Shell 中运行以下命令
nslookup web-0.nginx
输出类似于：
Server: 10.0.0.10
Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local
Name: web-0.nginx
Address 1: 10.244.1.7
nslookup web-1.nginx
Server: 10.0.0.10
Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local
Name: web-1.nginx
Address 1: 10.244.2.8
（现在可以退出容器 Shell：exit）
Pod 的序号、主机名、SRV 条目和记录名称没有改变，但和 Pod 相关联的 IP 地址可能发生了改变。 在本教程中使用的集群中它们就改变了。这就是为什么不要在其他应用中使用 StatefulSet 中 Pod 的 IP 地址进行连接，这点很重要。
如果你需要查找并连接一个 StatefulSet 的活动成员，你应该查询 Headless Service 的 CNAME。 和 CNAME 相关联的 SRV 记录只会包含 StatefulSet 中处于 Running 和 Ready 状态的 Pod。
如果你的应用已经实现了用于测试是否已存活（liveness）并就绪（readiness）的连接逻辑，
你可以使用 Pod 的 SRV 记录（web-0.nginx.default.svc.cluster.local、
web-1.nginx.default.svc.cluster.local）。因为它们是稳定的，并且当你的
Pod 的状态变为 Running 和 Ready 时，你的应用就能够发现它们的地址。
获取 web-0 和 web-1 的 PersistentVolumeClaims：
kubectl get pvc -l app=nginx
输出类似于：
NAME STATUS VOLUME CAPACITY ACCESSMODES AGE
www-web-0 Bound pvc-15c268c7-b507-11e6-932f-42010a800002 1Gi RWO 48s
www-web-1 Bound pvc-15c79307-b507-11e6-932f-42010a800002 1Gi RWO 48s
StatefulSet 控制器创建了两个 PersistentVolumeClaims， 绑定到两个 PersistentVolumes。
由于本教程使用的集群配置为动态制备 PersistentVolume 卷，所有的 PersistentVolume 卷都是自动创建和绑定的。
NginX Web 服务器默认会加载位于 /usr/share/nginx/html/index.html 的 index 文件。
StatefulSet spec 中的 volumeMounts 字段保证了 /usr/share/nginx/html
文件夹由一个 PersistentVolume 卷支持。
将 Pod 的主机名写入它们的 index.html 文件并验证 NginX Web 服务器使用该主机名提供服务：
for i in 0 1; do kubectl exec "web-$i" -- sh -c 'echo "$(hostname)" > /usr/share/nginx/html/index.html'; done
for i in 0 1; do kubectl exec -i -t "web-$i" -- curl http://localhost/; done
web-0
web-1
请注意，如果你看见上面的 curl 命令返回了 403 Forbidden 的响应，你需要像这样修复使用 volumeMounts
（原因归咎于使用 hostPath 卷时存在的缺陷）
挂载的目录的权限，先运行：
for i in 0 1; do kubectl exec web-$i -- chmod 755 /usr/share/nginx/html; done
再重新尝试上面的 curl 命令。
在一个终端监视 StatefulSet 的 Pod：
kubectl get pod -w -l app=nginx
在另一个终端删除 StatefulSet 所有的 Pod：
kubectl delete pod -l app=nginx
pod "web-0" deleted
pod "web-1" deleted
在第一个终端里检查 kubectl get 命令的输出，等待所有 Pod 变成 Running 和 Ready 状态。
kubectl get pod -w -l app=nginx
NAME READY STATUS RESTARTS AGE
web-0 0/1 ContainerCreating 0 0s
NAME READY STATUS RESTARTS AGE
web-0 1/1 Running 0 2s
web-1 0/1 Pending 0 0s
web-1 0/1 Pending 0 0s
web-1 0/1 ContainerCreating 0 0s
web-1 1/1 Running 0 34s
验证所有 Web 服务器在继续使用它们的主机名提供服务：
for i in 0 1; do kubectl exec -i -t "web-$i" -- curl http://localhost/; done
web-0
web-1
虽然 web-0 和 web-1 被重新调度了，但它们仍然继续监听各自的主机名，因为和它们的
PersistentVolumeClaim 相关联的 PersistentVolume 卷被重新挂载到了各自的 volumeMount 上。
不管 web-0 和 web-1 被调度到了哪个节点上，它们的 PersistentVolume 卷将会被挂载到合适的挂载点上。
扩容/缩容 StatefulSet 指增加或减少它的副本数。这通过更新 replicas 字段完成。
你可以使用 kubectl scale
或者 kubectl patch 来扩容/缩容一个 StatefulSet。
在一个终端窗口监视 StatefulSet 的 Pod：
kubectl get pods -w -l app=nginx
在另一个终端窗口使用 kubectl scale 扩展副本数为 5：
kubectl scale sts web --replicas=5
statefulset.apps/web scaled
在第一个 终端中检查 kubectl get 命令的输出，等待增加的 3 个 Pod 的状态变为 Running 和 Ready。
kubectl get pods -w -l app=nginx
NAME READY STATUS RESTARTS AGE
web-0 1/1 Running 0 2h
web-1 1/1 Running 0 2h
NAME READY STATUS RESTARTS AGE
web-2 0/1 Pending 0 0s
web-2 0/1 Pending 0 0s
web-2 0/1 ContainerCreating 0 0s
web-2 1/1 Running 0 19s
web-3 0/1 Pending 0 0s
web-3 0/1 Pending 0 0s
web-3 0/1 ContainerCreating 0 0s
web-3 1/1 Running 0 18s
web-4 0/1 Pending 0 0s
web-4 0/1 Pending 0 0s
web-4 0/1 ContainerCreating 0 0s
web-4 1/1 Running 0 19s
StatefulSet 控制器扩展了副本的数量。 如同创建 StatefulSet 所述，StatefulSet 按序号索引顺序创建各个 Pod，并且会等待前一个 Pod 变为 Running 和 Ready 才会启动下一个 Pod。
在一个终端监视 StatefulSet 的 Pod：
kubectl get pods -w -l app=nginx
在另一个终端使用 kubectl patch 将 StatefulSet 缩容回三个副本：
kubectl patch sts web -p '{"spec":{"replicas":3}}'
statefulset.apps/web patched
等待 web-4 和 web-3 状态变为 Terminating。
kubectl get pods -w -l app=nginx
NAME READY STATUS RESTARTS AGE
web-0 1/1 Running 0 3h
web-1 1/1 Running 0 3h
web-2 1/1 Running 0 55s
web-3 1/1 Running 0 36s
web-4 0/1 ContainerCreating 0 18s
NAME READY STATUS RESTARTS AGE
web-4 1/1 Running 0 19s
web-4 1/1 Terminating 0 24s
web-4 1/1 Terminating 0 24s
web-3 1/1 Terminating 0 42s
web-3 1/1 Terminating 0 42s
控制器会按照与 Pod 序号索引相反的顺序每次删除一个 Pod。在删除下一个 Pod 前会等待上一个被完全关闭。
获取 StatefulSet 的 PersistentVolumeClaims：
kubectl get pvc -l app=nginx
NAME STATUS VOLUME CAPACITY ACCESSMODES AGE
www-web-0 Bound pvc-15c268c7-b507-11e6-932f-42010a800002 1Gi RWO 13h
www-web-1 Bound pvc-15c79307-b507-11e6-932f-42010a800002 1Gi RWO 13h
www-web-2 Bound pvc-e1125b27-b508-11e6-932f-42010a800002 1Gi RWO 13h
www-web-3 Bound pvc-e1176df6-b508-11e6-932f-42010a800002 1Gi RWO 13h
www-web-4 Bound pvc-e11bb5f8-b508-11e6-932f-42010a800002 1Gi RWO 13h
五个 PersistentVolumeClaims 和五个 PersistentVolume 卷仍然存在。 查看 Pod 的稳定存储，我们发现当删除 StatefulSet 的 Pod 时，挂载到 StatefulSet 的 Pod 的 PersistentVolume 卷不会被删除。 当这种删除行为是由 StatefulSet 缩容引起时也是一样的。
从 Kubernetes 1.7 版本开始，StatefulSet 控制器支持自动更新。
更新策略由 StatefulSet API 对象的 spec.updateStrategy 字段决定。这个特性能够用来更新一个
StatefulSet 中 Pod 的的容器镜像、资源请求和限制、标签和注解。
RollingUpdate 更新策略是 StatefulSet 默认策略。
RollingUpdate 更新策略会更新一个 StatefulSet 中的所有
Pod，采用与序号索引相反的顺序并遵循 StatefulSet 的保证。
对 web StatefulSet 应用 Patch 操作来应用 RollingUpdate 更新策略：
kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate"}}}'
statefulset.apps/web patched
在一个终端窗口中对 web StatefulSet 执行 patch 操作来再次改变容器镜像：
kubectl patch statefulset web --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"gcr.io/google_containers/nginx-slim:0.8"}]'
statefulset.apps/web patched
在另一个终端监控 StatefulSet 中的 Pod：
kubectl get pod -l app=nginx -w
输出类似于：
NAME READY STATUS RESTARTS AGE
web-0 1/1 Running 0 7m
web-1 1/1 Running 0 7m
web-2 1/1 Running 0 8m
web-2 1/1 Terminating 0 8m
web-2 1/1 Terminating 0 8m
web-2 0/1 Terminating 0 8m
web-2 0/1 Terminating 0 8m
web-2 0/1 Terminating 0 8m
web-2 0/1 Terminating 0 8m
web-2 0/1 Pending 0 0s
web-2 0/1 Pending 0 0s
web-2 0/1 ContainerCreating 0 0s
web-2 1/1 Running 0 19s
web-1 1/1 Terminating 0 8m
web-1 0/1 Terminating 0 8m
web-1 0/1 Terminating 0 8m
web-1 0/1 Terminating 0 8m
web-1 0/1 Pending 0 0s
web-1 0/1 Pending 0 0s
web-1 0/1 ContainerCreating 0 0s
web-1 1/1 Running 0 6s
web-0 1/1 Terminating 0 7m
web-0 1/1 Terminating 0 7m
web-0 0/1 Terminating 0 7m
web-0 0/1 Terminating 0 7m
web-0 0/1 Terminating 0 7m
web-0 0/1 Terminating 0 7m
web-0 0/1 Pending 0 0s
web-0 0/1 Pending 0 0s
web-0 0/1 ContainerCreating 0 0s
web-0 1/1 Running 0 10s
StatefulSet 里的 Pod 采用和序号相反的顺序更新。在更新下一个 Pod 前，StatefulSet 控制器终止每个 Pod 并等待它们变成 Running 和 Ready。 请注意，虽然在顺序后继者变成 Running 和 Ready 之前 StatefulSet 控制器不会更新下一个 Pod，但它仍然会重建任何在更新过程中发生故障的 Pod，使用的是它们当前的版本。
已经接收到更新请求的 Pod 将会被恢复为更新的版本，没有收到请求的 Pod 则会被恢复为之前的版本。 像这样，控制器尝试继续使应用保持健康并在出现间歇性故障时保持更新的一致性。
获取 Pod 来查看它们的容器镜像：
for p in 0 1 2; do kubectl get pod "web-$p" --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'; echo; done
registry.k8s.io/nginx-slim:0.8
registry.k8s.io/nginx-slim:0.8
registry.k8s.io/nginx-slim:0.8
StatefulSet 中的所有 Pod 现在都在运行之前的容器镜像。
你还可以使用 kubectl rollout status sts/<名称> 来查看
StatefulSet 的滚动更新状态。
你可以使用 RollingUpdate 更新策略的 partition 参数来分段更新一个 StatefulSet。
分段的更新将会使 StatefulSet 中的其余所有 Pod 保持当前版本的同时允许改变
StatefulSet 的 .spec.template。
对 web StatefulSet 执行 Patch 操作为 updateStrategy 字段添加一个分区：
kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate","rollingUpdate":{"partition":3}}}}'
statefulset.apps/web patched
再次 Patch StatefulSet 来改变容器镜像：
kubectl patch statefulset web --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"registry.k8s.io/nginx-slim:0.7"}]'
statefulset.apps/web patched
删除 StatefulSet 中的 Pod：
kubectl delete pod web-2
pod "web-2" deleted
等待 Pod 变成 Running 和 Ready。
kubectl get pod -l app=nginx -w
NAME READY STATUS RESTARTS AGE
web-0 1/1 Running 0 4m
web-1 1/1 Running 0 4m
web-2 0/1 ContainerCreating 0 11s
web-2 1/1 Running 0 18s
获取 Pod 的容器镜像：
kubectl get pod web-2 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'
registry.k8s.io/nginx-slim:0.8
请注意，虽然更新策略是 RollingUpdate，StatefulSet 还是会使用原始的容器恢复 Pod。
这是因为 Pod 的序号比 updateStrategy 指定的 partition 更小。
你可以通过减少上文指定的
partition 来进行金丝雀发布，以此来测试你的程序的改动。
通过 patch 命令修改 StatefulSet 来减少分区：
kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate","rollingUpdate":{"partition":2}}}}'
statefulset.apps/web patched
等待 web-2 变成 Running 和 Ready。
kubectl get pod -l app=nginx -w
NAME READY STATUS RESTARTS AGE
web-0 1/1 Running 0 4m
web-1 1/1 Running 0 4m
web-2 0/1 ContainerCreating 0 11s
web-2 1/1 Running 0 18s
获取 Pod 的容器：
kubectl get pod web-2 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'
registry.k8s.io/nginx-slim:0.7
当你改变 partition 时，StatefulSet 会自动更新 web-2
Pod，这是因为 Pod 的序号大于或等于 partition。
删除 web-1 Pod：
kubectl delete pod web-1
pod "web-1" deleted
等待 web-1 变成 Running 和 Ready。
kubectl get pod -l app=nginx -w
输出类似于：
NAME READY STATUS RESTARTS AGE
web-0 1/1 Running 0 6m
web-1 0/1 Terminating 0 6m
web-2 1/1 Running 0 2m
web-1 0/1 Terminating 0 6m
web-1 0/1 Terminating 0 6m
web-1 0/1 Terminating 0 6m
web-1 0/1 Pending 0 0s
web-1 0/1 Pending 0 0s
web-1 0/1 ContainerCreating 0 0s
web-1 1/1 Running 0 18s
获取 web-1 Pod 的容器镜像：
kubectl get pod web-1 --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'
registry.k8s.io/nginx-slim:0.8
web-1 被按照原来的配置恢复，因为 Pod 的序号小于分区。当指定了分区时，如果更新了
StatefulSet 的 .spec.template，则所有序号大于或等于分区的 Pod 都将被更新。
如果一个序号小于分区的 Pod 被删除或者终止，它将被按照原来的配置恢复。
你可以使用类似金丝雀发布的方法执行一次分阶段的发布
（例如一次线性的、等比的或者指数形式的发布）。
要执行一次分阶段的发布，你需要设置 partition 为希望控制器暂停更新的序号。
分区当前为 2。请将分区设置为 0：
kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate","rollingUpdate":{"partition":0}}}}'
statefulset.apps/web patched
等待 StatefulSet 中的所有 Pod 变成 Running 和 Ready。
kubectl get pod -l app=nginx -w
输出类似于：
NAME READY STATUS RESTARTS AGE
web-0 1/1 Running 0 3m
web-1 0/1 ContainerCreating 0 11s
web-2 1/1 Running 0 2m
web-1 1/1 Running 0 18s
web-0 1/1 Terminating 0 3m
web-0 1/1 Terminating 0 3m
web-0 0/1 Terminating 0 3m
web-0 0/1 Terminating 0 3m
web-0 0/1 Terminating 0 3m
web-0 0/1 Terminating 0 3m
web-0 0/1 Pending 0 0s
web-0 0/1 Pending 0 0s
web-0 0/1 ContainerCreating 0 0s
web-0 1/1 Running 0 3s
获取 StatefulSet 中 Pod 的容器镜像详细信息：
for p in 0 1 2; do kubectl get pod "web-$p" --template '{{range $i, $c := .spec.containers}}{{$c.image}}{{end}}'; echo; done
registry.k8s.io/nginx-slim:0.7
registry.k8s.io/nginx-slim:0.7
registry.k8s.io/nginx-slim:0.7
将 partition 改变为 0 以允许 StatefulSet 继续更新过程。
OnDelete 更新策略实现了传统（1.7 之前）行为，它也是默认的更新策略。
当你选择这个更新策略并修改 StatefulSet 的 .spec.template 字段时，StatefulSet 控制器将不会自动更新 Pod。
StatefulSet 同时支持级联和非级联删除。使用非级联方式删除 StatefulSet 时，StatefulSet 的 Pod 不会被删除。使用级联删除时，StatefulSet 和它的 Pod 都会被删除。
在一个终端窗口监视 StatefulSet 中的 Pod。
kubectl get pods -w -l app=nginx
使用 kubectl delete
删除 StatefulSet。请确保提供了 --cascade=orphan 参数给命令。这个参数告诉
Kubernetes 只删除 StatefulSet 而不要删除它的任何 Pod。
kubectl delete statefulset web --cascade=orphan
statefulset.apps "web" deleted
获取 Pod 来检查它们的状态：
kubectl get pods -l app=nginx
NAME READY STATUS RESTARTS AGE
web-0 1/1 Running 0 6m
web-1 1/1 Running 0 7m
web-2 1/1 Running 0 5m
虽然 web 已经被删除了，但所有 Pod 仍然处于 Running 和 Ready 状态。
删除 web-0：
kubectl delete pod web-0
pod "web-0" deleted
获取 StatefulSet 的 Pod：
kubectl get pods -l app=nginx
NAME READY STATUS RESTARTS AGE
web-1 1/1 Running 0 10m
web-2 1/1 Running 0 7m
由于 web StatefulSet 已经被删除，web-0 没有被重新启动。
在一个终端监控 StatefulSet 的 Pod。
kubectl get pods -w -l app=nginx
在另一个终端里重新创建 StatefulSet。请注意，除非你删除了 nginx
Service（你不应该这样做），你将会看到一个错误，提示 Service 已经存在。
kubectl apply -f web.yaml
statefulset.apps/web created
service/nginx unchanged
请忽略这个错误。它仅表示 kubernetes 进行了一次创建 nginx headless Service 的尝试，尽管那个 Service 已经存在。
在第一个终端中运行并检查 kubectl get 命令的输出。
kubectl get pods -w -l app=nginx
NAME READY STATUS RESTARTS AGE
web-1 1/1 Running 0 16m
web-2 1/1 Running 0 2m
NAME READY STATUS RESTARTS AGE
web-0 0/1 Pending 0 0s
web-0 0/1 Pending 0 0s
web-0 0/1 ContainerCreating 0 0s
web-0 1/1 Running 0 18s
web-2 1/1 Terminating 0 3m
web-2 0/1 Terminating 0 3m
web-2 0/1 Terminating 0 3m
web-2 0/1 Terminating 0 3m
当重新创建 web StatefulSet 时，web-0 被第一个重新启动。
由于 web-1 已经处于 Running 和 Ready 状态，当 web-0 变成 Running 和 Ready 时，
StatefulSet 会接收这个 Pod。由于你重新创建的 StatefulSet 的 replicas 等于 2，
一旦 web-0 被重新创建并且 web-1 被认为已经处于 Running 和 Ready 状态时，web-2 将会被终止。
让我们再看看被 Pod 的 Web 服务器加载的 index.html 的内容：
for i in 0 1; do kubectl exec -i -t "web-$i" -- curl http://localhost/; done
web-0
web-1
尽管你同时删除了 StatefulSet 和 web-0 Pod，但它仍然使用最初写入 index.html 文件的主机名进行服务。
这是因为 StatefulSet 永远不会删除和一个 Pod 相关联的 PersistentVolume 卷。
当你重建这个 StatefulSet 并且重新启动了 web-0 时，它原本的 PersistentVolume 卷会被重新挂载。
在一个终端窗口监视 StatefulSet 里的 Pod。
kubectl get pods -w -l app=nginx
在另一个窗口中再次删除这个 StatefulSet。这次省略 --cascade=orphan 参数。
kubectl delete statefulset web
statefulset.apps "web" deleted
在第一个终端检查 kubectl get 命令的输出，并等待所有的 Pod 变成 Terminating 状态。
kubectl get pods -w -l app=nginx
NAME READY STATUS RESTARTS AGE
web-0 1/1 Running 0 11m
web-1 1/1 Running 0 27m
NAME READY STATUS RESTARTS AGE
web-0 1/1 Terminating 0 12m
web-1 1/1 Terminating 0 29m
web-0 0/1 Terminating 0 12m
web-0 0/1 Terminating 0 12m
web-0 0/1 Terminating 0 12m
web-1 0/1 Terminating 0 29m
web-1 0/1 Terminating 0 29m
web-1 0/1 Terminating 0 29m
如同你在缩容章节看到的，这些 Pod 按照与其序号索引相反的顺序每次终止一个。 在终止一个 Pod 前，StatefulSet 控制器会等待 Pod 后继者被完全终止。
尽管级联删除会删除 StatefulSet 及其 Pod，但级联不会删除与 StatefulSet
关联的 Headless Service。你必须手动删除 nginx Service。
kubectl delete service nginx
service "nginx" deleted
再一次重新创建 StatefulSet 和 headless Service：
kubectl apply -f web.yaml
service/nginx created
statefulset.apps/web created
当 StatefulSet 所有的 Pod 变成 Running 和 Ready 时，获取它们的 index.html 文件的内容：
for i in 0 1; do kubectl exec -i -t "web-$i" -- curl http://localhost/; done
web-0
web-1
即使你已经删除了 StatefulSet 和它的全部 Pod，这些 Pod 将会被重新创建并挂载它们的
PersistentVolume 卷，并且 web-0 和 web-1 将继续使用它的主机名提供服务。
最后删除 nginx service
kubectl delete service nginx
service "nginx" deleted
并且删除 web StatefulSet:
kubectl delete statefulset web
statefulset "web" deleted
对于某些分布式系统来说，StatefulSet 的顺序性保证是不必要和/或者不应该的。
这些系统仅仅要求唯一性和身份标志。为了解决这个问题，在 Kubernetes 1.7 中
我们针对 StatefulSet API 对象引入了 .spec.podManagementPolicy。
此选项仅影响扩缩操作的行为。更新不受影响。
OrderedReady Pod 管理策略是 StatefulSet 的默认选项。它告诉
StatefulSet 控制器遵循上文展示的顺序性保证。
Parallel Pod 管理策略告诉 StatefulSet 控制器并行的终止所有 Pod，
在启动或终止另一个 Pod 前，不必等待这些 Pod 变成 Running 和 Ready 或者完全终止状态。
apiVersion: v1
kind: Service
metadata:
name: nginx
labels:
app: nginx
spec:
ports:
- port: 80
name: web
clusterIP: None
selector:
app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: web
spec:
serviceName: "nginx"
podManagementPolicy: "Parallel"
replicas: 2
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: registry.k8s.io/nginx-slim:0.8
ports:
- containerPort: 80
name: web
volumeMounts:
- name: www
mountPath: /usr/share/nginx/html
volumeClaimTemplates:
- metadata:
name: www
spec:
accessModes: [ "ReadWriteOnce" ]
resources:
requests:
storage: 1Gi
下载上面的例子并保存为 web-parallel.yaml。
这份清单和你在上文下载的完全一样，只是 web StatefulSet 的
.spec.podManagementPolicy 设置成了 Parallel。
在一个终端窗口监视 StatefulSet 中的 Pod。
kubectl get pod -l app=nginx -w
在另一个终端窗口创建清单中的 StatefulSet 和 Service：
kubectl apply -f web-parallel.yaml
service/nginx created
statefulset.apps/web created
查看你在第一个终端中运行的 kubectl get 命令的输出。
kubectl get pod -l app=nginx -w
NAME READY STATUS RESTARTS AGE
web-0 0/1 Pending 0 0s
web-0 0/1 Pending 0 0s
web-1 0/1 Pending 0 0s
web-1 0/1 Pending 0 0s
web-0 0/1 ContainerCreating 0 0s
web-1 0/1 ContainerCreating 0 0s
web-0 1/1 Running 0 10s
web-1 1/1 Running 0 10s
StatefulSet 控制器同时启动了 web-0 和 web-1。
保持第二个终端打开，并在另一个终端窗口中扩容 StatefulSet：
kubectl scale statefulset/web --replicas=4
statefulset.apps/web scaled
在 kubectl get 命令运行的终端里检查它的输出。
web-3 0/1 Pending 0 0s
web-3 0/1 Pending 0 0s
web-3 0/1 Pending 0 7s
web-3 0/1 ContainerCreating 0 7s
web-2 1/1 Running 0 10s
web-3 1/1 Running 0 26s
StatefulSet 启动了两个新的 Pod，而且在启动第二个之前并没有等待第一个变成 Running 和 Ready 状态。
你应该打开两个终端，准备在清理过程中运行 kubectl 命令。
kubectl delete sts web
# sts is an abbreviation for statefulset
你可以监视 kubectl get 来查看那些 Pod 被删除
kubectl get pod -l app=nginx -w
web-3 1/1 Terminating 0 9m
web-2 1/1 Terminating 0 9m
web-3 1/1 Terminating 0 9m
web-2 1/1 Terminating 0 9m
web-1 1/1 Terminating 0 44m
web-0 1/1 Terminating 0 44m
web-0 0/1 Terminating 0 44m
web-3 0/1 Terminating 0 9m
web-2 0/1 Terminating 0 9m
web-1 0/1 Terminating 0 44m
web-0 0/1 Terminating 0 44m
web-2 0/1 Terminating 0 9m
web-2 0/1 Terminating 0 9m
web-2 0/1 Terminating 0 9m
web-1 0/1 Terminating 0 44m
web-1 0/1 Terminating 0 44m
web-1 0/1 Terminating 0 44m
web-0 0/1 Terminating 0 44m
web-0 0/1 Terminating 0 44m
web-0 0/1 Terminating 0 44m
web-3 0/1 Terminating 0 9m
web-3 0/1 Terminating 0 9m
web-3 0/1 Terminating 0 9m
在删除过程中，StatefulSet 将并发的删除所有 Pod，在删除一个 Pod 前不会等待它的顺序后继者终止。
关闭 kubectl get 命令运行的终端并删除 nginx Service：
kubectl delete svc nginx
删除本教程中用到的 PersistentVolume 卷的持久化存储介质。
kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
www-web-0 Bound pvc-2bf00408-d366-4a12-bad0-1869c65d0bee 1Gi RWO standard 25m
www-web-1 Bound pvc-ba3bfe9c-413e-4b95-a2c0-3ea8a54dbab4 1Gi RWO standard 24m
www-web-2 Bound pvc-cba6cfa6-3a47-486b-a138-db5930207eaf 1Gi RWO standard 15m
www-web-3 Bound pvc-0c04d7f0-787a-4977-8da3-d9d3a6d8d752 1Gi RWO standard 15m
www-web-4 Bound pvc-b2c73489-e70b-4a4e-9ec1-9eab439aa43e 1Gi RWO standard 14m
kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pvc-0c04d7f0-787a-4977-8da3-d9d3a6d8d752 1Gi RWO Delete Bound default/www-web-3 standard 15m
pvc-2bf00408-d366-4a12-bad0-1869c65d0bee 1Gi RWO Delete Bound default/www-web-0 standard 25m
pvc-b2c73489-e70b-4a4e-9ec1-9eab439aa43e 1Gi RWO Delete Bound default/www-web-4 standard 14m
pvc-ba3bfe9c-413e-4b95-a2c0-3ea8a54dbab4 1Gi RWO Delete Bound default/www-web-1 standard 24m
pvc-cba6cfa6-3a47-486b-a138-db5930207eaf 1Gi RWO Delete Bound default/www-web-2 standard 15m
kubectl delete pvc www-web-0 www-web-1 www-web-2 www-web-3 www-web-4
persistentvolumeclaim "www-web-0" deleted
persistentvolumeclaim "www-web-1" deleted
persistentvolumeclaim "www-web-2" deleted
persistentvolumeclaim "www-web-3" deleted
persistentvolumeclaim "www-web-4" deleted
kubectl get pvc
No resources found in default namespace.
你需要删除本教程中用到的 PersistentVolume 卷的持久化存储介质。
基于你的环境、存储配置和制备方式，按照必需的步骤保证回收所有的存储。
本示例描述了如何通过 Minikube 在 Kubernetes 上安装 WordPress 和 MySQL。 这两个应用都使用 PersistentVolumes 和 PersistentVolumeClaims 保存数据。
PersistentVolume（PV）是在集群里由管理员手动制备或 Kubernetes 通过 StorageClass 动态制备的一块存储。 PersistentVolumeClaim 是用户对存储的请求，该请求可由某个 PV 来满足。 PersistentVolumes 和 PersistentVolumeClaims 独立于 Pod 生命周期而存在， 在 Pod 重启、重新调度甚至删除过程中用于保存数据。
这种部署并不适合生产场景，因为它使用的是单实例 WordPress 和 MySQL Pod。 在生产场景中，请考虑使用 WordPress Helm Chart 部署 WordPress。
本教程中提供的文件使用 GA Deployment API，并且特定于 kubernetes 1.9 或更高版本。 如果你希望将本教程与 Kubernetes 的早期版本一起使用，请相应地更新 API 版本，或参考本教程的早期版本。
kustomization.yaml 以使用kubectl apply -k ./ 来应用整个 kustomization 目录你必须拥有一个 Kubernetes 的集群，同时你的 Kubernetes 集群必须带有 kubectl 命令行工具。 建议在至少有两个节点的集群上运行本教程，且这些节点不作为控制平面主机。 如果你还没有集群，你可以通过 Minikube 构建一个你自己的集群，或者你可以使用下面任意一个 Kubernetes 工具构建：
要获知版本信息，请输入kubectl version.此例在 kubectl 1.14 或者更高版本有效。
下载下面的配置文件：
MySQL 和 Wordpress 都需要一个 PersistentVolume 来存储数据。 它们的 PersistentVolumeClaims 将在部署步骤中创建。
许多集群环境都安装了默认的 StorageClass。如果在 PersistentVolumeClaim 中未指定 StorageClass， 则使用集群的默认 StorageClass。
创建 PersistentVolumeClaim 时，将根据 StorageClass 配置动态制备一个 PersistentVolume。
在本地集群中，默认的 StorageClass 使用 hostPath 制备程序。hostPath 卷仅适用于开发和测试。
使用 hostPath 卷时，你的数据位于 Pod 调度到的节点上的 /tmp 中，并且不会在节点之间移动。
如果 Pod 死亡并被调度到集群中的另一个节点，或者该节点重新启动，则数据将丢失。
如果要建立需要使用 hostPath 制备程序的集群，
则必须在 controller-manager 组件中设置 --enable-hostpath-provisioner 标志。
如果你已经有运行在 Google Kubernetes Engine 的集群， 请参考此指南。
Secret 是存储诸如密码或密钥之类敏感数据的对象。
从 1.14 开始，kubectl 支持使用一个 kustomization 文件来管理 Kubernetes 对象。
你可以通过 kustomization.yaml 中的生成器创建一个 Secret。
通过以下命令在 kustomization.yaml 中添加一个 Secret 生成器。
你需要将 YOUR_PASSWORD 替换为自己要用的密码。
cat <<EOF >./kustomization.yaml
secretGenerator:
- name: mysql-pass
literals:
- password=YOUR_PASSWORD
EOF
以下清单文件描述的是一个单实例的 MySQL Deployment。MySQL 容器将 PersistentVolume 挂载在 /var/lib/mysql。
MYSQL_ROOT_PASSWORD 环境变量根据 Secret 设置数据库密码。
apiVersion: v1
kind: Service
metadata:
name: wordpress-mysql
labels:
app: wordpress
spec:
ports:
- port: 3306
selector:
app: wordpress
tier: mysql
clusterIP: None
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: mysql-pv-claim
labels:
app: wordpress
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 20Gi
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: wordpress-mysql
labels:
app: wordpress
spec:
selector:
matchLabels:
app: wordpress
tier: mysql
strategy:
type: Recreate
template:
metadata:
labels:
app: wordpress
tier: mysql
spec:
containers:
- image: mysql:5.6
name: mysql
env:
- name: MYSQL_ROOT_PASSWORD
valueFrom:
secretKeyRef:
name: mysql-pass
key: password
ports:
- containerPort: 3306
name: mysql
volumeMounts:
- name: mysql-persistent-storage
mountPath: /var/lib/mysql
volumes:
- name: mysql-persistent-storage
persistentVolumeClaim:
claimName: mysql-pv-claim
以下清单文件描述的是一个单实例 WordPress Deployment。WordPress 容器将 PersistentVolume
挂载到 /var/www/html，用于保存网站数据文件。
WORDPRESS_DB_HOST 环境变量设置上面定义的 MySQL Service 的名称，WordPress 将通过 Service 访问数据库。
WORDPRESS_DB_PASSWORD 环境变量根据使用 kustomize 生成的 Secret 设置数据库密码。
apiVersion: v1
kind: Service
metadata:
name: wordpress
labels:
app: wordpress
spec:
ports:
- port: 80
selector:
app: wordpress
tier: frontend
type: LoadBalancer
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: wp-pv-claim
labels:
app: wordpress
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 20Gi
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: wordpress
labels:
app: wordpress
spec:
selector:
matchLabels:
app: wordpress
tier: frontend
strategy:
type: Recreate
template:
metadata:
labels:
app: wordpress
tier: frontend
spec:
containers:
- image: wordpress:4.8-apache
name: wordpress
env:
- name: WORDPRESS_DB_HOST
value: wordpress-mysql
- name: WORDPRESS_DB_PASSWORD
valueFrom:
secretKeyRef:
name: mysql-pass
key: password
ports:
- containerPort: 80
name: wordpress
volumeMounts:
- name: wordpress-persistent-storage
mountPath: /var/www/html
volumes:
- name: wordpress-persistent-storage
persistentVolumeClaim:
claimName: wp-pv-claim
下载 MySQL Deployment 配置文件。
curl -LO https://k8s.io/examples/application/wordpress/mysql-deployment.yaml
下载 WordPress 配置文件。
curl -LO https://k8s.io/examples/application/wordpress/wordpress-deployment.yaml
将上述内容追加到 kustomization.yaml 文件。
cat <<EOF >>./kustomization.yaml
resources:
- mysql-deployment.yaml
- wordpress-deployment.yaml
EOF
kustomization.yaml 包含用于部署 WordPress 网站以及 MySQL 数据库的所有资源。你可以通过以下方式应用目录：
kubectl apply -k ./
现在，你可以验证所有对象是否存在。
通过运行以下命令验证 Secret 是否存在：
kubectl get secrets
响应应如下所示：
NAME TYPE DATA AGE
mysql-pass-c57bb4t7mf Opaque 1 9s
验证是否已动态制备 PersistentVolume：
kubectl get pvc
制备和绑定 PV 可能要花费几分钟。
响应应如下所示：
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
mysql-pv-claim Bound pvc-8cbd7b2e-4044-11e9-b2bb-42010a800002 20Gi RWO standard 77s
wp-pv-claim Bound pvc-8cd0df54-4044-11e9-b2bb-42010a800002 20Gi RWO standard 77s
通过运行以下命令来验证 Pod 是否正在运行：
kubectl get pods
等待 Pod 状态变成 RUNNING 可能会花费几分钟。
响应应如下所示：
NAME READY STATUS RESTARTS AGE
wordpress-mysql-1894417608-x5dzt 1/1 Running 0 40s
通过运行以下命令来验证 Service 是否正在运行：
kubectl get services wordpress
响应应如下所示：
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
wordpress LoadBalancer 10.0.0.89 <pending> 80:32406/TCP 4m
Minikube 只能通过 NodePort 公开服务。EXTERNAL-IP 始终处于 pending 状态。
运行以下命令以获取 WordPress 服务的 IP 地址：
minikube service wordpress --url
响应应如下所示：
http://1.2.3.4:32406
复制 IP 地址，然后将页面加载到浏览器中来查看你的站点。
你应该看到类似于以下屏幕截图的 WordPress 设置页面。
不要在此页面上保留 WordPress 安装。如果其他用户找到了它，他们可以在你的实例上建立一个网站并使用它来提供恶意内容。
通过创建用户名和密码来安装 WordPress 或删除你的实例。
运行以下命令删除你的 Secret、Deployment、Service 和 PersistentVolumeClaims：
kubectl delete -k ./
本教程描述了如何在 Kubernetes 上运行 Apache Cassandra。 数据库 Cassandra 需要永久性存储提供数据持久性（应用状态）。 在此示例中，自定义 Cassandra seed provider 使数据库在接入 Cassandra 集群时能够发现新的 Cassandra 实例。
使用StatefulSet可以更轻松地将有状态的应用程序部署到你的 Kubernetes 集群中。 有关本教程中使用的功能的更多信息， 请参阅 StatefulSet。
Cassandra 和 Kubernetes 都使用术语节点来表示集群的成员。 在本教程中，属于 StatefulSet 的 Pod 是 Cassandra 节点，并且是 Cassandra 集群的成员（称为 ring）。 当这些 Pod 在你的 Kubernetes 集群中运行时，Kubernetes 控制平面会将这些 Pod 调度到 Kubernetes 的 节点上。
当 Cassandra 节点启动时，使用 seed 列表来引导发现 ring 中的其他节点。 本教程部署了一个自定义的 Cassandra seed provider， 使数据库可以发现 Kubernetes 集群中出现的新的 Cassandra Pod。
你必须拥有一个 Kubernetes 的集群，同时你的 Kubernetes 集群必须带有 kubectl 命令行工具。 建议在至少有两个节点的集群上运行本教程，且这些节点不作为控制平面主机。 如果你还没有集群，你可以通过 Minikube 构建一个你自己的集群，或者你可以使用下面任意一个 Kubernetes 工具构建：
要完成本教程，你应该已经熟悉 Pod、 Service 和 StatefulSet。
Minikube 默认需要 2048MB 内存和 2 个 CPU。 在本教程中，使用默认资源配置运行 Minikube 会出现资源不足的错误。为避免这些错误，请使用以下设置启动 Minikube：
minikube start --memory 5120 --cpus=4
在 Kubernetes 中，一个 Service 描述了一组执行相同任务的 Pod。
以下 Service 用于在 Cassandra Pod 和集群中的客户端之间进行 DNS 查找：
apiVersion: v1
kind: Service
metadata:
labels:
app: cassandra
name: cassandra
spec:
clusterIP: None
ports:
- port: 9042
selector:
app: cassandra
创建一个 Service 来跟踪 cassandra-service.yaml 文件中的所有 Cassandra StatefulSet：
kubectl apply -f https://k8s.io/examples/application/cassandra/cassandra-service.yaml
获取 Cassandra Service。
kubectl get svc cassandra
响应是：
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
cassandra ClusterIP None <none> 9042/TCP 45s
如果没有看到名为 cassandra 的服务，则表示创建失败。
请阅读调试服务，以解决常见问题。
下面包含的 StatefulSet 清单创建了一个由三个 Pod 组成的 Cassandra ring。
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: cassandra
labels:
app: cassandra
spec:
serviceName: cassandra
replicas: 3
selector:
matchLabels:
app: cassandra
template:
metadata:
labels:
app: cassandra
spec:
terminationGracePeriodSeconds: 1800
containers:
- name: cassandra
image: gcr.io/google-samples/cassandra:v13
imagePullPolicy: Always
ports:
- containerPort: 7000
name: intra-node
- containerPort: 7001
name: tls-intra-node
- containerPort: 7199
name: jmx
- containerPort: 9042
name: cql
resources:
limits:
cpu: "500m"
memory: 1Gi
requests:
cpu: "500m"
memory: 1Gi
securityContext:
capabilities:
add:
- IPC_LOCK
lifecycle:
preStop:
exec:
command:
- /bin/sh
- -c
- nodetool drain
env:
- name: MAX_HEAP_SIZE
value: 512M
- name: HEAP_NEWSIZE
value: 100M
- name: CASSANDRA_SEEDS
value: "cassandra-0.cassandra.default.svc.cluster.local"
- name: CASSANDRA_CLUSTER_NAME
value: "K8Demo"
- name: CASSANDRA_DC
value: "DC1-K8Demo"
- name: CASSANDRA_RACK
value: "Rack1-K8Demo"
- name: POD_IP
valueFrom:
fieldRef:
fieldPath: status.podIP
readinessProbe:
exec:
command:
- /bin/bash
- -c
- /ready-probe.sh
initialDelaySeconds: 15
timeoutSeconds: 5
# 这些卷挂载是持久的。它们类似内联申领，但并不完全相同，
# 因为这些卷挂载的名称需要与 StatefulSet 中某 Pod 卷完全匹配。
volumeMounts:
- name: cassandra-data
mountPath: /cassandra_data
# 这些将被控制器转换为卷申领，并挂载在上述路径。
# 请勿将此设置用于生产环境，除非使用了 GCEPersistentDisk 或其他 SSD 持久盘。
volumeClaimTemplates:
- metadata:
name: cassandra-data
spec:
accessModes: [ "ReadWriteOnce" ]
storageClassName: fast
resources:
requests:
storage: 1Gi
---
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
name: fast
provisioner: k8s.io/minikube-hostpath
parameters:
type: pd-ssd
使用 cassandra-statefulset.yaml 文件创建 Cassandra StatefulSet：
# 如果你能未经修改地应用 cassandra-statefulset.yaml，请使用此命令
kubectl apply -f https://k8s.io/examples/application/cassandra/cassandra-statefulset.yaml
如果你为了适合你的集群需要修改 cassandra-statefulset.yaml，
下载 https://k8s.io/examples/application/cassandra/cassandra-statefulset.yaml，
然后应用修改后的清单。
# 如果使用本地的 cassandra-statefulset.yaml ，请使用此命令
kubectl apply -f cassandra-statefulset.yaml
获取 Cassandra StatefulSet:
kubectl get statefulset cassandra
响应应该与此类似：
NAME DESIRED CURRENT AGE
cassandra 3 0 13s
StatefulSet 资源会按顺序部署 Pod。
获取 Pod 查看已排序的创建状态：
kubectl get pods -l="app=cassandra"
响应应该与此类似：
NAME READY STATUS RESTARTS AGE
cassandra-0 1/1 Running 0 1m
cassandra-1 0/1 ContainerCreating 0 8s
这三个 Pod 要花几分钟的时间才能部署。部署之后，相同的命令将返回类似于以下的输出：
NAME READY STATUS RESTARTS AGE
cassandra-0 1/1 Running 0 10m
cassandra-1 1/1 Running 0 9m
cassandra-2 1/1 Running 0 8m
运行第一个 Pod 中的 Cassandra nodetool， 以显示 ring 的状态。
kubectl exec -it cassandra-0 -- nodetool status
响应应该与此类似：
Datacenter: DC1-K8Demo
======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns (effective) Host ID Rack
UN 172.17.0.5 83.57 KiB 32 74.0% e2dd09e6-d9d3-477e-96c5-45094c08db0f Rack1-K8Demo
UN 172.17.0.4 101.04 KiB 32 58.8% f89d6835-3a42-4419-92b3-0e62cae1479c Rack1-K8Demo
UN 172.17.0.6 84.74 KiB 32 67.1% a6a1e8c2-3dc5-4417-b1a0-26507af2aaad Rack1-K8Demo
使用 kubectl edit 修改 Cassandra StatefulSet 的大小。
运行以下命令：
kubectl edit statefulset cassandra
此命令你的终端中打开一个编辑器。需要更改的是 replicas 字段。下面是 StatefulSet 文件的片段示例：
# 请编辑以下对象。以 '#' 开头的行将被忽略，
# 且空文件将放弃编辑。如果保存此文件时发生错误，
# 将重新打开并显示相关故障。
apiVersion: apps/v1
kind: StatefulSet
metadata:
creationTimestamp: 2016-08-13T18:40:58Z
generation: 1
labels:
app: cassandra
name: cassandra
namespace: default
resourceVersion: "323"
uid: 7a219483-6185-11e6-a910-42010a8a0fc0
spec:
replicas: 3
将副本数（replicas）更改为 4，然后保存清单。
StatefulSet 现在可以扩展到运行 4 个 Pod。
获取 Cassandra StatefulSet 验证更改：
kubectl get statefulset cassandra
响应应该与此类似：
NAME DESIRED CURRENT AGE
cassandra 4 4 36m
删除或缩小 StatefulSet 不会删除与 StatefulSet 关联的卷。 这个设置是出于安全考虑，因为你的数据比自动清除所有相关的 StatefulSet 资源更有价值。
根据存储类和回收策略，删除 PersistentVolumeClaims 可能导致关联的卷也被删除。 千万不要认为其容量声明被删除，你就能访问数据。
运行以下命令（连在一起成为一个单独的命令）删除 Cassandra StatefulSet 中的所有内容：
grace=$(kubectl get pod cassandra-0 -o=jsonpath='{.spec.terminationGracePeriodSeconds}') \
&& kubectl delete statefulset -l app=cassandra \
&& echo "Sleeping ${grace} seconds" 1>&2 \
&& sleep $grace \
&& kubectl delete persistentvolumeclaim -l app=cassandra
运行以下命令，删除你为 Cassandra 设置的 Service：
kubectl delete service -l app=cassandra
本教程中的 Pod 使用来自 Google 容器镜像库
的 gcr.io/google-samples/cassandra:v13
镜像。上面的 Docker 镜像基于 debian-base，
并且包含 OpenJDK 8。
该镜像包括来自 Apache Debian 存储库的标准 Cassandra 安装。
通过使用环境变量，你可以更改插入到 cassandra.yaml 中的值。
| 环境变量 | 默认值 |
|---|---|
CASSANDRA_CLUSTER_NAME | 'Test Cluster' |
CASSANDRA_NUM_TOKENS | 32 |
CASSANDRA_RPC_ADDRESS | 0.0.0.0 |
本教程展示了在 Kubernetes 上使用 StatefulSet、 PodDisruptionBudget 和 PodAntiAffinity 特性运行 Apache Zookeeper。
在开始本教程前，你应该熟悉以下 Kubernetes 概念。
你需要一个至少包含四个节点的集群，每个节点至少 2 个 CPU 和 4 GiB 内存。 在本教程中你将会隔离（Cordon）和腾空（Drain ）集群的节点。 这意味着集群节点上所有的 Pod 将会被终止并移除。这些节点也会暂时变为不可调度。 在本教程中你应该使用一个独占的集群，或者保证你造成的干扰不会影响其它租户。
本教程假设你的集群已配置为动态制备 PersistentVolume。 如果你的集群没有配置成这样，在开始本教程前，你需要手动准备三个 20 GiB 的卷。
在学习本教程后，你将熟悉下列内容。
Apache ZooKeeper 是一个分布式的开源协调服务，用于分布式系统。 ZooKeeper 允许你读取、写入数据和发现数据更新。 数据按层次结构组织在文件系统中，并复制到 ensemble（一个 ZooKeeper 服务器的集合） 中所有的 ZooKeeper 服务器。对数据的所有操作都是原子的和顺序一致的。 ZooKeeper 通过 Zab 一致性协议在 ensemble 的所有服务器之间复制一个状态机来确保这个特性。
Ensemble 使用 Zab 协议选举一个领导者，在选举出领导者前不能写入数据。 一旦选举出了领导者，ensemble 使用 Zab 保证所有写入被复制到一个 quorum， 然后这些写入操作才会被确认并对客户端可用。 如果没有遵照加权 quorums，一个 quorum 表示包含当前领导者的 ensemble 的多数成员。 例如，如果 ensemble 有 3 个服务器，一个包含领导者的成员和另一个服务器就组成了一个 quorum。 如果 ensemble 不能达成一个 quorum，数据将不能被写入。
ZooKeeper 在内存中保存它们的整个状态机，但是每个改变都被写入一个在存储介质上的持久 WAL（Write Ahead Log）。 当一个服务器出现故障时，它能够通过回放 WAL 恢复之前的状态。 为了防止 WAL 无限制的增长，ZooKeeper 服务器会定期的将内存状态快照保存到存储介质。 这些快照能够直接加载到内存中，所有在这个快照之前的 WAL 条目都可以被安全的丢弃。
下面的清单包含一个无头服务、 一个 Service、 一个 PodDisruptionBudget 和一个 StatefulSet。
apiVersion: v1
kind: Service
metadata:
name: zk-hs
labels:
app: zk
spec:
ports:
- port: 2888
name: server
- port: 3888
name: leader-election
clusterIP: None
selector:
app: zk
---
apiVersion: v1
kind: Service
metadata:
name: zk-cs
labels:
app: zk
spec:
ports:
- port: 2181
name: client
selector:
app: zk
---
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: zk-pdb
spec:
selector:
matchLabels:
app: zk
maxUnavailable: 1
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: zk
spec:
selector:
matchLabels:
app: zk
serviceName: zk-hs
replicas: 3
updateStrategy:
type: RollingUpdate
podManagementPolicy: OrderedReady
template:
metadata:
labels:
app: zk
spec:
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: "app"
operator: In
values:
- zk
topologyKey: "kubernetes.io/hostname"
containers:
- name: kubernetes-zookeeper
imagePullPolicy: Always
image: "registry.k8s.io/kubernetes-zookeeper:1.0-3.4.10"
resources:
requests:
memory: "1Gi"
cpu: "0.5"
ports:
- containerPort: 2181
name: client
- containerPort: 2888
name: server
- containerPort: 3888
name: leader-election
command:
- sh
- -c
- "start-zookeeper \
--servers=3 \
--data_dir=/var/lib/zookeeper/data \
--data_log_dir=/var/lib/zookeeper/data/log \
--conf_dir=/opt/zookeeper/conf \
--client_port=2181 \
--election_port=3888 \
--server_port=2888 \
--tick_time=2000 \
--init_limit=10 \
--sync_limit=5 \
--heap=512M \
--max_client_cnxns=60 \
--snap_retain_count=3 \
--purge_interval=12 \
--max_session_timeout=40000 \
--min_session_timeout=4000 \
--log_level=INFO"
readinessProbe:
exec:
command:
- sh
- -c
- "zookeeper-ready 2181"
initialDelaySeconds: 10
timeoutSeconds: 5
livenessProbe:
exec:
command:
- sh
- -c
- "zookeeper-ready 2181"
initialDelaySeconds: 10
timeoutSeconds: 5
volumeMounts:
- name: datadir
mountPath: /var/lib/zookeeper
securityContext:
runAsUser: 1000
fsGroup: 1000
volumeClaimTemplates:
- metadata:
name: datadir
spec:
accessModes: [ "ReadWriteOnce" ]
resources:
requests:
storage: 10Gi
打开一个命令行终端，使用命令
kubectl apply
创建这个清单。
kubectl apply -f https://k8s.io/examples/application/zookeeper/zookeeper.yaml
这个操作创建了 zk-hs 无头服务、zk-cs 服务、zk-pdb PodDisruptionBudget
和 zk StatefulSet。
service/zk-hs created
service/zk-cs created
poddisruptionbudget.policy/zk-pdb created
statefulset.apps/zk created
使用命令
kubectl get
查看 StatefulSet 控制器创建的几个 Pod。
kubectl get pods -w -l app=zk
一旦 zk-2 Pod 变成 Running 和 Ready 状态，请使用 CRTL-C 结束 kubectl。
NAME READY STATUS RESTARTS AGE
zk-0 0/1 Pending 0 0s
zk-0 0/1 Pending 0 0s
zk-0 0/1 ContainerCreating 0 0s
zk-0 0/1 Running 0 19s
zk-0 1/1 Running 0 40s
zk-1 0/1 Pending 0 0s
zk-1 0/1 Pending 0 0s
zk-1 0/1 ContainerCreating 0 0s
zk-1 0/1 Running 0 18s
zk-1 1/1 Running 0 40s
zk-2 0/1 Pending 0 0s
zk-2 0/1 Pending 0 0s
zk-2 0/1 ContainerCreating 0 0s
zk-2 0/1 Running 0 19s
zk-2 1/1 Running 0 40s
StatefulSet 控制器创建 3 个 Pod，每个 Pod 包含一个 ZooKeeper 服务容器。
由于在匿名网络中没有用于选举 leader 的终止算法，Zab 要求显式的进行成员关系配置， 以执行 leader 选举。Ensemble 中的每个服务器都需要具有一个独一无二的标识符， 所有的服务器均需要知道标识符的全集，并且每个标识符都需要和一个网络地址相关联。
使用命令
kubectl exec
获取 zk StatefulSet 中 Pod 的主机名。
for i in 0 1 2; do kubectl exec zk-$i -- hostname; done
StatefulSet 控制器基于每个 Pod 的序号索引为它们各自提供一个唯一的主机名。
主机名采用 <statefulset 名称>-<序数索引> 的形式。
由于 zk StatefulSet 的 replicas 字段设置为 3，这个集合的控制器将创建
3 个 Pod，主机名为：zk-0、zk-1 和 zk-2。
zk-0
zk-1
zk-2
ZooKeeper ensemble 中的服务器使用自然数作为唯一标识符，
每个服务器的标识符都保存在服务器的数据目录中一个名为 myid 的文件里。
检查每个服务器的 myid 文件的内容。
for i in 0 1 2; do echo "myid zk-$i";kubectl exec zk-$i -- cat /var/lib/zookeeper/data/myid; done
由于标识符为自然数并且序号索引是非负整数，你可以在序号上加 1 来生成一个标识符。
myid zk-0
1
myid zk-1
2
myid zk-2
3
获取 zk StatefulSet 中每个 Pod 的全限定域名（Fully Qualified Domain Name，FQDN）。
for i in 0 1 2; do kubectl exec zk-$i -- hostname -f; done
zk-hs Service 为所有 Pod 创建了一个域：zk-hs.default.svc.cluster.local。
zk-0.zk-hs.default.svc.cluster.local
zk-1.zk-hs.default.svc.cluster.local
zk-2.zk-hs.default.svc.cluster.local
Kubernetes DNS 中的 A 记录将 FQDN 解析成为 Pod 的 IP 地址。 如果 Kubernetes 重新调度这些 Pod，这个 A 记录将会使用这些 Pod 的新 IP 地址完成更新， 但 A 记录的名称不会改变。
ZooKeeper 在一个名为 zoo.cfg 的文件中保存它的应用配置。
使用 kubectl exec 在 zk-0 Pod 中查看 zoo.cfg 文件的内容。
kubectl exec zk-0 -- cat /opt/zookeeper/conf/zoo.cfg
文件底部为 server.1、server.2 和 server.3，其中的 1、2 和 3
分别对应 ZooKeeper 服务器的 myid 文件中的标识符。
它们被设置为 zk StatefulSet 中的 Pods 的 FQDNs。
clientPort=2181
dataDir=/var/lib/zookeeper/data
dataLogDir=/var/lib/zookeeper/log
tickTime=2000
initLimit=10
syncLimit=2000
maxClientCnxns=60
minSessionTimeout= 4000
maxSessionTimeout= 40000
autopurge.snapRetainCount=3
autopurge.purgeInterval=0
server.1=zk-0.zk-hs.default.svc.cluster.local:2888:3888
server.2=zk-1.zk-hs.default.svc.cluster.local:2888:3888
server.3=zk-2.zk-hs.default.svc.cluster.local:2888:3888
一致性协议要求每个参与者的标识符唯一。 在 Zab 协议里任何两个参与者都不应该声明相同的唯一标识符。 对于让系统中的进程协商哪些进程已经提交了哪些数据而言，这是必须的。 如果有两个 Pod 使用相同的序号启动，这两个 ZooKeeper 服务器会将自己识别为相同的服务器。
kubectl get pods -w -l app=zk
NAME READY STATUS RESTARTS AGE
zk-0 0/1 Pending 0 0s
zk-0 0/1 Pending 0 0s
zk-0 0/1 ContainerCreating 0 0s
zk-0 0/1 Running 0 19s
zk-0 1/1 Running 0 40s
zk-1 0/1 Pending 0 0s
zk-1 0/1 Pending 0 0s
zk-1 0/1 ContainerCreating 0 0s
zk-1 0/1 Running 0 18s
zk-1 1/1 Running 0 40s
zk-2 0/1 Pending 0 0s
zk-2 0/1 Pending 0 0s
zk-2 0/1 ContainerCreating 0 0s
zk-2 0/1 Running 0 19s
zk-2 1/1 Running 0 40s
每个 Pod 的 A 记录仅在 Pod 变成 Ready 状态时被录入。
因此，ZooKeeper 服务器的 FQDN 只会解析到一个端点，
而那个端点将是申领其 myid 文件中所配置标识的唯一 ZooKeeper 服务器。
zk-0.zk-hs.default.svc.cluster.local
zk-1.zk-hs.default.svc.cluster.local
zk-2.zk-hs.default.svc.cluster.local
这保证了 ZooKeeper 的 zoo.cfg 文件中的 servers 属性代表了一个正确配置的 ensemble。
server.1=zk-0.zk-hs.default.svc.cluster.local:2888:3888
server.2=zk-1.zk-hs.default.svc.cluster.local:2888:3888
server.3=zk-2.zk-hs.default.svc.cluster.local:2888:3888
当服务器使用 Zab 协议尝试提交一个值的时候，它们会达成一致并成功提交这个值 （如果领导者选举成功并且至少有两个 Pod 处于 Running 和 Ready 状态）， 或者将会失败（如果没有满足上述条件中的任意一条）。 当一个服务器承认另一个服务器的代写时不会有状态产生。
最基本的健康检查是向一个 ZooKeeper 服务器写入一些数据，然后从另一个服务器读取这些数据。
使用 zkCli.sh 脚本在 zk-0 Pod 上写入 world 到路径 /hello。
kubectl exec zk-0 zkCli.sh create /hello world
WATCHER::
WatchedEvent state:SyncConnected type:None path:null
Created /hello
使用下面的命令从 zk-1 Pod 获取数据。
kubectl exec zk-1 zkCli.sh get /hello
你在 zk-0 上创建的数据在 ensemble 中所有的服务器上都是可用的。
WATCHER::
WatchedEvent state:SyncConnected type:None path:null
world
cZxid = 0x100000002
ctime = Thu Dec 08 15:13:30 UTC 2016
mZxid = 0x100000002
mtime = Thu Dec 08 15:13:30 UTC 2016
pZxid = 0x100000002
cversion = 0
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 5
numChildren = 0
如同在 ZooKeeper 一节所提到的， ZooKeeper 提交所有的条目到一个持久 WAL，并周期性的将内存快照写入存储介质。 对于使用一致性协议实现一个复制状态机的应用来说， 使用 WAL 提供持久化是一种常用的技术，对于普通的存储应用也是如此。
使用 kubectl delete
删除 zk StatefulSet。
kubectl delete statefulset zk
statefulset.apps "zk" deleted
观察 StatefulSet 中的 Pod 变为终止状态。
kubectl get pods -w -l app=zk
当 zk-0 完全终止时，使用 CRTL-C 结束 kubectl。
zk-2 1/1 Terminating 0 9m
zk-0 1/1 Terminating 0 11m
zk-1 1/1 Terminating 0 10m
zk-2 0/1 Terminating 0 9m
zk-2 0/1 Terminating 0 9m
zk-2 0/1 Terminating 0 9m
zk-1 0/1 Terminating 0 10m
zk-1 0/1 Terminating 0 10m
zk-1 0/1 Terminating 0 10m
zk-0 0/1 Terminating 0 11m
zk-0 0/1 Terminating 0 11m
zk-0 0/1 Terminating 0 11m
重新应用 zookeeper.yaml 中的清单。
kubectl apply -f https://k8s.io/examples/application/zookeeper/zookeeper.yaml
zk StatefulSet 将会被创建。由于清单中的其他 API 对象已经存在，所以它们不会被修改。
观察 StatefulSet 控制器重建 StatefulSet 的 Pod。
kubectl get pods -w -l app=zk
一旦 zk-2 Pod 处于 Running 和 Ready 状态，使用 CRTL-C 停止 kubectl 命令。
NAME READY STATUS RESTARTS AGE
zk-0 0/1 Pending 0 0s
zk-0 0/1 Pending 0 0s
zk-0 0/1 ContainerCreating 0 0s
zk-0 0/1 Running 0 19s
zk-0 1/1 Running 0 40s
zk-1 0/1 Pending 0 0s
zk-1 0/1 Pending 0 0s
zk-1 0/1 ContainerCreating 0 0s
zk-1 0/1 Running 0 18s
zk-1 1/1 Running 0 40s
zk-2 0/1 Pending 0 0s
zk-2 0/1 Pending 0 0s
zk-2 0/1 ContainerCreating 0 0s
zk-2 0/1 Running 0 19s
zk-2 1/1 Running 0 40s
从 zk-2 Pod 中获取你在健康检查中输入的值。
kubectl exec zk-2 zkCli.sh get /hello
尽管 zk StatefulSet 中所有的 Pod 都已经被终止并重建过，
ensemble 仍然使用原来的数值提供服务。
WATCHER::
WatchedEvent state:SyncConnected type:None path:null
world
cZxid = 0x100000002
ctime = Thu Dec 08 15:13:30 UTC 2016
mZxid = 0x100000002
mtime = Thu Dec 08 15:13:30 UTC 2016
pZxid = 0x100000002
cversion = 0
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 5
numChildren = 0
zk StatefulSet 的 spec 中的 volumeClaimTemplates
字段标识了将要为每个 Pod 准备的 PersistentVolume。
volumeClaimTemplates:
- metadata:
name: datadir
annotations:
volume.alpha.kubernetes.io/storage-class: anything
spec:
accessModes: [ "ReadWriteOnce" ]
resources:
requests:
storage: 20Gi
StatefulSet 控制器为 StatefulSet 中的每个 Pod 生成一个 PersistentVolumeClaim。
获取 StatefulSet 的 PersistentVolumeClaim。
kubectl get pvc -l app=zk
当 StatefulSet 重新创建它的 Pod 时，Pod 的 PersistentVolume 会被重新挂载。
NAME STATUS VOLUME CAPACITY ACCESSMODES AGE
datadir-zk-0 Bound pvc-bed742cd-bcb1-11e6-994f-42010a800002 20Gi RWO 1h
datadir-zk-1 Bound pvc-bedd27d2-bcb1-11e6-994f-42010a800002 20Gi RWO 1h
datadir-zk-2 Bound pvc-bee0817e-bcb1-11e6-994f-42010a800002 20Gi RWO 1h
StatefulSet 的容器 template 中的 volumeMounts 一节使得
PersistentVolume 被挂载到 ZooKeeper 服务器的数据目录。
volumeMounts:
- name: datadir
mountPath: /var/lib/zookeeper
当 zk StatefulSet 中的一个 Pod 被（重新）调度时，它总是拥有相同的 PersistentVolume，
挂载到 ZooKeeper 服务器的数据目录。
即使在 Pod 被重新调度时，所有对 ZooKeeper 服务器的 WAL 的写入和它们的全部快照都仍然是持久的。
如同在促成领导者选举和达成一致 小节中提到的，ZooKeeper ensemble 中的服务器需要一致性的配置来选举一个领导者并形成一个 quorum。它们还需要 Zab 协议的一致性配置来保证这个协议在网络中正确的工作。 在这次的示例中，我们通过直接将配置写入代码清单中来达到该目的。
获取 zk StatefulSet。
kubectl get sts zk -o yaml
...
command:
- sh
- -c
- "start-zookeeper \
--servers=3 \
--data_dir=/var/lib/zookeeper/data \
--data_log_dir=/var/lib/zookeeper/data/log \
--conf_dir=/opt/zookeeper/conf \
--client_port=2181 \
--election_port=3888 \
--server_port=2888 \
--tick_time=2000 \
--init_limit=10 \
--sync_limit=5 \
--heap=512M \
--max_client_cnxns=60 \
--snap_retain_count=3 \
--purge_interval=12 \
--max_session_timeout=40000 \
--min_session_timeout=4000 \
--log_level=INFO"
...
用于启动 ZooKeeper 服务器的命令将这些配置作为命令行参数传给了 ensemble。 你也可以通过环境变量来传入这些配置。
zkGenConfig.sh 脚本产生的一个文件控制了 ZooKeeper 的日志行为。
ZooKeeper 使用了 Log4j
并默认使用基于文件大小和时间的滚动文件追加器作为日志配置。
从 zk StatefulSet 的一个 Pod 中获取日志配置。
kubectl exec zk-0 cat /usr/etc/zookeeper/log4j.properties
下面的日志配置会使 ZooKeeper 进程将其所有的日志写入标志输出文件流中。
zookeeper.root.logger=CONSOLE
zookeeper.console.threshold=INFO
log4j.rootLogger=${zookeeper.root.logger}
log4j.appender.CONSOLE=org.apache.log4j.ConsoleAppender
log4j.appender.CONSOLE.Threshold=${zookeeper.console.threshold}
log4j.appender.CONSOLE.layout=org.apache.log4j.PatternLayout
log4j.appender.CONSOLE.layout.ConversionPattern=%d{ISO8601} [myid:%X{myid}] - %-5p [%t:%C{1}@%L] - %m%n
这是在容器里安全记录日志的最简单的方法。 由于应用的日志被写入标准输出，Kubernetes 将会为你处理日志轮转。 Kubernetes 还实现了一个智能保存策略， 保证写入标准输出和标准错误流的应用日志不会耗尽本地存储介质。
使用命令 kubectl logs
从一个 Pod 中取回最后 20 行日志。
kubectl logs zk-0 --tail 20
使用 kubectl logs 或者从 Kubernetes Dashboard 可以查看写入到标准输出和标准错误流中的应用日志。
2016-12-06 19:34:16,236 [myid:1] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@827] - Processing ruok command from /127.0.0.1:52740
2016-12-06 19:34:16,237 [myid:1] - INFO [Thread-1136:NIOServerCnxn@1008] - Closed socket connection for client /127.0.0.1:52740 (no session established for client)
2016-12-06 19:34:26,155 [myid:1] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxnFactory@192] - Accepted socket connection from /127.0.0.1:52749
2016-12-06 19:34:26,155 [myid:1] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@827] - Processing ruok command from /127.0.0.1:52749
2016-12-06 19:34:26,156 [myid:1] - INFO [Thread-1137:NIOServerCnxn@1008] - Closed socket connection for client /127.0.0.1:52749 (no session established for client)
2016-12-06 19:34:26,222 [myid:1] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxnFactory@192] - Accepted socket connection from /127.0.0.1:52750
2016-12-06 19:34:26,222 [myid:1] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@827] - Processing ruok command from /127.0.0.1:52750
2016-12-06 19:34:26,226 [myid:1] - INFO [Thread-1138:NIOServerCnxn@1008] - Closed socket connection for client /127.0.0.1:52750 (no session established for client)
2016-12-06 19:34:36,151 [myid:1] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxnFactory@192] - Accepted socket connection from /127.0.0.1:52760
2016-12-06 19:34:36,152 [myid:1] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@827] - Processing ruok command from /127.0.0.1:52760
2016-12-06 19:34:36,152 [myid:1] - INFO [Thread-1139:NIOServerCnxn@1008] - Closed socket connection for client /127.0.0.1:52760 (no session established for client)
2016-12-06 19:34:36,230 [myid:1] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxnFactory@192] - Accepted socket connection from /127.0.0.1:52761
2016-12-06 19:34:36,231 [myid:1] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@827] - Processing ruok command from /127.0.0.1:52761
2016-12-06 19:34:36,231 [myid:1] - INFO [Thread-1140:NIOServerCnxn@1008] - Closed socket connection for client /127.0.0.1:52761 (no session established for client)
2016-12-06 19:34:46,149 [myid:1] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxnFactory@192] - Accepted socket connection from /127.0.0.1:52767
2016-12-06 19:34:46,149 [myid:1] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@827] - Processing ruok command from /127.0.0.1:52767
2016-12-06 19:34:46,149 [myid:1] - INFO [Thread-1141:NIOServerCnxn@1008] - Closed socket connection for client /127.0.0.1:52767 (no session established for client)
2016-12-06 19:34:46,230 [myid:1] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxnFactory@192] - Accepted socket connection from /127.0.0.1:52768
2016-12-06 19:34:46,230 [myid:1] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@827] - Processing ruok command from /127.0.0.1:52768
2016-12-06 19:34:46,230 [myid:1] - INFO [Thread-1142:NIOServerCnxn@1008] - Closed socket connection for client /127.0.0.1:52768 (no session established for client)
Kubernetes 支持与多种日志方案集成。 你可以选择一个最适合你的集群和应用的日志解决方案。 对于集群级别的日志输出与整合，可以考虑部署一个 边车容器 来轮转和提供日志数据。
在容器中允许应用以特权用户运行这条最佳实践是值得商讨的。 如果你的组织要求应用以非特权用户运行，你可以使用 SecurityContext 控制运行容器入口点所使用的用户。
zk StatefulSet 的 Pod 的 template 包含了一个 SecurityContext。
securityContext:
runAsUser: 1000
fsGroup: 1000
在 Pod 的容器内部，UID 1000 对应用户 zookeeper，GID 1000 对应用户组 zookeeper。
从 zk-0 Pod 获取 ZooKeeper 进程信息。
kubectl exec zk-0 -- ps -elf
由于 securityContext 对象的 runAsUser 字段被设置为 1000 而不是 root，
ZooKeeper 进程将以 zookeeper 用户运行。
F S UID PID PPID C PRI NI ADDR SZ WCHAN STIME TTY TIME CMD
4 S zookeep+ 1 0 0 80 0 - 1127 - 20:46 ? 00:00:00 sh -c zkGenConfig.sh && zkServer.sh start-foreground
0 S zookeep+ 27 1 0 80 0 - 1155556 - 20:46 ? 00:00:19 /usr/lib/jvm/java-8-openjdk-amd64/bin/java -Dzookeeper.log.dir=/var/log/zookeeper -Dzookeeper.root.logger=INFO,CONSOLE -cp /usr/bin/../build/classes:/usr/bin/../build/lib/*.jar:/usr/bin/../share/zookeeper/zookeeper-3.4.9.jar:/usr/bin/../share/zookeeper/slf4j-log4j12-1.6.1.jar:/usr/bin/../share/zookeeper/slf4j-api-1.6.1.jar:/usr/bin/../share/zookeeper/netty-3.10.5.Final.jar:/usr/bin/../share/zookeeper/log4j-1.2.16.jar:/usr/bin/../share/zookeeper/jline-0.9.94.jar:/usr/bin/../src/java/lib/*.jar:/usr/bin/../etc/zookeeper: -Xmx2G -Xms2G -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.local.only=false org.apache.zookeeper.server.quorum.QuorumPeerMain /usr/bin/../etc/zookeeper/zoo.cfg
默认情况下，当 Pod 的 PersistentVolume 被挂载到 ZooKeeper 服务器的数据目录时， 它只能被 root 用户访问。这个配置将阻止 ZooKeeper 进程写入它的 WAL 及保存快照。
在 zk-0 Pod 上获取 ZooKeeper 数据目录的文件权限。
kubectl exec -ti zk-0 -- ls -ld /var/lib/zookeeper/data
由于 securityContext 对象的 fsGroup 字段设置为 1000，
Pod 的 PersistentVolume 的所有权属于 zookeeper 用户组，
因而 ZooKeeper 进程能够成功地读写数据。
drwxr-sr-x 3 zookeeper zookeeper 4096 Dec 5 20:45 /var/lib/zookeeper/data
ZooKeeper 文档 指出 “你将需要一个监管程序用于管理每个 ZooKeeper 服务进程（JVM）”。 在分布式系统中，使用一个看门狗（监管程序）来重启故障进程是一种常用的模式。
zk StatefulSet 的更新策略被设置为了 RollingUpdate。
你可以使用 kubectl patch 更新分配给每个服务器的 cpus 的数量。
kubectl patch sts zk --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/resources/requests/cpu", "value":"0.3"}]'
statefulset.apps/zk patched
使用 kubectl rollout status 观测更新状态。
kubectl rollout status sts/zk
waiting for statefulset rolling update to complete 0 pods at revision zk-5db4499664...
Waiting for 1 pods to be ready...
Waiting for 1 pods to be ready...
waiting for statefulset rolling update to complete 1 pods at revision zk-5db4499664...
Waiting for 1 pods to be ready...
Waiting for 1 pods to be ready...
waiting for statefulset rolling update to complete 2 pods at revision zk-5db4499664...
Waiting for 1 pods to be ready...
Waiting for 1 pods to be ready...
statefulset rolling update complete 3 pods at revision zk-5db4499664...
这项操作会逆序地依次终止每一个 Pod，并用新的配置重新创建。 这样做确保了在滚动更新的过程中 quorum 依旧保持工作。
使用 kubectl rollout history 命令查看历史或先前的配置。
kubectl rollout history sts/zk
输出类似于：
statefulsets "zk"
REVISION
1
2
使用 kubectl rollout undo 命令撤销这次的改动。
kubectl rollout undo sts/zk
输出类似于：
statefulset.apps/zk rolled back
重启策略 控制 Kubernetes 如何处理一个 Pod 中容器入口点的进程故障。 对于 StatefulSet 中的 Pod 来说，Always 是唯一合适的 RestartPolicy，也是默认值。 你应该绝不覆盖有状态应用的默认策略。
检查 zk-0 Pod 中运行的 ZooKeeper 服务器的进程树。
kubectl exec zk-0 -- ps -ef
作为容器入口点的命令的 PID 为 1，Zookeeper 进程是入口点的子进程，PID 为 27。
UID PID PPID C STIME TTY TIME CMD
zookeep+ 1 0 0 15:03 ? 00:00:00 sh -c zkGenConfig.sh && zkServer.sh start-foreground
zookeep+ 27 1 0 15:03 ? 00:00:03 /usr/lib/jvm/java-8-openjdk-amd64/bin/java -Dzookeeper.log.dir=/var/log/zookeeper -Dzookeeper.root.logger=INFO,CONSOLE -cp /usr/bin/../build/classes:/usr/bin/../build/lib/*.jar:/usr/bin/../share/zookeeper/zookeeper-3.4.9.jar:/usr/bin/../share/zookeeper/slf4j-log4j12-1.6.1.jar:/usr/bin/../share/zookeeper/slf4j-api-1.6.1.jar:/usr/bin/../share/zookeeper/netty-3.10.5.Final.jar:/usr/bin/../share/zookeeper/log4j-1.2.16.jar:/usr/bin/../share/zookeeper/jline-0.9.94.jar:/usr/bin/../src/java/lib/*.jar:/usr/bin/../etc/zookeeper: -Xmx2G -Xms2G -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.local.only=false org.apache.zookeeper.server.quorum.QuorumPeerMain /usr/bin/../etc/zookeeper/zoo.cfg
在一个终端观察 zk StatefulSet 中的 Pod。
kubectl get pod -w -l app=zk
在另一个终端杀掉 Pod zk-0 中的 ZooKeeper 进程。
kubectl exec zk-0 -- pkill java
ZooKeeper 进程的终结导致了它父进程的终止。由于容器的 RestartPolicy
是 Always，所以父进程被重启。
NAME READY STATUS RESTARTS AGE
zk-0 1/1 Running 0 21m
zk-1 1/1 Running 0 20m
zk-2 1/1 Running 0 19m
NAME READY STATUS RESTARTS AGE
zk-0 0/1 Error 0 29m
zk-0 0/1 Running 1 29m
zk-0 1/1 Running 1 29m
如果你的应用使用一个脚本（例如 zkServer.sh）来启动一个实现了应用业务逻辑的进程，
这个脚本必须和子进程一起结束。这保证了当实现应用业务逻辑的进程故障时，
Kubernetes 会重启这个应用的容器。
你的应用配置为自动重启故障进程，但这对于保持一个分布式系统的健康来说是不够的。 许多场景下，一个系统进程可以是活动状态但不响应请求，或者是不健康状态。 你应该使用存活性探针来通知 Kubernetes 你的应用进程处于不健康状态，需要被重启。
zk StatefulSet 的 Pod 的 template 一节指定了一个存活探针。
livenessProbe:
exec:
command:
- sh
- -c
- "zookeeper-ready 2181"
initialDelaySeconds: 15
timeoutSeconds: 5
这个探针调用一个简单的 Bash 脚本，使用 ZooKeeper 的四字缩写 ruok
来测试服务器的健康状态。
OK=$(echo ruok | nc 127.0.0.1 $1)
if [ "$OK" == "imok" ]; then
exit 0
else
exit 1
fi
在一个终端窗口中使用下面的命令观察 zk StatefulSet 中的 Pod。
kubectl get pod -w -l app=zk
在另一个窗口中，从 Pod zk-0 的文件系统中删除 zookeeper-ready 脚本。
kubectl exec zk-0 -- rm /opt/zookeeper/bin/zookeeper-ready
当 ZooKeeper 进程的存活探针探测失败时，Kubernetes 将会为你自动重启这个进程， 从而保证 ensemble 中不健康状态的进程都被重启。
kubectl get pod -w -l app=zk
NAME READY STATUS RESTARTS AGE
zk-0 1/1 Running 0 1h
zk-1 1/1 Running 0 1h
zk-2 1/1 Running 0 1h
NAME READY STATUS RESTARTS AGE
zk-0 0/1 Running 0 1h
zk-0 0/1 Running 1 1h
zk-0 1/1 Running 1 1h
就绪不同于存活。如果一个进程是存活的，它是可调度和健康的。 如果一个进程是就绪的，它应该能够处理输入。存活是就绪的必要非充分条件。 在许多场景下，特别是初始化和终止过程中，一个进程可以是存活但没有就绪的。
如果你指定了一个就绪探针，Kubernetes 将保证在就绪检查通过之前， 你的应用不会接收到网络流量。
对于一个 ZooKeeper 服务器来说，存活即就绪。
因此 zookeeper.yaml 清单中的就绪探针和存活探针完全相同。
readinessProbe:
exec:
command:
- sh
- -c
- "zookeeper-ready 2181"
initialDelaySeconds: 15
timeoutSeconds: 5
虽然存活探针和就绪探针是相同的，但同时指定它们两者仍然重要。 这保证了 ZooKeeper ensemble 中只有健康的服务器能接收网络流量。
ZooKeeper 需要一个 quorum 来提交数据变动。对于一个拥有 3 个服务器的 ensemble 来说， 必须有两个服务器是健康的，写入才能成功。 在基于 quorum 的系统里，成员被部署在多个故障域中以保证可用性。 为了防止由于某台机器断连引起服务中断，最佳实践是防止应用的多个实例在相同的机器上共存。
默认情况下，Kubernetes 可以把 StatefulSet 的 Pod 部署在相同节点上。
对于你创建的 3 个服务器的 ensemble 来说，
如果有两个服务器并存于相同的节点上并且该节点发生故障时，ZooKeeper 服务将中断，
直至至少其中一个 Pod 被重新调度。
你应该总是提供多余的容量以允许关键系统进程在节点故障时能够被重新调度。
如果你这样做了，服务故障就只会持续到 Kubernetes 调度器重新调度某个
ZooKeeper 服务器为止。
但是，如果希望你的服务在容忍节点故障时无停服时间，你应该设置 podAntiAffinity。
使用下面的命令获取 zk StatefulSet 中的 Pod 的节点。
for i in 0 1 2; do kubectl get pod zk-$i --template {{.spec.nodeName}}; echo ""; done
zk StatefulSet 中所有的 Pod 都被部署在不同的节点。
kubernetes-node-cxpk
kubernetes-node-a5aq
kubernetes-node-2g2d
这是因为 zk StatefulSet 中的 Pod 指定了 PodAntiAffinity。
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: "app"
operator: In
values:
- zk
topologyKey: "kubernetes.io/hostname"
requiredDuringSchedulingIgnoredDuringExecution 告诉 Kubernetes 调度器，
在以 topologyKey 指定的域中，绝对不要把带有键为 app、值为 zk 的标签
的两个 Pod 调度到相同的节点。topologyKey kubernetes.io/hostname 表示
这个域是一个单独的节点。
使用不同的规则、标签和选择算符，你能够通过这种技术把你的 ensemble 分布
在不同的物理、网络和电力故障域之间。
在本节中你将会隔离（Cordon）和腾空（Drain）节点。 如果你是在一个共享的集群里使用本教程，请保证不会影响到其他租户。
上一小节展示了如何在节点之间分散 Pod 以在计划外的节点故障时保证服务存活。 但是你也需要为计划内维护引起的临时节点故障做准备。
使用此命令获取你的集群中的节点。
kubectl get nodes
使用 kubectl cordon
隔离你的集群中除 4 个节点以外的所有节点。
kubectl cordon <node-name>
使用下面的命令获取 zk-pdb PodDisruptionBudget。
kubectl get pdb zk-pdb
max-unavailable 字段指示 Kubernetes 在任何时候，zk StatefulSet
至多有一个 Pod 是不可用的。
NAME MIN-AVAILABLE MAX-UNAVAILABLE ALLOWED-DISRUPTIONS AGE
zk-pdb N/A 1 1
在一个终端中，使用下面的命令观察 zk StatefulSet 中的 Pod。
kubectl get pods -w -l app=zk
在另一个终端中，使用下面的命令获取 Pod 当前调度的节点。
for i in 0 1 2; do kubectl get pod zk-$i --template {{.spec.nodeName}}; echo ""; done
kubernetes-node-pb41
kubernetes-node-ixsl
kubernetes-node-i4c4
使用 kubectl drain
来隔离和腾空 zk-0 Pod 调度所在的节点。
kubectl drain $(kubectl get pod zk-0 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-emptydir-data
输出类似于：
node "kubernetes-node-pb41" cordoned
WARNING: Deleting pods not managed by ReplicationController, ReplicaSet, Job, or DaemonSet: fluentd-cloud-logging-kubernetes-node-pb41, kube-proxy-kubernetes-node-pb41; Ignoring DaemonSet-managed pods: node-problem-detector-v0.1-o5elz
pod "zk-0" deleted
node "kubernetes-node-pb41" drained
由于你的集群中有 4 个节点, kubectl drain 执行成功，zk-0 被调度到其它节点。
NAME READY STATUS RESTARTS AGE
zk-0 1/1 Running 2 1h
zk-1 1/1 Running 0 1h
zk-2 1/1 Running 0 1h
NAME READY STATUS RESTARTS AGE
zk-0 1/1 Terminating 2 2h
zk-0 0/1 Terminating 2 2h
zk-0 0/1 Terminating 2 2h
zk-0 0/1 Terminating 2 2h
zk-0 0/1 Pending 0 0s
zk-0 0/1 Pending 0 0s
zk-0 0/1 ContainerCreating 0 0s
zk-0 0/1 Running 0 51s
zk-0 1/1 Running 0 1m
在第一个终端中持续观察 StatefulSet 的 Pod 并腾空 zk-1 调度所在的节点。
kubectl drain $(kubectl get pod zk-1 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-emptydir-data
输出类似于：
kubernetes-node-ixsl" cordoned
WARNING: Deleting pods not managed by ReplicationController, ReplicaSet, Job, or DaemonSet: fluentd-cloud-logging-kubernetes-node-ixsl, kube-proxy-kubernetes-node-ixsl; Ignoring DaemonSet-managed pods: node-problem-detector-v0.1-voc74
pod "zk-1" deleted
node "kubernetes-node-ixsl" drained
zk-1 Pod 不能被调度，这是因为 zk StatefulSet 包含了一个防止 Pod
共存的 PodAntiAffinity 规则，而且只有两个节点可用于调度，
这个 Pod 将保持在 Pending 状态。
kubectl get pods -w -l app=zk
输出类似于：
NAME READY STATUS RESTARTS AGE
zk-0 1/1 Running 2 1h
zk-1 1/1 Running 0 1h
zk-2 1/1 Running 0 1h
NAME READY STATUS RESTARTS AGE
zk-0 1/1 Terminating 2 2h
zk-0 0/1 Terminating 2 2h
zk-0 0/1 Terminating 2 2h
zk-0 0/1 Terminating 2 2h
zk-0 0/1 Pending 0 0s
zk-0 0/1 Pending 0 0s
zk-0 0/1 ContainerCreating 0 0s
zk-0 0/1 Running 0 51s
zk-0 1/1 Running 0 1m
zk-1 1/1 Terminating 0 2h
zk-1 0/1 Terminating 0 2h
zk-1 0/1 Terminating 0 2h
zk-1 0/1 Terminating 0 2h
zk-1 0/1 Pending 0 0s
zk-1 0/1 Pending 0 0s
继续观察 StatefulSet 中的 Pod 并腾空 zk-2 调度所在的节点。
kubectl drain $(kubectl get pod zk-2 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-emptydir-data
输出类似于：
node "kubernetes-node-i4c4" cordoned
WARNING: Deleting pods not managed by ReplicationController, ReplicaSet, Job, or DaemonSet: fluentd-cloud-logging-kubernetes-node-i4c4, kube-proxy-kubernetes-node-i4c4; Ignoring DaemonSet-managed pods: node-problem-detector-v0.1-dyrog
WARNING: Ignoring DaemonSet-managed pods: node-problem-detector-v0.1-dyrog; Deleting pods not managed by ReplicationController, ReplicaSet, Job, or DaemonSet: fluentd-cloud-logging-kubernetes-node-i4c4, kube-proxy-kubernetes-node-i4c4
There are pending pods when an error occurred: Cannot evict pod as it would violate the pod's disruption budget.
pod/zk-2
使用 CTRL-C 终止 kubectl。
你不能腾空第三个节点，因为驱逐 zk-2 将和 zk-budget 冲突。
然而这个节点仍然处于隔离状态（Cordoned）。
使用 zkCli.sh 从 zk-0 取回你的健康检查中输入的数值。
kubectl exec zk-0 zkCli.sh get /hello
由于遵守了 PodDisruptionBudget，服务仍然可用。
WatchedEvent state:SyncConnected type:None path:null
world
cZxid = 0x200000002
ctime = Wed Dec 07 00:08:59 UTC 2016
mZxid = 0x200000002
mtime = Wed Dec 07 00:08:59 UTC 2016
pZxid = 0x200000002
cversion = 0
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 5
numChildren = 0
使用 kubectl uncordon
来取消对第一个节点的隔离。
kubectl uncordon kubernetes-node-pb41
输出类似于：
node "kubernetes-node-pb41" uncordoned
zk-1 被重新调度到了这个节点。等待 zk-1 变为 Running 和 Ready 状态。
kubectl get pods -w -l app=zk
输出类似于：
NAME READY STATUS RESTARTS AGE
zk-0 1/1 Running 2 1h
zk-1 1/1 Running 0 1h
zk-2 1/1 Running 0 1h
NAME READY STATUS RESTARTS AGE
zk-0 1/1 Terminating 2 2h
zk-0 0/1 Terminating 2 2h
zk-0 0/1 Terminating 2 2h
zk-0 0/1 Terminating 2 2h
zk-0 0/1 Pending 0 0s
zk-0 0/1 Pending 0 0s
zk-0 0/1 ContainerCreating 0 0s
zk-0 0/1 Running 0 51s
zk-0 1/1 Running 0 1m
zk-1 1/1 Terminating 0 2h
zk-1 0/1 Terminating 0 2h
zk-1 0/1 Terminating 0 2h
zk-1 0/1 Terminating 0 2h
zk-1 0/1 Pending 0 0s
zk-1 0/1 Pending 0 0s
zk-1 0/1 Pending 0 12m
zk-1 0/1 ContainerCreating 0 12m
zk-1 0/1 Running 0 13m
zk-1 1/1 Running 0 13m
尝试腾空 zk-2 调度所在的节点。
kubectl drain $(kubectl get pod zk-2 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-emptydir-data
输出类似于：
node "kubernetes-node-i4c4" already cordoned
WARNING: Deleting pods not managed by ReplicationController, ReplicaSet, Job, or DaemonSet: fluentd-cloud-logging-kubernetes-node-i4c4, kube-proxy-kubernetes-node-i4c4; Ignoring DaemonSet-managed pods: node-problem-detector-v0.1-dyrog
pod "heapster-v1.2.0-2604621511-wht1r" deleted
pod "zk-2" deleted
node "kubernetes-node-i4c4" drained
这次 kubectl drain 执行成功。
取消第二个节点的隔离，以允许 zk-2 被重新调度。
kubectl uncordon kubernetes-node-ixsl
输出类似于：
node "kubernetes-node-ixsl" uncordoned
你可以同时使用 kubectl drain 和 PodDisruptionBudgets 来保证你的服务在维护过程中仍然可用。
如果使用了腾空操作来隔离节点并在节点离线之前驱逐了 Pod，
那么设置了干扰预算的服务将会遵守该预算。
你应该总是为关键服务分配额外容量，这样它们的 Pod 就能够迅速的重新调度。
kubectl uncordon 解除你集群中所有节点的隔离。运行在 Kubernetes 集群中的应用程序通过 Service 抽象发现彼此并相互通信，它们也用 Service 与外部世界通信。 本文解释了发送到不同类型 Service 的数据包的源 IP 会发生什么情况，以及如何根据需要切换此行为。
本文使用了下列术语：
你必须拥有一个 Kubernetes 的集群，同时你的 Kubernetes 集群必须带有 kubectl 命令行工具。 建议在至少有两个节点的集群上运行本教程，且这些节点不作为控制平面主机。 如果你还没有集群，你可以通过 Minikube 构建一个你自己的集群，或者你可以使用下面任意一个 Kubernetes 工具构建：
示例使用一个小型 nginx Web 服务器，服务器通过 HTTP 标头返回它接收到的请求的源 IP。 你可以按如下方式创建它：
kubectl create deployment source-ip-app --image=registry.k8s.io/echoserver:1.4
输出为：
deployment.apps/source-ip-app created
Type=ClusterIP 类型 Service 的源 IP如果你在 iptables 模式（默认）下运行
kube-proxy，则从集群内发送到 ClusterIP 的数据包永远不会进行源 NAT。
你可以通过在运行 kube-proxy 的节点上获取 http://localhost:10249/proxyMode 来查询 kube-proxy 模式。
kubectl get nodes
输出类似于：
NAME STATUS ROLES AGE VERSION
kubernetes-node-6jst Ready <none> 2h v1.13.0
kubernetes-node-cx31 Ready <none> 2h v1.13.0
kubernetes-node-jj1t Ready <none> 2h v1.13.0
在其中一个节点上获取代理模式（kube-proxy 监听 10249 端口）：
# 在要查询的节点上的 shell 中运行
curl http://localhost:10249/proxyMode
输出为：
iptables
你可以通过在源 IP 应用程序上创建 Service 来测试源 IP 保留：
kubectl expose deployment source-ip-app --name=clusterip --port=80 --target-port=8080
输出为：
service/clusterip exposed
kubectl get svc clusterip
输出类似于：
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
clusterip ClusterIP 10.0.170.92 <none> 80/TCP 51s
并从同一集群中的 Pod 中访问 ClusterIP：
kubectl run busybox -it --image=busybox:1.28 --restart=Never --rm
输出类似于：
Waiting for pod default/busybox to be running, status is Pending, pod ready: false
If you don't see a command prompt, try pressing enter.
然后，你可以在该 Pod 中运行命令：
# 从 “kubectl run” 的终端中运行
ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1460 qdisc noqueue
link/ether 0a:58:0a:f4:03:08 brd ff:ff:ff:ff:ff:ff
inet 10.244.3.8/24 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::188a:84ff:feb0:26a5/64 scope link
valid_lft forever preferred_lft forever
然后使用 wget 查询本地 Web 服务器：
# 将 “10.0.170.92” 替换为 Service 中名为 “clusterip” 的 IPv4 地址
wget -qO - 10.0.170.92
CLIENT VALUES:
client_address=10.244.3.8
command=GET
...
不管客户端 Pod 和服务器 Pod 位于同一节点还是不同节点，client_address 始终是客户端 Pod 的 IP 地址。
Type=NodePort 类型 Service 的源 IP默认情况下，发送到 Type=NodePort
的 Service 的数据包会经过源 NAT 处理。你可以通过创建一个 NodePort 的 Service 来测试这点：
kubectl expose deployment source-ip-app --name=nodeport --port=80 --target-port=8080 --type=NodePort
输出为：
service/nodeport exposed
NODEPORT=$(kubectl get -o jsonpath="{.spec.ports[0].nodePort}" services nodeport)
NODES=$(kubectl get nodes -o jsonpath='{ $.items[*].status.addresses[?(@.type=="InternalIP")].address }')
如果你在云供应商上运行，你可能需要为上面报告的 nodes:nodeport 打开防火墙规则。
现在你可以尝试通过上面分配的节点端口从集群外部访问 Service。
for node in $NODES; do curl -s $node:$NODEPORT | grep -i client_address; done
输出类似于：
client_address=10.180.1.1
client_address=10.240.0.5
client_address=10.240.0.3
请注意，这些并不是正确的客户端 IP，它们是集群的内部 IP。这是所发生的事情：
node2:nodePortnode2 使用它自己的 IP 地址替换数据包的源 IP 地址（SNAT）node2 将数据包上的目标 IP 替换为 Pod IP用图表示： 如图。使用 SNAT 的源 IP（Type=NodePort）
为避免这种情况，Kubernetes 有一个特性可以保留客户端源 IP。
如果将 service.spec.externalTrafficPolicy 设置为 Local，
kube-proxy 只会将代理请求代理到本地端点，而不会将流量转发到其他节点。
这种方法保留了原始源 IP 地址。如果没有本地端点，则发送到该节点的数据包将被丢弃，
因此你可以在任何数据包处理规则中依赖正确的源 IP，你可能会应用一个数据包使其通过该端点。
设置 service.spec.externalTrafficPolicy 字段如下：
kubectl patch svc nodeport -p '{"spec":{"externalTrafficPolicy":"Local"}}'
输出为：
service/nodeport patched
现在，重新运行测试：
for node in $NODES; do curl --connect-timeout 1 -s $node:$NODEPORT | grep -i client_address; done
输出类似于：
client_address=198.51.100.79
请注意，你只从运行端点 Pod 的节点得到了回复，这个回复有正确的客户端 IP。
这是发生的事情：
node2:nodePortnode1:nodePort用图表示： 如图。源 IP（Type=NodePort）保存客户端源 IP 地址
Type=LoadBalancer 类型 Service 的源 IP默认情况下，发送到 Type=LoadBalancer
的 Service 的数据包经过源 NAT处理，因为所有处于 Ready 状态的可调度 Kubernetes
节点对于负载均衡的流量都是符合条件的。
因此，如果数据包到达一个没有端点的节点，系统会将其代理到一个带有端点的节点，用该节点的 IP 替换数据包上的源 IP（如上一节所述）。
你可以通过负载均衡器上暴露 source-ip-app 进行测试：
kubectl expose deployment source-ip-app --name=loadbalancer --port=80 --target-port=8080 --type=LoadBalancer
输出为：
service/loadbalancer exposed
打印 Service 的 IP 地址：
kubectl get svc loadbalancer
输出类似于：
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
loadbalancer LoadBalancer 10.0.65.118 203.0.113.140 80/TCP 5m
接下来，发送请求到 Service 的 的外部 IP（External-IP）：
curl 203.0.113.140
输出类似于：
CLIENT VALUES:
client_address=10.240.0.5
...
然而，如果你在 Google Kubernetes Engine/GCE 上运行，
将相同的 service.spec.externalTrafficPolicy 字段设置为 Local，
故意导致健康检查失败，从而强制没有端点的节点把自己从负载均衡流量的可选节点列表中删除。
用图表示：
你可以通过设置注解进行测试：
kubectl patch svc loadbalancer -p '{"spec":{"externalTrafficPolicy":"Local"}}'
你应该能够立即看到 Kubernetes 分配的 service.spec.healthCheckNodePort 字段：
kubectl get svc loadbalancer -o yaml | grep -i healthCheckNodePort
输出类似于：
healthCheckNodePort: 32122
service.spec.healthCheckNodePort 字段指向每个在 /healthz
路径上提供健康检查的节点的端口。你可以这样测试：
kubectl get pod -o wide -l app=source-ip-app
输出类似于：
NAME READY STATUS RESTARTS AGE IP NODE
source-ip-app-826191075-qehz4 1/1 Running 0 20h 10.180.1.136 kubernetes-node-6jst
使用 curl 获取各个节点上的 /healthz 端点：
# 在你选择的节点上本地运行
curl localhost:32122/healthz
1 Service Endpoints found
在不同的节点上，你可能会得到不同的结果：
# 在你选择的节点上本地运行
curl localhost:32122/healthz
No Service Endpoints Found
在控制平面上运行的控制器负责分配云负载均衡器。
同一个控制器还在每个节点上分配指向此端口/路径的 HTTP 健康检查。
等待大约 10 秒，让 2 个没有端点的节点健康检查失败，然后使用 curl 查询负载均衡器的 IPv4 地址：
curl 203.0.113.140
输出类似于：
CLIENT VALUES:
client_address=198.51.100.79
...
只有部分云提供商为 Type=LoadBalancer 的 Service 提供保存源 IP 的支持。
你正在运行的云提供商可能会以几种不同的方式满足对负载均衡器的请求：
使用终止客户端连接并打开到你的节点/端点的新连接的代理。 在这种情况下，源 IP 将始终是云 LB 的源 IP，而不是客户端的源 IP。
使用数据包转发器，这样客户端发送到负载均衡器 VIP 的请求最终会到达具有客户端源 IP 的节点，而不是中间代理。
第一类负载均衡器必须使用负载均衡器和后端之间商定的协议来传达真实的客户端 IP，
例如 HTTP 转发或
X-FORWARDED-FOR
标头，或代理协议。
第二类负载均衡器可以通过创建指向存储在 Service 上的 service.spec.healthCheckNodePort
字段中的端口的 HTTP 健康检查来利用上述功能。
删除 Service：
kubectl delete svc -l app=source-ip-app
删除 Deployment、ReplicaSet 和 Pod：
kubectl delete deployment source-ip-app
既然有了一个持续运行、可复制的应用，我们就能够将它暴露到网络上。
Kubernetes 假设 Pod 可与其它 Pod 通信，不管它们在哪个主机上。 Kubernetes 给每一个 Pod 分配一个集群私有 IP 地址，所以没必要在 Pod 与 Pod 之间创建连接或将容器的端口映射到主机端口。 这意味着同一个 Pod 内的所有容器能通过 localhost 上的端口互相连通，集群中的所有 Pod 也不需要通过 NAT 转换就能够互相看到。 本文档的剩余部分详述如何在上述网络模型之上运行可靠的服务。
本教程使用一个简单的 Nginx 服务器来演示概念验证原型。
我们在之前的示例中已经做过，然而让我们以网络连接的视角再重做一遍。 创建一个 Nginx Pod，注意其中包含一个容器端口的规约：
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-nginx
spec:
selector:
matchLabels:
run: my-nginx
replicas: 2
template:
metadata:
labels:
run: my-nginx
spec:
containers:
- name: my-nginx
image: nginx
ports:
- containerPort: 80
这使得可以从集群中任何一个节点来访问它。检查节点，该 Pod 正在运行：
kubectl apply -f ./run-my-nginx.yaml
kubectl get pods -l run=my-nginx -o wide
NAME READY STATUS RESTARTS AGE IP NODE
my-nginx-3800858182-jr4a2 1/1 Running 0 13s 10.244.3.4 kubernetes-minion-905m
my-nginx-3800858182-kna2y 1/1 Running 0 13s 10.244.2.5 kubernetes-minion-ljyd
检查 Pod 的 IP 地址：
kubectl get pods -l run=my-nginx -o custom-columns=POD_IP:.status.podIPs
POD_IP
[map[ip:10.244.3.4]]
[map[ip:10.244.2.5]]
你应该能够通过 ssh 登录到集群中的任何一个节点上，并使用诸如 curl 之类的工具向这两个 IP 地址发出查询请求。
需要注意的是，容器 不会 使用该节点上的 80 端口，也不会使用任何特定的 NAT 规则去路由流量到 Pod 上。
这意味着可以在同一个节点上运行多个 Nginx Pod，使用相同的 containerPort，并且可以从集群中任何其他的
Pod 或节点上使用 IP 的方式访问到它们。
如果你想的话，你依然可以将宿主节点的某个端口的流量转发到 Pod 中，但是出于网络模型的原因，你不必这么做。
如果对此好奇，请参考 Kubernetes 网络模型。
我们有一组在一个扁平的、集群范围的地址空间中运行 Nginx 服务的 Pod。 理论上，你可以直接连接到这些 Pod，但如果某个节点死掉了会发生什么呢？ Pod 会终止，Deployment 将创建新的 Pod，且使用不同的 IP。这正是 Service 要解决的问题。
Kubernetes Service 是集群中提供相同功能的一组 Pod 的抽象表达。 当每个 Service 创建时，会被分配一个唯一的 IP 地址（也称为 clusterIP）。 这个 IP 地址与 Service 的生命周期绑定在一起，只要 Service 存在，它就不会改变。 可以配置 Pod 使它与 Service 进行通信，Pod 知道与 Service 通信将被自动地负载均衡到该 Service 中的某些 Pod 上。
可以使用 kubectl expose 命令为 2 个 Nginx 副本创建一个 Service：
kubectl expose deployment/my-nginx
service/my-nginx exposed
这等价于使用 kubectl create -f 命令及如下的 yaml 文件创建：
apiVersion: v1
kind: Service
metadata:
name: my-nginx
labels:
run: my-nginx
spec:
ports:
- port: 80
protocol: TCP
selector:
run: my-nginx
上述规约将创建一个 Service，该 Service 会将所有具有标签 run: my-nginx 的 Pod 的 TCP
80 端口暴露到一个抽象的 Service 端口上（targetPort：容器接收流量的端口；port：
可任意取值的抽象的 Service 端口，其他 Pod 通过该端口访问 Service）。
查看 Service
API 对象以了解 Service 所能接受的字段列表。
查看你的 Service 资源:
kubectl get svc my-nginx
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
my-nginx ClusterIP 10.0.162.149 <none> 80/TCP 21s
正如前面所提到的，一个 Service 由一组 Pod 提供支撑。这些 Pod 通过 EndpointSlices 暴露出来。 Service Selector 将持续评估，结果被 POST 到使用标签与该 Service 连接的一个 EndpointSlice。 当 Pod 终止后，它会自动从包含该 Pod 的 EndpointSlices 中移除。 新的能够匹配上 Service Selector 的 Pod 将自动地被为该 Service 添加到 EndpointSlice 中。 检查 Endpoint，注意到 IP 地址与在第一步创建的 Pod 是相同的。
kubectl describe svc my-nginx
Name: my-nginx
Namespace: default
Labels: run=my-nginx
Annotations: <none>
Selector: run=my-nginx
Type: ClusterIP
IP Family Policy: SingleStack
IP Families: IPv4
IP: 10.0.162.149
IPs: 10.0.162.149
Port: <unset> 80/TCP
TargetPort: 80/TCP
Endpoints: 10.244.2.5:80,10.244.3.4:80
Session Affinity: None
Events: <none>
kubectl get endpointslices -l kubernetes.io/service-name=my-nginx
NAME ADDRESSTYPE PORTS ENDPOINTS AGE
my-nginx-7vzhx IPv4 80 10.244.2.5,10.244.3.4 21s
现在，你应该能够从集群中任意节点上使用 curl 命令向 <CLUSTER-IP>:<PORT> 发送请求以访问 Nginx Service。
注意 Service IP 完全是虚拟的，它从来没有走过网络，如果对它如何工作的原理感到好奇，
可以进一步阅读服务代理的内容。
Kubernetes 支持两种查找服务的主要模式：环境变量和 DNS。前者开箱即用，而后者则需要 CoreDNS 集群插件。
如果不需要服务环境变量（因为可能与预期的程序冲突，可能要处理的变量太多，或者仅使用DNS等），则可以通过在
pod spec
上将 enableServiceLinks 标志设置为 false 来禁用此模式。
当 Pod 在节点上运行时，kubelet 会针对每个活跃的 Service 为 Pod 添加一组环境变量。 这就引入了一个顺序的问题。为解释这个问题，让我们先检查正在运行的 Nginx Pod 的环境变量（你的环境中的 Pod 名称将会与下面示例命令中的不同）：
kubectl exec my-nginx-3800858182-jr4a2 -- printenv | grep SERVICE
KUBERNETES_SERVICE_HOST=10.0.0.1
KUBERNETES_SERVICE_PORT=443
KUBERNETES_SERVICE_PORT_HTTPS=443
能看到环境变量中并没有你创建的 Service 相关的值。这是因为副本的创建先于 Service。 这样做的另一个缺点是，调度器可能会将所有 Pod 部署到同一台机器上，如果该机器宕机则整个 Service 都会离线。 要改正的话，我们可以先终止这 2 个 Pod，然后等待 Deployment 去重新创建它们。 这次 Service 会 先于 副本存在。这将实现调度器级别的 Pod 按 Service 分布（假定所有的节点都具有同样的容量），并提供正确的环境变量：
kubectl scale deployment my-nginx --replicas=0; kubectl scale deployment my-nginx --replicas=2;
kubectl get pods -l run=my-nginx -o wide
NAME READY STATUS RESTARTS AGE IP NODE
my-nginx-3800858182-e9ihh 1/1 Running 0 5s 10.244.2.7 kubernetes-minion-ljyd
my-nginx-3800858182-j4rm4 1/1 Running 0 5s 10.244.3.8 kubernetes-minion-905m
你可能注意到，Pod 具有不同的名称，这是因为它们是被重新创建的。
kubectl exec my-nginx-3800858182-e9ihh -- printenv | grep SERVICE
KUBERNETES_SERVICE_PORT=443
MY_NGINX_SERVICE_HOST=10.0.162.149
KUBERNETES_SERVICE_HOST=10.0.0.1
MY_NGINX_SERVICE_PORT=80
KUBERNETES_SERVICE_PORT_HTTPS=443
Kubernetes 提供了一个自动为其它 Service 分配 DNS 名字的 DNS 插件 Service。 你可以通过如下命令检查它是否在工作：
kubectl get services kube-dns --namespace=kube-system
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kube-dns ClusterIP 10.0.0.10 <none> 53/UDP,53/TCP 8m
本段剩余的内容假设你已经有一个拥有持久 IP 地址的 Service（my-nginx），以及一个为其
IP 分配名称的 DNS 服务器。 这里我们使用 CoreDNS 集群插件（应用名为 kube-dns），
所以在集群中的任何 Pod 中，你都可以使用标准方法（例如：gethostbyname()）与该 Service 通信。
如果 CoreDNS 没有在运行，你可以参照
CoreDNS README
或者安装 CoreDNS 来启用它。
让我们运行另一个 curl 应用来进行测试：
kubectl run curl --image=radial/busyboxplus:curl -i --tty
Waiting for pod default/curl-131556218-9fnch to be running, status is Pending, pod ready: false
Hit enter for command prompt
然后，按回车并执行命令 nslookup my-nginx：
[ root@curl-131556218-9fnch:/ ]$ nslookup my-nginx
Server: 10.0.0.10
Address 1: 10.0.0.10
Name: my-nginx
Address 1: 10.0.162.149
到现在为止，我们只在集群内部访问了 Nginx 服务器。在将 Service 暴露到因特网之前，我们希望确保通信信道是安全的。 为实现这一目的，需要：
你可以从 Nginx https 示例获取所有上述内容。 你需要安装 go 和 make 工具。如果你不想安装这些软件，可以按照后文所述的手动执行步骤执行操作。简要过程如下：
make keys KEY=/tmp/nginx.key CERT=/tmp/nginx.crt
kubectl create secret tls nginxsecret --key /tmp/nginx.key --cert /tmp/nginx.crt
secret/nginxsecret created
kubectl get secrets
NAME TYPE DATA AGE
nginxsecret kubernetes.io/tls 2 1m
以下是 configmap：
kubectl create configmap nginxconfigmap --from-file=default.conf
configmap/nginxconfigmap created
kubectl get configmaps
NAME DATA AGE
nginxconfigmap 1 114s
以下是你在运行 make 时遇到问题时要遵循的手动步骤（例如，在 Windows 上）：
# 创建公钥和相对应的私钥
openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /d/tmp/nginx.key -out /d/tmp/nginx.crt -subj "/CN=my-nginx/O=my-nginx"
# 对密钥实施 base64 编码
cat /d/tmp/nginx.crt | base64
cat /d/tmp/nginx.key | base64
使用前面命令的输出来创建 yaml 文件，如下所示。 base64 编码的值应全部放在一行上。
apiVersion: "v1"
kind: "Secret"
metadata:
name: "nginxsecret"
namespace: "default"
type: kubernetes.io/tls
data:
tls.crt: "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURIekNDQWdlZ0F3SUJBZ0lKQUp5M3lQK0pzMlpJTUEwR0NTcUdTSWIzRFFFQkJRVUFNQ1l4RVRBUEJnTlYKQkFNVENHNW5hVzU0YzNaak1SRXdEd1lEVlFRS0V3aHVaMmx1ZUhOMll6QWVGdzB4TnpFd01qWXdOekEzTVRKYQpGdzB4T0RFd01qWXdOekEzTVRKYU1DWXhFVEFQQmdOVkJBTVRDRzVuYVc1NGMzWmpNUkV3RHdZRFZRUUtFd2h1CloybHVlSE4yWXpDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBSjFxSU1SOVdWM0IKMlZIQlRMRmtobDRONXljMEJxYUhIQktMSnJMcy8vdzZhU3hRS29GbHlJSU94NGUrMlN5ajBFcndCLzlYTnBwbQppeW1CL3JkRldkOXg5UWhBQUxCZkVaTmNiV3NsTVFVcnhBZW50VWt1dk1vLzgvMHRpbGhjc3paenJEYVJ4NEo5Ci82UVRtVVI3a0ZTWUpOWTVQZkR3cGc3dlVvaDZmZ1Voam92VG42eHNVR0M2QURVODBpNXFlZWhNeVI1N2lmU2YKNHZpaXdIY3hnL3lZR1JBRS9mRTRqakxCdmdONjc2SU90S01rZXV3R0ljNDFhd05tNnNTSzRqYUNGeGpYSnZaZQp2by9kTlEybHhHWCtKT2l3SEhXbXNhdGp4WTRaNVk3R1ZoK0QrWnYvcW1mMFgvbVY0Rmo1NzV3ajFMWVBocWtsCmdhSXZYRyt4U1FVQ0F3RUFBYU5RTUU0d0hRWURWUjBPQkJZRUZPNG9OWkI3YXc1OUlsYkROMzhIYkduYnhFVjcKTUI4R0ExVWRJd1FZTUJhQUZPNG9OWkI3YXc1OUlsYkROMzhIYkduYnhFVjdNQXdHQTFVZEV3UUZNQU1CQWY4dwpEUVlKS29aSWh2Y05BUUVGQlFBRGdnRUJBRVhTMW9FU0lFaXdyMDhWcVA0K2NwTHI3TW5FMTducDBvMm14alFvCjRGb0RvRjdRZnZqeE04Tzd2TjB0clcxb2pGSW0vWDE4ZnZaL3k4ZzVaWG40Vm8zc3hKVmRBcStNZC9jTStzUGEKNmJjTkNUekZqeFpUV0UrKzE5NS9zb2dmOUZ3VDVDK3U2Q3B5N0M3MTZvUXRUakViV05VdEt4cXI0Nk1OZWNCMApwRFhWZmdWQTRadkR4NFo3S2RiZDY5eXM3OVFHYmg5ZW1PZ05NZFlsSUswSGt0ejF5WU4vbVpmK3FqTkJqbWZjCkNnMnlwbGQ0Wi8rUUNQZjl3SkoybFIrY2FnT0R4elBWcGxNSEcybzgvTHFDdnh6elZPUDUxeXdLZEtxaUMwSVEKQ0I5T2wwWW5scE9UNEh1b2hSUzBPOStlMm9KdFZsNUIyczRpbDlhZ3RTVXFxUlU9Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K"
tls.key: "LS0tLS1CRUdJTiBQUklWQVRFIEtFWS0tLS0tCk1JSUV2UUlCQURBTkJna3Foa2lHOXcwQkFRRUZBQVNDQktjd2dnU2pBZ0VBQW9JQkFRQ2RhaURFZlZsZHdkbFIKd1V5eFpJWmVEZWNuTkFhbWh4d1NpeWF5N1AvOE9ta3NVQ3FCWmNpQ0RzZUh2dGtzbzlCSzhBZi9WemFhWm9zcApnZjYzUlZuZmNmVUlRQUN3WHhHVFhHMXJKVEVGSzhRSHA3VkpMcnpLUC9QOUxZcFlYTE0yYzZ3MmtjZUNmZitrCkU1bEVlNUJVbUNUV09UM3c4S1lPNzFLSWVuNEZJWTZMMDUrc2JGQmd1Z0ExUE5JdWFubm9UTWtlZTRuMG4rTDQKb3NCM01ZUDhtQmtRQlAzeE9JNHl3YjREZXUraURyU2pKSHJzQmlIT05Xc0RadXJFaXVJMmdoY1kxeWIyWHI2UAozVFVOcGNSbC9pVG9zQngxcHJHclk4V09HZVdPeGxZZmcvbWIvNnBuOUYvNWxlQlkrZStjSTlTMkQ0YXBKWUdpCkwxeHZzVWtGQWdNQkFBRUNnZ0VBZFhCK0xkbk8ySElOTGo5bWRsb25IUGlHWWVzZ294RGQwci9hQ1Zkank4dlEKTjIwL3FQWkUxek1yall6Ry9kVGhTMmMwc0QxaTBXSjdwR1lGb0xtdXlWTjltY0FXUTM5SjM0VHZaU2FFSWZWNgo5TE1jUHhNTmFsNjRLMFRVbUFQZytGam9QSFlhUUxLOERLOUtnNXNrSE5pOWNzMlY5ckd6VWlVZWtBL0RBUlBTClI3L2ZjUFBacDRuRWVBZmI3WTk1R1llb1p5V21SU3VKdlNyblBESGtUdW1vVlVWdkxMRHRzaG9reUxiTWVtN3oKMmJzVmpwSW1GTHJqbGtmQXlpNHg0WjJrV3YyMFRrdWtsZU1jaVlMbjk4QWxiRi9DSmRLM3QraTRoMTVlR2ZQegpoTnh3bk9QdlVTaDR2Q0o3c2Q5TmtEUGJvS2JneVVHOXBYamZhRGR2UVFLQmdRRFFLM01nUkhkQ1pKNVFqZWFKClFGdXF4cHdnNzhZTjQyL1NwenlUYmtGcVFoQWtyczJxWGx1MDZBRzhrZzIzQkswaHkzaE9zSGgxcXRVK3NHZVAKOWRERHBsUWV0ODZsY2FlR3hoc0V0L1R6cEdtNGFKSm5oNzVVaTVGZk9QTDhPTm1FZ3MxMVRhUldhNzZxelRyMgphRlpjQ2pWV1g0YnRSTHVwSkgrMjZnY0FhUUtCZ1FEQmxVSUUzTnNVOFBBZEYvL25sQVB5VWs1T3lDdWc3dmVyClUycXlrdXFzYnBkSi9hODViT1JhM05IVmpVM25uRGpHVHBWaE9JeXg5TEFrc2RwZEFjVmxvcG9HODhXYk9lMTAKMUdqbnkySmdDK3JVWUZiRGtpUGx1K09IYnRnOXFYcGJMSHBzUVpsMGhucDBYSFNYVm9CMUliQndnMGEyOFVadApCbFBtWmc2d1BRS0JnRHVIUVV2SDZHYTNDVUsxNFdmOFhIcFFnMU16M2VvWTBPQm5iSDRvZUZKZmcraEppSXlnCm9RN3hqWldVR3BIc3AyblRtcHErQWlSNzdyRVhsdlhtOElVU2FsbkNiRGlKY01Pc29RdFBZNS9NczJMRm5LQTQKaENmL0pWb2FtZm1nZEN0ZGtFMXNINE9MR2lJVHdEbTRpb0dWZGIwMllnbzFyb2htNUpLMUI3MkpBb0dBUW01UQpHNDhXOTVhL0w1eSt5dCsyZ3YvUHM2VnBvMjZlTzRNQ3lJazJVem9ZWE9IYnNkODJkaC8xT2sybGdHZlI2K3VuCnc1YytZUXRSTHlhQmd3MUtpbGhFZDBKTWU3cGpUSVpnQWJ0LzVPbnlDak9OVXN2aDJjS2lrQ1Z2dTZsZlBjNkQKckliT2ZIaHhxV0RZK2Q1TGN1YSt2NzJ0RkxhenJsSlBsRzlOZHhrQ2dZRUF5elIzT3UyMDNRVVV6bUlCRkwzZAp4Wm5XZ0JLSEo3TnNxcGFWb2RjL0d5aGVycjFDZzE2MmJaSjJDV2RsZkI0VEdtUjZZdmxTZEFOOFRwUWhFbUtKCnFBLzVzdHdxNWd0WGVLOVJmMWxXK29xNThRNTBxMmk1NVdUTThoSDZhTjlaMTltZ0FGdE5VdGNqQUx2dFYxdEYKWSs4WFJkSHJaRnBIWll2NWkwVW1VbGc9Ci0tLS0tRU5EIFBSSVZBVEUgS0VZLS0tLS0K"
现在使用文件创建 Secret：
kubectl apply -f nginxsecrets.yaml
kubectl get secrets
NAME TYPE DATA AGE
nginxsecret kubernetes.io/tls 2 1m
现在修改 Nginx 副本以启动一个使用 Secret 中的证书的 HTTPS 服务器以及相应的用于暴露其端口（80 和 443）的 Service：
apiVersion: v1
kind: Service
metadata:
name: my-nginx
labels:
run: my-nginx
spec:
type: NodePort
ports:
- port: 8080
targetPort: 80
protocol: TCP
name: http
- port: 443
protocol: TCP
name: https
selector:
run: my-nginx
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-nginx
spec:
selector:
matchLabels:
run: my-nginx
replicas: 1
template:
metadata:
labels:
run: my-nginx
spec:
volumes:
- name: secret-volume
secret:
secretName: nginxsecret
- name: configmap-volume
configMap:
name: nginxconfigmap
containers:
- name: nginxhttps
image: bprashanth/nginxhttps:1.0
ports:
- containerPort: 443
- containerPort: 80
volumeMounts:
- mountPath: /etc/nginx/ssl
name: secret-volume
- mountPath: /etc/nginx/conf.d
name: configmap-volume
关于 nginx-secure-app 清单，值得注意的几点如下：
/etc/nginx/ssl 的卷访问秘钥。卷和密钥需要在 Nginx 服务器启动 之前 配置好。kubectl delete deployments,svc my-nginx; kubectl create -f ./nginx-secure-app.yaml
这时，你可以从任何节点访问到 Nginx 服务器。
kubectl get pods -l run=my-nginx -o custom-columns=POD_IP:.status.podIPs
POD_IP
[map[ip:10.244.3.5]]
node $ curl -k https://10.244.3.5
...
<h1>Welcome to nginx!</h1>
注意最后一步我们是如何提供 -k 参数执行 curl 命令的，这是因为在证书生成时，
我们不知道任何关于运行 nginx 的 Pod 的信息，所以不得不在执行 curl 命令时忽略 CName 不匹配的情况。
通过创建 Service，我们连接了在证书中的 CName 与在 Service 查询时被 Pod 使用的实际 DNS 名字。
让我们从一个 Pod 来测试（为了方便，这里使用同一个 Secret，Pod 仅需要使用 nginx.crt 去访问 Service）：
apiVersion: apps/v1
kind: Deployment
metadata:
name: curl-deployment
spec:
selector:
matchLabels:
app: curlpod
replicas: 1
template:
metadata:
labels:
app: curlpod
spec:
volumes:
- name: secret-volume
secret:
secretName: nginxsecret
containers:
- name: curlpod
command:
- sh
- -c
- while true; do sleep 1; done
image: radial/busyboxplus:curl
volumeMounts:
- mountPath: /etc/nginx/ssl
name: secret-volume
kubectl apply -f ./curlpod.yaml
kubectl get pods -l app=curlpod
NAME READY STATUS RESTARTS AGE
curl-deployment-1515033274-1410r 1/1 Running 0 1m
kubectl exec curl-deployment-1515033274-1410r -- curl https://my-nginx --cacert /etc/nginx/ssl/tls.crt
...
<title>Welcome to nginx!</title>
...
对应用的某些部分，你可能希望将 Service 暴露在一个外部 IP 地址上。
Kubernetes 支持两种实现方式：NodePort 和 LoadBalancer。
在上一段创建的 Service 使用了 NodePort，因此，如果你的节点有一个公网
IP，那么 Nginx HTTPS 副本已经能够处理因特网上的流量。
kubectl get svc my-nginx -o yaml | grep nodePort -C 5
uid: 07191fb3-f61a-11e5-8ae5-42010af00002
spec:
clusterIP: 10.0.162.149
ports:
- name: http
nodePort: 31704
port: 8080
protocol: TCP
targetPort: 80
- name: https
nodePort: 32453
port: 443
protocol: TCP
targetPort: 443
selector:
run: my-nginx
kubectl get nodes -o yaml | grep ExternalIP -C 1
- address: 104.197.41.11
type: ExternalIP
allocatable:
--
- address: 23.251.152.56
type: ExternalIP
allocatable:
...
$ curl https://<EXTERNAL-IP>:<NODE-PORT> -k
...
<h1>Welcome to nginx!</h1>
让我们重新创建一个 Service 以使用云负载均衡器。
将 my-nginx Service 的 Type 由 NodePort 改成 LoadBalancer：
kubectl edit svc my-nginx
kubectl get svc my-nginx
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
my-nginx LoadBalancer 10.0.162.149 xx.xxx.xxx.xxx 8080:30163/TCP 21s
curl https://<EXTERNAL-IP> -k
...
<title>Welcome to nginx!</title>
在 EXTERNAL-IP 列中的 IP 地址能在公网上被访问到。CLUSTER-IP 只能从集群/私有云网络中访问。
注意，在 AWS 上，类型 LoadBalancer 的服务会创建一个 ELB，且 ELB 使用主机名（比较长），而不是 IP。
ELB 的主机名太长以至于不能适配标准 kubectl get svc 的输出，所以需要通过执行
kubectl describe service my-nginx 命令来查看它。
可以看到类似如下内容：
kubectl describe service my-nginx
...
LoadBalancer Ingress: a320587ffd19711e5a37606cf4a74574-1142138393.us-east-1.elb.amazonaws.com
...
一旦你参照使用 Service 连接到应用中概述的那些步骤使用 Service 连接到了你的应用，你就有了一个持续运行的多副本应用暴露在了网络上。 本教程帮助你了解 Pod 的终止流程，探索实现连接排空的几种方式。
你经常会遇到需要终止 Pod 的场景，例如为了升级或缩容。 为了改良应用的可用性，实现一种合适的活跃连接排空机制变得重要。
本教程将通过使用一个简单的 nginx Web 服务器演示此概念， 解释 Pod 终止的流程及其与相应端点状态和移除的联系。
以下是 Pod 终止文档中所述的流程示例。
假设你有包含单个 nginx 副本（仅用于演示目的）的一个 Deployment 和一个 Service：
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
terminationGracePeriodSeconds: 120 # 超长优雅期
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
lifecycle:
preStop:
exec:
# 实际生产环境中的 Pod 终止可能需要执行任何时长，但不会超过 terminationGracePeriodSeconds。
# 在本例中，只需挂起至少 terminationGracePeriodSeconds 所指定的持续时间，
# 在 120 秒时容器将被强制终止。
# 请注意，在所有这些时间点 nginx 都将继续处理请求。
command: [
"/bin/sh", "-c", "sleep 180"
]
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
terminationGracePeriodSeconds: 120 # 超长优雅期
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
lifecycle:
preStop:
exec:
# 实际生产环境中的 Pod 终止可能需要执行任何时长，但不会超过 terminationGracePeriodSeconds。
# 在本例中，只需挂起至少 terminationGracePeriodSeconds 所指定的持续时间，
# 在 120 秒时容器将被强制终止。
# 请注意，在所有这些时间点 nginx 都将继续处理请求。
command: [
"/bin/sh", "-c", "sleep 180"
]
---
apiVersion: v1
kind: Service
metadata:
name: nginx-service
spec:
selector:
app: nginx
ports:
- protocol: TCP
port: 80
targetPort: 80
一旦 Pod 和 Service 开始运行，你就可以获取对应的所有 EndpointSlices 的名称：
kubectl get endpointslice
输出类似于：
NAME ADDRESSTYPE PORTS ENDPOINTS AGE
nginx-service-6tjbr IPv4 80 10.12.1.199,10.12.1.201 22m
你可以查看其 status 并验证已经有一个端点被注册：
kubectl get endpointslices -o json -l kubernetes.io/service-name=nginx-service
输出类似于：
{
"addressType": "IPv4",
"apiVersion": "discovery.k8s.io/v1",
"endpoints": [
{
"addresses": [
"10.12.1.201"
],
"conditions": {
"ready": true,
"serving": true,
"terminating": false
}
}
]
}
现在让我们终止这个 Pod 并验证该 Pod 正在遵从体面终止期限的配置进行终止：
kubectl delete pod nginx-deployment-7768647bf9-b4b9s
查看所有 Pod：
kubectl get pods
输出类似于：
NAME READY STATUS RESTARTS AGE
nginx-deployment-7768647bf9-b4b9s 1/1 Terminating 0 4m1s
nginx-deployment-7768647bf9-rkxlw 1/1 Running 0 8s
你可以看到新的 Pod 已被调度。
当系统在为新的 Pod 创建新的端点时，旧的端点仍处于 Terminating 状态：
kubectl get endpointslice -o json nginx-service-6tjbr
输出类似于：
{
"addressType": "IPv4",
"apiVersion": "discovery.k8s.io/v1",
"endpoints": [
{
"addresses": [
"10.12.1.201"
],
"conditions": {
"ready": false,
"serving": true,
"terminating": true
},
"nodeName": "gke-main-default-pool-dca1511c-d17b",
"targetRef": {
"kind": "Pod",
"name": "nginx-deployment-7768647bf9-b4b9s",
"namespace": "default",
"uid": "66fa831c-7eb2-407f-bd2c-f96dfe841478"
},
"zone": "us-central1-c"
},
]
{
"addresses": [
"10.12.1.202"
],
"conditions": {
"ready": true,
"serving": true,
"terminating": false
},
"nodeName": "gke-main-default-pool-dca1511c-d17b",
"targetRef": {
"kind": "Pod",
"name": "nginx-deployment-7768647bf9-rkxlw",
"namespace": "default",
"uid": "722b1cbe-dcd7-4ed4-8928-4a4d0e2bbe35"
},
"zone": "us-central1-c"
}
}
这种设计使得应用可以在终止期间公布自己的状态，而客户端（如负载均衡器）则可以实现连接排空功能。 这些客户端可以检测到正在终止的端点，并为这些端点实现特殊的逻辑。
在 Kubernetes 中，正在终止的端点始终将其 ready 状态设置为 false。
这是为了满足向后兼容的需求，确保现有的负载均衡器不会将 Pod 用于常规流量。
如果需要排空正被终止的 Pod 上的流量，可以将 serving 状况作为实际的就绪状态。
当 Pod 被删除时，旧的端点也会被删除。