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

教程

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
验证配置已经被正确应用

准备开始

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

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

你的 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 版本，请查阅该版本的文档。

准备开始

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

kind
kubectl

本教程演示了你可以对完全由你控制的 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
kubectl

创建集群

按照如下方式创建一个 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/ 的目录中，以便将它们加载到集群中。

执行这些命令： ubernetes/website/main/content/zh-cn/examples/pods/security/seccomp/profiles/audit.json" download="pods/security/seccomp/profiles/audit.json">pods/security/seccomp/profiles/audit.json class="icon-copycode" onclick="copyCode('pods-security-seccomp-profiles-audit-json')" title="复制 pods/security/seccomp/profiles/audit.json 到剪贴板">

eccomp-profiles-audit-json">