K8s 1.31：针对 Job 的 Pod 失效策略进阶至 GA

作者：Michał Woźniak^[1] (Google),Shannon Kularathna^[2] (Google)

译者：Michael Yao^[3] (DaoCloud)

这篇博文阐述在 Kubernetes 1.31 中进阶至 Stable 的 Pod 失效策略，还介绍如何在你的 Job 中使用此策略。

关于 Pod 失效策略

当你在 Kubernetes 上运行工作负载时，Pod 可能因各种原因而失效。理想情况下，像 Job 这样的工作负载应该能够忽略瞬时的、可重试的失效，并继续运行直到完成。

要允许这些瞬时的失效，Kubernetes Job 需包含 backoffLimit 字段， 此字段允许你指定在 Job 执行期间你愿意容忍的 Pod 失效次数。然而， 如果你为 backoffLimit 字段设置了一个较大的值，并完全依赖这个字段， 你可能会发现，由于在满足 backoffLimit 条件之前 Pod 重启次数太多，导致运营成本发生不必要的增加。

在运行大规模的、包含跨数千节点且长时间运行的 Pod 的 Job 时，这个问题尤其严重。

Pod 失效策略扩展了回退限制机制，帮助你通过以下方式降低成本：

• 让你在出现不可重试的 Pod 失效时控制 Job 失败。
• 允许你忽略可重试的错误，而不增加 backoffLimit 字段。

例如，通过忽略由节点体面关闭^[4]引起的 Pod 失效，你可以使用 Pod 失效策略在更实惠的临时机器上运行你的工作负载。

此策略允许你基于失效 Pod 中的容器退出码或 Pod 状况来区分可重试和不可重试的 Pod 失效。

它是如何工作的

你在 Job 规约中指定的 Pod 失效策略是一个规则的列表。

对于每个规则，你基于以下属性之一来定义匹配条件：

• 容器退出码：onExitCodes 属性。
• Pod 状况：onPodConditions 属性。

此外，对于每个规则，你要指定在 Pod 与此规则匹配时应采取的动作，可选动作为以下之一：

• Ignore：不将失效计入 backoffLimit 或 backoffLimitPerIndex。
• FailJob：让整个 Job 失败并终止所有运行的 Pod。
• FailIndex：与失效 Pod 对应的索引失效。
  此动作与逐索引回退限制^[5]特性一起使用。
• Count：将失效计入 backoffLimit 或 backoffLimitPerIndex。这是默认行为。

当在运行的 Job 中发生 Pod 失效时，Kubernetes 按所给的顺序将失效 Pod 的状态与 Pod 失效策略规则的列表进行匹配，并根据匹配的第一个规则采取相应的动作。

请注意，在指定 Pod 失效策略时，你还必须在 Job 的 Pod 模板中设置 restartPolicy: Never。此字段可以防止在对 Pod 失效计数时在 kubelet 和 Job 控制器之间出现竞争条件。

Kubernetes 发起的 Pod 干扰

为了允许将 Pod 失效策略规则与由 Kubernetes 引发的干扰所导致的失效进行匹配， 此特性引入了 DisruptionTarget Pod 状况。

Kubernetes 会将此状况添加到因可重试的干扰场景^[6]而失效的所有 Pod，无论其是否由 Job 控制器管理。其中 DisruptionTarget 状况包含与这些干扰场景对应的以下原因之一：

• PreemptionByKubeScheduler：由 kube-scheduler抢占^[7]以接纳更高优先级的新 Pod。
• DeletionByTaintManager - Pod 因其不容忍的 NoExecute污点^[8]而被 kube-controller-manager 删除。
• EvictionByEvictionAPI - Pod 因为 API 发起的驱逐^[9]而被删除。
• DeletionByPodGC - Pod 被绑定到一个不再存在的节点，并将通过Pod 垃圾收集^[10]而被删除。
• TerminationByKubelet - Pod 因节点体面关闭^[11]、节点压力驱逐^[12]或被系统关键 Pod^[13]抢占

在所有其他干扰场景中，例如因超过Pod 容器限制^[14]而驱逐， Pod 不会收到 DisruptionTarget 状况，因为干扰可能是由 Pod 引起的，并且在重试时会再次发生干扰。

示例

下面的 Pod 失效策略片段演示了一种用法：

podFailurePolicy:
  rules:
  - action: Ignore
    onPodConditions:
    - type: DisruptionTarget
  - action: FailJob
    onPodConditions:
    - type: ConfigIssue
  - action: FailJob
    onExitCodes:
      operator: In
      values: [ 42 ]

在这个例子中，Pod 失效策略执行以下操作：

• 忽略任何具有内置 DisruptionTarget 状况的失效 Pod。这些 Pod 不计入 Job 回退限制。
• 如果任何失效的 Pod 具有用户自定义的、由自定义控制器或 Webhook 添加的 ConfigIssue状况，则让 Job 失败。
• 如果任何容器以退出码 42 退出，则让 Job 失败。
• 将所有其他 Pod 失效计入默认的 backoffLimit（在合适的情况下，计入 backoffLimitPerIndex）。

进一步了解

• 有关使用 Pod 失效策略的实践指南， 参见使用 Pod 失效策略处理可重试和不可重试的 Pod 失效^[15]
• 阅读文档：Pod 失效策略^[16]和逐索引回退限制^[17]
• 阅读文档：Pod 干扰状况^[18]
• 阅读 KEP：Pod 失效策略^[19]

相关工作

基于 Pod 失效策略所引入的概念，正在进行中的进一步工作如下：

• JobSet 集成：可配置的失效策略 API^[20]
• 扩展 Pod 失效策略以添加更细粒度的失效原因^[21]
• 通过 JobSet 在 Kubeflow Training v2^[22]中支持 Pod 失效策略
• 提案：受干扰的 Pod 应从端点中移除^[23]

参与其中

这项工作由 Batch Working Group（批处理工作组）^[24] 发起， 与 SIG Apps^[25]、SIG Node^[26]和 SIG Scheduling^[27]社区密切合作。

如果你有兴趣处理这个领域中的新特性，建议你订阅我们的Slack^[28] 频道，并参加定期的社区会议。

感谢

我想感谢在这些年里参与过这个项目的每个人。这是一段旅程，也是一个社区共同努力的见证！以下名单是我尽力记住并对此特性产生过影响的人。感谢大家！

• Aldo Culquicondor^[29] 在整个过程中提供指导和审查
• Jordan Liggitt^[30] 审查 KEP 和 API
• David Eads^[31] 审查 API
• Maciej Szulik^[32] 从 SIG Apps 角度审查 KEP
• Clayton Coleman^[33] 提供指导和 SIG Node 审查
• Sergey Kanzhelev^[34] 从 SIG Node 角度审查 KEP
• Dawn Chen^[35] 从 SIG Node 角度审查 KEP
• Daniel Smith^[36] 从 SIG API Machinery 角度进行审查
• Antoine Pelisse^[37] 从 SIG API Machinery 角度进行审查
• John Belamaric^[38] 审查 PRR
• Filip Křepinský^[39] 从 SIG Apps 角度进行全面审查并修复 Bug
• David Porter^[40] 从 SIG Node 角度进行全面审查
• Jensen Lo^[41] 进行早期需求讨论、测试和报告问题
• Daniel Vega-Myhre^[42] 推进 JobSet 集成并报告问题
• Abdullah Gharaibeh^[43] 进行早期设计讨论和指导
• Antonio Ojea^[44] 审查测试
• Yuki Iwai^[45] 审查并协调相关 Job 特性的实现
• Kevin Hannon^[46] 审查并协调相关 Job 特性的实现
• Tim Bannister^[47] 审查文档
• Shannon Kularathna^[48] 审查文档
• Paola Cortés^[49] 审查文档