Kubernetes 1.33：Job 的 SuccessPolicy 进阶至 GA

我代表 Kubernetes 项目组，很高兴地宣布在 v1.33 版本中，Job 的成功策略已进阶至 GA（正式发布）。

关于 Job 的成功策略

在批处理工作负载中，你可能希望使用类似 MPI 的领导者跟随者（leader-follower）模式，其中领导者控制执行过程，包括跟随者的生命周期。

在这种情况下，即使某些索引失败了，你也可能希望将 Job 标记为成功。 然而，在没有使用成功策略的情况下，Kubernetes 中的领导者跟随者 Job 通常必须要求所有 Pod 成功完成，整个 Job 才会被视为成功。

对于 Kubernetes Job，API 允许你通过 .spec.successPolicy 字段指定提前退出的条件 （你只能将此字段用于带索引的 Job）。 此字段通过使用已成功的索引列表或定义成功索引的最小数量来描述一组规则。

这个全新的稳定字段对科学仿真、AI/ML 和高性能计算（HPC）等批处理工作负载特别有价值。 这些领域的用户通常会运行大量实验，而他们可能只需要其中一部分成功完成，而不需要全部成功。 在这种情况下，领导者索引失败是对应 Job 的唯一重要退出条件，个别跟随者 Pod 的结果仅通过领导者索引的状态间接被处理。此外，跟随者自身并不知道何时可以终止。

一旦 Job 满足任一成功策略，此 Job 就会被标记为成功，并终止所有 Pod，包括正在运行的 Pod。

工作原理

以下是使用 .successPolicy.rules[0].succeededCount 的 Job 清单片段， 这是一个自定义成功策略的例子：

  parallelism: 10
  completions: 10
  completionMode: Indexed
  successPolicy:
    rules:
    - succeededCount: 1

在这里，只要有任意一个索引成功，Job 就会被标记为成功，而不管具体是哪个索引。 此外，你还可以基于 .successPolicy.rules[0].succeededCount 限制索引编号，如下所示：

parallelism: 10
completions: 10
completionMode: Indexed
successPolicy:
  rules:
  - succeededIndexes: 0 # 领导者 Pod 的索引
    succeededCount: 1

这个例子表示，只要具有特定索引（Pod 索引 0）的 Pod 成功，整个 Job 就会被标记为成功。

一旦 Job 满足任一条 successPolicy 规则，或根据 .spec.completions 达到其 Complete 条件， kube-controller-manager 中的 Job 控制器就会向 Job 状态添加 SuccessCriteriaMet 状况。 之后，job-controller 会为具有 SuccessCriteriaMet 状况的 Job 发起 Pod 的清理和终止。 当 job-controller 完成清理和终止后，Job 会获得 Complete 状况。

了解更多

• 阅读关于成功策略的文档
• 阅读关于 Job 成功/完成策略的 KEP

加入我们

这项工作由 Kubernetes 的 Batch Working Group（批处理工作组）牵头，并与 SIG Apps 社区密切协作。

如果你对此领域的新特性开发感兴趣，推荐你订阅我们的 Slack 频道，并参加定期举行的社区会议。

• ←上一页
• 下一页→