在机器学习训练、科学计算、大数据离线分析这类场景里，作业往往由几十甚至上百个Pod组成，必须全部同时启动才能正常工作。原生Kubernetes调度器是逐个调度Pod的，一旦集群资源不足，就会出现一部分任务起来了、另一部分卡在Pending的尴尬局面，分布式训练框架直接卡死，资源却被白白占着。Volcano就是为了解决这个问题而生的批处理调度系统，它由华为云开源，目前已是CNCF孵化项目，在AI平台、HPC集群里应用非常广泛。本文将从架构、核心概念、安装实践和进阶配置几个方面，完整讲清楚Volcano是怎么工作的。
一、原生调度器为什么撑不住批处理场景
要理解Volcano的价值，得先看清原生调度器的三个硬伤。第一是缺乏队列能力。Kubernetes本身没有队列的概念，所有Pod扔进调度缓存里一视同仁，先到先得。当多个团队共享一个集群时，某个团队提交了海量任务，就会把资源吃干抹净，其他团队的任务只能干等，公平性完全无法保证。
第二是没有成组调度（Gang Scheduling）能力。一个分布式训练作业，比如用8张GPU做数据并行的任务，需要所有worker同时就位才能开始训练。如果调度器只成功启动了5个worker，剩下3个因为资源不足一直Pending，那已经启动的5个就白白占着GPU空转，既浪费资源，作业又跑不完，最终还可能因为训练框架的初始化超时而整体失败。
第三是调度算法偏向延迟敏感的在线服务。原生调度器的打分策略主要考虑资源均衡，对吞吐量优先的批处理作业并不友好。批处理更关心的是整体完成时间、队列公平性，以及尽量减少资源碎片，这些都需要专门的算法来支撑，比如后面要讲的DRF和回填调度。
二、Volcano的核心架构与关键概念
Volcano部署后主要包含三个组件：vc-controller-manager负责控制器逻辑，处理vcjob、queue、podgroup等自定义资源的生命周期；vc-scheduler是调度器核心，实现了一套可插拔的调度框架，通过插件组合出完整的调度行为；vc-webhook-admission则是准入控制器，负责给Job自动注入默认配置。这套架构与Kubernetes的调度框架思路一致，熟悉kube-scheduler源码的话上手会很快。
Volcano引入了两个关键概念。第一个是PodGroup，它把一组相关的Pod抽象成一个调度单元，记录了最小启动数量（minMember）、队列归属等信息，Gang调度就是围绕PodGroup实现的。第二个是Queue，队列是资源配额和公平调度的基本单位，每个队列可以设置权重和能力上限，调度器按比例在不同队列间分配资源。普通Pod带上scheduling.k8s.io/group-name注解也能加入PodGroup，这意味着Volcano可以调度原生的工作负载，兼容性很好。
调度器内部由动作和插件两部分组成。动作（Action）定义调度流程的各个阶段，比如enqueue判断作业能否入队、allocate执行具体的资源分配、preempt处理抢占、backfill做回填；插件（Plugin）则在各个阶段提供具体策略，例如proportion插件按队列权重分配资源、gang插件实现成组调度、predicates和nodeorder插件分别负责节点过滤和节点打分。整个调度过程可以概括为：作业先经过enqueue进入会话，然后由allocate逐一分配资源，全部满足minMember则整组启动，不满足则可能触发抢占或者等待。
三、安装Volcano并提交第一个vcjob
Volcano的安装非常简单，官方提供了helm chart，一条命令就能拉起来：
# 添加Volcano官方helm仓库并安装 helm repo add volcano-sh https://volcano-sh.github.io/helm-charts helm repo update helm install volcano volcano-sh/volcano -n volcano-system --create-namespace # 确认核心组件运行正常 kubectl get pods -n volcano-system
安装完成后，先创建一个队列，再提交一个vcjob试试。下面的例子定义了一个名为training的队列，然后提交一个包含4个task、每组最小副本数为2的作业，用busybox模拟长时间运行的计算任务：
apiVersion: scheduling.volcano.sh/v1beta1
kind: Queue
metadata:
name: training
spec:
weight: 3 # 队列权重，相对于其他队列的资源共享比例
capability: cpu: 16, memory: 32Gi # 队列可使用的资源上限
---
apiVersion: batch.volcano.sh/v1alpha1
kind: Job
metadata:
name: demo-vcjob
spec:
schedulerName: volcano # 必须指定使用volcano调度器
queue: training # 归属的队列
minAvailable: 3 # 至少3个副本就绪才会整体启动
tasks:
- replicas: 4
name: worker
template:
spec:
containers:
- name: main
image: busybox
command: ["sleep", "3600"]
resources:
requests:
cpu: "1"
memory: 1Gi
restartPolicy: OnFailure
提交后可以用kubectl get vcjob查看作业状态，用kubectl get podgroup查看PodGroup的调度详情。如果把minAvailable设置成大于集群当前可分配的副本数，会观察到所有Pod都处于Pending，这正是Gang调度在起作用：宁可整体等待，也不让一部分任务先占着资源空转。在实际的GPU训练场景里，这个机制能避免严重的资源浪费和训练框架初始化失败。
四、进阶配置：公平调度、抢占与回填
队列的weight字段决定了资源瓜分比例。假设集群里有A、B两个队列，weight分别是4和1，那么在资源紧张时，A队列理论上能拿到大约五分之四的资源，B拿五分之一。这种按比例分配由proportion插件实现，配合queue的deserved概念，队列实际能获得的资源会在weight和capability之间动态调整，既保证公平又不会让某个队列无限扩张。
当高优先级队列资源不够时，可以开启抢占让新任务抢走低优先级任务的资源。抢占行为由preempt动作配合插件完成，通常需要在vcjob的spec里设置priorityClass，并在队列或job层面声明抢占策略。需要注意的是，抢占会导致被抢任务重新排队，在训练场景下要谨慎使用，避免频繁打断长任务。相比之下，回填（backfill）是一种更温和的手段，它会利用小任务去填补资源空洞，前提是这些小任务声明了很短的运行时间预估，调度器判断它们能在被阻塞的大任务获得资源之前跑完。
最后提一个多租户场景的实用建议：按团队或业务线划分队列，给每个队列设置合理的capability和reclaimable属性。reclaimable设为true时，队列的空闲资源可以被其他队列借用，任务结束后又能归还，这在潮汐明显的业务里能显著提升整体利用率。同时把不同优先级的任务放进不同队列，比在同一个队列里靠priorityClass抢占要可控得多，排查问题也更容易。
Kubernetes批处理Volcano调度器队列管理修改时间：2026-09-09 20:02:46