大家关注 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 到 PyTorchVolcano 的适配范围已经超出你的想象我记得前几年聊 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 装到自己集群里试试。我建议你从最基础的QueueJob流程开始把调度器的核心行为摸透。以下是一个可以直接照着操作的示例。首先用 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 个 workerapiVersion: 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-namebert-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 一直 PendingPodGroup 卡在 Pending 状态这是使用 Volcano 后最常见的现象。排查顺序我建议固定成这样的流程先看 PodGroup 的statuskubectl get podgroup name -o yaml重点看status.conditions里面会记录为什么没进入 Running。常见原因有resources not enough队列 capacity 不够。这时你去kubectl describe queue查看队列的allocated和capability字段看是不是剩余资源不足。minAvailable not satisfied当前集群符合要求的节点数少于minAvailable。这种情况要检查kubectl describe node node看节点上报的资源是否正常特别是 GPU 卡数有没有因为驱动问题被漏报。PodGroup not foundjob 创建了但 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 reasonEvicted -n namespace如果是运维层面主动驱逐且你的业务支持断点续训那我建议在 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 的分享。提前准备好问题、带着自己的用例去交流这趟行程的收获会比刷一百篇文章都大。