进击云原生

V2

2023/01/04阅读:17主题:山吹

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

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

Kubernetes 1.26 版本包括一个稳定的 Job 控制器实现,可以可靠地跟踪大量具有高并行度的作业。自 Kubernetes 1.22 以来, SIG AppsWG 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 调用来跟踪作业进度。

如果您是批处理、HPCAIML 或相关工作负载的运算符开发人员,我们鼓励您使用 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 调用。

  1. 对于每个终止的 Pod,将 Pod 的唯一 ID (UID) 添加到存储在拥有作业的.status ( .status.uncountedTerminatedPods )中的列表中。
  2. 从 Pod 中移除终结器。
  3. 原子地执行以下操作:
    • 从列表中删除 UID
    • 在作业的status中增加succeededfailed计数器总数。

作业控制器可能会在第 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/

说明

请关注 危 ❤ 工中号【进击云原生】,更有 free 资源供您学习

分类:

后端

标签:

运维部署

作者介绍

进击云原生
V2

公众号:进击云原生