3.3 批处理调度器对比：Volcano、Kueue 与 YuniKorn

3.3 批处理调度器对比：Volcano、Kueue 与 YuniKorn

分布式训练的 8 个 worker 必须同时启动，少一个都跑不起来——这就是 Gang Scheduling（成组调度）的诉求。但 K8s 原生调度器是逐个 Pod 调度的，可能造成「调度了 5 个、剩 3 个资源不够、前 5 个死等」的僵局。批处理调度器就是为破解这类问题而生。

3.3.1 原生调度器的批处理短板

K8s 默认调度器（kube-scheduler）是为在线服务设计的，假设「每个 Pod 是独立的、随时可调度」。但批处理负载（训练、Spark、Ray）有几个截然不同的诉求：

1. Gang Scheduling（成组调度）：一组 Pod 必须全部调度成功，否则一个都不调度。否则部分 Pod 占着资源干等，造成集群资源僵死。
2. 队列与公平性：多团队共享集群时，要有公平的资源分配机制（如 DRF、max-min fairness），避免一个团队饿死其他团队。
3. 抢占与回填：高优先级任务来了要能抢占低优先级；空闲资源要能回填给排队任务。
4. 配额管理：按团队、按项目分配资源配额，超额拒绝。

原生调度器对这些诉求的支持都很弱。于是出现了专门为批处理设计的调度器，主流有三：Volcano、Kueue、YuniKorn。

3.3.2 Gang Scheduling：批处理的核心需求

先讲清 Gang Scheduling 为什么是批处理的「命门」。

假设一个 8 卡训练，原生调度器逐个调度 8 个 worker Pod：

• 碰巧节点有 8 张空闲 GPU：8 个 Pod 都成功，训练正常。
• 节点只有 5 张空闲 GPU：5 个 Pod 调度成功占住资源，剩 3 个排队。这 5 个 Pod 在等剩余 3 个就绪（PyTorch 的 init_process_group 会卡住），但剩余 3 个又调度不上（资源被前 5 个占着）。
• 结果：5 个 Pod 长期占着资源不工作，其他任务也用不上，整个集群陷入死锁。

Gang Scheduling 的解决方案是「要么全成功，要么全不调度」：

• 调度器尝试同时调度全部 8 个 Pod。
• 如果资源够：8 个一起成功。
• 如果资源不够：8 个一起等待（不占资源），让其他任务先用。

💡 判读：Gang Scheduling 是「用资源利用率换调度确定性」。它宁可让作业等待，也不让它半吊子占着资源。对训练这种「全有或全无」的负载，这是唯一合理的调度语义。

3.3.3 Volcano：CNCF 孵化的批处理调度器

Volcano（原名 kube-batch）是华为开源、CNCF 孵化的批处理调度器，是 K8s 上最早成熟的 AI/大数据调度方案。

Volcano 的核心特性：

• PodGroup CRD：Volcano 引入了 PodGroup 概念，把一组相关 Pod 作为一个调度单元，原生支持 Gang Scheduling。
• 队列与公平调度：支持多级队列、DRF（Dominant Resource Fairness）公平调度。
• 抢占与回填：支持优先级抢占、跨队列借调、空闲资源回填。
• 多种插件：可插拔的调度插件（gang、binpack、drf、topology 等），灵活组合。
• 拓扑感知：内建 GPU 拓扑感知能力。

Volcano 与 Training Operator 的协作：

• 用户提交 PyTorchJob（Training Operator CRD）。
• Training Operator 创建 worker Pod 时，给它们打上同一个 PodGroup 标签。
• Volcano 按 PodGroup 做 Gang Scheduling，确保 8 个 Pod 同时调度。

3.3.4 Kueue：Kubernetes 官方的作业排队方案

Kueue 是 Kubernetes SIG-WG Batch 官方推出的作业排队与配额管理项目，2023 年成为官方推荐方案。它的设计哲学与 Volcano 略有不同：

• 不改调度器：Kueue 不替换 kube-scheduler，而是在其之上做「排队与准入控制」。
• 复用原生 Job/CRD：Kueue 通过 webhook 暂停 Job、按队列配额放行，与原生 Job、Kubeflow Training Operator 等无缝集成。
• 配额为中心：核心抽象是 ClusterQueue 与 LocalQueue，定义资源配额与借调策略。

Kueue 的工作流程：

1. 管理员定义 ClusterQueue（配额池）与 LocalQueue（用户视角的队列）。
2. 用户提交 Job 时指定要进的 LocalQueue。
3. Kueue 检查配额：够则放行（suspend=false），不够则挂起（suspend=true）排队。
4. 资源释放后，Kueue 按优先级或公平策略放行排队中的作业。

💡 判读：Kueue 与 Volcano 的本质区别是「是否替换调度器」。Volcano 是「Volcano 调度器接管」，Kueue 是「原生调度器 + Kueue 排队」。后者更轻量、与原生生态融合更好，是官方力推的方向。但 Kueue 的 Gang 调度依赖原生 Job 的 Indexed completion，对一些复杂场景不如 Volcano 灵活。

3.3.5 YuniKorn：大数据与流式作业的调度器

YuniKorn 是 Apache 社区（最初来自 Cloudera）的调度器，定位偏大数据与流式作业（Spark、Flink）。它的强项是：

• 层次化队列：精细的多级队列与层级配额。
• 大数据生态融合：与 Spark、Flink 等 Hadoop 生态深度集成。
• Gang 调度：支持。

但在 AI 场景，YuniKorn 的使用相对少，因为它的设计假设更接近 Hadoop YARN 而非 K8s AI 负载。多数 AI 团队在 Volcano 与 Kueue 之间选择。

3.3.6 三大批处理调度器对比

把三者放一张表里全面对比，这是选型的核心参考：

3.3.7 选型决策树

面对三大调度器，怎么选？给出一个工程决策树：

💡 选型经验总结：

• 纯 AI 训练集群、新建、追求官方路线 → Kueue（轻量、与 K8s 原生融合、官方力推）。
• 复杂 Gang 场景、需要大数据与 AI 混部、训练生态深度集成 → Volcano（功能强、生态成熟）。
• 以 Spark/Flink 为主、有 Hadoop 背景 → YuniKorn（大数据强项）。
• 不确定时优先 Kueue，因为它的路线最清晰、与未来 K8s 演进对齐。

3.3.8 配额与公平调度的工程实践

无论选哪个调度器，配额与公平调度都是核心议题。几个工程实践：

1. 按团队分配配额：每个团队一个 LocalQueue，配额绑定到 ClusterQueue，避免一个团队吃掉全部资源。
2. Cohort 借调（Kueue）/ 跨队列借调（Volcano）：允许空闲资源被其他队列借走，提升整体利用率。
3. 优先级分层：生产训练高优先级、实验训练中优先级、调试试错低优先级，抢占时从低到高。
4. 配额评审：定期评审团队配额是否合理，按业务重要性调整。

3.3.9 调度器与第 2 章 Operator 的协作

最后回顾一下，本章的批处理调度器与第 2 章的训练 Operator 是如何协作的：

• Training Operator（2.4） 负责「该创建哪些 Pod、它们的生命周期」。
• 批处理调度器（本章） 负责「这些 Pod 何时、以何种顺序被调度」。
• kube-scheduler 负责「Pod 落到哪个节点」。

三者形成清晰的分工：Operator 提交 Pod → Kueue/Volcano 排队与 Gang 准入 → kube-scheduler 落节点。这种分层让每个组件职责单一、可独立演进，是云原生 AI 调度栈的设计精髓。

本节小结

• K8s 原生调度器对批处理负载支持弱：无 Gang Scheduling、无队列公平、抢占有限。
• Gang Scheduling 是分布式训练的命门——「全部成功或全部不调度」，避免半吊子占资源死锁。
• Volcano 是 CNCF 孵化的全功能批处理调度器，PodGroup + Gang + DRF，AI 训练生态成熟。
• Kueue 是 K8s 官方排队方案，不替换调度器、与原生 Job 深度集成，是新建集群首选。
• YuniKorn 强在大数据与流式作业，AI 场景使用较少。
• 选型决策：纯 AI 新建 → Kueue；复杂 Gang + 混部 → Volcano；大数据为主 → YuniKorn。
• 配额与公平调度核心实践：团队配额、借调、优先级分层、定期评审。
• Operator（生命周期） + 批处理调度器（排队准入） + kube-scheduler（落节点） 三层分工，是云原生 AI 调度栈的设计精髓。

下一节《3.4 抢占、重调度与弹性训练》将讲清中断与故障下的弹性恢复策略。