这篇文章已经一年多了，较旧的文章可能包含过时的内容。请检查从发表以来，页面中的信息是否变得不正确。

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

借由 Michał Woźniak (Google), Shannon Kularathna (Google) | 译者 Michael Yao (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 字段。

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

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

它是如何工作的

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

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

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

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

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

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

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

Kubernetes 发起的 Pod 干扰

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

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

在所有其他干扰场景中，例如因超过Pod 容器限制而驱逐，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 失效策略所引入的概念，正在进行中的进一步工作如下：

参与其中

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

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

感谢

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