为您的应用程序指定中断预算

此页面展示了如何限制应用程序经历的并发中断数量，从而在允许集群管理员管理集群节点的同时实现更高的可用性。

开始之前

• 你是 Kubernetes 集群上运行的、需要高可用性的应用程序的所有者。
• 你应该知道如何部署复制的无状态应用程序和/或复制的有状态应用程序。
• 你应该阅读过Pod 中断。
• 你应该与你的集群所有者或服务提供商确认他们是否尊重 Pod 中断预算。

使用 PodDisruptionBudget 保护应用程序

1. 确定要使用 PodDisruptionBudget (PDB) 保护的应用程序。
2. 考虑你的应用程序如何响应中断。
3. 以 YAML 文件形式创建 PDB 定义。
4. 从 YAML 文件创建 PDB 对象。

确定要保护的应用程序

当你想要保护由内置 Kubernetes 控制器之一指定的应用程序时，最常见的情况

• Deployment
• ReplicationController
• ReplicaSet
• StatefulSet

在这种情况下，记下控制器的 .spec.selector；相同的选择算符放入 PDB 的 .spec.selector 中。

从 1.15 版本开始，PDB 支持启用了规模子资源的自定义控制器。

你也可以将 PDB 与不受上述控制器之一控制的 Pod 或任意 Pod 组一起使用，但有一些限制，详见 任意工作负载和任意选择算符。

考虑你的应用程序如何响应中断

确定由于自愿中断，在短时间内可以同时关闭多少个实例。

• 无状态前端
  • 关注点：不要将服务能力降低超过 10%。
    • 解决方案：例如，使用 minAvailable 为 90% 的 PDB。
• 单实例有状态应用程序
  • 关注点：不要在没有和我商量的情况下终止此应用程序。
    • 可能的解决方案 1：不要使用 PDB 并容忍偶尔的停机时间。
    • 可能的解决方案 2：将 PDB 设置为 maxUnavailable=0。在 Kubernetes 之外达成共识，集群操作员需要在终止前咨询你。当集群操作员联系你时，为停机做好准备，然后删除 PDB 以指示已准备好中断。之后重新创建。
• 多实例有状态应用程序，例如 Consul、ZooKeeper 或 etcd
  • 关注点：不要将实例数量减少到仲裁数量以下，否则写入会失败。
    • 可能的解决方案 1：将 maxUnavailable 设置为 1（适用于应用程序的不同规模）。
    • 可能的解决方案 2：将 minAvailable 设置为仲裁大小（例如，当规模为 5 时为 3）。（允许一次发生更多中断）。
• 可重启的批处理作业
  • 关注点：在发生自愿中断时，作业需要完成。
    • 可能的解决方案：不要创建 PDB。作业控制器将创建一个替换 Pod。

指定百分比时的舍入逻辑

minAvailable 或 maxUnavailable 的值可以表示为整数或百分比。

• 当你指定一个整数时，它表示 Pod 的数量。例如，如果你将 minAvailable 设置为 10，则即使在中断期间，也必须始终有 10 个 Pod 可用。
• 当你通过将值设置为百分比的字符串表示形式（例如 "50%"）指定百分比时，它表示 Pod 总数的百分比。例如，如果你将 minAvailable 设置为 "50%"，则在中断期间，至少有 50% 的 Pod 保持可用。

当你将值指定为百分比时，它可能无法映射到 Pod 的确切数量。例如，如果你有 7 个 Pod，并将 minAvailable 设置为 "50%"，则不清楚这意味着必须有 3 个 Pod 可用还是 4 个 Pod 可用。Kubernetes 会向上舍入到最接近的整数，因此在本例中，必须有 4 个 Pod 可用。当你将值 maxUnavailable 指定为百分比时，Kubernetes 会向上舍入可能中断的 Pod 数量。因此，中断可能会超出你定义的 maxUnavailable 百分比。你可以检查控制此行为的代码。

指定 PodDisruptionBudget

PodDisruptionBudget 有三个字段

• 标签选择算符 .spec.selector，用于指定它所适用的 Pod 集。此字段为必需字段。
• .spec.minAvailable，它描述了该集合中在驱逐后仍然必须可用的 Pod 数量，即使在没有被驱逐的 Pod 的情况下也是如此。minAvailable 可以是绝对数量或百分比。
• .spec.maxUnavailable（在 Kubernetes 1.7 及更高版本中可用），它描述了驱逐后可能不可用的集合中的 Pod 数量。它可以是绝对数量或百分比。

你可以在单个 PodDisruptionBudget 中仅指定 maxUnavailable 和 minAvailable 中的一个。maxUnavailable 只能用于控制驱逐那些有相关控制器管理它们的 Pod。在下面的示例中，“期望副本数”是管理被 PodDisruptionBudget 的 selector 选择的 Pod 的控制器的 scale。

示例 1：当 minAvailable 为 5 时，只要在 PodDisruptionBudget 的 selector 选择的 Pod 中留下 5 个或更多健康的 Pod，就允许驱逐。

示例 2：当 minAvailable 为 30% 时，只要至少有 30% 的期望副本数是健康的，就允许驱逐。

示例 3：当 maxUnavailable 为 5 时，只要在期望副本总数中最多有 5 个不健康的副本，就允许驱逐。

示例 4：当 maxUnavailable 为 30% 时，只要不健康副本的数量不超过期望副本总数的 30%（向上舍入到最接近的整数），就允许驱逐。如果期望副本总数只有一个，则仍然允许中断该单个副本，从而导致有效不可用性为 100%。

在典型用法中，单个预算将用于由控制器管理的 Pod 集合，例如，单个 ReplicaSet 或 StatefulSet 中的 Pod。

如果你将 maxUnavailable 设置为 0% 或 0，或者将 minAvailable 设置为 100% 或副本数，则表示需要零自愿驱逐。当你为诸如 ReplicaSet 之类的工作负载对象设置零自愿驱逐时，则无法成功排空运行其中一个 Pod 的节点。如果你尝试排空运行不可驱逐的 Pod 的节点，则排空永远不会完成。根据 PodDisruptionBudget 的语义，这是允许的。

你可以在下面找到定义的 Pod 中断预算的示例。它们匹配带有标签 app: zookeeper 的 Pod。

使用 minAvailable 的 PDB 示例

policy/zookeeper-pod-disruption-budget-minavailable.yaml

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: zk-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: zookeeper

使用 maxUnavailable 的 PDB 示例

policy/zookeeper-pod-disruption-budget-maxunavailable.yaml

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: zk-pdb
spec:
  maxUnavailable: 1
  selector:
    matchLabels:
      app: zookeeper

例如，如果上面的 zk-pdb 对象选择大小为 3 的 StatefulSet 的 Pod，则两个规范的含义完全相同。建议使用 maxUnavailable，因为它会自动响应相应控制器的副本数的变化。

创建 PDB 对象

你可以使用 kubectl 创建或更新 PDB 对象。

kubectl apply -f mypdb.yaml

检查 PDB 的状态

使用 kubectl 检查是否已创建 PDB。

假设你的命名空间中实际上没有匹配 app: zookeeper 的 Pod，那么你将看到类似这样的内容

kubectl get poddisruptionbudgets

NAME     MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
zk-pdb   2               N/A               0                     7s

如果有匹配的 Pod（例如，3 个），那么你将看到类似这样的内容

kubectl get poddisruptionbudgets

NAME     MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
zk-pdb   2               N/A               1                     7s

ALLOWED DISRUPTIONS 的非零值表示中断控制器已查看 Pod、计算了匹配的 Pod，并更新了 PDB 的状态。

您可以使用此命令获取有关 PDB 状态的更多信息

kubectl get poddisruptionbudgets zk-pdb -o yaml

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  annotations:
…
  creationTimestamp: "2020-03-04T04:22:56Z"
  generation: 1
  name: zk-pdb
…
status:
  currentHealthy: 3
  desiredHealthy: 2
  disruptionsAllowed: 1
  expectedPods: 3
  observedGeneration: 1

Pod 的健康状况

当前实现将健康的 Pod 视为具有 .status.conditions 项且 type="Ready" 和 status="True" 的 Pod。这些 Pod 通过 PDB 状态中的 .status.currentHealthy 字段进行跟踪。

不健康 Pod 驱逐策略

保护应用程序的 PodDisruptionBudget 确保 .status.currentHealthy Pod 的数量不低于 .status.desiredHealthy 中指定的数量，方法是不允许驱逐健康的 Pod。通过使用 .spec.unhealthyPodEvictionPolicy，您还可以定义何时应考虑驱逐不健康的 Pod 的标准。未指定策略时的默认行为对应于 IfHealthyBudget 策略。

策略

IfHealthyBudget

只有在受保护的应用程序未中断（.status.currentHealthy 至少等于 .status.desiredHealthy）时，才能驱逐正在运行的 Pod (.status.phase="Running")，但尚未健康的 Pod。

此策略确保已中断的应用程序的正在运行的 Pod 有最佳机会变得健康。这对于排空节点有负面影响，可能会被由 PDB 保护的不良行为应用程序阻塞。更具体地说，例如处于 CrashLoopBackOff 状态（由于错误或配置错误）的应用程序的 Pod，或只是无法报告 Ready 状态的 Pod。

AlwaysAllow

正在运行的 Pod (.status.phase="Running")，但尚未健康的 Pod 被视为已中断，无论是否满足 PDB 中的标准，都可以将其驱逐。

这意味着已中断应用程序的潜在运行 Pod 可能没有机会变得健康。通过使用此策略，集群管理器可以轻松驱逐由 PDB 保护的不良行为应用程序。更具体地说，例如处于 CrashLoopBackOff 状态（由于错误或配置错误）的应用程序的 Pod，或只是无法报告 Ready 状态的 Pod。

任意工作负载和任意选择器

如果您仅将 PDB 与内置的工作负载资源（Deployment、ReplicaSet、StatefulSet 和 ReplicationController）或使用实现了 scale 子资源的自定义资源，并且 PDB 选择器与 Pod 的拥有资源的选择器完全匹配，则可以跳过本节。

您可以使用由另一个资源、“操作器”或裸 Pod 控制的 PDB，但有以下限制

• 只能使用 .spec.minAvailable，不能使用 .spec.maxUnavailable。
• 只能将整数值与 .spec.minAvailable 一起使用，不能使用百分比。

无法使用其他可用性配置，因为 Kubernetes 无法在没有支持的拥有资源的情况下推导出 Pod 的总数。

您可以使用选择器来选择属于工作负载资源的 Pod 的子集或超集。驱逐 API 将不允许驱逐多个 PDB 覆盖的任何 Pod，因此大多数用户都希望避免选择器重叠。重叠 PDB 的一个合理用途是在 Pod 从一个 PDB 转换到另一个 PDB 时。