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 進行產業知識梳理，不構成任何技術選型或投資建議。所有市場資料均已標明來源、年份和口徑；未找到權威資料的地方已註明“公開資料未見”。