这几天业内群聊里，KubeCon + CloudNativeCon China 2026的消息一出来，话题热度马上就上来了。很多人第一反应是问阵容、问议程、问有没有搞头，但我身边的运维和平台架构团队，问得最多的反而是另一个问题：Volcano今年到底会讲什么。
这个反应其实很真实。过去几年云原生大会的内容重心，明显从“怎么把容器跑起来”转向了“怎么把复杂的作业调度好、资源利用率提上去”。而只要聊到调度，Volcano就绕不开。它已经从最初那个专门解决MPI、TensorFlow任务调度痛点的项目，长成了CNCF生态里负责批处理、AI训练、大数据作业调度的主力选手。借着2026年大会的预热窗口，我把Volcano目前的一些技术重点、社区动态、以及落地时需要想清楚的事情整理一下，方便你参会的时候能有的放矢，而不是到了现场一头扎进人堆里。
1. 抢鲜预告：为什么 Volcano 是 KubeCon 2026 不可跳过的一条主线
1.1 从“跑通 Pod”到“调度作业”：云原生下一阶段的关键词
早些年大家用Kubernetes，讨论的都是Pod、Service、Deployment这些基础概念，好像能把服务稳定跑起来就算成功。但这两年的风向明显变了：数据预处理、模型训练、Spark批处理、科学计算任务，统统开始往Kubernetes上搬。这类工作负载和传统无状态服务最大的区别在于，它们以“作业”为单位，而不是以“单个容器”为单位。一个作业可能是几十个、几百个、甚至上万个Pod协同工作，互相之间有依赖、有顺序、有资源竞争。
默认的kube-scheduler当然不是不能调度，但它的设计视角一直是“单Pod独立调度”。今天调度一个Pod，它不太关心这个Pod是不是某个作业的一部分，也不关心这个作业里的其他Pod现在是什么状态。这在跑微服务的时候问题不大，但放到分布式训练上就会出大问题。训练任务经常要求所有Worker同时就绪，缺一个都跑不起来。如果调度器把一个作业里的前99个Pod都安排好了，最后一个Pod因为资源不足一直Pending，那整个作业就卡死了，前面的资源也全被白白占着。
Volcano出场要解决的，就是这个被称为“作业级调度”的问题。它在Kubernetes默认调度能力之上，抽象出了PodGroup（一组Pod的集合）、Job（作业）、Queue（队列）这些概念，让调度器能够站在“整个作业”的视角去分配资源，而不是看到一个Pod就调度一个Pod。这个转变，是云原生从“支撑在线应用”走向“支撑完整业务负载”的关键一步。所以2026年大会上，Volcano相关的内容必然会成为很多人关注的焦点，因为大家已经不再是抱着尝鲜的心态看它，而是真的要在生产环境里做决策。
1.2 Volcano 解决的不是单点问题，而是资源利用的整体效率
很多人对Volcano有一个误解，觉得它就是一个“给AI训练用的调度器”。这个说法没问题，但太窄了。Volcano本质上是一个通用的批处理和弹性工作负载调度平台，AI训练只是它最亮眼的场景之一。
如果拆开看，Volcano解决的是集群资源利用效率的整体问题。首先是公平性，多个部门、多个团队共享同一个集群，怎么保证谁也不会饿死谁，怎么让高优先级作业插队，同时又不至于让低优先级任务永远等不到资源。其次是资源碎片，GPU、CPU、内存、NPU这些资源分散在不同节点上，调度策略怎么选择才能尽量把碎片拼起来，避免出现“每台机器都剩一点，但谁也跑不了新作业”的尴尬。再其次是混合部署，在线服务白天高峰、离线任务晚上低峰，能不能通过抢占、驱逐、回收机制让这些负载更好地共享集群。
这些需求都不是某一个插件能搞定的，需要一个系统性的框架。Volcano采用的就是“Action + Plugin”的灵活架构，把调度过程拆成Enqueue（入队）、Allocate（分配）、Preempt（抢占）、Reclaim（回收）、Backfill（回填）等多个动作，每个动作又可以挂载不同的插件，比如gang调度、binpack打包、DRF公平份额等。这种架构给了平台工程师极大的定制空间，也让Volcano能适配不同行业、不同规模集群的差异化需求。
1.3 普通开发者也要关注的原因
我知道很多读者可能并不直接维护集群，甚至只是把应用部署到公司统一的K8s平台上。那Volcano和你有什么关系？
关系很大。如果你的业务是数据仓库的定时ETL，如果你们部门在集群里跑着每日一次的推荐模型更新，如果你的公司把在线推理和离线训练放在同一套基础设施上，那么底层调度策略的好坏，直接决定了你提交的作业是排队三分钟还是三十分钟，是稳定跑完还是因为资源被抢占而失败重试。Volcano的队列机制、优先级策略、抢占规则，本质上就是在帮不同业务划分“资源地盘”，并且在这些地盘之间建立规则。
我之前见过一个例子，某个数据团队在没上队列管理之前，一个跑了两小时的Spark作业常常因为凌晨的批量任务资源竞争，速度慢到四五个小时才跑完。后来平台组用了Volcano的队列加上公平调度策略，把在线推理和离线批处理放到不同队列，设好权重和优先级，同样作业的耗时直接降了接近一半。所以哪怕你不是平台团队的人，了解一些Volcano的基础概念，也能在业务侧更好地理解“为什么我的作业跑这么慢”“为什么资源要这样分”。
2. 拆解 Volcano 的核心调度逻辑：队列、插件与设备共享
2.1 队列模型：多个团队怎么公平地分同一个集群
要说Volcano最实用的能力，队列管理能排到第一。很多企业集群是多团队共用的，如果没有任何资源治理，最后一定是某个“嗓门大”的团队把集群占满。Volcano的Queue模型提供了一套类似“资源配额+弹性共享”的机制。
每个Queue可以设置capability（容量上限），比如CPU 200核、GPU 100卡。这个上限不是硬性的物理隔离，而是调度器的约束条件：当队列内资源用量未达到上限时，作业正常排队调度；当队列资源已满时，新作业进入Pending状态，等待资源释放或者被其他队列抢占。配合上每个作业的PriorityClass（优先级），调度器可以在多个队列之间做权重分配和抢占决策。
举个例子，你有两个队列：一个是在线推理队列，一个是离线训练队列。在线推理业务通常时延敏感，可以配置较高的优先级和较大的capacity；离线训练任务则可以配置为可被抢占的“低优”作业。当在线业务高峰期资源不够时，调度器会把低优先级离线作业驱逐或抢占掉，把资源让给在线业务；等高峰期过了，离线作业又可以自动恢复调度。这套逻辑在实际落地中非常重要，因为它让混部成为可能，直接提升整个集群的资源利用率。
2.2 插件化动作：gang、binpack、fair-share 如何配合
Volcano的调度器核心是一组“动作”的循环执行。每个动作是一个调度阶段，而每个阶段内部又可以启用不同的插件。这种设计最大的好处是，调度策略不再是一个黑盒子，而是可以按需拆解、组合、替换。
最常用的是gang插件，也就是“All-or-Nothing”调度。它保证一个作业里的所有Pod要么全部被调度，要么一个都不调度。这个能力对分布式训练至关重要。比如一个PyTorch训练作业需要8个Worker同时运行，gang插件会检查集群是否有足够的空闲资源一次性满足8个Worker的需求，如果不够，就整个作业都不调度，避免出现部分Pod占着资源、整个作业却无法启动的死锁情况。可以把gang理解成包场看电影，人数凑不够就不开场，免得大家进去了也看不完整场。
binpack插件则负责“把Pod往尽量少的节点上塞”，通过计算节点资源利用的离散程度，优先选择那些能填得更满的节点。这样做能减少集群的节点碎片，尤其对于大规模GPU集群，能把不同作业的Pod打包到同一批节点上，节省出更多整节点用于其他作业。fair-share（DRF）插件则解决“多作业公平共享”的问题，它参考的是主导资源公平算法——看每个作业对某一种资源的“主导份额”，然后尽量让所有作业的主导份额接近。这样不会出现一个作业把CPU全占了、另一个作业只需要内存却没得用的极端情况。
实际生产环境中，这些插件通常是组合使用的：一个作业先通过gang判断是否能够整体调度，再通过binpack选择合适的节点，同时整个调度流程受fair-share和priority的影响。灵活性非常高，也非常考验平台工程师对业务负载模型的理解。
2.3 设备维度：GPU 共享与异构资源
2026年前后，GPU和各类AI加速卡在Kubernetes集群里的地位已经不需要再强调了。但一个容易被忽略的问题是，GPU不是“分配一个设备”就完事了，还要考虑显存、算力、共享粒度、拓扑亲和性。
Volcano对设备共享的探索一直很积极，尤其是GPU共享调度。在很多推理场景里，单个推理任务根本用不满一张GPU卡，如果把整张卡分配给一个Pod，剩下的算力就浪费了。通过Volcano的GPU共享调度，可以让多个Pod共享同一张物理GPU，同时限制每个Pod能够使用的显存和算力比例；还能结合不同卡的显存大小做更细粒度的“设备规划”，比如一张40GB的卡，可以拆成多个10GB的调度单元，让更多小作业能被塞进同一节点。
对于依赖NPU、FPGA这类异构设备的环境，Volcano也提供了灵活的device plugin对接方式。它并不试图替代各家硬件厂商的device plugin，而是通过统一的资源上报、节点拓扑感知和调度策略，让上层作业能感知到底层设备的具体型号、显存容量和拓扑位置，从而做出更优的资源选择。这一点在千卡以上集群里尤其重要，因为这时通信拓扑已经能直接影响训练性能了，不能只管“有卡没卡”，还得管“卡和卡之间挨得近不近”。
3. 这次大会上，Volcano 技术话题里最值得跟进的三条线索
3.1 调度吞吐提升：往更大集群、更大作业规模迈进
如果你关注过Volcano的issue和社区讨论，会发现“调度吞吐”和“性能压测”是最近一年多的高频词。原因很好理解：现在不少企业的集群规模已经从数百节点涨到了数千节点，训练作业也从单机多卡变成大规模分布式，一次提交的Pod数量动辄数千甚至上万。传统调度器在这种压力下，很容易出现调度时延飙升、API Server负担过重、调度队列堆积等问题。
在这一版大会预告里，调度吞吐和性能优化大概率会是被反复提及的内容。社区在做的方向基本包括：减少调度器与API Server之间的冗余请求、提升PodGroup创建和状态同步的效率、优化调度周期内对不同队列和作业的遍历逻辑、支持更细粒度的调度并发控制等。对于正在运行大规模集群的团队来说，这些改动直接影响实战体验。
我建议你在听相关议题的时候，重点关注两个指标：调度吞吐量（每秒能成功调度多少个Pod）和调度时延P99（在压力状态下单个Pod从入队到绑定节点的耗时）。这两个指标最能反映调度器在极端场景下的真实表现，比单纯看功能列表有价值得多。
3.2 与 AI 训练框架的深度融合：生态位越来越清晰
Volcano之所以在AI算力调度领域有不可替代的地位，很大一部分原因在于它和主流训练框架的集成关系已经非常深入。Kubeflow的PyTorchJob、TFJob，Spark的K8s原生调度器，PaddlePaddle、MindSpore的训练任务，都能和Volcano对接。Volcano在其中扮演的不只是一个底层调度插件，更是统一作业生命周期管理的入口。
2026年的大会内容里，AI平台相关的实践分享会是一个重头戏。你可以关注这些内容：Volcano如何与Kueue、KubeFlow这类作业编排层协同，如何在ModelKits或者推理服务框架中接入统一调度能力，以及如何把队列管理、配额管理、优先级策略覆盖到从训练到推理的全链路。
从整个云原生AI生态来看，Volcano的定位越来越像“调度底座”。上层的AI平台、中间层的训练框架、下层的异构硬件，都要通过某一种方式连接到一起，而调度层就是那个承上启下的关键环节。如果你所在团队正在建设AI基础设施，这部分信息非常值得提前做功课。
3.3 面向运维侧的可观测性与稳定性
功能再强，不好用、不稳定，生产团队还是不敢用。这也是Volcano社区最近投入很大的方向：可观测性和运维友好性。
所谓可观测性，就是让平台团队能够实时看到“队列里有多少作业在排队”“每个作业为什么Pending”“资源到底卡在哪个环节”。目前不少使用Volcano的团队，依赖的还是自建监控和日志来排查问题，过程比较痛苦。社区在推进的是更完善的调度指标暴露、事件机制和Dashboard能力，让调度器的运行状态透明化。这次大会上相关主题的价值在于，你能了解到这些能力的成熟度——到底只是雏形，还是已经可以生产使用。
稳定性的部分，主要涉及抢占和驱逐的可靠性、调度器自身的HA方案、以及异常情况下的恢复能力。调度器是整个集群的“总指挥”，如果它挂了或者状态错乱了，影响面是全局性的。Volcano在这些方面一直在持续加固，但具体到了什么程度，还需要结合社区最新版本的Release Note来看。
4. 从社区近况看 Volcano 的 2026：稳定压倒一切的工程走向
4.1 性能优化的持续推进
从2023年到现在的几次重要版本发布，Volcano给我的感觉是越来越“稳”了。早期版本里有不少调度器崩溃、死锁、状态不一致的issue报告，近一年这些和稳定性相关的重大bug明显减少。这不是偶然，而是社区把大量精力投入到了核心路径的代码质量、回归测试和混沌工程上。
性能方面，Volcano社区做了很明显的针对性优化，比如对大规模PodGroup的调度流程进行了重构，减少了无谓的状态转换；对队列调度的锁粒度做了优化，降低了高并发场景下的锁竞争；还对调度器与Informer的交互方式做过调整，减少资源对象在大规模集群中的重复监听开销。这些优化单看每一项都很细节，但组合起来，就是在几千节点集群上调度体验的质变。
我在自己的生产环境测试中，最大感受是：调度器的CPU和内存占用变得稳定了，不会因为某个大作业提交就出现明显的内存尖刺。这种“没什么存在感”的状态，其实才是调度器最好的状态。
4.2 运行时生态的“连接器”角色
另一个值得关注的动态是Volcano正在成为一个越来越标准的“连接器”。它的API能力不只是面向开发者的，更是面向生态系统的：一方面，它兼容Kubernetes的原生API，你不需要把集群翻个底朝天就能接入；另一方面，它提供了上层的自定义资源接口，云厂商、AI平台厂商可以在它之上做自己的产品封装。
国内不少云厂商的AI容器服务、数据科学平台，底层调度用的就是Volcano或其变种。这种生态蔓延带来的直接影响是，Volcano的版本兼容性和API稳定性变得非常重要。2026年大会如果涉及企业落地案例，建议听一听他们是怎么做版本升级的——是直接平滑升级，还是需要业务侧配合调整。这比任何技术指标都更能反映项目的真实成熟度。
4.3 落地用户增多带来的真实反馈
社区项目的生命力，最终要看有没有人在真实生产环境里用，并且愿意把问题和成果拿出来讲。从这些年KubeCon的演讲主题就能看出来，Volcano的分享者已经从“项目开发者”扩展到了“行业用户”：有做自动驾驶数据闭环的，有做金融风控模型训练的，有做推荐系统大规模离线训练的，也有做科学计算和基因测序的。
这些来自不同行业的分享往往会带出一些非常细节的痛点，比如“某个特定型号的GPU在binpack策略下出现了资源碎片”“队列的抢占配置在某种业务场景下导致了频繁的重调度”“多租户场景下如何设计队列层级”。这些问题你在官方文档里是看不到的，只有真实用户踩过坑之后才会讲出来。参加大会的时候，这种分享的价值往往高于单纯的功能宣传。
5. 如果你也准备去现场逛，这是我给你的 Volcano 参会行动建议
5.1 会前先把集群“体检单”列出来
参会不是“去听一耳朵”就完事，尤其是如果你带着实际工作目标，建议会前先花一两个小时，把你当前集群的情况梳理一遍。列几个关键问题：集群规模是几百节点还是几千节点？主要跑的是在线服务、离线训练还是大数据作业？当前资源利用率是多少？有没有出现过资源分配不公平、作业互相抢占的情况？用过队列管理吗？如果没有，最想解决哪个问题？
这些问题不需要太复杂，但一定要具体。带着具体问题去听演讲，你会发现完全不一样的关注点。比如你正在头疼“多团队怎么分资源”，你就会更仔细地听队列配置的细节；如果你正被GPU利用率低困扰，你就会特别关注设备共享和binpack的案例。没有问题的参会，很容易变成走马观花。
5.2 带着问题逛展台和分会场，别只领纪念品
Volcano在大会上的存在感这几年一直很强，展台会有核心维护者志愿者坐镇。这是非常难得的机会，因为平时你在GitHub上提issue、在Slack里提问，响应速度再快，也不如面对面聊得清楚。去展台的时候，我建议准备几个有深度的问题，而不是问“Volcano是什么”这种主页上就有答案的问题。
可以问的技术点包括：“抢占配置在Production环境里怎么调参才不会引起频繁驱逐？”“多队列场景下，单队列的资源上限满了之后，借调资源的逻辑是怎样的？”“如果我们的设备是自研NPU，device plugin需要怎么适配才能被Volcano调度？”“调度器本身的高可用方案有什么推荐实践？”“在Kubernetes原生调度器已经支持了一些调度框架能力之后，为什么还推荐用Volcano？”
这些问题没有任何一个是能在两分钟内回答完的，但正因为如此，你才能在和维护者交流的过程中获得真正的洞察。同时，你也可以观察其他参会者在问什么，那些往往是行业里最普遍的痛点，对你自己的选型判断也很有参考意义。
5.3 会后第一周做小范围灰度，比任何总结都有用
大会结束回到工位，最忌讳的事情就是“看起来都懂了，然后就搁置了”。我的个人经验是，会后第一周是落地验证的黄金窗口。趁记忆还热乎，选择一个规模可控、风险最低的集群，把Volcano接入进去，用一两个有小作业量的业务做验证。
前期可以不用上太复杂的策略，先体验核心能力：创建一个Queue，提交一个多Pod作业，把gang插件打开，感受一下作业整体调度的效果。然后把binpack打开，把另一个高优先级作业加进去，观察抢占和排队的行为是否符合预期。这个过程不追求一步到位，目的就是让团队里每个人对Volcano的实际运行方式有一个真实体感。
等小规模验证通过了，再逐步把更复杂的业务、更大的作业量、多队列配置引进来。不要试图一次性把所有功能全部上线，尤其是抢占和高优先级策略，一定要在业务侧有明确预期的情况下再开。调度器牵一发动全身，宁可慢一点，也要稳一点。
我在这个过程中最大的受，是调度器选型和集群业务模型的关系太紧密了。Volcano不是一把万能钥匙，但它提供了足够多的旋钮和杠杆，让你能够针对自己的业务把集群调到相对最优的状态。这也是我期待这次KubeCon + CloudNativeCon China 2026上Volcano相关内容的原因——工具本身我在用，但社区里那些从实战中长出来的经验，永远比任何宣传材料都值钱。