企业官网建设流程全解析

1. 从一张GPU排不上队的截图说起

上周有个做模型训练的朋友甩给我一张截图，集群里八张卡闲了三张，但他提交的分布式训练任务在队列里趴了四十分钟没动静。他问我：调度器是不是坏了？我看了一眼他的作业描述，心里大概就有数了——这不是调度器坏了，是调度器压根没看懂他这活儿该怎么摆。

这件事特别典型。传统调度器是给在线服务和无状态应用设计的，它脑子里装的模型是"一个Pod占多少CPU、多少内存，塞进哪台机器合适"。可AI作业完全是另一套逻辑：一个训练任务可能要几十个Pod同时起来、同时占卡、同时通信，少一个都跑不起来；跑起来之后又可能一跑就是几天，中途还不能被随便打断；更麻烦的是，它要的不是普通CPU，而是GPU、NPU这类加速器，还涉及显存、卡型、拓扑这些细粒度资源。

这就是Volcano要解决的问题。它是从Kubernetes生态里长出来的一套批处理调度系统，专门为AI、大数据、高性能计算这类"作业型"负载做调度增强。你如果正在搭训练平台、跑离线推理、做批量数据处理，或者单纯被"卡明明空着任务却排不上"折磨过，那这篇内容就是写给你的。我会把Volcano接纳AI作业的整套逻辑拆开讲，从它为什么这么设计，到具体怎么配、怎么调、怎么排错，尽量让你看完能直接上手抄作业。

2. Volcano到底在Kubernetes之上补了哪几块短板

2.1 默认调度器为什么接不住AI作业

要理解Volcano的价值，得先看清楚原生Kubernetes调度器的能力边界。原生调度器是"逐个Pod"调度的，它拿到一个Pod，评估一遍节点，选一个最合适的放上去，然后处理下一个。这个模型对Web服务、微服务非常友好，因为那些场景里Pod之间基本独立，谁先谁后无所谓。

但AI作业不是这样。一个分布式训练任务通常由多个角色组成，比如参数服务器架构里有PS和Worker，集合通信架构里有一堆Worker加若干协调节点。这些角色必须"要么全上、要么全不上"，否则就会出现部分Pod占着资源干等，另一部分Pod因为资源不够起不来，整个作业卡死。原生调度器没有"作业"这个概念，它只认Pod，所以很容易造成资源死锁。

第二个短板是资源维度。原生调度器主要看CPU和内存，GPU这类扩展资源虽然能识别，但只当成一个整数计数，不关心显存大小、卡型号、卡之间的互联拓扑。AI作业对这些很敏感，一张A100和一张T4混着用，训练效率能差出好几倍。

第三个短板是调度策略。原生调度器偏向"打散"，尽量把Pod分散到不同节点提高可用性。但AI训练恰恰相反，它希望相关Pod尽量聚在一起，减少跨节点通信开销。这种"成组调度、亲和优先"的需求，原生调度器支持得很勉强。

2.2 Volcano的四个核心能力

Volcano针对上面这些短板，补了四块关键能力，我按重要性排一下。

第一块是作业级调度。Volcano引入了Job这个抽象（它自己有一套CRD），一个Job下面挂多个Task，每个Task可以指定副本数和资源需求。调度的时候以Job为单位做决策，要么整个Job的资源都满足才调度，要么就等着，从根本上避免了资源死锁。

第二块是成组调度（Gang Scheduling）。这是作业级调度的具体实现机制，核心参数是minAvailable。比如一个Job有10个Task，你设minAvailable: 10，那调度器必须凑齐10个Task所需的资源才会真正下发，否则一个都不发。这个机制是分布式训练能跑起来的关键。

第三块是队列与公平调度。Volcano支持多队列，每个队列可以设权重、配额、优先级。这样多个团队共享集群时，能保证每个团队都有基本资源，同时又不浪费空闲资源。它内置了多种调度插件，比如DRF（Dominant Resource Fairness）、Proportion、Capacity，可以按需组合。

第四块是丰富的调度插件体系。Volcano的调度流程是插件化的，enqueue、allocate、preempt、reclaim、backfill这些动作都可以挂插件。你可以按业务需要开启或关闭某个插件，比如开启predicates做资源过滤，开启gang做成组调度，开启priority做优先级抢占。

2.3 一张表看清原生调度器与Volcano的差异

这张表不是要贬低原生调度器，而是说明两者定位不同。实际生产里，Volcano和原生调度器往往是共存的，在线业务走原生，AI作业走Volcano，各管一摊。

3. 作业提交后，Volcano内部到底走了哪几步

3.1 从Job创建到Pod下发的完整链路

很多人用Volcano只是照着文档配了个YAML，但不知道背后发生了什么，一出问题就抓瞎。我把这条链路拆成六步，你跟着走一遍就清楚了。

第一步，用户提交一个Volcano Job的YAML，里面定义了Task、副本数、资源需求、minAvailable等。这个Job被API Server接收，存进etcd。

第二步，Volcano的vc-controller-manager监听到新Job，开始做作业级别的初始化，比如创建对应的PodGroup。PodGroup是成组调度的载体，它记录了这个Job的minAvailable和当前状态。

第三步，vc-scheduler开始工作。它先把Job放进某个队列（Queue），队列的准入由enqueue插件控制。如果队列配额满了，Job就停在Pending，等资源释放。

第四步，进入allocate阶段。调度器遍历Job下的所有Task，为每个Task找合适的节点。这一步会调用一系列插件：predicates做硬性过滤（比如卡型不匹配就排除），gang检查是否凑齐minAvailable，priority决定多个Job竞争时的顺序。

第五步，如果gang插件判定资源凑不齐，整个Job回滚，已经预分配的节点资源释放，Job继续等。这就是成组调度的"全有或全无"。

第六步，资源凑齐后，调度器把绑定决策写回，vc-controller-manager创建真正的Pod，kubelet拉起容器，作业开始跑。

3.2 关键组件各自负责什么

Volcano的组件不多，但职责划分很清晰，搞混了容易排查错方向。

• vc-scheduler：核心调度器，负责队列管理、作业调度、成组判定、抢占决策。出调度问题先看它。
• vc-controller-manager：作业生命周期管理，负责Job、PodGroup、Queue这些CRD的创建和状态维护。作业状态不对先看它。
• vc-webhook-manager：准入控制，负责给Pod打补丁、注入调度信息。Pod没被正确调度有时是它的问题。
• vc-agent：节点侧代理，负责上报节点资源和拓扑信息。资源识别不准先看它。

提示：排查问题时，先确认是"调度没决策"还是"决策了没执行"。前者看vc-scheduler日志，后者看vc-controller-manager和kubelet。

3.3 一个最小可用的Job长什么样

光说概念太虚，直接看一个能跑的最小例子。下面这个Job起两个Worker，每个要一张GPU，必须两个都起来才跑。

apiVersion: batch.volcano.sh/v1alpha1 kind: Job metadata: name: demo-training spec: minAvailable: 2 schedulerName: volcano queue: default tasks: - replicas: 2 name: worker template: spec: containers: - name: trainer image: demo/trainer:latest resources: limits: nvidia.com/gpu: 1 restartPolicy: Never

这里有几个点必须注意。schedulerName: volcano是必须的，否则Pod会被原生调度器接管，成组调度就失效了。minAvailable: 2和replicas: 2要对应，如果你写minAvailable: 1，那就退化成普通调度了。queue指定队列，不写会进默认队列。

4. 成组调度、队列、抢占这三件事怎么配才不踩坑

4.1 minAvailable设多少才合理

minAvailable是成组调度的命门，设错了要么资源浪费，要么作业永远起不来。我的经验是按作业类型分三档。

对于强同步的分布式训练，比如用集合通信的AllReduce架构，minAvailable必须等于总副本数。因为这类训练每一步都要所有节点参与通信，少一个就卡死。你设小了，作业起来了但跑不动，反而更糟。

对于参数服务器架构，PS和Worker的依赖没那么强，可以适当放宽。比如10个Worker配2个PS，你可以设minAvailable: 10，允许部分Worker先起来，PS后到。但要注意，如果PS一直起不来，Worker也会空转。

对于批处理类作业，比如离线推理、数据清洗，任务之间基本独立，minAvailable可以设得很小，甚至设1，让它退化成普通调度，提高资源利用率。

注意：minAvailable设得越大，作业启动越慢，因为要等资源凑齐。集群碎片化严重时，大minAvailable的作业可能长期排队。这时候要么扩容，要么用抢占。

4.2 队列配额怎么划分才不打架

多团队共享集群时，队列配置是门艺术。Volcano的Queue支持weight、capability、deserved这些字段，我一般这么配。

先给每个团队建一个队列，设weight表示相对权重。比如训练团队weight=3，推理团队weight=2，数据团队weight=1。空闲时大家都能用满集群，竞争时按权重分配。

再设capability做硬上限，防止某个团队把集群吃光。比如训练团队最多用80%的GPU，留20%给其他团队应急。

deserved是软保障，表示这个队列至少应该拿到的资源。它和capability配合，形成"保底+封顶"的结构。

apiVersion: scheduling.volcano.sh/v1beta1 kind: Queue metadata: name: training spec: weight: 3 capability: nvidia.com/gpu: 80 deserved: nvidia.com/gpu: 40

这个配置的意思是：训练队列权重最高，最多用80张卡，但至少保障40张。实际用多少取决于竞争情况。

4.3 抢占和回收什么时候该开

抢占（preempt）和回收（reclaim）是两个容易混淆的机制。抢占是"高优先级Job抢低优先级Job的资源"，回收是"队列之间把超用的资源还回去"。

抢占适合场景：你有紧急任务要插队，比如线上模型出问题要紧急重训。开启preempt插件后，高优先级Job可以踢掉低优先级Job。但要注意，被抢占的Job会重新排队，如果它也是长任务，损失很大。所以抢占要慎用，最好配合优先级分级。

回收适合场景：多个队列共享资源，某个队列空闲时把资源借给别的队列，忙起来再要回来。开启reclaim插件后，Volcano会周期性检查各队列的实际使用和deserved，把超出的部分回收。

我的建议是：抢占默认关，只在有明确紧急通道需求时开；回收默认开，能显著提升集群利用率。两个都开的时候要注意优先级配置，别让回收把正在跑的关键任务干掉了。

5. 资源识别、拓扑感知这些细节决定训练效率

5.1 GPU资源是怎么被识别和上报的

Volcano本身不直接识别GPU，它依赖设备插件（device plugin）把GPU注册成扩展资源。以NVIDIA为例，节点上要装nvidia-device-plugin，它会把每张卡注册成nvidia.com/gpu。Volcano的vc-agent再把这些信息汇总，供调度器使用。

这里有个常见坑：设备插件版本和驱动版本不匹配，导致卡识别不全。比如节点有8张卡，只上报了4张。排查方法是看节点的allocatable字段，对比物理卡数。

kubectl describe node <node-name> | grep -A 5 "Allocatable"

如果数字对不上，先查设备插件日志，再查驱动。

5.2 拓扑感知调度怎么提升通信效率

分布式训练里，卡间通信开销能占到总时间的30%以上。如果调度器把同一个作业的Pod分散到跨交换机的节点上，通信延迟会飙升。Volcano支持拓扑感知调度，通过numa、network这些插件，尽量把Pod放在同一NUMA节点或同一交换机下。

配置上，你需要在节点打标签，标明拓扑信息，比如topology.kubernetes.io/zone、node.kubernetes.io/network。然后在Job里通过亲和性规则引导调度。

affinity: podAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchLabels: job: demo-training topologyKey: topology.kubernetes.io/zone

这段配置的意思是：同一个作业的Pod必须落在同一个zone内。这样能保证它们走同一套网络设备，减少跨区通信。

提示：拓扑感知会降低调度灵活性，集群碎片化时可能导致大作业排不上。建议只在通信密集的训练作业上开，推理和批处理不必。

5.3 显存和卡型怎么区分对待

原生调度器只认nvidia.com/gpu这个整数，不区分A100还是T4。但实际业务里，大模型训练必须用大显存卡，推理可以用小卡。Volcano可以通过节点标签加亲和性来实现卡型区分。

先给节点打标签：gpu-type: a100、gpu-type: t4。然后在Job里加节点选择器：

nodeSelector: gpu-type: a100

这样调度器就只会把Pod放到A100节点上。显存区分类似，打gpu-memory: 80g这样的标签即可。

6. 生产环境里那些文档不会写的坑

6.1 作业卡在Pending的六种常见原因

作业起不来是最常见的问题，我整理了一张速查表，按排查顺序排列。

这张表覆盖了我遇到的八成问题。排查时按顺序来，别一上来就怀疑调度器坏了。

6.2 资源碎片化导致大作业排不上怎么办

集群用久了必然碎片化：每个节点都剩一两张卡，但凑不出一个需要16张卡的大作业。这时候有几个办法。

第一，开启backfill插件，让小作业填补碎片，同时给大作业预留资源。第二，用reclaim把其他队列超用的资源收回来。第三，配置preempt，让大作业抢占小作业。第四，最直接的，加节点。

我的经验是，碎片化到一定程度，调度手段只能缓解，根治还得靠容量规划。定期看集群的资源分布，如果碎片率长期超过20%，就该考虑扩容或调整作业粒度了。

6.3 优先级和抢占配置的实战心得

优先级配置有个反直觉的点：优先级数字越大，优先级越高。很多人第一次配会搞反。

apiVersion: scheduling.k8s.io/v1 kind: PriorityClass metadata: name: high-priority value: 1000 globalDefault: false description: "紧急训练任务"

然后在Job里引用priorityClassName: high-priority。抢占时，value大的会踢掉value小的。

我的建议是分三档：紧急任务1000，普通任务500，低优任务100。别设太多档，否则维护起来头疼。另外，被抢占的Job最好配置重试策略，不然踢掉就没了。

7. 我个人在实际操作中的几点体会

调Volcano这几年，最大的感受是：它不是一个"配好就不管"的组件，而是需要跟着业务一起演进的。业务从单机训练走到分布式，从几张卡走到几百张卡，调度配置也得跟着变。我见过太多团队一开始配了个能跑的YAML，后面业务涨了十倍还在用老配置，结果就是各种排队和浪费。

另一个体会是，监控比配置更重要。Volcano暴露了不少指标，比如队列使用率、作业等待时间、抢占次数。把这些接进监控面板，你能提前发现容量问题，而不是等业务方来投诉。我一般会盯三个指标：作业平均等待时间、集群GPU利用率、队列超用比例。这三个数字一异常，基本就能定位到问题。

最后分享一个小技巧：调试调度问题时，把vc-scheduler的日志级别调到-v=4，能看到每个插件的决策过程。虽然日志量大，但排查成组调度和抢占问题时特别管用。平时调回默认级别就行，不然日志能把磁盘写满。