Kubernetes 1.26：普遍可用的 Job 跟踪，以支持大规模并行批处理工作负载

Kubernetes 1.26 版本包括一个稳定的 Job 控制器实现，可以可靠地跟踪大量具有高并行度的作业。自 Kubernetes 1.22 以来， SIG Apps 和WG Batch 一直致力于这项基础改进。经过多次迭代和规模验证，现在这是 Job 控制器的默认实现。

与 Indexed completion mode配合使用，Job controller 可以处理大规模并行批处理作业，支持多达 100k 个并发 Pod。

新的实现还使Pod 故障策略的开发成为可能，该策略在 1.26 版本中处于 beta 阶段。

如何使用此功能？

要将作业跟踪与终结器一起使用，请升级到 Kubernetes 1.25 或更新版本并创建新作业。如果您有能力启用JobTrackingWithFinalizers feature gate ，您也可以在 v1.23 和 v1.24 中使用此功能。

如果您的集群运行 Kubernetes 1.26，则使用终结器进行作业跟踪是一项稳定的功能。对于 v1.25，它位于功能门之后，您的集群管理员可能已明确禁用它 - 例如，如果您有不使用 beta 功能的策略。

升级前创建的作业仍将使用旧行为进行跟踪。这是为了避免向正在运行的 Pod 追溯添加终结器，这可能会引入竞争条件。

为了在大型作业上获得最佳性能，Kubernetes 项目建议使用Indexed completion mode。在这种模式下，控制平面能够通过较少的 API 调用来跟踪作业进度。

如果您是批处理、HPC、 AI、ML 或相关工作负载的运算符开发人员，我们鼓励您使用 Job API 将准确的进度跟踪委托给 Kubernetes。如果 Job API 中缺少某些东西迫使您管理普通 Pod，Working Group Batch 欢迎您提供反馈和贡献。

弃用通知

在该功能的开发过程中，控制平面将注释添加 batch.kubernetes.io/job-tracking 到启用该功能时创建的作业中。

在 1.26 版本中，我们弃用了注解batch.kubernetes.io/job-tracking ，控制平面将停止在 Kubernetes 1.27 中添加它。随着这一变化，我们将删除遗留的作业跟踪实施。因此，Job 控制器将跟踪所有使用终结器的 Job，它会忽略没有上述终结器的 Pod。

在将集群升级到 1.27 之前，我们建议您确认没有 annotation 的正在运行的作业，或者等待这些作业完成。否则，您可能会观察到控制平面重新创建了一些 Pod。我们希望这不会影响任何用户，因为该功能自 Kubernetes 1.25 以来默认启用，为旧作业提供足够的缓冲区来完成。

新的实施解决了什么问题？

通常，Kubernetes 工作负载控制器（例如 ReplicaSet 或 StatefulSet）依赖于 Pod 或 API 中其他对象的存在来确定工作负载的状态以及是否需要替换。例如，如果属于 ReplicaSet 的 Pod 终止或不复存在，ReplicaSet 控制器需要创建一个替换 Pod 以满足所需的副本数 ( .spec.replicas)。

从一开始，Job 控制器也依赖 API 中 Pod 的存在来跟踪 Job 状态。Job 有完成和失败处理策略，需要完成的 Pod 的结束状态来确定是否创建替换 Pod 或将 Job 标记为已完成或失败。因此，Job 控制器依赖于 Pod，甚至是终止的 Pod，以保留在 API 中以跟踪状态。

这种依赖性使得对 Job 状态的跟踪变得不可靠，因为可以出于多种原因从 API 中删除 Pod，包括：

垃圾收集器在节点宕机时移除孤立的 Pod。
垃圾收集器在达到阈值时移除已终止的 Pod。
Kubernetes 调度程序抢占 Pod 以容纳更高优先级的 Pod。
污点管理器驱逐一个不能容忍NoExecute污点的 Pod。
外部控制器，不包含在 Kubernetes 中，或人工删除 Pod。

新的实施

当控制器需要在删除对象之前对对象采取操作时，它应该向它管理的对象添加终结器。终结器可防止对象从 API 中删除，直到移除终结器为止。一旦控制器完成清理并记录已删除的对象，它就可以从对象中删除终结器，并且控制平面从 API 中删除对象。

这就是新的 Job 控制器正在做的事情：在 Pod 创建期间添加终结器，并在 Pod 终止并在 Job 状态中说明后删除终结器。然而，事情并没有那么简单。

主要的挑战是至少涉及两个对象：Pod 和 Job。虽然终结器存在于 Pod 对象中，但执行状态存在于 Job 对象中。没有任何机制可以自动删除 Pod 中的终结器并更新 Job 状态中的计数器。此外，在给定的时间可能有多个终止的 Pod。

为了解决这个问题，我们实施了一个三阶段的方法，每个阶段都转化为一个 API 调用。

对于每个终止的 Pod，将 Pod 的唯一 ID (UID) 添加到存储在拥有作业的.status ( .status.uncountedTerminatedPods )中的列表中。
从 Pod 中移除终结器。
原子地执行以下操作：
- 从列表中删除 UID
- 在作业的status中增加succeeded和failed计数器总数。

作业控制器可能会在第 1 步和第 2 步中乱序接收 API 更改的结果，从而使问题更加复杂。我们通过为删除的终结器添加内存缓存来解决这个问题。

尽管如此，我们在测试阶段仍然遇到了一些问题，在某些情况下，一些 pod 会被终结器卡住（#108645、 #109485和 #111646）。因此，我们决定将 1.23 和 1.24 版本的功能门控切换为默认禁用。

解决后，我们重新启用了 1.25 版本的功能。从那时起，我们收到了客户通过 Job API 在他们的集群中同时运行数万个 Pod 的报告。看到这一成功，我们决定在 1.26 中将该功能升级到稳定版，作为我们长期承诺的一部分，使 Job API 成为在 Kubernetes 集群中运行大批量作业的最佳方式。

要了解有关该功能的更多信息，您可以阅读KEP。

作者: Aldo Culquicondor
出处: https://kubernetes.io/blog/2022/12/29/scalable-job-tracking-ga/