本文分享自華為雲社區《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]

相關PRs:

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

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]

相關PRs：

https://github.com/volcano-sh/apis/pull/192

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]

相關PR：

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

由衷感謝社區開發者：@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工作負載。

相關PR:

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

設計文檔請參考: 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。

相關PR:

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

由衷感謝社區開發者：@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"標籤的節點上

相關PRs:

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

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]

相關PRs：

https://github.com/volcano-sh/volcano/pull/4391
https://github.com/volcano-sh/volcano/pull/4454
https://github.com/volcano-sh/volcano/pull/4512

由衷感謝社區開發者：@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/

相關PRs:

https://github.com/volcano-sh/volcano/pull/4409
https://github.com/volcano-sh/volcano/pull/4630

由衷感謝社區開發者：@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/

相關PRs：

https://github.com/volcano-sh/volcano/pull/4413
https://github.com/volcano-sh/volcano/pull/4630

由衷感謝社區開發者：@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"

相關PRs:

https://github.com/volcano-sh/volcano/pull/4583
https://github.com/volcano-sh/apis/pull/193

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

適配 Kubernetes 1.33

Volcano 版本緊隨 Kubernetes 社區版本。v1.13 支持最新的 Kubernetes v1.33 版本，並通過完整的 UT 和 E2E 測試用例確保功能和可靠性。

如需參與 Volcano 對新 Kubernetes 版本的適配工作，請參考：adapt-k8s-todo[14]。

相關PR：

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

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

致謝貢獻者

Volcano v1.13 版本包含了來自 36 位社區貢獻者的上百次代碼提交，在此對各位貢獻者表示由衷的感謝，貢獻者 GitHub ID：

相關鏈接

[1] Volcano v1.13版本:https://github.com/volcano-sh/volcano/releases/tag/v1.13.0

[2] Volcano:https://volcano.sh/en/

[3] LeaderWorkerSet (LWS):https://github.com/kubernetes-sigs/lws

[4] LWS v0.7:https://github.com/kubernetes-sigs/lws/releases/tag/v0.7.0

[5] LeaderWorkerSet With Gang:https://github.com/kubernetes-sigs/lws/tree/main/docs/examples/sample/gang-scheduling

[6] Cron Volcano Job Example:https://github.com/volcano-sh/volcano/blob/master/example/cronjob/cronjob.yaml

[7] HyperNode Auto Discovery:https://github.com/volcano-sh/volcano/blob/master/docs/user-guide/how_to_use_hypernode_auto_discovery.md

[8] Ray Design Doc:https://github.com/volcano-sh/volcano/blob/master/docs/design/distributed-framework-plugins.md

[9] Ray User Guide:https://github.com/volcano-sh/volcano/blob/master/docs/user-guide/how_to_use_ray_plugin.md

[10] NodeGroup Design:https://github.com/volcano-sh/volcano/blob/master/docs/design/node-group.md

[11] NodeGroup User Guide:https://github.com/volcano-sh/volcano/blob/master/docs/user-guide/how_to_use_nodegroup_plugin.md

[12] ResourceStrategyFit:https://github.com/volcano-sh/volcano/blob/master/docs/design/resource-strategy-fit-scheduling.md

[13] how to use resource strategy fit plugin:https://github.com/volcano-sh/volcano/blob/master/docs/user-guide/how_to_use_resource_strategy_fit_plugin.md

[14] adapt-k8s-todo:https://github.com/volcano-sh/volcano/blob/master/docs/design/adapt-k8s-todo.md

點擊關注，第一時間瞭解華為雲新鮮技術~

huaweiyun Blog

@huaweiyun

Tags

前端 (1158)

angular (73)

雲計算 (56)

敏捷開發 (15)

AI綜合 (12)

Stories

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

大模型推理場景支持 LeaderWorkerSet

新增 Cron Volcano Job

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

原生支持 Ray 框架

新增 HCCL 插件支持

增強 NodeGroup 功能

新增 ResourceStrategyFit 插件

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

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

實現混部與 OS 解耦

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

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

適配 Kubernetes 1.33

致謝貢獻者

Add a new Comments