本文已超过一年。较旧的文章可能包含过时的内容。检查页面中的信息自发布以来是否已变得不正确。
Kubernetes 1.26:由 PodDisruptionBudgets 保护的不健康 Pod 的驱逐策略
确保应用程序的中断不会影响其可用性并非易事。上个月发布的 Kubernetes v1.26 允许您为 PodDisruptionBudgets (PDB) 指定不健康的 pod 驱逐策略,以帮助您在节点管理操作期间保持该可用性。在本文中,我们将深入探讨为 PDB 引入了哪些修改,以使应用程序所有者在管理中断时具有更大的灵活性。
这解决了什么问题?
API 发起的 Pod 驱逐会遵守 PodDisruptionBudget(PDB)。这意味着通过驱逐 Pod 发起的自愿中断请求不应中断受保护的应用程序,并且 PDB 的 .status.currentHealthy
不应低于 .status.desiredHealthy
。运行中的 不健康 的 Pod 不会计入 PDB 状态,但只有在不中断应用程序的情况下才能驱逐这些 Pod。这有助于已中断或尚未启动的应用程序尽快实现可用性,而不会因驱逐而导致额外的停机时间。
不幸的是,这给希望在没有任何人工干预的情况下排空节点的集群管理员带来了一个问题。行为不端的应用程序,其 Pod 处于 CrashLoopBackOff
状态(由于错误或配置错误)或只是无法就绪的 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 功能,这意味着你必须使用命令行参数 --feature-gates=PDBUnhealthyPodEvictionPolicy=true
启用 kube-apiserver 的 PDBUnhealthyPodEvictionPolicy
功能门。
这是一个示例。假设你已在集群中启用了功能门,并且你已经定义了一个运行普通 Web 服务器的 Deployment。你使用 app: nginx
标记了该 Deployment 的 Pod。你希望限制可避免的中断,并且你知道此应用程序的最佳可用性就足够了。你决定允许驱逐,即使那些 Web 服务器 Pod 不健康。你创建一个 PDB 来保护此应用程序,并使用 AlwaysAllow
策略来驱逐不健康的 Pod。
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、排空节点和 驱逐 的信息
如何参与?
如果你有任何反馈,请通过 Slack 上的 #sig-apps 频道联系我们(如果需要邀请,请访问 https://slack.k8s.io/),或通过 SIG Apps 邮件列表:[email protected]