Volcano v1.13 重磅发布！大模型训练与推理等调度能力全面增强

关注

原创 2025-10-17 16:50:38 2.1k 阅读 AI 写同款· GEO 优化 ›

本文分享自华为云社区《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]

支持基于 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]

原生支持 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工作负载。

新增 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。

增强 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]

实现混部与 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/

将网络拓扑感知调度能力扩展至 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"

由衷感谢社区开发者：@zhifei92 对该特性的贡献！