企业官网建设流程全解析

那一刻我盯着Kubernetes集群的Pod列表，看到两个训练任务卡在Pending状态整整三个小时。应用的日志一切正常，节点的GPU资源明明还有富余，可新提交的Pod就是调度不上去。等到最后查清根因时我才意识到，问题根本不在应用侧，而在于默认的kube-scheduler压根就不是为批处理场景设计的。后来我引入Volcano，把任务队列、Gang调度、公平性全部纳管起来，这套环境才算真正稳了。

这篇文章把我从那次事件到现在用Volcano的全过程写下来，包括它解决了什么问题、核心调度模型怎么运作、怎么在集群里快速跑通一个训练任务，以及我在生产环境踩过的几个真实大坑。无论你是在搭建AI训练平台，还是想优化Spark、Flink这类批任务的资源利用率，这篇内容都值得你花几分钟读完。

1. 原生调度器在批处理场景为什么总"卡住"

1.1 一次线上事件：从"工具人排查"到"调度器背锅"

当时我们集群的构成并不复杂：三台GPU节点，每台八卡A100，上面同时跑着几个团队的训练任务和定时数据处理任务。某天下午运维同学反馈说有两个训练任务提交后一直不动，我一开始以为是镜像拉取、节点污点或者是存储挂载的问题，手动describe了Pod，发现事件里全是FailedScheduling，原因是GPU资源不够。

但矛盾就出在这里——我用kubectl describe node看GPU节点，每张卡的利用率虽然不低，但离跑满还远。问题在于这些卡被碎片化地分配给了不同Pod：一个任务占了三张卡，另一个任务占了两张卡，还有一个任务占了一张卡，而新提交的任务每Pod需要四张卡，结果就是任何单台机器都凑不出连续的可用卡来承载它。

这类问题靠人肉调整资源请求可以暂时缓解，但根本上是调度器策略的缺失：默认的kube-scheduler按Pod逐个调度，不关心任务整体的资源需求，也不关心一组Pod是否应该捆绑调度。它不"认识"作业，更不知道哪些Pod是一伙的。

1.2 三类典型任务暴露出原生调度器的天花板

在这套集群上我们一共跑三类负载，这三类负载恰好在不同维度戳中了kube-scheduler的软肋。

第一类是分布式训练任务。以PyTorch DDP为例，一个训练作业往往由一个master和多个worker组成，这些Pod彼此之间需要建立通信。如果调度器只把前三个worker调度上去了，第四个worker因为资源不足一直Pending，那前三个worker就会一直空转等待，甚至直接超时失败。这种"要么全部就绪、要么全部不启动"的诉求，原生调度器完全不管。

第二类是Spark任务。Spark的Executor在执行阶段需要批量拉起，如果一批Executor被零散地调度到不同节点、还要等待后续Executor慢慢补齐，整个Stage的启动时间会被拖得很长。更严重的是，如果集群资源紧张，部分Executor可能迟迟无法启动，任务直接失败重试，反复消耗资源。

第三类是定时批处理任务，比如每天凌晨的数据清洗。这类任务通常由CronJob触发，一到整点就一起提交几十个PVC挂载的Pod，瞬间把调度器和API Server的压力拉满。如果没有队列控制，高优任务和低优任务只能按创建时间排队，一旦低优任务先占了资源，高优任务想插队就得等它跑完。

这三类负载不是边缘场景，而是很多公司上Kubernetes之后必然会遇到的典型需求。kube-scheduler的定位是通用调度器，它走的是"单Pod视角、资源足够就调度、资源不够就等待"的策略，面对多Pod协作、作业生命周期管理、多租户配额这类需求时，确实不够用。

1.3 从Kubernetes视角看Volcano存在的意义

Volcano并不是要替代kube-scheduler在普通工作负载上的作用，它做的事情是把"作业"这个概念引入调度系统。普通无状态服务比如Nginx、API网关，继续用默认调度器完全没有问题；但当你需要调度的是"一组存在依赖关系、共享资源配额、需要整体调度的Pod"时，就需要一个懂作业语义的调度器来接管。

Volcano在Kubernetes体系中承担的角色类似于一个"批处理调度中间层"：它通过自定义资源定义PodGroup和Queue来感知作业和队列，再通过自身的控制器把作业转换成对应的Pod，最后由自身的调度器以作业为粒度完成调度。它跑的仍然是Kubernetes上原生的Pod，没有改变Pod的本质，只是从更高维度把这些Pod组织了起来。

2. Volcano的调度模型：PodGroup、Queue和Action/Plugin怎么协作

2.1 调度的基本单位从Pod上升为PodGroup

用Volcano之后，调度的最小单位从一个Pod变成了一组Pod，这一组Pod在Volcano里叫PodGroup。你可以把PodGroup理解成"一批必须同生共死的Pod集合"。它有一个关键参数minMember，表示这个组至少需要多少个成员被成功调度，才能放行整个组的调度。

这个抽象非常贴近分布式作业的真实形态。以M线程的Horovod训练为例，使用AllReduce方案通信时，M个worker必须同时就绪才算这个训练作业真正跑起来。Volcano的做法是：只有当PodGroup中满足minMember要求的Pod全部有可行节点时，整个组才会被一起调度；否则整个组保持Pending，不抢占资源，也不造成部分启动的尴尬状态。

PodGroup也有自己的优先级、队列归属、最小资源、最大资源等属性。这些属性会被调度器读取，作为后续排队、抢占、配额判断的依据。你可以通过两种方式创建PodGroup：一是直接定义PodGroup资源，二是定义Volcano Job，由Volcano的控制器自动生成PodGroup。

2.2 三个核心CRD：PodGroup、Queue、Volcano Job

在Volcano体系里，日常打交道最多的是三个CRD：PodGroup、Queue和Job。

Queue是资源配额和任务分组的容器，很像大数据平台的资源队列。每个队列可以配置deserved（应得资源）、capability（资源上限）和weight（权重）。多个团队共用一个集群时，合理的做法是给每个团队建一个Queue，通过capability限制它们最多能用多少资源，再通过weight控制在资源竞争时的分配比例，防止某个团队把整个集群占满。

Job则是Volcano对Kubernetes Job的扩展。它允许你在一个Job里定义多个task，每个task对应一组相同配置的Pod，并且可以给task设置角色名。比如一个训练Job里可以定义ps角色3个副本、worker角色8个副本、master角色1个副本，这种多角色描述能力是默认Kubernetes Job完全不具备的。

配合这两个CRD的还有PodGroup本身，它就像Job和调度器之间的桥梁：Job控制器创建PodGroup，并在Pod上注入对应的PodGroup引用；Volcano调度器监听到PodGroup发生变化后，把PodGroup和它管理的全部Pod作为一个整体加入调度流程。

2.3 调度器的Action和Plugin机制是怎么运作的

如果只看CRD，你只能理解Volcano的"数据结构"，真正决定调度行为的是它的Action和Plugin机制。我可以用一个餐厅等位的例子来类比这个过程。

想象一家餐厅有若干个卡座，每个卡座可以坐4个人，这就是一个可分配的节点。不同批次的客人有的是一人位、有的是四人小团队，这就是不同类型的PodGroup。Volcano调度器每一轮"调度会话"就像服务员重复执行一套流程：先把排队单上的客人分组整理（enqueue），再判断哪些组合能凑够一个卡座（allocate），卡座不够时看看能不能劝退占着大桌但还吃得不多的客人（preempt），最后捡漏把剩余空位补满（backfill）。

对应到实现上，Volcano把每一轮调度拆成多个Action：enqueue把进入调度范围的Job和PodGroup放到待调度队列；allocate为Pod找到合适的节点；preempt在资源不足时触发抢占；reclaim回收属于其他Queue但被当前Queue占用的资源；backfill利用剩余碎片资源调度一些BestEffort任务。每个Action内部又有多个Plugin配合，比如gang插件处理Gang调度、proportion插件负责队列配额比例、nodeorder插件负责节点打分排序、priority插件负责根据优先级排序。这种Action+Plugin的分层设计让调度策略变成可插拔的，不用改动调度器主体就能灵活调整行为。

值得注意的是，Volcano的调度决策并不是实时的、事件驱动的，而是以"调度会话"为单位周期性执行。每次调度会话开始时会重新拉取集群状态快照，运行一系列Action和Plugin，形成一批调度决策后再统一应用到集群。这个设计保证了调度过程的整体一致性，也解释了为什么Volcano能够承载大规模批处理任务。

3. 手把手跑通Volcano并在集群上提交一个训练任务

3.1 安装Volcano：版本选型与部署细节

Volcano的安装方式很多，最省心的是用Helm。以我部署的v1.8.0版本为例，安装命令非常简单：

helm repo add volcano https://volcano-sh.github.io/charts helm repo update kubectl create namespace volcano-system helm install volcano volcano/volcano --namespace volcano-system --version 1.8.0

安装完成后检查一下核心组件是否正常运行：

kubectl get pods -n volcano-system

正常情况下你会看到volcano-admission-*、volcano-controller-*、volcano-scheduler-*三组Pod，分别对应准入控制、控制器和调度器三大模块。有一点必须注意：Volcano调度器需要作为kube-scheduler的插件或独立调度器运行，如果你在自定义的Kubernetes集群里用二进制方式部署控制平面，需要确保scheduler组件的启动方式支持扩展调度器，否则Volcano装了也接不上Pod的调度请求。

这里提醒一个很多人忽略的点：安装完成后，默认情况下Volcano会把名为volcano的SchedulerName注册到集群中。如果你提交的任务指定了schedulerName: volcano，Pod才会走Volcano调度器；不指定的话，Pod仍然走默认的kube-scheduler。所以安装完Volcano不会影响已有普通工作负载的调度行为，这一点对同集群的在线业务是安全的。

3.2 编写第一个Volcano Job：YAML逐段拆解

跑通Volcano最简单的方式是直接创建一个Volcano Job。下面这个例子复制了一个最小可运行的MPI风格分布式训练任务：一个master节点加两个worker节点。这个YAML是我调试时实际用过的，注释能帮你理解每个字段的含义。

apiVersion: batch.volcano.sh/v1alpha1 kind: Job metadata: name: volcano-mpi-demo namespace: default spec: # 最少需要多少Pod成功运行，满足后Job才会被放行调度 minAvailable: 3 # 指定使用Volcano调度器 schedulerName: volcano # 归入哪个队列，不写默认是default队列 queue: default policies: - event: PodEvicted action: RestartJob - event: PodFailed action: RestartJob tasks: - name: master replicas: 1 policies: - event: TaskCompleted action: CompleteJob template: spec: containers: - image: volcanosh/example-mpi:0.0.1 name: master command: - /home/mpiuser/run.sh resources: requests: cpu: "1" memory: "1Gi" limits: cpu: "1" memory: "1Gi" - name: worker replicas: 2 template: spec: containers: - image: volcanosh/example-mpi:0.0.1 name: worker resources: requests: cpu: "1" memory: "1Gi" limits: cpu: "1" memory: "1Gi"

提交后先看Job状态：

kubectl get vcjob volcano-mpi-demo

再确认Pod是否都调度成功：

kubectl get pods -l job-name=volcano-mpi-demo

如果一切正常，你会看到master和worker各Pod的状态都进入Running。这里面值得关注的是policies字段——它定义了Job在不同生命周期事件下应该怎么处理。比如PodFailed发生时RestartJob重启整个Job，TaskCompleted时CompleteJob结束整个Job。这个能力对训练任务非常关键，因为某些角色的Pod失败就代表整个训练失败，继续等下去只会浪费资源。

3.3 怎么验证Volcano真正接管了调度

任务跑起来之后，可以进一步确认调度链路确实是Volcano在控制。最简单的办法是查看Pod的spec.schedulerName字段：

kubectl get pod <pod-name> -o jsonpath='{.spec.schedulerName}'

如果输出是volcano，说明这个Pod已经交给了Volcano调度器。你还可以查看Volcano自动创建的PodGroup：

kubectl get podgroup

对于通过Volcano Job创建的任务，PodGroup的名字会带有Job前缀。把Pod和PodGroup对应起来之后，再看调度器日志里有没有对应的调度记录：

kubectl logs -n volcano-system -l app.kubernetes.io/name=volcano -c volcano-scheduler --tail=100 | grep <job-name>

能看到一条类似FailedPlacement或Allocate的记录，就说明调度器确实处理了这个作业。这套验证方法是我每次排查调度问题时的第一步：先确认Pod是不是真的走Volcano，如果没有走，后面的一切都无从谈起。

4. 踩过的坑：从日志到事件的完整排查链路

4.1 第一个坑：PodGroup一直处于Pending，任务排队三小时

有一次同事反映一个训练任务提交后一直不启动，我查了Volcano Job的状态，发现Running还是0/3，再查PodGroup，状态是Pending。当时我的第一反应是资源不足，但看了节点资源明明还有空余。

后来翻到volcano-controller的日志，发现有一条反复出现的信息：Failed to create podgroup for job xxx，说是admission webhook拒绝创建PodGroup。我这才想起来，新环境部署Volcano的时候，admission的配置因为证书问题没有生效，导致Job控制器无法自动创建PodGroup。也就是说，Job虽然被创建出来了，但没有PodGroup兜底，调度器根本不认识这个作业。

这类问题最大的迷惑性在于表面上看"没有任何错误事件"，因为Pod根本没有被创建出来，自然不会产生调度失败事件。你这边的排查链路应该是：Job的Event看有没有创建PodGroup的记录，PodGroup是否存在，webhook配置是否正常。很多时候不是调度器的问题，而是连调度器的输入都没构建好。

4.2 第二个坑：minAvailable设置过大引发全组死锁

还有一次是把minAvailable设置成了和副本数完全相等的值，但其中一个副本的资源需求比较大，整个集群只有一台节点满足它的要求。结果就是：调度器把小的副本都调度上去了，大副本的节点资源不够，因为不满足minAvailable条件，整个PodGroup都不被放行，之前已调度的Pod也被回滚，卡在Pending状态。

这就是Gang调度最常见的一个坑：minAvailable设得越高，调度容错空间越小，越容易出现"少数Pod没资源，整个组全部等待"的伪死锁状态。尤其在混合负载的共享集群中，节点资源是动态变化的，如果minAvailable设得太死，碰到高峰时段极容易把所有作业卡住。

我的经验是，minAvailable不要盲目和副本数画等号，要结合集群规模和任务特征来判断。如果你的任务是四副本的分布式训练，缺一个副本通信组就建不起来，那minAvailable建议是4；但如果你的任务只是普通的并行数据处理，缺一两个副本只是影响处理速度，那minAvailable设成3，剩余的Pod按普通Pod逐个补齐，会大大降低调度死锁的概率。

4.3 第三个坑：Queue的capability设置不合理引发资源饥饿

Volcano里Queue的capability字段决定了这个队列最多能占用多少资源，deserved字段决定了这个队列在资源竞争时"应得"的资源。我一开始图省事，只给开发队列设了capability，没设deserved，结果生产队列的任务一多，开发队列的权重变得非常低，分配到的资源远低于预期。

更麻烦的是抢占比的自动调节逻辑。如果某个队列的share（当前用量与配额的比值）持续过高，它可能会被调度器判定为"资源富余方"，在发生抢占时优先把资源让给share更低的队列。这个机制本身的目的是公平，但如果配额设置没有结合实际使用场景，就会出现"重要任务排队、不重要的任务反而优先"的情况。

解决方法是把每个Queue的deserved和capability都显式设置出来，不能只设一个。比如开发队列配置deserved: 20核、capability: 40核，生产队列配置deserved: 30核、capability: 80核，再根据实际业务量定期调整。这样Volcano的proportion插件在计算队列权重和抢占优先级时，才有明确的参考依据。

4.4 第四个坑：抢占配置不当导致低优任务被反复杀死

Volcano的preemptAction确实能在资源紧张时让低优任务给高优任务让路，但它是一把双刃剑。我遇到过这样的情况：低优任务刚被抢占杀死，控制器马上把它重新创建出来，再次被调度器看到，又因为资源不足被抢占，形成"创建-杀死-再创建-再杀死"的循环。这个循环不仅白白消耗API Server和调度器的性能，还会让其他正常任务也被波及。

排查时发现根因有两点：一是低优任务没有启用合理的重试策略，业务侧把Pod失败当成临时故障无限重试；二是抢占的reevict策略没有做任务级保护，某些关键但优先级低的作业被误伤。

我的建议是：在使用抢占前，先想清楚哪些作业可以被抢占、哪些不行。可以通过给作业配置不同的PriorityClass、在Job的policies里设置PodEvicted事件对应的处理策略来控制。另外，把preempt和queue配合起来用，让抢占只发生在指定的队列范围内，能有效减少误伤面。

5. 生产环境的调优建议与落地细节

5.1 队列规划：给团队分队列，给阶段分策略

如果你准备在生产环境正式用Volcano，我建议做三件事。第一件事是搭建队列体系，每一个业务团队、每一类重要等级的任务都应该有自己的Queue。我在当前环境里的做法是：ai-training-prod、ai-training-dev、>