借助 Pod 删除事件的传播实现 Pod 摘流
共 4655字,需浏览 10分钟
·
2021-03-31 14:00
原文标题:Gracefully Shutting Down Pods in a Kubernetes Cluster
发布时间:Jan 26, 2019
原文链接:https://blog.gruntwork.io/delaying-shutdown-to-wait-for-pod-deletion-propagation-445f779a8304
文章作者:yorinasub17
这是实现「 Kubernetes 集群零停机时间更新」系列文章的第三部分。在本系列的第二部分中,我们通过利用 Pod 生命周期钩子实现了应用程序Pod的正常终止,从而减轻了由于 Pod 未处理完已存请求而直接关机而导致的停机时间。但是,我们还了解到,在启动关闭序列后,Pod 会拒绝为新到来的流量提供服务,但实际情况是 Pod 仍然可能会继续接收到新流量。这意味着最终客户端可能会收到错误消息,因为它们的请求被路由到了不再能为流量提供服务的Pod。理想情况下,我们希望 Pod 在启动关闭后立即停止接收流量。为了减轻这种情况,我们必须首先了解为什么会发生Pod开始关闭时仍然会接收到新流量这个问题。
这篇文章中的很多信息都是从「 Kubernetes in Action」一书中学到的。除了在这里介绍的信息外,本书还提供了在 Kubernetes 上运行应用程序的最佳实践,因此强烈建议您阅读此书。
Pod关闭序列
在上篇文章「如何优雅地关闭Pod」中我们介绍了 Pod 被驱逐的生命周期,逐出序列的第一步是开始删除 Pod ,这会引发一系列事件,最终导致 Pod 从系统中删除。但是,上篇文章里我们没有谈论到的是,如何从上层的 Service 控制器中注销 Pod,使得 Pod 能停止接收流量。
译注:我的理解是要在Pod真正停止运行前,要先把它从Service上拿掉,也就是摘流。
那么,是什么情况会导致 Pod 从 Service 中注销掉呢?要了解这一点,我们需要更深入一层,来了解从集群中删除Pod时都发生了什么。
通过 Kubernetes 的 API 将 Pod 从群集中删除后,该 Pod 在元数据服务器中被标记为要删除。这会向所有相关子系统发送一个 Pod 删除通知,然后处理该通知:
译注:这里说的元数据服务器,指的应该是Kubernetes APIServer,而子系统则是Kubernetes的一些核心组件。
Pod 所在节点上的 kubelet
将启动上一篇文章中描述的 Pod 关闭序列。所有节点上运行的 kube-proxy
守护程序将从 iptables 中删除 Pod的 IP 地址。端点控制器将从有效端点列表中删除该 Pod,反映到我们这个例子中来就是从 Service 管控的端点(endpoint)列表中移除这个 Pod 端点。
我们无需了解每个系统的详细信息。这里的重点是涉及多个子系统,这些系统可能在不同的节点上运行,而上面列举的这些操作是会并行发生的。因此,在将 Pod 从所有活动列表中删除之前,Pod 很有可能已经开始执行 preStop 钩子并接收到了 TERM 信号。这就是即使 Pod 在启动关闭序列后,仍继续接收到流量的原因。
摘流方案
从表面上看,我们可以将上面那些事件序列串联起来,禁止他们并行进行,直到从所有相关子系统注销了要删除的 Pod 之后,再开始 Pod 的关闭序列。但是,由于 Kuberenetes 系统的分布式性质,在实践中很难做到这一点。如果节点之一遇到网络阻隔会怎样?是否要无限期地等待事件传播?如果该节点重新恢复联机怎么办?如果你的Kubernetes 集群有成千上万个节点怎么办?
不幸的是,现实情况是并不存在防止所有中断的完美解决方案。但是,我们可以做的是在 Pod 关闭序列中引入足够的延迟,以捕获99%的情况。为此,我们在preStop挂钩中引入了一个 sleep指令,以延迟 Pod 关闭序列。接下来,让我们看看在我们的例子中它是如何工作的。
我们会更新一直以来使用的资源定义文件,使用sleep 命令引入延迟来作为要执行的 preStop 钩子的一部分。在「 Kubernetes in Action」中,作者 Lukša
建议使用5到10秒的延迟,因此在这里我们将使用5秒延迟作为 preStop 钩子的一部分:
lifecycle:
preStop:
exec:
command: [
"sh", "-c",
# Introduce a delay to the shutdown sequence to wait for the
# pod eviction event to propagate. Then, gracefully shutdown
# nginx.
"sleep 5 && /usr/sbin/nginx -s quit",
]
现在,让我们推演一下这个示例关闭序列中会发生什么。像上一篇文章的分析一样,我们将使用kubectl drain
逐出节点上的 Pod。这将会发送一个Pod deletion 事件,该事件会同时通知给 kubelet 和 Endpoint Controller(端点控制器,这里指的是 Pod 上层的 Service控制器)。在此,我们假设 preStop 钩子在 Service 从自己可用列表中移除 Pod 之前启动。
在 preStop 钩子执行时,首先会延迟5秒执行第二条关闭Nginx的命令。在这个期间,Service 将会从自己的可用列表中移除 Pod。
在此延迟期间,Pod 仍处于运行状态,因此即使其接收到新的连接请求,它仍能够处理连接。此外,在将 Pod 从Service 中移除后,客户端的连接请求,将不会路由到将要关闭的 Pod 上。因此,在这种情况下,假如 Service 在延迟期间内处理完这些事件,集群将不会有停机时间。
最后,preStop 钩子进程从休眠中醒来并执行关闭 Nginx 容器,从节点中删除容器:
此时,我们就可以安全地在Node1上进行任何升级,包括重启节点加载新的内核版本。如果我们已经启动了一个新节点来容纳Node1运行的工作负载,那么我们也可以关闭Node1节点。
重新创建Pod
如果你已经看到了这里,你可能想知道如何重新创建最初被调度到维护节点上的 Pod。现在,我们知道了如何正常关闭 Pod,但是如果要维持运行中的 Pod 的数量,该怎么办?这就要靠 Deployment 控制器发挥作用了。
Deployment 控制器负责在集群上维护指定的期望状态,如果你能回想起我们的资源定义文件里的内容,你会发现我们不是直接创建的 Pod。取而代之的是我们通过给 Deployment 提供创建Pod的模板,让它来自动为我们管理 Pod。下面是定义中的 Pod 模板部分的内容:
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.15
ports:
- containerPort: 80
模板指定了创建一个运行nginx:1.15
镜像的容器的Pod,指定 Pod 携带的标签为app:nginx
,向外暴露80端口。
除了Pod模板之外,我们还为 Deployment 资源提供了一个配置,用于指定应维护的 Pod 副本数:
spec:
replicas: 2
这会通知 Deployment 控制器它应始终维持有两个 Pod 运行在集群上。每当运行的 Pod 数量下降时,Deployment 控制器都会自动创建一个新的Pod来替换它。因此,在我们这个例中,当我们使用 kubectl drain
操作从节点上驱逐 Pod 时,Deployment 控制器会在其他可用节点上自动重新创建 Pod,保持当前状态与定义里指定的期望状态一直。
总结
总而言之,在 preStop 钩子有足够的延迟和正常终止的情况下,我们现在能在单个节点上正常关闭 Pod 了。利用Deployment,我们可以自动重新创建被关闭的 Pod。但是,如果我们想一次替换集群中的所有节点怎么办?
如果我们天真地重启所有节点,因为服务负载均衡器可能没有可用的Pod,而导致系统停机。更糟糕的是,对于有状态的系统,这样操作可能会让仲裁机制失效。
为了处理这种情况,Kubernetes 提供了一个称为PodDisruptionBudgets
的功能,该功能指定了在任何给定时间点 Kubernetes 可以承受的关闭的 Pod 数量的上线。在本系列的下一也是最后一部分,我们将介绍如何使用它来控制同时发生的节点驱逐事件的数量。