这是本节的多页打印视图。点击此处打印.

教程

1: 你好，Minikube
2: 学习 Kubernetes 基础知识

2.1: 创建集群

2.1.1: 使用 Minikube 创建集群

2.2: 部署应用

2.2.1: 使用 kubectl 创建 Deployment

2.3: 了解你的应用

2.3.1: 查看 Pod 和节点

2.4: 公开地暴露你的应用

2.4.1: 使用 Service 暴露你的应用

2.5: 扩缩你的应用

2.5.1: 运行多实例的应用

2.6: 更新你的应用

2.6.1: 执行滚动更新

3: 配置

3.1: 通过 ConfigMap 更新配置
3.2: 使用 ConfigMap 来配置 Redis
3.3: 使用边车（Sidecar）容器

4: 安全

4.1: 在集群级别应用 Pod 安全标准
4.2: 在名字空间级别应用 Pod 安全标准
4.3: 使用 AppArmor 限制容器对资源的访问
4.4: 使用 seccomp 限制容器的系统调用

5: 无状态的应用

5.1: 公开外部 IP 地址以访问集群中的应用
5.2: 示例：使用 Redis 部署 PHP 留言板应用

6: 有状态的应用

6.1: StatefulSet 基础
6.2: 示例：使用持久卷部署 WordPress 和 MySQL
6.3: 示例：使用 StatefulSet 部署 Cassandra
6.4: 运行 ZooKeeper，一个分布式协调系统

7: 集群管理

7.1: 以独立模式运行 kubelet

8: Service

8.1: 使用 Service 连接到应用
8.2: 使用源 IP
8.3: 探索 Pod 及其端点的终止行为

Kubernetes 文档的这一部分包含教程。每个教程展示了如何完成一个比单个任务更大的目标。通常一个教程有几个部分，每个部分都有一系列步骤。在浏览每个教程之前，你可能希望将标准化术语表页面添加到书签，供以后参考。

基础知识

Kubernetes 基础知识是一个深入的交互式教程，帮助你理解 Kubernetes 系统，并尝试一些基本的 Kubernetes 特性。
Kubernetes 介绍 (edX)
你好 Minikube

配置

构造 Pod

采用 Sidecar 容器

无状态应用程序

有状态应用程序

服务

安全

集群管理

以独立模式运行 kubelet

接下来

如果你要编写教程，请参阅内容页面类型以获取有关教程页面类型的信息。

1 - 你好，Minikube

本教程向你展示如何使用 Minikube 在 Kubernetes 上运行一个应用示例。教程提供了容器镜像，使用 NGINX 来对所有请求做出回应。

教程目标

将一个示例应用部署到 Minikube。
运行应用程序。
查看应用日志。

准备开始

本教程假设你已经安装了 minikube。有关安装说明，请参阅 minikube start 的步骤 1。

说明：

仅执行步骤 1：安装中的说明，其余内容均包含在本页中。

你还需要安装 kubectl。有关安装说明，请参阅安装工具。

创建 Minikube 集群

minikube start

打开仪表板

打开 Kubernetes 仪表板。你可以通过两种不同的方式执行此操作：

启动浏览器
URL 复制粘贴

打开一个新的终端，然后运行：

# 启动一个新的终端，并保持此命令运行。
minikube dashboard

现在，切换回运行 minikube start 的终端。

说明：

dashboard 命令启用仪表板插件，并在默认的 Web 浏览器中打开代理。你可以在仪表板上创建 Kubernetes 资源，例如 Deployment 和 Service。

要了解如何避免从终端直接调用浏览器并获取 Web 仪表板的 URL，请参阅 "URL 复制和粘贴"选项卡。

默认情况下，仪表板只能从内部 Kubernetes 虚拟网络中访问。 dashboard 命令创建一个临时代理，使仪表板可以从 Kubernetes 虚拟网络外部访问。

要停止代理，请运行 Ctrl+C 退出该进程。仪表板仍在运行中。命令退出后，仪表板仍然在 Kubernetes 集群中运行。你可以再次运行 dashboard 命令创建另一个代理来访问仪表板。

如果你不想 Minikube 为你打开 Web 浏览器，可以使用 --url 标志运行 dashboard 子命令。 minikube 会输出一个 URL，你可以在你喜欢的浏览器中打开该 URL。

打开一个新的终端，然后运行：

# 启动一个新的终端，并保持此命令运行。
minikube dashboard --url

现在，你可以使用此 URL 并切换回运行 minikube start 的终端。

创建 Deployment

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 可能需要一些时间才能变得可用。如果你在输出结果中看到 “0/1”，请在几秒钟后重试。）

查看 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
```

查看 Pod 中容器的应用程序日志（将 Pod 名称替换为你用 kubectl get pods 命令获得的名称）。
说明：
将 kubectl logs 命令中的 hello-node-5f76cf6ccf-br9b5 替换为 kubectl get pods 命令输出中的 Pod 名称。
```
kubectl logs hello-node-5f76cf6ccf-br9b5
```
输出类似于：
```
I0911 09:19:26.677397       1 log.go:195] Started HTTP server on port 8080
I0911 09:19:26.677586       1 log.go:195] Started UDP server on port  8081
```

说明：

有关 kubectl 命令的更多信息，请参阅 kubectl 概述。

创建 Service

默认情况下，Pod 只能通过 Kubernetes 集群中的内部 IP 地址访问。要使得 hello-node 容器可以从 Kubernetes 虚拟网络的外部访问，你必须将 Pod 通过 Kubernetes Service 公开出来。

警告：

agnhost 容器有一个 /shell 端点，对于调试很有帮助，但暴露给公共互联网很危险。请勿在面向互联网的集群或生产集群上运行它。

使用 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 的输出：

kubectl top pods

输出类似于：

NAME                         CPU(cores)   MEMORY(bytes)   
hello-node-ccf4b9788-4jn97   1m           6Mi

如果你看到以下消息，请等待并重试：

error: Metrics API not available

禁用 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。

结论

本页介绍了启动和运行 minikube 集群的基本知识，现在部署应用的准备工作已经完成。

接下来

2 - 学习 Kubernetes 基础知识

Kubernetes 基础

本教程介绍了 Kubernetes 集群编排系统的基础知识。每个模块包含关于 Kubernetes 主要特性和概念的一些背景信息，并包括一个在线互动教程。这些互动教程让你可以自己管理一个简单的集群及其容器化应用程序。

使用互动教程，你可以学习：

在集群上部署容器化应用程序
弹性部署
使用新的软件版本，更新容器化应用程序
调试容器化应用程序

这些教程使用 Katacoda 在你的浏览器中运行一个运行着 Minikube 的虚拟终端，Minikube 是 Kubernetes 的一个小规模本地部署，可以运行在任何地方。不需要安装任何软件或进行任何配置；每个交互性教程都直接从你的网页浏览器上运行。

Kubernetes 可以为你做些什么?

通过现代的 Web 服务，用户希望应用程序能够 24/7 全天候使用，开发人员希望每天可以多次发布部署新版本的应用程序。容器化可以帮助软件包达成这些目标，使应用程序能够以简单快速的方式发布和更新，而无需停机。Kubernetes 帮助你确保这些容器化的应用程序在你想要的时间和地点运行，并帮助应用程序找到它们需要的资源和工具。Kubernetes 是一个可用于生产的开源平台，根据 Google 容器集群方面积累的经验，以及来自社区的最佳实践而设计。

Kubernetes 基础模块

1. 创建一个 Kubernetes 集群

2. 部署应用程序

3. 应用程序探索

4. 应用外部可见

5. 应用可扩展

6. 应用更新

2.1 - 创建集群

了解 Kubernetes 集群并使用 Minikube 创建一个简单的集群。

2.1.1 - 使用 Minikube 创建集群

了解 Kubernetes 集群。了解 Minikube。启动一个 Kubernetes 集群。

目标

了解 Kubernetes 集群。
了解 Minikube。
在你的电脑上开启一个 Kubernetes 集群。

Kubernetes 集群

Kubernetes 协调一个高可用计算机集群，每个计算机作为独立单元互相连接工作。 Kubernetes 中的抽象允许你将容器化的应用部署到集群，而无需将它们绑定到某个特定的独立计算机。为了使用这种新的部署模型，应用需要以将应用与单个主机分离的方式打包：它们需要被容器化。与过去的那种应用直接以包的方式深度与主机集成的部署模型相比，容器化应用更灵活、更可用。 Kubernetes 以更高效的方式跨集群自动分发和调度应用容器。 Kubernetes 是一个开源平台，并且可应用于生产环境。

一个 Kubernetes 集群包含两种类型的资源：

控制面调度整个集群
节点（Nodes）负责运行应用

总结:

Kubernetes 集群
Minikube

Kubernetes 是一个生产级别的开源平台，可协调在计算机集群内和跨计算机集群的应用容器的部署（调度）和执行.

集群图

控制面负责管理整个集群。 控制面协调集群中的所有活动，例如调度应用、维护应用的所需状态、应用扩容以及推出新的更新。

节点是一个虚拟机或者物理机，它在 Kubernetes 集群中充当工作机器的角色。 每个节点都有 Kubelet，它管理节点而且是节点与控制面通信的代理。节点还应该具有用于处理容器操作的工具，例如 containerd 或 CRI-O。处理生产级流量的 Kubernetes 集群至少应具有三个节点，因为如果只有一个节点，出现故障时其对应的 etcd 成员和控制面实例都会丢失，并且冗余会受到影响。你可以通过添加更多控制面节点来降低这种风险。

控制面管理集群，节点用于托管正在运行的应用。

在 Kubernetes 上部署应用时，你告诉控制面启动应用容器。控制面就编排容器在集群的节点上运行。 节点使用控制面暴露的 Kubernetes API 与控制面通信。终端用户也可以使用 Kubernetes API 与集群交互。

Kubernetes 既可以部署在物理机上也可以部署在虚拟机上。你可以使用 Minikube 开始部署 Kubernetes 集群。 Minikube 是一种轻量级的 Kubernetes 实现，可在本地计算机上创建 VM 并部署仅包含一个节点的简单集群。 Minikube 可用于 Linux、macOS 和 Windows 系统。Minikube CLI 提供了用于引导集群工作的多种操作，包括启动、停止、查看状态和删除。

现在你已经知道 Kubernetes 是什么了，在你的电脑上访问你好 Minikube，试试。

完成这一步之后，继续使用 kubectl 创建一个 Deployment。

2.2 - 部署应用

2.2.1 - 使用 kubectl 创建 Deployment

学习应用的部署。使用 kubectl 在 Kubernetes 上部署第一个应用。

目标

学习应用的部署。
使用 kubectl 在 Kubernetes 上部署第一个应用。

Kubernetes 部署

一旦运行了 Kubernetes 集群，就可以在其上部署容器化应用。为此，你需要创建 Kubernetes Deployment。 Deployment 指挥 Kubernetes 如何创建和更新应用的实例。创建 Deployment 后，Kubernetes 控制平面将 Deployment 中包含的应用实例调度到集群中的各个节点上。

创建应用实例后，Kubernetes Deployment 控制器会持续监视这些实例。如果托管实例的节点关闭或被删除，则 Deployment 控制器会将该实例替换为集群中另一个节点上的实例。 这提供了一种自我修复机制来解决机器故障维护问题。

在没有 Kubernetes 这种编排系统之前，安装脚本通常用于启动应用，但它们不允许从机器故障中恢复。通过创建应用实例并使它们在节点之间运行，Kubernetes Deployment 提供了一种与众不同的应用管理方法。

总结：

Deployment
kubectl

Deployment 负责创建和更新应用的实例

部署你在 Kubernetes 上的第一个应用

你可以使用 Kubernetes 命令行界面 kubectl 创建和管理 Deployment。 kubectl 使用 Kubernetes API 与集群进行交互。在本单元中，你将学习创建在 Kubernetes 集群上运行应用的 Deployment 所需的最常见的 kubectl 命令。

创建 Deployment 时，你需要指定应用的容器镜像以及要运行的副本数。你可以稍后通过更新 Deployment 来更改该信息；模块 5 和 6 讨论了如何扩展和更新 Deployment。

应用需要打包成一种受支持的容器格式，以便部署在 Kubernetes 上

对于你第一次部署，你将使用打包在 Docker 容器中的 hello-node 应用，该应用使用 NGINX 回显所有请求。（如果你尚未尝试创建 hello-node 应用并使用容器进行部署，则可以首先按照 Hello Minikube 教程中的说明进行操作）。

你也需要安装好 kubectl。如果你需要安装 kubectl，参阅安装工具。

现在你已经了解了部署的内容，让我们部署第一个应用！

kubectl 基础知识

kubectl 命令的常见格式是：kubectl 操作资源

这会对指定的资源（类似 node 或 deployment）执行指定的操作（类似 create、describe 或 delete）。你可以在子命令之后使用 --help 获取可能参数相关的更多信息（例如：kubectl get nodes --help）。

通过运行 kubectl version 命令，查看 kubectl 是否被配置为与你的集群通信。

查验 kubectl 是否已安装，你能同时看到客户端和服务器版本。

要查看集群中的节点，运行 kubectl get nodes 命令。

你可以看到可用的节点。稍后 Kubernetes 将根据节点可用的资源选择在哪里部署应用。

部署一个应用

让我们使用 kubectl create deployment 命令在 Kubernetes 上部署第一个应用。我们需要提供 Deployment 命令以及应用镜像位置（包括托管在 Docker hub 之外的镜像的完整仓库地址）。

kubectl create deployment kubernetes-bootcamp --image=gcr.io/google-samples/kubernetes-bootcamp:v1

很好！你刚刚通过创建 Deployment 部署了第一个应用。这个过程中执行了以下一些操作：

搜索应用实例可以运行的合适节点（我们只有一个可用的节点）
调度应用在此节点上运行
配置集群在需要时将实例重新调度到新的节点上

要列出你的 Deployment，使用 kubectl get deployments 命令：

kubectl get deployments

我们看到有 1 个 Deployment 运行应用的单个实例。这个实例运行在节点上的一个容器内。

查看应用

在 Kubernetes 内运行的 Pod 运行在一个私有的、隔离的网络上。默认这些 Pod 可以从同一 Kubernetes 集群内的其他 Pod 和服务看到，但超出这个网络后则看不到。当我们使用 kubectl 时，我们通过 API 端点交互与应用进行通信。

在模块 4 中我们将讲述如何将应用暴露到 Kubernetes 集群外的其他选项。同样作为基础教程，我们不会在这里详细解释 Pod 是什么，后面的主题会介绍它。

kubectl proxy 命令可以创建一个代理，将通信转发到集群范围的私有网络。按下 Ctrl-C 此代理可以被终止，且在此代理运行期间不会显示任何输出。

你需要打开第二个终端窗口来运行此代理。

kubectl proxy

现在我们在主机（终端）和 Kubernetes 集群之间有一个连接。此代理能够从这些终端直接访问 API。

你可以看到通过代理端点托管的所有 API。例如，我们可以使用以下 curl 命令直接通过 API 查询版本：

curl http://localhost:8001/version

注：如果 Port 8001 不可访问，确保你上述启动的 kubectl proxy 运行在第二个终端中。

API 服务器将基于也能通过代理访问的 Pod 名称为每个 Pod 自动创建端点。

首先我们需要获取 Pod 名称，我们将存储到环境变量 POD_NAME 中：

export POD_NAME=$(kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}')
echo Name of the Pod: $POD_NAME

你可以运行以下命令通过代理的 API 访问 Pod：

curl http://localhost:8001/api/v1/namespaces/default/pods/$POD_NAME/

为了不使用代理也能访问新的 Deployment，需要一个 Service，这将在下一个模块 4 中讲述。

如果你准备好了，请访问查看 Pod 和 Node。

2.3 - 了解你的应用

2.3.1 - 查看 Pod 和节点

学习如何使用 kubectl get、kubectl describe、kubectl logs 和 kubectl exec 排除 Kubernetes 应用故障。

目标

了解 Kubernetes Pod。
了解 Kubernetes 节点。
对已部署的应用故障排除。

Kubernetes Pod

在模块 2 中创建 Deployment 时, Kubernetes 创建了一个 Pod 来托管你的应用实例。Pod 是 Kubernetes 抽象出来的，表示一组一个或多个应用容器（如 Docker），以及这些容器的一些共享资源。这些资源包括：

共享存储，当作卷
网络，作为唯一的集群 IP 地址
有关每个容器如何运行的信息，例如容器镜像版本或要使用的特定端口

Pod 为特定于应用的“逻辑主机”建模，并且可以包含相对紧耦合的不同应用容器。例如，Pod 可能既包含带有 Node.js 应用的容器，也包含另一个不同的容器，用于提供 Node.js 网络服务器要发布的数据。Pod 中的容器共享 IP 地址和端口，始终位于同一位置并且共同调度，并在同一节点上的共享上下文中运行。

Pod 是 Kubernetes 平台上的原子单元。当我们在 Kubernetes 上创建 Deployment 时，该 Deployment 会在其中创建包含容器的 Pod（而不是直接创建容器）。每个 Pod 都与调度它的节点绑定，并保持在那里直到终止（根据重启策略）或删除。如果节点发生故障，则会在集群中的其他可用节点上调度相同的 Pod。

总结：

Pod
节点
Kubectl 主要命令

Pod 是一个或多个应用容器（例如 Docker）的组合，包括共享存储（卷）、IP 地址和有关如何运行它们的信息。

Pod 概览

节点

Pod 总是运行在节点上。节点是 Kubernetes 中参与计算的机器，可以是虚拟机或物理计算机，具体取决于集群。每个节点由控制面管理。节点可以有多个 Pod，Kubernetes 控制面会自动处理在集群中的节点上调度 Pod。控制面的自动调度考量了每个节点上的可用资源。

每个 Kubernetes 节点至少运行：

Kubelet，负责 Kubernetes 控制面和节点之间通信的进程；它管理机器上运行的 Pod 和容器。
容器运行时（如 Docker）负责从镜像仓库中提取容器镜像、解压缩容器以及运行应用。

如果容器紧耦合并且需要共享磁盘等资源，则只应将其编排在一个 Pod 中。

节点概览

使用 kubectl 进行故障排除

在模块 2 中，你使用了 kubectl 命令行界面。你将继续在第 3 个模块中使用 kubectl 来获取有关已部署应用及其环境的信息。最常见的操作可以使用以下 kubectl 子命令完成：

kubectl get - 列出资源
kubectl describe - 显示有关资源的详细信息
kubectl logs - 打印 Pod 中容器的日志
kubectl exec - 在 Pod 中的容器上执行命令

你可以使用这些命令查看应用的部署时间、当前状态、运行位置以及配置。

现在我们了解了有关集群组件和命令行的更多信息，让我们来探索一下我们的应用。

节点是 Kubernetes 中负责计算的机器，可能是虚拟机或物理计算机，具体取决于集群。多个 Pod 可以在一个节点上运行。

检查应用配置

让我们验证之前场景中部署的应用是否在运行。我们将使用 kubectl get 命令查看现存的 Pod：

kubectl get pods

如果没有 Pod 在运行，请等几秒，让 Pod 再次列出。一旦看到一个 Pod 在运行，就可以继续操作。

接下来，要查看 Pod 内有哪些容器以及使用了哪些镜像来构建这些容器，我们运行 kubectl describe pods 命令：

kubectl describe pods

我们在这里看到了 Pod 的容器相关详情：IP 地址、使用的端口以及 Pod 生命期有关的事件列表。

describe 子命令的输出宽泛，涵盖了一些我们还未讲到的概念，但不用担心，这节课结束时你就会熟悉这些概念了。

注：describe子命令可用于获取有关大多数 Kubernetes 原语的详细信息，包括节点、Pod 和 Deployment。describe 的输出设计为人类可读的信息，而不是脚本化的信息。

在终端中显示应用

回想一下，Pod 运行在隔离的、私有的网络中，因此我们需要代理访问它们，这样才能进行调试和交互。为了做到这一点，我们将使用 kubectl proxy 命令在第二个终端中运行一个代理。打开一个新的终端窗口，在这个新的终端中运行以下命令：

kubectl proxy

现在我们再次获取 Pod 命令并直接通过代理查询该 Pod。要获取 Pod 命令并将其存到 POD_NAME 环境变量中，运行以下命令：

export POD_NAME="$(kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}')"
echo Name of the Pod: $POD_NAME

要查看应用的输出，运行 curl 请求：

curl http://localhost:8001/api/v1/namespaces/default/pods/$POD_NAME:8080/proxy/

URL 是到 Pod API 的路由。

查看容器日志

应用通常发送到标准输出的所有内容都成为 Pod 内容器的日志。我们可以使用 kubectl logs 命令检索这些日志：

kubectl logs "$POD_NAME"

注：我们不需要指定容器名称，因为在 Pod 内只有一个容器。

在容器上执行命令

一旦 Pod 启动并运行，我们就可以直接在容器上执行命令。为此，我们使用 exec 子命令，并将 Pod 的名称作为参数。让我们列出环境变量：

kubectl exec "$POD_NAME" -- env

另外值得一提的是，由于 Pod 中只有一个容器，所以容器本身的名称可以被省略。

接下来，让我们在 Pod 的容器中启动一个 bash 会话：

kubectl exec -ti $POD_NAME -- bash

现在我们在运行 Node.js 应用的容器上有一个打开的控制台。该应用的源代码位于 server.js 文件中：

cat server.js

你可以通过运行 curl 命令查看应用是否启动：

curl http://localhost:8080

注：在这里我们使用了 localhost，因为我们在 NodeJS Pod 内执行了此命令。如果你无法连接到 localhost:8080，请确保你已经运行了 kubectl exec 命令，并且从 Pod 内启动了该命令。

要关闭你的容器连接，键入 exit。

如果你准备好了，请继续学习使用服务来暴露你的应用。

2.4 - 公开地暴露你的应用

2.4.1 - 使用 Service 暴露你的应用

了解 Kubernetes 中的 Service。理解标签和选择算符如何关联到 Service。在 Kubernetes 集群外暴露应用。

目标

了解 Kubernetes 中的 Service
了解标签（Label）和选择算符（Selector）如何与 Service 关联
在 Kubernetes 集群外用 Service 暴露应用

Kubernetes Service 总览

Kubernetes Pod 是转瞬即逝的。 Pod 拥有生命周期。当一个工作节点挂掉后, 在节点上运行的 Pod 也会消亡。 ReplicaSet 会自动地通过创建新的 Pod 驱动集群回到目标状态，以保证应用正常运行。换一个例子，考虑一个具有 3 个副本的用作图像处理的后端程序。这些副本是可替换的。前端系统不应该关心后端副本，即使某个 Pod 丢失或被重新创建。此外，Kubernetes 集群中的每个 Pod 都有一个唯一的 IP 地址，即使是在同一个 Node 上的 Pod 也是如此，因此需要一种方法来自动协调 Pod 之间的变化，以便应用保持运行。

Kubernetes 中的服务（Service）是一种抽象概念，它定义了 Pod 的逻辑集和访问 Pod 的协议。 Service 使从属 Pod 之间的松耦合成为可能。和所有 Kubernetes 对象清单一样, Service 用 YAML 或者 JSON 来定义。 Service 下的一组 Pod 通常由一个 标签选择算符 来标记（请参阅下面的说明为什么你可能想要一个 spec 中不包含 selector 的 Service）。

尽管每个 Pod 都有一个唯一的 IP 地址，但是如果没有 Service，这些 IP 不会被公开到集群外部。 Service 允许你的应用接收流量。通过设置 Service 的 spec 中的 type，你可以用不同的方式公开 Service：

ClusterIP（默认）- 在集群的内部 IP 上公开 Service。这种类型使得 Service 只能从集群内访问。
NodePort - 使用 NAT 在集群中每个选定 Node 的相同端口上公开 Service 。使用<NodeIP>:<NodePort> 从集群外部访问 Service。是 ClusterIP 的超集。
LoadBalancer - 在当前云中创建一个外部负载均衡器（如果支持的话），并为 Service 分配一个固定的外部IP。是 NodePort 的超集。
ExternalName - 将 Service 映射到 externalName 字段的内容（例如 foo.bar.example.com），通过返回带有该名称的 CNAME 记录实现。不设置任何类型的代理。这种类型需要 kube-dns 的 v1.7 或更高版本，或者 CoreDNS 的 0.8 或更高版本。

关于不同 Service 类型的更多信息可以在使用源 IP 教程找到。也请参阅使用 Service 连接到应用。

另外，需要注意的是有一些 Service 的用例不需要在 spec 中定义 selector。一个创建时未设置 selector 的 Service 也不会创建相应的 Endpoint 对象。这允许用户手动将 Service 映射到特定的端点。没有 selector 的另一种可能是你在严格使用 type: ExternalName 服务。

总结

将 Pod 暴露给外部通信
跨多个 Pod 的负载均衡
使用标签（Label）

Kubernetes 的 Service 是一个抽象层，它定义了一组 Pod 的逻辑集，并为这些 Pod 支持外部流量暴露、负载平衡和服务发现。

Service 和 Label

Service 为一组 Pod 提供流量路由。Service 是一种抽象，允许 Kubernetes 中的 Pod 死亡和复制，而不会影响应用。在依赖的 Pod（如应用中的前端和后端组件）之间进行发现和路由是由 Kubernetes Service 处理的。

Service 通过标签和选择算符来匹配一组 Pod，它们是允许对 Kubernetes 中的对象进行逻辑操作的一种分组原语。标签是附加在对象上的键/值对，可以以多种方式使用：

指定用于开发、测试和生产的对象
嵌入版本标记
使用标记将对象分类

标签可以在对象创建时或之后附加到对象上。它们可以随时被修改。现在使用 Service 发布我们的应用并添加一些标签。

第一步：创建新 Service

让我们来验证我们的应用正在运行。我们将使用 kubectl get 命令并查找现有的 Pod：

kubectl get pods

如果没有 Pod 正在运行，则意味着之前教程中的对象已被清理。这时，请返回并参考使用 kubectl 创建 Deployment 教程重新创建 Deployment。请等待几秒钟，然后再次列举 Pod。一旦看到一个 Pod 正在运行，你就可以继续了。

接下来，让我们列举当前集群中的 Service：

kubectl get services

我们有一个名为 kubernetes 的 Service ，它在 minikube 启动集群时默认创建。要创建一个新的 Service 然后暴露给外部流量，我们将使用 expose 命令，并将 NodePort 作为参数。

kubectl expose deployment/kubernetes-bootcamp --type="NodePort" --port 8080

让我们再次运行 get services 子命令：

kubectl get services

我们现在有一个运行中的 Service 名为 kubernetes-bootcamp。这里我们看到 Service 收到了一个唯一的集群内 IP（cluster-IP），一个内部端口和一个外部 IP （external-IP）（Node 的 IP）。

要得到外部打开的端口号（对于 type: NodePort 的服务），我们需要运行 describe service 子命令：

kubectl describe services/kubernetes-bootcamp

创建一个名为 NODE_PORT 的环境变量，它的值为所分配的 Node 端口：

export NODE_PORT="$(kubectl get services/kubernetes-bootcamp -o go-template='{{(index .spec.ports 0).nodePort}}')"
echo "NODE_PORT=$NODE_PORT"

现在我们可以使用 curl、Node 的 IP 地址和对外暴露的端口，来测试应用是否已经被公开到了集群外部：

curl http://"$(minikube ip):$NODE_PORT"

说明：

如果你正在使用 Docker Desktop 作为容器驱动来运行 minikube, 需要使用 minikube tunnel。这是因为 Docker Desktop 内部的容器和宿主机是隔离的。

在另一个终端窗口中，执行：
minikube service kubernetes-bootcamp --url

输出结果如下：

http://127.0.0.1:51082
!  Because you are using a Docker driver on darwin, the terminal needs to be open to run it.

然后使用提供的 URL 访问应用：
curl 127.0.0.1:51082

然后我们就会收到服务器的响应。Service 已经被暴露。

第二步：使用标签

Deployment 自动给我们的 Pod 创建了一个标签。通过 describe deployment 子命令你可以看到那个标签的名称（对应 key）：

kubectl describe deployment

让我们使用这个标签来查询 Pod 列表。我们将使用 kubectl get pods 命令和 -l 参数，后面给出标签值：

kubectl get pods -l app=kubernetes-bootcamp

你可以用同样的方法列出现有的 Service:

kubectl get services -l app=kubernetes-bootcamp

获取 Pod 的名称，然后存放到 POD_NAME 环境变量：

export POD_NAME="$(kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}')"
echo "Name of the Pod: $POD_NAME"

要应用一个新的标签，我们使用 label 子命令，接着是对象类型、对象名称和新的标签：

kubectl label pods "$POD_NAME" version=v1

这将会在我们的 Pod 上应用一个新标签（我们把应用版本锁定到 Pod 上），然后我们可以通过 describe pods 命令检查它：

kubectl describe pods "$POD_NAME"

我们可以看到现在标签已经被附加到我们的 Pod 上。我们可以通过新的标签来查询 Pod 列表：

kubectl get pods -l version=v1

我们看到了对应的 Pod。

第三步：删除一个 Service

要删除一个 Service 你可以使用 delete service 子命令。这里也可以使用标签：

kubectl delete service -l app=kubernetes-bootcamp

确认对应的 Service 已经消失：

kubectl get services

这里确认了我们的 Service 已经被删除。要确认路由已经不再被公开，你可以 curl 之前公开的 IP 和端口：

curl http://"$(minikube ip):$NODE_PORT"

这证明了集群外部已经不再可以访问应用。你可以通过在 Pod 内部运行 curl 确认应用仍在运行：

kubectl exec -ti $POD_NAME -- curl http://localhost:8080

这里我们看到应用是运行状态。这是因为 Deployment 正在管理应用。要关闭应用，你还需要删除 Deployment。

准备好之后，继续学习运行应用的多个实例。

2.5 - 扩缩你的应用

2.5.1 - 运行多实例的应用

使用 kubectl 手动扩缩现有的应用

目标

用 kubectl 扩缩应用

扩缩应用

之前我们创建了一个 Deployment，然后通过 Service 让其可以公开访问。 Deployment 仅创建了一个 Pod 用于运行这个应用。当流量增加时，我们需要扩容应用满足用户需求。

如果你还没有学习过之前的章节，从使用 Minikube 创建集群开始。

扩缩是通过改变 Deployment 中的副本数量来实现的。

小结：

扩缩一个 Deployment

通过在使用 kubectl create deployment 命令时设置 --replicas 参数，你可以在启动 Deployment 时创建多个实例。

说明：

如果你是在上一节之后尝试此操作, 那么你可能已经删除了你创建的服务或已创建了 type: NodePort 类别的 Service。在本节中，假设为 kubernetes-bootcamp Deployment 创建了 type: LoadBalancer 类别的 Service。

如果你没有删除在前一节中创建的 Service，请先删除该 Service，然后运行以下命令来创建一个新的 type 设置为 LoadBalancer 的 Service：

kubectl expose deployment/kubernetes-bootcamp --type="LoadBalancer" --port 8080

扩缩概述

对 Deployment 横向扩容将保证新的 Pod 被创建并调度到有可用资源的 Node 上，扩容会将 Pod 数量增加至新的预期状态。 Kubernetes 还支持 Pod 的自动扩缩容，但这并不在本教程的讨论范围内。将 Pods 数量收缩到 0 也是可以的，这会终止指定 Deployment 上所有的 Pod。

运行多实例的应用，需要有方法在多个实例之间分配流量。Service 有一个集成的负载均衡器，将网络流量分配到一个可公开访问的 Deployment 的所有 Pod 上。服务将会一直通过端点来监视 Pod 的运行，保证流量只分配到可用的 Pod 上。

扩缩是通过改变 Deployment 中的副本数量来实现的。

一旦有了多个应用实例，就可以进行滚动更新而无需停机。我们将会在教程的下一节介绍这些。现在让我们进入终端，来扩缩我们的应用。

扩容 Deployment

要列出你的 Deployment，使用 get deployments 子命令：

kubectl get deployments

输出应该类似于：

NAME                  READY   UP-TO-DATE   AVAILABLE   AGE
kubernetes-bootcamp   1/1     1            1           11m

我们应该有 1 个 Pod。如果没有，请再次运行该命令。结果显示：

NAME 列出 Deployment 在集群中的名称。
READY 显示当前/预期（CURRENT/DESIRED）副本数的比例。
UP-TO-DATE 显示为了达到预期状态，而被更新的副本的数量。
AVAILABLE 显示应用有多少个副本对你的用户可用。
AGE 显示应用的运行时间。

要查看由 Deployment 创建的 ReplicaSet，运行：

kubectl get rs

注意 ReplicaSet 名称总是遵循 [DEPLOYMENT-NAME]-[RANDOM-STRING] 的格式。随机字符串是使用 pod-template-hash 作为种子随机生成的。

该输出有两个重要的列是：

DESIRED 显示了应用的预期副本数量，这是你在创建 Deployment 时定义的。这就是预期状态（desired state）。
CURRENT 显示了当前正在运行的副本数量。

接下来，让我们扩容 Deployment 到 4 个副本。我们将使用 kubectl scale 命令，后面给出 Deployment 类型、名称和预期的实例数量：

kubectl scale deployments/kubernetes-bootcamp --replicas=4

要再次列举出你的 Deployment，使用 get deployments：

kubectl get deployments

更改已应用，我们有 4 个应用实例可用。接下来，让我们检查 Pod 的数量是否发生变化：

kubectl get pods -o wide

现在有 4 个 Pod，各有不同的 IP 地址。这一变化会记录到 Deployment 的事件日志中。要检查这一点，请使用 describe 子命令：

kubectl describe deployments/kubernetes-bootcamp

你还可以从该命令的输出中看到，现在有 4 个副本。

负载均衡

让我们来检查 Service 是否在进行流量负载均衡。要查找对外公开的 IP 和端口，我们可以使用在教程之前部份学到的 describe services：

kubectl describe services/kubernetes-bootcamp

export NODE_PORT="$(kubectl get services/kubernetes-bootcamp -o go-template='{{(index .spec.ports 0).nodePort}}')"

echo NODE_PORT=$NODE_PORT

接下来，我们将使用 curl 访问对外公开的 IP 和端口。多次执行以下命令：

curl http://"$(minikube ip):$NODE_PORT"

我们每个请求都命中了不同的 Pod，这证明负载均衡正在工作。

输出应该类似于：

Hello Kubernetes bootcamp! | Running on: kubernetes-bootcamp-644c5687f4-wp67j | v=1
Hello Kubernetes bootcamp! | Running on: kubernetes-bootcamp-644c5687f4-hs9dj | v=1
Hello Kubernetes bootcamp! | Running on: kubernetes-bootcamp-644c5687f4-4hjvf | v=1
Hello Kubernetes bootcamp! | Running on: kubernetes-bootcamp-644c5687f4-wp67j | v=1
Hello Kubernetes bootcamp! | Running on: kubernetes-bootcamp-644c5687f4-4hjvf | v=1

说明：

如果你使用 Docker Desktop 作为容器驱动程序运行 minikube，则需要 minikube 隧道。这是因为 Docker Desktop 内的容器与主机隔离。

在单独的终端窗口中，执行：
minikube service kubernetes-bootcamp --url

输出看起来像这样：

http://127.0.0.1:51082
!  Because you are using a Docker driver on darwin, the terminal needs to be open to run it.

然后使用给定的 URL 访问应用： curl 127.0.0.1:51082

缩容

要将 Deployment 缩容到 2 个副本，请再次运行 scale 子命令：

kubectl scale deployments/kubernetes-bootcamp --replicas=2

要列举 Deployment 以检查是否应用了更改，使用 get deployments 子命令：

kubectl get deployments

副本数量减少到了 2 个，要列出 Pod 的数量，使用 get pods：

kubectl get pods -o wide

这证实了有 2 个 Pod 被终止。

准备好之后，继续学习执行滚动更新。

2.6 - 更新你的应用

2.6.1 - 执行滚动更新

使用 kubectl 执行滚动更新。

目标

使用 kubectl 执行滚动更新。

更新应用程序

用户希望应用程序始终可用，而开发人员则需要每天多次部署它们的新版本。在 Kubernetes 中，这些是通过滚动更新（Rolling Updates）完成的。 滚动更新 允许通过使用新的实例逐步更新 Pod 实例，实现零停机的 Deployment 更新。新的 Pod 将被调度到具有可用资源的节点上。

在前面的模块中，我们将应用程序扩展为运行多个实例。这是在不影响应用程序可用性的情况下执行更新的要求。默认情况下，更新期间不可用的 pod 的最大值和可以创建的新 pod 数都是 1。这两个选项都可以配置为（pod）数字或百分比。在 Kubernetes 中，更新是经过版本控制的，任何 Deployment 更新都可以恢复到以前的（稳定）版本。

摘要：

更新应用

滚动更新通过逐步更新 Pod 实例并替换为新的实例，从而允许在 Deployment 更新过程中实现零停机。

滚动更新概述

与应用程序扩展类似，如果 Deployment 是公开的，Service 在更新期间仅将流量负载均衡到可用的 Pod。可用的 Pod 是指应用程序对于用户可用的实例。

滚动更新允许以下操作：

将应用程序从一个环境升级到另一个环境（通过容器镜像更新）
回滚到以前的版本
持续集成和持续交付应用程序，无需停机

如果 Deployment 是公开的，Service 在更新期间仅将流量负载均衡到可用的 Pod。

在下面的交互式教程中，我们将应用程序更新为新版本，并执行回滚。

更新应用的版本

要列举 Deployment，请运行 get deployments 子命令：

kubectl get deployments

要列举运行中的 Pod，请运行 get pods 子命令：

kubectl get pods

要查看应用程序当前的版本，请运行 describe pods 子命令，然后查找 Image 字段：

kubectl describe pods

要更新应用程序的镜像版本到 v2，请使用 set image 子命令，后面给出 Deployment 名称和新的镜像版本：

kubectl set image deployments/kubernetes-bootcamp kubernetes-bootcamp=jocatalin/kubernetes-bootcamp:v2

此命令通知 Deployment 为应用程序使用不同的镜像，并启动滚动更新。要检查新 Pod 的状态，并查看旧 Pod 的终止状况，请使用 get pods 子命令：

kubectl get pods

第二步：验证更新

首先，检查应用是否正在运行。要查找应用暴露的 IP 地址和端口，请运行 describe services 子命令：

kubectl describe services/kubernetes-bootcamp

创建名为 NODE_PORT 的环境变量，值为已被分配的 Node 端口：

export NODE_PORT="$(kubectl get services/kubernetes-bootcamp -o go-template='{{(index .spec.ports 0).nodePort}}')"
echo "NODE_PORT=$NODE_PORT"

接下来，针对所暴露的 IP 和端口执行 curl：

curl http://"$(minikube ip):$NODE_PORT"

你每次执行 curl 命令，都会命中不同的 Pod。注意现在所有的 Pod 都运行着最新版本（v2）。

你也可以通过运行 rollout status 来确认此次更新：

kubectl rollout status deployments/kubernetes-bootcamp

要查看应用程序当前的镜像版本，请运行 describe pods 子命令：

kubectl describe pods

在输出的 Image 字段，确认你正在运行最新的版本（v2）。

回滚更新

让我们执行另一次更新，并尝试部署一个标记为 v10 的镜像：

kubectl set image deployments/kubernetes-bootcamp kubernetes-bootcamp=gcr.io/google-samples/kubernetes-bootcamp:v10

使用 get deployments 来查看 Deployment 的状态：

kubectl get deployments

注意，这里的输出列出的可用 Pod 数量不符合预期。运行 get pods 子命令来列举所有的 Pod：

kubectl get pods

注意此处部分 Pod 的状态是 ImagePullBackOff。

要深入了解此问题，请运行 describe pods 子命令：

kubectl describe pods

在受影响的 Pod 的 Events 部分，可以注意到镜像的 v10 版本在仓库中不存在。

要回滚 Deployment 到上一个工作的版本，请使用 rollout undo 子命令：

kubectl rollout undo deployments/kubernetes-bootcamp

rollout undo 命令会恢复 Deployment 到先前的已知状态（v2 的镜像）。更新是受版本控制的，你可以恢复 Deployment 到任何先前已知状态。

使用 get pods 子命令再次列举 Pod：

kubectl get pods

有四个 Pod 正在运行。要检查这些 Pod 部署的镜像，请使用 describe pods 子命令：

kubectl describe pods

Deployment 再次使用了稳定版本的应用程序（v2）。回滚成功。

记得清理本地集群：

kubectl delete deployments/kubernetes-bootcamp services/kubernetes-bootcamp

3 - 配置

3.1 - 通过 ConfigMap 更新配置

本页提供了通过 ConfigMap 更新 Pod 中配置信息的分步示例，本教程的前置任务是配置 Pod 以使用 ConfigMap。
在本教程结束时，你将了解如何变更运行中应用的配置。本教程以 alpine 和 nginx 镜像为例。

准备开始

你必须拥有一个 Kubernetes 的集群，且必须配置 kubectl 命令行工具让其与你的集群通信。建议运行本教程的集群至少有两个节点，且这两个节点不能作为控制平面主机。如果你还没有集群，你可以通过 Minikube 构建一个你自己的集群，或者你可以使用下面的 Kubernetes 练习环境之一：

你需要有 curl 命令行工具，用于从终端或命令行界面发出 HTTP 请求。如果你没有 curl，可以安装此工具。请查阅你本地操作系统的文档。

教程目标

通过作为卷挂载的 ConfigMap 更新配置
通过 ConfigMap 更新 Pod 的环境变量
在多容器 Pod 中通过 ConfigMap 更新配置
在包含边车容器的 Pod 中通过 ConfigMap 更新配置

通过作为卷挂载的 ConfigMap 更新配置

使用 kubectl create configmap 命令基于字面值创建一个 ConfigMap：

kubectl create configmap sport --from-literal=sport=football

下面是一个 Deployment 清单示例，其中 ConfigMap sport 作为卷挂载到 Pod 的唯一容器中。

deployments/deployment-with-configmap-as-volume.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: configmap-volume
  labels:
    app.kubernetes.io/name: configmap-volume
spec:
  replicas: 3
  selector:
    matchLabels:
      app.kubernetes.io/name: configmap-volume
  template:
    metadata:
      labels:
        app.kubernetes.io/name: configmap-volume
    spec:
      containers:
        - name: alpine
          image: alpine:3
          command:
            - /bin/sh
            - -c
            - while true; do echo "$(date) My preferred sport is $(cat /etc/config/sport)";
              sleep 10; done;
          ports:
            - containerPort: 80
          volumeMounts:
            - name: config-volume
              mountPath: /etc/config
      volumes:
        - name: config-volume
          configMap:
            name: sport

创建此 Deployment：

kubectl apply -f https://k8s.io/examples/deployments/deployment-with-configmap-as-volume.yaml

检查此 Deployment 的 Pod 以确保它们已就绪（通过选择算符进行匹配）：

kubectl get pods --selector=app.kubernetes.io/name=configmap-volume

你应该会看到类似以下的输出：

NAME                                READY   STATUS    RESTARTS   AGE
configmap-volume-6b976dfdcf-qxvbm   1/1     Running   0          72s
configmap-volume-6b976dfdcf-skpvm   1/1     Running   0          72s
configmap-volume-6b976dfdcf-tbc6r   1/1     Running   0          72s

在运行这些 Pod 之一的每个节点上，kubelet 获取该 ConfigMap 的数据，并将其转换为本地卷中的文件。然后，kubelet 按照 Pod 模板中指定的方式将该卷挂载到容器中。在该容器中运行的代码从文件中加载信息，并使用它将报告打印到标准输出。你可以通过查看该 Deployment 中其中一个 Pod 的日志来检查此报告：

# 选择一个属于该 Deployment 的 Pod，并查看其日志
kubectl logs deployments/configmap-volume

你应该会看到类似以下的输出：

Found 3 pods, using pod/configmap-volume-76d9c5678f-x5rgj
Thu Jan  4 14:06:46 UTC 2024 My preferred sport is football
Thu Jan  4 14:06:56 UTC 2024 My preferred sport is football
Thu Jan  4 14:07:06 UTC 2024 My preferred sport is football
Thu Jan  4 14:07:16 UTC 2024 My preferred sport is football
Thu Jan  4 14:07:26 UTC 2024 My preferred sport is football

编辑 ConfigMap：

kubectl edit configmap sport

在出现的编辑器中，将键 sport 的值从 football 变更为 cricket。保存你的变更。kubectl 工具会相应地更新 ConfigMap（如果报错，请重试）。

以下是你编辑后该清单可能的样子：

apiVersion: v1
data:
  sport: cricket
kind: ConfigMap
# 你可以保留现有的 metadata 不变。
# 你将看到的值与本例的值不会完全一样。
metadata:
  creationTimestamp: "2024-01-04T14:05:06Z"
  name: sport
  namespace: default
  resourceVersion: "1743935"
  uid: 024ee001-fe72-487e-872e-34d6464a8a23

你应该会看到以下输出：

configmap/sport edited

查看属于此 Deployment 的 Pod 之一的日志（并跟踪最新写入的条目）：

kubectl logs deployments/configmap-volume --follow

几秒钟后，你应该会看到日志输出中的如下变化：

Thu Jan  4 14:11:36 UTC 2024 My preferred sport is football
Thu Jan  4 14:11:46 UTC 2024 My preferred sport is football
Thu Jan  4 14:11:56 UTC 2024 My preferred sport is football
Thu Jan  4 14:12:06 UTC 2024 My preferred sport is cricket
Thu Jan  4 14:12:16 UTC 2024 My preferred sport is cricket

当你有一个 ConfigMap 通过 configMap 卷或 projected 卷映射到运行中的 Pod，并且你更新了该 ConfigMap 时，运行中的 Pod 几乎会立即更新。
但是，你的应用只有在编写为轮询变更或监视文件更新时才能看到变更。
启动时一次性加载其配置的应用将不会注意到变更。

说明：

从更新 ConfigMap 的那一刻到将新的键投射到 Pod 的那一刻，整个延迟可能与 kubelet 同步周期相同。另请参阅挂载的 ConfigMap 会被自动更新。

通过 ConfigMap 更新 Pod 的环境变量

使用 kubectl create configmap 命令基于字面值创建一个 ConfigMap：

kubectl create configmap fruits --from-literal=fruits=apples

下面是一个 Deployment 清单的示例，包含一个通过 ConfigMap fruits 配置的环境变量。

deployments/deployment-with-configmap-as-envvar.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: configmap-env-var
  labels:
    app.kubernetes.io/name: configmap-env-var
spec:
  replicas: 3
  selector:
    matchLabels:
      app.kubernetes.io/name: configmap-env-var
  template:
    metadata:
      labels:
        app.kubernetes.io/name: configmap-env-var
    spec:
      containers:
        - name: alpine
          image: alpine:3
          env:
            - name: FRUITS
              valueFrom:
                configMapKeyRef:
                  key: fruits
                  name: fruits
          command:
            - /bin/sh
            - -c
            - while true; do echo "$(date) The basket is full of $FRUITS";
                sleep 10; done;
          ports:
            - containerPort: 80

创建此 Deployment：

kubectl apply -f https://k8s.io/examples/deployments/deployment-with-configmap-as-envvar.yaml

检查此 Deployment 的 Pod 以确保它们已就绪（通过选择算符进行匹配）：

kubectl get pods --selector=app.kubernetes.io/name=configmap-env-var

你应该会看到类似以下的输出：

NAME                                 READY   STATUS    RESTARTS   AGE
configmap-env-var-59cfc64f7d-74d7z   1/1     Running   0          46s
configmap-env-var-59cfc64f7d-c4wmj   1/1     Running   0          46s
configmap-env-var-59cfc64f7d-dpr98   1/1     Running   0          46s

ConfigMap 中的键值对被配置为 Pod 容器中的环境变量。通过查看属于该 Deployment 的某个 Pod 的日志来检查这一点。

kubectl logs deployment/configmap-env-var

你应该会看到类似以下的输出：

Found 3 pods, using pod/configmap-env-var-7c994f7769-l74nq
Thu Jan  4 16:07:06 UTC 2024 The basket is full of apples
Thu Jan  4 16:07:16 UTC 2024 The basket is full of apples
Thu Jan  4 16:07:26 UTC 2024 The basket is full of apples

编辑 ConfigMap：

kubectl edit configmap fruits

在出现的编辑器中，将键 fruits 的值从 apples 变更为 mangoes。保存你的变更。kubectl 工具会相应地更新 ConfigMap（如果报错，请重试）。

以下是你编辑后该清单可能的样子：

apiVersion: v1
data:
  fruits: mangoes
kind: ConfigMap
# 你可以保留现有的 metadata 不变。
# 你将看到的值与本例的值不会完全一样。
metadata:
  creationTimestamp: "2024-01-04T16:04:19Z"
  name: fruits
  namespace: default
  resourceVersion: "1749472"

你应该看到以下输出：

configmap/fruits edited

查看此 Deployment 的日志，并观察几秒钟的输出：

# 如上所述，输出不会有变化
kubectl logs deployments/configmap-env-var --follow

请注意，即使你编辑了 ConfigMap，输出仍然没有变化：

Thu Jan  4 16:12:56 UTC 2024 The basket is full of apples
Thu Jan  4 16:13:06 UTC 2024 The basket is full of apples
Thu Jan  4 16:13:16 UTC 2024 The basket is full of apples
Thu Jan  4 16:13:26 UTC 2024 The basket is full of apples

说明：

尽管 ConfigMap 中的键的取值已经变更，Pod 中的环境变量仍然显示先前的值。这是因为当源数据变更时，在 Pod 内运行的进程的环境变量不会被更新；如果你想强制更新，需要让 Kubernetes 替换现有的 Pod。新 Pod 将使用更新的信息来运行。

你可以触发该替换。使用 kubectl rollout 为 Deployment 执行上线操作：

# 触发上线操作
kubectl rollout restart deployment configmap-env-var

# 等待上线操作完成
kubectl rollout status deployment configmap-env-var --watch=true

接下来，检查 Deployment：

kubectl get deployment configmap-env-var

你应该会看到类似以下的输出：

NAME                READY   UP-TO-DATE   AVAILABLE   AGE
configmap-env-var   3/3     3            3           12m

检查 Pod：

kubectl get pods --selector=app.kubernetes.io/name=configmap-env-var

上线操作会导致 Kubernetes 为 Deployment 新建一个 ReplicaSet；这意味着现有的 Pod 最终会终止，并创建新的 Pod。几秒钟后，你应该会看到类似以下的输出：

NAME                                 READY   STATUS        RESTARTS   AGE
configmap-env-var-6d94d89bf5-2ph2l   1/1     Running       0          13s
configmap-env-var-6d94d89bf5-74twx   1/1     Running       0          8s
configmap-env-var-6d94d89bf5-d5vx8   1/1     Running       0          11s

说明：

请等待旧的 Pod 完全终止后再进行下一步。

查看此 Deployment 中某个 Pod 的日志：

# 选择属于 Deployment 的一个 Pod，并查看其日志
kubectl logs deployment/configmap-env-var

你应该会看到类似以下的输出：

Found 3 pods, using pod/configmap-env-var-6d9ff89fb6-bzcf6
Thu Jan  4 16:30:35 UTC 2024 The basket is full of mangoes
Thu Jan  4 16:30:45 UTC 2024 The basket is full of mangoes
Thu Jan  4 16:30:55 UTC 2024 The basket is full of mangoes

这个场景演示了在 Pod 中如何更新从 ConfigMap 派生的环境变量。ConfigMap 值的变更在随后的上线操作期间被应用到 Pod。如果 Pod 由于其他原因（例如 Deployment 扩容）被创建，那么新 Pod 也会使用最新的配置值；如果你不触发上线操作，你可能会发现你的应用在运行过程中混用了新旧环境变量值。

在多容器 Pod 中通过 ConfigMap 更新配置

使用 kubectl create configmap 命令基于字面值创建一个 ConfigMap：

kubectl create configmap color --from-literal=color=red

下面是一个 Deployment 清单的示例，该 Deployment 管理一组 Pod，每个 Pod 有两个容器。这两个容器共享一个 emptyDir 卷并使用此卷进行通信。第一个容器运行 Web 服务器（nginx）。在 Web 服务器容器中共享卷的挂载路径是 /usr/share/nginx/html。第二个辅助容器基于 alpine，对于这个容器，emptyDir 卷被挂载在 /pod-data。辅助容器生成一个 HTML 文件，其内容基于 ConfigMap。Web 服务器容器通过 HTTP 提供此 HTML 文件。

deployments/deployment-with-configmap-two-containers.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: configmap-two-containers
  labels:
    app.kubernetes.io/name: configmap-two-containers
spec:
  replicas: 3
  selector:
    matchLabels:
      app.kubernetes.io/name: configmap-two-containers
  template:
    metadata:
      labels:
        app.kubernetes.io/name: configmap-two-containers
    spec:
      volumes:
        - name: shared-data
          emptyDir: {}
        - name: config-volume
          configMap:
            name: color
      containers:
        - name: nginx
          image: nginx
          volumeMounts:
            - name: shared-data
              mountPath: /usr/share/nginx/html
        - name: alpine
          image: alpine:3
          volumeMounts:
            - name: shared-data
              mountPath: /pod-data
            - name: config-volume
              mountPath: /etc/config
          command:
            - /bin/sh
            - -c
            - while true; do echo "$(date) My preferred color is $(cat /etc/config/color)" > /pod-data/index.html;
              sleep 10; done;

创建此 Deployment：

kubectl apply -f https://k8s.io/examples/deployments/deployment-with-configmap-two-containers.yaml

检查此 Deployment 的 Pod 以确保它们已就绪（通过选择算符进行匹配）：

kubectl get pods --selector=app.kubernetes.io/name=configmap-two-containers

你应该会看到类似以下的输出：

NAME                                        READY   STATUS    RESTARTS   AGE
configmap-two-containers-565fb6d4f4-2xhxf   2/2     Running   0          20s
configmap-two-containers-565fb6d4f4-g5v4j   2/2     Running   0          20s
configmap-two-containers-565fb6d4f4-mzsmf   2/2     Running   0          20s

公开 Deployment（kubectl 工具会为你创建 Service）：

kubectl expose deployment configmap-two-containers --name=configmap-service --port=8080 --target-port=80

使用 kubectl 转发端口：

# 此命令将在后台运行
kubectl port-forward service/configmap-service 8080:8080 &

访问服务：

curl http://localhost:8080

你应该会看到类似以下的输出：

Fri Jan  5 08:08:22 UTC 2024 My preferred color is red

编辑 ConfigMap：

kubectl edit configmap color

在出现的编辑器中，将键 color 的值从 red 变更为 blue。保存你的变更。kubectl 工具会相应地更新 ConfigMap（如果报错，请重试）。

以下是你编辑后该清单可能的样子：

apiVersion: v1
data:
  color: blue
kind: ConfigMap
# 你可以保留现有的 metadata 不变。
# 你将看到的值与本例的值不会完全一样。
metadata:
  creationTimestamp: "2024-01-05T08:12:05Z"
  name: color
  namespace: configmap
  resourceVersion: "1801272"
  uid: 80d33e4a-cbb4-4bc9-ba8c-544c68e425d6

循环访问服务 URL 几秒钟。

# 当你满意时可以取消此操作 (Ctrl-C)
while true; do curl --connect-timeout 7.5 http://localhost:8080; sleep 10; done

你应该会看到如下的输出变化：

Fri Jan  5 08:14:00 UTC 2024 My preferred color is red
Fri Jan  5 08:14:02 UTC 2024 My preferred color is red
Fri Jan  5 08:14:20 UTC 2024 My preferred color is red
Fri Jan  5 08:14:22 UTC 2024 My preferred color is red
Fri Jan  5 08:14:32 UTC 2024 My preferred color is blue
Fri Jan  5 08:14:43 UTC 2024 My preferred color is blue
Fri Jan  5 08:15:00 UTC 2024 My preferred color is blue

在包含边车容器的 Pod 中通过 ConfigMap 更新配置

要重现上述场景，可以使用边车容器作为辅助容器来写入 HTML 文件。
由于边车容器在概念上是一个 Init 容器，因此保证会在主要 Web 服务器容器启动之前启动。
这确保了当 Web 服务器准备好提供服务时，HTML 文件始终可用。
请参阅启用边车容器以使用此特性。

如果你从前一个场景继续操作，你可以在此场景中重用名为 color 的 ConfigMap。
如果你是独立执行此场景，请使用 kubectl create configmap 命令基于字面值创建一个 ConfigMap：

kubectl create configmap color --from-literal=color=blue

以下是一个 Deployment 清单示例，该 Deployment 管理一组 Pod，每个 Pod 有一个主容器和一个边车容器。这两个容器共享一个 emptyDir 卷并使用此卷来通信。主容器运行 Web 服务器（NGINX）。在 Web 服务器容器中共享卷的挂载路径是 /usr/share/nginx/html。第二个容器是基于 Alpine Linux 作为辅助容器的边车容器。对于这个辅助容器，emptyDir 卷被挂载在 /pod-data。边车容器写入一个 HTML 文件，其内容基于 ConfigMap。Web 服务器容器通过 HTTP 提供此 HTML 文件。

deployments/deployment-with-configmap-and-sidecar-container.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: configmap-sidecar-container
  labels:
    app.kubernetes.io/name: configmap-sidecar-container
spec:
  replicas: 3
  selector:
    matchLabels:
      app.kubernetes.io/name: configmap-sidecar-container
  template:
    metadata:
      labels:
        app.kubernetes.io/name: configmap-sidecar-container
    spec:
      volumes:
        - name: shared-data
          emptyDir: {}
        - name: config-volume
          configMap:
            name: color
      containers:
        - name: nginx
          image: nginx
          volumeMounts:
            - name: shared-data
              mountPath: /usr/share/nginx/html
      initContainers:
        - name: alpine
          image: alpine:3
          restartPolicy: Always
          volumeMounts:
            - name: shared-data
              mountPath: /pod-data
            - name: config-volume
              mountPath: /etc/config
          command:
            - /bin/sh
            - -c
            - while true; do echo "$(date) My preferred color is $(cat /etc/config/color)" > /pod-data/index.html;
              sleep 10; done;

创建此 Deployment：

kubectl apply -f https://k8s.io/examples/deployments/deployment-with-configmap-and-sidecar-container.yaml

检查此 Deployment 的 Pod 以确保它们已就绪（通过选择算符进行匹配）：

kubectl get pods --selector=app.kubernetes.io/name=configmap-sidecar-container

你应该会看到类似以下的输出：

NAME                                           READY   STATUS    RESTARTS   AGE
configmap-sidecar-container-5fb59f558b-87rp7   2/2     Running   0          94s
configmap-sidecar-container-5fb59f558b-ccs7s   2/2     Running   0          94s
configmap-sidecar-container-5fb59f558b-wnmgk   2/2     Running   0          94s

公开 Deployment（kubectl 工具会为你创建一个 Service）：

kubectl expose deployment configmap-sidecar-container --name=configmap-sidecar-service --port=8081 --target-port=80

使用 kubectl 转发端口：

# 此命令将在后台运行
kubectl port-forward service/configmap-sidecar-service 8081:80 &

访问服务：

curl http://localhost:8081

你应该看到类似以下的输出：

Sat Feb 17 13:09:05 UTC 2024 My preferred color is blue

编辑 ConfigMap：

kubectl edit configmap color

在出现的编辑器中，将键 color 的值从 blue 变更为 green。保存你的变更。kubectl 工具会相应地更新 ConfigMap（如果报错，请重试）。

以下是你编辑后该清单可能的样子：

apiVersion: v1
data:
  color: green
kind: ConfigMap
# 你可以保留现有的 metadata 不变。
# 你将看到的值与本例的值不会完全一样。
metadata:
  creationTimestamp: "2024-02-17T12:20:30Z"
  name: color
  namespace: default
  resourceVersion: "1054"
  uid: e40bb34c-58df-4280-8bea-6ed16edccfaa

循环访问服务 URL 几秒钟。

# 当你满意时可以取消此操作 (Ctrl-C)
while true; do curl --connect-timeout 7.5 http://localhost:8081; sleep 10; done

你应该会看到如下的输出变化：

Sat Feb 17 13:12:35 UTC 2024 My preferred color is blue
Sat Feb 17 13:12:45 UTC 2024 My preferred color is blue
Sat Feb 17 13:12:55 UTC 2024 My preferred color is blue
Sat Feb 17 13:13:05 UTC 2024 My preferred color is blue
Sat Feb 17 13:13:15 UTC 2024 My preferred color is green
Sat Feb 17 13:13:25 UTC 2024 My preferred color is green
Sat Feb 17 13:13:35 UTC 2024 My preferred color is green

通过作为卷挂载的不可变 ConfigMap 更新配置

说明：

不可变 ConfigMap 专门用于恒定且预期不会随时间变化的配置。将 ConfigMap 标记为不可变可以提高性能，因为 kubelet 不会监视变更。

如果你确实需要进行变更，你应计划：

变更 ConfigMap 的名称，并转而运行引用新名称的 Pod
替换集群中之前运行使用旧值的 Pod 的所有节点
在任何之前加载过旧 ConfigMap 的节点上重新启动 kubelet

以下是一个不可变 ConfigMap的示例清单。

configmap/immutable-configmap.yaml

apiVersion: v1
data:
  company_name: "ACME, Inc." # 虚构的公司名称
kind: ConfigMap
immutable: true
metadata:
  name: company-name-20150801

创建不可变 ConfigMap：

kubectl apply -f https://k8s.io/examples/configmap/immutable-configmap.yaml

下面是一个 Deployment 清单示例，其中不可变 ConfigMap company-name-20150801 作为卷挂载到 Pod 的唯一容器中。

deployments/deployment-with-immutable-configmap-as-volume.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: immutable-configmap-volume
  labels:
    app.kubernetes.io/name: immutable-configmap-volume
spec:
  replicas: 3
  selector:
    matchLabels:
      app.kubernetes.io/name: immutable-configmap-volume
  template:
    metadata:
      labels:
        app.kubernetes.io/name: immutable-configmap-volume
    spec:
      containers:
        - name: alpine
          image: alpine:3
          command:
            - /bin/sh
            - -c
            - while true; do echo "$(date) The name of the company is $(cat /etc/config/company_name)";
              sleep 10; done;
          ports:
            - containerPort: 80
          volumeMounts:
            - name: config-volume
              mountPath: /etc/config
      volumes:
        - name: config-volume
          configMap:
            name: company-name-20150801

创建此 Deployment：

kubectl apply -f https://k8s.io/examples/deployments/deployment-with-immutable-configmap-as-volume.yaml

检查此 Deployment 的 Pod 以确保它们已就绪（通过选择算符进行匹配）：

kubectl get pods --selector=app.kubernetes.io/name=immutable-configmap-volume

你应该看到类似以下的输出：

NAME                                          READY   STATUS    RESTARTS   AGE
immutable-configmap-volume-78b6fbff95-5gsfh   1/1     Running   0          62s
immutable-configmap-volume-78b6fbff95-7vcj4   1/1     Running   0          62s
immutable-configmap-volume-78b6fbff95-vdslm   1/1     Running   0          62s

Pod 的容器引用 ConfigMap 中所定义的数据，并使用它将报告打印到标准输出。你可以通过查看 Deployment 中某个 Pod 的日志来检查此报告：

# 选择属于该 Deployment 的一个 Pod，并查看其日志
kubectl logs deployments/immutable-configmap-volume

你应该会看到类似以下的输出：

Found 3 pods, using pod/immutable-configmap-volume-78b6fbff95-5gsfh
Wed Mar 20 03:52:34 UTC 2024 The name of the company is ACME, Inc.
Wed Mar 20 03:52:44 UTC 2024 The name of the company is ACME, Inc.
Wed Mar 20 03:52:54 UTC 2024 The name of the company is ACME, Inc.

说明：

一旦 ConfigMap 被标记为不可变，就无法撤销此变更，也无法修改 data 或 binaryData 字段的内容。
为了修改使用此配置的 Pod 的行为，你需要创建一个新的不可变 ConfigMap，并编辑 Deployment 以定义一个稍有不同的 Pod 模板，引用新的 ConfigMap。

通过使用下面所示的清单创建一个新的不可变 ConfigMap：

configmap/new-immutable-configmap.yaml

apiVersion: v1
data:
  company_name: "Fiktivesunternehmen GmbH" # 虚构的公司名称
kind: ConfigMap
immutable: true
metadata:
  name: company-name-20240312

kubectl apply -f https://k8s.io/examples/configmap/new-immutable-configmap.yaml

你应该看到类似以下的输出：

configmap/company-name-20240312 created

检查新建的 ConfigMap：

kubectl get configmap

你应该看到输出会同时显示新旧 ConfigMap：

NAME                    DATA   AGE
company-name-20150801   1      22m
company-name-20240312   1      24s

修改 Deployment 以引用新的 ConfigMap。

编辑 Deployment：

kubectl edit deployment immutable-configmap-volume

在出现的编辑器中，更新现有的卷定义以使用新的 ConfigMap。

volumes:
- configMap:
    defaultMode: 420
    name: company-name-20240312 # 更新此字段
  name: config-volume

你应该看到以下输出：

deployment.apps/immutable-configmap-volume edited

这将触发一次上线操作。等待所有先前的 Pod 终止并且新的 Pod 处于就绪状态。

监控 Pod 的状态：

kubectl get pods --selector=app.kubernetes.io/name=immutable-configmap-volume

NAME                                          READY   STATUS        RESTARTS   AGE
immutable-configmap-volume-5fdb88fcc8-29v8n   1/1     Running       0          13s
immutable-configmap-volume-5fdb88fcc8-52ddd   1/1     Running       0          14s
immutable-configmap-volume-5fdb88fcc8-n5jx4   1/1     Running       0          15s
immutable-configmap-volume-78b6fbff95-5gsfh   1/1     Terminating   0          32m
immutable-configmap-volume-78b6fbff95-7vcj4   1/1     Terminating   0          32m
immutable-configmap-volume-78b6fbff95-vdslm   1/1     Terminating   0          32m

最终，你应该会看到类似以下的输出：

NAME                                          READY   STATUS    RESTARTS   AGE
immutable-configmap-volume-5fdb88fcc8-29v8n   1/1     Running   0          43s
immutable-configmap-volume-5fdb88fcc8-52ddd   1/1     Running   0          44s
immutable-configmap-volume-5fdb88fcc8-n5jx4   1/1     Running   0          45s

查看此 Deployment 中某个 Pod 的日志：

# 选择属于此 Deployment 的一个 Pod，并查看其日志
kubectl logs deployment/immutable-configmap-volume

你应该会看到类似下面的输出：

Found 3 pods, using pod/immutable-configmap-volume-5fdb88fcc8-n5jx4
Wed Mar 20 04:24:17 UTC 2024 The name of the company is Fiktivesunternehmen GmbH
Wed Mar 20 04:24:27 UTC 2024 The name of the company is Fiktivesunternehmen GmbH
Wed Mar 20 04:24:37 UTC 2024 The name of the company is Fiktivesunternehmen GmbH

建议一旦所有 Deployment 都迁移到使用新的不可变 ConfigMap，删除旧的 ConfigMap。

kubectl delete configmap company-name-20150801

总结

在 Pod 上作为卷挂载的 ConfigMap 所发生的变更将在后续的 kubelet 同步后无缝生效。

配置为 Pod 环境变量的 ConfigMap 所发生变更将在后续的 Pod 上线操作后生效。

一旦 ConfigMap 被标记为不可变，就无法撤销此变更（你不能将不可变的 ConfigMap 改为可变），并且你也不能对 data 或 binaryData 字段的内容进行任何变更。你可以删除并重新创建 ConfigMap，或者你可以创建一个新的不同的 ConfigMap。当你删除 ConfigMap 时，运行中的容器及其 Pod 将保持对引用了现有 ConfigMap 的任何卷的挂载点。

清理现场

终止正在运行的 kubectl port-forward 命令。

删除以上教程中所创建的资源：

kubectl delete deployment configmap-volume configmap-env-var configmap-two-containers configmap-sidecar-container immutable-configmap-volume
kubectl delete service configmap-service configmap-sidecar-service
kubectl delete configmap sport fruits color company-name-20240312

kubectl delete configmap company-name-20150801 # 如果在任务执行期间未被处理

3.2 - 使用 ConfigMap 来配置 Redis

这篇文档基于配置 Pod 以使用 ConfigMap 这个任务，提供了一个使用 ConfigMap 来配置 Redis 的真实案例。

教程目标

使用 Redis 配置的值创建一个 ConfigMap
创建一个 Redis Pod，挂载并使用创建的 ConfigMap
验证配置已经被正确应用

准备开始

要获知版本信息，请输入 kubectl version.

此页面上显示的示例适用于 kubectl 1.14 及以上的版本。
理解配置 Pod 以使用 ConfigMap。

真实世界的案例：使用 ConfigMap 来配置 Redis

按照下面的步骤，使用 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].configMap.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 公开。

pods/config/redis-pod.yaml

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 添加一些配置：

pods/config/example-redis-config.yaml

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

接下来

了解有关 ConfigMap 的更多信息。
学习通过 ConfigMap 更新配置的示例。

3.3 - 使用边车（Sidecar）容器

本文适用于使用新的内置边车容器特性的用户。

边车容器并不是一个新概念，正如在博客文章中所提到的那样。 Kubernetes 允许在一个 Pod 中运行多个容器来实现这一概念。然而，作为一个普通容器运行边车容器存在许多限制，这些限制通过新的内置边车容器支持得到了解决。

特性状态： Kubernetes v1.29 [beta] (enabled by default: true)

教程目标

理解边车容器的需求
能够排查边车容器的问题
了解如何"注入"边车容器到任意的工作负载中

准备开始

你的 Kubernetes 服务器版本必须不低于版本 1.29. 要获知版本信息，请输入 kubectl version.

边车容器概述

边车容器是与主应用程序容器在同一 Pod 内一起运行的辅助容器。这些容器通过提供额外的服务或功能（如日志记录、监控、安全或数据同步）来增强或扩展主应用容器的功能，而无需直接修改主应用程序代码。你可以在边车容器概念页面中阅读更多相关内容。

边车容器的概念并不新鲜，有许多不同的实现方式。除了你（定义 Pod 的人）希望运行的边车容器外，一些插件也会在 Pod 开始运行之前对其进行修改，以添加额外的边车容器。这些额外边车容器的注入机制通常是变更 Webhook（Mutating Webhook）。例如，服务网格插件可能会注入一个配置双向 TLS（Mutual TLS）和传输中加密的边车容器。

虽然边车容器的概念并不新鲜，但 Kubernetes 对这一特性的原生实现却是新的。与每一项新特性一样，采用这一特性可能会带来某些挑战。

本教程探讨了终端用户和边车容器作者可能遇到的挑战及其解决方案。

内置边车容器的优势

使用 Kubernetes 对边车容器的原生支持可以带来以下几个好处：

你可以配置原生边车容器在 Init 容器之前启动。
内置边车容器可以编写为确保它们最后终止。一旦所有常规容器完成并终止，边车容器将接收到 SIGTERM 信号。如果边车容器未能体面关闭，系统将使用 SIGKILL 信号终止它。
在 Job 中，当 Pod 配置 restartPolicy: OnFailure 或 restartPolicy: Never 时，原生边车容器不会阻止 Pod 完成。而对于传统边车容器，需要特别处理这种情况。
同样在 Job 中，即使 Pod 的 restartPolicy: Never 时常规容器不会重启，内置边车容器仍会在完成后继续重启。

更多详情请参见与 Init 容器的区别。

采用内置边车容器

从 Kubernetes 1.29 版本开始，SidecarContainers 特性门控处于 Beta 阶段，并默认启用。某些集群可能禁用了此特性，或者安装了与该特性不兼容的软件。

当这种情况发生时，Pod 可能会被拒绝，或者边车容器可能阻止 Pod 启动，导致 Pod 无法使用。这种情况下很容易检测到问题，因为 Pod 会卡在初始化阶段。然而，通常不清楚是什么原因导致了问题。

以下是在使用边车容器处理工作负载时可以考虑的因素和排查步骤。

确保特性门控已启用

首先，确保 API 服务器和节点都在 Kubernetes v1.29 及更高版本上运行。如果节点运行的是早期版本且未启用该特性，集群中的该特性将无法正常工作。

注意

此特性可以在 1.28 版本的节点上启用。然而，内置边车容器的终止行为在 1.28 版本中有所不同，不建议将边车的行为调整为 1.28 中的行为。但是，如果唯一的关注点是启动顺序，上述陈述可以改为：运行 1.28 版本并启用了特性门控的节点。

你应该确保控制平面内的 API 服务器和所有节点都启用了特性门控。

一种检查特性门控是否启用的方法是运行如下命令：

对于 API 服务器：

kubectl get --raw /metrics | grep kubernetes_feature_enabled | grep SidecarContainers

对于单个节点：

kubectl get --raw /api/v1/nodes/<node-name>/proxy/metrics | grep kubernetes_feature_enabled | grep SidecarContainers

如果你看到类似这样的内容：

kubernetes_feature_enabled{name="SidecarContainers",stage="BETA"} 1

表示该特性已启用。

检查第三方工具和变更 Webhook

如果你在验证特性时遇到问题，这可能表明某个第三方工具或变更 Webhook 出现了问题。

当 SidecarContainers 特性门控启用后，Pod 在其 API 中会新增一个字段。某些工具或变更 Webhook 可能是基于早期版本的 Kubernetes API 构建的。

如果工具使用各种修补策略将未知字段原样传递，这不会有问题。然而，有些工具会删除未知字段；如果你使用的是这些工具，必须使用 v1.28+ 版本的 Kubernetes API 客户端代码重新编译它们。

检查这一点的方法是使用 kubectl describe pod 命令查看已通过变更准入的 Pod。如果任何工具删除了新字段（如 restartPolicy: Always），你将不会在命令输出中看到它。

如果你遇到了此类问题，请告知工具或 Webhook 的作者使用修补策略来修改对象，而不是进行完整的对象更新。

注意

变更 Webhook 可能会根据某些条件更新 Pod。因此，边车容器可能对某些 Pod 有效，但对其他 Pod 无效。

边车的自动注入

如果你使用的是自动注入边车的软件，可以采取几种策略来确保能够使用原生边车容器。所有这些策略通常都是你可以选择的选项，以决定注入边车的 Pod 是否会落在支持该特性的节点上。

例如，可以参考 Istio 社区中的这次讨论。讨论中探讨了以下选项：

标记支持边车的节点上的 Pod。你可以使用节点标签和节点亲和性来标记支持边车容器的节点以及落在这些节点上的 Pod。

注入时检查节点兼容性。在边车注入过程中，可以使用以下策略来检查节点兼容性：
- 查询节点版本并假设版本 1.29+ 上启用了特性门控。
- 查询节点 Prometheus 指标并检查特性启用状态。
- 假设节点与 API 服务器的版本差异在支持的版本范围内。
- 可能还有其他自定义方法来检测节点兼容性。

开发通用边车注入器（Sidecar Injector）。通用边车注入器的想法是在注入一个普通容器的同时注入一个原生边车容器，并在运行时决定哪个容器会生效。通用边车注入器虽然浪费资源（因为它会两次计算请求量），但在某些特殊情况下可以视为可行的解决方案。
- 一种方法是在原生边车容器启动时检测节点版本，如果不支持边车特性则立即退出。
- 考虑运行时特性检测设计：
  - 定义一个空目录（Empty Dir）以便容器之间通信。
  - 注入一个 Init 容器，我们称之为 NativeSidecar，并设置 restartPolicy=Always。
  - NativeSidecar 必须在空目录中写入一个文件，表示首次运行并立即退出，退出码为 0。
```
 - `NativeSidecar` 在重启时（当支持原生边车时）检查空目录中是否已存在该文件，并进行更改 —— 表示已支持原生边车容器并正在运行。
```
  - 注入一个普通容器，我们称之为 OldWaySidecar。
  - OldWaySidecar 启动时检查空目录中是否存在文件。
  - 如果文件表示 NativeSidecar 未运行，则假设边特性不支持，并按边车的方式工作。
  - 如果文件表示 NativeSidecar 正在运行，则根据 Pod 的 restartPolicy 决定行为：
  - 如果 Pod 的 restartPolicy=Always，则不做任何操作并永远休眠。
  - 如果 Pod 的 restartPolicy!=Always，则立即退出，退出码为 0。

接下来

了解有关边车容器的更多信息。

4 - 安全

对于运行 Kubernetes 集群的大多数组织和人员来说，安全是一个重要问题。你可以在 Kubernetes 文档的其他地方找到基本的安全检查清单。

要了解如何部署和管理 Kubernetes 的安全的方方面面，你可以按照本部分中的教程进行操作。

4.1 - 在集群级别应用 Pod 安全标准

Note

本教程仅适用于新集群。

Pod 安全是一个准入控制器，当新的 Pod 被创建时，它会根据 Kubernetes Pod 安全标准进行检查。这是在 v1.25 中达到正式发布（GA）的功能。本教程将向你展示如何在集群级别实施 baseline Pod 安全标准，该标准将标准配置应用于集群中的所有名字空间。

要将 Pod 安全标准应用于特定名字空间，请参阅在名字空间级别应用 Pod 安全标准。

如果你正在运行 v1.31 以外的 Kubernetes 版本，请查阅该版本的文档。

准备开始

在你的工作站中安装以下内容：

本教程演示了你可以对完全由你控制的 Kubernetes 集群所配置的内容。如果你正在学习如何为一个无法配置控制平面的托管集群配置 Pod 安全准入，请参阅在名字空间级别应用 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.31.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

说明：

pod-security.admission.config.k8s.io/v1 配置需要 v1.25+。对于 v1.23 和 v1.24，使用 v1beta1。对于 v1.22，使用 v1alpha1。

在创建集群时配置 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.31.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：

security/example-baseline-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
    - image: nginx
      name: nginx
      ports:
        - containerPort: 80

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

接下来

运行一个 shell 脚本一次执行前面的所有步骤：
1. 创建一个基于 Pod 安全标准的集群级别配置
2. 创建一个文件让 API 服务器消费这个配置
3. 创建一个集群，用这个配置创建一个 API 服务器
4. 设置 kubectl 上下文为这个新集群
5. 创建一个最小的 Pod yaml 文件
6. 应用这个文件，在新集群中创建一个 Pod
Pod 安全准入
Pod 安全标准
在名字空间级别应用 Pod 安全标准

4.2 - 在名字空间级别应用 Pod 安全标准

Note

本教程仅适用于新集群。

Pod Security Admission 是一个准入控制器，在创建 Pod 时应用 Pod 安全标准。这是在 v1.25 中达到正式发布（GA）的功能。在本教程中，你将应用 baseline Pod 安全标准，每次一个名字空间。

你还可以在集群级别一次将 Pod 安全标准应用于多个名称空间。有关说明，请参阅在集群级别应用 Pod 安全标准。

准备开始

在你的工作站中安装以下内容：

创建集群

按照如下方式创建一个 kind 集群：

kind create cluster --name psa-ns-level

输出类似于：

Creating cluster "psa-ns-level" ...
 ✓ Ensuring node image (kindest/node:v1.31.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 安全标准。在这一步中，我们将根据最新版本（默认值）对基线 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

验证 Pod 安全标准

在 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 脚本一次执行所有前面的步骤。
1. 创建 kind 集群
2. 创建新的名字空间
3. 在 enforce 模式下应用 baseline Pod 安全标准，同时在 warn 和 audit 模式下应用 restricted Pod 安全标准。
4. 创建一个应用以下 Pod 安全标准的新 Pod
Pod 安全准入
Pod 安全标准
在集群级别应用 Pod 安全标准

4.3 - 使用 AppArmor 限制容器对资源的访问

特性状态： Kubernetes v1.31 [stable] (enabled by default: true)

本页面向你展示如何在节点上加载 AppArmor 配置文件并在 Pod 中强制应用这些配置文件。要了解有关 Kubernetes 如何使用 AppArmor 限制 Pod 的更多信息，请参阅 Pod 和容器的 Linux 内核安全约束。

教程目标

查看如何在节点上加载配置文件示例
了解如何在 Pod 上强制执行配置文件
了解如何检查配置文件是否已加载
查看违反配置文件时会发生什么
查看无法加载配置文件时会发生什么

准备开始

AppArmor 是一个可选的内核模块和 Kubernetes 特性，因此请在继续之前验证你的节点是否支持它：

AppArmor 内核模块已启用 —— 要使 Linux 内核强制执行 AppArmor 配置文件，必须安装并且启动 AppArmor 内核模块。默认情况下，有几个发行版支持该模块，如 Ubuntu 和 SUSE，还有许多发行版提供可选支持。要检查模块是否已启用，请检查 /sys/module/apparmor/parameters/enabled 文件：
```
cat /sys/module/apparmor/parameters/enabled
Y
```
kubelet 会先验证主机上是否已启用 AppArmor，然后再接纳显式配置了 AppArmor 的 Pod。

容器运行时支持 AppArmor —— 所有常见的 Kubernetes 支持的容器运行时都应该支持 AppArmor，包括 CRI-O 和 containerd。请参考相应的运行时文档并验证集群是否满足使用 AppArmor 的要求。

配置文件已加载 —— 通过指定每个容器应使用的 AppArmor 配置文件， AppArmor 会被应用到 Pod 上。如果所指定的配置文件未加载到内核， kubelet 将拒绝 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)
```
有关在节点上加载配置文件的详细信息，请参见使用配置文件设置节点。

保护 Pod

说明：

在 Kubernetes v1.30 之前，AppArmor 是通过注解指定的。使用文档版本选择器查看包含此已弃用 API 的文档。

AppArmor 配置文件可以在 Pod 级别或容器级别指定。容器 AppArmor 配置文件优先于 Pod 配置文件。

securityContext:
  appArmorProfile:
    type: <profile_type>

其中 <profile_type> 是以下之一：

RuntimeDefault 使用运行时的默认配置文件
Localhost 使用主机上加载的配置文件（见下文）
Unconfined 无需 AppArmor 即可运行

有关 AppArmor 配置文件 API 的完整详细信息，请参阅指定 AppArmor 限制。

要验证是否应用了配置文件，你可以通过检查容器根进程的进程属性来检查该进程是否正在使用正确的配置文件运行：

kubectl exec <pod_name> -- cat /proc/1/attr/current

输出应如下所示：

cri-containerd.apparmor.d (enforce)

你还可以通过检查容器的 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 来安装配置文件，但是在使用配置文件设置节点中讨论了其他方法。

# 此示例假设节点名称与主机名称匹配，并且可通过 SSH 访问。
NODES=($(kubectl get nodes -o name))
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：

pods/security/hello-apparmor.yaml

apiVersion: v1
kind: Pod
metadata:
  name: hello-apparmor
spec:
  securityContext:
    appArmorProfile:
      type: Localhost
      localhostProfile: k8s-apparmor-example-deny-write
  containers:
  - name: hello
    image: busybox:1.28
    command: [ "sh", "-c", "echo 'Hello AppArmor!' && sleep 1h" ]

kubectl create -f hello-apparmor.yaml

你可以通过检查其 /proc/1/attr/current 来验证容器是否确实使用该配置文件运行：

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
spec:
  securityContext:
    appArmorProfile:
      type: Localhost
      localhostProfile: k8s-apparmor-example-allow-write
  containers:
  - name: hello
    image: busybox:1.28
    command: [ "sh", "-c", "echo 'Hello AppArmor!' && sleep 1h" ]
EOF

pod/hello-apparmor-2 created

虽然 Pod 创建成功，但进一步检查会发现它陷入 pending 状态：

kubectl describe pod hello-apparmor-2

Name:          hello-apparmor-2
Namespace:     default
Node:          gke-test-default-pool-239f5d02-x1kf/10.128.0.27
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
...
Events:
  Type     Reason     Age              From               Message
  ----     ------     ----             ----               -------
  Normal   Scheduled  10s              default-scheduler  Successfully assigned default/hello-apparmor to gke-test-default-pool-239f5d02-x1kf
  Normal   Pulled     8s               kubelet            Successfully pulled image "busybox:1.28" in 370.157088ms (370.172701ms including waiting)
  Normal   Pulling    7s (x2 over 9s)  kubelet            Pulling image "busybox:1.28"
  Warning  Failed     7s (x2 over 8s)  kubelet            Error: failed to get container spec opts: failed to generate apparmor spec opts: apparmor profile not found k8s-apparmor-example-allow-write
  Normal   Pulled     7s               kubelet            Successfully pulled image "busybox:1.28" in 90.980331ms (91.005869ms including waiting)

事件提供错误消息及其原因，具体措辞与运行时相关：

  Warning  Failed     7s (x2 over 8s)  kubelet            Error: failed to get container spec opts: failed to generate apparmor spec opts: apparmor profile not found

管理

使用配置文件设置节点

Kubernetes 1.31 目前不提供任何本地机制来将 AppArmor 配置文件加载到节点上。可以通过自定义基础设施或工具（例如 Kubernetes Security Profiles Operator）加载配置文件。

调度程序不知道哪些配置文件加载到哪个节点上，因此必须将全套配置文件加载到每个节点上。另一种方法是为节点上的每个配置文件（或配置文件类）添加节点标签，并使用节点选择器确保 Pod 在具有所需配置文件的节点上运行。

编写配置文件

获得正确指定的 AppArmor 配置文件可能是一件棘手的事情。幸运的是，有一些工具可以帮助你做到这一点：

aa-genprof 和 aa-logprof 通过监视应用程序的活动和日志并准许它所执行的操作来生成配置文件规则。 AppArmor 文档提供了进一步的指导。
bane 是一个用于 Docker的 AppArmor 配置文件生成器，它使用一种简化的画像语言（profile language）。

想要调试 AppArmor 的问题，你可以检查系统日志，查看具体拒绝了什么。 AppArmor 将详细消息记录到 dmesg，错误通常可以在系统日志中或通过 journalctl 找到。更多详细信息参见 AppArmor 失败。

指定 AppArmor 限制

注意：

在 Kubernetes v1.30 之前，AppArmor 是通过注解指定的。使用文档版本选择器查看包含此已弃用 API 的文档。

安全上下文中的 AppArmor 配置文件

你可以在容器的 securityContext 或 Pod 的 securityContext 中设置 appArmorProfile。如果在 Pod 级别设置配置文件，该配置将被用作 Pod 中所有容器（包括 Init、Sidecar 和临时容器）的默认配置文件。如果同时设置了 Pod 和容器 AppArmor 配置文件，则将使用容器的配置文件。

AppArmor 配置文件有 2 个字段：

type （必需） - 指示将应用哪种 AppArmor 配置文件。有效选项是：

Localhost: 节点上预加载的配置文件（由 localhostProfile 指定）。
RuntimeDefault: 容器运行时的默认配置文件。
Unconfined: 不强制执行 AppArmor。

localhostProfile - 在节点上加载的、应被使用的配置文件的名称。该配置文件必须在节点上预先配置才能工作。当且仅当 type 是 Localhost 时，必须提供此选项。

接下来

其他资源：

4.4 - 使用 seccomp 限制容器的系统调用

特性状态： Kubernetes v1.19 [stable]

Seccomp 代表安全计算（Secure Computing）模式，自 2.6.12 版本以来，一直是 Linux 内核的一个特性。它可以用来沙箱化进程的权限，限制进程从用户态到内核态的调用。 Kubernetes 能使你自动将加载到节点上的 seccomp 配置文件应用到你的 Pod 和容器。

识别你的工作负载所需要的权限是很困难的。在本篇教程中，你将了解如何将 seccomp 配置文件加载到本地的 Kubernetes 集群中，如何将它们应用到 Pod，以及如何开始制作只为容器进程提供必要的权限的配置文件。

教程目标

了解如何在节点上加载 seccomp 配置文件
了解如何将 seccomp 配置文件应用到容器上
观察容器进程对系统调用的审计
观察指定的配置文件缺失时的行为
观察违反 seccomp 配置文件的行为
了解如何创建细粒度的 seccomp 配置文件
了解如何应用容器运行时所默认的 seccomp 配置文件

准备开始

为了完成本篇教程中的所有步骤，你必须安装 kind 和 kubectl。

本教程中使用的命令假设你使用 Docker 作为容器运行时。（kind 创建的集群可以在内部使用不同的容器运行时）。你也可以使用 Podman，但如果使用了 Podman，你必须执行特定的指令才能顺利完成任务。

本篇教程演示的某些示例仍然是 Beta 状态（自 v1.25 起），另一些示例则仅使用 seccomp 正式发布的功能。你应该确保，针对你使用的版本，正确配置了集群。

本篇教程也使用了 curl 工具来下载示例到你的计算机上。你可以使用其他自己偏好的工具来自适应这些步骤。

说明：

无法将 seccomp 配置文件应用于在容器的 securityContext 中设置了 privileged: true 的容器。特权容器始终以 Unconfined 的方式运行。

下载示例 seccomp 配置文件

这些配置文件的内容将在稍后进行分析，现在先将它们下载到名为 profiles/ 的目录中，以便将它们加载到集群中。

class=copy-code-icon>pods/security/seccomp/profiles/audit.json onclick='copyCode("pods-security-seccomp-profiles-audit-json")' title="复制 pods/security/seccomp/profiles/audit.json 到剪贴板">

{ "defaultAction": "SCMP_ACT_LOG" }

pods/security/seccomp/profiles/violation.json onclick='copyCode("pods-security-seccomp-profiles-violation-json")' title="复制 pods/security/seccomp/profiles/violation.json 到剪贴板">

{ "defaultAction": "SCMP_ACT_ERRNO" }

pods/security/seccomp/profiles/fine-grained.json onclick='copyCode("pods-security-seccomp-profiles-fine-grained-json")' title="复制 pods/security/seccomp/profiles/fine-grained.json 到剪贴板">

{ "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 创建本地 Kubernetes 集群

为简单起见，kind 可用来创建加载了 seccomp 配置文件的单节点集群。 Kind 在 Docker 中运行 Kubernetes，因此集群的每个节点都是一个容器。这允许将文件挂载到每个容器的文件系统中，类似于将文件加载到节点上。

pods/security/seccomp/kind.yaml

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.31。

作为 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。

创建使用容器运行时默认 seccomp 配置文件的 Pod

大多数容器运行时都提供了一组合理的、默认被允许或默认被禁止的系统调用。你可以通过将 Pod 或容器的安全上下文中的 seccomp 类型设置为 RuntimeDefault 来为你的工作负载采用这些默认值。

说明：

如果你已经启用了 seccompDefault 配置，只要没有指定其他 seccomp 配置文件，那么 Pod 就会使用 RuntimeDefault seccomp 配置文件。否则，默认值为 Unconfined。

这是一个 Pod 的清单，它要求其所有容器使用 RuntimeDefault seccomp 配置文件：

pods/security/seccomp/ga/default-pod.yaml

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:1.0
    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

在进入下一节之前先删除 Pod：

kubectl delete pod default-pod --wait --now

使用 seccomp 配置文件创建 Pod 以进行系统调用审计

首先，将 audit.json 配置文件应用到新的 Pod 上，该配置文件将记录进程的所有系统调用。

这是该 Pod 的清单：

pods/security/seccomp/ga/audit-pod.yaml

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:1.0
    args:
    - "-text=just made some syscalls!"
    securityContext:
      allowPrivilegeEscalation: false

说明：

旧版本的 Kubernetes 允许你使用注解配置 seccomp 行为。Kubernetes 1.31 仅支持使用位于 .spec.securityContext 内的字段来配置 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 和端口号 32373
docker exec -it 6a96207fed4b curl localhost:32373

just made some syscalls!

你可以看到该进程正在运行，但它实际上进行了哪些系统调用？因为这个 Pod 在本地集群中运行，你应该能够在本地系统的 /var/log/syslog 中看到它们。打开一个新的终端窗口并 tail 来自 http-echo 的调用的输出：

# 在你的计算机上，日志路径可能不是 "/var/log/syslog"
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 配置文件的基础。

在转到下一节之前删除该 Service 和 Pod：

kubectl delete service audit-pod --wait
kubectl delete pod audit-pod --wait --now

使用导致违规的 seccomp 配置文件创建 Pod

出于演示目的，将配置文件应用于不允许任何系统调用的 Pod 上。

此演示的清单是：

pods/security/seccomp/ga/violation-pod.yaml

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:1.0
    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

使用只允许必要的系统调用的 seccomp 配置文件创建 Pod

如果你看一看 fine-grained.json 配置文件，你会注意到第一个示例的 syslog 中看到的一些系统调用，其中配置文件设置为 "defaultAction": "SCMP_ACT_LOG"。现在的配置文件设置 "defaultAction": "SCMP_ACT_ERRNO"，但在 "action": "SCMP_ACT_ALLOW" 块中明确允许一组系统调用。理想情况下，容器将成功运行，并且你看到没有消息发送到 syslog。

此示例的清单是：

pods/security/seccomp/ga/fine-pod.yaml

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:1.0
    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 和端口号 32373
docker exec -it 6a96207fed4b curl localhost:32373

just made some syscalls!

你应该在 syslog 中看不到任何输出。这是因为配置文件允许所有必要的系统调用，并指定如果调用列表之外的系统调用应发生错误。从安全角度来看，这是一种理想的情况，但需要在分析程序时付出一些努力。如果有一种简单的方法可以在不需要太多努力的情况下更接近这种安全性，那就太好了。

在进入下一节之前删除该 Service 和 Pod：

kubectl delete service fine-pod --wait
kubectl delete pod fine-pod --wait --now

启用使用 `RuntimeDefault` 作为所有工作负载的默认 seccomp 配置文件

特性状态： Kubernetes v1.27 [stable]

要采用为 Seccomp（安全计算模式）设置默认配置文件这一行为，你必须使用在想要启用此行为的每个节点上启用 --seccomp-default 命令行标志来运行 kubelet。

如果启用，kubelet 将会默认使用 RuntimeDefault seccomp 配置文件，（这一配置文件是由容器运行时定义的），而不是使用 Unconfined（禁用 seccomp）模式。默认的配置文件旨在提供一组限制性较强且能保留工作负载功能的安全默认值。不同容器运行时及其不同发布版本之间的默认配置文件可能有所不同，例如在比较来自 CRI-O 和 containerd 的配置文件时。

说明：

启用该功能既不会更改 Kubernetes securityContext.seccompProfile API 字段，也不会添加已弃用的工作负载注解。这样用户可以随时回滚，而且无需实际更改工作负载配置。 crictl inspect 之类的工具可用于检查容器正在使用哪个 seccomp 配置文件。

与其他工作负载相比，某些工作负载可能需要更少的系统调用限制。这意味着即使使用 RuntimeDefault 配置文件，它们也可能在运行时失败。要应对此类故障，你可以：

显式地以 Unconfined 模式运行工作负载。
禁用节点的 SeccompDefault 特性。同时，确保工作负载被调度到禁用该特性的节点上。
为工作负载创建自定义 seccomp 配置文件。

如果你将此特性引入到类似的生产集群中， Kubernetes 项目建议你在部分节点上启用此特性门控，然后在整个集群范围内推出更改之前，测试工作负载执行情况。

你可以在相关的 Kubernetes 增强提案（KEP）中找到可能的升级和降级策略的更详细信息: 默认启用 Seccomp。

Kubernetes 1.31 允许你配置 Seccomp 配置文件，当 Pod 的规约未定义特定的 Seccomp 配置文件时应用该配置文件。但是，你仍然需要为合适的节点启用这种设置默认配置的能力。

如果你正在运行 Kubernetes 1.31 集群并希望启用该特性，请使用 --seccomp-default 命令行参数运行 kubelet，或通过 kubelet 配置文件启用。

要在 kind 启用特性门控，请确保 kind 提供所需的最低 Kubernetes 版本，并在 kind 配置中启用 SeccompDefault 特性：

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
  - role: control-plane
    image: kindest/node:v1.28.0@sha256:9f3ff58f19dcf1a0611d11e8ac989fdb30a28f40f236f59f0bea31fb956ccf5c
    kubeadmConfigPatches:
      - |
        kind: JoinConfiguration
        nodeRegistration:
          kubeletExtraArgs:
            seccomp-default: "true"        
  - role: worker
    image: kindest/node:v1.28.0@sha256:9f3ff58f19dcf1a0611d11e8ac989fdb30a28f40f236f59f0bea31fb956ccf5c
    kubeadmConfigPatches:
      - |
        kind: JoinConfiguration
        nodeRegistration:
          kubeletExtraArgs:
            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": ["..."]
    }
  ]
}

接下来

你可以了解有关 Linux seccomp 的更多信息：

5 - 无状态的应用

5.1 - 公开外部 IP 地址以访问集群中的应用

此页面显示如何创建公开外部 IP 地址的 Kubernetes 服务对象。

准备开始

安装 kubectl。
使用 Google Kubernetes Engine 或 Amazon Web Services 等云供应商创建 Kubernetes 集群。本教程创建了一个外部负载均衡器，需要云供应商。
配置 kubectl 与 Kubernetes API 服务器通信。有关说明，请参阅云供应商文档。

教程目标

运行 Hello World 应用的五个实例。
创建一个公开外部 IP 地址的 Service 对象。
使用 Service 对象访问正在运行的应用。

为在五个 Pod 中运行的应用创建服务

在集群中运行 Hello World 应用：

service/load-balancer-example.yaml

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/hello-app:2.0
        name: hello-world
        ports:
        - containerPort: 8080

kubectl apply -f https://k8s.io/examples/service/load-balancer-example.yaml

前面的命令创建一个 Deployment 对象和一个关联的 ReplicaSet 对象。 ReplicaSet 有五个 Pod，每个都运行 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, world!
Version: 2.0.0
Hostname: 0bd46b45f32f
```

清理现场

要删除 Service，请输入以下命令：

kubectl delete services my-service

要删除正在运行 Hello World 应用的 Deployment、ReplicaSet 和 Pod，请输入以下命令：

kubectl delete deployment hello-world

接下来

进一步了解使用 Service 连接到应用。

5.2 - 示例：使用 Redis 部署 PHP 留言板应用

本教程向你展示如何使用 Kubernetes 和 Docker 构建和部署一个简单的 (非面向生产的) 多层 Web 应用。本例由以下组件组成：

单实例 Redis 以保存留言板条目
多个 Web 前端实例

教程目标

启动 Redis 领导者（Leader）
启动两个 Redis 跟随者（Follower）
公开并查看前端服务
清理

准备开始

你的 Kubernetes 服务器版本必须不低于版本 v1.14. 要获知版本信息，请输入 kubectl version.

启动 Redis 数据库

留言板应用使用 Redis 存储数据。

创建 Redis Deployment

下面包含的清单文件指定了一个 Deployment 控制器，该控制器运行一个 Redis Pod 副本。

application/guestbook/redis-leader-deployment.yaml

# 来源：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 领导者服务

留言板应用需要往 Redis 中写数据。因此，需要创建 Service 来转发 Redis Pod 的流量。Service 定义了访问 Pod 的策略。

application/guestbook/redis-leader-service.yaml

# 来源：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 跟随者

尽管 Redis 领导者只有一个 Pod，你可以通过添加若干 Redis 跟随者来将其配置为高可用状态，以满足流量需求。

application/guestbook/redis-follower-deployment.yaml

# 来源：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: us-docker.pkg.dev/google-samples/containers/gke/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

创建 Redis 跟随者服务

Guestbook 应用需要与 Redis 跟随者通信以读取数据。为了让 Redis 跟随者可被发现，你必须创建另一个 Service。

application/guestbook/redis-follower-service.yaml

# 来源：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 的用户体验。

创建 Guestbook 前端 Deployment

application/guestbook/frontend-deployment.yaml

# 来源：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: us-docker.pkg.dev/google-samples/containers/gke/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。

application/guestbook/frontend-service.yaml

# 来源：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

在浏览器中加载 http://localhost:8080 页面以查看 Guestbook。

通过 `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

复制这里的外部 IP 地址，然后在浏览器中加载页面以查看留言板。

说明：

尝试通过输入消息并点击 Submit 来添加一些留言板条目。你所输入的消息会在前端显示。这一消息表明数据被通过你之前所创建的 Service 添加到 Redis 存储中。

扩展 Web 前端

你可以根据需要执行伸缩操作，这是因为服务器本身被定义为使用一个 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.
```

接下来

完成 Kubernetes 基础交互式教程
使用 Kubernetes 创建一个博客，使用 MySQL 和 Wordpress 的持久卷
进一步阅读使用 Service 连接到应用
进一步阅读有效使用标签

6 - 有状态的应用

6.1 - StatefulSet 基础

本教程介绍了如何使用 StatefulSet 来管理应用。演示了如何创建、删除、扩容/缩容和更新 StatefulSet 的 Pod。

准备开始

在开始本教程之前，你应该熟悉以下 Kubernetes 的概念：

你应该配置 kubectl 的上下文使用 default 命名空间。如果你使用的是现有集群，请确保可以使用该集群的 default 命名空间进行练习。理想情况下，在没有运行任何实际工作负载的集群中进行练习。

阅读有关 StatefulSet 的概念页面也很有用。

说明：

本教程假设你的集群被配置为动态制备 PersistentVolume 卷，且有一个默认 StorageClass。如果没有这样配置，在开始本教程之前，你需要手动准备 2 个 1 GiB 的存储卷，以便这些 PersistentVolume 可以映射到 StatefulSet 定义的 PersistentVolumeClaim 模板。

教程目标

StatefulSet 旨在与有状态的应用及分布式系统一起使用。然而在 Kubernetes 上管理有状态应用和分布式系统是一个宽泛而复杂的话题。为了演示 StatefulSet 的基本特性，并且不使前后的主题混淆，你将会使用 StatefulSet 部署一个简单的 Web 应用。

在阅读本教程后，你将熟悉以下内容：

如何创建 StatefulSet
StatefulSet 怎样管理它的 Pod
如何删除 StatefulSet
如何对 StatefulSet 进行扩容/缩容
如何更新一个 StatefulSet 的 Pod

创建 StatefulSet

作为开始，使用如下示例创建一个 StatefulSet（以及它所依赖的 Service）。它和 StatefulSet 概念中的示例相似。它创建了一个 Headless Service nginx 用来发布 StatefulSet web 中的 Pod 的 IP 地址。

application/web/web.yaml

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.21
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 1Gi

你需要使用至少两个终端窗口。在第一个终端中，使用 kubectl get 来监视 StatefulSet 的 Pod 的创建情况。

# 使用此终端运行指定 --watch 的命令
# 当你被要求开始一个新的 watch 时结束这个 watch
kubectl get pods --watch -l app=nginx

在另一个终端中，使用 kubectl apply 来创建 Headless Service 和 StatefulSet。

kubectl apply -f https://k8s.io/examples/application/web/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   READY   AGE
web    2/2     37s

顺序创建 Pod

StatefulSet 默认以严格的顺序创建其 Pod。

对于一个拥有 n 个副本的 StatefulSet，Pod 被部署时是按照 {0..n-1} 的序号顺序创建的。在第一个终端中使用 kubectl get 检查输出。这个输出最终将看起来像下面的样子。

# 不要开始一个新的 watch
# 这应该已经处于 Running 状态
kubectl get pods --watch -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 拥有一个唯一的顺序索引和稳定的网络身份标识。

检查 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：

# 启动一个新的 watch
# 当你看到删除完成后结束这个 watch
kubectl get pod --watch -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 状态：

# 这应该已经处于 Running 状态
kubectl get pod --watch -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 地址进行连接，这点很重要（可以通过解析 Pod 的主机名来连接到 Pod）。

发现 StatefulSet 中特定的 Pod

如果你需要查找并连接一个 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 时，你的应用就能够发现它们的地址。

如果你的应用程序想要在 StatefulSet 中找到任一健康的 Pod，且不需要跟踪每个特定的 Pod，你还可以连接到由该 StatefulSet 中的 Pod 关联的 type: ClusterIP Service 的 IP 地址。你可以使用跟踪 StatefulSet 的同一 Service （StatefulSet 中 serviceName 所指定的）或选择正确的 Pod 集的单独 Service。

写入稳定的存储

获取 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：

# 当你到达该部分的末尾时结束此 watch
# 在开始“扩展 StatefulSet” 时，你将启动一个新的 watch。
kubectl get pod --watch -l app=nginx

pod "web-0" deleted
pod "web-1" deleted

在第一个终端里检查 kubectl get 命令的输出，等待所有 Pod 变成 Running 和 Ready 状态。

# 这应该已经处于 Running 状态
kubectl get pod --watch -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

扩容/缩容 StatefulSet 指增加或减少它的副本数。这通过更新 replicas 字段完成（水平缩放）。你可以使用 kubectl scale 或者 kubectl patch 来扩容/缩容一个 StatefulSet。

扩容

扩容意味着添加更多副本。如果你的应用程序能够在整个 StatefulSet 范围内分派工作，则新的更大的 Pod 集可以执行更多的工作。

在一个终端窗口监视 StatefulSet 的 Pod：

# 如果你已经有一个正在运行的 wach，你可以继续使用它。
# 否则，就启动一个。
# 当 StatefulSet 有 5 个健康的 Pod 时结束此 watch
kubectl get pods --watch -l app=nginx

在另一个终端窗口使用 kubectl scale 扩展副本数为 5：

kubectl scale sts web --replicas=5

statefulset.apps/web scaled

在第一个终端中检查 kubectl get 命令的输出，等待增加的 3 个 Pod 的状态变为 Running 和 Ready。

# 这应该已经处于 Running 状态
kubectl get pod --watch -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
# 当 StatefulSet 只有 3 个 Pod 时结束此 watch
kubectl get pod --watch -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
# 这应该已经处于 Running 状态
kubectl get pods --watch -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。在删除下一个 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 缩容引起时也是一样的。

更新 StatefulSet

StatefulSet 控制器支持自动更新。更新策略由 StatefulSet API 对象的 spec.updateStrategy 字段决定。这个特性能够用来更新一个 StatefulSet 中 Pod 的容器镜像、资源请求和限制、标签和注解。

有两个有效的更新策略：RollingUpdate（默认）和 OnDelete。

滚动更新

RollingUpdate 更新策略会更新一个 StatefulSet 中的所有 Pod，采用与序号索引相反的顺序并遵循 StatefulSet 的保证。

你可以通过指定 .spec.updateStrategy.rollingUpdate.partition 将使用 RollingUpdate 策略的 StatefulSet 的更新拆分为多个分区。你将在本教程中稍后练习此操作。

首先，尝试一个简单的滚动更新。

在一个终端窗口中对 web StatefulSet 执行 patch 操作来再次改变容器镜像：

kubectl patch statefulset web --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"registry.k8s.io/nginx-slim:0.24"}]'

statefulset.apps/web patched

在另一个终端监控 StatefulSet 中的 Pod：

# 滚动完成后结束此 watch
#
# 如果你不确定，请让它再运行一分钟
kubectl get pod -l app=nginx --watch

输出类似于：

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.24
registry.k8s.io/nginx-slim:0.24
registry.k8s.io/nginx-slim:0.24

StatefulSet 中的所有 Pod 现在都在运行之前的容器镜像。

说明：

你还可以使用 kubectl rollout status sts/<名称> 来查看 StatefulSet 的滚动更新状态。

分段更新

你可以通过指定 .spec.updateStrategy.rollingUpdate.partition 将使用 RollingUpdate 策略的 StatefulSet 的更新拆分为多个分区。

有关更多上下文，你可以阅读 StatefulSet 概念页面中的分区滚动更新。

你可以使用 .spec.updateStrategy.rollingUpdate 中的 partition 字段对 StatefulSet 执行更新的分段操作。对于此更新，你将保持 StatefulSet 中现有 Pod 不变，同时更改 StatefulSet 的 Pod 模板。然后，你（或通过教程之外的一些外部自动化工具）可以触发准备好的更新。

对 web StatefulSet 执行 Patch 操作，为 updateStrategy 字段添加一个分区：

# "partition" 的值决定更改适用于哪些序号
# 确保使用比 StatefulSet 的最后一个序号更大的数字
kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate","rollingUpdate":{"partition":3}}}}'

statefulset.apps/web patched

再次 Patch StatefulSet 来改变此 StatefulSet 使用的容器镜像：

kubectl patch statefulset web --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"registry.k8s.io/nginx-slim:0.21"}]'

statefulset.apps/web patched

删除 StatefulSet 中的 Pod：

kubectl delete pod web-2

pod "web-2" deleted

等待替代的 Pod 变成 Running 和 Ready。

# 当你看到 web-2 运行正常时结束 watch
kubectl get pod -l app=nginx --watch

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.24

请注意，虽然更新策略是 RollingUpdate，StatefulSet 还是会使用原始的容器镜像恢复 Pod。这是因为 Pod 的序号比 updateStrategy 指定的 partition 更小。

金丝雀发布

现在，你将尝试对分段的变更进行金丝雀发布。

你可以通过减少上文指定的 partition 来进行金丝雀发布，以测试修改后的模板。

通过 patch 命令修改 StatefulSet 来减少分区：

# “partition” 的值应与 StatefulSet 现有的最高序号相匹配
kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate","rollingUpdate":{"partition":2}}}}'

statefulset.apps/web patched

控制平面会触发 web-2 的替换（先优雅地删除现有 Pod，然后在删除完成后创建一个新的 Pod）。等待新的 web-2 Pod 变成 Running 和 Ready。

# 这应该已经处于 Running 状态
kubectl get pod -l app=nginx --watch

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.21

当你改变 partition 时，StatefulSet 会自动更新 web-2 Pod，这是因为 Pod 的序号大于或等于 partition。

删除 web-1 Pod：

kubectl delete pod web-1

pod "web-1" deleted

等待 web-1 变成 Running 和 Ready。

# 这应该已经处于 Running 状态
kubectl get pod -l app=nginx --watch

输出类似于：

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.24

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。

# 这应该已经处于 Running 状态
kubectl get pod -l app=nginx --watch

输出类似于：

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.21
registry.k8s.io/nginx-slim:0.21
registry.k8s.io/nginx-slim:0.21

将 partition 改变为 0 以允许 StatefulSet 继续更新过程。

OnDelete 策略

通过将 .spec.template.updateStrategy.type 设置为 OnDelete，你可以为 StatefulSet 选择此更新策略。

对 web StatefulSet 执行 patch 操作，以使用 OnDelete 更新策略：

kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"OnDelete"}}}'

statefulset.apps/web patched

当你选择这个更新策略并修改 StatefulSet 的 .spec.template 字段时，StatefulSet 控制器将不会自动更新 Pod。你需要自己手动管理发布，或使用单独的自动化工具来管理发布。

删除 StatefulSet

StatefulSet 同时支持非级联和级联删除。使用非级联方式删除 StatefulSet 时，StatefulSet 的 Pod 不会被删除。使用级联删除时，StatefulSet 和它的 Pod 都会被删除。

阅读在集群中使用级联删除，以了解通用的级联删除。

非级联删除

在一个终端窗口监视 StatefulSet 中的 Pod。

# 当 StatefulSet 没有 Pod 时结束此 watch
kubectl get pods --watch -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。

# 让 watch 一直运行到你下次启动 watch 为止
kubectl get pods --watch -l app=nginx

在另一个终端里重新创建 StatefulSet。请注意，除非你删除了 nginx Service（你不应该这样做），你将会看到一个错误，提示 Service 已经存在。

kubectl apply -f https://k8s.io/examples/application/web/web.yaml

statefulset.apps/web created
service/nginx unchanged

请忽略这个错误。它仅表示 kubernetes 进行了一次创建 nginx Headless Service 的尝试，尽管那个 Service 已经存在。

在第一个终端中运行并检查 kubectl get 命令的输出。

# 这应该已经处于 Running 状态
kubectl get pods --watch -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 --watch -l app=nginx

在另一个窗口中再次删除这个 StatefulSet，这次省略 --cascade=orphan 参数。

kubectl delete statefulset web

statefulset.apps "web" deleted

在第一个终端检查 kubectl get 命令的输出，并等待所有的 Pod 变成 Terminating 状态。

# 这应该已经处于 Running 状态
kubectl get pods --watch -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 https://k8s.io/examples/application/web/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

Pod 管理策略

对于某些分布式系统来说，StatefulSet 的顺序性保证是不必要和/或者不应该的。这些系统仅仅要求唯一性和身份标志。

你可以指定 Pod 管理策略以避免这个严格的顺序；你可以选择 OrderedReady（默认）或 Parallel。

OrderedReady Pod 管理策略

OrderedReady Pod 管理策略是 StatefulSet 的默认选项。它告诉 StatefulSet 控制器遵循上文展示的顺序性保证。

当你的应用程序需要或期望变更（例如推出应用程序的新版本）按照 StatefulSet 提供的序号（Pod 编号）的严格顺序发生时，请使用此选项。换句话说，如果你已经有了 Pod app-0、app-1 和 app-2，Kubernetes 将首先更新 app-0 并检查它。一旦检查良好，Kubernetes 就会更新 app-1，最后更新 app-2。

如果你再添加两个 Pod，Kubernetes 将设置 app-3 并等待其正常运行，然后再部署 app-4。

因为这是默认设置，所以你已经在练习使用它，本教程不会让你再次执行类似的步骤。

Parallel Pod 管理策略

另一种选择，Parallel Pod 管理策略告诉 StatefulSet 控制器并行的终止所有 Pod，在启动或终止另一个 Pod 前，不必等待这些 Pod 变成 Running 和 Ready 或者完全终止状态。

Parallel Pod 管理选项仅影响扩缩容操作的行为。变更操作不受其影响；Kubernetes 仍然按顺序推出变更。对于本教程，应用本身非常简单：它是一个告诉你其主机名的网络服务器（因为这是一个 StatefulSet，每个 Pod 的主机名都是不同的且可预测的）。

application/web/web-parallel.yaml

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.24
        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 StatefulSet 的 .spec.podManagementPolicy 设置成了 Parallel。

在一个终端窗口监视 StatefulSet 中的 Pod。

# 让 watch 一直运行直到本节结束
kubectl get pod -l app=nginx --watch

在另一个终端中，重新配置 StatefulSet 以进行 Parallel Pod 管理：

kubectl apply -f https://k8s.io/examples/application/web/web-parallel.yaml

service/nginx updated
statefulset.apps/web updated

保持你运行监视进程的终端为打开状态，并在另一个终端窗口中扩容 StatefulSet：

kubectl scale statefulset/web --replicas=5

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     0/1       Pending   0         0s
web-4     0/1       Pending   0         0s
web-2     1/1       Running   0         8s
web-4     0/1       ContainerCreating   0         4s
web-3     1/1       Running   0         26s
web-4     1/1       Running   0         2s

StatefulSet 启动了三个新的 Pod，而且在启动第二和第三个之前并没有等待第一个变成 Running 和 Ready 状态。

如果你的工作负载具有有状态元素，或者需要 Pod 能够通过可预测的命名来相互识别，特别是当你有时需要快速提供更多容量时，此方法非常有用。如果本教程的这个简单 Web 服务突然每分钟收到额外 1,000,000 个请求，那么你可能会想要运行更多 Pod，但你也不想等待每个新 Pod 启动。并行启动额外的 Pod 可以缩短请求额外容量和使其可供使用之间的时间。

清理现场

你应该打开两个终端，准备在清理过程中运行 kubectl 命令。

kubectl delete sts web
# sts is an abbreviation for statefulset

你可以监视 kubectl get 来查看那些 Pod 被删除：

# 当你看到需要的内容后结束 watch
kubectl get pod -l app=nginx --watch

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 卷的持久化存储介质。

基于你的环境、存储配置和制备方式，按照必需的步骤保证回收所有的存储。

6.2 - 示例：使用持久卷部署 WordPress 和 MySQL

本示例描述了如何通过 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 版本，或参考本教程的早期版本。

教程目标

创建 PersistentVolumeClaims 和 PersistentVolumes
创建 kustomization.yaml 以使用
- Secret 生成器
- MySQL 资源配置
- WordPress 资源配置
kubectl apply -k ./ 来应用整个 kustomization 目录
清理

准备开始

要获知版本信息，请输入 kubectl version.

此例在 kubectl 1.27 或者更高版本有效。

下载下面的配置文件：

创建 PersistentVolumeClaims 和 PersistentVolumes

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 的集群，请参考此指南。

创建 kustomization.yaml

创建 Secret 生成器

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 和 WordPress 的资源配置

以下清单文件描述的是一个单实例的 MySQL Deployment。MySQL 容器将 PersistentVolume 挂载在 /var/lib/mysql。 MYSQL_ROOT_PASSWORD 环境变量根据 Secret 设置数据库密码。

application/wordpress/mysql-deployment.yaml

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:8.0
        name: mysql
        env:
        - name: MYSQL_ROOT_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql-pass
              key: password
        - name: MYSQL_DATABASE
          value: wordpress
        - name: MYSQL_USER
          value: wordpress
        - name: MYSQL_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 设置数据库密码。

application/wordpress/wordpress-deployment.yaml

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:6.2.1-apache
        name: wordpress
        env:
        - name: WORDPRESS_DB_HOST
          value: wordpress-mysql
        - name: WORDPRESS_DB_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql-pass
              key: password
        - name: WORDPRESS_DB_USER
          value: wordpress
        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 ./
```

接下来

进一步了解自省与调试
进一步了解 Job
进一步了解端口转发
了解如何获得容器的 Shell

6.3 - 示例：使用 StatefulSet 部署 Cassandra

本教程描述了如何在 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。

教程目标

创建并验证 Cassandra 无头（headless）Service。
使用 StatefulSet 创建一个 Cassandra ring。
验证 StatefulSet。
修改 StatefulSet。
删除 StatefulSet 及其 Pod。

准备开始

要完成本教程，你应该已经熟悉 Pod、 Service 和 StatefulSet。

额外的 Minikube 设置说明

注意：

Minikube 默认需要 2048MB 内存和 2 个 CPU。在本教程中，使用默认资源配置运行 Minikube 会出现资源不足的错误。为避免这些错误，请使用以下设置启动 Minikube：

minikube start --memory 5120 --cpus=4

为 Cassandra 创建无头（headless） Services

在 Kubernetes 中，一个 Service 描述了一组执行相同任务的 Pod。

以下 Service 用于在 Cassandra Pod 和集群中的客户端之间进行 DNS 查找：

application/cassandra/cassandra-service.yaml

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 创建 Cassandra Ring

下面包含的 StatefulSet 清单创建了一个由三个 Pod 组成的 Cassandra ring。

说明：

本示例使用 Minikube 的默认配置程序。请为正在使用的云更新以下 StatefulSet。

application/cassandra/cassandra-statefulset.yaml

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: 500
      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

获取 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

修改 Cassandra StatefulSet

使用 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
```

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`

接下来

了解如何扩缩 StatefulSet。
了解有关 KubernetesSeedProvider 的更多信息
查看更多自定义 Seed Provider Configurations

6.4 - 运行 ZooKeeper，一个分布式协调系统

本教程展示了在 Kubernetes 上使用 StatefulSet、 PodDisruptionBudget 和 PodAntiAffinity 特性运行 Apache Zookeeper。

准备开始

在开始本教程前，你应该熟悉以下 Kubernetes 概念。

你需要一个至少包含四个节点的集群，每个节点至少 2 个 CPU 和 4 GiB 内存。在本教程中你将会隔离（Cordon）和腾空（Drain ）集群的节点。 这意味着集群节点上所有的 Pod 将会被终止并移除。这些节点也会暂时变为不可调度。在本教程中你应该使用一个独占的集群，或者保证你造成的干扰不会影响其它租户。

本教程假设你的集群已配置为动态制备 PersistentVolume。如果你的集群没有配置成这样，在开始本教程前，你需要手动准备三个 20 GiB 的卷。

教程目标

在学习本教程后，你将熟悉下列内容。

如何使用 StatefulSet 部署一个 ZooKeeper ensemble。
如何一致地配置 ensemble。
如何在 ensemble 中分布 ZooKeeper 服务器的部署。
如何在计划维护中使用 PodDisruptionBudget 确保服务可用性。

ZooKeeper

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 条目都可以被安全的丢弃。

创建一个 ZooKeeper Ensemble

下面的清单包含一个无头服务、一个 Service、一个 PodDisruptionBudget 和一个 StatefulSet。

application/zookeeper/zookeeper.yaml

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 选举

由于在匿名网络中没有用于选举 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 状态），或者将会失败（如果没有满足上述条件中的任意一条）。当一个服务器承认另一个服务器的代写时不会有状态产生。

Ensemble 健康检查

最基本的健康检查是向一个 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 文档指出 “你将需要一个监管程序用于管理每个 ZooKeeper 服务进程（JVM）”。在分布式系统中，使用一个看门狗（监管程序）来重启故障进程是一种常用的模式。

更新 Ensemble

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 解除你集群中所有节点的隔离。
你需要删除在本教程中使用的 PersistentVolume 的持久存储介质。请遵循必须的步骤，基于你的环境、存储配置和制备方法，保证回收所有的存储。

7 - 集群管理

7.1 - 以独立模式运行 kubelet

本教程将向你展示如何运行一个独立的 kubelet 实例。

你可能会有不同的动机来运行一个独立的 kubelet。本教程旨在向你介绍 Kubernetes，即使你对此并没有太多经验也没有关系。你可以跟随本教程学习节点设置、基本（静态）Pod 以及 Kubernetes 如何管理容器。

你学习完本教程后，就可以尝试使用带一个控制平面的集群来管理 Pod、节点和其他类别的对象。例如，你好，Minikube。

你还可以以独立模式运行 kubelet 来满足生产场景要求，例如为高可用、弹性部署的集群运行控制平面。本教程不涵盖运行弹性控制平面所需的细节。

教程目标

在 Linux 系统上安装 cri-o 和 kubelet，并将其作为 systemd 服务运行。
启动一个运行 nginx 的 Pod，监听针对此 Pod 的 IP 地址的 TCP 80 端口的请求。
学习此方案中不同组件之间如何交互。

注意：

本教程中所使用的 kubelet 配置在设计上是不安全的，不得用于生产环境中。

准备开始

对使用 systemd 和 iptables（或使用 iptables 仿真的 nftables）的 Linux 系统具有管理员（root）访问权限。
有权限访问互联网以下载本教程所需的组件，例如：
- 实现 Kubernetes CRI 的容器运行时。
- 网络插件（通常称为容器网络接口（CNI））。
- 必需的 CLI 工具：curl、tar、jq。

准备好系统

配置内存交换

默认情况下，如果在节点上检测到内存交换，kubelet 将启动失败。这意味着内存交换应该被禁用或被 kubelet 容忍。

说明：

如果你配置 kubelet 为容忍内存交换，则 kubelet 仍会配置 Pod（以及这些 Pod 中的容器）不使用交换空间。要了解 Pod 实际上可以如何使用可用的交换，你可以进一步阅读 Linux 节点上交换内存管理。

如果你启用了交换内存，则禁用它或在 kubelet 配置文件中添加 failSwapOn: false。

要检查交换内存是否被启用：

sudo swapon --show

如果此命令没有输出，则交换内存已被禁用。

临时禁用交换内存：

sudo swapoff -a

要使此变更持续到重启之后：

确保在 /etc/fstab 或 systemd.swap 中禁用交换内存，具体取决于它在你的系统上是如何配置的。

启用 IPv4 数据包转发

检查 IPv4 数据包转发是否被启用：

cat /proc/sys/net/ipv4/ip_forward

如果输出为 1，则 IPv4 数据包转发已被启用。如果输出为 0，按照以下步骤操作。

要启用 IPv4 数据包转发，创建一个配置文件，将 net.ipv4.ip_forward 参数设置为 1：

sudo tee /etc/sysctl.d/k8s.conf <<EOF
net.ipv4.ip_forward = 1
EOF

将变更应用到系统：

sudo sysctl --system

输出类似于：

...
* Applying /etc/sysctl.d/k8s.conf ...
net.ipv4.ip_forward = 1
* Applying /etc/sysctl.conf ...

下载、安装和配置组件

说明： 本部分链接到提供 Kubernetes 所需功能的第三方项目。Kubernetes 项目作者不负责这些项目。此页面遵循CNCF 网站指南，按字母顺序列出项目。要将项目添加到此列表中，请在提交更改之前阅读内容指南。

安装容器运行时

下载所需软件包的最新可用版本（推荐）。

本教程建议安装 CRI-O 容器运行时（外部链接）。

根据你安装的特定 Linux 发行版，有几种安装容器运行时的方式。尽管 CRI-O 推荐使用 deb 或 rpm 包，但本教程使用 CRI-O Packaging 项目中的静态二进制包脚本，以简化整个安装过程，并保持与 Linux 发行版无关。

此脚本安装并配置更多必需的软件，例如容器联网所用的 cni-plugins 以及运行容器所用的 crun 和 runc。

此脚本将自动检测系统的处理器架构（amd64 或 arm64），并选择和安装最新版本的软件包。

设置 CRI-O

查阅发布版本页面（外部链接）。

下载静态二进制包脚本：

curl https://raw.githubusercontent.com/cri-o/packaging/main/get > crio-install

运行安装器脚本：

sudo bash crio-install

启用并启动 crio 服务：

sudo systemctl daemon-reload
sudo systemctl enable --now crio.service

快速测试：

sudo systemctl is-active crio.service

输出类似于：

active

详细的服务检查：

sudo journalctl -f -u crio.service

安装网络插件

cri-o 安装器安装并配置 cni-plugins 包。你可以通过运行以下命令来验证安装包：

/opt/cni/bin/bridge --version

输出类似于：

CNI bridge plugin v1.5.1
CNI protocol versions supported: 0.1.0, 0.2.0, 0.3.0, 0.3.1, 0.4.0, 1.0.0

检查默认配置：

cat /etc/cni/net.d/11-crio-ipv4-bridge.conflist

输出类似于：

{
  "cniVersion": "1.0.0",
  "name": "crio",
  "plugins": [
    {
      "type": "bridge",
      "bridge": "cni0",
      "isGateway": true,
      "ipMasq": true,
      "hairpinMode": true,
      "ipam": {
        "type": "host-local",
        "routes": [
            { "dst": "0.0.0.0/0" }
        ],
        "ranges": [
            [{ "subnet": "10.85.0.0/16" }]
        ]
      }
    }
  ]
}

说明：

确保默认的 subnet 范围（10.85.0.0/16）不会与你已经在使用的任一网络地址重叠。如果出现重叠，你可以编辑此文件并进行相应的更改。更改后重启服务。

下载并设置 kubelet

下载 kubelet 的最新稳定版本。

x86-64
ARM64


curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubelet"


curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/arm64/kubelet"

配置：

sudo mkdir -p /etc/kubernetes/manifests

sudo tee /etc/kubernetes/kubelet.yaml <<EOF
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
authentication:
  webhook:
    enabled: false # 请勿在生产集群中使用！
authorization:
  mode: AlwaysAllow # 请勿在生产集群中使用！
enableServer: false
logging:
  format: text
address: 127.0.0.1 # 限制对 localhost 的访问
readOnlyPort: 10255 # 请勿在生产集群中使用！
staticPodPath: /etc/kubernetes/manifests
containerRuntimeEndpoint: unix:///var/run/crio/crio.sock
EOF

说明：

由于你搭建的不是一个生产集群，所以你可以使用明文 HTTP（readOnlyPort: 10255）对 kubelet API 进行不做身份认证的查询。

为了顺利完成本次教学，身份认证 Webhook 被禁用，鉴权模式被设置为 AlwaysAllow。你可以进一步了解鉴权模式和 Webhook 身份认证，以正确地配置 kubelet 在你的环境中以独立模式运行。

参阅端口和协议以了解 Kubernetes 组件使用的端口。

安装：

chmod +x kubelet
sudo cp kubelet /usr/bin/

创建 systemd 服务单元文件：

sudo tee /etc/systemd/system/kubelet.service <<EOF
[Unit]
Description=Kubelet

[Service]
ExecStart=/usr/bin/kubelet \
 --config=/etc/kubernetes/kubelet.yaml
Restart=always

[Install]
WantedBy=multi-user.target
EOF

服务配置文件中故意省略了命令行参数 --kubeconfig。此参数设置 kubeconfig 文件的路径，指定如何连接到 API 服务器，以启用 API 服务器模式。省略此参数将启用独立模式。

启用并启动 kubelet 服务：

sudo systemctl daemon-reload
sudo systemctl enable --now kubelet.service

快速测试：

sudo systemctl is-active kubelet.service

输出类似于：

active

详细的服务检查：

sudo journalctl -u kubelet.service

检查 kubelet 的 API /healthz 端点：

curl http://localhost:10255/healthz?verbose

输出类似于：

[+]ping ok
[+]log ok
[+]syncloop ok
healthz check passed

查询 kubelet 的 API /pods 端点：

curl http://localhost:10255/pods | jq '.'

输出类似于：

{
  "kind": "PodList",
  "apiVersion": "v1",
  "metadata": {},
  "items": null
}

在 kubelet 中运行 Pod

在独立模式下，你可以使用 Pod 清单运行 Pod。这些清单可以放在本地文件系统上，或通过 HTTP 从配置源获取。

为 Pod 创建一个清单：

cat <<EOF > static-web.yaml
apiVersion: v1
kind: Pod
metadata:
  name: static-web
spec:
  containers:
    - name: web
      image: nginx
      ports:
        - name: web
          containerPort: 80
          protocol: TCP
EOF

将 static-web.yaml 清单文件复制到 /etc/kubernetes/manifests 目录。

sudo cp static-web.yaml /etc/kubernetes/manifests/

查找 kubelet 和 Pod 的信息

Pod 网络插件为每个 Pod 创建一个网络桥（cni0）和一对 veth 接口（这对接口的其中一个接口在新创建的 Pod 内，另一个接口在主机层面）。

查询 kubelet 的 API 端点 http://localhost:10255/pods：

curl http://localhost:10255/pods | jq '.'

要获取 static-web Pod 的 IP 地址：

curl http://localhost:10255/pods | jq '.items[].status.podIP'

输出类似于：

"10.85.0.4"

连接到 nginx 服务器 Pod，地址为 http://<IP>:<Port>（端口 80 是默认端口），在本例中为：

curl http://10.85.0.4

输出类似于：

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
...

了解更多细节

如果你需要排查在学习本教程时遇到的问题，你可以在以下目录中查找监控和故障排查资料：

/var/lib/cni
/var/lib/containers
/var/lib/kubelet

/var/log/containers
/var/log/pods

清理

kubelet

sudo systemctl disable --now kubelet.service
sudo systemctl daemon-reload
sudo rm /etc/systemd/system/kubelet.service
sudo rm /usr/bin/kubelet
sudo rm -rf /etc/kubernetes
sudo rm -rf /var/lib/kubelet
sudo rm -rf /var/log/containers
sudo rm -rf /var/log/pods

容器运行时

sudo systemctl disable --now crio.service
sudo systemctl daemon-reload
sudo rm -rf /usr/local/bin
sudo rm -rf /usr/local/lib
sudo rm -rf /usr/local/share
sudo rm -rf /usr/libexec/crio
sudo rm -rf /etc/crio
sudo rm -rf /etc/containers

网络插件

sudo rm -rf /opt/cni
sudo rm -rf /etc/cni
sudo rm -rf /var/lib/cni

结论

本页涵盖了以独立模式部署 kubelet 的各个基本方面。你现在可以部署 Pod 并测试更多功能。

请注意，在独立模式下，kubelet 不支持从控制平面获取 Pod 配置（因为没有控制平面连接）。

你还不能使用 ConfigMap 或 Secret 来配置静态 Pod 中的容器。

接下来

跟随你好，Minikube 学习如何在有控制平面的情况下运行 Kubernetes。minikube 工具帮助你在自己的计算机上搭建一个练习集群。
进一步了解网络插件
进一步了解容器运行时
进一步了解 kubelet
进一步了解静态 Pod

8 - Service

8.1 - 使用 Service 连接到应用

Kubernetes 连接容器的模型

既然有了一个持续运行、可复制的应用，我们就能够将它暴露到网络上。

Kubernetes 假设 Pod 可与其它 Pod 通信，不管它们在哪个主机上。 Kubernetes 给每一个 Pod 分配一个集群私有 IP 地址，所以没必要在 Pod 与 Pod 之间创建连接或将容器的端口映射到主机端口。这意味着同一个 Pod 内的所有容器能通过 localhost 上的端口互相连通，集群中的所有 Pod 也不需要通过 NAT 转换就能够互相看到。本文档的剩余部分详述如何在上述网络模型之上运行可靠的服务。

本教程使用一个简单的 Nginx 服务器来演示概念验证原型。

在集群中暴露 Pod

我们在之前的示例中已经做过，然而让我们以网络连接的视角再重做一遍。创建一个 Nginx Pod，注意其中包含一个容器端口的规约：

service/networking/run-my-nginx.yaml

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 上。这意味着你可以使用相同的 containerPort 在同一个节点上运行多个 Nginx Pod，并且可以从集群中任何其他的 Pod 或节点上使用为 Pod 分配的 IP 地址访问到它们。如果你想的话，你依然可以将宿主节点的某个端口的流量转发到 Pod 中，但是出于网络模型的原因，你不必这么做。

如果对此好奇，请参考 Kubernetes 网络模型。

创建 Service

我们有一组在一个扁平的、集群范围的地址空间中运行 Nginx 服务的 Pod。理论上，你可以直接连接到这些 Pod，但如果某个节点宕机会发生什么呢？ Pod 会终止，Deployment 内的 ReplicaSet 将创建新的 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 文件创建：

service/networking/nginx-svc.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 完全是虚拟的，它从来没有走过网络，如果对它如何工作的原理感到好奇，可以进一步阅读服务代理的内容。

访问 Service

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

DNS

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 --rm

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

保护 Service

到现在为止，我们只在集群内部访问了 Nginx 服务器。在将 Service 暴露到因特网之前，我们希望确保通信信道是安全的。为实现这一目的，需要：

用于 HTTPS 的自签名证书（除非已经有了一个身份证书）
使用证书配置的 Nginx 服务器
使 Pod 可以访问证书的 Secret

你可以从 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

你可以在 Kubernetes examples 项目代码仓库中找到 default.conf 示例。

configmap/nginxconfigmap created

kubectl get configmaps

NAME             DATA   AGE
nginxconfigmap   1      114s

你可以使用以下命令来查看 nginxconfigmap ConfigMap 的细节：

kubectl describe configmap  nginxconfigmap

输出类似于：

Name:         nginxconfigmap
Namespace:    default
Labels:       <none>
Annotations:  <none>

Data
====
default.conf:
----
server {
        listen 80 default_server;
        listen [::]:80 default_server ipv6only=on;

        listen 443 ssl;

        root /usr/share/nginx/html;
        index index.html;

        server_name localhost;
        ssl_certificate /etc/nginx/ssl/tls.crt;
        ssl_certificate_key /etc/nginx/ssl/tls.key;

        location / {
                try_files $uri $uri/ =404;
        }
}

BinaryData
====

Events:  <none>

以下是你在运行 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：

service/networking/nginx-secure-app.yaml

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 清单，值得注意的几点如下：

它将 Deployment 和 Service 的规约放在了同一个文件中。
Nginx 服务器通过 80 端口处理 HTTP 流量，通过 443 端口处理 HTTPS 流量，而 Nginx Service 则暴露了这两个端口。
每个容器能通过挂载在 /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）：

service/networking/curlpod.yaml

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

对应用的某些部分，你可能希望将 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
...

接下来

8.2 - 使用源 IP

运行在 Kubernetes 集群中的应用程序通过 Service 抽象发现彼此并相互通信，它们也用 Service 与外部世界通信。本文解释了发送到不同类型 Service 的数据包的源 IP 会发生什么情况，以及如何根据需要切换此行为。

准备开始

术语表

本文使用了下列术语：

NAT: 网络地址转换
Source NAT: 替换数据包上的源 IP；在本页面中，这通常意味着替换为节点的 IP 地址
Destination NAT: 替换数据包上的目标 IP；在本页面中，这通常意味着替换为 Pod 的 IP 地址
VIP: 一个虚拟 IP 地址，例如分配给 Kubernetes 中每个 Service 的 IP 地址
Kube-proxy: 一个网络守护程序，在每个节点上协调 Service VIP 管理

先决条件

示例使用一个小型 nginx Web 服务器，服务器通过 HTTP 标头返回它接收到的请求的源 IP。你可以按如下方式创建它：

kubectl create deployment source-ip-app --image=registry.k8s.io/echoserver:1.10

输出为：

deployment.apps/source-ip-app created

教程目标

通过多种类型的 Service 暴露一个简单应用
了解每种 Service 类型如何处理源 IP NAT
了解保留源 IP 所涉及的权衡

`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:nodePort
node2 使用它自己的 IP 地址替换数据包的源 IP 地址（SNAT）
node2 将数据包上的目标 IP 替换为 Pod IP
数据包被路由到 node1，然后到端点
Pod 的回复被路由回 node2
Pod 的回复被发送回给客户端

用图表示：

图 1：源 IP NodePort — 如图。使用 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:nodePort
数据包被丢弃
客户端发送数据包到必有端点的 node1:nodePort
node1 使用正确的源 IP 地址将数据包路由到端点

用图表示：

图 2：源 IP 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，故意导致健康检查失败，从而强制没有端点的节点把自己从负载均衡流量的可选节点列表中删除。

用图表示：

具有 externalTrafficPolicy 的源 IP

你可以通过设置注解进行测试：

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

接下来

详细了解通过 Service 连接应用程序
阅读如何创建外部负载均衡器

8.3 - 探索 Pod 及其端点的终止行为

一旦你参照使用 Service 连接到应用中概述的那些步骤使用 Service 连接到了你的应用，你就有了一个持续运行的多副本应用暴露在了网络上。本教程帮助你了解 Pod 的终止流程，探索实现连接排空的几种方式。

Pod 及其端点的终止过程

你经常会遇到需要终止 Pod 的场景，例如为了升级或缩容。为了改良应用的可用性，实现一种合适的活跃连接排空机制变得重要。

本教程将通过使用一个简单的 nginx Web 服务器演示此概念，解释 Pod 终止的流程及其与相应端点状态和移除的联系。

端点终止的示例流程

以下是 Pod 终止文档中所述的流程示例。

假设你有包含单个 nginx 副本（仅用于演示目的）的一个 Deployment 和一个 Service：

service/pod-with-graceful-termination.yaml

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"
              ]

service/explore-graceful-termination-nginx.yaml

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80

现在使用以上文件创建 Deployment Pod 和 Service：

kubectl apply -f pod-with-graceful-termination.yaml
kubectl apply -f explore-graceful-termination-nginx.yaml

一旦 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 被删除时，旧的端点也会被删除。