Kubernetes 1.26：由 PodDisruptionBudgets 保护的非健康 Pod 驱逐策略

确保应用中断不会影响其可用性并非易事。上个月发布的 Kubernetes v1.26 允许您为 PodDisruptionBudgets (PDBs) 指定非健康 Pod 驱逐策略，以帮助您在节点管理操作期间保持可用性。在本文中，我们将深入探讨 PDB 为赋予应用所有者在管理中断方面更大的灵活性而引入了哪些修改。

这解决了什么问题？

由 API 发起的 Pod 驱逐会遵循 PodDisruptionBudgets (PDBs)。这意味着通过对 Pod 进行驱逐所请求的自愿中断不应中断受 PDB 保护的应用，并且 PDB 的 .status.currentHealthy 不应低于 .status.desiredHealthy。状态为不健康的运行中 Pod 不计入 PDB 状态，但只有在应用未被中断的情况下才能对其进行驱逐。这有助于已经中断或尚未启动的应用尽快达到可用状态，而不会因驱逐造成额外的停机时间。

不幸的是，这给希望在无需任何手动干预的情况下排空节点的集群管理员带来了问题。行为异常、Pod 处于 CrashLoopBackOff 状态（由于 Bug 或错误配置）的应用，或根本无法变为 Ready 的 Pod，使得这项任务变得更加困难。当应用的所有 Pod 都不健康时，任何驱逐请求都会因违反 PDB 而失败。在这种情况下，节点排空将无法进行。

另一方面，有些用户依赖现有行为，以便

• 防止因删除正在守护底层资源或存储的 Pod 而导致数据丢失
• 为其应用实现最佳可用性

Kubernetes 1.26 在 PodDisruptionBudget API 中引入了一个新的实验性字段：.spec.unhealthyPodEvictionPolicy。启用后，该字段允许您同时满足上述两种需求。

它是如何工作的？

由 API 发起的驱逐是触发优雅 Pod 终止的过程。该过程可以通过直接调用 API、使用 kubectl drain 命令或集群中的其他参与者来启动。在此过程中，每次移除 Pod 都会咨询相应的 PDB，以确保集群中始终运行着足够数量的 Pod。

以下策略允许 PDB 作者更好地控制该过程如何处理不健康的 Pod。

有两种策略可供选择：IfHealthyBudget 和 AlwaysAllow。

前者 IfHealthyBudget 遵循现有行为，以实现您默认获得的最大可用性。只有当应用拥有最小可用 .status.desiredHealthy 数量的 Pod 时，不健康的 Pod 才能被中断。

将 PDB 的 spec.unhealthyPodEvictionPolicy 字段设置为 AlwaysAllow，意味着您选择为您的应用提供尽力而为的可用性。采用此策略，始终可以驱逐不健康的 Pod。这将使维护和升级集群变得更加容易。

我们认为 AlwaysAllow 通常是更好的选择，但对于某些关键工作负载，您可能仍然希望保护甚至不健康的 Pod 免受节点排空或其他形式的 API 发起驱逐的影响。

如何使用它？

这是一个 Alpha 特性，这意味着您必须通过向 kube-apiserver 添加命令行参数 --feature-gates=PDBUnhealthyPodEvictionPolicy=true 来启用 PDBUnhealthyPodEvictionPolicy 特性门控。

下面是一个示例。假设您已在集群中启用了特性门控，并且已经定义了一个运行普通 Web 服务器的 Deployment。您使用 app: nginx 标签标记了该 Deployment 的 Pods。您希望限制可避免的中断，并且您知道尽力而为的可用性对于此应用是足够的。您决定即使这些 Web 服务器 Pods 不健康，也允许对其进行驱逐。您创建一个 PDB 来守护此应用，并为其不健康的 Pods 设置 AlwaysAllow 驱逐策略

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: nginx-pdb
spec:
  selector:
    matchLabels:
      app: nginx
  maxUnavailable: 1
  unhealthyPodEvictionPolicy: AlwaysAllow

如何了解更多信息？

• 阅读 KEP：PDB 的非健康 Pod 驱逐策略
• 阅读文档：PodDisruptionBudgets 的非健康 Pod 驱逐策略
• 查阅 Kubernetes 文档中关于 PodDisruptionBudgets、Node 排空 和 驱逐 的内容

如何参与？

如果您有任何反馈，请通过 Slack 上的 #sig-apps 频道联系我们（如果您需要邀请，请访问 https://slack.k8s.io/），或通过 SIG Apps 邮件列表联系我们：kubernetes-sig-apps@googlegroups.com

• ←上一篇
• 下一篇→