Volcano on Volcano

Volcano社区发布Kthena子项目: 重新定义大模型智能推理

Mon, 29 Dec 2025 00:00:00 +0000

今天，我们激动地向全球开发者和 MLOps 工程师宣布，Volcano 社区迎来了一个新的子项目 Kthena！Kthena 是一个专为 Kubernetes 设计的、云原生、高性能的 LLM 推理路由和编排、调度系统。它旨在解决在生产环境中大规模编排、部署和服务 LLM 所面临的核心挑战，通过其独特的超节点拓扑感知的亲和性调度，KV Cache 感知的流量调度、Prefill/Decode 分离路由等高级功能，显著提升 GPU/NPU 资源利用率和吞吐，降低推理延迟，并赋予企业前所未有的灵活性和控制力。作为 Volcano 的子项目，Kthena将致力于帮助 Volcano 扩展除 AI 训练之外的边界，打造训推一体的完整解决方案。

LLM 服务化的“最后一公里”困境

大语言模型（LLM）正在以前所未有的速度重塑各行各业，但将其高效、经济地部署在生产环境中，特别是基于 Kubernetes 的云原生平台上，仍然困难重重。开发者们普遍面临以下挑战：
1. 资源利用率低：LLM 推理，尤其是其独特的 KV Cache 机制，对 GPU、NPU 显存的占用是动态且巨大的。传统的负载均衡一般采用Round-Robin算法，无法感知这种负载特性，导致 GPU、NPU 资源闲置与请求排队并存，成本高昂。
2. 延迟与吞吐量难以兼顾：LLM 推理分为“Prefill”（处理输入提示）和“Decode”（生成 Token）两个阶段，前者是计算密集型，后者是访存密集型。将两者混合调度，常常导致无法针对性优化，影响整体服务的响应速度和吞吐能力。因此PD分离的部署已经成为主流，但如何高效路由和调度，仍是一个难题。
3. 多租户与多模型管理复杂：在企业环境中，通常需要同时提供多个不同模型、不同版本或经过 LoRA 微调的模型。如何实现请求的公平调度、优先级管理以及动态路由，是一个复杂的工程难题，业界甚至有些方案将AI网关与大模型一一对应。
4. 缺乏K8s原生集成：许多现有的解决方案要么是外部系统，与 Kubernetes 生态割裂；要么过于复杂，无法满足生产级所需的简单易用性和灵活运维。

Kthena：云原生 LLM 推理的智能大脑

为了攻克上述难题，Kthena 应运而生。它并非要取代现有的 LLM 服务框架（如 vLLM, sgLang），而是作为它们上层的智能“交通枢纽”和“调度中心”，深度集成于 Kubernetes 之中。

Kthena 的核心由两大组件构成：

1）Kthena Router：一个独立、高性能面向多模型的router，负责接收所有推理请求，并根据 ModelRoute 规则，智能地将请求分发到后端的 ModelServer。

2）Kthena Controller Manager：Kubernetes 控制平面的控制器，它主要包含多种控制器，负责 LLM 工作负载的编排与生命周期管理。它持续调谐并联动多类 CRD（如 ModelBooster、ModelServing、AutoScalingPolicy/AutoScalingPolicyBinding、以及 ModelRoute/ModelServer），将声明式API转化为运行时资源：ModelServing 控制器编排 ServingGroup 与 Prefill/Decode 角色分组；支持网络拓扑亲和调度和Gang调度、滚动升级与故障恢复；基于 AutoScalingPolicy 实现弹性扩缩容。

这种架构使得 Kthena 成为连接用户请求与 LLM 模型的高度可编程的桥梁。

核心特性与优势

Kthena 的强大之处在于其专为 LLM 推理场景设计的核心功能：

1) 生产级推理编排（ModelServing）

LLM工作负载三层架构设计：ModelServing -> ServingGroup -> Role，一个API，支持LLM原生部署、PD分离部署，乃至大EP部署等多种部署形态，简化管理多LWS的负担。例如对于PD分离的大规模部署，可用一个ModelServing表示，根据负载的大小每个ModelServing可以包含任意数目的 ServingGroup（xPyD 分组），每个ServingGroup包含多个角色（Prefill Decode，他们通常部署在同一个超节点内以提升推理性能），相同的角色可以等价为一个LeaderWorkerSet，支持TP/PP/EP等多节推理并行计算。
原生支持Prefill-Decode分离部署：将计算密集型的 Prefill 实例调度到配备高性能计算卡的节点组，而将访存密集型的 Decode 实例调度到配备高带宽显存的节点组，实现资源的最佳匹配和极致的端到端延迟优化。另可以独立伸缩，动态调整Prefill-Decode的比例，更灵活的应对各种复杂的业务场景（如长短句混合、实时推理等）。
多并行范式支持：TP/PP/DP/EP 等并行模式灵活配置，最大化提升资源利用率和SLO
内置拓扑感知、Gang 调度支持：Gang调度确保ServingGroup/Role“成组原子化”落地，避免资源浪费；拓扑感知调度通过将Role内的一组Pod调度到网络拓扑更优的节点，提升并行计算的数据传输时延。

2) 开箱即用的模型上线（ModelBooster）

针对主流的大模型，提供包括PD分离在内的多种部署范式模板，自动生成ModelRoute/ModelServer/ModelServing/Autoscaling等路由策略和生命周期管理资源
覆盖通用的部署场景，至于更灵活的编排可通过ModelServing进行细粒度的控制

3) 智能、模型感知的路由（Kthena Router）

多模型路由：兼容OpenAI API，根据请求头或Body体内容，将流量调度到不同的基础模型。
插件化调度算法：提供最少请求、最小时延、KV Cache 感知、Prefix Cache 感知、LoRA 亲和、GPU 利用率感知、公平调度等多种负载均衡算法，满足用户不同业务场景和部署形态的需求
LoRA 模型热插拔无中断：感知推理引擎加载的LoRA 适配器，提供无中断的插拔和路由能力
丰富的流量治理策略：基于权重的模型路由，金丝雀发布、Token级流控、故障转移
All-in-one实现架构，无需部署Envoy Gateway，原生支持PD分离的流量调度，将多层路由合并成一层，易于维护

4) 成本驱动的自动扩缩容（Autoscaler）

同构伸缩：支持稳定、突发双模式，按业务指标（CPU/GPU/内存/自定义）精准扩缩
异构部署优化：在多推理引擎/异构加速器组合中按“成本-能力”贪心分配，最大化性价比

5) 主流推理引擎与异构硬件支持

支持多种主流推理引擎vLLM、SGLang、Triton/TGI 等，统一API抽象、标准化指标
支持GPU/NPU 等异构混部，配合异构 Autoscaling 实现成本与 SLO 的动态平衡

6) 内置流量控制与公平性调度

公平调度：支持基于优先级和历史Token消耗的的公平调度，既兼顾用户的优先级，对高优先级用户提供更好的服务，又防止低优先级用户“饿死”
流量控制：支持按照用户、模型、token长度进行精细化流量控制

极致的性能提升

基于 Kthena Router 的调度插件架构，在长系统提示词场景（如 4096 tokens）下，采用“KV Cache 感知 + 最少请求”策略相较随机基线：

吞吐可提升约 2.73 倍
TTFT 降低约 73.5%
端到端时延降低超过 60%

Plugin Configuration	Throughput (req/s)	TTFT (s)	E2E Latency (s)
Least Request + KVCacheAware	32.22	9.22	0.57
Least Request + Prefix Cache	23.87	12.47	0.83
Random	11.81	25.23	2.15

短提示词场景差距会随提示词长度收敛，但在多轮对话、模板化生成、前缀高度相似的业务中，KV Cache 感知策略优势显著。实际收益与模型规模、Prompt长短、硬件紧密相关，但“按需组合、按场景选型”已被验证有效。

社区展望

Kthena 在项目规划和发展的初期便得到了部分社区用户单位的关注和支持，但这只是一个开始。我们计划在未来支持更高效的调度算法、更广泛的大模型最佳部署实践，并持续深耕 LLM 推理的大规模部署和性能优化。

“开源是技术创新的源头活水，也是推动产业标准化的最强引擎。作为Volcano项目的发起单位，华为云很荣幸能够与社区其他伙伴一起推出全新的Kthena分布式推理项目。这不仅是Volcano社区技术演进的重要里程碑，更是华为云在云原生AI领域长期投入与持续创新的有力见证。它将与华为云CCE（云容器引擎）、CCI（云容器实例）等基础设施深度结合，进一步释放包括昇腾（Ascend）在内的多元算力价值，为客户提供极致的算力性价比。我们希望通过Kthena，与全球开发者与伙伴，共建、共享一个开放、繁荣的云原生AI生态，为千行万业的智能化升级构筑最坚实的算力底座。”

—— 祁小波，华为云通用计算服务产品部部长

“Kthena进一步巩固了Volcano在智能计算调度领域的领先地位。我们的平台利用Volcano的统一调度与资源池化能力，一站式满足通用计算与智能计算中训练、推理等多类算力需求。这使得算力资源能够在不同场景间灵活流转，有效避免了资源割裂的问题。展望未来，我们期待 Kthena结合Volcano的弹性伸缩能力与Volcano Global的跨集群调度特性，共同推动算力资源利用率进一步提升！”

—— 杨磊，中电信人工智能公司 PaaS研发总监

“Volcano 项目自诞生之日起，便始终与社区以及各类 AI 场景深度共建、同频演进，逐步沉淀出一整套面向 AI 工作负载的调度与批处理生态。今天，Kthena 的出现，不仅将这条共建链路进一步拓展到大模型推理领域，把推理这一关键一环真正纳入 Volcano 生态之中，更是在统一编排与智能路由层面，将 Volcano 在调度、弹性伸缩以及多算力适配上的多年实践，凝练成一个令人振奋的里程碑式能力。
借助既有的 Kubernetes / Volcano 生态，更多团队可以用更低的成本，获得更智能的调度决策和更高效的算力利用，并在开放协作的基础上持续演进。这不仅为道客解决了在推理场景中遇到的实际问题，也是我们所期待的云原生 AI 形态——一个足够开放、足够智能、值得我们长期投入和深度参与的社区方向。”

—— 徐俊杰，DaoCloud 开源团队负责人、Kubernetes 社区指导委员会成员

“自建大模型推理服务的生产级部署和运维难题，是一个覆盖推理服务全生命周期管理（部署、运维、弹性、故障恢复等），GPU集群稳定性，资源调度效率、推理服务性能提升，推理流量智能调度、AI可观测等领域的系统工程。而这也正是Kthena项目的技术定位。
早在Kthena的规划阶段，小红书云原生团队就和Kthena贡献者做了深度的沟通，在推理流量智能调度方向，一起设计了多种流量调度策略和路由实现。未来，双方将继续在AI网关方向合作，结合小红书内部业务经验，一起为社区提供更精细化的AI流量智能调度能力，模型API管理能力，MCP协议支持等多种生产可用能力。”

—— 空古(陈华昌)，小红书云原生业务网关负责人

“在深入调研并试用Kthena这一云原生AI推理平台后，联通云对其展现出的前瞻能力印象深刻。我们尤为看好其与Volcano实现的联合调度特性，其网络拓扑感知与Gang Scheduling功能，能够有效解决大规模分布式模型推理场景下中，关于效率与可靠性的核心诉求，为破解复杂调度难题提供了极具潜力的解决方案。我们相信，Kthena卓越的低延迟、高吞吐与多模型智能路由能力，将为开源社区带来真正具备生产级的AI推理解决方案，助力开发者更高效地构建和管理云原生环境下的智能应用。”

—— 卢照旭，联通云智算能力中心团队长

“开放和协作是构建社区的未来、加速技术创新的核心动力。在CNCF，我们持续致力于推动基础设施向‘AI Native’演进，为整个云原生生态提供标准、中立且可扩展的基础能力。Volcano社区通过孵化Kthena子项目，将其在大规模批量计算和调度上积累的拓扑感知、Gang调度等核心经验，精准地应用到了LLM在线推理这一关键场景。
Kthena的价值在于，它提供了一套专为大模型设计、可供业界参考借鉴的云原生调度原语和抽象，这有助于将复杂的LLM推理工作负载，真正以Kubernetes原生的一等公民身份进行高效管理。
这不仅是Volcano项目技术演进的重要一步，更是社区生态在解决AI规模化部署挑战中贡献的一份重要实践经验。我们诚挚邀请全球的开发者、研究人员和所有云原生爱好者加入，共同贡献智慧，完善这些关键AI基础设施，加速 AI Native 进程。”

—— Kevin Wang, Volcano Maintainer、CNCF TOC 副主席

立即开始探索 Kthena

GitHub 仓库: https://github.com/volcano-sh/kthena
官网: https://kthena.volcano.sh/
社区: 加入我们的 Slack https://cloud-native.slack.com/archives/C011GJDQS0N

让我们一起，为 LLM 插上云原生的翅膀，释放 AI 的全部潜能！

Ray on Volcano

Mon, 22 Dec 2025 00:00:00 +0000

Ray简介

Ray 是一个专为AI/ML应用设计的统一分布式计算框架。Ray提供以下核心能力：

分布式训练：将机器学习工作负载从单机扩展到数千个节点
超参数调优：通过Ray Tune运行并行实验，实现高效的模型优化
分布式数据处理：使用Ray Data处理大规模数据集，支持批量推理和数据预处理
强化学习：通过Ray RLlib大规模训练强化学习模型
模型服务：使用Ray Serve在生产环境中部署和扩展机器学习模型
通用分布式计算：使用Ray Core API构建任意分布式应用

在Volcano上运行Ray

当前有两种方式可以在Volcano上部署Ray集群：

KubeRay Operator方式：通过集成Volcano调度器的KubeRay Operator实现RayCluster, RayService和RayJob资源的自动化部署和管理
Volcano Job (vcjob) 方式：通过Volcano Job配合Ray插件直接部署Ray集群

以上两种方式都可以充分利用Volcano强大的调度能力，包括gang调度和网络拓扑感知调度，以实现最优的资源分配。

方法一：使用KubeRay Operator

KubeRay 是一个开源的Kubernetes Operator，可以简化在Kubernetes上运行Ray的流程。它通过Kubernetes原生的工具和API实现Ray集群的自动化部署、扩缩容和管理。

KubeRay与Volcano集成

从KubeRay v1.5.1版本开始，所有KubeRay资源（RayJob、RayCluster和RayService）均支持Volcano的高级调度特性，包括gang调度和网络拓扑感知调度。该集成能够优化资源分配并提升分布式AI/ML工作负载的性能。

支持的标签

在RayJob和RayCluster资源的metadata部分，可以使用以下标签配置Volcano调度：

标签	描述	是否必需
`ray.io/priority-class-name`	为Pod调度分配Kubernetes优先级类	否
`volcano.sh/queue-name`	指定资源提交的Volcano队列	否
`volcano.sh/network-topology-mode`	配置网络拓扑感知调度模式	否
`volcano.sh/network-topology-highest-tier-allowed`	设置调度允许的最高网络层级	否

自动扩缩容行为

KubeRay与Volcano的集成会根据自动扩缩容是否启用采用不同的gang调度策略：

启用自动扩缩容时：使用minReplicas进行gang调度
禁用自动扩缩容时：使用期望的副本数进行gang调度

这确保了在支持灵活扩缩容行为的同时，gang调度约束能够得到正确维护。

以下是包含详细说明的配置示例。有关完整的配置选项，请参阅KubeRay Volcano调度器文档。

环境要求

在使用KubeRay部署Ray之前，请确保：

已安装Volcano的Kubernetes集群正常运行

已安装支持Volcano批处理调度器的KubeRay Operator：

# Install KubeRay Operator with Volcano integration
$ helm install kuberay-operator kuberay/kuberay-operator --version 1.5.1 --set batchScheduler.name=volcano

部署示例

RayCluster示例

使用Volcano调度部署RayCluster：

# Download the sample RayCluster configuration with Volcano labels
$ curl -LO https://raw.githubusercontent.com/ray-project/kuberay/v1.5.1/ray-operator/config/samples/ray-cluster.volcano-scheduler.yaml

# Apply the configuration
$ kubectl apply -f ray-cluster.volcano-scheduler.yaml

# Verify the RayCluster deployment
$ kubectl get pod -l ray.io/cluster=test-cluster-0

# Expected output:
# NAME                                 READY   STATUS    RESTARTS   AGE
# test-cluster-0-head-jj9bg            1/1     Running   0          36s

RayJob示例

从KubeRay v1.5.1版本开始支持RayJob与Volcano的集成：

# Download the sample RayJob configuration with Volcano queue integration
$ curl -LO https://raw.githubusercontent.com/ray-project/kuberay/v1.5.1/ray-operator/config/samples/ray-job.volcano-scheduler-queue.yaml

# Apply the configuration
$ kubectl apply -f ray-job.volcano-scheduler-queue.yaml

# Monitor the job execution
$ kubectl get pod

# Expected output:
# NAME                                             READY   STATUS      RESTARTS   AGE
# rayjob-sample-0-k449j-head-rlgxj                 1/1     Running     0          93s
# rayjob-sample-0-k449j-small-group-worker-c6dt8   1/1     Running     0          93s
# rayjob-sample-0-k449j-small-group-worker-cq6xn   1/1     Running     0          93s
# rayjob-sample-0-qmm8s                            0/1     Completed   0          32s

方法二：使用Volcano Job配合Ray插件

Volcano提供了原生的Ray插件，可以简化通过Volcano Job直接部署Ray集群的流程。该方式作为KubeRay的轻量级替代方案，允许用户使用Volcano的作业管理能力来管理Ray集群。

Ray插件工作原理

Ray插件自动完成以下配置：

为Ray集群中的head节点和worker节点配置启动命令
开放Ray服务所需的端口（GCS：6379，Dashboard：8265，Client Server：10001）
创建映射到Ray head节点的Kubernetes Service，用于作业提交和Dashboard访问

环境要求

在使用Volcano Job部署Ray之前，请确保：

已安装Volcano并启用Ray插件
同时启用svc插件（创建Service所必需）

部署示例

创建一个包含1个head节点和2个worker节点的Ray集群：

apiVersion: batch.volcano.sh/v1alpha1
kind: Job
metadata:
  name: ray-cluster-job
spec:
  minAvailable: 3
  schedulerName: volcano
  plugins:
    ray: []
    svc: []
  policies:
    - event: PodEvicted
      action: RestartJob
  queue: default
  tasks:
    - replicas: 1
      name: head
      template:
        spec:
          containers:
            - name: head
              image: rayproject/ray:latest-py311-cpu
              resources: {}
          restartPolicy: OnFailure
    - replicas: 2
      name: worker
      template:
        spec:
          containers:
            - name: worker
              image: rayproject/ray:latest-py311-cpu
              resources: {}
          restartPolicy: OnFailure

应用配置：

kubectl apply -f ray-cluster-job.yaml

访问Ray集群

部署完成后，可以通过自动创建的Service访问Ray集群：

# Check pod status
kubectl get pod
# Expected output:
# NAME                       READY   STATUS    RESTARTS   AGE
# ray-cluster-job-head-0     1/1     Running   0          106s
# ray-cluster-job-worker-0   1/1     Running   0          106s
# ray-cluster-job-worker-1   1/1     Running   0          106s

# Check service
kubectl get service
# Expected output includes:
# ray-cluster-job-head-svc   ClusterIP   10.96.184.65   <none>   6379/TCP,8265/TCP,10001/TCP

# Port-forward to access Ray Dashboard
kubectl port-forward service/ray-cluster-job-head-svc 8265:8265

# Submit a job to the cluster
ray job submit --address http://localhost:8265 -- python -c "import ray; ray.init(); print(ray.cluster_resources())"

了解更多

有关KubeRay集成的详细信息，请访问KubeRay Volcano调度器文档
有关Volcano Job Ray插件的详细信息，请参阅Volcano Ray插件指南

Cron VolcanoJob

Wed, 19 Nov 2025 00:00:00 +0000

定义

Cron VolcanoJob, 简称cronvcjob，cronvj，是Volcano自定义的资源类型。用户现在可以根据预定义的调度计划定期创建和运行Volcano Job，类似于Kubernetes原生的CronJob，以实现批量计算任务(如AI和大数据)的定期执行。

样例

apiVersion: batch.volcano.sh/v1alpha1
kind: CronJob
metadata:
  name: volcano-cronjob-example
spec:
  schedule: "*/5 * * * *"
  concurrencyPolicy: Forbid
  startingDeadlineSeconds: 60
  successfulJobsHistoryLimit: 5
  failedJobsHistoryLimit: 3
  jobTemplate:
    spec:
      schedulerName: volcano
      tasks:
        - replicas: 1
          name: "task-1"
          template:
            spec:
              containers:
                - name: busybox-container
                  image: busybox:latest
                  command: ["/bin/sh", "-c", "date; echo Hello from Volcano CronJob"]
              restartPolicy: OnFailure
      policies:
        - event: PodEvicted
          action: RestartJob
      minAvailable: 1

查看 Cron VolcanoJob

kubectl get cronvcjob

查看创建的 job 实例

kubectl get vcjob

关键字段

schedule

必需。用于volcano job 执行的 cron 计划字符串。使用标准 cron 格式。
timeZone

可选。调度计划的时区名称。默认为 kube-controller-manager 的本地时区。
concurrencyPolicy

可选。指定如何管理 Cron VolcanoJob 创建的 job 的并发执行。为下列规则中的一种：
- Allow（默认）：允许并发运行
- Forbid：禁止并发运行，跳过新周期的执行
- Replace：取消当前运行的 job，并用新的 job 替换它

startingDeadlineSeconds

可选。如果 job 错过其计划时间，启动 job 的截止时间（秒）。
suspend

可选。如果设置为 true，所有后续执行将被暂停。
jobTemplate

必需。用于创建 Volcano Job 的模板。包含完整的 Volcano Job 规范。
successfulJobsHistoryLimit

可选。要保留的成功完成 job 的数量。默认为 3。
failedJobsHistoryLimit

可选。要保留的失败完成 job 的数量。默认为 1。

使用场景

定期模型训练

每天凌晨自动启动分布式模型训练任务，利用集群空闲时段进行大规模机器学习训练。

apiVersion: batch.volcano.sh/v1alpha1
kind: CronJob
metadata:
  name: daily-model-training
spec:
  schedule: "0 2 * * *"  # 每天凌晨2点运行
  concurrencyPolicy: Forbid
  jobTemplate:
    spec:
      minAvailable: 4
      schedulerName: volcano
      tasks:
        - replicas: 1
          name: ps
          template:
            # 参数服务器配置
        - replicas: 3  
          name: worker
          template:
            # 训练worker配置

定时资源清理

每周日晚上清理临时数据和日志文件，释放集群存储空间。

apiVersion: batch.volcano.sh/v1alpha1
kind: CronJob
metadata:
  name: weekly-cleanup
spec:
  schedule: "0 22 * * 0"  # 每周日22点运行
  timeZone: "Asia/Shanghai"
  jobTemplate:
    spec:
      minAvailable: 1
      schedulerName: volcano
      tasks:
        - replicas: 1
          name: cleanup
          template:
            # 清理任务容器配置

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

Mon, 29 Sep 2025 00:00:00 +0000

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

北京时间2025年9月29日，Volcano v1.13 版本[1]正式发布。本次更新在多方面进行了功能增强，为用户提供更完善的云原生批量计算解决方案。

版本亮点

v1.13.0版本的主要更新包括：

AI训练与推理增强

资源管理与调度增强

混部能力增强

支持LeaderWorkerSet用于大模型推理场景

LeaderWorkerSet (LWS) 是一个用于在Kubernetes上部署一组Pod的API。它主要用于解决AI/ML推理工作负载中的多主机推理问题，特别是需要对大型语言模型(LLM)进行分片并在多个节点的多个设备上运行的场景。

自开源以来，Volcano一直积极与上下游生态集成，构建了涵盖AI和大数据等批量计算的全面社区生态。在LWS的v0.7版本中，它原生集成了Volcano的AI调度能力。与新版本的Volcano配合使用时，LWS会自动创建PodGroup，然后由Volcano进行调度和管理，从而为大模型推理场景实现Gang调度等高级能力。

展望未来，Volcano将继续扩展其生态集成能力，为更多致力于在Kubernetes上实现分布式推理的项目提供强大的调度和资源管理支持。

使用文档：LeaderWorkerSet With Gang。

感谢社区开发者：@JesseStutler

新增Cron VolcanoJob

本次版本引入了对Cron Volcano Job的支持。用户现在可以根据预定义的调度计划定期创建和运行Volcano Job，类似于Kubernetes原生的CronJob，以实现批量计算任务(如AI和大数据)的定期执行。详细功能如下：

定时执行：使用标准的Cron表达式(spec.schedule)定义作业的执行周期。
时区支持：在spec.timeZone中设置时区，确保作业在预期的本地时间执行。
并发策略：通过spec.concurrencyPolicy控制并发行为：
- AllowConcurrent：允许多个作业并发执行(默认)。
- ForbidConcurrent：如果前一个作业尚未完成，则跳过当前的调度执行。
- ReplaceConcurrent：如果前一个作业仍在运行，则终止它并启动新的作业。
历史管理：配置要保留的成功(successfulJobsHistoryLimit)和失败(failedJobsHistoryLimit)作业历史记录的数量；旧作业会自动清理。
错过调度处理：startingDeadlineSeconds字段允许在一定时间范围内容忍调度延迟；超时被视为错过执行。
状态跟踪：CronJob状态(status)跟踪当前活动的作业、上次调度时间和上次成功完成时间，便于监控和管理。

感谢社区开发者：@GoingCharlie, @hwdef, @Monokaix

使用示例：Cron Volcano Job Example。

支持基于标签的HyperNode自动发现

Volcano在v1.12版本中正式推出了网络拓扑感知调度能力，并率先实现了基于InfiniBand (IB)网络的UFM自动发现机制。然而，对于不支持IB网络或使用其他网络架构(如以太网)的硬件集群，手动维护网络拓扑仍然繁琐。

为解决这一问题，新版本引入了基于标签的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中添加标签源来启用。上述配置定义了一个名为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

基于标签的网络拓扑自动发现功能提供了出色的通用性和灵活性。它不依赖于特定的网络硬件(如IB)，适用于各种异构集群，并允许用户通过标签灵活定义任意深度的层级结构。它将复杂的拓扑维护任务自动化为简单的节点标签管理，显著降低了运维成本和错误风险。此外，该机制可以动态适应集群节点和标签的变化，实时保持拓扑信息的准确性，无需手动干预。

感谢社区开发者：@zhaoqi612

使用文档：HyperNode Auto Discovery。

新增原生Ray框架支持

Ray 是一个开源的统一分布式计算框架，其核心目标是简化从单机到大规模集群的并行计算，特别适合扩展Python和AI应用。为了在Kubernetes上管理和运行Ray，社区提供了KubeRay——一个专为Kubernetes设计的操作器。它充当Kubernetes和Ray框架之间的桥梁，极大地简化了Ray集群和作业的部署和管理。

历史上，在Kubernetes上运行Ray工作负载主要依赖于KubeRay Operator。KubeRay在其v0.4.0版本(2022年发布)中集成了Volcano，用于Ray集群的调度和资源管理，解决了分布式训练场景中的资源死锁等问题。随着Volcano新版本的推出，用户现在可以直接通过原生Volcano Job创建和管理Ray集群并提交计算任务。这为Ray用户提供了另一种使用方案，允许他们更直接地利用Volcano的Gang调度、队列管理和公平调度以及作业生命周期管理等能力来运行Ray工作负载。

感谢社区开发者：@Wonki4

设计文档：Ray Framework Plugin Design Doc。

使用文档：Ray Plugin User Guide。

新增HCCL插件支持

新版本为Volcano Job添加了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配置非严格模式。示例配置如下：

actions: "allocate, backfill, preempt, reclaim"
tiers:
- plugins:
  - name: nodegroup
    arguments:
      enableHierarchy: true # 启用层级支持
      strict: false # 设置为非严格模式，允许队列中的任务调度到没有"volcano.sh/nodegroup-name"标签的节点

感谢社区开发者：@JesseStutler, @wuyueandrew

NodeGroup设计文档：NodeGroup Design.

NodeGroup使用文档：NodeGroup User Guide.

引入ResourceStrategyFit插件

在Kubernetes原生的noderesources fit策略中，只能对所有资源应用单一的聚合(MostAllocated)或分散(LeastAllocated)策略。这在复杂的异构计算环境(如AI/ML集群)中存在局限性。为满足差异化的调度需求，Volcano引入了增强的ResourceStrategyFit插件。

该插件现在集成了两个核心功能：按资源类型独立评分策略和稀缺资源避让(SRA)。

按资源类型独立评分策略

此功能允许用户为不同的资源(例如cpu、memory、nvidia.com/gpu)独立指定MostAllocated(binpack)或LeastAllocated(spread)策略，并为它们分配不同的权重。调度器根据每种资源的独立配置精细计算节点分数。

为简化同一系列资源的管理(例如，同一供应商的不同型号GPU)，此功能还支持资源名称的后缀通配符(*)匹配。

语法规则：仅支持后缀通配符，例如nvidia.com/gpu/*。像*或vendor.*/gpu这样的模式被视为无效。
匹配优先级：使用”最长前缀匹配”原则。精确匹配具有最高优先级；当不存在精确匹配时，选择具有最长前缀的通配符模式。

配置示例：以下配置为特定的V100 GPU型号设置高优先级binpack策略，为所有其他NVIDIA GPU设置通用binpack策略，为CPU资源设置spread策略。还支持Pod级别的资源评分策略配置。

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

稀缺资源避让(SRA)

SRA是一种”软”策略，旨在提高昂贵或稀缺资源(如GPU)的整体利用率。它影响节点评分，引导不需要特定稀缺资源的普通任务(例如，仅需CPU的任务)尽可能避免包含这些资源的节点。这有助于为真正需要稀缺资源的任务”保留”稀缺资源节点，从而减少资源争用和任务等待时间。

机制：

用户在配置中定义一组”稀缺资源”(例如nvidia.com/gpu)。
当调度不请求任何定义的稀缺资源的Pod时，SRA策略生效。
调度器降低拥有这些稀缺资源的节点的分数。节点拥有的稀缺资源类型越多，其分数越低。
对于请求稀缺资源的Pod，SRA策略不会对其调度决策产生负面影响。

配置示例：以下配置将nvidia.com/gpu定义为稀缺资源。当调度仅需CPU的任务时，拥有GPU的节点的分数将降低，使任务更有可能调度到没有GPU的节点。

actions: "enqueue, allocate, backfill, reclaim, preempt"
tiers:
- plugins:
  - name: resource-strategy-fit
    arguments:
      # ... resourceStrategyFit的binpack/spread策略配置 ...
      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的binpack/spread策略和SRA的避让策略，用户可以实现对异构资源更精细和高效的调度。

感谢社区开发者：@LY-today, @XbaoWu, @ditingdapeng, @kingeasternsun

设计文档：ResourceStrategyFit Design

使用文档：ResourceStrategyFit User Guide

混部能力与操作系统解耦

Volcano的混部能力由两部分组成：应用级和内核级。应用级混部为在线和离线工作负载提供统一调度、动态资源超卖、节点压力驱逐等功能。内核级混部涉及在内核级别对CPU、内存和网络等资源的QoS保证，通常需要特定操作系统(如OpenEuler)的支持。在新版本中，Volcano将混部能力与操作系统解耦。对于使用不支持内核级混部的操作系统的用户，他们可以选择使用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"

感谢社区开发者：@ShuhanYan, @Monokaix

混部文档：https://volcano.sh/en/docs/colocation/

支持自定义超卖资源名称

Volcano混部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/memory

感谢社区开发者：@ShuhanYan, @Monokaix

混部文档：https://volcano.sh/en/docs/colocation/

新增Kubernetes 1.33支持

Volcano版本与Kubernetes社区发布保持同步。v1.13支持最新的Kubernetes v1.33版本，通过全面的UT和E2E测试用例确保功能和可靠性。

参与Volcano适配新Kubernetes版本工作，请参考：adapt-k8s-todo。

感谢社区开发者：@mahdikhashan

总结：Volcano v1.13.0，持续引领云原生批量计算发展

Volcano v1.13.0不仅是技术的提升，更是云原生批量计算领域的持续创新。无论是AI大模型训练与推理、大数据调度，还是资源优化，Volcano v1.13.0都提供了强大的功能和灵活的解决方案。我们相信Volcano v1.13.0将帮助用户在云原生批量计算领域取得更大的成就，开启AI与大数据调度的新篇章！

立即体验Volcano v1.13.0，步入高效计算的新时代！

v1.13.0发布地址： https://github.com/volcano-sh/volcano/releases/tag/v1.13.0

致谢

Volcano v1.13.0包含了36位社区成员的贡献。衷心感谢所有贡献者：

@ElectricFish7	@philandstuff	@junzebao
@ShuhanYan	@GautamBytes	@coldzerofear
@houyuting	@lhlxc	@cyf-2002
@neo502721	@suyiiyii	@dafu-wu
@ditingdapeng	@GoingCharlie	@Wonki4
@zhaoqi612	@huntersman	@JesseStutler
@LY-today	@XbaoWu	@kingeasternsun
@Monokaix	@wuyueandrew	@mahdikhashan
@bibibox	@archlitchi	@guoqinwill
@ouyangshengjia	@Poor12	@dongjiang1989
@zhifei92	@halcyon-r	@Xu-Wentao
@hajnalmt	@kevin-wangzefeng	@linuxfhy

GPU虚拟化

Thu, 19 Jun 2025 00:00:00 +0000

前提条件

运行Volcano设备插件所需的前提条件如下：

NVIDIA驱动 > 440
nvidia-docker版本 > 2.0 (参见如何安装及其前提条件)
将docker配置为使用nvidia作为默认运行时
Kubernetes版本 >= 1.16
Volcano版本 >= 1.9

环境设置

安装 Volcano

参考安装指南安装Volcano。

安装后，更新调度器配置：

kubectl edit cm -n volcano-system volcano-scheduler-configmap

kind: ConfigMap
apiVersion: v1
metadata:
  name: volcano-scheduler-configmap
  namespace: volcano-system
data:
  volcano-scheduler.conf: |
    actions: "enqueue, allocate, backfill"
    tiers:
    - plugins:
      - name: priority
      - name: gang
      - name: conformance
    - plugins:
      - name: drf
      - name: deviceshare
        arguments:
          deviceshare.VGPUEnable: true # 启用 vgpu
      - name: predicates
      - name: proportion
      - name: nodeorder
      - name: binpack

安装 Volcano vGPU Device Plugin

参考Enabling GPU Support in Kubernetes。

验证环境是否就绪

检查节点状态，如果在可分配资源（allocatable resources）中包含 volcano.sh/vgpu-memory 和 volcano.sh/vgpu-number，则表示环境正常。

$ kubectl get node {node name} -oyaml
...
status:
  addresses:
  - address: 172.17.0.3
    type: InternalIP
  - address: volcano-control-plane
    type: Hostname
  allocatable:
    cpu: "4"
    ephemeral-storage: 123722704Ki
    hugepages-1Gi: "0"
    hugepages-2Mi: "0"
    memory: 8174332Ki
    pods: "110"
    volcano.sh/vgpu-memory: "89424"
    volcano.sh/vgpu-number: "8"    # GPU 资源
  capacity:
    cpu: "4"
    ephemeral-storage: 123722704Ki
    hugepages-1Gi: "0"
    hugepages-2Mi: "0"
    memory: 8174332Ki
    pods: "110"
    volcano.sh/vgpu-memory: "89424"
    volcano.sh/vgpu-number: "8"   # GPU 资源

运行 GPU 共享作业

可以通过在resource.limit中设置”volcano.sh/vgpu-number”、”volcano.sh/vgpu-cores”和”volcano.sh/vgpu-memory”来申请vGPU。

$ cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: gpu-pod1
spec:
  schedulerName: volcano
  containers:
    - name: cuda-container
      image: nvidia/cuda:9.0-devel
      command: ["sleep"]
      args: ["100000"]
      resources:
        limits:
          volcano.sh/vgpu-number: 2 # 申请 2 个 vGPU 卡
          volcano.sh/vgpu-memory: 3000 # (可选) 每个 vGPU 使用 3G 设备显存
          volcano.sh/vgpu-cores: 50 # (可选) 每个 vGPU 使用 50% 的核心
EOF

可以在容器内使用nvidia-smi命令验证设备显存：

警告： 如果在使用device plugin和NVIDIA镜像时未申请GPU，节点上的所有GPU都会暴露在容器内。 容器使用的vGPU数量不能超过该节点上的物理GPU总数。

监控

volcano-scheduler-metrics记录了每个GPU的使用情况和限制。访问以下地址获取这些指标：

curl {volcano-scheduler-cluster-ip}:8080/metrics

还可通过访问以下地址，在节点上收集GPU利用率、GPU显存使用量、Pod的GPU显存限制和Pod的GPU显存使用量等指标：

curl {volcano-device-plugin-pod-ip}:9394/metrics

问题与贡献

可以通过提交新的issue报告Bug。
可以通过发起拉取请求(pull request)为项目做出贡献。

科大讯飞凭借Volcano实现AI基础设施突破，赢得CNCF最终用户案例研究竞赛

Fri, 13 Jun 2025 00:00:00 +0000

[ 中国，香港，2025年6月10日 ] 云原生计算基金会（CNCF）宣布，科大讯飞赢得 CNCF 最终用户案例研究竞赛。CNCF致力于构建可持续的云原生软件生态，科大讯飞凭借其在 Volcano 上的创新应用脱颖而出，获得本次殊荣，于6月10日至11日在香港举行的KubeCon + CloudNativeCon China 大会上，分享其大规模 AI 模型训练的成功经验。

科大讯飞的挑战

作为专注于语音和语言 AI 的中国科技公司，科大讯飞在业务快速增长过程中遇到了扩展难题。调度效率低导致 GPU 资源利用不足，工作流管理复杂，团队间资源争抢激烈，这些问题拖慢了研发进度，也给基础设施带来压力。

使用 Volcano 后，科大讯飞实现了弹性调度、基于 DAG 的工作流和多租户隔离，简化了操作流程，显著提升了资源利用率。

“在使用 Volcano 之前，跨团队协调大规模 GPU 集群训练就像不断‘灭火’，资源瓶颈、任务失败和复杂的训练管道调试层出不穷，”科大讯飞高级平台架构师 DongJiang 表示。“Volcano 让我们拥有更灵活的控制权，能够高效可靠地扩展 AI 训练。CNCF 对我们的认可令我们倍感荣幸，我们也很期待在 KubeCon + CloudNativeCon China 现场与更多同行分享我们的实践经验。”

关于 Volcano

Volcano 是基于 Kubernetes 构建的云原生批处理系统，专为 AI/机器学习训练、大数据处理和科学计算等高性能工作负载设计。它提供先进的调度功能，如任务编排、资源公平分配和队列管理，能够高效管理大规模分布式任务。自 2020 年加入 CNCF Sandbox 项目，2022 年晋升为 Incubating 阶段项目，Volcano 已成为处理计算密集型任务的关键工具。

Volcano 为科大讯飞带来的显著成效

随着 AI 需求不断增长，科大讯飞选择 Volcano 来应对训练基础设施日益复杂和庞大的挑战。工程团队需要更高效的资源分配方案，管理多阶段复杂训练工作流，减少任务中断，并保障不同团队的公平资源使用。借助 Volcano，他们实现了：

GPU 利用率提升 40%，显著降低基础设施成本和计算资源闲置。
任务失败恢复速度提升 70%，确保训练过程不中断。
资源干扰率降低 50 %，保障业务稳定性和资源使用灵活性

CNCF 首席技术官 Chris Aniszczyk 表示：“科大讯飞的案例展示了开源技术如何解决复杂且关键的规模化挑战。通过 Volcano 提升 GPU 效率和优化训练工作流，他们降低了成本，加快了开发，并在 Kubernetes 平台上构建了更可靠的 AI 基础设施，这对所有致力于 AI 领先的组织都至关重要。”

随着 AI 工作负载变得更加复杂和资源密集，科大讯飞的实践证明，Volcano 等云原生工具能够帮助团队简化运营、提升扩展能力。其在 KubeCon + CloudNativeCon China 的分享[1]，带来如何在 Kubernetes 环境下更有效管理分布式训练的实用经验。

参考资料

[1] 分享: https://kccncchn2025.sched.com/event/23EWS?iframe=no

Volcano v1.12.0正式发布

Thu, 12 Jun 2025 00:00:00 +0000

Volcano v1.12 正式发布！驱动云原生AI与批量计算向智能高效新阶段演进

随着AI大模型技术的快速发展，企业对计算资源利用效率和应用性能的要求日益提高。在AI、大数据及高性能计算（HPC）等复杂应用场景下，如何高效利用GPU等异构加速器、保障系统高可用性并精细化管理资源，是Volcano社区持续探索和创新的核心方向。

Volcano的每一次版本迭代，都是对这些挑战的积极回应。在来自全球30余个国家、超过1000名开发者、近40000次贡献的共同建设下，Volcano已在国内外60多家企业的生产环境中得到应用，其调度性能与资源管理能力在实践中获得了广泛认可。

今天，Volcano社区正式发布 v1.12 版本。 新版本聚焦于AI与大数据等前沿场景的核心需求，带来了一系列关键特性与体验优化：

新版本亮点一览

网络拓扑感知调度 (Alpha): 优化大规模AI训练与推理任务部署，通过感知网络拓扑减少跨交换机通信，提升运行效率。
GPU虚拟化方案增强: 在原有vCUDA方案基础上，新增对NVIDIA GPU动态MIG切分的支持，为用户提供软件与硬件两种虚拟化选择，实现更灵活、高效的GPU资源共享。
DRA支持: 增强异构资源管理的灵活性与能力。
Volcano Global支持队列容量管理: 在多集群环境下，支持对租户队列的资源配额（capability）进行统一限制和管理。
安全性全面增强: 从API访问控制到容器运行时权限，实施多维度安全加固，提升系统稳健性。
大规模场景性能优化: 通过减少不必要的Webhook调用等手段，有效提升高并发任务处理效率。
增强通用工作负载的Gang调度控制: 现已支持通过Annotation为Deployment、StatefulSet等通用工作负载自定义Gang调度所需的最小成员数（minMember），提供了更精细的Gang Scheduling调度策略。
Job Flow功能增强: 提升了内置工作流编排引擎的健壮性与可观测性。
以及更多稳定性与易用性改进。

我们相信，v1.12版本的这些更新将进一步提升任务调度的智能化水平、资源利用效率和系统的整体性能，帮助用户更好地应对AI和大数据时代的挑战。

核心功能详解

网络拓扑感知调度 (Alpha Release)

Volcano 的网络拓扑感知调度功能，在 v1.11 中作为预览版发布后，现已在 v1.12 中达到 Alpha 发布状态。此功能旨在优化大规模训练和推理场景（如模型并行训练、Leader-Worker 推理）中 AI 任务的部署。它通过将任务调度到同一网络拓扑性能域内，减少跨交换机通信，从而显著提升任务效率。Volcano 使用 HyperNode CRD 来抽象和表示异构硬件网络拓扑，并支持层级结构以方便管理。

v1.12 版本集成了以下关键特性：

HyperNode 自动发现 (HyperNode Auto-Discovery)： Volcano 提供了集群网络拓扑的自动发现能力。用户可配置发现类型，系统将自动创建和维护反映集群真实网络拓扑的层级 HyperNode。目前支持 InfiniBand (IB) 网络下通过 UFM (Unified Fabric Manager) 接口获取网络拓扑信息，并自动更新 HyperNode。未来计划支持 RoCE 等更多网络协议。
HyperNode 优选策略 (Prioritized HyperNode Selection)：引入了基于节点级别和 HyperNode 级别的打分策略，累加后作为 HyperNode 的最终得分。
- 节点级别 (Node-level)：建议配置 BinPack 插件以优先填满 HyperNode，减少资源碎片。
- HyperNode 级别 (HyperNode-level)：优先选择层级更低的 HyperNode 以获得更优性能，因其涉及的跨交换机次数较少；对于相同层级的 HyperNode，包含更多任务的 HyperNode 得分更高，旨在减少 HyperNode 级别的资源碎片。
支持通过 Label Selector 匹配节点 (Support for Label Selector Node Matching)： HyperNode 叶子节点与集群中的物理节点关联，支持以下三种匹配策略：
- 精确匹配 (Exact Match)：直接匹配节点名称。
- 正则匹配 (Regex Match)：通过正则表达式匹配节点名称。
- 标签匹配 (Label Match)：通过标准 Label Selector 匹配节点。

GPU 虚拟化支持动态 MIG 切分

Volcano 提供的 GPU 虚拟化功能支持按显存和算力申请部分 GPU 资源，通过与 Device Plugin 配合实现硬件隔离，从而提升 GPU 利用率。传统 GPU 虚拟化通过拦截 CUDA API 方式限制 GPU 使用。NVIDIA Ampere 架构引入的 MIG (Multi-Instance GPU) 技术允许将单个物理 GPU 划分为多个独立实例。然而，通用 MIG 方案通常预先固定实例大小，存在资源浪费和灵活性不足的问题。

Volcano v1.12 提供了动态 MIG 切分与调度能力，可根据用户申请的 GPU 用量实时选择合适的 MIG 实例大小，并使用 Best-Fit 算法减少资源浪费。同时支持 BinPack 和 Spread 等 GPU 打分策略，以减少资源碎片并提升 GPU 利用率。用户可使用统一的 volcano.sh/vgpu-number、volcano.sh/vgpu-cores、volcano.sh/vgpu-memory API 申请资源，无需关注底层实现。

设计文档：Dynamic MIG 设计文档
使用文档：Dynamic MIG 使用文档

Related PRs:

由衷感谢社区开发者: @sailorvii, @archlitchi 对该特性的贡献！

支持 DRA (Dynamic Resource Allocation)

Kubernetes DRA (Dynamic Resource Allocation，动态资源分配) 是一项内置的 Kubernetes 功能，旨在提供一种更灵活、更强大的方式来管理集群中的异构硬件资源，例如 GPU、FPGA、高性能网卡等。它解决了传统设备插件 (Device Plugin) 在某些高级场景下的局限性。Volcano v1.12 增加了对 DRA 的支持，允许集群动态分配和管理外部资源，增强了 Volcano 与 Kubernetes 生态系统的集成能力及资源管理的灵活性。

使用文档：在Volcano中启用DRA

Related PR:

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

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

Volcano Global 支持队列容量管理

队列是 Volcano 的核心概念。为支持多集群和多租户场景下的租户配额管理，Volcano 在 v1.12 中扩展了其全局队列容量管理能力。现在，用户可以在多集群环境中统一限制租户的资源使用，其配置方式与单集群场景一致：通过在队列配置中设置 capability 字段来限制租户配额。

Related PR:

https://github.com/volcano-sh/volcano-global/pull/16

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

安全性增强

Volcano 社区持续关注安全性。在 v1.12 中，除了对 ClusterRole 等敏感权限的精细控制外，还修复了以下潜在安全风险并进行了加固：

HTTP Server 设置超时时间： Volcano 各组件的 Metric 和 Healthz 端点均已设置服务器端的 ReadHeader、Read、Write 超时，避免资源长时间占用。(PR: https://github.com/volcano-sh/volcano/pull/4208)
跳过 SSL 证书验证时增加警告日志：当客户端请求设置insecureSkipVerify为 true时，添加警告日志，建议生产环境启用 SSL 证书验证。(PR: https://github.com/volcano-sh/volcano/pull/4211)
默认关闭 Volcano Scheduler 的 pprof 端点：为避免敏感程序信息泄露，默认关闭用于定位问题的 Profiling 数据端口。(PR: https://github.com/volcano-sh/volcano/pull/4173)
移除不必要的文件权限：移除 Go 源文件不必要的执行权限，保持文件最小权限。(PR: https://github.com/volcano-sh/volcano/pull/4171)
为容器设置 Security Context 并以非 Root 权限运行：所有 Volcano 组件均以非 Root 权限运行，并增加了 seccompProfile, SELinuxOptions，设置 allowPrivilegeEscalation避免容器提权，同时仅保留必要的 Linux Capabilities，全面限制容器权限。(PR: https://github.com/volcano-sh/volcano/pull/4207)
限制 HTTP 请求返回体大小：针对 Extender Plugin 和 Elastic Search Service 发送的 HTTP 请求，限制其返回体大小，避免资源过度消耗导致的 OOM 等问题。(披露地址: https://github.com/volcano-sh/volcano/security/advisories/GHSA-hg79-fw4p-25p8)

大规模场景性能提升

Volcano 持续优化性能。新版本在不影响功能的前提下，默认移除和关闭了部分非必要的 Webhook，提升了大规模批创建场景下的性能：

默认关闭 PodGroup 的 Mutating Webhook：在创建 PodGroup 未指定队列时，可从 Namespace 读取进行填充。由于该场景不常见，故默认关闭此 Webhook。用户可按需开启。
任务提交时的队列状态校验从 Pod 迁移到 PodGroup：当队列处于关闭状态时，不允许提交任务。原校验逻辑在创建 Pod 时进行，而 Volcano 的调度基本单位是 PodGroup，将校验迁移至 PodGroup 创建时更为合理。因 PodGroup 数量少于 Pod，此举可减少 Webhook 调用，提升性能。

Related PRs:

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

多种负载类型支持 Gang 调度

Gang 调度是 Volcano 的核心能力。对于 Volcano Job 和 PodGroup 对象，用户可直接设置 minMember 来定义所需最小副本数。在新版本中，用户可通过在 Deployment、StatefulSet、Job 等其他类型工作负载上设置 Annotation scheduling.volcano.sh/group-min-member 来指定所需最小副本数。这意味着在使用 Volcano 调度时，要么指定数量的副本全部调度成功，要么一个也不调度，从而为多种负载类型实现了 Gang 调度。

例如，为 Deployment 设置 minMember=10：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: volcano-group-deployment
  annotations:
    # Set min member=10
    scheduling.volcano.sh/group-min-member: "10"

Related PR:

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

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

Job Flow 功能增强

Job Flow 是 Volcano 提供的轻量级 Volcano Job 工作流编排框架。在 v1.12 版本中，Job Flow 进行了以下增强：

新增监控指标：增加了对成功和失败的 Job Flow 数量的度量支持。
DAG 合法性校验：引入了对 Job Flow DAG (有向无环图) 结构进行合法性校验的功能。
状态同步问题修复：解决了 Job Flow 状态同步不准确的问题。

Related PRs:

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

多租户场景下更细粒度的权限控制

Volcano 原生支持多租户环境，并重视多租户场景下的权限控制。在新版本中，Volcano 增强了对 Volcano Job 的权限控制，增加了只读和读写的 ClusterRole，用户可根据需要为不同租户分配不同的读写权限，以实现权限隔离。

Related PR:

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

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

支持 Kubernetes 1.32

Volcano 版本紧随 Kubernetes 社区版本。v1.12 支持最新的 Kubernetes v1.32 版本，并通过完整的 UT 和 E2E 测试用例确保功能和可靠性。

如需参与 Volcano 对新 Kubernetes 版本的适配工作，请参考：adapt-k8s-todo。

Related PR:

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

由衷感谢社区开发者: @guoqinwill, @danish9039 对该特性的贡献！

队列监控指标增强

Volcano 队列新增了多项关键资源度量指标。现在支持对 CPU、Memory 及扩展资源的请求量 (request)、已分配量 (allocated)、应得量 (deserved)、容量 (capacity) 和实际容量 (real_capacity) 等指标进行监控与可视化，提供队列关键资源状态的详细视图。

Related PR:

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

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

支持模糊测试

模糊测试 (Fuzz Testing) 是一种自动化软件测试技术。Volcano 在新版本中引入了模糊测试框架，对关键函数单元进行了模糊测试，并使用 Google 开源的 OSS-Fuzz 模糊测试框架进行持续测试，旨在提前发现潜在漏洞和缺陷，增强 Volcano 的安全性和健壮性。

Related PR:

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

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

稳定性增强

新版本中修复了多项稳定性问题，包括队列容量设置不合理导致的 Panic、层级队列校验失败、PodGroup 无意义刷新以及 StatefulSet 副本为0时仍占用队列资源等问题，进一步提升了系统在复杂场景下的稳定运行能力。

Related PRs:

由衷感谢社区开发者: @halcyon-r, @guoqinwill, @JackyTYang, @JesseStutler, @zhutong196, @Wang-Kai, @HalfBuddhist 的贡献！

升级前注意事项

在升级到 Volcano v1.12 之前，请注意以下改动：

PodGroup Mutating Webhook 默认关闭：在 v1.12 中，PodGroup 的 Mutating Webhook 默认处于关闭状态。若您有依赖此行为（创建 PodGroup 未指定队列时从 Namespace 填充）的特定工作流，请确保在升级后手动开启此 Webhook。
队列状态校验迁移及行为变更：任务提交时的队列状态校验逻辑已从 Pod 创建阶段迁移到 PodGroup 创建阶段。当队列处于关闭状态时，系统将在 PodGroup 创建时即阻止任务提交。然而，如果在队列关闭后继续向该队列提交独立的 Pod（非通过 PodGroup 提交），这些 Pod 可以提交成功，但 Volcano Scheduler 将不会对其进行调度。
Volcano Scheduler pprof 端点默认禁用：出于安全增强考虑，Volcano Scheduler 的 pprof 端点在此版本中默认禁用。如需使用，可通过 Helm 参数 custom.scheduler_pprof_enable=true 或命令行参数 --enable-pprof=true 显式启用。

总结与展望

Volcano v1.12 版本的发布，得益于社区贡献者和用户的共同努力。此版本在 AI 任务调度、GPU 资源利用率、异构资源管理、安全性以及大规模场景下的性能与稳定性等多个方面进行了增强。

v1.12 版本旨在提升用户在云原生环境中运行 AI、大数据等批量计算任务的性能和效率。我们建议用户升级并体验新版本，并欢迎通过社区渠道提供使用反馈与改进建议。

未来，Volcano 社区将继续关注 CNAI 和大数据等领域的核心需求，持续进行迭代。

未来展望与需求征集

Volcano 社区始终致力于构建更加强大、灵活和易用的批量计算平台，并积极响应快速发展的技术趋势与用户需求。在接下来的版本迭代中，我们计划重点投入以下方向：

深化网络拓扑感知调度能力：在v1.12 Alpha版本的基础上，我们将持续演进网络拓扑感知能力。重点包括提供对RoCE网络的自动发现支持、节点标签的智能识别与利用，并向更细粒度的任务级（Task-level）拓扑感知调度迈进。同时，我们也将积极探索和实现更多高级调度特性，以应对复杂AI训练等场景的极致性能需求。相关issue:
引入高级资源管理机制：重点开发和完善作业重调度（Rescheduling）与资源预留（Resource Reservation）功能。这将有助于更灵活地应对集群动态负载变化，保障关键任务的资源确定性，并进一步提升整体集群的资源利用效率。相关issue:
- GPU fragmentation across nodes and Job/Pod rescheduling strategy request
增强队列调度灵活性：提供队列级别的调度策略（Queue-level Scheduling Policy）精细化配置能力。用户将能根据不同业务队列的特性、优先级和SLA需求，更灵活地定制其调度行为和资源分配策略。相关issue：
- volcano supports queue-level scheduling policies
深化生态协同与集成：我们将积极推进与Kubernetes上游社区及其他云原生项目的协作。例如，推动LWS（Leader Worker Set）与Volcano的集成，以便更好地为分布式应用提供Gang Scheduling能力。相关issue：
- Support custom scheduler to enable gang scheduling
  我们热忱欢迎更多优秀的开源项目与Volcano携手，共同构建和繁荣云原生批量计算生态。
拓展异构硬件支持与合作：加强与硬件生态伙伴的合作，如昇腾（Ascend）的Device Plugin和DRA Driver的适配与优化，以及与主流GPU厂商在DRA Driver上的协作，确保Volcano能高效、稳定地调度和管理各类前沿异构加速器资源。
JobFlow工作流能力提升：持续优化Volcano内置的轻量级工作流引擎JobFlow。计划增强其在复杂作业依赖管理、状态监控、错误处理及用户自定义扩展等方面的能力，为用户提供更强大、更易用的工作流编排解决方案。相关issue：
- Support JobFlowTemplate CRD
- Enhance JobFlow Functionality
引入Volcano调度模拟器，提升调度透明度与可测试性：为提升调度过程的透明度并简化测试验证，Volcano计划引入调度模拟器。这一工具将允许用户在轻量级环境中，通过灵活配置模拟集群状态（节点、Pod、队列配置等），精准复现Volcano核心调度流程——从队列选择、节点过滤与打分到最终绑定。通过输出详尽的调度日志及可选的性能分析，模拟器将极大地便利开发者测试新特性，帮助用户深入理解和验证Volcano在不同场景下的调度行为，并高效评估各类调度策略的实际影响。相关issue：
- Implement Volcano Scheduler Simulator

社区参与

以上 Roadmap 为社区的初步规划。我们欢迎开发者和用户通过以下渠道参与讨论，为 Volcano 的发展贡献新的想法和建议。

GitHub Issues: 在 Volcano GitHub 仓库中创建 kind/feature 类型的 Issue，详细说明您的使用场景和功能期望。
社区交流: 参与社区会议，或在微信交流群/Slack 频道及邮件列表中发起讨论，与开发者和社区成员进行交流。
Roadmap 共建: 针对我们提出的 Roadmap 或您认为重要的其他特性，欢迎随时提出建议。

致谢贡献者

Volcano v1.12 版本包含了来自43位社区贡献者的上百次代码提交，在此对各位贡献者表示由衷的感谢，贡献者GitHub ID：

@AdamKorcz	@HalfBuddhist	@Hcryw
@JackyTYang	@JesseStutler	@MondayCha
@Monokaix	@Poor12	@SataQiu
@Wang-Kai	@archlitchi	@baddoub
@cnmcavoy	@co63oc	@de6p
@dongjiang1989	@ecosysbin	@fengruotj
@feyounger	@fjq123123	@googs1025
@guoqinwill	@halcyon-r	@hansongChina
@hiwangzhihui	@hwdef	@kingeasternsun
@linuxfhy	@mahdikhashan	@mahmut-Abi
@murali1539	@ouyangshengjia	@qGentry
@sailorvii	@sceneryback	@sfc-gh-raravena
@wangyang0616	@weapons97	@xieyanke
@ytcisme	@yuyue9284	@zedongh
@zhutong196

GPU虚拟化

Thu, 29 May 2025 00:00:00 +0000

背景

随着AI应用的日益普及，对GPU的需求也随之激增。GPU作为模型训练与推理任务的核心组件，其重要性不言而喻。然而，GPU成本高昂，如何在云原生环境下最大化其利用率，已成为业界关注的焦点。在实际应用中，常出现以下情况：对于小型工作负载，单个GPU可能造成资源浪费；而对于大型工作负载，单个GPU的算力又可能未被充分挖掘。

为应对这一挑战，Volcano通过提供强大的虚拟GPU (vGPU)调度能力，实现了物理GPU在多个容器和作业间的有效共享。这不仅能显著提升GPU利用率、降低运营成本，也为各类AI/ML工作负载带来了更灵活的资源调度方案。

Volcano致力于简化GPU虚拟化的复杂度，使用户能便捷地运用这些高级共享机制。用户只需在Pod或作业的配置中声明所需的GPU资源及期望的切分方式，Volcano便能自动完成底层的资源编排工作。

Volcano主要支持以下两种GPU共享模式，用以实现vGPU调度并满足不同的硬件能力与性能需求：

1. HAMI-core（基于软件的vGPU）

描述：通过VCUDA (一种CUDA API劫持技术) 对GPU核心与显存的使用进行限制，从而实现软件层面的虚拟GPU切片。

使用场景：适用于需要细粒度GPU共享的场景，兼容所有类型的GPU。

2. Dynamic MIG（硬件级GPU切片）

描述：采用NVIDIA的MIG (Multi-Instance GPU)技术，可将单个物理GPU分割为多个具备硬件级性能保障的隔离实例。

使用场景：尤其适用于对性能敏感的工作负载，要求GPU支持MIG特性（如A100、H100系列）。

Dynamic MIG的设计文档请参考：dynamic-mig

GPU共享模式属于节点级别的配置。Volcano支持异构集群，即集群中可同时包含采用HAMI-core模式的节点和采用Dynamic MIG模式的节点。更多配置及详情，请参阅volcano-vgpu-device-plugin。

安装

若需启用vGPU调度功能，请根据所选模式配置以下组件：

通用要求

环境依赖：

NVIDIA驱动 > 440
nvidia-docker > 2.0
Docker已配置nvidia为默认运行时
Kubernetes >= 1.16
Volcano >= 1.9
安装Volcano：
- 具体步骤请参照Volcano安装指南。
安装设备插件：
- 部署volcano-vgpu-device-plugin。

说明：vgpu设备插件的YAML文件中亦包含节点GPU模式及MIG实例规格等相关配置。详情请参阅vgpu设备插件配置文档。

验证部署：请确保节点的可分配资源（Allocatable Resources）中包含以下信息：


  volcano.sh/vgpu-memory: "89424"
  volcano.sh/vgpu-number: "8"

更新调度器配置：


kind: ConfigMap
apiVersion: v1
metadata:
  name: volcano-scheduler-configmap
  namespace: volcano-system
data:
  volcano-scheduler.conf: |
    actions: "enqueue, allocate, backfill"
    tiers:
    - plugins:
      - name: predicates
      - name: deviceshare
        arguments:
          deviceshare.VGPUEnable: true   # 启用vgpu插件
          deviceshare.SchedulePolicy: binpack  # 调度策略：binpack / spread

可通过以下命令检查：

kubectl get node {node-name} -o yaml

HAMI-core使用方法

Pod配置示例：


metadata:
  name: hami-pod
  annotations:
    volcano.sh/vgpu-mode: "hami-core"
spec:
  schedulerName: volcano
  containers:
  - name: cuda-container
    image: nvidia/cuda:9.0-devel
    resources:
      limits:
        volcano.sh/vgpu-number: 1    # 请求1张GPU卡
        volcano.sh/vgpu-cores: 50    # (可选)每个vGPU使用50%核心
        volcano.sh/vgpu-memory: 3000 # (可选)每个vGPU使用3G显存

Dynamic MIG使用方法

启用MIG模式：

若需启用MIG (Multi-Instance GPU)模式，请在目标GPU节点上执行以下命令：

sudo nvidia-smi -mig 1

MIG实例规格配置（可选）：

volcano-vgpu-device-plugin会自动生成一套初始MIG配置，并存储于kube-system命名空间下的volcano-vgpu-device-config ConfigMap中。用户可按需自定义此配置。更多详情请参阅vgpu设备插件YAML文件。

带MIG注解的Pod配置示例：


metadata:
  name: mig-pod
  annotations:
    volcano.sh/vgpu-mode: "mig"
spec:
  schedulerName: volcano
  containers:
  - name: cuda-container
    image: nvidia/cuda:9.0-devel
    resources:
      limits:
        volcano.sh/vgpu-number: 1
        volcano.sh/vgpu-memory: 3000

注意：实际分配的显存大小取决于最匹配的MIG实例规格（例如：请求3GB显存，可能会分配到规格为5GB的MIG实例）。

调度器模式选择

显式指定模式：
- 通过Pod注解volcano.sh/vgpu-mode来强制指定HAMI-core或MIG模式。
- 若未指定该注解，调度器将依据资源匹配度及预设策略自动选择合适的模式。
调度策略影响：
- 调度策略（如binpack或spread）会影响vGPU Pod在节点间的分布。

总结表

模式	隔离级别	是否依赖MIG GPU	需注解指定模式	核心/显存控制方式	推荐应用场景
HAMI-core	软件 (VCUDA)	否	否	用户自定义 (核心/显存)	通用型工作负载
Dynamic MIG	硬件 (MIG)	是	是	MIG实例规格决定	对性能敏感的工作负载

监控

调度器监控指标：

curl http://<volcano-scheduler-ip>:8080/metrics

设备插件监控指标：

curl http://<plugin-pod-ip>:9394/metrics

监控指标包括GPU利用率、各Pod的显存使用量及限制等。

问题和贡献

提交Issue：Volcano Issues
贡献代码：Pull Request指南

GPU虚拟化

Thu, 29 May 2025 00:00:00 +0000

背景

Volcano主要支持以下两种GPU共享模式，用以实现vGPU调度并满足不同的硬件能力与性能需求：

1. HAMI-core（基于软件的vGPU）

描述：通过VCUDA (一种CUDA API劫持技术) 对GPU核心与显存的使用进行限制，从而实现软件层面的虚拟GPU切片。

使用场景：适用于需要细粒度GPU共享的场景，兼容所有类型的GPU。

2. Dynamic MIG（硬件级GPU切片）

描述：采用NVIDIA的MIG (Multi-Instance GPU)技术，可将单个物理GPU分割为多个具备硬件级性能保障的隔离实例。

使用场景：尤其适用于对性能敏感的工作负载，要求GPU支持MIG特性（如A100、H100系列）。

Dynamic MIG的设计文档请参考：dynamic-mig

GPU共享模式属于节点级别的配置。Volcano支持异构集群，即集群中可同时包含采用HAMI-core模式的节点和采用Dynamic MIG模式的节点。更多配置及详情，请参阅volcano-vgpu-device-plugin。

安装

若需启用vGPU调度功能，请根据所选模式配置以下组件：

通用要求

环境依赖：

NVIDIA驱动 > 440
nvidia-docker > 2.0
Docker已配置nvidia为默认运行时
Kubernetes >= 1.16
Volcano >= 1.9
安装Volcano：
- 具体步骤请参照Volcano安装指南。
安装设备插件：
- 部署volcano-vgpu-device-plugin。

说明：vgpu设备插件的YAML文件中亦包含节点GPU模式及MIG实例规格等相关配置。详情请参阅vgpu设备插件配置文档。

验证部署：请确保节点的可分配资源（Allocatable Resources）中包含以下信息：


  volcano.sh/vgpu-memory: "89424"
  volcano.sh/vgpu-number: "8"

更新调度器配置：


kind: ConfigMap
apiVersion: v1
metadata:
  name: volcano-scheduler-configmap
  namespace: volcano-system
data:
  volcano-scheduler.conf: |
    actions: "enqueue, allocate, backfill"
    tiers:
    - plugins:
      - name: predicates
      - name: deviceshare
        arguments:
          deviceshare.VGPUEnable: true   # 启用vgpu插件
          deviceshare.SchedulePolicy: binpack  # 调度策略：binpack / spread

可通过以下命令检查：

kubectl get node {node-name} -o yaml

HAMI-core使用方法

Pod配置示例：


metadata:
  name: hami-pod
  annotations:
    volcano.sh/vgpu-mode: "hami-core"
spec:
  schedulerName: volcano
  containers:
  - name: cuda-container
    image: nvidia/cuda:9.0-devel
    resources:
      limits:
        volcano.sh/vgpu-number: 1    # 请求1张GPU卡
        volcano.sh/vgpu-cores: 50    # (可选)每个vGPU使用50%核心
        volcano.sh/vgpu-memory: 3000 # (可选)每个vGPU使用3G显存

Dynamic MIG使用方法

启用MIG模式：

若需启用MIG (Multi-Instance GPU)模式，请在目标GPU节点上执行以下命令：

sudo nvidia-smi -mig 1

MIG实例规格配置（可选）：

带MIG注解的Pod配置示例：


metadata:
  name: mig-pod
  annotations:
    volcano.sh/vgpu-mode: "mig"
spec:
  schedulerName: volcano
  containers:
  - name: cuda-container
    image: nvidia/cuda:9.0-devel
    resources:
      limits:
        volcano.sh/vgpu-number: 1
        volcano.sh/vgpu-memory: 3000

注意：实际分配的显存大小取决于最匹配的MIG实例规格（例如：请求3GB显存，可能会分配到规格为5GB的MIG实例）。

调度器模式选择

显式指定模式：
- 通过Pod注解volcano.sh/vgpu-mode来强制指定HAMI-core或MIG模式。
- 若未指定该注解，调度器将依据资源匹配度及预设策略自动选择合适的模式。
调度策略影响：
- 调度策略（如binpack或spread）会影响vGPU Pod在节点间的分布。

总结表

模式	隔离级别	是否依赖MIG GPU	需注解指定模式	核心/显存控制方式	推荐应用场景
HAMI-core	软件 (VCUDA)	否	否	用户自定义 (核心/显存)	通用型工作负载
Dynamic MIG	硬件 (MIG)	是	是	MIG实例规格决定	对性能敏感的工作负载

监控

调度器监控指标：

curl http://<volcano-scheduler-ip>:8080/metrics

设备插件监控指标：

curl http://<plugin-pod-ip>:9394/metrics

监控指标包括GPU利用率、各Pod的显存使用量及限制等。

问题和贡献

提交Issue：Volcano Issues
贡献代码：Pull Request指南

Volcano v1.11.0正式发布

Fri, 07 Feb 2025 00:00:00 +0000

Volcano v1.11 重磅发布！开启AI与大数据的云原生调度新纪元

作为云原生批量计算领域的事实标准，Volcano已经在AI、Big Data及高性能计算 (HPC) 等多种场景中获得广泛应用，吸引了来自30多个国家的800多名贡献者，累计代码提交数万次。Volcano已在国内外60+企业进行了生产落地，经受住了实际生产环境的考验，赢得了用户的广泛赞誉，为业界提供了云原生批量计算的卓越实践标准与解决方案。

随着用户使用场景的日益复杂，以及对资源利用率极致追求，特别是在AI大模型场景下，对训练与推理任务的性能、GPU资源利用率、可用性提出了更高的要求，促使Volcano不断拓展其应用场景，深入解决用户的核心诉求。Volcano目前的版本历程里共发布了28个release，针对批量计算的场景做了一系列功能增强和优化，帮助用户更好的将业务迁移到云原生平台，解决了诸多痛点问题，赢得了用户的广泛的喜爱与好评，用户与社区之间也形成了良好的互动，approver和reviewer数量累计发展了30+，达成了双赢互利的局面。

值此2025新年之际，Volcano新版本将会是一个新的里程碑，社区将在2025年引入一系列重大特性，继续深耕CNAI(Cloud Native AI 云原生AI)和大数据等领域，主要特性包括：

AI场景:

网络拓扑感知调度: 降低训练任务间的网络传输开销，优化大模型训练场景下的性能。
NPU卡调度和虚拟化能力: 提升NPU资源利用率。
GPU卡动态切分能力: 提供MIG与MPS动态切分能力，提升GPU资源利用率。
Volcano Global多集群AI作业调度: 支持跨集群的AI任务部署与拆分。
断点续训与故障恢复能力优化: 支持更细粒度的作业重启策略。
支持DRA：支持动态资源分配，灵活高效的管理异构资源。

大数据场景:

弹性层级队列能力: 帮助用户将大数据业务丝滑迁移到云原生平台。

微服务场景：

在离线混部与动态资源超卖: 提升资源利用率，同时保障在线业务QoS。
负载感知调度与重调度: 提供资源碎片整理和负载均衡能力。

Volcano v1.11的正式发布，标志着云原生批量计算迈入全新阶段！本次更新聚焦AI与大数据的核心需求，推出网络拓扑感知调度、多集群AI作业调度等重磅特性，显著提升AI训练与推理任务的性能。同时，在离线混部与动态资源超卖及负载感知重调度功能进一步优化资源利用率，确保在线业务的高可用性。此外，弹性层级队列为大数据场景提供了更灵活的调度策略。Volcano v1.11不仅是技术的飞跃，更是云原生批量计算领域的全新标杆！

重磅特性详解

本次发布的v1.11版本针对AI、大数据和资源利用率提升场景提供一系列重磅特性更新，主要包含：

网络拓扑感知调度：优化AI大模型训练性能

在AI大模型训练场景中，模型并行（Model Parallelism）将模型分割到多个节点上，训练过程中这些节点需要频繁进行大量数据交互。此时，节点间的网络传输性能往往成为训练的瓶颈，显著影响训练效率。数据中心的网络类型多样，如InfiniBand (IB)、RoCE、NVSwitch等，且网络拓扑复杂，通常包含多层交换机。两个节点间跨的交换机越少，通信延迟越低，吞吐量越高。因此，用户希望将工作负载调度到具有最高吞吐量和最低延迟的最佳性能域，尽可能减少跨交换机的通信，以加速数据交换，提升训练效率。

为此，Volcano提出了网络拓扑感知调度（Network Topology Aware Scheduling）策略，通过统一的网络拓扑API和智能调度策略，解决大规模数据中心AI训练任务的网络通信性能问题。

统一的网络拓扑API：精准表达网络结构

为了屏蔽数据中心网络类型的差异，Volcano定义了新的CRD HyperNode来表示网络拓扑，提供了标准化的API接口。与传统的通过节点标签（label）表示网络拓扑的方式相比，HyperNode具有以下优势：

语义统一：HyperNode提供了标准化的网络拓扑描述方式，避免了标签方式的语义不一致问题。
层级结构：HyperNode支持树状层级结构，能够更精确地表达实际的网络拓扑。
易于管理：集群管理员可以手动创建HyperNode，或通过网络拓扑自动发现工具维护HyperNode。

一个HyperNode表示一个网络拓扑性能域，通常映射到一个交换机。多个HyperNode通过层级连接，形成树状结构。例如，下图展示了由多个HyperNode构成的网络拓扑：

叶子HyperNode（s0、s1、s2、s3）：子节点为集群中的真实节点。
非叶子HyperNode（s4、s5、s6）：子节点为其他HyperNode。

在这种结构中，节点间的通信效率取决于它们之间的HyperNode层级跨度。例如：

node0和node1同属于s0，通信效率最高。
node1和node2需要跨两层HyperNode（s0→s4→s1），通信效率较低。
node0和node4需要跨三层HyperNode（s0→s4→s6），通信效率最差。

HyperNode配置示例

以下是一个叶子HyperNode和非叶子HyperNode的配置示例：

叶子HyperNode示例：

apiVersion: topology.volcano.sh/v1alpha1
kind: HyperNode
metadata:
  name: s0
spec:
  tier: 1  # HyperNode层级，层级越低通信效率越高
  members: # 子节点列表
  - type: Node  # 子节点类型为Node
    selector:
      exactMatch: # 精确匹配
        name: node-0
  - type: Node
    selector:
      regexMatch: # 正则匹配
        pattern: node-[01]

非叶子HyperNode示例：

apiVersion: topology.volcano.sh/v1alpha1
kind: HyperNode
metadata:
  name: s6
spec:
  tier: 3  # HyperNode层级
  members: # 子节点列表
  - type: HyperNode  # 子节点类型为HyperNode
    selector:
      exactMatch: # 精确匹配
        name: s4
  - type: HyperNode
    selector:
      exactMatch:
        name: s5

基于网络拓扑的感知调度策略

Volcano Job和PodGroup可以通过networkTopology字段设置作业的拓扑约束，支持以下配置：

mode：支持hard和soft两种模式。
- hard：硬约束，作业内的任务必须部署在同一个HyperNode内。
- soft：软约束，尽可能将作业部署在同一个HyperNode下。
highestTierAllowed：与hard模式配合使用，表示作业允许跨到哪层HyperNode部署。

例如，以下配置表示作业只能部署在2层及以下的HyperNode内（如s4或s5），否则作业将处于Pending状态：

spec:
  networkTopology:
    mode: hard
    highestTierAllowed: 2

通过这种调度策略，用户可以精确控制作业的网络拓扑约束，确保作业在满足条件的最佳性能域运行，从而显著提升训练效率。

未来展望

Volcano将持续优化网络拓扑感知调度功能，未来计划：

支持从节点标签自动转换为HyperNode CR，帮助用户迁移到Volcano。
集成底层网络拓扑自动发现工具，简化HyperNode的管理。
提供命令行工具，方便用户查看和管理HyperNode层级结构。

关于Network Topology Awre Scheduling的详细设计与使用指导，请参考

设计文档：Network Topology Aware Scheduling。

使用文档：Network Topology Aware Scheduling | Volcano。

由衷感谢社区开发者: @ecosysbin, @weapons97, @Xu-Wentao,@penggu, @JesseStutler, @Monokaix 对该特性的贡献！

弹性层级队列：灵活的多租户资源管理策略

在多租户场景中，资源分配的公平性、隔离性以及任务优先级控制是核心需求。不同部门或团队通常需要共享集群资源，同时又要确保各自的任务能够按需获得资源，避免资源争用或浪费。为此，Volcano v1.11 引入了弹性层级队列功能，大幅增强了队列的资源管理能力。通过层级队列，用户可以实现更细粒度的资源配额管理、跨层级资源共享与回收，以及灵活的抢占策略，从而构建高效、公平的统一调度平台。同时对于使用YARN的用户，可以使用Volcano无缝将大数据业务迁移到Kubernetes集群之上。

弹性层级队列的核心能力

Volcano的弹性层级队列具备以下关键特性，满足多租户场景下的复杂需求：

支持配置队列层级关系: 用户可以按需创建多级队列，形成树状结构。每个队列可以设置独立的资源配额和优先级，确保资源的合理分配。
跨层级资源共享与回收: 子队列资源空闲时，可以将资源共享给兄弟队列，当子队列提交任务时，可以从兄弟队列回收资源。
细粒度的资源配额管理: 每个队列可以设置以下资源参数：
- capability：队列的资源容量上限。
- deserved：队列应得的资源量。如果队列已分配的资源超过deserved值，超出的部分可以被回收。
- guarantee：队列的资源预留量，这部分资源不会被其他队列共享，确保队列的最低资源保障。
灵活的抢占策略: 支持基于优先级的资源抢占，确保高优先级任务能够及时获得所需资源。

层级队列示意图

以下是一个简单的层级队列结构示例：

根队列：作为所有队列的父队列，负责全局资源的分配与管理。
部门队列：隶属于根队列，代表不同部门或团队的资源池。
子队列：隶属于部门队列，代表具体的项目或任务，用户可以将作业提交到叶子队列。

适用场景

多部门资源共享：在大型企业中，不同部门共享同一个集群，通过层级队列实现资源的公平分配与隔离。
大数据任务调度：从YARN迁移到Kubernetes的用户，可以利用Volcano的层级队列功能，无缝迁移大数据业务。
AI训练与推理：在AI场景中，不同训练任务或推理服务可以通过层级队列实现资源的动态分配与回收。

关于弹性层级队列详细设计与使用指导，请参考:

设计文档: hierarchical-queue-on-capacity-plugin。

使用文档: Hierarchica Queue | Volcano。

由衷感谢社区开发者: @Rui-Gan 对该特性的贡献！

多集群AI作业调度：跨集群的统一管理与高效调度

随着企业业务的快速增长，单个 Kubernetes 集群通常无法满足大规模 AI 训练和推理任务的需求。用户通常需要管理多个 Kubernetes 集群，以实现统一的工作负载分发、部署和管理。目前，已经有许多用户在多个集群中使用 Volcano，并使用 Karmada 进行管理。为了更好地支持多集群环境中的 AI 任务，支持全局队列管理、任务优先级和公平调度等功能，Volcano 社区孵化了 Volcano Global子项目。该项目将 Volcano 在单个集群中的强大调度能力扩展到多集群场景，为多集群 AI 任务提供统一的调度平台，支持跨集群任务分发、资源管理和优先级控制。

Volcano Global 在 Karmada 的基础上提供了以下增强功能，以满足多集群 AI 任务调度的复杂需求：

核心能力

Volcano Global在Karmada的基础上，提供了以下增强功能，满足多集群AI作业调度的复杂需求：

支持Volcano Job的跨集群调度：用户可以在多集群环境中部署和调度Volcano Job，充分利用多个集群的资源，提升任务执行效率。
队列优先级调度：支持跨集群的队列优先级管理，确保高优先级队列的任务能够优先获得资源。
作业优先级调度与排队：在多集群环境中，支持作业级别的优先级调度和排队机制，确保关键任务能够及时执行。
多租户公平调度：提供跨集群的多租户公平调度能力，确保不同租户之间的资源分配公平合理，避免资源争用。

关于Volcano Global的详细部署和使用指导，请参考: Multi-Cluster AI Job Scheduling | Volcano。

由衷感谢社区开发者: @Vacant2333, @MondayCha, @lowang-bh, @Monokaix 对该特性的贡献！

在离线混部与动态资源超卖：最大化资源利用率，保障业务稳定性

背景：资源利用率的挑战

随着云原生技术的快速发展，Kubernetes已成为云原生时代的“操作系统”，越来越多的业务迁移到Kubernetes平台。然而，尽管云原生技术带来了灵活性和可扩展性，数据中心的资源利用率仍然较低。在线业务（如微服务）通常具有明显的波峰波谷特征，在波谷时段，大量资源处于闲置状态，而在波峰时段，资源又可能不足。为了提升资源利用率并保障高优先级业务的SLO（Service Level Objective），Volcano推出了云原生混部解决方案，通过在离线混部与动态资源超卖，最大化集群资源利用率，同时确保在线业务的稳定性。

云原生混部的核心思想是将在线业务（如实时服务）和离线业务（如批处理任务）部署在同一个集群中。当在线业务处于波谷时，离线业务可以利用闲置资源；当在线业务达到波峰时，通过优先级控制压制离线业务，确保在线业务的资源需求。这种动态资源分配机制不仅提升了资源利用率，还保障了在线业务的服务质量。

业界实践：Volcano的独特优势

业界已有许多公司和用户对在离线混部技术进行了探索与实践，但仍存在一些不足，比如不能做到和Kubernetes完全解耦，超卖资源计算方式粗糙，在离线作业使用方式不一致、用户体验不友好等问题。

基于这些问题，Volcano对在离线混部技术进行了深度优化，具备以下独特优势：

天然支持离线作业调度：Volcano Scheduler原生支持离线作业的调度与管理，无需额外适配。
无侵入式设计：对Kubernetes无侵入式修改，用户无需调整现有集群架构即可使用。
动态资源超卖：实时计算节点的可超卖资源，确保资源利用与业务QoS的平衡。
OS层面的隔离与保障：通过内核级别的资源隔离机制，确保在线业务的优先级和稳定性。

Volcano云原生混部解决方案：端到端的资源优化

Volcano的云原生混部解决方案从应用层到内核提供了端到端的资源隔离与共享机制，主要包括以下核心组件：

Volcano Scheduler：负责在离线作业的统一调度，提供队列、组、作业优先级、公平调度、资源预留等多种抽象，满足微服务、大数据、AI等多种业务场景的调度需求。

Volcano SLO Agent：每个节点上部署的SLO Agent实时监控节点的资源使用情况，动态计算可超卖的资源，并将这些资源分配给离线作业。同时，SLO Agent会检测节点的CPU/内存压力，在必要时驱逐离线作业，保障在线业务的优先级。

Enhanced OS：为了进一步强化资源隔离，Volcano在内核层面实现了精细化的QoS保障。通过cgroup接口，为在线和离线业务设置不同的资源限制，确保在线业务在高负载时仍能获得足够的资源。

架构

核心能力：资源利用与业务保障的双赢

Volcano云原生混部解决方案具备以下关键能力，帮助用户实现资源利用与业务稳定性的双赢：

统一调度：支持多种工作负载的统一调度，包括微服务、批处理作业和AI任务。
基于QoS的资源模型：为在线和离线业务提供基于服务质量（QoS）的资源管理，确保高优先级业务的稳定性。
动态资源超卖：根据节点的实时CPU/内存利用率，动态计算可超卖的资源，最大化资源利用率。
CPU Burst：允许容器临时超出CPU限制，避免在关键时刻被限流，提升业务响应速度。
网络带宽隔离：支持整机网络出口带宽限制，保障在线业务的网络使用需求。

关于Volcano云原生混部的详细设计和使用文档，请参考: Cloud Native Colocation | Volcano。

由衷感谢社区开发者: @william-wang 对该特性的贡献！

负载感知重调度：智能均衡集群资源，告别资源热点

在Kubernetes集群中，随着工作负载的动态变化，节点资源利用率不均衡的问题时常发生，导致部分节点过热，影响整体集群的稳定性与效率。为了解决这一问题，Volcano v1.11 引入了负载感知重调度功能，基于节点的真实负载动态调整Pod分布，确保集群资源的均衡利用，避免资源热点，提升集群的整体性能与可靠性。负载感知重调度通过子项目 descheduler 孵化。

核心能力：

真实负载感知调度：通过监控节点的CPU、内存等真实负载指标，动态调整Pod分布，避免仅依赖Pod Request的粗糙调度。
定时与动态触发：支持按CronTab定时任务或固定时间间隔触发重调度，灵活适应不同场景需求。

适用场景：

节点资源不均衡：当集群中部分节点资源利用率过高，而其他节点资源闲置时，负载感知重调度可自动平衡节点负载。
热点节点治理：当节点因高负载出现性能瓶颈或故障风险时，重调度可及时迁移Pod，保障业务稳定性。

技术亮点：

基于真实负载的重调度：相比传统的基于Pod Request的调度策略，Volcano的负载感知重调度更加精准，能够真实反映节点的资源使用情况。
无缝集成Kubernetes生态：与Kubernetes原生调度器兼容，无需额外配置即可实现负载感知重调度。
灵活的策略配置：用户可根据业务需求，自定义重调度的时间间隔或触发条件，确保调度的灵活性与可控性。

关于负载感知重调度的使用说明，请参考: Load-aware Descheduling | Volcano。

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

细粒度的作业故障恢复策略：高效应对任务中断，提升训练效率

在AI、大数据和高性能计算（HPC）场景中，作业的稳定性和故障恢复能力至关重要。传统的作业故障恢复策略通常会在某个Pod失败时重启整个Job，这不仅浪费资源，还可能导致训练任务从头开始，严重影响效率。随着AI场景中断点续训和Checkpoint技术的普及，单个Pod的失败不再需要重启整个Job。为此，Volcano v1.11 引入了细粒度的作业故障恢复策略，支持更灵活的故障处理机制，帮助用户高效应对任务中断，显著提升训练效率。

核心能力：

支持Pod粒度的重启策略

用户可以根据需求，设置仅重启失败的Pod或所属的Task，避免不必要的Job重启，减少资源浪费。

重启单个Pod：当某个Pod失败时，仅重启该Pod，不影响其他正常运行的任务。
```
policies:
- event: PodFailed
action: RestartPod
```
重启整个Task：当某个Pod失败时，重启该Pod所属的Task（一组Pod），适用于需要保持任务组一致性的场景。
```
policies:
- event: PodFailed
action: RestartTask
```

支持为Action设置超时时间

Pod失败可能是由临时性故障（如网络抖动或硬件问题）引起的，Volcano允许用户为故障恢复动作设置超时时间。如果在超时时间内Pod恢复正常，则不再执行重启操作，避免过度干预。

示例配置：若Pod失败后重启，10分钟内仍未恢复，则重启整个Job。

policies:
- event: PodFailed
action: RestartPod
- event: PodEvicted
action: RestartJob
timeout: 10m

新增PodPending事件处理

当Pod因资源不足或拓扑约束长期处于Pending状态时，用户可以为Pending事件设置超时时间。若超时后Pod仍未运行，则可以选择终止整个Job，避免资源浪费。

示例配置：若Pod处于Pending状态超过10分钟，则终止Job。
```
policies:
- event: PodPending
action: TerminateJob
timeout: 10m
```

适用场景：

AI大模型训练：在分布式训练中，单个Pod的失败不会影响整体训练进度，通过细粒度的故障恢复策略，可以快速恢复任务，避免从头开始训练。
大数据处理：在批处理任务中，部分任务的失败可以通过重启单个Pod或Task解决，无需重启整个作业，提升处理效率。
高性能计算：在HPC场景中，任务的稳定性和高效恢复至关重要，细粒度的故障恢复策略可以最大限度地减少任务中断时间。

技术亮点：

灵活的策略配置：用户可以根据业务需求，自定义故障恢复策略，支持Pod、Task和Job级别的重启操作。
超时机制：通过设置超时时间，避免因临时性故障导致的过度重启行为，提升作业的稳定性。
无缝兼容断点续训：与AI场景中的断点续训和Checkpoint技术完美结合，确保训练任务的高效恢复。

关于Volcano Job的详细设计和说明文档，请参考: How to use job policy。

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

Volcano Dashboard：资源管理的可视化利器

Volcano dashboard是Volcano官方提供的资源展示仪表盘，用户在部署Volcano后，再部署Volcano dashboard，就可以通过图形界面展示集群中Volcano相关的资源，方便用户查询和操作，项目地址: https://github.com/volcano-sh/dashboard

目前支持的功能有：

支持查看集群总览，包括Job数量、状态、完成率，Queue数量，Queue的资源利用率等。
支持查看Job列表和详情，支持模糊搜索匹配，支持按照Namespace、Queue、Status等条件过滤，支持Job排序展示。
支持查看Queue列表和详情，支持模糊搜索匹配，支持按照Status等条件过滤，支持Queue排序展示。
支持查看Pod的列表和详情，支持模糊搜索匹配，支持按照Namespace、Status等条件过滤，支持Pod排序展示。

由衷感谢社区开发者: @WY-Dev0, @Monokaix 对该特性的贡献！

Volcano支持Kubernetes v1.31

Volcano版本紧跟Kubernetes社区版本节奏，对Kubernetes的每个大版本都进行支持，目前最新支持的版本为v1.31，并运行了完整的UT、E2E用例，保证功能和可靠性。

如果您想参与Volcano适配Kubernetes新版本的开发工作，请参考：adapt-k8s-todo进行社区贡献。

由衷感谢社区开发者: @vie-serendipity, @dongjiang1989 对该特性的贡献！

Volcano Job支持Preemption Policy

PriorityClass可以表示Pod的优先级，包含一个优先级数值和抢占策略，在调度和抢占的过程中，PriorityClass会被用来作为调度和抢占的依据，高优先级的Pod先于低优先级Pod调度，并且可以抢占低优先级的Pod，Volcano在Pod层面完整支持优先级调度和抢占策略，在Volcano Job层面支持基于priorityClass value的优先级调度和抢占。但在某些场景下，用户希望Volcano Job不通过抢占触发资源回收，而是等待集群资源自动释放，从而整体保障业务稳定性，Volcano在新版本支持了Job级别的PreemptionPolicy，配置了PreemptionPolicy为Never的Volcano Job不会抢占其他Pod。

Volcano Job和Job内的task同时支持配置PriorityClass，关于两个PriorityClass的配合关系以及配置样例请参考: how to configure priorityclass for job。

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

性能优化：大规模场景下的高效调度

在Volcano中，Queue是最基本且最重要的资源之一。Queue的status字段记录了其中状态为Unknown、Pending、Running、Inqueue、Completed的PodGroup。然而，在大规模场景下，当队列中的PodGroup频繁发生变化时（例如，队列中循环提交大量运行时间较短的任务），会导致大量PodGroup状态从Running变为Completed。这种情况下，Volcano Controller需要频繁刷新Queue的status字段，给APIServer带来较大压力。此外，Volcano Scheduler在Job调度完成后会更新Queue的status.allocated字段，这在大规模场景下可能导致Queue更新冲突，进一步影响系统性能。

为了彻底解决大规模场景下Queue频繁刷新和更新冲突的问题，Volcano v1.11 对Queue的管理机制进行了优化，将Queue中PodGroup的统计数据迁移到指标（Metrics）中，不再进行持久化存储。这一优化显著降低了APIServer的压力，同时提升了系统的整体性能和稳定性。

优化后的核心改进

PodGroup统计数据迁移到指标Queue中的PodGroup状态数据（如Unknown、Pending、Running等）不再存储在Queue的status字段中，而是通过指标系统进行记录和展示。用户可以通过以下命令查看Queue中PodGroup的统计数据：

查看指定队列的统计数据：
```
vcctl queue get -n [name]
```
查看所有队列的统计数据：
```
vcctl queue list
```

减少APIServer压力通过将PodGroup统计数据迁移到指标中，避免了频繁更新Queue的status字段，显著降低了APIServer的负载，提升系统吞吐。

解决Queue更新冲突在大规模场景下，Queue的更新冲突问题得到了有效缓解，确保了调度器的高效运行。

关于Queue中PodGroup的状态统计数据迁移到指标的详细设计以及指标名称，请参考: Queue podgroup statistics。

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

总结：Volcano v1.11，云原生批量计算的新标杆

Volcano v1.11不仅是技术的飞跃，更是云原生批量计算领域的全新标杆。无论是AI大模型训练、大数据调度，还是资源利用率的提升，Volcano v1.11都提供了强大的功能和灵活的解决方案。我们相信，Volcano v1.11将帮助用户在云原生批量计算领域走得更远、更稳，开启AI与大数据的云原生调度新纪元！

立即体验Volcano v1.11.0，开启高效计算新时代！

v1.11.0 release: https://github.com/volcano-sh/volcano/releases/tag/v1.11.0

致谢贡献者

Volcano v1.11.0 版本包含了来自39位社区贡献者的上百次代码提交，在此对各位贡献者表示由衷的感谢，贡献者GitHub ID：

@QingyaFan	@JesseStutler	@bogo-y
@bibibox	@zedongh	@archlitchi
@dongjiang1989	@william-wang	@fengruotj
@SataQiu	@lowang-bh	@Rui-Gan
@xovoxy	@wangyang0616	@PigNatovsky
@Yanping-io	@lishangyuzi	@hwdef
@bood	@kerthcet	@WY-Dev0
@raravena80	@SherlockShemol	@zhifanggao
@conghuhu	@MondayCha	@vie-serendipity
@Prepmachine4	@Monokaix	@lengrongfu
@jasondrogba	@sceneryback	@TymonLee
@liuyuanchun11	@Vacant2333	@matbme
@lekaf974	@kursataktas	@lut777

多集群AI作业调度

Tue, 21 Jan 2025 00:00:00 +0000

背景

随着企业业务的快速增长，单个 Kubernetes 集群通常无法满足大规模 AI 训练和推理任务的需求。用户通常需要管理多个 Kubernetes 集群，以实现统一的AI工作负载分发、部署和管理。目前，已经有许多用户在多个集群中使用 Volcano，并使用 Karmada 进行管理。为了更好地支持多集群环境中的 AI 任务，支持全局队列管理、任务优先级和公平调度等功能，Volcano 社区孵化了Volcano Global子项目。该项目将 Volcano 在单个集群中的强大调度能力扩展到多集群场景，为多集群 AI 任务提供统一的调度平台，支持跨集群任务分发、资源管理和优先级控制。

功能

Volcano Global在Karmada的基础上，提供了以下增强功能，满足多集群AI作业调度的复杂需求：

支持Volcano Job的跨集群调度 用户可以在多集群环境中部署和调度Volcano Job，充分利用多个集群的资源，提升任务执行效率。
队列优先级调度 支持跨集群的队列优先级管理，确保高优先级队列的任务能够优先获得资源。
作业优先级调度与排队 在多集群环境中，支持作业级别的优先级调度和排队机制，确保关键任务能够及时执行。
多租户公平调度 提供跨集群的多租户公平调度能力，确保不同租户之间的资源分配公平合理，避免资源争用。

架构

Volcano global主要包含两个组件：

Volcano Webhook: 监听ResourceBinding资源的创建事件，将ResourceBinding设置为暂停状态。
Volcano Controller: 监听处于暂停状态的ResourceBinding，根据Job所在队列的优先级、Job本身的优先级，对Job进行优先级和公平调度，并运行资源准入机制，决定是否可以调度Job，准入成功后将ResourceBinding解除暂停状态，由Karmada进行资源分发。

使用指导

请参考: Volcano global deploy。

多集群AI作业调度

Tue, 21 Jan 2025 00:00:00 +0000

背景

功能

Volcano Global在Karmada的基础上，提供了以下增强功能，满足多集群AI作业调度的复杂需求：

支持Volcano Job的跨集群调度 用户可以在多集群环境中部署和调度Volcano Job，充分利用多个集群的资源，提升任务执行效率。
队列优先级调度 支持跨集群的队列优先级管理，确保高优先级队列的任务能够优先获得资源。
作业优先级调度与排队 在多集群环境中，支持作业级别的优先级调度和排队机制，确保关键任务能够及时执行。
多租户公平调度 提供跨集群的多租户公平调度能力，确保不同租户之间的资源分配公平合理，避免资源争用。

架构

Volcano global主要包含两个组件：

Volcano Webhook: 监听ResourceBinding资源的创建事件，将ResourceBinding设置为暂停状态。
Volcano Controller: 监听处于暂停状态的ResourceBinding，根据Job所在队列的优先级、Job本身的优先级，对Job进行优先级和公平调度，并运行资源准入机制，决定是否可以调度Job，准入成功后将ResourceBinding解除暂停状态，由Karmada进行资源分发。

使用指导

请参考: Volcano global deploy。

多集群AI作业调度

Tue, 21 Jan 2025 00:00:00 +0000

背景

功能

Volcano Global在Karmada的基础上，提供了以下增强功能，满足多集群AI作业调度的复杂需求：

支持Volcano Job的跨集群调度 用户可以在多集群环境中部署和调度Volcano Job，充分利用多个集群的资源，提升任务执行效率。
队列优先级调度 支持跨集群的队列优先级管理，确保高优先级队列的任务能够优先获得资源。
作业优先级调度与排队 在多集群环境中，支持作业级别的优先级调度和排队机制，确保关键任务能够及时执行。
多租户公平调度 提供跨集群的多租户公平调度能力，确保不同租户之间的资源分配公平合理，避免资源争用。

架构

Volcano global主要包含两个组件：

Volcano Webhook: 监听ResourceBinding资源的创建事件，将ResourceBinding设置为暂停状态。
Volcano Controller: 监听处于暂停状态的ResourceBinding，根据Job所在队列的优先级、Job本身的优先级，对Job进行优先级和公平调度，并运行资源准入机制，决定是否可以调度Job，准入成功后将ResourceBinding解除暂停状态，由Karmada进行资源分发。

使用指导

请参考: Volcano global deploy。

网络拓扑感知调度

Tue, 21 Jan 2025 00:00:00 +0000

背景

在AI大模型训练场景中，模型并行（Model Parallelism）将模型分割到多个节点上，训练过程中这些节点需要频繁进行大量数据交互。此时，节点间的网络传输性能往往成为训练的瓶颈，显著影响训练效率。数据中心的网络类型多样（如IB、RoCE、NVSwitch等），且网络拓扑复杂，通常包含多层交换机。两个节点间跨的交换机越少，通信延迟越低，吞吐量越高。因此，用户希望将工作负载调度到具有最高吞吐量和最低延迟的最佳性能域，尽可能减少跨交换机的通信，以加速数据交换，提升训练效率。

功能

统一的网络拓扑API：精准表达网络结构

语义统一：HyperNode提供了标准化的网络拓扑描述方式，避免了标签方式的语义不一致问题。
层级结构：HyperNode支持树状层级结构，能够更精确地表达实际的网络拓扑。
易于管理：集群管理员可以手动创建HyperNode，或通过网络拓扑自动发现工具维护HyperNode。

一个HyperNode表示一个网络拓扑性能域，通常映射到一个交换机或者Tor。多个HyperNode通过层级连接，形成树状结构。例如，下图展示了由多个HyperNode构成的网络拓扑：

叶子HyperNode（s0、s1、s2、s3）：子节点类型为集群中的真实节点。
非叶子HyperNode（s4、s5、s6）：子节点类型为其他HyperNode。

在这种结构中，节点间的通信效率取决于它们之间的HyperNode层级跨度。例如：

node0和node1同属于s0，通信效率最高。
node1和node2需要跨两层HyperNode（s0→s4→s1），通信效率较低。
node0和node4需要跨三层HyperNode（s0→s4→s6），通信效率最差。

关键字段

spec.tier: 表示HyperNode的层级，层级越低，则该HyperNode内的节点通信效率越高。
spec.members: HyperNode下面的一组子节点，可以通过selector来匹配关联的子节点。
spec.members[i].type: 子节点的类型，支持Node和HyperNode两种，子节点全部为Node时，代表当前HyperNode为叶子节点，子节点全部为HyperNode时，代表当前节点为非叶子HyperNode。
spec.members[i].selector: 子节点选择器，支持exactMatch，regexMatch，和labelMatch三种selector。
- exactMatch表示精确匹配，子节点需要填写完整的HyperNode或者Node的name，
- regexMatch表示的是正则匹配，与正则表达式匹配的Node都会被当做当前HyperNode的子节点。
- labelMatch表示的是按标签匹配，带有对应标签的节点都会被当做当前HyperNode的子节点，配置示例如:
```
labelMatch:
  matchLabels:
    topology-rack: rack-1
```

注意：regexMatch/labelMatch只能用在叶子HyperNode中，用来匹配集群中的真实节点，也就是说当spec.members[i].selector.type为HyperNode时，不支持regexMatch/labelMatch。

基于网络拓扑的感知调度策略

Volcano Job和PodGroup可以通过networkTopology字段设置作业的拓扑约束，支持以下配置：

mode：支持hard和soft两种模式。
- hard：硬约束，作业内的任务必须部署在同一个HyperNode内。
- soft：软约束，尽可能将作业部署在同一个HyperNode下。
highestTierAllowed：与hard模式配合使用，表示作业允许跨到哪层HyperNode部署，soft模式下无需配置该字段。

例如，以下配置表示作业只能部署在2层及以下的HyperNode内，如s4和s5，以及更低层的tier: s4和s5的子节点s0，s1，s2，s3，否则作业将处于Pending状态：

spec:
  networkTopology:
    mode: hard
    highestTierAllowed: 2

通过这种调度策略，用户可以精确控制作业的网络拓扑约束，确保作业在满足条件的最佳性能域运行，从而显著提升训练效率。

HyperNode自动发现：简化网络拓扑管理

为进一步降低网络拓扑信息的管理负担，Volcano提供了HyperNode自动发现功能。该功能能够自动发现集群内的网络拓扑结构，并根据发现结果自动创建、更新或删除相应的HyperNode自定义资源（CRs）。

自动发现功能具有以下核心优势：

自动化管理：自动从多种数据源（如UFM、RoCE或节点标签）发现和维护HyperNode信息，无需手动维护。
实时同步：定期同步网络拓扑变化，确保HyperNode信息与实际网络状态保持一致。
可扩展架构：支持可插拔的Discoverer组件，用户可针对特定的网络管理工具开发自定义发现逻辑。

通过这一自动化发现机制，用户可以专注于作业调度配置，无需担心HyperNode创建和维护的复杂性，显著简化了网络拓扑感知调度的部署和管理。

使用指导

安装Volcano

Volcano支持以下两种安装方式：

通过Helm安装（推荐）

helm repo add volcano-sh https://volcano-sh.github.io/helm-charts
helm repo update
helm install volcano volcano-sh/volcano -n volcano-system --create-namespace --version 1.12.0

使用YAML文件安装

kubectl apply -f https://raw.githubusercontent.com/volcano-sh/volcano/refs/heads/network-topology/installer/volcano-development.yaml

配置Volcano调度器

要启用网络拓扑感知调度功能，需要修改Volcano调度器的配置文件。以下是一个配置示例，其中同时启用了 network-topology-aware 和 binpack 插件，开启binpack更有助于实现更紧凑的任务调度：

kind: ConfigMap
apiVersion: v1
metadata:
  name: volcano-scheduler-configmap
  namespace: volcano-system
data:
  volcano-scheduler.conf: |
    actions: "enqueue, allocate, backfill"
    tiers:
    - plugins:
      - name: priority
      - name: gang
    - plugins:
      - name: predicates
      - name: proportion
      - name: nodeorder
      - name: binpack # 启用binpack插件，有助于任务的紧凑调度
      # arguments: # 用来配置binpack插件中各项资源的权重以及binpack插件自身的权重
      #   binpack.weight: 10 # binpack插件的权重，影响binpack策略的整体得分
      #   binpack.cpu: 5 # CPU资源的权重，权重越高，CPU资源在打分时的占比越大
      #   binpack.memory: 1 # Memory资源的权重
      #   binpack.resources: nvidia.com/gpu # 指定额外资源类型，如GPU
      #   binpack.resources.nvidia.com/gpu: 2 # GPU的权重
      - name: network-topology-aware # 开启network-topology-aware插件
      # arguments:
      #   weight: 10 # 可以选择设置network-topology-aware的打分权重，默认weight为1

HyperNode CRs管理

HyperNode CRs可以通过自动发现或手动创建两种方式进行管理。

HyperNode自动发现（推荐）

Volcano通过集成可插拔的网络拓扑发现工具（Discoverer）实现HyperNode的自动发现与管理。Discoverer负责定期从外部网络拓扑管理系统（如UFM、RoCE、或基于节点标签等方式）收集网络拓扑信息，并将其转换为标准的HyperNode表示。随后，Volcano内置的HyperNode Controller会根据Discoverer提供的信息，自动创建、更新或删除相应的HyperNode自定义资源（CRs）。这种机制使得Volcano调度器能够利用动态维护的HyperNode CRs进行精准的网络拓扑感知调度，从而免除用户手动创建和维护HyperNode信息的负担，简化网络拓扑管理的复杂性。

Volcano提供了一些通用的Discoverer实现，以适应常见的网络环境。同时，Volcano也支持用户根据自身特定的网络拓扑发现工具和需求，开发自定义的Discoverer插件。

配置

HyperNode自动发现功能通过ConfigMap进行配置。ConfigMap中包含了发现源（如UFM、RoCE和label）的配置，你可以根据自己的集群环境修改配置。

Secret配置（UFM源必需）

如果你的集群底层网络采用InfiniBand (IB) 组网，并由UFM (Unified Fabric Manager) 管理，那么在配置UFM作为发现源时，需要首先创建一个Kubernetes Secret来存储UFM凭据：

kubectl create secret generic ufm-credentials \
  --from-literal=username='your-ufm-username' \
  --from-literal=password='your-ufm-password' \
  -n volcano-system

注意：请将 your-ufm-username 和 your-ufm-password 替换为你的实际UFM凭据，并根据需要调整命名空间。

ConfigMap示例

apiVersion: v1
kind: ConfigMap
metadata:
  name: volcano-controller-configmap
  namespace: volcano-system # 如果Volcano未安装在默认命名空间，请替换为实际的Volcano命名空间。
data:
  volcano-controller.conf: |
    networkTopologyDiscovery:
      - source: ufm
        enabled: true
        interval: 10m
        credentials:
          secretRef:
            name: ufm-credentials # 替换为存储UFM凭据的Secret名称。
            namespace: volcano-system #替换为存储UFM凭据的Secret的命名空间。
        config:
          endpoint: https://ufm-server:8080
          insecureSkipVerify: true
      - source: roce
        enabled: false
        interval: 15m
        config:
          endpoint: https://roce-server:9090
      - source: label
        enabled: true
        config:
          networkTopologyTypes:
            topologyA2:
              - nodeLabel: "volcano.sh/tor" # 用于指示节点所属交换机（tor）的标签。如果不同节点上该标签对应的取值相同，则表示这些节点属于同一台交换机（tor）。
              - nodeLabel: "kubernetes.io/hostname" # Kubernetes 集群中自动添加到每个节点的标准标签，用于标识节点的主机名。
            topologyA3:
              - nodeLabel: "volcano.sh/hypercluster" # 用于指示节点所属超集群（hypercluster）的标签。如果不同节点上该标签对应的取值相同，则表示这些节点属于同一个超集群（hypercluster）。
              - nodeLabel: "volcano.sh/hypernode" # 用于指示节点所属超节点（hypernode）的标签。如果不同节点上该标签对应的取值相同，则表示这些节点属于同一个超节点（hypernode）。
              - nodeLabel: "kubernetes.io/hostname" # Kubernetes 集群中自动添加到每个节点的标准标签，用于标识节点的主机名。

配置选项

source: 发现源，例如 ufm。
enabled: 是否启用该发现源。
interval: 发现操作之间的时间间隔。如果未指定，则默认值为1小时。
config: 发现源的配置。配置选项因发现源而异。
credentials: 用于访问发现源的凭据配置。
- secretRef: 对包含凭据的Kubernetes Secret的引用。
  - name: Secret的名称。
  - namespace: Secret的命名空间。

UFM配置选项

endpoint: UFM API端点。
insecureSkipVerify: 是否跳过TLS证书验证。这只应在开发环境中使用。

RoCE配置选项（当前不支持）

endpoint: RoCE API端点。
token: RoCE API令牌。

Label配置选项

networkTopologyTypes: 支持不同类型网络拓扑的结构，包括适用于GPU、NPU等的拓扑。以下是NPU集群网络拓扑的示例。
- topologyA2: A2（昇腾 910B）集群的网络拓扑类型
  - nodeLabel: 对于节点上的标签，当存在多个标签时，超节点会自下而上构建。最底层的标签是kubernetes.io/hostname，这是Kubernetes中的标准内置标签键，其上方的标签是volcano.sh/tor，用于指示节点所属的交换机。
- topologyA3: A3（昇腾 910C）集群的网络拓扑类型
  - nodeLabel: 对于节点上的标签，当存在多个标签时，超节点会自下而上构建。最底层的标签是kubernetes.io/hostname，这是Kubernetes中的标准内置标签键，其上方的标签为volcano.sh/hypernode和volcano.sh/hypercluster，volcano.sh/hypernode用于指示节点所属的超节点，volcano.sh/hypercluster用于指示节点所属的超集群。

验证

检查Volcano控制器日志，确保发现源已成功启动。

kubectl logs -n volcano-system -l app=volcano-controllers -c volcano-controllers | grep "Successfully started all network topology discoverers"

检查已创建的HyperNode资源。

kubectl get hypernodes -l volcano.sh/network-topology-source=<source>

将 <source> 替换为你配置的发现源，例如 ufm。

故障排除

如果发现源未成功启动，请检查Volcano控制器日志以获取错误信息。
如果未创建HyperNode资源，请检查发现源配置，并确保发现源能够连接到网络拓扑数据源。

如果用户要实现自己的HyperNode discoverer，请参考：HyperNode Discoverer 开发指南

手动创建HyperNode

如果你的环境中没有可用的网络拓扑自动发现工具，或者你希望更精细地控制HyperNode的定义，可以选择手动创建HyperNode CRs。

仍以图1中的网络拓扑为例，分别创建叶子节点和非叶子节点HyperNode。本样例仅为使用演示，实际需要创建的HyperNode请以集群中的真实拓扑为准。

先创建叶子节点HyperNode s0，s1，s2和s3。

apiVersion: topology.volcano.sh/v1alpha1
kind: HyperNode
metadata:
  name: s0
spec:
  tier: 1 # s0位于tier1
  members:
  - type: Node
    selector:
      exactMatch:
        name: "node-0"
  - type: Node
    selector:
      exactMatch:
        name: "node-1"
---
apiVersion: topology.volcano.sh/v1alpha1
kind: HyperNode
metadata:
  name: s1 # s1位于tier1
spec:
  tier: 1
  members:
  - type: Node
    selector:
      exactMatch:
        name: "node-2"
  - type: Node
    selector:
      exactMatch:
        name: "node-3"
---
apiVersion: topology.volcano.sh/v1alpha1
kind: HyperNode
metadata:
  name: s2 # s2位于tier1
spec:
  tier: 1
  members:
  - type: Node
    selector:
      exactMatch:
        name: "node-4"
  - type: Node
    selector:
      exactMatch:
        name: "node-5"
---
apiVersion: topology.volcano.sh/v1alpha1
kind: HyperNode
metadata:
  name: s3
spec:
  tier: 1 # s3位于tier1
  members:
  - type: Node
    selector:
      exactMatch:
        name: "node-6"
  - type: Node
    selector:
      exactMatch:
        name: "node-7"

然后创建非叶子节点s4，s5和s6。

apiVersion: topology.volcano.sh/v1alpha1
kind: HyperNode
metadata:
  name: s4 # s4位于tier2
spec:
  tier: 2
  members:
  - type: HyperNode
    selector:
      exactMatch:
        name: "s0"
  - type: HyperNode
    selector:
      exactMatch:
        name: "s1"
---
apiVersion: topology.volcano.sh/v1alpha1
kind: HyperNode
metadata:
  name: s5
spec:
  tier: 2 # s5位于tier2
  members:
  - type: HyperNode
    selector:
      exactMatch:
        name: "s2"
  - type: HyperNode
    selector:
      exactMatch:
        name: "s3"
---
apiVersion: topology.volcano.sh/v1alpha1
kind: HyperNode
metadata:
  name: s6
spec:
  tier: 3 # s6位于tier3
  members:
  - type: HyperNode
    selector:
      exactMatch:
        name: "s4"
  - type: HyperNode
    selector:
      exactMatch:
        name: "s5"

部署带有拓扑约束的Job

apiVersion: batch.volcano.sh/v1alpha1
kind: Job
metadata:
  name: mindspore-cpu
spec:
  minAvailable: 3
  schedulerName: volcano
  networkTopology: # 设置network topology约束
    mode: hard
    highestTierAllowed: 2
  queue: default
  tasks:
    - replicas: 3
      name: "pod"
      template:
        spec:
          containers:
            - command: ["/bin/bash", "-c", "python /tmp/lenet.py"]
              image: lyd911/mindspore-cpu-example:0.2.0
              imagePullPolicy: IfNotPresent
              name: mindspore-cpu-job
              resources:
                limits:
                  cpu: "1"
                requests:
                  cpu: "1"
          restartPolicy: OnFailure

由于Job的spec.networkTopology.highestTierAllowed为2，因此期望结果为: 不能部署在3层HyperNode s6内，也就是只能部署到node0-node3，或者node4-node7内，而不能部署在node0-node7内。

注意事项

非叶子节点HyperNode的member selector不支持regexMatch/labelMatch。
regexMatch/exactMatch/labelMatch selector不能同时配置，只能配置一种selector。
HyperNode的member是Node类型，即HypeNode为叶子节点时，不允许再设置类型为HyperNode的member。
叶子节点HyperNode包含了集群中的真实节点，因此使用该特性时必须要创建出叶子HyperNode节点。
HyperNode之间不能有环依赖，否则Job无法正常调度。
一个HyperNode可以有多个子节点，但一个HyperNode最多只能有一个parent HyperNode，否则Job无法正常调度。

最佳实践

Hard模式、Soft模式选择及调度简述

hard模式:
- 作业中的所有任务必须被调度到 spec.networkTopology.highestTierAllowed 定义的单个HyperNode层级（或更低层级）内。如果找不到满足此约束的HyperNode，作业将保持Pending状态。此模式适用于对网络拓扑有严格要求的场景。
soft模式:
- 调度器会尽最大努力将作业中的所有任务调度到同一个HyperNode内，以优化网络性能。但如果无法在单个HyperNode内满足所有任务的资源需求，也允许任务被调度到不同的HyperNode上，以确保作业能够尽快运行。此模式适用于希望优化网络性能，但又能接受一定调度灵活性的场景。
调度插件与基本打分逻辑:
- 网络拓扑感知调度依赖于 network-topology-aware 插件。该插件打分时：
  1. HyperNode的层级越低，得分越高。
  2. 如果多个HyperNode层级相同，则作业在该HyperNode内已成功调度的Pod数量越多，该HyperNode得分越高。

HyperNode自动发现相关实践

Volcano使用 Kubernetes 标准的 Secret 来存储敏感的凭证信息（用户名/密码或令牌）。对于更严格的密钥加密要求，用户应考虑额外的机制，如静态加密Secret数据。
凭证 Secret 可以放置在指定的命名空间中，以实现更好的隔离。
对于UFM发现器，控制器仅需要对包含凭证的特定 Secret 的读取权限。
在生产环境中部署时，应配置适当的RBAC策略以限制对 Secret 的访问。
应在生产环境中启用TLS证书验证以防止中间人攻击。
监控Volcano控制器日志以获取错误信息。
设置合理的发现间隔以避免网络拓扑数据源过载。

网络拓扑感知调度

Tue, 21 Jan 2025 00:00:00 +0000

背景

特性状态: preview

功能

统一的网络拓扑API：精准表达网络结构

语义统一：HyperNode提供了标准化的网络拓扑描述方式，避免了标签方式的语义不一致问题。
层级结构：HyperNode支持树状层级结构，能够更精确地表达实际的网络拓扑。
易于管理：集群管理员可以手动创建HyperNode，或通过网络拓扑自动发现工具维护HyperNode。

叶子HyperNode（s0、s1、s2、s3）：子节点类型为集群中的真实节点。
非叶子HyperNode（s4、s5、s6）：子节点类型为其他HyperNode。

在这种结构中，节点间的通信效率取决于它们之间的HyperNode层级跨度。例如：

node0和node1同属于s0，通信效率最高。
node1和node2需要跨两层HyperNode（s0→s4→s1），通信效率较低。
node0和node4需要跨三层HyperNode（s0→s4→s6），通信效率最差。

关键字段

spec.tier: 表示HyperNode的层级，层级越低，则该HyperNode内的节点通信效率越高。
spec.members: HyperNode下面的一组子节点，可以通过selector来匹配关联的子节点。
spec.members[i].type: 子节点的类型，支持Node和HyperNode两种，子节点全部为Node时，代表当前HyperNode为叶子节点，子节点全部为HyperNode时，代表当前节点为非叶子HyperNode。
spec.members[i].selector: 子节点选择器，支持exactMatch和regexMatch两种selector。
- exactMatch表示精确匹配，子节点需要填写完整的HyperNode或者Node的name，
- regexMatch表示的是正则匹配，与正则表达式匹配的Node都会被当做当前HyperNode的子节点。

注意：regexMatch只能用在叶子HyperNode中，用来匹配集群中的真实节点，也就是说当spec.members[i].selector.type为HyperNode时，不支持regexMatch。

基于网络拓扑的感知调度策略

Volcano Job和PodGroup可以通过networkTopology字段设置作业的拓扑约束，支持以下配置：

mode：支持hard和soft两种模式。
- hard：硬约束，作业内的任务必须部署在同一个HyperNode内。
- soft：软约束，尽可能将作业部署在同一个HyperNode下。
highestTierAllowed：与hard模式配合使用，表示作业允许跨到哪层HyperNode部署。

例如，以下配置表示作业只能部署在2层及以下的HyperNode内，如s4和s5，以及更低层的tier: s4和s5的子节点s0，s1，s2，s3，否则作业将处于Pending状态：

spec:
  networkTopology:
    mode: hard
    highestTierAllowed: 2

通过这种调度策略，用户可以精确控制作业的网络拓扑约束，确保作业在满足条件的最佳性能域运行，从而显著提升训练效率。

使用指导

安装Volcano

Volcano支持以下两种安装方式：

通过Helm安装（推荐）

helm repo add volcano-sh https://volcano-sh.github.io/helm-charts
helm repo update
helm install volcano volcano-sh/volcano -n volcano-system --create-namespace --version 1.11.0-network-topology-preview.0

使用YAML文件安装

kubectl apply -f https://raw.githubusercontent.com/volcano-sh/volcano/refs/heads/network-topology/installer/volcano-development.yaml

创建HyperNode CRs

仍以图1中的网络拓扑为例，分别创建叶子节点和非叶子节点HyperNode。本样例仅为使用演示，实际需要创建的HyperNode请以集群中的真实拓扑为准。

先创建叶子节点HyperNode s0，s1，s2和s3。

apiVersion: topology.volcano.sh/v1alpha1
kind: HyperNode
metadata:
  name: s0
spec:
  tier: 1 # s0位于tier1
  members:
  - type: Node
    selector:
      exactMatch:
        name: "node-0"
  - type: Node
    selector:
      exactMatch:
        name: "node-1"
---
apiVersion: topology.volcano.sh/v1alpha1
kind: HyperNode
metadata:
  name: s1 # s1位于tier1
spec:
  tier: 1
  members:
  - type: Node
    selector:
      exactMatch:
        name: "node-2"
  - type: Node
    selector:
      exactMatch:
        name: "node-3"
---
apiVersion: topology.volcano.sh/v1alpha1
kind: HyperNode
metadata:
  name: s2 # s2位于tier1
spec:
  tier: 1
  members:
  - type: Node
    selector:
      exactMatch:
        name: "node-4"
  - type: Node
    selector:
      exactMatch:
        name: "node-5"
---
apiVersion: topology.volcano.sh/v1alpha1
kind: HyperNode
metadata:
  name: s3
spec:
  tier: 1 # s3位于tier1
  members:
  - type: Node
    selector:
      exactMatch:
        name: "node-6"
  - type: Node
    selector:
      exactMatch:
        name: "node-7"

然后创建非叶子节点s4，s5和s6。

apiVersion: topology.volcano.sh/v1alpha1
kind: HyperNode
metadata:
  name: s4 # s4位于tier2
spec:
  tier: 2
  members:
  - type: HyperNode
    selector:
      exactMatch:
        name: "s0"
  - type: HyperNode
    selector:
      exactMatch:
        name: "s1"
---
apiVersion: topology.volcano.sh/v1alpha1
kind: HyperNode
metadata:
  name: s5
spec:
  tier: 2 # s5位于tier2
  members:
  - type: HyperNode
    selector:
      exactMatch:
        name: "s2"
  - type: HyperNode
    selector:
      exactMatch:
        name: "s3"
---
apiVersion: topology.volcano.sh/v1alpha1
kind: HyperNode
metadata:
  name: s6
spec:
  tier: 3 # s6位于tier3
  members:
  - type: HyperNode
    selector:
      exactMatch:
        name: "s4"
  - type: HyperNode
    selector:
      exactMatch:
        name: "s5"

部署带有拓扑约束的Job

apiVersion: batch.volcano.sh/v1alpha1
kind: Job
metadata:
  name: mindspore-cpu
spec:
  minAvailable: 3
  schedulerName: volcano
  networkTopology: # 设置network topology约束
    mode: hard
    highestTierAllowed: 2
  queue: default
  tasks:
    - replicas: 3
      name: "pod"
      template:
        spec:
          containers:
            - command: ["/bin/bash", "-c", "python /tmp/lenet.py"]
              image: lyd911/mindspore-cpu-example:0.2.0
              imagePullPolicy: IfNotPresent
              name: mindspore-cpu-job
              resources:
                limits:
                  cpu: "1"
                requests:
                  cpu: "1"
          restartPolicy: OnFailure

注意事项

非叶子节点HyperNode的member selector不支持regexMatch。
regexMatch和exactMatch selector不能同时配置。
HyperNode的member是Node类型，即HypeNode为叶子节点时，不允许再设置类型为HyperNode的member。
叶子节点HyperNode包含了集群中的真实节点，因此使用该特性时必须要创建出叶子HyperNode节点。
HyperNode之间不能有环依赖，否则Job无法正常调度。
一个HyperNode可以有多个子节点，但一个HyperNode最多只能有一个parent HyperNode，否则Job无法正常调度。

最佳实践

调度器配置

HyperNode的打分是基于其管理的所有节点的打分总和。为了将作业尽可能地集中到相同HyperNode下，减少资源碎片，需要在调度器配置中开启binpack插件并设置合适的权重，binpack策略会优先将Pod调度到已有负载的节点上：

kind: ConfigMap
apiVersion: v1
metadata:
  name: volcano-scheduler-configmap
  namespace: volcano-system
data:
  volcano-scheduler.conf: |
    actions: "enqueue, allocate, backfill"
    tiers:
    - plugins:
      - name: priority
      - name: gang
    - plugins:
      - name: predicates
      - name: proportion
      - name: nodeorder
      - name: binpack #开启binpack插件
        arguments:
          binpack.weight: 10 #设置较高的权重值，使binpack策略的打分占主导地位，尽可能减少资源碎片

软约束模式配置

Job的spec.networkTopology.highestTierAllowed字段约束了Job允许部署的最高Tier，该值只有在spec.networkTopology.mode设置为hard时才有意义，因此将spec.networkTopology.highestTierAllowed设置为集群中最大的tier时，Job在调度时的资源视图为集群中的所有节点，此时拓扑约束与soft模式一致。因此若要使用soft模式，请将spec.networkTopology.highestTierAllowed设置为集群中最大的Tier，仍以图1为例，应该设置该值为3。

spec:
  networkTopology:
    mode: hard
    highestTierAllowed: 3