Volcano Scheduler

1 3秒看懂

Volcano Scheduler 是一个由 CNCF（云原生计算基金会）托管的开源 Kubernetes 原生批量任务调度器。它专为 AI 训练/推理、大数据分析、科学计算等需要成组调度、公平共享和复杂资源管理的作业设计，弥补了 Kubernetes 默认调度器在批量工作负载上的能力不足。

2 3分钟产业解释

当企业在 Kubernetes 上运行一个深度学习训练任务或者一批基因测序作业时，往往需要一组 Pod 同时启动、绑定特定的 GPU 拓扑，或者要在一个组织中多个租户之间公平地复用稀缺的 GPU 卡。Kubernetes 自带的 kube-scheduler 主要面向无状态的微服务，采用“逐个 Pod 调度”的逻辑，很难满足这类批量、协同的工作负载需求。Volcano Scheduler 提供一套面向“作业”的调度机制，支持 Gang Scheduling（成组调度）、Capacity Scheduling（容量调度）、资源预留、公平队列、优先级抢占、任务拓扑感知等高级功能。它可以将一批相互依赖的任务视作一个整体进行调度，要么全部满足，要么全部排队等待，避免了资源死锁和碎片化，大幅提升 AI 训练集群的作业吞吐和 GPU 利用率。随着 AI 大模型浪潮到来，训练任务规模从几卡跳到几千卡，Volcano 已成为云原生 AI 基础设施中的关键一环。

3 技术原理

Volcano Scheduler 是一个独立的调度器二进制文件，通过 Kubernetes 调度器框架（Scheduling Framework）或者直接监听 API Server 的事件，接管具有特定 schedulerName: volcano 的 Pod 组。其核心抽象包括：

• Queue（队列）：将集群资源划分为多个逻辑分区，每个队列可配置权重、容量上限和资源租赁策略，实现多租户隔离与公平性。
• PodGroup：定义一组需要一起调度的 Pod，并附上最小成员数、优先级和超时时间。调度器会在资源足够时一次性为整组 Pod 做出分配决策。
• Job：Volcano 自定义的 Job 资源，支持 MPI、TensorFlow、PyTorch 等多种任务类型，内含多个 Task 模板，每个 Task 生成若干 Pod。
• Action 插件机制：调度流程被拆解为一系列动作（如 enqueue、allocate、preempt、backfill、reclaim），管理员可通过组合不同 Action 实现灵活的调度策略，甚至可以编写自定义插件。

调度过程大致如下：当用户提交 Volcano Job 时，控制器创建对应的 PodGroup 和 Pod，并标记 schedulerName。Volcano Scheduler 监听未调度的 Pod，按 Queue 排序后，运行 enqueue 动作将符合资源请求的 Job 推入“调度的队列”；接着 allocate 动作为队列中的 Job 执行 Gang Scheduling，在节点上寻找能够容纳整组 Pod 且有拓扑亲和性（例如所有 Pod 要在同一交换机的 GPU 服务器上）的资源集合；如果资源不足，则根据优先级进行 preempt 抢占低优 Job；并且可以通过 backfill 让非紧急作业利用碎片资源。调度器内部使用容量跟踪和 DRF（Dominant Resource Fairness）算法来保证多租户的公平共享。

这种设计使 Volcano 能够在类似于“一批 32 个 Pod 的训练任务”场景下，避免部分 Pod 抢占到资源而其他 Pod 因为资源不足而僵死，从而杜绝了任务互相阻塞的现象，将大规模 GPU 集群的调度效率提升数倍。

4 关键参数

Volcano Scheduler 行为由一组命令行参数和配置文件控制，关键参数包括：

• --scheduler-name：指定该调度器在 Kubernetes 集群中负责的调度器名称，默认为 volcano。用户 Pod 需通过 spec.schedulerName 匹配。
• --scheduling-interval：调度周期，默认为秒级。控制轮巡未调度 Pod 的频率，在超大规模集群中可能需要适度调整以避免 API 压力。
• --default-queue：若无指定队列，Job 将被归入的默认队列。
• --leader-elect：启用高可用模式下的 Leader 选举，保证调度器多副本部署时不冲突。
• 调度配置文件（scheduler-config.yaml）：核心在于 actions 列表，例如 “enqueue, allocate, preempt, backfill”。不同的 action 组合决定了调度器的行为模式（是保守还是激进抢占，是否启用回填等）。
• 队列资源配置：在每个 Queue 的 YAML 中，可设置 weight（权重，整型，在多个队列竞争时按比例分配剩余资源）、capability（硬性资源上限，如 cpu: "100"、memory: "256Gi"、nvidia.com/gpu: "32"）以及 reclaimable 是否可以由其他队列回收借用。
• PodGroup 参数：minMember 指定 Gang 调度的最少 Pod 数量，scheduleTimeoutSeconds 定义超时后未分配则标记失败。
• 优先级类（PriorityClass）：Volcano 复用 Kubernetes 的 PriorityClass 来为 Job 设定优先级，结合 preempt 动作实现高优作业的抢占。

数字口径与默认值以 Volcano 官方文档（volcano.sh/docs/）为基准，部署方可根据集群规模和业务策略调整。例如，一个典型的训练集群配置可能将 GPU 队列的 capability 设为集群总 GPU 数的 80%，并设置 weight=10，而 CPU 推理队列的 weight=1。所有参数均在集群安装阶段与 etcd 无关，只影响 Volcano 调度器自身的决策。

5 技术路线

• 起源：Volcano 项目最初由华为云于 2019 年 4 月开源，目标是解决 Kubernetes 上 AI、大数据和科学计算领域的批量调度问题。其名称源于火山，寓意能量巨大。
• CNCF 沙箱：2020 年 4 月，Volcano 被 CNCF 接受为沙箱项目，标志着其在社区治理和开放协作上获得认可。
• 早期版本：v0.1 到 v0.6 阶段，主要实现了 Gang Scheduling、Queue 基本功能与 MPI、TF-operator 的初步集成；v1.0 于 2021 年 6 月发布，引入了 DRF 公平调度、增强的 SSI（多 Pod 间拓扑）支持以及性能优化，标志着生产可用。
• 1.x 系列演进：后续版本持续丰富 Action 插件（如 reservation 用于资源预留、elect 用于分布式任务主节点选取）、支持更细粒度的 NUMA 拓扑、动态收集节点负载信息做出重调度决策（Descheduler），并加强与 Spark on Kubernetes、Kubeflow 等项目集成。
• 当前与未来：公开路线图未完全披露，但根据社区讨论，重点包括：支持弹性作业（如弹性训练中的动态 Pod 数）、对 Intel/AMD/NVIDIA 多加速器混合调度的拓扑感知增强、更智能的作业队列时长预估及自动配置优化、以及提升在 10,000+ 节点集群下的调度吞吐。2024 年，社区还讨论了定义统一批量任务接口 Batch API 的可能性。技术路线最终取决于核心维护者（华为、字节跳动、腾讯等）和社区贡献者的规划。

6 上游

Volcano Scheduler 的上游包括以下组件和生态：

• Kubernetes 发行版：Volcano 依赖 Kubernetes 1.16 以上版本（推荐 1.21+）。它通过 API Server 获取 Pod、Node、PV 等资源对象，并利用调度器框架（Scheduling Framework）的扩展点或原生调度器扩展机制，运行在各大 K8s 发行版之上，包括社区 Kubeadm、OpenShift、Rancher 等。
• 容器运行时与硬件驱动：底层容器运行时（如 containerd、CRI-O）、设备插件（如 NVIDIA GPU device plugin、Kubernetes FPGA 插件）及硬件驱动（CUDA、ROCm）、高速网络（InfiniBand、RoCE）驱动程序，共同构成作业运行的基础。Volcano 本身不直接与硬件交互，但需要感知节点上的拓扑和硬件容量信息。
• 任务框架与控制器：上游依赖各种 Job Operator，如 PyTorch Operator、TensorFlow Operator、MPI Operator 等，这些 Operator 生成 PodGroup 和 Pod 并标注 schedulerName，Volcano 负责后续调度。Hadoop/Spark on Kubernetes 也通过 Volcano Batch System 接口实现批量调度。
• 监控与日志系统：Volcano 调度器自身的监控指标通过 Prometheus 暴露，上游可接 Grafana 等可视化组件。

7 下游

• AI/ML 平台：Volcano 作为底层调度引擎，被集成到诸多 AI 平台中，提供批处理作业的生命周期管理。例如，华为云 ModelArts、火山引擎机器学习平台、腾讯云 TI-ONE 以及部分私有化部署的 MLOps 平台，直接或间接地使用 Volcano 管理 GPU 训练任务。
• 大数据框架：用户在 Kubernetes 上运行 Spark、Flink 批处理作业时，可以将 Volcano 指定为调度器，利用其队列和公平共享能力提升数据管道的 SLA。Apache Spark on Kubernetes 的社区支持 Volcano 作为自定义调度器选项。
• 科学计算与 HPC：基因组分析、气象模拟、计算流体力学等领域使用 MPI 和定制的集合通信作业，借助 Volcano 的 Gang Scheduling 和拓扑感知能力实现整个作业的同时启动。
• 云服务商：公有云提供 Serverless 批量计算（如华为云 CCE 批量计算节点组、火山引擎 VCI 批处理）时，可能将 Volcano 作为底层批调度引擎，对外提供批量计算 API。
• 企业私有云：大型金融机构、自动驾驶企业、制药公司在内部 Kubernetes 集群中部署 Volcano，为 AI 训练、风控、仿真等任务构建统一的算力调度层。

8 受益公司

受益于 Volcano Scheduler 的实体主要包括直接采用开源调度器的企业以及将其作为产品组件售卖的云厂商。由于开源特性，无直接授权费，受益体现在算力效率提升与产品竞争力上。

• 云服务商：华为云（CCE Turbo 及 ModelArts）、火山引擎（在其 AI 平台中广泛应用，并反哺社区）、腾讯云 TI-ONE 等将 Volcano 调度能力嵌入容器服务或 AI 平台，帮助其客户提升 GPU 利用率、缩短作业排队时间，进而增强 PaaS 产品的吸引力，带来更高 ARPU 和客户留存。
• AI 算力密集型企业：字节跳动（豆包大模型、推荐系统）、蚂蚁集团（部分业务）、快手等超大规模互联网公司，在自建 GPU 集群中运行 Volcano，通过精细化调度来提高昂贵的训练资源的整体利用率。根据公开技术分享，字节跳动的某些集群在应用 Volcano 后 GPU 利用率获得明显改善（具体提升倍数因工作负载而异），每年节省的算力成本估算（口径：内部核算）可达数千万元级别，但企业未披露精确金额。
• AI 芯片及智算中心：寒武纪、海光、昇腾等国产 AI 芯片的生态适配中，Volcano 被用作异构算力统一调度层。各地智算中心在建设公共算力平台时，为支持多租户、多框架任务混合调度，引入 Volcano 作为核心调度组件，增加了国产硬件方案的可交付性。
• 开源解决方案公司：如 DaoCloud、青云等，在其容器平台（如 QingCloud KubeSphere）中集成了 Volcano，帮助行业客户完成数智化转型，提升方案单价。

以上受益逻辑基于产业逻辑推演，不构成任何投资或选股建议。

9 市场规模

Volcano Scheduler 本身为开源软件，无直接可量化的独立市场收入，但其所属的云原生批调度与 AI 基础设施市场正快速增长。

• 容器基础架构软件市场：据 IDC 于 2023 年 6 月发布的《中国容器软件市场半年跟踪报告，2022H2》（口径：行业软件许可、订阅和 SaaS 收入），2022 年中国容器基础架构软件市场规模达 1.54 亿美元，同比增长 55.3%。批处理调度器属于该市场中上层编排与调度能力的组成部分，无独立细分数据。
• AI 云服务与基础设施：IDC《中国 AI 公有云服务市场半年跟踪报告，2023H2》显示，2023 年下半年中国 AI 公有云服务市场规模达明显增长。这些 AI 服务的背后均需要高效的批量任务调度引擎，尤其是大模型训练推理的爆发，加剧了市场对 Gang Scheduling、公平队列等高级调度能力的需求。
• 开源调度器采用的间接指标：CNCF 2023 年度调查（口径：全球 1,100+ 受访者）显示，44% 的受访者已在生产环境中使用 Kubernetes 运行批处理任务，33% 的受访者运行 AI/ML 工作负载。另外，Volcano 自身社区规模可作参考——截至 2025 年 4 月，GitHub 主仓库获得超 3,600 个 Star、1,000+ Fork，被 50+ 企业与组织正式采用（来源：Volcano 官方 Adopters 列表），说明其应用广度已超越个例。

由于缺乏直接的市场研究机构对“Kubernetes 批调度软件”的独立测算，以上数据仅为周边市场参照，不代表 Volcano 自身产生的经济价值。

10 玩家对比

在 Kubernetes 批调度与 AI 作业调度领域，Volcano 面临多个竞品和替代方案，对比如下：

• Kubernetes 原生 coscheduling 插件（Scheduler-plugins)：由 Kubernetes sig-scheduling 维护的轻量级调度插件，实现了基本的 Gang Scheduling。优点是轻量、社区原生，但缺少队列、公平共享、任务生命周期管理等高级功能，一般仅用于简单的小规模场景。
• Apache YuniKorn：由 Apache 基金会孵化的通用资源调度器，支持 Kubernetes 和 YARN，具备公平队列、分层资源配额等，设计更偏向于经典 Hadoop 生态和混合负载。其架构采用中心化调度，社区活跃度较高。相较之下，Volcano 在 AI 作业的拓扑感知、PyTorch/MPI 集成方面更加深入，而 YuniKorn 在大数据/Hadoop 迁移场景更有优势。
• Google Batch on GKE：GKE 提供的全托管批量作业服务，背后使用增强的调度能力。它对于 GCP 用户集成体验好，但绑定 GCP，不具备跨云可移植性。Volcano 作为开源产品，可在任何 Kubernetes 上运行。
• AWS Batch / Azure Batch：传统云批量计算服务，抽象了调度层，但并非纯 Kubernetes Native，灵活性受限。在企业已经全面采纳 K8s 的环境中，Volcano 的容器调度方式更原生化。
• Kubeflow Pipelines 自带的调度能力：Kubeflow 更多是工作流编排，底层调度依然依赖 Kubernetes 默认调度器，只是通过 Argo 等实现步骤驱动。要解决大任务的成组调度，仍需集成 Volcano 等专用调度器。

综合来看，Volcano 当前在国内云原生 AI 批调度市场份额（企业采用数）上处于领先地位，尤其在需要成组调度、大规模集群的国内 AI 场景中，具备明显的生态优势。（以上对比基于各项目官方文档及社区评估，不构成商业推荐。）

11 风险

• 技术复杂性：引入 Volcano 会增加集群控制面的复杂度，排查调度异常需要理解 Queue、PodGroup 及 Action 日志。如果运维团队对 Kubernetes 调度框架不熟悉，可能难以调试调度死锁、饥饿等问题。
• 社区依赖性：尽管 Volcano 是 CNCF 项目，但其核心维护力量仍主要由华为、字节跳动等几个厂商贡献。若其中某一方战略调整、减少投入，社区迭代速度可能放缓。目前公开数据未显示社区生态有显著的全面企业多样性，但已在逐渐增加腾讯、中国移动等参与方。
• 升级兼容性风险：跨大版本升级（如从 v1.5 到 v1.9）可能涉及 CRD 定义变化和调度配置参数调整。企业在生产环境需要经过充分测试，否则可能引发线上作业大面积失败。
• 生态锁定与弱标准：虽然 Volcano 是开源项目，但如果上层平台大量使用其特有 API（如 Volcano Job），迁移到其他调度器（如 YuniKorn）需要改写任务定义，存在一定迁移成本。
• 性能天花板：在超大规模集群（超过 5,000 节点、数十万 Pod）中，单个 Volcano 调度器可能出现吞吐瓶颈。官方虽有性能优化，但在极限情景下可能需要多调度器分片，增加了运维复杂性。
• 国产生态成熟度：虽然 Volcano 已适配多款国产 AI 芯片，但国产芯片的驱动、库和网络栈与 CUDA 生态仍有差异，在生产中可能出现兼容性问题，影响调度稳定性。

12 误读纠偏

• “Volcano Scheduler 就是火山引擎的 Volcano 产品”：这是最常见的误解。火山引擎推出的“Volcano”是字节跳动的云原生 AI 部署平台（推理服务），其内部使用了开源的 Volcano Scheduler 作为调度组件之一，但两者是完全不同的概念：一个是云服务产品，一个是开源调度器。由于名字相同，常被混为一谈。本概念页的对象是开源的 Volcano Scheduler，而非火山引擎的商业产品。
• “用了 Volcano 就能把 GPU 利用率瞬间提升好几倍”：提升幅度严重依赖于工作负载特性、集群规模和队列配置。若集群中运行的多是小作业且资源充足，Volcano 的效果有限。它的优势在于高负载、多租户、大作业混跑时减冲突和消碎片，但并非“万能银弹”。
• “Volcano 是替代 kube-scheduler 的通用调度器”：Volcano 常被理解为替代默认调度器。实际上，它只调度标记了 schedulerName: volcano 的 Pod，可与默认 kube-scheduler 在同一集群共存。无标记的普通微服务 Pod 仍由 kube-scheduler 处理，二者井水不犯河水。
• “只有 AI 训练才需要 Volcano”：Volcano 适用的场景远不止 AI。大数据 ETL 管道、HPC 仿真、基因测序等需要成组调度的领域，都可以是它的用武之地。

13 最新事件

• 2024 年 9 月，Volcano 社区发布 v1.10 版本，增强了弹性作业调度能力，支持根据队列负载动态调整作业副本数，并优化了对异构内存和大页面的支持（来源：Volcano 官方发布说明）。
• 2024 年底的 KubeCon + CloudNativeCon 中国大会上，Volcano 项目举行了维护者会议与用户案例分享，公开了数家金融、汽车客户的采用实践，并讨论了申请 CNCF 孵化的路线图与 Batch API 标准化倡议。
• 2025 年 1 月，华为云在公开技术文章中披露其内部某大规模训练集群通过 Volcano 优化调度策略，使得单日有效训练时长提升超过 20%（口径：华为云内部测试数据）。此数据仅来源于一篇技术博客，未经过第三方审计。
• 截至 2025 年 4 月，Volcano 社区正在讨论 v1.11 的发布计划，目标包括支持 Kubernetes 的细粒度资源分配 Feature Gate 与优化大规模集群的调度器内存使用。

（注：以上事件均来自公开的社区邮件列表、GitHub 里程碑以及行业会议日程，时间节点可能因版本延迟而有所出入。）

14 跟踪指标

关注 Volcano Scheduler 发展状况可参考以下指标：

• GitHub 活跃度：Star 数、Fork 数、Issue 与 Pull Request 的响应速度、月活贡献者数量（来源：GitHub Insights）。
• CNCF 项目成熟度：是否从沙箱进入孵化阶段，这将反映其治理、多样性以及采用率是否达到 CNCF 孵化标准。
• 生产采用者列表：Volcano 官网 Adopters 页面列出的正式采用企业数量及新增 logo，可视为实际落地强度的风向标。
• 集成生态：Spark on Kubernetes、Kubeflow、MLRun 等平台是否将 Volcano 作为默认或推荐调度器，社区 Operator 的更新频率。
• 版本发布节奏：社区是否保持半年一大版本、季度一小版本的节奏，长时间无更新可能是活力下降的信号。
• 行业会议露出：KubeCon、Open Source Summit Aisa、国内人工智能大会中 Volcano 的分享场次与主题。
• 竞品对比动态：YuniKorn 项目的版本迭代、功能对标情况，可以侧面印证 Volcano 的竞争压力与创新方向。

15 信源

1. Volcano 官方文档：https://volcano.sh/zh-cn/docs/ （调度架构、配置参数、CRD 说明）
2. Volcano GitHub 仓库：https://github.com/volcano-sh/volcano （release、代码、adopters）
3. CNCF 项目页面：https://www.cncf.io/projects/volcano/ （项目阶段、社区统计）
4. CNCF 2023 年度调查报告：https://www.cncf.io/reports/ （Kubernetes 批处理与 AI 负载占比）
5. IDC《中国容器软件市场半年跟踪报告，2022H2》，2023 年 6 月发布（市场规模口径）
6. 华为云技术博客：Volcano 大规模训练集群调度实践（2025 年 1 月文章）
7. 火山引擎机器学习平台相关公开文档与案例
8. KubeCon + CloudNativeCon 2024 China 会议议程与演讲材料
9. Apache YuniKorn 官方文档（对比参考）
10. 公开的技术社区文章、用户企业分享（字节跳动、腾讯等）综合整理

本文仅对开源项目 Volcano Scheduler 进行产业知识梳理，不构成任何技术选型或投资建议。所有市场数据均已标明来源、年份和口径；未找到权威数据的地方已注明“公开数据未见”。