这是本节的多页打印视图。
点击此处打印 .
返回本页常规视图 .
教程 Kubernetes 文档的这一部分包含教程。
每个教程展示了如何完成一个比单个任务 更大的目标。
通常一个教程有几个部分,每个部分都有一系列步骤。在浏览每个教程之前,
你可能希望将标准化术语表 页面添加到书签,供以后参考。
基础知识 配置 构造 Pod 无状态应用程序 有状态应用程序 服务 安全 集群管理 接下来 如果你要编写教程,请参阅内容页面类型
以获取有关教程页面类型的信息。
1 - 你好,Minikube 本教程向你展示如何使用 Minikube 在 Kubernetes 上运行一个应用示例。
教程提供了容器镜像,使用 NGINX 来对所有请求做出回应。
教程目标 将一个示例应用部署到 Minikube。 运行应用程序。 查看应用日志。 准备开始 本教程假设你已经安装了 minikube
。
有关安装说明,请参阅 minikube start 的步骤 1 。
说明: 仅执行步骤 1:安装 中的说明,其余内容均包含在本页中。
你还需要安装 kubectl
。
有关安装说明,请参阅安装工具 。
创建 Minikube 集群 打开仪表板 打开 Kubernetes 仪表板。你可以通过两种不同的方式执行此操作:
打开一个新的 终端,然后运行:
# 启动一个新的终端,并保持此命令运行。
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:
输出结果类似于这样:
NAME READY UP-TO-DATE AVAILABLE AGE
hello-node 1/1 1 1 1m
(该 Pod 可能需要一些时间才能变得可用。如果你在输出结果中看到 “0/1”,请在几秒钟后重试。)
查看 Pod:
输出结果类似于这样:
NAME READY STATUS RESTARTS AGE
hello-node-5f76cf6ccf-br9b5 1/1 Running 0 1m
查看集群事件:
查看 kubectl
配置:
查看 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
创建 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:
输出结果类似于这样:
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 环境中启用、禁用和打开。
列出当前支持的插件:
输出结果类似于这样:
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
的输出:
输出类似于:
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 虚拟机(VM):
如果你还想使用 Minikube 进一步学习 Kubernetes,那就不需要删除 Minikube。
结论 本页介绍了启动和运行 minikube 集群的基本知识,现在部署应用的准备工作已经完成。
接下来 2 - 学习 Kubernetes 基础知识 Kubernetes 基础 本教程介绍了 Kubernetes 集群编排系统的基础知识。每个模块包含关于 Kubernetes 主要特性和概念的一些背景信息,并包括一个在线互动教程。这些互动教程让你可以自己管理一个简单的集群及其容器化应用程序。
使用互动教程,你可以学习:
在集群上部署容器化应用程序 弹性部署 使用新的软件版本,更新容器化应用程序 调试容器化应用程序 这些教程使用 Katacoda 在你的浏览器中运行一个运行着 Minikube 的虚拟终端,Minikube 是 Kubernetes 的一个小规模本地部署,可以运行在任何地方。不需要安装任何软件或进行任何配置;每个交互性教程都直接从你的网页浏览器上运行。
Kubernetes 可以为你做些什么? 通过现代的 Web 服务,用户希望应用程序能够 24/7 全天候使用,开发人员希望每天可以多次发布部署新版本的应用程序。 容器化可以帮助软件包达成这些目标,使应用程序能够以简单快速的方式发布和更新,而无需停机。Kubernetes 帮助你确保这些容器化的应用程序在你想要的时间和地点运行,并帮助应用程序找到它们需要的资源和工具。Kubernetes 是一个可用于生产的开源平台,根据 Google 容器集群方面积累的经验,以及来自社区的最佳实践而设计。
2.1 - 创建集群 了解 Kubernetes 集群 并使用 Minikube
创建一个简单的集群。
2.1.1 - 使用 Minikube 创建集群 了解 Kubernetes 集群。
了解 Minikube。
启动一个 Kubernetes 集群。
目标 了解 Kubernetes 集群。 了解 Minikube。 在你的电脑上开启一个 Kubernetes 集群。 Kubernetes 集群 Kubernetes 协调一个高可用计算机集群,每个计算机作为独立单元互相连接工作。
Kubernetes 中的抽象允许你将容器化的应用部署到集群,而无需将它们绑定到某个特定的独立计算机。
为了使用这种新的部署模型,应用需要以将应用与单个主机分离的方式打包:它们需要被容器化。
与过去的那种应用直接以包的方式深度与主机集成的部署模型相比,容器化应用更灵活、更可用。
Kubernetes 以更高效的方式跨集群自动分发和调度应用容器。
Kubernetes 是一个开源平台,并且可应用于生产环境。
一个 Kubernetes 集群包含两种类型的资源:
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 ,
试试。
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 提供了一种与众不同的应用管理方法。
你可以使用 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 中讲述。
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 是一个或多个应用容器(例如 Docker)的组合,包括共享存储(卷)、IP 地址和有关如何运行它们的信息。
节点 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 为一组 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 手动扩缩现有的应用
扩缩应用 之前我们创建了一个 Deployment ,
然后通过 Service 让其可以公开访问。
Deployment 仅创建了一个 Pod 用于运行这个应用。当流量增加时,我们需要扩容应用满足用户需求。
如果你还没有学习过之前的章节,
从使用 Minikube 创建集群 开始。
扩缩 是通过改变 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 执行滚动更新。
更新应用程序 用户希望应用程序始终可用,而开发人员则需要每天多次部署它们的新版本。
在 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 的唯一容器中。
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 的环境变量 使用 kubectl create configmap
命令基于字面值 创建一个
ConfigMap:
kubectl create configmap fruits --from-literal= fruits = apples
下面是一个 Deployment 清单的示例,包含一个通过 ConfigMap fruits
配置的环境变量。
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 文件。
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 文件。
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 的示例清单。
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 的唯一容器中。
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:
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:
你应该看到输出会同时显示新旧 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
.
真实世界的案例:使用 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
公开。
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:
同样,查看 maxmemory-policy
:
127.0.0.1:6379> CONFIG GET maxmemory-policy
它也应该显示默认值 noeviction
:
1) "maxmemory-policy"
2) "noeviction"
现在,向 example-redis-config
ConfigMap 添加一些配置:
apiVersion : v1
kind : ConfigMap
metadata :
name : example-redis-config
data :
redis-config : |
maxmemory 2mb
maxmemory-policy allkeys-lru
应用更新的 ConfigMap:
kubectl apply -f example-redis-config.yaml
确认 ConfigMap 已更新:
kubectl describe configmap/example-redis-config
你应该可以看到我们刚刚添加的配置:
Name: example-redis-config
Namespace: default
Labels: <none>
Annotations: <none>
Data
====
redis-config:
----
maxmemory 2mb
maxmemory-policy allkeys-lru
通过 kubectl exec
使用 redis-cli
再次检查 Redis Pod,查看是否已应用配置:
kubectl exec -it redis -- redis-cli
查看 maxmemory
:
127.0.0.1:6379> CONFIG GET maxmemory
它保持默认值 0:
同样,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
接下来 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)。通用边车注入器的想法是在注入一个普通容器的同时注入一个原生边车容器,并在运行时决定哪个容器会生效。
通用边车注入器虽然浪费资源(因为它会两次计算请求量),但在某些特殊情况下可以视为可行的解决方案。 接下来 4 - 安全 对于运行 Kubernetes 集群的大多数组织和人员来说,安全是一个重要问题。
你可以在 Kubernetes 文档的其他地方找到基本的安全检查清单 。
要了解如何部署和管理 Kubernetes 的安全的方方面面,你可以按照本部分中的教程进行操作。
4.1 - 在集群级别应用 Pod 安全标准 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'.
获取集群中的名字空间列表:
输出类似于:
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:
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
接下来 4.2 - 在名字空间级别应用 Pod 安全标准 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
接下来 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 node -o jsonpath = '{.items[*].status.addresses[?(.type == "Hostname")].address}' ) )
for NODE in ${ NODES [*]} ; do ssh $NODE 'sudo apparmor_parser -q <<EOF
#include <tunables/global>
profile k8s-apparmor-example-deny-write flags=(attach_disconnected) {
#include <abstractions/base>
file,
# Deny all file writes.
deny /** w,
}
EOF'
done
接下来,运行一个带有拒绝写入配置文件的简单 “Hello AppArmor” Pod:
apiVersion : v1
kind : Pod
metadata :
name : hello-apparmor
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/
的目录中,以便将它们加载到集群中。
{
"defaultAction" : "SCMP_ACT_LOG"
}
{
"defaultAction" : "SCMP_ACT_ERRNO"
}
{
"defaultAction" : "SCMP_ACT_ERRNO" ,
"architectures" : [
"SCMP_ARCH_X86_64" ,
"SCMP_ARCH_X86" ,
"SCMP_ARCH_X32"
],
"syscalls" : [
{
"names" : [
"accept4" ,
"epoll_wait" ,
"pselect6" ,
"futex" ,
"madvise" ,
"epoll_ctl" ,
"getsockname" ,
"setsockopt" ,
"vfork" ,
"mmap" ,
"read" ,
"write" ,
"close" ,
"arch_prctl" ,
"sched_getaffinity" ,
"munmap" ,
"brk" ,
"rt_sigaction" ,
"rt_sigprocmask" ,
"sigaltstack" ,
"gettid" ,
"clone" ,
"bind" ,
"socket" ,
"openat" ,
"readlinkat" ,
"exit_group" ,
"epoll_create1" ,
"listen" ,
"rt_sigreturn" ,
"sched_yield" ,
"clock_gettime" ,
"connect" ,
"dup2" ,
"epoll_pwait" ,
"execve" ,
"exit" ,
"fcntl" ,
"getpid" ,
"getuid" ,
"ioctl" ,
"mprotect" ,
"nanosleep" ,
"open" ,
"poll" ,
"recvfrom" ,
"sendto" ,
"set_tid_address" ,
"setitimer" ,
"writev"
],
"action" : "SCMP_ACT_ALLOW"
}
]
}
执行这些命令:
mkdir ./profiles
curl -L -o profiles/audit.json https://k8s.io/examples/pods/security/seccomp/profiles/audit.json
curl -L -o profiles/violation.json https://k8s.io/examples/pods/security/seccomp/profiles/violation.json
curl -L -o profiles/fine-grained.json https://k8s.io/examples/pods/security/seccomp/profiles/fine-grained.json
ls profiles
你应该看到在最后一步的末尾列出有三个配置文件:
audit.json fine-grained.json violation.json
使用 kind 创建本地 Kubernetes 集群 为简单起见,kind 可用来创建加载了 seccomp 配置文件的单节点集群。
Kind 在 Docker 中运行 Kubernetes,因此集群的每个节点都是一个容器。
这允许将文件挂载到每个容器的文件系统中,类似于将文件加载到节点上。
apiVersion : kind.x-k8s.io/v1alpha4
kind : Cluster
nodes :
- role : control-plane
extraMounts :
- hostPath : "./profiles"
containerPath : "/var/lib/kubelet/seccomp/profiles"
下载该示例 kind 配置,并将其保存到名为 kind.yaml
的文件中:
curl -L -O https://k8s.io/examples/pods/security/seccomp/kind.yaml
你可以通过设置节点的容器镜像来设置特定的 Kubernetes 版本。
有关此类配置的更多信息,
参阅 kind 文档中节点 小节。
本篇教程假定你正在使用 Kubernetes v1.31。
作为 Beta 特性,你可以将 Kubernetes
配置为使用容器运行时 默认首选的配置文件,
而不是回退到 Unconfined
。
如果你想尝试,请在继续之前参阅
启用使用 RuntimeDefault
作为所有工作负载的默认 seccomp 配置文件 。
有了 kind 配置后,使用该配置创建 kind 集群:
kind create cluster --config= kind.yaml
新的 Kubernetes 集群准备就绪后,找出作为单节点集群运行的 Docker 容器:
你应该看到输出中名为 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 配置文件:
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 的清单:
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 上。
此演示的清单是:
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
。
此示例的清单是:
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
此 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 应用:
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 的集群,且必须配置 kubectl 命令行工具让其与你的集群通信。
建议运行本教程的集群至少有两个节点,且这两个节点不能作为控制平面主机。
如果你还没有集群,你可以通过 Minikube
构建一个你自己的集群,或者你可以使用下面的 Kubernetes 练习环境之一:
你的 Kubernetes 服务器版本必须不低于版本 v1.14.
要获知版本信息,请输入
kubectl version
.
启动 Redis 数据库 留言板应用使用 Redis 存储数据。
创建 Redis Deployment 下面包含的清单文件指定了一个 Deployment 控制器,该控制器运行一个 Redis Pod 副本。
# 来源:https://cloud.google.com/kubernetes-engine/docs/tutorials/guestbook
apiVersion : apps/v1
kind : Deployment
metadata :
name : redis-leader
labels :
app : redis
role : leader
tier : backend
spec :
replicas : 1
selector :
matchLabels :
app : redis
template :
metadata :
labels :
app : redis
role : leader
tier : backend
spec :
containers :
- name : leader
image : "docker.io/redis:6.0.5"
resources :
requests :
cpu : 100m
memory : 100Mi
ports :
- containerPort : 6379
在下载清单文件的目录中启动终端窗口。
从 redis-leader-deployment.yaml
文件中应用 Redis Deployment:
kubectl apply -f https://k8s.io/examples/application/guestbook/redis-leader-deployment.yaml
查询 Pod 列表以验证 Redis Pod 是否正在运行:
响应应该与此类似:
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 的策略。
# 来源: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 服务是否正在运行:
响应应该与此类似:
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 跟随者来将其配置为高可用状态,
以满足流量需求。
# 来源: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 跟随者副本在运行:
响应应该类似于这样:
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 。
# 来源: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 服务在运行:
响应应该类似于这样:
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 # 来源: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
。
# 来源: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 列表以验证前端服务正在运行:
响应应该与此类似:
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 的数量:
响应应该类似于这样:
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 的数量:
响应应该类似于这样:
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 在运行:
响应应该是:
No resources found in default namespace.
接下来
6 - 有状态的应用 6.1 - StatefulSet 基础 本教程介绍了如何使用
StatefulSet
来管理应用。
演示了如何创建、删除、扩容/缩容和更新 StatefulSet 的 Pod。
准备开始 在开始本教程之前,你应该熟悉以下 Kubernetes 的概念:
你必须拥有一个 Kubernetes 的集群,且必须配置 kubectl 命令行工具让其与你的集群通信。
建议运行本教程的集群至少有两个节点,且这两个节点不能作为控制平面主机。
如果你还没有集群,你可以通过 Minikube
构建一个你自己的集群,或者你可以使用下面的 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 地址。
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:
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:
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
:
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 的主机名都是不同的且可预测的)。
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:
删除本教程中用到的 PersistentVolume 卷的持久化存储介质:
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
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
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 重启、重新调度甚至删除过程中用于保存数据。
说明: 本教程中提供的文件使用 GA Deployment API,并且特定于 kubernetes 1.9 或更高版本。
如果你希望将本教程与 Kubernetes 的早期版本一起使用,请相应地更新 API 版本,或参考本教程的早期版本。
教程目标 创建 PersistentVolumeClaims 和 PersistentVolumes 创建 kustomization.yaml
以使用Secret 生成器 MySQL 资源配置 WordPress 资源配置 kubectl apply -k ./
来应用整个 kustomization 目录清理 准备开始
你必须拥有一个 Kubernetes 的集群,且必须配置 kubectl 命令行工具让其与你的集群通信。
建议运行本教程的集群至少有两个节点,且这两个节点不能作为控制平面主机。
如果你还没有集群,你可以通过 Minikube
构建一个你自己的集群,或者你可以使用下面的 Kubernetes 练习环境之一:
要获知版本信息,请输入
kubectl version
.
此例在 kubectl
1.27 或者更高版本有效。
下载下面的配置文件:
mysql-deployment.yaml
wordpress-deployment.yaml
创建 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 设置数据库密码。
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 设置数据库密码。
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 数据库的所有资源。你可以通过以下方式应用目录:
现在,你可以验证所有对象是否存在。
通过运行以下命令验证 Secret 是否存在:
响应应如下所示:
NAME TYPE DATA AGE
mysql-pass-c57bb4t7mf Opaque 1 9s
验证是否已动态制备 PersistentVolume:
响应应如下所示:
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 是否正在运行:
说明: 等待 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:
接下来 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 。 准备开始 你必须拥有一个 Kubernetes 的集群,且必须配置 kubectl 命令行工具让其与你的集群通信。
建议运行本教程的集群至少有两个节点,且这两个节点不能作为控制平面主机。
如果你还没有集群,你可以通过 Minikube
构建一个你自己的集群,或者你可以使用下面的 Kubernetes 练习环境之一:
要完成本教程,你应该已经熟悉 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 查找:
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。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
接下来 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 。
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 cordon
隔离你的集群中除 4 个节点以外的所有节点。
kubectl cordon <node-name>
使用下面的命令获取 zk-pdb
PodDisruptionBudget
。
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
)访问权限。 有权限访问互联网以下载本教程所需的组件,例如: 准备好系统 配置内存交换 默认情况下,如果在节点上检测到内存交换,kubelet 将启动失败。
这意味着内存交换应该被禁用或被 kubelet 容忍。
说明: 如果你配置 kubelet 为容忍内存交换,则 kubelet 仍会配置 Pod(以及这些 Pod 中的容器)不使用交换空间。
要了解 Pod 实际上可以如何使用可用的交换,你可以进一步阅读 Linux
节点上交换内存管理 。
如果你启用了交换内存,则禁用它或在 kubelet 配置文件中添加 failSwapOn: false
。
要检查交换内存是否被启用:
如果此命令没有输出,则交换内存已被禁用。
临时禁用交换内存:
要使此变更持续到重启之后:
确保在 /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
将变更应用到系统:
输出类似于:
...
* 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
运行安装器脚本:
启用并启动 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 的最新稳定版本 。
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/
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 是默认端口),在本例中为:
输出类似于:
<!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 中的容器。
接下来
8 - Service 8.1 - 使用 Service 连接到应用 Kubernetes 连接容器的模型 既然有了一个持续运行、可复制的应用,我们就能够将它暴露到网络上。
Kubernetes 假设 Pod 可与其它 Pod 通信,不管它们在哪个主机上。
Kubernetes 给每一个 Pod 分配一个集群私有 IP 地址,所以没必要在
Pod 与 Pod 之间创建连接或将容器的端口映射到主机端口。
这意味着同一个 Pod 内的所有容器能通过 localhost 上的端口互相连通,集群中的所有 Pod
也不需要通过 NAT 转换就能够互相看到。
本文档的剩余部分详述如何在上述网络模型之上运行可靠的服务。
本教程使用一个简单的 Nginx 服务器来演示概念验证原型。
在集群中暴露 Pod 我们在之前的示例中已经做过,然而让我们以网络连接的视角再重做一遍。
创建一个 Nginx Pod,注意其中包含一个容器端口的规约:
apiVersion : apps/v1
kind : Deployment
metadata :
name : my-nginx
spec :
selector :
matchLabels :
run : my-nginx
replicas : 2
template :
metadata :
labels :
run : my-nginx
spec :
containers :
- name : my-nginx
image : nginx
ports :
- containerPort : 80
这使得可以从集群中任何一个节点来访问它。检查节点,该 Pod 正在运行:
kubectl apply -f ./run-my-nginx.yaml
kubectl get pods -l run = my-nginx -o wide
NAME READY STATUS RESTARTS AGE IP NODE
my-nginx-3800858182-jr4a2 1/1 Running 0 13s 10.244.3.4 kubernetes-minion-905m
my-nginx-3800858182-kna2y 1/1 Running 0 13s 10.244.2.5 kubernetes-minion-ljyd
检查 Pod 的 IP 地址:
kubectl get pods -l run = my-nginx -o custom-columns= POD_IP:.status.podIPs
POD_IP
[ map[ ip:10.244.3.4]]
[ map[ ip:10.244.2.5]]
你应该能够通过 ssh 登录到集群中的任何一个节点上,并使用诸如 curl
之类的工具向这两个 IP 地址发出查询请求。
需要注意的是,容器 不会 使用该节点上的 80 端口,也不会使用任何特定的 NAT 规则去路由流量到 Pod 上。
这意味着你可以使用相同的 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 文件创建:
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 资源:
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
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
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:
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):
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 管理 先决条件 你必须拥有一个 Kubernetes 的集群,且必须配置 kubectl 命令行工具让其与你的集群通信。
建议运行本教程的集群至少有两个节点,且这两个节点不能作为控制平面主机。
如果你还没有集群,你可以通过 Minikube
构建一个你自己的集群,或者你可以使用下面的 Kubernetes 练习环境之一:
示例使用一个小型 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 模式。
输出类似于:
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 的回复被发送回给客户端 用图表示:
如图。使用 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 地址将数据包路由到端点 用图表示:如图。源 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):
输出类似于:
CLIENT VALUES:
client_address=10.240.0.5
...
然而,如果你在 Google Kubernetes Engine/GCE 上运行,
将相同的 service.spec.externalTrafficPolicy
字段设置为 Local
,
故意导致健康检查失败,从而强制没有端点的节点把自己从负载均衡流量的可选节点列表中删除。
用图表示:
你可以通过设置注解进行测试:
kubectl patch svc loadbalancer -p '{"spec":{"externalTrafficPolicy":"Local"}}'
你应该能够立即看到 Kubernetes 分配的 service.spec.healthCheckNodePort
字段:
kubectl get svc loadbalancer -o yaml | grep -i healthCheckNodePort
输出类似于:
healthCheckNodePort : 32122
service.spec.healthCheckNodePort
字段指向每个在 /healthz
路径上提供健康检查的节点的端口。你可以这样测试:
kubectl get pod -o wide -l app = source-ip-app
输出类似于:
NAME READY STATUS RESTARTS AGE IP NODE
source-ip-app-826191075-qehz4 1/1 Running 0 20h 10.180.1.136 kubernetes-node-6jst
使用 curl
获取各个节点上的 /healthz
端点:
# 在你选择的节点上本地运行
curl localhost:32122/healthz
1 Service Endpoints found
在不同的节点上,你可能会得到不同的结果:
# 在你选择的节点上本地运行
curl localhost:32122/healthz
No Service Endpoints Found
在控制平面 上运行的控制器负责分配云负载均衡器。
同一个控制器还在每个节点上分配指向此端口/路径的 HTTP 健康检查。
等待大约 10 秒,让 2 个没有端点的节点健康检查失败,然后使用 curl
查询负载均衡器的 IPv4 地址:
输出类似于:
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
接下来 8.3 - 探索 Pod 及其端点的终止行为 一旦你参照使用 Service 连接到应用 中概述的那些步骤使用
Service 连接到了你的应用,你就有了一个持续运行的多副本应用暴露在了网络上。
本教程帮助你了解 Pod 的终止流程,探索实现连接排空的几种方式。
Pod 及其端点的终止过程 你经常会遇到需要终止 Pod 的场景,例如为了升级或缩容。
为了改良应用的可用性,实现一种合适的活跃连接排空机制变得重要。
本教程将通过使用一个简单的 nginx Web 服务器演示此概念,
解释 Pod 终止的流程及其与相应端点状态和移除的联系。
端点终止的示例流程 以下是 Pod 终止 文档中所述的流程示例。
假设你有包含单个 nginx 副本(仅用于演示目的)的一个 Deployment 和一个 Service:
apiVersion : apps/v1
kind : Deployment
metadata :
name : nginx-deployment
labels :
app : nginx
spec :
replicas : 1
selector :
matchLabels :
app : nginx
template :
metadata :
labels :
app : nginx
spec :
terminationGracePeriodSeconds : 120 # 超长优雅期
containers :
- name : nginx
image : nginx:latest
ports :
- containerPort : 80
lifecycle :
preStop :
exec :
# 实际生产环境中的 Pod 终止可能需要执行任何时长,但不会超过 terminationGracePeriodSeconds。
# 在本例中,只需挂起至少 terminationGracePeriodSeconds 所指定的持续时间,
# 在 120 秒时容器将被强制终止。
# 请注意,在所有这些时间点 nginx 都将继续处理请求。
command : [
"/bin/sh" , "-c" , "sleep 180"
]
apiVersion : 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:
输出类似于:
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 被删除时,旧的端点也会被删除。
接下来