1. Volcano平台初识
在Kubernetes默认调度器面向在线服务设计的前提下，批处理作业的调度需求长期被低估。Volcano正是为弥补这一缺口而生的云原生批处理调度平台，它并非简单替换kube-scheduler，而是在Kubernetes之上构建了一套面向作业（Job）语义的调度与生命周期管理体系。理解Volcano，首先要理解它解决的核心矛盾：在线服务关注单Pod的即时可用性，而批处理作业关注一组Pod的整体完成效率与资源公平性。
核心价值：从“单Pod调度”到“作业级调度”
Kubernetes原生调度以Pod为最小单位，每个Pod独立参与调度决策。这在微服务场景下没有问题，但放到AI训练、大数据分析、基因测序等批处理场景中就会暴露三个典型问题：一是资源死锁，一个分布式训练任务需要8个Worker同时启动，但集群资源只够调度其中5个，剩余3个永远等不到资源，已调度的5个也白白占用资源；二是资源碎片，多个小作业各自占满不同节点的零散资源，导致大作业无法找到满足条件的节点组合；三是缺乏公平性，多个团队共享集群时，没有机制保证资源按队列或按份额分配。
Volcano通过引入PodGroup和Queue两个核心抽象来解决上述问题。PodGroup将一组需要协同调度的Pod绑定为一个调度单元，Queue则为不同团队或业务线提供资源配额与优先级边界。调度器在决策时，先判断PodGroup整体能否满足最小可用成员数（minMember），再决定是否执行调度，从而避免“部分启动、整体卡死”的尴尬局面。
典型应用场景
Volcano的适用场景集中在“多任务协同、资源密集、需要公平共享”的领域。最典型的是AI分布式训练，例如使用PyTorch或TensorFlow进行多机多卡训练时，AllReduce通信要求所有Worker同时在线，Volcano的gang scheduling（成组调度）能力恰好满足这一约束。其次是大数据批处理，如Spark on Kubernetes场景中，Driver和Executor需要作为一个整体提交，Volcano可以保证Executor全部就绪后再启动Driver，避免Driver空转等待。第三类是高性能计算（HPC），如气象模拟、分子动力学等MPI作业，对节点间通信拓扑和同时启动有严格要求。此外，在多团队共享集群的离线业务场景中，Volcano的队列权重和资源预留机制可以防止某个团队的大作业挤占其他团队的资源。
整体架构与关键组件
Volcano的架构可以理解为“一个调度器 + 一组控制器 + 一套准入与缓存机制”的组合。下图展示了其核心组件及其数据流向：
从图中可以看到，Volcano的调度链路是：用户提交Job后，Admission Webhook负责校验并确保Pod与PodGroup的绑定关系正确；Scheduler从Cache中获取集群快照，按照队列优先级和插件链执行调度决策；决策结果通过API Server写入etcd，最终由各节点的kubelet拉起容器。Controllers则负责Job、Queue、PodGroup等CRD资源的生命周期管理，例如当Job的所有Pod完成后更新Job状态为Completed。
关键组件职责速览
| 组件 | 核心职责 | 工程关注点 |
|---|---|---|
| Volcano Scheduler | 执行PodGroup级调度，运行gang、fair-share、binpack等插件 | 调度周期延迟、插件链顺序、缓存一致性 |
| Scheduler Cache | 维护节点、Pod、Queue的本地快照，减少API Server压力 | 缓存与etcd的同步延迟、快照一致性 |
| Admission Webhook | 校验Job合法性，自动注入PodGroup绑定信息 | Webhook超时、失败策略、证书轮换 |
| Controllers | 管理Job/Queue/PodGroup/Cron等CRD的状态流转 | Reconcile周期、状态机正确性、事件记录 |
| Queue CRD | 定义资源配额、权重、优先级边界 | weight与capability的配比、多队列抢占 |
| PodGroup CRD | 定义一组Pod的调度约束（minMember、优先级） | minMember设置、超时等待策略 |
与默认调度器的关系
Volcano Scheduler与kube-scheduler是并列关系，二者可以共存于同一集群，但同一时间只有一个调度器负责某类Pod的调度。通常的做法是：在线服务Pod继续由kube-scheduler调度，批处理Job的Pod通过schedulerName: volcano字段显式指定由Volcano调度。这种共存模式降低了迁移成本，也让集群可以同时承载在线和离线两类负载。需要注意的是，Volcano调度器启动后会接管所有schedulerName为volcano的Pod，如果配置不当，可能出现Pod长时间Pending的情况，此时应优先检查PodGroup是否创建成功、Queue是否存在以及minMember是否大于实际可调度Pod数。