pod-disruption-budget
weight: 20
title: Pod 中断与PDB (Pod 中断预算)
date: “2022-05-21T00:00:00+08:00”
type: book
这篇文档适用于要构建高可用应用程序的所有者,因此他们需要了解
自愿中断和非自愿中断
我们把这些不可避免的情况称为应用的非自愿性中断。例如:
- 后端节点物理机的硬件故障
- 集群管理员错误地删除虚拟机(实例)
- 云提供商或管理程序故障使虚拟机消失
- 内核恐慌(kernel panic)
- 节点由于集群网络分区而从集群中消失
- 由于节点资源不足而将容器逐出
除资源不足的情况外,大多数用户应该都熟悉以下这些情况;它们不是特定于
我们称这些情况为”自愿中断“。包括由应用程序所有者发起的操作和由集群管理员发起的操作。典型的应用程序所有者操作包括:
- 删除管理该
pod 的Deployment 或其他控制器 - 更新了
Deployment 的pod 模板导致pod 重启 - 直接删除
pod (意外删除)
集群管理员操作包括:
- 排空(drain)节点进行修复或升级。
- 从集群中排空节点以缩小集群。
- 从节点中移除一个
pod ,以允许其他pod 使用该节点。
这些操作可能由集群管理员直接执行,也可能由集群管理员或集群托管提供商自动执行。
询问您的集群管理员或咨询您的云提供商或发行文档,以确定是否为您的集群启用了任何自动中断源。如果没有启用,您可以跳过创建
处理中断
以下是一些减轻非自愿性中断的方法:
- 确保您的
pod 请求所需的资源。 - 如果您需要更高的可用性,请复制您的应用程序
。 (了解有关运行复制的无状态和有状态应用程序的信息。 ) - 为了在运行复制应用程序时获得更高的可用性,请跨机架(使用反亲和性)或跨区域(如果使用多区域集群)分布应用程序。
自愿中断的频率各不相同。在
中断预算的工作原理
应用程序所有者可以为每个应用程序创建一个 PodDisruptionBudget
对象(PDB
集群管理器和托管提供商应使用遵循 Pod Disruption Budgets
的工具,方法是调用Eviction API而不是直接删除kubectl drain
命令和cluster/gce/upgrade.sh
当集群管理员想要排空节点时,可以使用 kubectl drain
命令。该命令会试图驱逐机器上的所有
spec.replicas:5
的
使用标签选择器来指定应用程序的一组
.spec.replicas
计算“预期的” .metadata.ownerReferences
值从控制器获取。
由于应用程序的滚动升级而被删除或不可用的
使用驱逐terminationGracePeriodSeconds
PDB 示例
假设集群有node-1
到 node-3
。集群中运行了一些应用,其中一个应用有pod-a
、pod-b
和 pod-c
。另外,还有一个与它相关的不具有pod-x
。最初,所有
node-1 | node-2 | node-3 |
---|---|---|
pod-a available | pod-b available | pod-c available |
pod-x available |
所有的
例如,假设集群管理员想要重启系统,升级内核版本来修复内核中的错误。集群管理员首先使用 kubectl drain
命令尝试排除 node-1
。该工具试图驱逐 pod-a
和 pod-x
。这立即成功。两个
node-1 draining | node-2 | node-3 |
---|---|---|
pod-a terminating | pod-b available | pod-c available |
pod-x terminating |
pod-d
来替换。由于 node-1
被封锁(cordonpod-y
作为 pod-x
的替代品。
(注意:对于 StatefulSet
,pod-a
将被称为 pod-1
,需要在替换之前完全终止,替代它的也称为 pod-1
,但是具有不同的
当前集群的状态如下:
node-1 draining | node-2 | node-3 |
---|---|---|
pod-a terminating | pod-b available | pod-c available |
pod-x terminating | pod-d starting | pod-y |
在某一时刻,
node-1 drained | node-2 | node-3 |
---|---|---|
pod-b available | pod-c available | |
pod-d starting | pod-y |
此时,如果一个急躁的集群管理员试图排空(drain)node-2
或 node-3
,pod-d
变得可用。
node-1 drained | node-2 | node-3 |
---|---|---|
pod-b available | pod-c available | |
pod-d available | pod-y |
现在,集群管理员尝试排空 node-2
。pod-b
,然后再 pod-d
。它将成功驱逐 pod-b
。但是,当它试图驱逐 pod-d
时,将被拒绝,因为这样对
pod-e
的 pod-b
的替代品。但是,集群中没有足够的资源来安排 pod-e
。那么,
node-1 drained | node-2 drained | node-3 | no node |
---|---|---|---|
pod-c available | pod-e pending | ||
pod-d available | pod-y |
此时,集群管理员需要向集群中添加回一个节点以继续升级操作。
您可以看到
- 应用程序需要多少副本
- 正常关闭实例需要多长时间
- 启动新实例需要多长时间
- 控制器的类型
- 集群的资源能力
分离集群所有者和应用程序所有者角色
将集群管理者和应用程序所有者视为彼此知识有限的独立角色通常是很有用的。这种责任分离在这些情况下可能是有意义的:
- 当有许多应用程序团队共享一个
Kubernetes 集群,并且有自然的专业角色 - 使用第三方工具或服务来自动化集群管理
Pod Disruption Budget(
如果您的组织中没有这样的职责分离,则可能不需要使用
如何在集群上执行中断操作
如果您是集群管理员,要对集群的所有节点执行中断操作,例如节点或系统软件升级,则可以使用以下选择:
- 在升级期间接受停机时间。
- 故障转移到另一个完整的副本集群。
- 没有停机时间,但是对于重复的节点和人工协调成本可能是昂贵的。
- 编写可容忍中断的应用程序和使用
PDB 。- 没有停机时间。
- 最小的资源重复。
- 允许更多的集群管理自动化。
- 编写可容忍中断的应用程序是很棘手的,但对于可容忍自愿中断,和支持自动调整以容忍非自愿中断,两者在工作上有大量的重叠。
参考
-
通过配置Pod Disruption Budget(
Pod 中断预算)来执行保护应用程序的步骤。 -
了解更多关于排空节点的信息。