1 概述
Volcano是 CNCF 下首个也是唯一的基于Kubernetes的容器批量计算平台，主要用于高性能计算场景。Volcano是一个开源的 Kubernetes 批处理系统，专为高性能计算任务设计。
它提供了一种高效的方式来管理和调度资源密集型作业。比如：大数据处理和机器学习任务。
它提供了Kubernetes目前缺少的一套机制，这些机制通常是机器学习、大数据应用、科学计算、特效渲染等多种高性能工作负载所需的。
作为一个通用批处理平台，Volcano与几乎所有的主流计算框架无缝对接，如Spark 、TensorFlow 、PyTorch 、 Flink 、Argo 、MindSpore 、 PaddlePaddle，Ray等。
它还提供了包括异构设备调度，网络拓扑感知调度，多集群调度，在离线混部调度等多种调度能力。
Volcano的设计 理念建立在15年来多种系统和平台大规模运行各种高性能工作负载的使用经验之上，并结合来自开源社区的最佳思想和实践。
- 在批处理领域，任务通常需要大量计算资源，但这些资源在 Kubernetes 集群中可能是有限的或者分布不均。
Volcano 尝试通过一些高级调度功能来解决这些问题，尽可能确保资源被高效利用，同时最小化作业的等待时间。
这对于需要快速处理大量数据的场景尤其重要，如科学研究、金融建模或任何需要并行处理大量任务的应用。
Volcano的关键特性之一是它的gang调度机制。
这个机制允许同时调度一组相关任务，确保它们要么全部启动，要么都不启动。
这种方法对于那些需要多个任务协同工作的复杂作业来说至关重要，因为它避免了部分任务因资源不足而无法执行的情况。
- 举个例子：Kubernetes 原生的调度器只能实现一个 Pod 一个 Pod 的顺序调度，对于小规模在线服务而言，也基本够用。
不过当一个服务需要大量 Pod 一起启动才能正常运行时（比如一次模型训练任务需要用到100个 pods 时，如何保证这100个 pods 要么都成功调度，要么都不被调度呢？
这时候就需要 Volcano 提供的gang调度能力了。
由来
- 随着各种新兴高性能计算需求的持续增长，Job的调度和管理能力变得必要和复杂。下面罗列了一些共性需求：
- 调度算法的多样性
- 调度性能的高效性
- 无缝对接主流计算框架
- 对异构设备的支持
- Volcano正是针对这些需求应运而生的。
同时，Volcano继承了Kubernetes接口的设计风格和核心概念。
您可以在充分享受Volcano的高效性和便利性的同时不用改 变任何以前使用Kubernetes的习惯。
特性
统一调度
- 支持Kubernetes原生负载调度
- 支持使用VolcanoJob来进行PyTorch、TensorFlow、Spark、Flink、Ray等框架的一体化作业调度
- 将在线微服务和离线批处理作业统一调度，提升集群资源利用率
丰富的调度策略
- Gang Scheduling：确保作业的所有任务同时启动，适用于分布式训练、大数据等场景
- Binpack Scheduling：通过任务紧凑分配优化资源利用率
- Heterogeneous device scheduling：高效共享GPU异构资源，支持CUDA和MIG两种模式的GPU调度，支持NPU调度
- Proportion/Capacity Scheduling：基于队列配额进行资源的共享/抢占/回收
- NodeGroup Scheduling：支持节点分组亲和性调度，实现队列与节点组的绑定关系
- DRF Scheduling：支持多维度资源的公平调度
- SLA Scheduling：基于服务质量的调度保障
- Task-topology Scheduling：支持任务拓扑感知调度，优化通信密集型应用性能
- NUMA Aware Scheduling：支持NUMA架构的调度，优化任务在多核处理器上的资源分配，提升内存访问效率和计算性能
- …
得益于可扩展性的架构设计，Volcano支持用户自定义plugin和action以支持更多调度算法。
队列资源管理
- 支持多维度资源配额控制(CPU、内存、GPU等)
- 提供多层级队列结构和资源继承
- 支持队列间资源借用、回收与抢占
- 实现多租户资源隔离和优先级控制
异构设备的支持
Volcano提供了基于多种架构的计算资源的混合调度能力：
-
x86
-
ARM
-
鲲鹏
-
昇腾
-
GPU：支持多种
GPU虚拟化
技术，提供灵活的GPU资源管理
- 动态MIG支持：支持NVIDIA Multi-Instance GPU(MIG)，通过硬件级隔离将单个GPU分割为多个独立的GPU实例
- vCUDA虚拟化：通过软件层将物理GPU虚拟化为多个vGPU设备，实现资源共享和隔离
- 细粒度资源控制：为每个GPU实例提供独立的显存和算力分配
- 多容器共享：允许多个容器安全地共享同一个GPU资源，提升利用率
- 统一监控：提供对所有GPU实例的统一使用情况监控和指标收集
网络拓扑感知调度
- 支持基于网络拓扑的感知调度，充分考虑节点间的网络带宽特性。在AI场景中，针对分布式训练任务的通信密集型特点，拓扑感知调度能够有效优化数据传输，显著减少通信开销，从而提升模型训练速度和整体效率。
在离线混部
- 支持在线和离线业务混合部署，通过统一调度，动态资源超卖，CPU Burst，资源隔离等能力，提升资源利用率的同时保障在线业务QoS
多集群调度
- 支持作业跨集群调度，将VolcanoJob的能力扩展到多集群，实现更大规模的资源池管理
Volcano多集群调度仓库详见：volcano-global
重调度
- 支持动态重调度，优化集群负载分布，提升系统稳定性
Volcano重调度仓库详见：descheduler
监控与可观测性
- 完整的日志系统
- 丰富的监控指标
- 提供可视化的Dashboard，便于用户进行图形化界面操作
Volcano Dashboard详见：dashboard
Volcano指标详见: metrics
生态
Volcano已经成为业界批量计算场景中的事实标准，并被广泛应用于以下高性能计算框架中：
- Spark
- TensorFlow
- PyTorch
- Flink
- Argo
- Ray
- MindSpore
- PaddlePaddle
- OpenMPI
- Horovod
- mxnet
- Kubeflow
- Cromwell
此外，Volcano已被多个企业和组织广泛应用于AI和大数据领域。
它通过强大的资源管理能力、高效的Job管理机制，以及丰富的调度策略（如Gang调度、异构设备调度、拓扑感知调度等），有效满足了分布式训练、数据分析等任务的复杂需求。
同时，Volcano在提升调度性能的基础上，兼顾了任务调度的灵活性和可靠性，为企业打造高效的资源利用体系提供了有力支持。
2 工作原理与架构
架构概览
图:Volcano的应用场景
- Volcano与Kubernetes天然兼容，并为高性能计算而生。它遵循Kubernetes的设计理念和风格。
图:系统架构
Volcano: 由scheduler、controllermanager、admission和vcctl组成:
Scheduler: Volcano scheduler通过一系列的action和plugin调度Job，并为它找到一个最适合的节点。与Kubernetes default-scheduler相比，Volcano与众不同的 地方是它支持针对Job的多种调度算法。Controller Manager: Volcano controllermanager管理CRD资源的生命周期。它主要由
Queue ControllerManager、PodGroupControllerManager、VCJob ControllerManager构成。
Admission: Volcano admission负责对CRD API资源进行校验。Vcctl: Volcano vcctl是Volcano的命令行客户端工具。
Volcano 核心概念
先认识下 Volcano 的几个核心概念。
2.1 认识 Queue、PodGroup 和 VolcanoJob
Volcano引入了几个新概念：
- Queue
- Pod Group
- Volcano Job
这些都是 K8s 里的自定义资源，也就是我们能够通过
kubectl命令查到相应的资源对象，好比 Deployment、Service、Pod 这些。
- Queue
在 Volcano 中，Queue 用于管理和优先级排序任务。
它允许用户根据业务需求或优先级，将作业分组到不同的队列中。
这有助于更好地控制资源分配、资源隔离和调度优先级，确保高优先级的任务可以优先获取资源。
- Pod Group
一组相关的 Pod 集合。
这主要解决了 Kubernetes 原生调度器中单个Pod调度的限制。
通过将相关的 Pod 组织成 PodGroup，Volcano 能够更有效地处理那些需要多个 Pod 协同工作的复杂任务。
- Volcano Job
其是 Volcano 中的一个核心概念，它扩展了 Kubernetes 的 Job 资源。
VolcanoJob 不仅包括了 Kubernetes Job 的所有特性，还加入了对批处理作业的额外支持，使得 Volcano 能够更好地适应高性能和大规模计算任务的需求。
2.2. Queue、PodGroup 和 VolcanoJob 的关系
-
大致知道了 Volcano 中有 Queue、PodGroup 和 VolcanoJob 三种自定义资源后，我们接着具体看下这三种资源的作用、关系等。
-
首先，Queue 是一个 Pod Group 队列，Pod Group 是一组强关联的 Pod 集合。而
VolcanoJob则是一个K8s Job升级版，对应的下一级资源是 PodGroup。
换言之，就好比
ReplicaSet的下一级资源是 Pod 一样。
所以，VolcanoJob背后对应一个 K8s 里的自定义控制器（Operator模式），这个控制器会根据VolcanoJob的具体配置去创建相应的PodGroup出来。
而PodGroup最终会被当做一个整体被Volcano Scheduler调度。
在调度的过程中，Volcano还用到了Queue来实现 PodGroup 的排队、优先级控制等逻辑。
3. Volcano 调度框架概览
继续看 Volcano 调度逻辑的实现框架。
- 官方文档里有一张图，长这样：
- 第一眼看这张图会有点蒙，主要是如何理解 Action 和 Plugin 两个概念，以及具体的 actions 和 plugins 作用是啥。
简单来说，Volcano 调度过程中会执行一系列的动作，这些动作也就是 Action，主要是 enqueue、allocate、backfill 这些。
具体有哪些 actions，默认执行哪些 actions，后面我们到源码里去寻找。
然后每个具体的 Action 中执行什么算法逻辑，就取决于注册进去的 plugins。
换言之，actions 是基本固定的，合计6个（刚翻源码看到的，文档落后了），可选执行其中某几个；而 plugins 就有点多了（十几个），具体哪些 plugins 在哪个 Action 中被调用呢？咱接下来翻源码扒一扒。
Z FAQ for Vocalno
Q: flink on vocalno 与 stream park 中 flink on k8s 的关系?
- 要理清 Flink on Volcano 与 StreamPark 中 Flink on K8s 的关系，核心结论是：
二者是“互补而非替代”的关系，聚焦 Flink 部署在 K8s 生态中的不同层面，【可叠加使用】。
1. 明确两个概念的核心定义
A. StreamPark 中 Flink on K8s
-
StreamPark 是什么：开源的 Flink 一站式运维管理平台（原 FlinkX-Manager），核心作用是 “简化 Flink 任务的全生命周期管理”，而非替代 K8s 或 Flink 的调度层。
-
其 Flink on K8s 的核心能力：
封装 Flink 原生的 K8s 部署逻辑（Session/Application/Per-Job 模式），提供 UI 界面、配置化操作，帮用户完成：- Flink 集群/任务的创建、提交、启停、扩缩容；
- 配置管理（Flink 配置、K8s 资源请求/限制、依赖包管理）；
- 监控告警、日志查看、任务运维；
本质是 “Flink on K8s 的上层管理封装”，底层仍依赖 K8s 的调度能力。
B. Flink on Volcano
-
Volcano 是什么：Kubernetes 生态的 增强型调度器（CNCF 毕业项目），专为高性能计算（HPC）、AI 训练、流计算等“批流混合”“资源密集型”场景设计，弥补原生 K8s 调度器（kube-scheduler）在复杂调度场景的不足。
-
Flink on Volcano 的核心能力：
让 Flink 任务通过 Volcano 而非原生 K8s 调度器运行，解决 Flink 对 K8s 调度的核心诉求：- 作业级资源预留（避免任务因资源碎片无法启动）；
- gang 调度（保证 Flink JobManager + TaskManager 集群整体启动/销毁，避免部分组件缺失导致失败）；
- 优先级调度、队列管理、资源抢占（适合多租户共享集群场景）；
本质是 “Flink 在 K8s 上的调度层优化”，替代原生 K8s 调度器，让 Flink 运行更稳定、资源利用率更高。
2. 核心定位差异（关键区分点）
| 维度 | StreamPark 中 Flink on K8s | Flink on Volcano |
|---|---|---|
| 核心角色 | Flink 任务的“运维管理平台”（上层封装） | Flink 任务的“K8s 调度器”（底层调度） |
| 解决的问题 | 降低 Flink on K8s 的使用门槛，简化运维（无需手动写 YAML、调用 Flink CLI） | 解决原生 K8s 调度不适配 Flink 的问题（gang 调度、资源预留等） |
| 依赖关系 | 底层依赖 K8s 调度层（可是原生调度器，也可是 Volcano） | 依赖 K8s 集群，替代原生调度器，为 Flink 提供调度能力 |
| 交互层面 | 面向用户/运维人员（UI/API 操作） | 面向 K8s 集群（调度层，用户无感知） |
| 是否可独立使用 | 可独立使用（搭配原生 K8s 调度器运行 Flink） | 不可独立使用（需结合 Flink + K8s，需上层管理平台提交任务） |
3. 二者的关系：叠加使用，各司其职
- StreamPark 与 Volcano 并非“二选一”，而是 “上层管理 + 底层调度”的组合关系，完整链路如下：
用户操作（UI/API） → StreamPark（管理层） → Flink 任务定义 → K8s 资源请求 → Volcano（调度层） → 调度 TaskManager/JobManager 到 K8s 节点 → 任务运行
具体关系拆解：
-
StreamPark 负责“管”：用户通过 StreamPark 配置 Flink 任务的资源需求（CPU/内存）、并行度、依赖包、运行模式（Application/Session），StreamPark 会将这些配置转化为 K8s 可识别的资源对象（如 Deployment/Job、ConfigMap 等），并提交到 K8s 集群。
-
Volcano 负责“调”：当 K8s 集群启用 Volcano 作为调度器后，StreamPark 提交的 Flink 资源请求会被 Volcano 接管，Volcano 会根据 Flink 任务的 gang 调度需求、资源优先级、队列策略，将 TaskManager 和 JobManager 调度到合适的 K8s 节点，确保任务稳定启动和运行。
-
无冲突，可替换底层调度：
- 若不需要复杂调度，StreamPark 可直接搭配 原生 K8s 调度器 运行 Flink（适合简单场景）；
- 若需要 gang 调度、资源预留等高级能力，只需在 K8s 集群中部署 Volcano，StreamPark 无需修改，仅需在提交任务时配置 Volcano 相关调度参数（如队列、优先级），即可切换到底层调度器。
4. 实际使用场景对比
| 场景 | 推荐组合 | 原因 |
|---|---|---|
| 中小规模 Flink 集群，运维简单 | StreamPark + 原生 K8s 调度器 | 无需额外部署 Volcano，StreamPark 已满足运维需求 |
| 大规模批流混合集群，多租户共享 | StreamPark + Volcano + Flink on K8s | Volcano 解决资源碎片、gang 调度问题，StreamPark 简化多任务运维 |
| 对 Flink 任务稳定性要求高 | StreamPark + Volcano + Flink on K8s | Volcano 的资源预留、抢占能力避免任务因资源不足失败 |
| 纯命令行/脚本运维，无需 UI | Flink on Volcano（直接通过 Flink CLI 提交） | 无需 StreamPark，直接用 Flink 原生 K8s 提交方式搭配 Volcano |
总结
- 层级不同：StreamPark 是 Flink on K8s 的「上层运维管理平台」，Volcano 是 K8s 的「底层调度器」；
- 关系互补：二者可叠加使用，StreamPark 简化操作，Volcano 优化调度，共同解决 Flink 在 K8s 上的“易用性”和“稳定性”问题；
- 选择逻辑：是否需要 Volcano，取决于是否需要 gang 调度、资源预留等高级调度能力；是否需要 StreamPark，取决于是否需要 UI 化、配置化的运维管理。
Y 推荐文献
- Volcano
- https://volcano.sh/zh/docs
https://volcano.sh/zh/docs/architecture/
- Flink on Volcano
https://volcano.sh/zh/docs/flink_on_volcano/
Flink cluster的部署需要创建2个deploy、一个service和一个configmap，而调度策略采用volcano。
- flink-configuration-configmap.yaml
- jobmanager-service.yaml
- jobmanager-session-deployment.yaml
- taskmanager-session-deployment.yaml
- Volcano 原理、源码分析（一） - 博客园
)
