本文发表于一年多前。旧文章可能包含过时内容。请检查页面中的信息自发布以来是否已变得不正确。

Kubernetes 1.26:由 PodDisruptionBudgets 保护的不健康 Pod 的驱逐策略

确保应用程序的中断不影响其可用性并非易事。上个月发布的 Kubernetes v1.26 允许你为 PodDisruptionBudgets(PDB)指定一个**不健康 Pod 驱逐策略**,以帮助你在节点管理操作期间保持可用性。在本文中,我们将深入探讨对 PDB 引入了哪些修改,以便为应用程序所有者提供更大的灵活性来管理中断。

这解决了什么问题?

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

不幸的是,这给希望在没有任何手动干预的情况下排空节点的集群管理员带来了问题。行为不当的应用程序(由于 bug 或配置错误导致 Pod 处于 CrashLoopBackOff 状态)或根本无法就绪的 Pod 使这项任务变得更加困难。当应用程序的所有 Pod 都不健康时,任何驱逐请求都会因违反 PDB 而失败。在这种情况下,节点的排空无法取得任何进展。

另一方面,有些用户依赖于现有行为,以便:

  • 防止因删除保护底层资源或存储的 Pod 而导致的数据丢失
  • 为他们的应用程序实现最佳的可用性

Kubernetes 1.26 在 PodDisruptionBudget API 中引入了一个新的实验性字段:.spec.unhealthyPodEvictionPolicy。启用后,该字段可以让你同时支持这两种需求。

它是如何工作的?

通过 API 发起的驱逐是触发 Pod 优雅终止的过程。该过程可以通过直接调用 API、使用 kubectl drain 命令或集群中的其他角色来启动。在此过程中,每次移除 Pod 都会与适当的 PDBs 进行协商,以确保集群中始终有足够数量的 Pod 在运行。

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

有两种策略可供选择:IfHealthyBudgetAlwaysAllow

前者,IfHealthyBudget,遵循现有行为以实现你默认获得的最佳可用性。只有当应用程序具有最小可用 .status.desiredHealthy 数量的 Pod 时,才能中断不健康的 Pod。

通过将 PDB 的 spec.unhealthyPodEvictionPolicy 字段设置为 AlwaysAllow,你是在为你的应用程序选择尽力而为的可用性。使用此策略,始终可以驱逐不健康的 Pod。这将使维护和升级你的集群变得更加容易。

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

我该如何使用它?

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

这里有一个例子。假设你已经在集群中启用了该特性门控,并且已经定义了一个运行普通 Web 服务器的 Deployment。你为该 Deployment 的 Pod 添加了标签 app: nginx。你希望限制可避免的中断,并且你知道尽力而为的可用性对于此应用已经足够。你决定即使这些 Web 服务器 Pod 不健康也允许驱逐。你创建一个 PDB 来保护此应用程序,并为驱逐不健康的 Pod 设置 AlwaysAllow 策略。

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

我如何了解更多信息?

我如何参与?

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