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/
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
