大家关注 KubeCon + CloudNativeCon China 2026 的同时，社区里讨论度最高的一个词就是 Volcano。作为在云原生批量计算和 AI 基础设施领域待了挺久的从业者，我身边不少同行都在等着这次大会里 Volcano 相关的最新进展，毕竟它的每一次版本变化，都直接影响我们生产环境里那几千个 GPU 任务能不能按时跑完。
这篇文章我想以从业者的视角，把 Volcano 在 2026 年这个节点上值得关注的点拆开讲清楚。内容包括它当前在云原生生态里的位置、这次大会上大概率会聊到的技术方向，以及如果你想把 Volcano 真正用起来，需要提前做哪些功课。不管你是刚接触批量调度的新人，还是已经在生产环境里维护智算集群的工程师，都能从里面找到自己关心的东西。
1. 先理清楚：Volcano 在云原生体系里到底解决什么问题
1.1 它不是“又一个调度器”，而是批量计算的准入与控制层
很多刚接触 Kubernetes 的朋友会有个误会，觉得 Volcano 就是换了个 pod 调度算法的插件。这个理解不算错，但远远不够。如果只用一句话概括，我会说：Volcano 是让 Kubernetes 能够高效运行 AI、大数据、HPC 这类批量作业的“作业管理 + 批量调度”中间层。
Kubernetes 原生的调度器 kube-scheduler 是为长时间运行的在线服务设计的。它处理的是 deployment、statefulset 这类“一直活着”的工作负载，调度核心是“能不能找到一个节点把 pod 放下去”。但批量计算不一样，它的特点是：
- 作业有开始、有结束，生命周期短则几十秒，长则几天；
- 一个作业往往包含多个 pod，这些 pod 之间要么有依赖关系，要么需要同时启动（比如分布式训练中 all-reduce 通信要求 rank 之间网络互通）；
- 资源需求往往不是整数。训练任务要 4 张卡，但单机 8 卡，剩下 4 张怎么不浪费？这需要精细的 binpack 和碎片整理能力；
- 队列之间要分优先级。数据预处理任务可以等，但线上一个紧急的模型微调任务需要“抢”到资源。
原生 Kubernetes 对这些问题不能说完全没有支持，但解决方案非常零散。你可能要用 podPriority 做强占，要自己写 controller 来管理作业依赖，要手动处理“gang scheduling”的逻辑。而 Volcano 把这些能力做成了统一的 API 和调度插件，让你通过一个Job对象就能描述完整的多 pod 作业，通过Queue和PodGroup就能控制资源配额和优先级。
1.2 从 Spark 到 PyTorch，Volcano 的适配范围已经超出你的想象
我记得前几年聊 Volcano，大家第一反应是 “Spark on Kubernetes 怎么跑”。后来随着大模型训练和推理需求暴涨，Volcano 的生态覆盖范围已经远不止大数据那一套。目前社区里最主流的集成方向有几个：
第一类是AI 训练与推理。PyTorch 的elastic模式、TensorFlow 的tf-operator、MindSpore、PaddlePaddle，都有官方或社区维护的 Volcano 集成方案。它提供的 gang scheduling 能保证分布式训练的所有 worker 要么全部得到资源，要么全部等待，避免因为部分 pod 启动后网络通信死等导致整个作业卡死。
第二类是大数据计算。Spark、Flink、Ray 的 on Kubernetes 方案里，Volcano 的queue和优先级机制直接对接回填与抢占能力。比如在混部场景下，离线 Spark 任务使用低优先级队列，在线推理服务使用高优先级队列，高峰期离线任务可以被优雅抢占，将资源让给在线任务。
第三类是科学计算与生命科学。MPI 作业、生信分析流程这类传统 HPC 负载，原来跑在 Slurm 或者 PBS 上，迁到 Kubernetes 后用 Volcano 也能保持类似的队列体验和作业依赖管理能力。
所以，当我们在 KubeCon + CloudNativeCon China 2026 上讨论 Volcano 时，讨论的其实是“云原生批量计算的统一底座”这个命题。对平台工程师来说，Volcano 的 API 就是你向上层业务提供的“作业即服务”的入口；对算法工程师来说，它是那群“帮你把训练任务编排好、调度好、异常重试好”的黑盒。
2. 这次大会，Volcano 最值得盯的几个方向
2.1 智能调度算法和异构资源调度
在 KubeCon 的议题里，调度器和资源管理历来是核心方向之一。以我对这个项目近两年 Roadmap 的观察，2026 年这届大会上，异构资源调度会是绝对的重头戏。
这里说的异构不只是“CPU 和 GPU”，还包括 GPU 型号差异、HBM 容量差异、NPU 加速卡、甚至 RDMA 网卡资源。你训练一个 70B 模型时，不同层对显存的需求是不同的；推理场景里，A100 和 H800 的算力差异、显存带宽差异，直接影响调度策略。Volcano 社区这两年在做一个明确的事情：把资源模型的抽象从 “nvidia.com/gpu” 这种简单的 counting 模式，升级为支持多维度的设备属性匹配。
举个例子，我有个朋友维护一个推理平台，他们 vGPU 池子里有 A10、A30、A100 三种卡。以前要做的事情是给每种卡打 label，然后用 nodeSelector 硬绑。工作量大不说，一旦某种卡的空闲资源出现碎片，调度效率就直线下降。如果 Volcano 的拓扑感知和设备属性调度能力成熟，它就能基于“需求的显存 + 算力 + 带宽”去做综合打分，而不再只看“数量是否够”。
另一个值得关注的是NUMA 感知和 Topology 调度。大模型训练的通信密集度非常高，如果两个 worker 分别被调度到不同 NUMA node 上，或者跨了 CPU socket，那么 NCCL 通信的延迟就会明显恶化。Volcano 和 Node Resource Manager 这类底层组件结合，可以在调度阶段就把 CPU 拓扑、GPU 亲和性考虑进去。这一块如果能在大会上看到生产环境的落地案例，我建议一定去现场听听。
2.2 AI 训练与推理的一体化调度
过去大家觉得 Volcano 主要是“训练调度器”，但我预测 2026 年的议题里会有大量篇幅在讨论训练与推理的混合调度。
原因很实际：很多公司的 GPU 集群已经不再是“训练归训练、推理归推理”两块完全隔离的资源了。训练任务有明显的波峰波谷，推理服务的负载也有明显的昼夜规律。如果能做分时复用，同样一批卡白天跑推理、夜间跑训练，综合利用率能从 30% 提到 70%。但这件事难度很大，推理服务对延迟敏感，不能被抢占得太狠；训练任务的 checkpoint 频率、弹性扩缩容能力、容错能力，决定了它能不能“被打断后继续”。
Volcano 现在的模型是在一个Queue里同时跑在线和离线作业，通过 priority 和 preempt 策略控制优先级。但真正要做到无缝混部，还需要和 Kubernetes 原生的 autoscaler、以及上层业务侧的弹性训练框架做更多联动。比如 PyTorch 的 elastic training 支持节点动态变化，那么当训练任务被抢占后，它是否能自动缩容，释放资源给推理服务，等推理低谷时再重新扩容？这个闭环如果打通，平台效率和业务稳定性会有质的提升。
所以这次 KubeCon 上，如果有关于“Volcano 与弹性训练框架集成”“基于 Volcano 的在离线混部实践”这类分享，我会非常建议平台团队派代表去听。因为它解决的已经不只是调度技术问题了，而是整个 GPU 成本模型的问题。
2.3 多云与边缘场景下的调度策略
还有一个可能的热点是 Volcano 在多云和边缘场景的进展。Kubernetes 生态这几年有一个明显的分化：核心数据中心里的集群越来越集中、规模越来越大，而边缘侧则越来越碎片化。Volcano 本身是中心化的调度器架构，但如果要覆盖边缘节点，网络分区、弱网环境、节点频繁上下线都会是新的挑战。
在多云方向，我关注的是 Volcano 是否能作为跨集群的“作业调度入口”，而不是每个集群都部署一套。类似的工作已经有 Karmada 这类多集群管理项目在做，但它们的重心是工作负载的分布，对“作业”这种批量生命周期概念的支持还不够深。Volcano 如果能在多集群联邦层做一层 job 抽象，那就非常有意思了——用户只需要描述“我要跑一个 64 卡规模的训练任务”，由调度层决定这 64 张卡分布在哪个集群的哪些节点上，并且处理集群间通信延迟问题。
不过从实际经验看，跨集群做大模型训练的场景目前并不普遍，主要瓶颈在网络带宽和高昂的通信成本。所以这一块我更倾向于大会上的相关内容是“探索性”和“架构设计”层面的，离生产落地还有距离。但这恰恰是技术前瞻的意义所在，提前看到方向，你才能在轮到自己做选型时心里有数。
3. 从大会回到生产：Volcano 的落地实操与关键技术点
3.1 创建队列和部署作业的完整流程
很多人听完大会分享，第一反应是把 Volcano 装到自己集群里试试。我建议你从最基础的Queue+Job流程开始，把调度器的核心行为摸透。以下是一个可以直接照着操作的示例。
首先用 Helm 安装 Volcano（这里假设你已经有一个可用的 Kubernetes 集群，版本在 1.24 以上）：
helm repo add volcano https://volcano-sh.github.io/charts helm repo update helm install volcano volcano/volcano -n volcano-system --create-namespace安装完成后，创建一个队列。队列的作用是对资源做逻辑分组，比如你给某个业务线分 200 个 CPU、8 块 GPU，这个配额就是在这里定义的：
apiVersion: scheduling.volcano.sh/v1beta1 kind: Queue metadata: name: ai-training spec: weight: 10 capability: cpu: "200" memory: "500Gi" nvidia.com/gpu: "8"这里有个容易忽略的点：weight和capability是两套逻辑。capability是队列的硬上限，决定了这个队列最多能使用多少资源；weight则用于队列间资源分配时的比例权重，当集群资源紧张时，Volcano 会按照 weight 计算各队列可分得的资源份额。你要理解“capability 是天花板，weight 是竞争时的优先级权重”，这样才不会在实际配置时糊涂。
接下来是创建作业。假设我们要运行一个 MPI 分布式训练任务（4 个 worker）：
apiVersion: batch.volcano.sh/v1alpha1 kind: Job metadata: name: bert-pretrain spec: minAvailable: 4 schedulerName: volcano policies: - event: PodEvicted action: RestartJob tasks: - name: worker replicas: 4 template: spec: containers: - name: training image: your-registry/train:latest resources: requests: cpu: "8" memory: "64Gi" nvidia.com/gpu: "1" limits: cpu: "8" memory: "64Gi" nvidia.com/gpu: "1" restartPolicy: OnFailure这里minAvailable: 4是最关键的一行。它的意思是：这个 Job 最少需要 4 个 pod 全部就绪才能开始运行。如果集群里当前只能满足 3 个 pod 的资源，那么这 3 个 pod 会进入 Pending 状态，而不是先启动起来干等第 4 个。这就是 gang scheduling 的核心语义，也解决了我前面提到的分布式训练中部分节点启动、部分节点卡死的问题。
提交作业：
kubectl apply -f queue.yaml kubectl apply -f job.yaml查看调度状态：
kubectl get podgroup -l volcano.sh/job-name=bert-pretrain kubectl describe podgroup bert-pretrain你会看到 PodGroup 的状态从 Pending 变为 Running，这个过程就是 Volcano 在完成“资源预留 + 所有 pod 就位”的检查。如果资源不足，PodGroup 会停留在 Pending，并且你能在kubectl describe pod里看到类似0/8 nodes available: 4 insufficient nvidia.com/gpu的提示。
3.2 用拓扑调度优化大模型训练的通信性能
调度器能把 pod 放在“能用的节点”上只是及格线，真正有价值的是让它把 pod 放在“应该放的节点”上。大模型训练里，节点间通信基本走 RDMA 或者高速 InfiniBand。如果你的集群里有几台机器是跨交换机连接的，调度的时候就要尽量把同一个作业的 worker 集中在同一台交换机范围内。
Volcano 目前支持的nodegroup和topology策略可以帮你做这件事。它的原理简单说就是把集群节点按某个维度分组（比如 rack、交换机），然后在调度时尽可能把同一个 job 的 pod 分到同一组里。
配置方式比较直观，给节点打上标签，然后在 job 的task里声明：
annotations: scheduling.volcano.sh/node-group: "gpu-rack-01"或者更灵活的做法，使用volcano.sh/affinity里的podGroupAffinity，让同一批 pod 优先调度到同一批节点：
affinity: podGroupAffinity: minNumberOfPods: 4这块要提醒的是：拓扑调度的本质是“用一部分调度自由度换取通信性能”。如果你们集群规模不大（几十台机器以内），网络拓扑比较简单，这个配置带来的收益不明显，反而可能因为约束太强导致调度失败。建议先做好监控，看训练作业实际的通信占比，再动态调整拓扑约束的强度。
3.3 抢占策略的正确打开方式
Volcano 的抢占是很多人又爱又恨的功能。爱它是因为真能在资源紧张时把集群利用率拉满；恨它是因为配置不对，容易把在线服务打挂。
默认情况下，Volcano 的preempt策略发生在队列之间和队列内部。高优先级的 job 在资源不足时，会尝试抢占低优先级 job 已占用的资源。我见过不少团队在生产环境里踩过同一个坑：把业务 pod 的priorityClassName设得很低，结果每次有训练任务提交，推理服务就被抢占，导致线上抖动。
我的建议是，严格区分“在线服务 pod”和“离线作业 pod”，并且给它们设置好PriorityClass后，再让 Volcano 接管。举例：
apiVersion: scheduling.k8s.io/v1 kind: PriorityClass metadata: name: online-critical value: 1000000 globalDefault: false description: "在线核心服务，不可被抢占" --- apiVersion: scheduling.k8s.io/v1 kind: PriorityClass metadata: name: offline-batch value: 100 globalDefault: false description: "离线任务，可被抢占"然后在提交 Volcano Job 时，通过policies指定抢占行为：
policies: - event: TaskFailed action: RestartJob - event: PodEvicted action: RestartJob更重要的是，你需要理解 Volcano 的preempt并不能跨 Kubernetes 的 PriorityClass 层级“保护”所有类型的 pod。如果在线服务没有通过 Volcano 队列管理，而是直接用原生 deployment 跑的，那它不会进入 Volcano 的资源统计模型。也就是说，Volcano 分配资源时看不到那部分负载，可能造成资源超卖，反过来让在线服务受到影响。所以，不要等到生产环境出问题才做全量迁移，最好从建设初期就把集群里的所有负载纳入 Volcano 的资源视图。
4. 常见问题与排查技巧实录
4.1 Pod 一直 Pending，PodGroup 卡在 Pending 状态
这是使用 Volcano 后最常见的现象。排查顺序我建议固定成这样的流程：
先看 PodGroup 的status：
kubectl get podgroup -o yaml重点看status.conditions，里面会记录为什么没进入 Running。常见原因有：
resources not enough：队列 capacity 不够。这时你去kubectl describe queue，查看队列的allocated和capability字段，看是不是剩余资源不足。minAvailable not satisfied：当前集群符合要求的节点数少于minAvailable。这种情况要检查kubectl describe node看节点上报的资源是否正常，特别是 GPU 卡数有没有因为驱动问题被漏报。PodGroup not found：job 创建了但 PodGroup 没有生成。大概率是你没在 job 的 spec 里写schedulerName: volcano，或者控制器没正常监听。查看 volcano-controller 的日志：
kubectl logs -f -n volcano-system deployment/volcano-controller4.2 GPU 卡资源被大量浪费，调度不紧凑
有一种情况是，每个任务只需要 2 张 GPU 卡，但每台机器有 4 张卡。如果调度器不做 binpack，可能会出现每台机器上“插花式”地分配资源，最终导致剩余的 1 张、2 张卡碎片太多，无法凑出一个完整任务。
Volcano 解决这个问题的手段是提供spread和binpack两种插件策略。如果你更在意资源利用率，建议在调度配置里开启binpack，并调高binpack.weight。它的直观效果是“尽量把任务塞进同一批节点”，减少空余碎片。
配置位置在 volcano-scheduler 的 configmap 里，核心参数类似：
actions: "enqueue, allocate, backfill" plugins: - name: binpack arguments: binpack.weight: 0.1不过 binpack 不是越高越好。如果过强，会让所有任务堆在少数几台机器上，造成 CPU、内存的局部热点，反而拖慢单节点上的计算速度。我的经验是，在纯 GPU 任务且网络互联很均匀的集群里，可以把 binpack 权重调到 0.2 左右；如果涉及大数据混部，保持默认 0.1 就好。
4.3 抢占后任务仍卡死不重试
Volcano Job 默认对部分事件有自动重试机制，但上面也说了，PodEvicted后要 RestartJob 是需要你显式写 policy 的。很多团队初始化时没注意这个配置，结果节点维护时 pod 被驱逐，整个 job 就停尸在 Failed 状态。
我自己处理这类问题时的排查经验是：先去事件里看驱逐原因：
kubectl get events --field-selector reason=Evicted -n 如果是运维层面主动驱逐，且你的业务支持断点续训，那我建议在 Job 的policies里加上PodEvicted -> RestartJob，同时把restartPolicy设为OnFailure。但要做好心理准备：任务重启后，如果训练框架没有做 checkpoint 对接，数据可能会从头开始。所以生产上一定要把 checkpoint 周期与调度器重试策略协调好——我见过太多的案例是“调度器完美重试，但训练框架从头再来”，最后浪费的时间比不重试还多。
4.4 队列配额改了半天，资源还是不够
Volcano 的 Queuecapability修改后不会立刻提升已创建 job 的配额。你需要通过 Python API 或直接改queue.spec.capability来调整，但新配额仅在下次调度时生效，已有 job 的 PodGroup 不会动态扩容。如果你测试时改了队列资源却看到 job 一直 Pending，可以先把这个因素排除掉。
另外一个隐藏点：Volcano 的队列配额只是调度层面的逻辑限制，它不会阻止 Kubernetes 原生资源（比如 Deployment）超用这部分容量。如果你们集群里混部了非 Volcano 工作负载，那些负载是不受 Queue capability 约束的。所以当出现“明明队列空闲，但节点资源还是不足”的情况，别只盯着 Volcano，先查查是不是有原生的 pod 占住了资源。用：
kubectl get pods --all-namespaces -o wide | grep -v volcano筛选一下就能发现。
5. 参会建议：怎么把 KubeCon 的价值“带回家”
5.1 提前做好议题筛选
KubeCon + CloudNativeCon China 2026 的参会者很多，热门的 topic 都会爆满。我给你的第一个建议是：不要等到现场再去看日程，会在会议开始前一到两周，通过官网或者 CNCF 的活动 App 把议题预览过一遍，选出和 Volcano 强相关的 session，标记好时间地点。
筛选标准我给三个：
第一个是看 title 和 abstract 里是否包含 “batch”“queue”“scheduling”“GPU”“AI infrastructure” 等关键词。通常这类议题背后就是调度器或资源管理团队的最佳实践。
第二个是看 speaker 的团队背景。如果演讲者来自你所属行业的头部公司（比如金融科技、自动驾驶、大模型创业公司），分享内容往往贴合业务实际，含金量更高；如果来自 CNCF 或厂商研发团队，可能偏架构演进和未来规划。
第三个是看 session 的类型。Hands-on Lab、Tutorial 这种互动性强的活动，比纯 talk 更适合新人；而如果你已经在生产里用了 Volcano，更应该去听 case study，而不是 Introductory 级别的分享。
5.2 带上你的“真实问题清单”去现场聊
KubeCon 的价值一半在会场里，一半在会场外。我的习惯是：参会之前，把生产环境里困扰自己的两三个具体问题写下来。比如：
- “我们的训练任务在批量提交时出现队列排队过长，如何优雅设置 queue weight？”
- “Volcano 是否支持我们自研的网络拓扑感知插件，需要改哪些代码？”
- “集群从 100 卡扩到 1000 卡，Volcano 的调度性能会有什么变化？”
这些问题带到 project 的 maintainer session、或者社区展台前直接问，效率远比自己回去翻文档高。Volcano 社区在 KubeCon 上的 maintainer 通常都愿意深入交流，尤其是你如果能把问题描述清楚、附上相关 log，基本能拿到比文档里更实用的建议。
另外一个容易被忽略的是社区生态展区。Volcano 的集成伙伴（比如 PyTorch、Spark、Ray 的维护者或者云厂商的团队）通常也会在展台出现。你可以实际去问他们“你家的 operator 对 Volcano 新版本的支持进度如何”。这类信息对于企业选型和升级往往比看代码仓库的 release notes 更直观。
5.3 录音、问答和后续沉淀
大会的 session 一般不允许全程录像，但记笔记和录音（提前问 speaker）是完全可以的。我自己的做法是，每场 session 结束后的 5 分钟休息时间里，快速写三条结论和两个待查问题。这比会议结束回家对着几十页 PPT 发呆要高效得多。
回来后的复盘也一样重要。KubeCon 上听到的内容不一定每一页 PPT 都能直接用，但有价值的不是“别人做了什么”，而是“别人的思路能否迁移到我的场景”。比如某家公司的 Volcano 队列模型，很可能稍微改改就能套用到你们的多租户平台里；某个 new feature 的 roadmap，很可能影响你们未来半年的资源规划节奏。
我个人的建议是：会议结束后两周内，把带走的信息整理成一页纸的“行动项”，分发给自己团队，并明确责任人。否则信息很快就会被日常崩线的告警淹没，参会就成了一次昂贵的技术旅游。
6. 结合我自己的实践，给平台团队的几句心里话
Volcano 不是银弹。如果你的集群只是跑少量无状态服务，队列和 gang scheduling 对你可能没什么明显感觉。但如果你开始接触大模型训练、分布式计算、或者多团队共享 GPU 资源，Volcano 这种“面向作业”的调度抽象几乎可以说是必需品。
在生产环境用了几年之后，我的核心体会是：调度器只是“资源之门”，真正的稳定性来自业务侧与调度器的配合。比如 checkpoint 是否完善、训练框架是否支持弹性、业务队列的优先级设计是否合理，这些看起来不属于调度器范畴的事情，反而决定了调度器能做得多好。
还有一点必须提醒：别等集群规模爆炸了才开始学 Volcano。这类系统的学习曲线不陡，但涉及的调度语义、事件策略、插件机制需要时间去理解。建议你现在就在一个测试集群里部署一套，跑几个模拟的训练作业，把 queue、priority、preemption、gang scheduling 这几个核心概念亲手验证一遍。等真正需要它在生产环境扛大活的时候，你就不会手忙脚乱。
KubeCon + CloudNativeCon China 2026 是难得的机会。如果你所在团队的云原生架构里有 AI 或大数据负载，我真心建议去现场关注 Volcano 相关的内容和技术 maintainer 的分享。提前准备好问题、带着自己的用例去交流，这趟行程的收获会比刷一百篇文章都大。