Volcano v1.13 重磅發布！大模型訓練與推理等調度能力全面增強

本文分享自華為云社區《Volcano v1.13 重磅發布！大模型訓練與推理等調度能力全面增強》，作者：云容器大未來。

北京時間2025年9月29日，Volcano v1.13 版本[1]正式發布。本次更新在多方面進行了功能增強，為用戶提供更完善的云原生批量計算解決方案。

新版本主要亮點包括：新增對大模型推理LWS的支持；新增定時任務管理能力；提供更靈活的網絡拓撲發現機制，并增強對主流AI計算框架的兼容性。同時在混部架構上實現了重要改進，提升了在不同環境中的部署靈活性。這些增強功能共同提升了Volcano[2]在復雜工作負載管理中的實用性和易用性，旨在打造更高效、更穩定的大規模計算平臺，為AI時代的基礎設施提供關鍵調度支撐。

大模型推理場景支持 LeaderWorkerSet

LeaderWorkerSet (LWS)[3] 是一個用于在 Kubernetes 上部署一組 Pod 的 API。它主要用于解決 AI/ML 推理工作負載中的多主機推理，尤其是需要將大型語言模型（LLM）分片并跨多個節點上的多個設備運行的場景。

Volcano自開源以來，積極與上下游生態進行集成，構建了完善的AI、大數據等批量計算社區生態，LWS在 v0.7[4]的版本中，原生集成了Volcano的AI調度能力，配合Volcano的新版本，用戶在使用LWS時，可自動創建PodGroup，由Volcano進行Pod的調度與資源管理，從而實現了大模型推理場景下的Gang調度等高階能力。

展望未來，Volcano 將繼續擴展其生態系統集成能力，為更多致力于在 Kubernetes 上實現分布式推理的項目提供強大的調度和資源管理支持。

使用文檔請參考：LeaderWorkerSet With Gang[5]

https://github.com/kubernetes-sigs/lws/pull/498

由衷感謝社區開發者：@JesseStutler 對該特性的貢獻！

新增 Cron Volcano Job

該版本引入了對 Cron Volcano Job 的支持，用戶可以像使用原生 Kubernetes CronJob 一樣，按預定的時間計劃（schedule）來周期性地創建和運行 Volcano Job，以實現周期性運行AI、大數據等批量計算任務。詳細功能如下：

定時調度：通過標準的 Cron 表達式（spec.schedule）定義作業的執行周期。
時區支持：支持在 spec.timeZone 中設置時區，以確保作業在預期的本地時間執行。
并發策略：通過 spec.concurrencyPolicy 控制并發行為：AllowConcurrent：允許并發運行多個作業（默認）。ForbidConcurrent：如果前一個作業尚未完成，則跳過本次調度。ReplaceConcurrent：如果前一個作業仍在運行，則終止它并啟動新的作業。

歷史記錄管理：可配置保留成功（successfulJobsHistoryLimit）和失敗（failedJobsHistoryLimit）的作業歷史記錄數量，自動清理舊的作業。

錯過調度處理：通過 startingDeadlineSeconds 字段，可以容忍一定時間內的調度延遲，超時則視為錯過執行。

狀態追蹤：CronJob 的狀態（status）會追蹤當前活躍的作業、上一次調度時間以及上一次成功完成的時間，便于監控和管理。

使用例子請參考：Cron Volcano Job Example[6]

https://github.com/volcano-sh/volcano/pull/4560

由衷感謝社區開發者：@GoingCharlie, @hwdef, @Monokaix 對該特性的貢獻！

支持基于 Label 的 HyperNode 自動發現機制

Volcano 在 v1.12 版本中正式推出了網絡拓撲感知調度能力，并率先實現了基于 InfiniBand (IB) 網絡的 UFM 自動發現機制。然而，對于不支持 IB 網絡或采用其他網絡架構的硬件集群（如以太網），手動維護網絡拓撲結構依然繁瑣。

為解決這一問題，新版本引入了基于節點標簽（Label）的 HyperNode 自動發現機制。該功能為用戶提供了一種通用且靈活的方式來描述網絡拓撲，將復雜的拓撲管理工作轉變為簡單的節點標簽管理。

該機制允許用戶在 volcano-controller-configmap 中定義拓撲層級與節點標簽的對應關系。Volcano 控制器會周期性地掃描集群中的所有節點，并根據其標簽自動完成以下工作：

自動構建拓撲：根據節點上的一組標簽，從上至下（例如：機架 -> 交換機 -> 節點）自動構建出多層 HyperNode 拓撲結構。

動態維護：當節點的標簽發生變化，或節點被添加、移除時，控制器會自動更新 HyperNode 的成員和結構，確保拓撲信息始終與集群狀態保持一致。

支持多種拓撲類型：允許用戶同時定義多種獨立的網絡拓撲，以適應不同的硬件集群（如 GPU 集群、NPU 集群等）或不同的網絡分區。

配置示例：

# volcano-controller-configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: volcano-controller-configmap
  namespace: volcano-system
data:
  volcano-controller.conf: |
    networkTopologyDiscovery:
      - source: label
        enabled: true
        interval: 10m # 發現周期
        config:
          networkTopologyTypes:
            # 定義一個名為 topology-A 的拓撲類型
            topology-A:
              # 定義拓撲層級，順序從上到下
              - nodeLabel: "volcano.sh/hypercluster"# 頂層 HyperNode
              - nodeLabel: "volcano.sh/hypernode"   # 中間層 HyperNode
              - nodeLabel: "kubernetes.io/hostname"# 底層物理節點

通過在 Volcano 控制器的 ConfigMap 中添加 label 源即可啟用此功能。以下配置定義了一個名為 topology-A 的三層拓撲結構：

頂層 (Tier 2) ：由 volcano.sh/hypercluster 標簽定義。

中間層 (Tier 1) ：由 volcano.sh/hypernode 標簽定義。

底層：物理節點，由 Kubernetes 內置的 kubernetes.io/hostname 標簽標識。

當一個節點被打上如下標簽時，它將被自動識別并歸入 cluster-s4 -> node-group-s0 的拓撲路徑下：

# 節點 node-0 的標簽
labels:
  kubernetes.io/hostname: node-0
  volcano.sh/hypernode: node-group-s0
  volcano.sh/hypercluster: cluster-s4

基于label的網絡拓撲自動發現功能具有出色的通用性與靈活性，不依賴于特定的網絡硬件（如 IB），因此適用于各類異構集群，并允許用戶通過標簽靈活定義任意深度的層級結構。它將復雜的拓撲維護工作轉變為簡單的節點標簽管理，實現了自動化，從而顯著降低運維成本和出錯風險。此外，該機制能夠動態適應集群節點和標簽的變化，無需人工干預即可實時保持拓撲信息的準確性。

使用文檔請參考：HyperNode Auto Discovery[7]

由衷感謝社區開發者：@zhaoqi612 對該特性的貢獻！

原生支持 Ray 框架

Ray是一個開源的統一分布式計算框架，其核心目標是簡化從單機到大規模集群的并行計算，特別適合擴展Python和AI應用。為了在Kubernetes上管理和運行Ray，社區提供了KubeRay——一個專為Kubernetes設計的Operator，它充當了Kubernetes和Ray框架之間的橋梁，極大地簡化了Ray集群和作業的部署與管理。

一直以來，在Kubernetes上運行Ray工作負載主要依賴于KubeRay Operator，同時Kuberay在v0.4.0 (2022年release) 版本已經集成了Volcano來進行Ray Cluster的調度和資源管理，以解決分布式訓練場景的資源死鎖等問題。現在，通過新版本的Volcano，用戶可以直接通過原生Volcano Job來創建和管理Ray集群，并提交計算任務。這為Ray用戶提供了另一種使用方案，可以更直接地使用Volcano的Gang Scheduling、隊列管理與公平調度、作業生命周期管理等能力來運行Ray工作負載。

設計文檔請參考: Ray Design Doc[8]

使用文檔請參考: Ray User Guide[9]

由衷感謝社區開發者：@Wonki4 對該特性的貢獻！

新增 HCCL 插件支持

新版本在Volcano Job中增加了分布式AI訓練場景需要的HCCL Rank 插件（hcclrank），用于在分布式任務中自動為 Pod 分配 HCCL Rank。具體包括：

新增 Volcano Job的hcclrank 插件實現，支持通過任務類型（master/worker）和索引自動計算并注入 HCCL Rank 到 Pod 注解。

插件支持自定義 master/worker 任務名，用戶可以指定分布式任務的master/worker角色。

該功能提升了 Volcano 在華為昇騰等 HCCL 通信場景下的原生支持，方便用戶在 AI 訓練任務中自動管理和分配 Rank。

由衷感謝社區開發者：@kingeasternsun 對該特性的貢獻！

增強 NodeGroup 功能

在層級隊列結構中，為每個子隊列重復配置與其父隊列相同的節點組親和性（nodeGroupAffinity）會導致配置冗余且難以維護。

為解決此問題，Nodegroup 插件新增了對層級隊列親和性的繼承支持。啟用后，調度器將遵循以下規則解析隊列的有效親和性：

優先自身配置：若隊列已定義 spec.affinity，則直接使用該配置。
向上繼承：若隊列未定義 spec.affinity，則沿其父級向上查找，并繼承最近的祖先隊列所定義的親和性配置。
覆蓋能力：子隊列可通過定義自身的 spec.affinity 來覆蓋繼承的配置，保證了靈活性。

此功能允許管理員在父隊列（如部門級別）設置統一的節點組親和性，其下的所有子隊列（如團隊級別）將自動繼承該設置，從而簡化了管理。

同時對于未設置NodeAffinity的隊列，用戶可以在插件配置中設置"strict"參數來決定調度行為。當 strict 為 true（默認值）時，這些隊列的任務將無法被調度到任何節點上。當 strict 設置為 false 時，這些任務則被允許調度到未設置 "volcano.sh/nodegroup-name" 標簽的普通節點上。

在調度配置文件的 nodegroup 插件參數中，設置 enableHierarchy: true可開啟層級隊列模式，設置strict為false可設置non-strict模式，示例配置如下：

actions: "allocate, backfill, preempt, reclaim"
tiers:
- plugins:
  - name: nodegroup
    enableHierarchy: true# 啟用層級隊列
    arguments:
      strict: false# 設置為non-strict模式，隊列內任務可以被調度到不包含"volcano.sh/nodegroup-name"標簽的節點上

https://github.com/volcano-sh/volcano/pull/4602

NodeGroup設計文檔請參考：NodeGroup Design[10]

NodeGroup使用文檔請參考: NodeGroup User Guide[11]

由衷感謝社區開發者：@JesseStutler , @wuyueandrew 對該特性的貢獻！

新增 ResourceStrategyFit 插件

在 Kubernetes 原生的 noderesources 調度策略中，只能對所有資源應用單一的聚合（MostAllocated）或分散（LeastAllocated）策略。這在復雜的異構計算環境（如 AI/ML 集群）中存在局限性。為了滿足差異化調度需求，Volcano 增強提出了 ResourceStrategyFit 插件，以應對更加復雜的場景。

該插件現在集成了兩大核心功能：按資源類型配置獨立策略以及稀缺資源規避（SRA）。

▍按資源類型的獨立打分策略

此功能允許用戶為不同的資源（如 cpu, memory, nvidia.com/gpu）分別指定 MostAllocated（聚合）或 LeastAllocated（分散）策略，并為其分配不同權重。調度器會根據每個資源的獨立配置精細化計算節點得分。

為了簡化對同一系列資源（如來自同一供應商的不同型號 GPU）的管理，該功能還支持資源名稱的后綴通配符（*）匹配。

語法規則：僅支持后綴通配符，例如 nvidia.com/gpu/*。諸如 vendor./gpu 等模式將被視為無效。

匹配優先級：采用“最長前綴匹配”原則。精確匹配的優先級最高；當沒有精確匹配時，將選擇前綴最長的通配符模式。

配置示例：以下配置為特定型號的 V100 GPU 設置了高優先級的聚合策略，為所有其他 NVIDIA GPU 設置了通用的聚合策略，同時為 CPU 資源配置了分散策略。

actions: "enqueue, allocate, backfill, reclaim, preempt"
tiers:
- plugins:
  - name: resource-strategy-fit
    arguments:
      resourceStrategyFitWeight: 10
      resources:
        # 精確匹配，最高優先級
        nvidia.com/gpu-v100:
          type: MostAllocated
          weight: 3
        # 通配符匹配，適用于其他所有 NVIDIA GPU
        nvidia.com/gpu/*:
          type: MostAllocated
          weight: 2
        # 精確匹配，用于 CPU 資源
        cpu:
          type: LeastAllocated
           weight: 1

同時ResourceStrategyFit 插件也支持設置Pod粒度的資源打分策略。主要通過以下兩個注解進行設置：

volcano.sh/resource-strategy-scoring-type: 指定該 Pod 的資源調度策略，可選值為 "LeastAllocated"（優先調度到資源使用率最低的節點）或 "MostAllocated"（優先調度到資源使用率最高的節點）。

volcano.sh/resource-strategy-weight: 以 JSON 格式為不同的資源（如 CPU、內存、GPU 等）設置自定義的調度權重，以影響最終的節點評分。

以下示例展示了如何為一個 Volcano Job 配置 Pod 粒度的資源調度策略：

apiVersion: batch.volcano.sh/v1alpha1
kind: Job
metadata:
  name: resource-strategy-job
spec:
  minAvailable: 2
  schedulerName: volcano
  tasks:
  - replicas: 2
    name: worker
    template:
      metadata:
        annotations:
          # 為該任務的 Pod 設置調度策略為 LeastAllocated
          volcano.sh/resource-strategy-scoring-type: "LeastAllocated"
          # 為 CPU 和內存資源設置不同的調度權重
          volcano.sh/resource-strategy-weight: '{"cpu": 2, "memory": 1}'
      spec:
        containers:
        - name: worker
          image: my-worker:latest
          resources:
            requests:
              cpu: "2"
              memory: "4Gi"
            limits:
              cpu: "2"
              memory: "4Gi"
        restartPolicy: Never

在這個例子中，worker 任務下的所有 Pod 在調度時將遵循 LeastAllocated 策略。在計算節點分數時，CPU 的權重是 2，內存的權重是 1。這意味著調度器會更傾向于將 Pod 調度到 CPU 和內存空閑資源（根據權重加權后）更多的節點上。

▍稀缺資源規避（Scarce Resource Avoidance, SRA）

SRA 是一項“軟”策略，旨在提高昂貴或稀缺資源（如 GPU）的整體利用率。它通過影響節點評分，引導那些不需要特定稀缺資源的普通任務（如純 CPU 任務）盡量避開包含這些資源的節點。這樣可以將稀缺資源節點“預留”給真正需要它們的任務，從而減少資源競爭和任務等待時間。

工作機制：

1. 用戶在配置中定義一組“稀缺資源”（如 nvidia.com/gpu）。

2. 當調度一個不請求任何已定義稀缺資源的 Pod 時，SRA 策略會生效。

3. 調度器會降低那些擁有這些稀缺資源的節點的得分。節點上存在的稀缺資源種類越多，其得分就越低。

4. 對于那些請求了稀缺資源的 Pod，SRA 策略不會對其調度決策產生負面影響。

配置示例：

以下配置將 nvidia.com/gpu 定義為稀缺資源。當調度純 CPU 任務時，擁有 GPU 的節點得分會降低，從而使任務更傾向于被調度到沒有 GPU 的節點上。

actions: "enqueue, allocate, backfill, reclaim, preempt"
tiers:
- plugins:
  - name: resource-strategy-fit
    arguments:
      # ... resourceStrategyFit 的聚合/分散策略配置 ...
      resources:
        nvidia.com/gpu:
          type: MostAllocated
          weight: 2
        cpu:
          type: LeastAllocated
          weight: 1
      # SRA 策略配置
      sra:
        enable: true
        resources: "nvidia.com/gpu"# 定義稀缺資源列表，逗號分隔
        weight: 10 # SRA 策略在總分中的權重
        resourceWeight:
          nvidia.com/gpu: 1 # 定義 nvidia.com/gpu 為稀缺資源及其權重

通過將 ResourceStrategyFit 的聚合/分散策略與 SRA 的規避策略相結合，用戶可以實現更精細、更高效的異構資源調度。

關于ResourceStrategyFit設計和使用文檔，請參考：ResourceStrategyFit[12]，how to use resource strategy fit plugin[13]

由衷感謝社區開發者：@LY-today, @XbaoWu, @ditingdapeng, @kingeasternsun對該特性的貢獻！

實現混部與 OS 解耦

Volcano 混部能力分為應用態和內核態兩部分，應用態混部提供在離線統一調度、動態資源超賣、節點壓力驅逐等能力，內核態混部分為內核層面的CPU/Memory/Network等資源的QoS保障，內核態混部能力通常需要特性OS支持（如OpenEuler等）。在新版本中，Volcano將混部能力與OS進行了解耦，對于使用了不支持混部能力的OS的用戶來講，可以選擇使用Volcano應用態的混部能力，來達到在離線任務統一調度、動態資源超賣、高優任務保障等能力。

具體使用方式如下，在安裝Volcano agent時指定--supported-features參數：

helm install volcano . --create-namespace -n volcano-system --set custom.colocation_enable=true --set"custom.agent_supported_features=OverSubscription\,Eviction\,Resources"

混部相關文檔請參考：https://volcano.sh/en/docs/colocation/

由衷感謝社區開發者：@ShuhanYan, @Monokaix 對該特性的貢獻！

支持自定義混部超賣資源名稱

Vocano混部Agent新增參數 --extend-resource-cpu-name 和 --extend-resource-memory-name，允許用戶自定義超賣資源名稱，支持自定義設置 CPU 和內存資源的名稱（默認分別為 kubernetes.io/batch-cpu 和 kubernetes.io/batch-memory）。提升了超賣資源名稱設置的靈活性。

具體使用方式如下，在安裝Volcano時指定--extend-resource-cpu-name和--extend-resource-memory-name參數：

helm install volcano . --create-namespace -n volcano-system --set custom.colocation_enable=true --set custom.agent_extend_resource_cpu_name=example.com/cpu --set custom.agent_extend_resource_memory_name=example.com/gpu

混部相關文檔請參考：https://volcano.sh/en/docs/colocation/

由衷感謝社區開發者：@ShuhanYan, @Monokaix 對該特性的貢獻！

將網絡拓撲感知調度能力擴展至 Kubernetes 標準工作負載

在新版本中，Volcano 的網絡拓撲感知調度能力不再局限于 Volcano Job。現在，也可以為 Kubernetes 的標準工作負載（如 Deployment、StatefulSet 等）配置網絡拓撲約束。

該功能通過 Pod 模板中的注解（Annotation）實現。當為 Deployment 或 StatefulSet 的 Pod 模板添加網絡拓撲相關的注解后，Volcano 的 podgroup-controller 會自動為這些 Pod 創建一個PodGroup，并將注解中定義的網絡拓撲約束繼承到 PodGroup 的規約（Spec）中，從而在調度時應用相應的網絡親和性策略。

可以通過以下兩個注解來配置網絡拓撲感知調度：

Deployment 配置示例

以下示例展示了如何為一個 Deployment 配置網絡拓撲感知調度。調度器將把該 Deployment 的 Pod 調度到網絡層級不超過 2 的節點上：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: network-aware-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
      annotations:
        # 設置網絡拓撲為硬約束
        topology.volcano.sh/network-topology-mode: "hard"
        # 設置允許調度的最高網絡層級為 2
        topology.volcano.sh/network-topology-highest-tier: "2"
    spec:
      # 必須指定調度器為 volcano
      schedulerName: volcano
      containers:
      - name: main-container
        image: nginx:latest
        resources:
          requests:
            cpu: "1"
            memory: "1Gi"
          limits:
            cpu: "1"
            memory: "1Gi"