这几天业内群聊里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-shareDRF插件则解决“多作业公平共享”的问题它参考的是主导资源公平算法——看每个作业对某一种资源的“主导份额”然后尽量让所有作业的主导份额接近。这样不会出现一个作业把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、TFJobSpark的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环境里怎么调参才不会引起频繁驱逐”“多队列场景下单队列的资源上限满了之后借调资源的逻辑是怎样的”“如果我们的设备是自研NPUdevice plugin需要怎么适配才能被Volcano调度”“调度器本身的高可用方案有什么推荐实践”“在Kubernetes原生调度器已经支持了一些调度框架能力之后为什么还推荐用Volcano”这些问题没有任何一个是能在两分钟内回答完的但正因为如此你才能在和维护者交流的过程中获得真正的洞察。同时你也可以观察其他参会者在问什么那些往往是行业里最普遍的痛点对你自己的选型判断也很有参考意义。5.3 会后第一周做小范围灰度比任何总结都有用大会结束回到工位最忌讳的事情就是“看起来都懂了然后就搁置了”。我的个人经验是会后第一周是落地验证的黄金窗口。趁记忆还热乎选择一个规模可控、风险最低的集群把Volcano接入进去用一两个有小作业量的业务做验证。前期可以不用上太复杂的策略先体验核心能力创建一个Queue提交一个多Pod作业把gang插件打开感受一下作业整体调度的效果。然后把binpack打开把另一个高优先级作业加进去观察抢占和排队的行为是否符合预期。这个过程不追求一步到位目的就是让团队里每个人对Volcano的实际运行方式有一个真实体感。等小规模验证通过了再逐步把更复杂的业务、更大的作业量、多队列配置引进来。不要试图一次性把所有功能全部上线尤其是抢占和高优先级策略一定要在业务侧有明确预期的情况下再开。调度器牵一发动全身宁可慢一点也要稳一点。我在这个过程中最大的受是调度器选型和集群业务模型的关系太紧密了。Volcano不是一把万能钥匙但它提供了足够多的旋钮和杠杆让你能够针对自己的业务把集群调到相对最优的状态。这也是我期待这次KubeCon CloudNativeCon China 2026上Volcano相关内容的原因——工具本身我在用但社区里那些从实战中长出来的经验永远比任何宣传材料都值钱。