批处理至今仍是一项重要能力，而且是一项举足轻重的能力。距离 Google 帮助将 Kueue 引入 Kubernetes（https://kubernetes.io/blog/2022/10/04/introducing-kueue/…）已将近四年，我最近注意到一些规模相当可观的采用案例。比如，Netflix 采用 Kueue 来替代内部自研方案。https://infoq.com/news/2026/08/netflix-kueue-kubernetes-batch…

介绍 Kueue

来源：https://kubernetes.io/blog/2022/10/04/introducing-kueue/ 本文发布已超过一年。较旧的文章可能包含过时的内容。请检查页面中的信息自发布之日起是否已发生变更。

无论是在本地环境还是云端，集群在资源使用、配额和成本管理方面都面临着实际限制。无论自动扩缩容能力如何，集群的容量都是有限的。因此，用户希望有一种简单的方式，能够公平且高效地共享资源。

在本文中，我们介绍 Kueue（https://github.com/kubernetes-sigs/kueue/tree/main/docs#readme），这是一个开源的作业排队控制器，旨在将批处理作业作为一个整体单元进行管理。Kueue 将 Pod 级别的编排交给 Kubernetes 中现有稳定的组件来处理。Kueue 原生支持 Kubernetes Job（https://kubernetes.io/docs/concepts/workloads/controllers/job/）API，并提供钩子以集成其他自定义构建的批处理作业 API。

为什么选择 Kueue？https://kubernetes.io/blog/2022/10/04/introducing-kueue/#why-kueue

作业排队是在本地和云环境中大规模运行批处理工作负载的关键特性。作业排队的主要目标是管理对多个租户共享的有限资源池的访问。作业排队决定哪些作业应等待、哪些可以立即开始，以及它们可以使用哪些资源。

作业排队的一些最理想需求包括：

• 配额和预算，用于控制谁可以使用什么资源以及使用上限。这不仅在本地这类静态资源集群中是必需的，在云环境中也同样需要，以便控制支出或稀缺资源的使用。
• 租户之间的公平资源共享。为了最大化可用资源的利用率，应允许将分配给非活跃租户的未使用配额公平地共享给活跃租户。
• 根据可用性，将作业灵活地放置到不同类型的资源上。这在云环境中尤为重要，因为云环境存在异构资源，例如不同的架构（GPU 或 CPU 型号）以及不同的供应模式（spot 与按需）。
• 支持可自动扩缩容的环境，能够按需调配资源。

普通的 Kubernetes 无法满足上述需求。在正常情况下，一旦创建 Job，job-controller 会立即创建 Pod，kube-scheduler 会持续尝试将 Pod 分配到节点。在规模化场景下，这种情况可能让控制平面不堪重负。目前也没有好的办法在作业级别控制哪些作业应优先获得哪些资源，也无法表达顺序或公平共享。现有的 ResourceQuota 模型并不适合这些需求，因为配额是在资源创建时强制执行的，并且没有请求排队机制。ResourceQuota 的意图是提供一种内置的可靠性机制，配合管理员所需的策略，以保护集群免于过载或失效。

在 Kubernetes 生态系统中，已有若干作业调度解决方案。然而，我们发现这些替代方案存在以下一个或多个问题：

• 它们替换了 Kubernetes 中现有的稳定组件，例如 kube-scheduler 或 job-controller。这不仅从运维角度看存在问题，而且作业 API 的重复会导致生态系统碎片化，降低可移植性。
• 它们不与自动扩缩容集成，或者
• 它们缺乏对资源灵活性的支持。

Kueue 的工作原理 https://kubernetes.io/blog/2022/10/04/introducing-kueue/#overview

通过 Kueue，我们决定采用一种不同的方法来实现 Kubernetes 上的作业排队，该方法围绕以下几个方面展开：

• 不重复实现 Kubernetes 既定组件已经提供的 Pod 调度、自动扩缩容和作业生命周期管理功能。
• 为现有组件添加缺失的关键功能。例如，我们投入于 Job API，以覆盖更多用例，如 IndexedJob（https://kubernetes.io/blog/2021/04/19/introducing-indexed-jobs），并修复了与 Pod 跟踪相关的长期问题（https://kubernetes.io/docs/concepts/workloads/controllers/job/#job-tracking-with-finalizers）。虽然这条路径需要更长时间才能让功能落地，但我们相信这是一个更可持续的长期方案。
• 确保与计算资源具有弹性且异构的云环境兼容。

为了使这种方法可行，Kueue 需要一些控制手段来影响那些既定组件的行为，从而能够有效地管理作业何时何地启动。我们以两种功能的形式将这些控制手段添加到了 Job API 中：

• Suspend 字段（https://kubernetes.io/docs/concepts/workloads/controllers/job/#suspending-a-job），允许 Kueue 向 job-controller 发出信号，指示何时启动或停止 Job。
• 可变的调度指令（https://kubernetes.io/docs/concepts/workloads/controllers/job/#mutable-scheduling-directives），允许 Kueue 在启动 Job 之前更新 Job 的 .spec.template.spec.nodeSelector。这样，Kueue 可以控制 Pod 放置，同时仍将实际的 Pod 到节点调度委托给 kube-scheduler。

请注意，任何自定义作业 API 只要提供上述两个能力，Kueue 都可以对其进行管理。

资源模型 https://kubernetes.io/blog/2022/10/04/introducing-kueue/#resource-model

Kueue 定义了新的 API 来满足本文开头所提到的需求。三个主要 API 是：

• ResourceFlavor：集群范围的 API，用于定义可供消费的资源类型（例如 GPU 型号）。其核心是一组标签，与提供这些资源的节点上的标签相对应。
• ClusterQueue：集群范围的 API，通过为一个或多个 ResourceFlavor 设置配额来定义资源池。
• LocalQueue：命名空间范围的 API，用于对单个租户的作业进行分组和管理。在最简单的形式下，LocalQueue 是指向租户（以命名空间建模）可用于启动其作业的 ClusterQueue 的指针。

更多详细信息，请参阅 API 概念文档（https://sigs.k8s.io/kueue/docs/concepts）。虽然这三个 API 可能看似庞大，但 Kueue 的大部分操作都围绕 ClusterQueue 展开；ResourceFlavor 和 LocalQueue API 主要是组织层面的封装。

示例用例 https://kubernetes.io/blog/2022/10/04/introducing-kueue/#example-use-case

想象一下在云上的 Kubernetes 集群中运行批处理工作负载的以下设置：

• 您已在集群中安装 cluster-autoscaler（https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler），以自动调整集群大小。
• 有两种类型的自动扩缩容节点组，其供应策略不同：spot 和按需。每组节点通过标签 instance-type=spot 或 instance-type=ondemand 进行区分。此外，由于并非所有 Job 都能容忍在 spot 节点上运行，因此这些节点带有 spot=true:NoSchedule 的污点。
• 为了在成本和资源可用性之间取得平衡，假设您希望 Job 最多使用 1000 个按需节点核心，然后使用最多 2000 个 spot 节点核心。

作为批处理系统的管理员，您定义两个 ResourceFlavor 来表示这两类节点：

``

apiVersion: kueue.x