Kubernetes 1.33：Job 的 SuccessPolicy 进阶至 GA

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

关于 Job 的成功策略

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

在这种情况下，即便某些索引失败了，你可能仍然希望将整个 Job 标记为 Succeeded。 然而，在没有使用成功策略的情况下，一个使用领导者追随者模式的 Kubernetes Job 通常需要所有 Pod 都成功完成，才能使该 Job 达到整体 Succeeded 的状态。

对于 Kubernetes Job，API 允许你通过使用 .spec.successPolicy 字段指定提前退出的标准 （你只能将 .spec.successPolicy 字段用于索引型 Job）。 此字段描述了一组判断 Job 成功与否的规则，可以是使用 Job 的 Succeeded 索引列表，或可以定义 Succeeded 索引要求的最小数量。

这个全新的稳定字段对于科学模拟、AI/ML 以及高性能计算（HPC）等批处理工作负载尤其有价值。 这些领域的用户通常会运行大量实验，而他们可能只需要一部分实验成功完成，而不是要求所有实验都成功。 在这种情况下，领导者索引的失败才是 Job 退出的唯一相关标准，个别追随者 Pod 的结果则通过领导者索引的状态间接处理。 此外，追随者通常不知道自己何时可以安全终止。

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

工作机制

以下是从使用 .successPolicy.rules[0].succeededCount 的 Job 清单中摘取的片段， 展示了如何使用自定义的成功策略：

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

在这个例子中，无论成功的是哪个索引，只要有一个索引成功，Job 就会被标记为 Succeeded。 此外，你还可以将 succeededCount 与特定的索引号配合使用，如下所示：

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

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

一旦 Job 达到了任意一个 successPolicy 规则，或者基于 .spec.completions 达成了 Complete 状况， kube-controller-manager 中的 Job 控制器会在 Job 状态中添加 SuccessCriteriaMet 状况。 之后，Job 控制器将开始清理和终止满足 SuccessCriteriaMet 状况的 Job 的 Pod。 最终，当 Job 控制器完成清理和终止操作后，Job 将获得 Complete 状况。

了解更多

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

加入我们

这一特性由 Kubernetes 的批处理工作组（Batch Working Group） 主导开发，并与 SIG Apps 社区紧密协作完成。

如果你有兴趣参与这一领域的新特性开发，推荐订阅我们的 Slack 频道，并参加定期的社区会议。

• ←上一页
• 下一页→