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%

短提示词场景差距会随提示词长度收敛，但在多轮对话、模板化生成、前缀高度相似的业务中，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 的全部潜能！

版本亮点​

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

AI训练与推理增强

• 支持LeaderWorkerSet用于大模型推理场景
• 新增Cron VolcanoJob
• 支持基于标签的HyperNode自动发现
• 新增原生Ray框架支持
• 新增HCCL插件支持

资源管理与调度增强

• 引入ResourceStrategyFit插件
  • 按资源类型独立评分策略
  • 稀缺资源避让(SRA)
• 增强NodeGroup功能

混部能力增强

• 混部能力与操作系统解耦
• 支持自定义超卖资源名称

支持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。

相关PRs：https://github.com/kubernetes-sigs/lws/pull/496, https://github.com/kubernetes-sigs/lws/pull/498

感谢社区开发者：@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)跟踪当前活动的作业、上次调度时间和上次成功完成时间，便于监控和管理。

相关PRs：https://github.com/volcano-sh/apis/pull/192, https://github.com/volcano-sh/volcano/pull/4560

感谢社区开发者：@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)，适用于各种异构集群，并允许用户通过标签灵活定义任意深度的层级结构。它将复杂的拓扑维护任务自动化为简单的节点标签管理，显著降低了运维成本和错误风险。此外，该机制可以动态适应集群节点和标签的变化，实时保持拓扑信息的准确性，无需手动干预。

相关PR：https://github.com/volcano-sh/volcano/pull/4629

感谢社区开发者：@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工作负载。

相关PR：https://github.com/volcano-sh/volcano/pull/4581

感谢社区开发者：@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的自动管理和分配。

相关PR：https://github.com/volcano-sh/volcano/pull/4524

感谢社区开发者：@kingeasternsun

增强NodeGroup功能​

在层级队列结构中，为每个子队列重复配置与其父队列相同的节点组亲和性(nodeGroupAffinity)会导致配置冗余且难以维护。

为解决这个问题，Nodegroup插件添加了对层级队列内亲和性继承的支持。启用后，调度器根据以下规则解析队列的有效亲和性：

1. 优先自身配置：如果队列定义了spec.affinity，则直接使用此配置。
2. 向上继承：如果队列没有定义spec.affinity，则向上搜索其父队列，并继承最近的祖先队列定义的亲和性配置。
3. 覆盖能力：子队列可以通过定义自己的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"标签的节点

相关PRs：https://github.com/volcano-sh/volcano/pull/4455

感谢社区开发者：@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的任务)尽可能避免包含这些资源的节点。这有助于为真正需要稀缺资源的任务"保留"稀缺资源节点，从而减少资源争用和任务等待时间。

机制：

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的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的避让策略，用户可以实现对异构资源更精细和高效的调度。

相关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

设计文档：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"

相关PRs：https://github.com/volcano-sh/volcano/pull/4409, https://github.com/volcano-sh/volcano/pull/4630

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

混部文档：Cloud Native 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

相关PRs：https://github.com/volcano-sh/volcano/pull/4413, https://github.com/volcano-sh/volcano/pull/4630

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

混部文档：Cloud Native Colocation

新增Kubernetes 1.33支持​

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

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

相关PR：https://github.com/volcano-sh/volcano/pull/4430

感谢社区开发者：@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位社区成员的贡献。衷心感谢所有贡献者：

[ 中国，香港，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

随着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 匹配节点。

相关参考文档：

• 网络拓扑感知调度介绍与使用
• 网络拓扑感知调度设计文档
• 网络拓扑自动发现设计文档
• 网络拓扑自动发现使用文档

Related PRs:

• https://github.com/volcano-sh/volcano/pull/3874
• https://github.com/volcano-sh/volcano/pull/3894
• https://github.com/volcano-sh/volcano/pull/3969
• https://github.com/volcano-sh/volcano/pull/3971
• https://github.com/volcano-sh/volcano/pull/4068
• https://github.com/volcano-sh/volcano/pull/4213
• https://github.com/volcano-sh/volcano/pull/3897
• https://github.com/volcano-sh/volcano/pull/3887

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

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:

• https://github.com/volcano-sh/volcano/pull/4290
• https://github.com/volcano-sh/volcano/pull/3953

由衷感谢社区开发者: @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:

• https://github.com/volcano-sh/volcano/pull/4128
• https://github.com/volcano-sh/volcano/pull/4132

由衷感谢社区开发者: @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:

• https://github.com/volcano-sh/volcano/pull/4169
• https://github.com/volcano-sh/volcano/pull/4090
• https://github.com/volcano-sh/volcano/pull/4135

由衷感谢社区开发者: @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:

• https://github.com/volcano-sh/volcano/pull/4273
• https://github.com/volcano-sh/volcano/pull/4272
• https://github.com/volcano-sh/volcano/pull/4179
• https://github.com/volcano-sh/volcano/pull/4141
• https://github.com/volcano-sh/volcano/pull/4033
• https://github.com/volcano-sh/volcano/pull/4012
• https://github.com/volcano-sh/volcano/pull/3603

由衷感谢社区开发者: @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 社区始终致力于构建更加强大、灵活和易用的批量计算平台，并积极响应快速发展的技术趋势与用户需求。在接下来的版本迭代中，我们计划重点投入以下方向：

1. 深化网络拓扑感知调度能力：在v1.12 Alpha版本的基础上，我们将持续演进网络拓扑感知能力。重点包括提供对RoCE网络的自动发现支持、节点标签的智能识别与利用，并向更细粒度的任务级（Task-level）拓扑感知调度迈进。同时，我们也将积极探索和实现更多高级调度特性，以应对复杂AI训练等场景的极致性能需求。相关issue:
   • HyperNode based binpack scheduling policy needed
   • Support task level network topology constraint
   • Support identifying network topology from node labels and converting into hyperNode resources
   • Network-topology-aware scheduling optimization: node reordering for tasks
2. 引入高级资源管理机制：重点开发和完善作业重调度（Rescheduling）与资源预留（Resource Reservation）功能。这将有助于更灵活地应对集群动态负载变化，保障关键任务的资源确定性，并进一步提升整体集群的资源利用效率。相关issue:
   • GPU fragmentation across nodes and Job/Pod rescheduling strategy request
3. 增强队列调度灵活性：提供队列级别的调度策略（Queue-level Scheduling Policy）精细化配置能力。用户将能根据不同业务队列的特性、优先级和SLA需求，更灵活地定制其调度行为和资源分配策略。相关issue：
   • volcano supports queue-level scheduling policies
4. 深化生态协同与集成：我们将积极推进与Kubernetes上游社区及其他云原生项目的协作。例如，推动LWS（Leader Worker Set）与Volcano的集成，以便更好地为分布式应用提供Gang Scheduling能力。相关issue：
   • Support custom scheduler to enable gang scheduling
     我们热忱欢迎更多优秀的开源项目与Volcano携手，共同构建和繁荣云原生批量计算生态。
5. 拓展异构硬件支持与合作：加强与硬件生态伙伴的合作，如昇腾（Ascend）的Device Plugin和DRA Driver的适配与优化，以及与主流GPU厂商在DRA Driver上的协作，确保Volcano能高效、稳定地调度和管理各类前沿异构加速器资源。
6. JobFlow工作流能力提升：持续优化Volcano内置的轻量级工作流引擎JobFlow。计划增强其在复杂作业依赖管理、状态监控、错误处理及用户自定义扩展等方面的能力，为用户提供更强大、更易用的工作流编排解决方案。相关issue：
   • Support JobFlowTemplate CRD
   • Enhance JobFlow Functionality
7. 引入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：

Volcano 通过实施针对性的配置变更，解决了若干基础设施层面的安全问题；这些变更有效降低了风险，并提升了其默认部署环境下的整体安全态势。下文将详细列出每一个安全问题及其关联风险，并阐述 Volcano 采取的解决措施，同时展示由此带来的安全改进成果。

其中一个问题涉及多个 Volcano 组件在默认状态下以 root 权限运行。容器若以 root 权限运行，会带来较高的安全风险：一旦容器遭到入侵，攻击者便能获取到可用于进行权限提升的系统能力（capabilities）。Volcano 针对此问题进行了修复，将所有组件——包括调度器（scheduler）、准入控制器（admission controller）、各类控制器（controllers）以及仪表板（dashboard）——均配置为默认以非 root 权限运行。这一变更限制了攻击者在容器内部可执行的操作范围，有助于在安全事件发生时更有效地遏制其扩散。

另一个问题是 Volcano 的各类工作负载（workloads）中均未配置 seccomp 配置文件。若缺乏 seccomp 机制，容器将能够调用任意 Linux 系统调用，从而扩大了针对内核层面的攻击面，并增加了容器逃逸（container escapes）的风险。Volcano 通过引入 seccomp 配置文件解决了这一问题——具体而言，我们采用了 RuntimeDefault 模式，该模式将容器可调用的系统调用范围限制在一个安全的子集内。此举有效降低了内核的暴露风险，并强化了运行时的隔离安全性。

此外，Volcano 的容器环境中此前也未启用 SELinux 安全机制。SELinux 负责在内核层面实施访问控制，并对进程与文件、系统资源及其他进程之间的交互行为进行限制。目前，Volcano 已为其所有的 Pod 和容器全面启用了 SELinux 安全机制。此外，Volcano 此前曾为容器分配了不必要的 Linux Capabilities（能力集）——这是一种细粒度的权限控制机制，用于决定容器化进程能够执行的操作。例如，像 CAP_NET_ADMIN 或 CAP_SYS_ADMIN 这样的能力集赋予了进程极高的权限，而对于典型的应用程序逻辑而言，这些权限往往并非必需。Volcano 采取了风险缓解措施，通过“全部丢弃”（drop all）的策略移除所有非必要的能力集，仅在确有需要时才重新添加特定的权限。此举不仅缩小了系统的攻击面，还严格贯彻了“最小权限原则”。

在本次安全审计之前，Volcano 允许容器在运行时进行权限提升（Privilege Escalation），这意味着原本不具备特权的进程有可能借机获取额外的权限。这种权限提升行为会显著增加攻击者绕过容器安全防护机制的风险。Volcano 针对这一问题进行了修复，通过在容器和 Pod 的配置中将 allowPrivilegeEscalation 参数设置为 false，从而确保容器内的进程只能在其最初被分配的权限范围内运行。

上述变更有助于有效遏制潜在的攻击行为，减少攻击者利用权限提升或容器逃逸漏洞进行渗透的途径，进而全面提升系统在多租户及生产环境下的整体安全韧性。

在应用程序层面，审计人员共发现了 5 个安全隐患。其中最值得关注的一项漏洞在于：若攻击者成功攻陷了集群内的弹性服务（Elastic Service）或扩展插件（Extender Plugin），便可借此引发 Volcano 调度器的拒绝服务（Denial of Service）故障。该漏洞已被分配了 CVE 编号：CVE​​-2025-32777，其危害等级被定为“高危”（HIGH）。

模糊测试（Fuzzing）​

在本次安全审计期间，Ada Logics 团队将 Volcano 项目接入了 Google 的 OSS-Fuzz 项目，并提交了首批两个模糊测试用例。OSS-Fuzz 是一个开源项目，旨在为各类关键性的开源软件项目提供集成式的模糊测试服务。Google 会利用其庞大的计算资源对已接入项目的模糊测试用例进行大规模运行，并通过电子邮件将发现的任何安全问题反馈给相应的项目开发团队。OSS-Fuzz 生成的报告内容详实，不仅包含完整的堆栈追踪信息（Stack Traces）和漏洞复现步骤，还会指明是哪一个模糊测试用例（Fuzz Harness）发现了该问题，以及其他相关细节。此外，OSS-Fuzz 系统会定期尝试对已报告的漏洞进行复现验证，以确认该漏洞是否依然存在。若系统无法成功复现该漏洞，OSS-Fuzz 便会自动将其标记为“已修复”状态。

参与 Volcano 社区​

Volcano 是业界首款云原生批处理计算引擎，也是目前 CNCF（云原生计算基金会）旗下唯一的批处理计算项目。它作为一套 Kubernetes 原生的批处理调度系统运行，对标准的 kube-scheduler 进行了功能增强。Volcano 提供了全面的功能，用于管理和优化各类批处理及弹性工作负载，涵盖 AI/ML/DL、生物信息学/基因组学以及其他“大数据”应用场景。它与 Spark、Flink、Ray、TensorFlow、PyTorch、Argo、MindSpore、PaddlePaddle、Kubeflow、MPI、Horovod、MXNet 和 KubeGene 等各类框架实现了深度集成。凭借超过十五年的……

The increasing adoption of large language models (LLMs) has led to heightened demand for efficient AI training and inference workloads. As model size and complexity grow, distributed training and inference have become essential. However, this expansion introduces challenges in network communication, resource allocation, and fault recovery within large-scale distributed environments. These issues often create performance bottlenecks that hinder scalability.

Addressing Network Bottlenecks Through Topology-Aware Scheduling​

In LLM training, model parallelism distributes workloads across multiple nodes, requiring frequent data exchanges. Network communication can become a bottleneck, particularly in heterogeneous environments with InfiniBand (IB), RoCE, or NVSwitch configurations. Communication efficiency depends on network topology—fewer switches between nodes typically result in lower latency and higher throughput. One approach to mitigating this challenge is Network Topology-Aware Scheduling, which optimizes workload placement to minimize cross-switch communication. A key component of this strategy is the HyperNode, an abstraction for representing network topology via Custom Resource Definitions (CRDs). Unlike label-based methods, HyperNode provides a hierarchical structure that reflects actual network layouts, improving management and optimization. Nodes within the same HyperNode communicate more efficiently than those spanning multiple layers.

Topology constraints can also be specified for jobs through the networkTopology field, with options for strict (Hard Mode) or flexible (Soft Mode) enforcement. This granular control helps ensure workloads are deployed in optimal network environments, reducing latency and improving throughput.

Managing Multi-Cluster Environments for Scalability​

As AI workloads expand, single Kubernetes clusters may no longer suffice for large-scale training and inference. While multiple clusters can address this limitation, managing them efficiently presents challenges. The Volcano Global subproject extends scheduling capabilities to multi-cluster environments, integrating with Karmada to enable cross-cluster scheduling for distributed workloads. Features such as Queue Priority Scheduling, Job Priority Scheduling, and Multi-Tenant Fair Scheduling help optimize resource allocation and ensure equitable access across tenants. This approach simplifies multi-cluster management while supporting scalable AI workloads.

Improving Stability with Fine-Grained Fault Recovery​

Fault recovery is critical in distributed AI training and inference. Traditional methods often restart entire jobs upon a single Pod failure, leading to resource inefficiencies. With checkpointing and resume-from-checkpoint techniques, full restarts are often unnecessary. Fine-Grained Job Fault Recovery allows policies to restart only failed Pods or associated tasks, reducing unnecessary disruptions. Timeout configurations can further minimize interventions—if a Pod recovers within the allotted time, no restart is triggered. This approach enhances stability and efficiency in distributed workloads.

Future Developments in Distributed Workload Management​

Ongoing advancements in distributed workload management include:

• Task-Level Network Topology Affinity Scheduling: Support for distributed inference scenarios, such as integration with lws.

• HyperNode Auto-Discovery and Status Updates: Automation for HyperNode lifecycle management.

• Dynamic Resource Allocation (DRA): Improved management of heterogeneous resources.

• Dynamic GPU Partitioning: Support for MIG and MPS to enhance GPU utilization.

More information for Volcano:

• Website: https://volcano.sh/

• GitHub: https://github.com/volcano-sh/volcano

• Slack: Join the conversation onVolcano Slack.

• Weekly Meetings: Attend our weekly meetings and review meeting notes:

  • Meeting Link: Zoom

  • Meeting Notes: Google Docs

• Twitter: Follow us on X (formerly Twitter) for the latest updates.

随着用户使用场景的日益复杂，以及对资源利用率极致追求，特别是在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的弹性层级队列具备以下关键特性，满足多租户场景下的复杂需求：

1. 支持配置队列层级关系: 用户可以按需创建多级队列，形成树状结构。每个队列可以设置独立的资源配额和优先级，确保资源的合理分配。

2. 跨层级资源共享与回收: 子队列资源空闲时，可以将资源共享给兄弟队列，当子队列提交任务时，可以从兄弟队列回收资源。

3. 细粒度的资源配额管理: 每个队列可以设置以下资源参数：

   • capability：队列的资源容量上限。
   • deserved：队列应得的资源量。如果队列已分配的资源超过deserved值，超出的部分可以被回收。
   • guarantee：队列的资源预留量，这部分资源不会被其他队列共享，确保队列的最低资源保障。

4. 灵活的抢占策略: 支持基于优先级的资源抢占，确保高优先级任务能够及时获得所需资源。

层级队列示意图​

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

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

适用场景​

• 多部门资源共享：在大型企业中，不同部门共享同一个集群，通过层级队列实现资源的公平分配与隔离。
• 大数据任务调度：从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作业调度的复杂需求：

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

关于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：

• 新增队列优先级设置策略

• 支持细粒度的GPU资源共享与回收

• 支持Pod Scheduling Readiness调度

• 支持Sidecar container调度

• 增强vcctl命令行工具功能

• Volcano支持Kubernetes v1.30

• 增强Volcano安全性

• 优化Volcano性能

• 提升GPU监控功能

• 优化helm chart包安装升级流程

Volcano是业界首个云原生批量计算项目，于2019年6月在上海 KubeCon 正式开源，并在2020年4月成为 CNCF 官方项目。2022年4月，Volcano 正式晋级为CNCF 孵化项目。Volcano 社区开源以来，受到众多开发者、合作伙伴和用户的认可和支持。截至目前，累计有800+全球开发者参与社区贡献。

Volcano v1.10.0 关键特性介绍​

新增队列优先级设置策略​

在传统的大数据处理场景下，用户可以直接设置队列优先级来控制作业的调度顺序，为了更好的帮助用户从Hadoop/Yarn迁移到云原生平台，Volcano也支持了在队列层面直接设置优先级，降低大数据用户的迁移成本，提升用户体验和资源利用效率。

队列是Volcano中的一种基本资源，不同队列有着优先级区分，在默认情况下，队列的优先级是由队列的share值决定的，share值是由队列中已分配的资源量除以队列的总容量计算得到的，不需要用户手动配置，share值越小，则代表队列中已分配的资源比例越小，即队列越不饱和，需要优先分配资源，因此队列的share越小，队列的优先级越高，在分配资源时会优先分配给share较小的队列，以保证资源分配的公平性。

但是在生产环境尤其是大数据处理场景下，用户更希望可以直接设置队列的优先级，从而能更直观的知道不同队列的优先级顺序，由于share值是实时计算得到的，因此会根据队列分配资源的饱和程度而实时变化，为了更加直观的表示队列优先级同时支持用户自行配置，Volcano在share值的基础上为队列新增了priority字段，支持用户配置队列优先级，priority越高则表示队列优先级越高，会优先分配资源给高优先级的队列，并且在回收队列资源时会优先回收低优先级队列内的作业。

队列优先级定义：

type QueueSpec struct {
...
  // Priority define the priority of queue. Higher values are prioritized for scheduling and considered     later during reclamation.
  // +optional
  Priority int32 `json:"priority,omitempty" protobuf:"bytes,10,opt,name=priority"`
}

同时为了兼容share值的使用方式，Volcano在计算队列优先级时也会考虑share值，默认情况下用户不设置队列优先级或者队列的优先级相等时，Volcano会再比较队列的share值，此时share越小队列优先级越高。用户可以根据实际场景选择设置不同的优先级策略，即priority和share两种方式。

关于队列优先级设计文档，请参考：Queue Priority.

支持细粒度的GPU资源共享与回收​

Volcano在v1.9版本发布了弹性队列容量capacity调度功能，用户可以直接为队列设置每一维度资源的容量，同时支持基于deserved的队列弹性容量调度，实现了更加细粒度的队列资源共享和回收机制。

弹性队列容量capacity调度的设计文档请参考：Capacity scheduling Design

使用指导请参考：Capacity Plugin User Guide.

为队列配置每一维度deserved使用样例：

apiVersion: scheduling.volcano.sh/v1beta1
kind: Queue
metadata:
  name: demo-queue
spec:
  reclaimable: true
  deserved: # set the deserved field.
    cpu: 64
    memeory: 128Gi
    nvidia.com/a100: 40
    nvidia.com/v100: 80

在v1.10版本中，Volcano在弹性队列容量capacity的基础上，支持了上报不同型号的GPU资源，NVIDIA默认的Device Plugin在上报GPU资源时无法区分GPU型号，统一上报为nvidia.com/gpu，AI训推任务无法根据业务特点选择不同型号的GPU，比如A100、T4等型号的GPU，为了解决这一问题，以满足不同类型的AI任务需求，Volcano在Device Plugin层面支持上报不同型号的GPU资源到节点，配合capacity插件实现更加细粒度的GPU资源共享和回收。

关于Device Plugin上报不同型号GPU的实现和使用指导，请参考：GPU Resource Naming.

注意：

capacity在v1.10.0版本中作为了默认的队列管理插件，capacity与proportion插件互相冲突，当升级到v1.10.0后，你需要再设置队列的deserved字段，以保证队列功能正常工作，具体的使用说明请参考：Capacity Plugin User Guide.

capacity插件根据用户指定的队列deserved值来划分集群资源，而proportion插件则根据队列权重动态划分集群资源，用户可以根据实际场景选择使用capacity或者proportion插件进行队列管理。proportion插件的介绍请参考：proportion plugin.

支持Pod Scheduling Readiness调度​

Pod 一旦创建就被认为已准备好进行调度，在 Kube-scheduler 中，它会尽力寻找合适的节点来放置所有Pending的 Pod。然而，在现实情况下，某些 Pod 可能会长时间处于“缺少必要资源”状态，这些 Pod 实际上以不必要的方式干扰调度程序（以及 Cluster AutoScaler 等下游组件）的决策和运行，造成资源浪费等问题。Pod Scheduling Readiness是 Kube-sheduler 的一项新增功能，在Kubernetes v.1.30版本GA，成为了一个稳定特性，它通过设置Pod的schedulingGates字段来控制Pod的调度时机。

Pod SchedulingGates

在前面的版本中，Volcano已集成了K8s默认调度器的所有算法，全面涵盖了Kube-scheduler的原生调度功能。因此，Volcano能够无缝替代Kube-scheduler，作为云原生平台下的统一调度器，支持微服务和AI/大数据工作负载的统一调度。在最新发布的v1.10版本中，Volcano更是引入了Pod Scheduling Readiness调度能力，进一步满足了用户在多样化场景下的调度需求。

关于Pod Scheduling Readiness特性的文档，请参考：Pod Scheduling Readiness | Kubernetes

Volcano支持Pod Scheduling Readiness调度的设计文档，请参考：Proposal for Support of Pod Scheduling Readiness by ykcai-daniel · Pull Request #3581 · volcano-sh/volcano (github.com)

支持Sidecar container调度​

Sidecar container是一种相对于业务容器而言的辅助容器，通常用来辅助业务容器的运行，比如收集业务容器日志、监控、初始化网络等。

在Kubernetes v1.28之前，Sidecar container只是一种概念，并没有单独的API来标识一个容器是否是Sidecar container，Sidecar容器和业务容器处于同等地位，有着相同的生命周期，Kubelet会并发启动所有Sidecar容器和业务容器，这样带来的问题是Sidecar容器可能会在业务容器启动之后才启动，并且在业务容器结束之前先结束，而我们期望的是Sidecar容器先于业务容器启动，并在业务容器结束之后再结束，这样就能保证Sidecar容器收集的日志，监控等信息是完整的。

Kubernetes v1.28在API层面支持了Sidecar container，并对init container、Sidecar container、业务container做了统一的生命周期管理，同时调整了Pod的request/limit资源计算方式，该特性在v1.29成为Beta特性。

该特性在设计阶段经历了漫长的讨论时间，特性本身并不复杂，主要的考虑点在于兼容旧的使用方式，如果定义一个除了init container、业务容器之外的新的容器类型，会对API有较大的破坏性，同时周边组件适配该特性的话会有较多的侵入式修改，带来很多额外开销，因此Kubernetes社区并没有引入新的容器类型来支持Sidecar container，而是直接复用了init container，通过设置init container的restartPolicy为Always来标识Sidecar container，完美的解决了API兼容性问题和Sidecar容器的生命周期问题。

在调度层面，该特性的影响在于Pod申请的request资源计算方式有所变化，因为Sidecar container作为一种特殊的init container是持久运行的，需要将Sidecar container的request值累加到业务容器的request值上，因此需要重新计算init container、Sidecar container和业务容器的资源request值。

Volcano调度器在新版本更改了Sidecar container的资源计算方式，支持了Sidecar container的调度，用户可以使用Volcano调度Sidecar container。

关于Sidecar container的详细信息，请参考：Sidecar Containers | Kubernetes

增强vcctl命令行工具功能​

vcctl是操作Volcano内置CRD资源的一个命令行工具，可以方便的用来查看/删除/暂停/恢复vcjob资源，并支持查看/删除/开启/关闭/更新queue资源。Volcano在新版本对vcctl做了功能增强，新增以下功能：

• 支持创建/删除/查看/描述jobflow和jobtemplate资源

• 支持查询指定队列里的vcjob

• 支持通过queue和vcjob过滤查询Pod

vcctl的详细指导文档，请参考：vcctl Command Line Enhancement.

Volcano支持Kubernetes v1.30​

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

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

增强Volcano安全性​

Volcano一直都很重视开源软件供应链的安全，在license合规、安全漏洞披露和修复、仓库分支保护、CI检查等方面遵循OpenSSF定义的规范，Volcano近期在Github Action加入了新的workflow，它会在代码合入时运行OpenSSF安全性检查，并实时更新软件安全评分，持续提升软件安全性。

同时Volcano对各个组件的RBAC权限进行了收缩，只保留必要的权限，避免了潜在的越权风险，提升了系统的安全性。

相关PR参见：

Added the scorecard github action and its badge by harshitasao · Pull Request #3655 · volcano-sh/volcano

Shrink permissions of vc scheduler & controller by Monokaix · Pull Request #3545 · volcano-sh/volcano (github.com)

Add pre-install&pre-upgrade hook for admission-init job by Monokaix · Pull Request #3504 · volcano-sh/volcano (github.com)

优化Volcano性能​

在大规模场景下，Volcano做了很多性能优化的工作，主要包括：

• 优化vcjob更新策略，降低vcjob的更新和同步频次，降低API Server压力，提升提交任务的QPS

• vc controller新增controller gate开关，用户可以选择关闭不需要的controller，减低内存占用和CPU负载

• 所有的controller使用共享的informer，减少内存占用

提升GPU监控功能​

新版本的Volcano针对GPU监控指标做了优化和增强，修复了GPU监控不精确的问题，并在GPU的算力和显存监控指标上新增了节点信息，方便用户更加直观的查看每个节点上每一张GPU的算力、显存的总量和已分配量。

详细PR参见：Update volcano-vgpu monitoring system by archlitchi · Pull Request #3620 · volcano-sh/volcano (github.com)

优化helm chart包安装升级流程​

Volcano针对helm chart的安装、升级流程进行了优化，并支持安装helm chart包设置更多自定义参数，主要包括：

• 利用helm的hook机制，在安装成功Volcano之后，自动删除volcano-admission-init这一job，避免后续使用helm upgrade升级失败的问题，相关PR参见：Add pre-install&pre-upgrade hook for admission-init job by Monokaix · Pull Request #3504 · volcano-sh/volcano (github.com)
• 每次安装成功后更新Volcano admission需要的secret文件，避免在不指定helm包名情况下，重复安装卸载volcano导致volcano admission处理失败的问题，详细PR参见：Update volcano-admission secret when it already exists by Monokaix · Pull Request #3653 · volcano-sh/volcano (github.com)
• 支持为helm包中的资源对象设置通用label，相关PR参见：Add common labels for chart objects by Aakcht · Pull Request #3511 · volcano-sh/volcano (github.com)
• 支持通过helm为Volcano组件设置日志等级，相关PR参见：Expose volcano components (controller, scheduler, etc.) log level control to the helm chat values by chenshiwei-io · Pull Request #3656 · volcano-sh/volcano (github.com)
• 支持通过helm设置Volcano组件的镜像代理仓库，相关PR参见：add image registry for helm by calvin0327 · Pull Request #3436 · volcano-sh/volcano (github.com)
• 支持通过helm设置容器级别的securityContext，相关PR参加：feat: Add securityContext support at container level in helm chart templates by lekaf974 · Pull Request #3704 · volcano-sh/volcano (github.com)

致谢贡献者​

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

贡献者GitHub ID

参考链接​

Release note: v1.10.0

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

Branch：release-1.10

https://github.com/volcano-sh/volcano/tree/release-1.10

深入了解Volcano​

Volcano 云原生批量计算项目主要用于 AI、大数据、基因、渲染等诸多高性能计算场景，对主流通用计算框架均有很好的支持。社区已吸引5.8万+全球开发者，并获得4.1k+ Star 和900+ Fork，参与贡献企业包括华为、AWS、百度、腾讯、京东、小红书、博云、第四范式等。目前，Volcano在人工智能、大数据、基因测序等海量数据计算和分析场景已得到快速应用，已完成对 Spark、Flink、Tensorflow、PyTorch、Argo、MindSpore、Paddlepaddle 、Kubeflow、MPI、Horovod、mxnet、KubeGene、Ray 等众多主流计算框架的支持，并构建起完善的上下游生态。

• 支持弹性队列容量capacity调度

• 支持队列与节点间的亲和调度

• Volcano支持Kubernetes v1.29

• GPU共享支持节点打分调度

• 增强scheduler metrics指标

• 新增License合规性检查

• 提升调度稳定性

Volcano是业界首个云原生批量计算项目，于2019年6月在上海 KubeCon 正式开源，并在2020年4月成为 CNCF 官方项目。2022年4月，Volcano 正式晋级为CNCF 孵化项目。Volcano 社区开源以来，受到众多开发者、合作伙伴和用户的认可和支持。截至目前，累计有600+全球开发者参与社区贡献。

Volcano v1.9.0 关键特性介绍​

支持弹性队列容量capacity调度​

Volcano现在使用proportion插件来进行队列管理，用户可以设置队列的guarantee、capability等字段来设置队列的预留资源和容量上限。并通过设置队列的weight值来实现集群内的资源共享，队列按照weight值按比例划分集群资源，但这种队列管理方式存在以下问题：

• 队列划分的资源容量通过权重体现，不够直观。
• 队列内的所有资源使用相同的比例进行划分，不能为队列的每一维资源单独设置容量。

基于以上考虑，Volcano实现了新的队列弹性容量管理能力，它支持：

• 用户可以直接为队列设置每一维度资源的容量，而不是设置weigh值来实现。
• 基于deserved的队列弹性容量调度，支持队列的资源共享和回收。

比如在AI大模型训练中分别为队列中不同的GPU型号如A100和V100，设置不同的资源容量。同时在集群资源空闲时，队列可以复用其他空闲队列的资源，并在需要时进行资源回收，直到回收到用户为队列设置的资源容量为止，即应得资源量deserved，从而实现弹性容量能力。

使用改功能时需要设置队列的deserved字段，为每一维资源设置应得资源量。同时需要在调度配置中打开capacity插件，并关闭proportion插件。

apiVersion: scheduling.volcano.sh/v1beta1
kind: Queue
metadata:
  name: demo-queue
spec:
  reclaimable: true
  deserved: # set the deserved field.
    cpu: 64
    memeory: 128Gi
    nvidia.com/a100: 40
    nvidia.com/v100: 80

队列弹性容量调度的完整使用例子，请参考：How to use capacity plugin.

关于弹性队列容量设计文档，请参考Capacity scheduling Design.

支持队列与节点间的亲和调度​

队列通常关联着公司内的部门，而不同部门通常需要使用不同的异构资源类型，比如大模型训练团队需要使用NIVDIA的Tesla GPU，而推荐团队需要使用AMD的GPU，当用户提交作业到队列时，需要根据队列的属性将作业自动调度到对应资源类型的节点上。

为此Volcano实现了队列和节点的亲和调度能力，用户只需在队列的affinity字段设置需要亲和的节点标签，Volcano会自动将提交到当前队列的作业调度到队列关联的节点上，用户无需单独设置作业的亲和性，而只需统一设置队列的亲和性，提交到队列的作业都会根据队列与节点的亲和性将作业调度到对应的节点。

该特性同时支持硬亲和、软亲和、反亲和调度，使用时需要为节点设置key为volcano.sh/nodegroup-name的标签，然后设置队列的affinity字段，指定硬亲和、软亲和和反亲和的标签值。例如如下的队列设置，表示提交到该队列的作业需要调度到标签值为groupname1和groupname2的节点，并优先调度到标签值为groupname2的节点，同时，作业不能调到到标签值为groupname3和groupname4的节点，当资源不足时则也可以调度到标签值为groupname3的节点上。

apiVersion: scheduling.volcano.sh/v1beta1
kind: Queue
metadata:
  name: default
  spec:
    reclaimable: true
    weight: 1
    affinity:            # added field
      nodeGroupAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
        - <groupname1>
        - <groupname2>	
        preferredDuringSchedulingIgnoredDuringExecution:
        - <groupname1>
      nodeGroupAntiAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
        - <groupname3>
        - <gropuname4>
        preferredDuringSchedulingIgnoredDuringExecution:
        - <groupname3>

该功能对应的调度插件名为nodegroup，完整使用例子请参考：How to use nodegroup plugin.

详细设计文档请参考：The nodegroup design.

GPU共享功能支持节点打分调度​

GPU共享是Volcano v1.8版本推出的GPU共享与隔离方案，提供GPU共享、设备显存控制能力，以提升AI训练推理场景下GPU资源利用率低的问题。v1.9在该功能基础上新增了对GPU节点打分的策略，从而可以在作业分配时选择最优的节点，进一步提升资源利用率，用户可以设置不同的打分策略。目前支持以下两种策略：

• Binpack：提供GPU卡粒度的binpack算法，优先把一个节点上的已经分配了资源的GPU卡占满，避免资源碎片和浪费。

• Spread：优先使用空闲的GPU卡而不是已经分配了资源的共享卡。

详细使用文档请参考：How to use gpu sharing

Volcano支持Kubernetes v1.29​

Volcano版本紧跟Kubernetes社区版本节奏，对Kubernetes的每个大的基数版本都进行支持，目前最新支持的版本为v1.29，并运行了完整的UT、E2E用例，保证功能和可靠性。如果您想参与Volcano适配Kubernetes新版本的开发工作，请参考：https://github.com/volcano-sh/volcano/pull/3459 进行社区贡献。

增强scheduler metrics指标​

Volcano使用了client-go客户端和Kubernetes交互，尽管客户端可以设置QPS来避免请求被限流，但是客户端实际使用的QPS到底达到了多少却很难观察到，为了实时观测到客户端请求的频率，Volcano新增了client-go客户端的metrics指标，用户可以通过访问metrics接口，查看GET、POST等请求在每秒钟的请求数量，从而确定每秒钟实际使用的QPS，以此决定是否需要调整客户端设置的QPS。同时client-go的相关指标还包括客户端证书轮转周期统计、每个请求的response size统计等。

用户可以使用curl http://$volcano_scheduler_pod_ip:8080/metrics 来获取volcano scheduler的所有详细指标。

详细PR见：[feat] Add rest client metrics by Monokaix · Pull Request #3274 · volcano-sh/volcano (github.com)

新增License合规性检查​

为了增强Volcano社区开源license合规治理规范，避免引入传染性开源协议，规避潜在风险，Volcano社区引入了开源license合规检查工具，所谓传染性协议指的是使用了该协议作为开源许可的软件在修改、使用、复制之后生成的衍生作品，也必须以该协议进行开源。开发者提交的PR会引入的三库如果包含了传染性开源协议比如GPL，LGPL等，CI门禁会进行拦截，开发者需要将三方库替换为松自由软件许可协议比如MIT、Apache 2.0，BSD等，以通过开源license合规检查。

提升调度稳定性​

Volcano v1.9.0版本在抢占、调度失败重试、避免内存泄露、安全性增强等方面做了较多优化，具体内容包括：

• 修复极端情况下deployment频繁扩缩容导致的pod无法调度的问题，详见PR：[cherry-pick for release-1.9]fix PodGroup being incorrectly deleted due to frequent creation and deletion of pods by guoqinwill · Pull Request #3376 · volcano-sh/volcano (github.com)

• 修复Pod抢占问题：详见PR：ignore PredicateFn err info for preempt & reclaim scheduler plugin by LivingCcj · Pull Request #3458 · volcano-sh/volcano (github.com)

• 优化Pod调度失败重试机制：详见PR：fix errTask channel memory leak by bibibox · Pull Request #3435 · volcano-sh/volcano (github.com)

• metrics指标优化：详见PR：Fix queue metrics when there are no jobs in it by Monokaix · Pull Request #3463 · volcano-sh/volcano (github.com)

• 安全性增强：详见PR：Remove list secret in controller ClusterRole by lekaf974 · Pull Request #3449 · volcano-sh/volcano (github.com)

致谢贡献者​

Volcano 1.9.0 版本包含了来自多位贡献者的代码提交，在此对各位贡献者表示由衷的感谢：

贡献者 GitHub ID：

参考链接

Release note: v1.9.0

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

Branch：release-1.9

https://github.com/volcano-sh/volcano/tree/release-1.9

深入了解Volcano​

Volcano 云原生批量计算项目主要用于 AI、大数据、基因、渲染等诸多高性能计算场景，对主流通用计算框架均有很好的支持。社区已吸引5.8万+全球开发者，并获得3.5k+ Star 和800+ Fork，参与贡献企业包括华为、AWS、百度、腾讯、京东、小红书、博云、第四范式等。目前，Volcano在人工智能、大数据、基因测序等海量数据计算和分析场景已得到快速应用，已完成对 Spark、Flink、Tensorflow、PyTorch、Argo、MindSpore、Paddlepaddle 、Kubeflow、MPI、Horovod、mxnet、KubeGene、Ray 等众多主流计算框架的支持，并构建起完善的上下游生态。

作为业界首个云原生批量计算项目，Volcano 于 2019 年 6 月在 KubeCon 上海峰会上正式开源，并于 2020 年 4 月正式成为 CNCF（云原生计算基金会）的官方项目。2022 年 4 月，Volcano 成功晋级为 CNCF 孵化项目。截至目前，全球已有超过 600 名开发者为该项目提交了代码。Volcano 社区正日益受到开发者、合作伙伴及用户的广泛关注与青睐。 ### 体验 Volcano v1.8.2 的新特性

在 Volcano 的最新版本 v1.8.2 中，新增了以下特性：

• 支持 vGPU 调度与隔离

• 支持 vGPU 及用户自定义资源的抢占能力

• 新增 JobFlow 工作流调度引擎

• 支持针对多种监控系统的节点负载感知调度与重调度

• 优化 Volcano 的微服务调度能力

• 优化 Volcano Chart 包的发布与归档流程

立即体验 Volcano v1.8.2：https://github.com/volcano-sh/volcano/releases/tag/v1.8.2

加入 Volcano 社区共建计划​

近期，已有超过 50 个与 Volcano 相关的应用案例落地实施。这些案例广泛分布于互联网、先进制造、金融、生命科学、科学研究、自动驾驶及医药等行业。它们涵盖了 AI、大数据、基因测序、渲染等海量数据计算与分析场景。主要用户包括腾讯、亚马逊、ING 银行、百度、小红书、滴滴、360、爱奇艺、乐脑、鹏城实验室、Cruise、理想汽车、云知声、喜马拉雅、唯品会、GrandOmics、BOSS 直聘等。随着 Volcano 生态系统的不断壮大，越来越多的用户表现出极高的意愿加入社区。

Volcano 社区正式启动了“社区共建计划”，旨在欢迎更多用户融入 Volcano 社区，加速云原生技术的演进，并确保 Volcano 生态系统的多元化发展。

通过参与该计划，您将有机会获得技术指导、推广支持，以及参与线上和线下的技术分享活动。如果您的公司或组织认可 Volcano 所能创造的价值，希望在使用 Volcano 方面获得协助，或者希望发挥自身的技术影响力，欢迎考虑加入此项计划。 有关参与要求与权益的详细信息，请参阅：https://github.com/volcano-sh/community/blob/master/community-building-program.md

3月19日至22日，相约巴黎 KubeCon + CloudNativeCon Europe 大会，与 Volcano 共同交流！ ​

Volcano 将参与多项活动，具体包括：

• 演讲日程
• 3月19日 14:05 - 14:30（CET）：7.3层 | S03会议室 Volcano 维护者 Kevin Wang（华为）将发表题为《利用 Karmada 与 Volcano 实现高效的多集群 GPU 工作负载管理》的演讲。
• 3月22日 11:55 - 12:30（CET）：7号馆 | 7.3层 | N03会议室 Volcano 维护者 William Wang（华为）与 Mengxuan Li（第四范式）将发表题为《基于 Volcano 的云原生批处理计算：最新进展与未来展望》的演讲。
• 3月22日 16:00 - 16:35（CET）：7号馆 | 7.3层 | Paris 会议室 Volcano 维护者 William Wang 与 Hongcai Ren（华为）将发表题为《最大化多集群 GPU 利用率：云原生 AI 平台的挑战与解决方案》的演讲。
• 展台开放时间：
• 3月20日至22日 下午时段（周三、周四、周五）：欢迎莅临 KubeCon + CloudNativeCon Europe 大会现场的 CNCF 项目展区 PP18-B 展台，与专家交流或观看演示！

• 支持vGPU调度及隔离

• 支持vGPU和用户自定义资源的抢占能力

• 新增JobFlow工作流编排引擎

• 节点负载感知调度与重调度支持多样化的监控系统

• 优化Volcano对通用服务调度的能力

• 优化Volcano charts包的发布与归档

Volcano是业界首个云原生批量计算项目，于2019年6月在上海 KubeCon 正式开源，并在2020年4月成为 CNCF 官方项目。2022年4月，Volcano 正式晋级为CNCF 孵化项目。Volcano 社区开源以来，受到众多开发者、合作伙伴和用户的认可和支持。截至目前，累计有600+全球开发者参与社区贡献。

Volcano v1.8.2 关键特性介绍​

支持vGPU调度及隔离​

自 ChatGPT 爆火之后，AI大模型的研发层出不穷，不同种类的AI大模型也相继推出，由于其庞大的训练任务需要大量算力，以 GPU 为核心的算力供给已成为大模型产业发展的关键基础设施。在实际使用场景中，用户对于 GPU 资源的使用存在资源利用率低，资源分配不灵活等痛点问题，必须采购大量冗余的异构算力才能满足业务需求，而异构算力本身成本高昂，为企业的发展带来了很大的负担。 从 1.8版本开始，Volcano 为可共享设备（GPU、NPU、FPGA...）提供一个抽象的通用框架，开发者可以基于该框架自定义多种类型的共享设备；当前，Volcano 已基于该框架实现 GPU 虚拟化特性，支持 GPU 设备复用、资源隔离等能力，详情如下：

• GPU共享：每个任务可以申请使用一个 GPU 卡的部分资源，GPU 卡可以在多个任务之间共享。

• 设备显存控制：GPU 可以按照设备显存分配（比如：3000M）或者按比例分配（比如：50%），实现 GPU 虚拟化资源隔离能力。

关于 vGPU 的更多信息，请参考：

• 如何使用 vGPU 功能：

  /docs/KeyFeatures/GPUVirtualization

• 如何增加新的异构算力共享策略：

  https://github.com/volcano-sh/volcano/blob/master/docs/design/device-sharing.md

支持vGPU和用户自定义资源的抢占能力​

当前 Volcano 支持 CPU、Memory 等基础资源抢占功能，对于 GPU 资源和用户基于 Volcano 框架二次开发调度插件，并自主管理的资源（如：NPU、网络资源等）尚不能很好的支持抢占能力。 在1.8版本中，Volcano 对节点过滤相关处理（ PredicateFn 回调函数）进行重构，返回结果中增加 Status 类型，用于标识在调度、抢占等场景下，当前节点是否满足作业下发条件。GPU 抢占功能已基于优化后的框架实现发布，用户基于Volcano 进行二次开发的调度插件可以结合业务场景适配升级。 在1.8.2版本中，Volcano支持节点CSI挂盘数量和节点Pods数量的抢占。

关于支持扩展资源抢占的更多信息，请参考：

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

新增JobFlow工作流编排引擎​

工作流编排引擎广泛应用于高性能计算、AI 生物医药、图片处理、美颜、游戏AGI、科学计算等场景，帮助用户简化多个任务并行与依赖关系的管理，大幅度提升整体计算效率。 JobFlow 是一种轻量化的任务流编排引擎，专注于 Volcano 的作业编排，为Volcano 提供作业探针、作业完成依赖，作业失败率容忍等多样化作业依赖类型，并支持复杂的流程控制原语，具体能力如下：

• 支持大规模作业管理以及复杂任务流编排

• 支持实时查询到所有关联作业的运行情况以及任务进度

• 支持作业自动运行、定时启动释放人力成本

• 支持不同任务可以设置多种动作策略，当任务满足特定条件时即可触发对应动作，如超时重试、节点故障漂移等

JobFlow 任务运行演示如下：

关于 JobFlow 的更多信息，请参考：

https://github.com/volcano-sh/volcano/blob/master/docs/design/jobflow/README.md

节点负载感知调度与重调度支持多样化的监控系统​

Kubernetes 集群状态随着任务的创建和结束实时变化，在某些场景（如：增加、删除节点，Pod、Node 的亲和性改变，作业生命周期动态变化等），出现集群节点间资源利用率不均衡，节点性能瓶颈掉线等问题，此时基于真实负载的调度与重调度可以帮助我们解决上述问题。 Volcano 1.8版本之前，真实负载调度与重调度的指标获取仅支持 Prometheus，从1.8版本开始，Volcano 优化监控指标获取框架，新增 ElasticSearch 监控系统支持，并支持以较小适配工作量平滑对接更多类型监控系统。

关于支持多种监控系统的更多信息，请参考：

• 基于节点负载感知调度：

  https://github.com/volcano-sh/volcano/blob/master/docs/design/usage-based-scheduling.md

• 重调度：

  https://github.com/volcano-sh/volcano/blob/master/docs/design/rescheduling.md

优化Volcano对微服务调度的能力​

增加Kubernetes默认调度器插件开关​

Volcano 是一个统一的融合调度系统，不仅支持 AI、BigData 等计算类作业，也支持微服务工作负载，兼容 Kubernetes 默认调度器的 PodTopologySpread、VolumeZone、VolumeLimits、NodeAffinity、PodAffinity等调度插件，Kubernetes 默认调度插件能力在 Volcano 中默认开启。 自 Volcano 1.8 版本开始，Kubernetes 默认调度插件可以通过配置文件的方式自由选择打开和关闭，默认全部打开，如果选择关闭部分插件，比如：关闭PodTopologySpread 和 VolumeZone插件，可以在 predicate 插件中将对应的值设置为 false，配置如下：

actions: "allocate, backfill, preempt"
tiers:
- plugins:
    - name: priority
    - name: gang
    - name: conformance
- plugins:
    - name: drf
    - name: predicates
      arguments:
      predicate.VolumeZoneEnable: false
      predicate.PodTopologySpreadEnable: false
    - name: proportion
    - name: nodeorder

更多信息，请参考：

https://github.com/volcano-sh/volcano/issues/2748

增强ClusterAutoscaler兼容性​

在 Kubernetes 平台中，Volcano 除了作为批量计算业务的调度器之外，也被越来越多的用作通用服务的调度器。Node 水平伸缩（ClusterAutoscaler）是Kubernetes 的核心功能之一，在面对用户业务量激增和节省运行成本方面发挥重要作用。Volcano 优化作业调度等相关逻辑，增强与 ClusterAutoscaler 的兼容互动能力，主要为以下两个方面： 调度阶段进入 pipeline 状态的 pod 及时触发扩容 候选节点分梯度打分，减少集群 terminating pod 对调度负载的影响，避免pod 进入无效 pipeline 状态，从而导致集群误扩容

更多信息，请参考：

https://github.com/volcano-sh/volcano/issues/3000 https://github.com/volcano-sh/volcano/issues/2782

精细化管理Node资源，增强韧性​

当节点中由于某种原因比如 device-plugin 上报信息异常，出现节点的某种资源总量小于已分配资源量时，Volcano 认为该节点数据不一致，会隔离节点，停止向该节点调度任何新的工作负载。在1.8版本中，对于节点资源进行精细化管理，比如：当节点的 GPU 总资源容量小于已分配资源量时，申请 GPU 资源的 pod 禁止再调度至该节点，申请非 GPU 资源的作业，将仍然允许正常向该节点调度。

更多信息，请参考：

https://github.com/volcano-sh/volcano/issues/2999

优化Volcano charts包的发布与归档​

随着 Volcano 在用户越来越多的生产环境和云环境中使用，简洁标准的安装动作至关重要。自1.8版本开始，Volcano 优化 charts 包发布归档动作，标准化安装使用流程，并完成历史版本（v1.6、v1.7）向新 helm 仓库的迁移，使用方式如下：

• 添加 Volcano charts 仓地址

helm repo add volcano-sh https://volcano-sh.github.io/helm-charts

• 查询所有可安装的 Volcano 版本

helm search repo volcano -l

• 安装最新版 Volcano

helm install volcano volcano-sh/volcano -n volcano-system --create-namespace

• 安装指定版本 Volcano，比如：1.8.2

helm install volcano volcano-sh/volcano -n volcano-system --create-namespace --version 1.8.2

关于 Volcano charts 包的更多信息，请参考：

https://github.com/volcano-sh/helm-charts

致谢贡献者​

Volcano 1.8.2 版本包含了来自 33 位贡献者的数百次代码提交，在此对各位贡献者表示由衷的感谢：

贡献者 GitHub ID：

参考链接

Release note: v1.8.0

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

Release note: v1.8.1

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

Release note: v1.8.2

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

Branch：release-1.8

https://github.com/volcano-sh/volcano/tree/release-1.8

深入了解Volcano​

Volcano 云原生批量计算项目主要用于 AI、大数据、基因、渲染等诸多高性能计算场景，对主流通用计算框架均有很好的支持。社区已吸引5.8万+全球开发者，并获得3.5k+ Star 和800+ Fork，参与贡献企业包括华为、AWS、百度、腾讯、京东、小红书、博云、第四范式等。目前，Volcano在人工智能、大数据、基因测序等海量数据计算和分析场景已得到快速应用，已完成对 Spark、Flink、Tensorflow、PyTorch、Argo、MindSpore、Paddlepaddle 、Kubeflow、MPI、Horovod、mxnet、KubeGene、Ray 等众多主流计算框架的支持，并构建起完善的上下游生态。

Volcano是业界首个云原生批量计算项目，2019年由华为云捐献给云原生计算基金会（CNCF），也是CNCF首个和唯一的孵化级容器批量计算项目。主要包含以下能力：

• 面向人工智能、大数据、HPC场景提供统一的高性能作业管理，支持丰富的高阶调度策略，包括在离线统一调度、AI弹性训练调度、SLA、作业拓扑、Fairness、负载感知、重调度、抢占、回收等；
• 对Spark、Flink、Pytorch、MPI、TensorFlow等工作负载实现统一生命周期管理，作业依赖、作业内任务依赖管理；
• 在细粒度资源管理方面，Volcano支持min-max队列资源管理，提供队列资源预留、多租户资源租借/抢占的动态资源共享等能力；
• 在异构资源管理方面，Volcano实现 x86、Arm、GPU、昇腾、昆仑等多元算力的统一调度，并提供CPU/GPU资源的精细化调度能力，用户可根据业务需求灵活搭配资源，实现最高性价比。

Volcano目前已吸引 5.8万+全球开发者，并获得 3.2k Star 和 730+ Fork，参与贡献企业包括华为、AWS、IBM、百度、腾讯、京东、小红书、第四范式、博云、DaoCloud、锐天投资、七牛云、银清科技、字节跳动、快手、云知声、Infosys、Visa、网易、Red Hat、金山云、浪潮、中兴、Oracle、爱奇艺等。

Volcano已实现 50+生产落地案例，广泛分布于互联网、先进制造、金融、生命科学、科研、自动驾驶、医药等行业，覆盖人工智能、大数据、基因测序、渲染等海量数据计算和分析场景。主要用户包括：腾讯、亚马逊、荷兰ING银行、百度、小红书、滴滴、360、爱奇艺、中科类脑、鹏程实验室、Curise、理想汽车、云知声、喜马拉雅、唯品会、希望组、BOSS直聘等，随着Volcano社区的生态圈不断扩大，越来越多的用户表达了加入社区的强烈意愿，为帮助用户快速融入社区，加速落地实践，共同打造繁荣的社区生态， 华为云携手11家合作伙伴启动Volcano社区共建计划。

华为云开源业务总经理邓明昆表示： “云原生批量计算项目Volcano自2019年6月开源以来，在人工智能、大数据、基因测序、渲染、转码、音视频、金融等领域得到越来越广泛的应用，一批行业标杆用户不仅积极地推动Volcano落地生产环境，也基于自身实践反哺社区，华为云希望携手合作伙伴启动Volcano社区共建计划，共同打造繁荣的社区生态，帮助更多企业加速云原生的进程。”

首批加入的合作伙伴有：百度、博云、第四范式、唯品会、锐天投资、中科类脑、品览、360、网易数帆、喜马拉雅、BOSS直聘

百度飞浆开源技术生态负责人 周倜表示： “为了提升飞桨框架的计算效率，飞桨团队和Volcano团队联合发布PaddlePaddle on Volcano方案。作为一个面向高性能计算场景的平台，Volcano弥补了Kubernetes 在机器学习、深度学习、HPC、大数据计算等场景下的基本能力缺失，并在原有Kubernetes能力基础上对计算任务的批量创建及生命周期管理、Fair-share调度等方面做了增强，从而满足飞桨对资源创建，资源调度的基本要求。”

博云PAAS产品线总经理 赵安全表示： “博云高性能算力解决方案为多个客户提供了运行 AI、big data、仿真计算等应用的高并发计算基础平台，切实解决了众多行业痛点，方案支持的CNCF Volcano调度引擎得到了众多客户的认可。秉持“取之于社区，回馈于社区”的理念，我们将行业首个用于高性能算力的作业编排组件JobFlow捐献给 Volcano 社区，便于用户更好地应用云原生技术。”

第四范式异构算力虚拟化负责人 李孟轩表示： “Volcano项目使得我们能以较低的成本解决AI项目在云原生落地的过程中遇到的痛点，尤其是在设备复用领域，使用Volcano将会为集群资源使用率带来显著的提升。第四范式将持续的为volcano项目贡献代码，目的是将volcano打造成一个支持所有主流异构算力（NPU，GPU，MLU，DCU等）的复用平台。

唯品会AI云平台负责人 何颖鹏表示： “作为国内TOP级的电商平台，随着业务发展，唯品会面临业务体量快速增长、产品快速迭代、产品模式多样化等问题。通过构建基于Volcano的AI训练平台，结合queue动态资源共享、gang-scheduling等Volcano提供的高阶调度能力，可支持系统10多万核的节点调度，加速了业务创新步伐。”

中科类脑研发中心负责人 常峰表示： “Volcano是最早针对批量计算场景开源的云原生项目之一，其动态可配的高级调度策略和优秀的资源管理能力解决了AI场景下作业调度、生命周期管理、异构硬件支持等多个问题。在落地实践的过程中，我们基于Volcano的能力做扩展，有效提升了系统稳定性和资源利用效率。”

品览联合创始人&CTO 彭靖田表示： “CNCF Volcano 项目成功应用于品览的 云原生智能建筑设计产品：筑绘通AlphaDraw。在CAD二维图纸的AI识图翻模和三维建筑模型的智能设计等业务场景中，Volcano为AlphaDraw的算法服务提供了批处理和弹性伸缩负载的能力，大幅提升了Kubernetes集群资源利用率，同时优化了工作负载性能。作为Volcano社区共建计划的首批成员，品览会将 Cloud+AI 在建筑设计领域的最佳实践，持续贡献给开源社区。期待AlphaDraw与Volcano项目共同成长，未来不断为智能云计算和产业云落地提供更多优秀的产品和解决方案。”

网易数帆云原生技术专家 王新勇表示： “Volcano为Kubernetes的原生能力提供了许多有益的补充，使其能够更好地编排AI训练、大数据计算等批处理任务。Volcano良好的任务抽象和管理能力，多种场景化的调度机制支持，以及与多种常见的开源计算框架集成，开箱即用，使我们能够更加专注于为用户提供业务价值，而无需花费大量精力去重复造轮子。”

锐天投资基础架构团队负责人表示： “Volcano补全了原生Kubernetes批处理任务调度、资源共享、公平调度策略等能力，并提供统一的接口降低学习和维护成本。在生产环境中，Volcano配合我们自研的二级调度，实现了每日数万任务的需求，大大提升了策略研究的效率。”

360容器团队负责人表示： “Volcano弥补了Kubernetes原生调度在机器学习，大数据计算任务上的能力缺失，丰富的调度插件，以解决不同场景下的任务调度，极大提升集群整体利用率。且支持大部分主流的计算框架，诸如Spark,Tensorflow,Flink等。整体设计遵循Kubernetes的设计理念和风格，降低学习成本。”

喜马拉雅AI云团队负责人表示： “Volcano补全了原生Kubernetes批处理任务调度、资源共享、公平调度策略等能力，并提供弹性调度能力。在生产环境中，作为机器学习平台资源调度的基础组件，提升了GPU利用率。”

BOSS直聘AI基础平台团队负责人表示： “BOSS直聘基于Volcano在AI、大数据计算等场景构建基础设施，其强大的批处理能力和丰富的调度策略，为我们支撑复杂业务场景提供了极大的便利，大幅提升集群资源利用率和稳定性。在其丰富的生态和广泛的社区的支持下，为我们的技术和业务发展提供了极大的帮助。”

我们期待着与更多的组织共建Volcano社区的繁荣！

为帮助用户快速融入社区，加速落地实践，共同打造繁荣的社区生态，Volcano社区现推出Volcano社区共建计划。

通过Volcano社区共建计划，你将获得技术指导、宣传推广等支持，线上/线下技术布道分享等机会！如果你的公司、组织认可Volcano的技术路线，希望在使用Volcano的过程中获得帮助，并有意和Volcano社区共建技术影响力，请考虑加入该计划。

关于加入该计划的要求与权益详情，请参考：https://github.com/volcano-sh/community/blob/master/community-building-program.md

申请流程​

• 扫描二维码或点击阅读全文填写申请表单

• 结果将通过邮件通知，请耐心等待

任何疑问和问题，请联系Volcano社区 Maintainer: wang.platform@gmail.com

北京时间2023年1月9日，Volcano社区v1.7.0版本正式发布。此次版本增加了以下新特性：

• Pytorch Job强化功能插件
• Ray on Volcano
• 增强Volcano对Kubernetes通用服务的调度能力
• 支持Volcano的多架构镜像
• 优化队列状态信息等

Volcano是业界首个云原生批量计算项目，于2019年6月在上海KubeCon正式开源，并在2020年4月成为CNCF官方项目。2022年4月，Volcano正式晋级为CNCF孵化项目。Volcano社区开源以来，受到众多开发者、合作伙伴和用户的认可和支持。截止目前，累计有490+全球开发者向项目贡献了代码。

Volcano v1.7.0 关键特性介绍​

1. Pytorch Job 强化功能插件​

Pytorch是当下最流行的AI框架之一，已被广泛应用于计算机视觉，自然语言处理等深度学习领域，并且已有越来越多的用户开始以容器化的方式在Kubernetes上运行Pytorch来获得更高资源利用率和并行效率。

本次1.7版本提供了Pytorch Job强化功能插件，免去了容器端口、MASTER_ADDR、MASTER_PORT、WORLD_SIZE、RANK环境变量等众多繁琐的手动配置环节，让用户可以用极简的方式在Volcano上运行Pytorch Job。

Volcano社区当前提供了TensorFlow、MPI和Pytorch等Job强化功能插件，帮助用户更简洁高效的运行对应的训练框架和计算作业。

此外，Volcano还提供了Job插件的扩展开发框架，满足高阶用户针对复杂场景定制Job插件的需求。

设计文档：Pytorch-plugin
用户手册：PyTorch 插件用户指南
Issue：#2292

2. Ray on Volcano​

Ray 是一个用于扩展 AI 和 Python 应用程序的统一框架，可以在任何机器、集群、云提供商和 Kubernetes 上运行，并具有不断发展完善的社区生态。

当前，机器学习工作负载的计算密集度越来越高，单节点开发环境已无法满足训练任务在资源上的需求，Ray可以将同一套代码从单机运行无缝扩展到集群中运行。Ray是面向通用场景进行的设计，可以高效运行任何类型的工作负载。

该特性实现Volcano和Ray的协同工作，使用Volcano为Ray提供批量调度功能。目前该特性已在KubeRay v0.4版本正式发布。

用户手册：KubeRay-integration-with-Volcano
Issue：#2429， #213

3. 增强Volcano对Kubernetes通用服务的调度能力​

在不同的业务场景下，调度器发挥的价值与能力各有不同。比如，在批量计算场景中，Volcano的调度策略和能力更为丰富；通用服务调度场景中，Kubernetes默认调度器的能力更为均衡。但用户的集群中通常不会只运行一种类型的任务，在既有批量计算任务运行，又需要调度通用服务的场景下，如何兼顾不同类型任务的调度是一项值得研究的工作。

从1.7版本开始，Volcano提供对Kubernetes 默认调度器完全兼容的能力，可用于调度管理长期运行的服务。通过本次功能强化，用户可以使用 Volcano 统一调度长时间运行的服务和批处理工作负载。

重点增强项如下：

• Volcano的 scheduler 和 webhook 支持多调度器
• 支持 NodeVolumeLimits 插件
• 支持 VolumeZone 插件
• 支持 PodTopologySpread 插件
• 支持 SelectorSpread插件

另外，本次版本将对Kubernetes的支持升级到了v1.25。

Issue： #2394，#2510

4. 支持Volcano的多架构镜像​

该特性通过交叉编译实现一键化编译Volcano多架构镜像功能，比如，可以在amd64架构机器上，一键化编译amd64和arm64架构的Volcano基础镜像，并上传至镜像仓库。用户安装部署时，会根据自身环境中机器架构自动选择合适的镜像运行，对开发者和用户更友好。

使用手册：building-docker-images
Issue：#2435

5. 优化队列状态信息​

该特性在队列状态信息中增加已分配资源实时统计功能，通过该功能，用户可以实时查看队列的资源分配情况，方便管理员动态规划资源，使集群资源得到最大化利用。

Volcano通过队列的方式对集群资源进行分配管理，使用Capability字段来限制每个队列的资源上限，这是我们进行队列资源分配的硬约束。

当前，在集群运行过程中，用户无法清楚的了解到队列中已分配资源和Capability中空闲资源的详细信息，有可能会在队列空闲资源不足时提交大量工作负载，导致作业挂起和autoScaler非预期的触发集群扩容，从而增加云资源的使用成本。通过该特性中新增加的状态信息，用户可以更清晰有效的管理集群资源，控制使用成本。

Issue：#2571

致谢贡献者​

Volcano v1.7.0 版本包含了来自29位贡献者的数百次代码提交，在此对各位贡献者表示由衷的感谢：

贡献者 GitHub ID：

相关链接​

Release note：v1.7.0
Branch：release-1.7

深入了解Volcano​

Volcano云原生批量计算项目主要用于 AI、大数据、基因、渲染等诸多高性能计算场景，对主流通用计算框架均有很好的支持。社区已吸引2.6万+全球开发者，并获得2.8k Star和670+ Fork，参与贡献企业包括华为、AWS、百度、腾讯、京东、小红书等。目前，Volcano在人工智能、大数据、基因测序等海量数据计算和分析场景已得到快速应用，已完成对Spark、Flink、Tensorflow、PyTorch、Argo、MindSpore、Paddlepaddle 、Kubeflow、MPI、Horovod、mxnet、KubeGene、Ray等众多主流计算框架的支持，并构建起完善的上下游生态。

2022年10月26日，ING集团在北美KubeCon发表了《Efficient Scheduling Of High Performance Batch Computing For Analytics Workloads With Volcano - Krzysztof Adamski & Tinco Boekestijn, ING》主题演讲，重点介绍了云原生批量计算项目Volcano如何在数据管理平台中为大数据分析作业提供高性能调度工作。详情参见：KubeCon + CloudNativeCon North America

ING背景介绍​

ING集团（荷兰语：Internationale Nederlanden Groep），亦名荷兰国际集团，是一个国际金融服务私营企业，成立于1991年，由荷兰最大的保险公司Nationale-Nederlanden，与荷兰的第三大银行NMB PostBank Group合并而成。

ING集团的服务遍及全球40多个国家，核心业务是银行、保险及资产管理等。ING集团的全球职员大约56,000人，顾客5320万人，包括自然人、家庭，企业、政府及其他等，例如基金组织。

业务背景介绍​

在银行行业有许多法规和限制，如：监管要求在全球范围内各不相同、数据孤岛-全局和本地限制、数据安全、合规创新等，想要快速引入新技术不是一件容易的事情，为此，ING布局符合自身产业的DAP平台（Data Analytics Platform），为全球50%的ING员工提供安全的、自助的端到端分析能力，帮助员工在数据平台之上构建并解决业务问题。

2013年开始我们有了数据平台的概念，2018年通过引入云原生技术打造新一代基础设施平台，从那时起，平台需求有了稳定的增长，采用率也在持续提升，目前数据索引平台上的项目已超过400个。 我们所构建的平台目标是在高度安全的自助服务平台中完成所有分析需求，并且具备以下特点：

• 开源工具模型
• 强大的计算能力
• 严格的安全和合规措施
• 所有的分析集中在同一个平台
• 满足全球和本地需求

挑战与方案​

目前我们在由传统的Hadoop平台向kubernetes过渡，但是对于作业管理和多框架支持方面还存在一些挑战，如下：

• Job的管理
  • Pod级调度，无法感知上层应用
  • 缺乏细粒度的生命周期管理
  • 缺乏任务依赖关系，作业依赖关系
• 调度
  • 缺少基于作业的调度，如：排序、优先级、抢占、公平调度、资源预定等
  • 缺少足够的高级调度算法，如：CPU拓扑、任务拓扑、IO-Awareness，回填等
  • 缺少对作业、队列、命名空间之间资源共享机制的支持
• 多框架支持
  • 对Tensorflow、Pytorch等框架的支持不足
  • 对每个框架部署（资源规划、共享）等管理比较复杂
  • 利用kubernetes来管理应用服务（无状态应用、甚至是有状态应用）是非常方便的，但是对于批量计算任务的调度管理不如yarn友好，同样yarn也存在一些限制，比如对新框架的支持不够完善，比如TensorFlow、Pytorch等，为此，我们也在寻找新的解决方案。

Kubernetes + Hadoop 在我们之前的集群管理上，会把Hadoop和Kubernetes的调度分开，基本上所有的spark作业都会运行在Hadoop集群中，其他的一些任务和算法会运行在Kubernetes集群，我们的目标是希望所有的任务全部运行在Kubernetes集群，这样管理起来会更简单。

Kubernetes和YARN共同工作时，由于Kubernetes和Hadoop资源是静态划分的，在正常办公时间，Hadoop应用和Kubernetes各自使用自身分配资源，即便spark任务压力大也无法借用更多资源。夜晚时间，集群中仅有批处理任务，Kubernetes资源全部空闲，却无法分配给Hadoop进行有效利用，对于调度平台来讲，这不是一种最佳的资源分配方式。

Kubernetes with Volcano 使用kubernetes管理整个集群，通过Volcano进行spark任务调度，此时不需要再对资源做静态划分，集群资源可根据Pod、Batch、Interactive任务的优先级、资源压力等进行动态调整，集群整体资源利用率得到极大提升。

比如在正常办公时间内，常规服务应用资源空闲的情况下，Batch和Interactive应用资源需求增多时，可以暂时借用常规服务的资源；在假期和夜晚休息时，Batch业务可以使用集群所有资源进行数据计算，集群资源利用率得到极大提升。

volcano是专为kubernetes而生的批处理调度引擎，其提供了以下能力：

• 加权优先级的作业队列
• 如果集群具有备用容量，可提交超过队列资源限制的任务
• 当更多的pod被调度时，具备抢占能力
• 丰富可配置的工作负载调度策略
• 兼容YARN的调度能力

Volcano的引入，补齐了kubernetes平台对批处理作业的调度管理能力，并且自Apache Spark 3.3版本以来，Volcano被作为Spark on Kubernetes的默认batch调度器，安装使用更方便。

业务常用特性​

冗余与局部亲和 Volcano保留kubernetes中pod级别的亲和性反亲和性策略配置，并增加了task级别的亲和性和反亲和性策略

DRF调度算法的全称是Dominant Resource Fairness，是基于容器组Dominant Resource的调度算法。volcano-scheduler观察每个Job请求的主导资源，并将其作为对集群资源使用的一种度量，根据Job的主导资源，计算Job的share值，在调度的过程中，具有较低share值的Job将具有更高的调度优先级。

比如集群资源总量为CPU：18C，Memory：72GB，两个用户分别是User1和User2，每个User分配1个队列，在提交作业时会根据主导资源计算job的调度优先级。

• User1: CPU share值为 6/18=0.33，Memory share值为 24 / 72 = 0.33，最终share值为0.33
• User2：CPU share值为 12/18=0.67，Memory share值为 24 / 72 = 0.33，最终share值为0.67

DRF策略在任务调度时，优先分配share值较低的Job，即User1所申请的资源。

集群内队列资源可以通过配置权重值进行划分，但是当本队列提交任务超出队列分配的资源，并且其他队列存在资源空闲时，可以进行队列间资源共享。即User2在使用完本队列CPU资源后，可以使用User1队列内的空闲CPU资源。当User1队列提交新任务需要CPU资源时，将会触发抢占动作，回收User1被其他队列借用的资源。

避免资源匮乏 在使用过程中，需要避免批量计算任务与自有服务出现资源抢占与冲突的问题。比如：我们集群中有两个可用节点，集群中需要部署一个统一的服务层对外提供服务，比如Presto，或者类似Alluxio的缓存服务。但是在批量计算调度时，集群的资源空间有可能全部被占用，我们将无法完成自有服务的部署或升级，为此我们增加了空间可用系数相关配置，为集群预留一些备用空间，用于自有服务的部署使用。

DRF 仪表盘 我们根据volcano的监控数据做了一个drf调度的仪表盘，在不同层次显示更细粒度的调度信息。在业务集群中，我们有一个队列存放交互式用户的任务，另有队列存放平台运行的所有重大项目的计算任务，我们可以为重大项目队列提供一定的资源倾斜，但是此时对交互式用户的任务将不会太友好。

目前我们正在考虑增加集群高峰时段展示的功能，为用户提供更多的集群使用状态和压力等信息，在自助服务平台用户视角来看，用户按照集群的繁忙程度选择自己任务的开始时间，这样可以避免后台复杂的配置就可以获得高性能的运算体验。

总结​

volcano对批处理任务调度做了很好的抽象，使我们在kubernetes平台能够获得更高的调度性能，后面我们也会将开发的功能逐步回合社区，比如：DRF Dashboard、在每个节点添加空闲空间、自动队列管理、更多的Prometheus监控指标、Grafana仪表盘更新、kube-state-metrics更新和集群角色限制等。

本文2021年9月6日首发于容器魔方微信公众号，原文链接Volcano v1.4.0-Beta发布，支持NUMA-Aware等多个重要特性

北京时间9月4日，CNCF首个批量计算项目Volcano发布v1.4.0-Beta版本。该版本发布了“支持GPU节点多维度资源比例分片”、“支持NUMA-Aware”、“支持多调度器混合部署”等多个重要特性，并在稳定性方面具有显著提升。

支持GPU节点多维度资源比例分片​

“支持GPU节点多维度资源比例分片”是该版本具有重大意义的特性之一，主要用于解决GPU节点因CPU等其他维度资源过度使用引起GPU作业饥饿但GPU资源空闲浪费的问题。该特性由Volcano社区合作伙伴中科类脑贡献。在传统调度器中，GPU等稀缺资源在进行分配时与CPU等资源离散考虑，即CPU型作业可直接分配到GPU节点而不会考虑GPU作业的CPU、内存需求，不会为其预留资源。在该特性中，允许用户设置一个主导型资源（通常设置为GPU），并可为它配置配套资源维度的预留比例（如GPU:CPU:Memory=1:4:32）。调度器在工作时将会时刻保持GPU节点上GPU、CPU、Memory的空闲资源比例不低于该设定值，因此任何时刻符合该比例需求的GPU作业均可调度到该节点，而不会引起GPU浪费。这一方法较业界其他解决方案，如GPU节点分配独立调度器、CPU型作业强制不允许调度到GPU节点等，更有利于提高节点资源利用率，使用也更加灵活。

特性设计和使用方式请参考：https://github.com/volcano-sh/volcano/blob/master/docs/design/proportional.md

支持CPU NUMA-Aware​

“支持CPU NUMA-Aware”是该版本的另一个重大特性。对于AI、大数据等计算密集型作业来说，启用NUMA特性将显著提升运算效率。该特性实现了CPU NUMA感知调度。用户可通过配置NUMA策略决定是否为工作负载启用NUMA。调度器将根据诉求选择满足NUMA要求的节点。

特性设计和使用方式请参考：https://github.com/volcano-sh/volcano/blob/master/docs/design/numa-aware.md

支持多调度器混合部署​

“支持多调度器混合部署”特性允许用户在Kubernetes集群中同时部署不同类型的调度器，并合理进行调度分工。最常见的工作方式为default-scheduler和Volcano混合部署。用户可以将Kubernetes原生资源类型，如deployment、statefulset等，分配给default-scheduler进行调度；将Volcano Job、TF Job、Spark Job等高性能计算负载分配给Volcano进行调度。该方案不仅能充分发挥各调度器的优势，也能很好的降低单调度器的并发压力。

特性设计和使用方式请参考：https://github.com/volcano-sh/volcano/blob/master/docs/design/multi-scheduler.md

除上述特性，v1.4.0-Beta还新增了压力测试自动化框架，并修复了因资源比较函数鲁棒性引入的多个bug等。社区正在进行v1.5的路标特性征集，已征集到的特性包括集群资源监控、支持层级队列、Spark集成能力增强、支持Task依赖等，欢迎有兴趣的开发者issue反馈。

本文首发于容器魔方微信公众号，原文链接锐天投资基于Volcano的大规模分布式离线计算平台的应用实践

业务场景与技术选型​

业务场景

• 为策略人员提供研究以及开发的虚拟机

• AI训练与推理

• 数据ETL

• 通用的分布式批处理任务

Why Use Kubernetes？

分布式批处理任务平台用于管理计算资源和存储资源。对计算资源而言，我们最终选用了Kubernetes来进行管理，主要原因有以下几点：

• 通过 Container 隔离用户环境:我们公司大概有4~5组不同的用户，其使用的开发环境、开发策略都是不同的，这对于整体集群环境管理而言是非常大的挑战，使用Container后，所有的环境可以封装在Container，直接通过k8进行调度，来解决环境隔离问题。

• 通过 Device Plugin 支持 GPU 等异构设备

• ETCD 的中心式数据存储机制

• 活跃健全的技术生态

• Go 语言符合公司技术栈

Why Use CephFS

存储部分我们使用的是CephFS，它是ceph提供的分布式文件存储的一种接口形式，ceph本身提供三种存储接口：S3、快存储以及CephFS。我们使用CephFS主要有以下几点原因：

• Posix Filesystem 权限与接口：对于我们所有人而言，最熟悉最自然的文件存储及获取方式是本地文件系统，而CephFS可提供稳定文件系统挂载。并且对我们这个行业而言，所有的用户多租户的情况下，每个用户他有自己的一个uid，每个用户他自己的数据都只能自己来访问。那么Posix Filesystem的一个权限机制，可以让用户无缝的把自己的文件权限迁移到sap上。

• 强一致性：在 a节点写入一个文件，在b节点可直接读取。

• 同时支持大规模小文件存取与大带宽 IO

• 层级化硬件支持

• Kubernetes ReadWriteMany PV

Why Volcano​

Why not default-scheduler

Default-scheduler无法满足我们需求的原因有4点：缺少队列调度、缺少公平调度、缺少多租户隔离、缺少高级调度策略，如Gang-Scheduling。最重要的是公平调度和高级调度策略。所谓的公平角度，是指当有很多人提交了非常多的任务排队正在等待时，应该来运行谁的任务？当集群空出来或有资源时，到底应该运行谁的任务？要完成这一点，每个队列映射于一个团队，基于队列的公平角度，每一个namespace对应一个用户，基于用户的公平调度，这两点都是必不可少的。所以在这两点上，default-scheduler完全没有办法满足我们的需求。

因此我们求助了社区。kube-batch是社区下面的批处理调度器，它只是一个调度器，不提供除调度以外的任何解决方案，这也是我们没有使用kube-batch的最主要原因。要做一个批处理方案，不只需要调度器的功能，还需要对于环境及其他任务 CRD做一系列处理。没有及时处理的话很难作为平台来使用。

Why is Volcano

• 支持公平调度

• 支持丰富的高级调度策略，如 Gang-Scheduling、Binpack 等

• 支持通过 SSH plugin 方式实现 Pod 互访

• 支持通过 ENV plugin 方式向 Pod 注入任务依赖，天然支持 Tensorflow Worker Sharding

• 支持 SVC plugin 方式对外提供服务

有了这样一个调度平台，基本可以满足我们的整体需求。

系统架构​

服务架构

• 基于 Ceph 提供高性能存储

• 基于 Kubernetes 管理多种异构硬件

• 通过 Loki + Grafana 同时作为用户面板与监控面板

• 中间件与应用层混部，充分使用集群资源

• 基于 Batch Job 形式，扩展多种业务场景

多租户

用户提交任务还会遇到多租户的问题。例如用户提交一个pod到集群，这个pod运行用户与Uid是什么？默认情况下，它的运行用户Uid是image制造者的Uid,相当于所有用户提交的pod的Uid变成同一个人,这是不行的，因为他们获取的数据和生成的数据互相之间是不能看的。

在这种情况下，我们的解决方案是通过K8s Namespace做整个用户所有资源的隔离，namespace对应于一个用户，通过已有的LDAP服务和OIDC与开发信息对接，给用户一个认证，通过RBAC进行用户资源的授权，授权用户使用以下的一个Pod Security Policy，Pod Security Policy是直接限制用户提交时，必须采用SecurityContext写上其uid与gid是什么？用户运行时整个的环境全部以此为准。

有了Pod Security Policy后，用户提交的pod必须以其uid和gid进行体现。但访问的数据都在Ceph上，也就是其gid和uid所能够访问的数据。以此来解决多租户的问题。

工作流

解决刚才所有的问题后，基础的工作流就出现了。本地渲染 Job Yaml 进行提交，用户所有的依赖数据同步 CephFS，并通过 PVC挂载 Pod，每个用户 Namespace 下，拥有自己目录的 PVC 权限，全部是通过IBS进行权限管控，以此来提交任务到整个集群运行。

Volcano 的深度定制​

基础的提交框架平台我们选择了直接给用户提供库的形式，自研提交工具Jobctl，其开发完成后，自动支持两种使用方式，一种是命令行里面直接使用,另外一种是作为Python列表input到用户本身的notebook进行使用或直接体现到自己的Python脚本。Jobctl同时支持两种提交状态形式，一种是异步的，也就是说不停的向整个集群提交任务，任务提交完成后可直接退出；另一种是同步，job control提交完一个任务后，并且watch这个任务，当任务全部结束后，才返回给用户，这是返回给用户的工作流。

有了Jobctl后，还可以对用户隔离整个K8s复杂性,同时支持命令行提交和 Python Lib 集成,并且提供最基础的按 replicas 并行与按天并行。

OOM Auto Scale Up

首先做的第一个定制是OOM的时候对整个任务进行资源Scale Up，因为用户不能很好预估内存，OOM 后需要重复提交验证，因此我们通过直接定制 OOMKill Auto Scale Up ，通过修改Volcano Controller自动把OOMKill的pod所申请的资源按比例进行放大，放大后自动重复提交，并且提交完成后通知用户。按照这个功能让用户的整个任务在他自己不参与的情况下自动重复提交，得到合理内存申请值,这里其实使用了上文提到的Volcano policy event机制。

MinSuccess

• minAvailable 个 Pod 结束，则任务结束

• 非 Gang 的任务难以灵活调度

• minSuccess 个 Pod 结束，则任务结束

• 解耦 Gang 所需 Task 数量和完成 Job 所需任务数量

NodeZone

• 一个 Volcano 实例管理所有节点

• 无法解决 Noisy Neighbor

• 无法做紧急资源预留

• 多个 Volcano 实例，分别管理多个Zone

• 对某些任务做物理隔离

Volcano Namespace Quota

默认的k8s Quota并不能满足我们的需求，因为触发原生 Namespace Quota 时，Pod 直接 Fail，因此我们在Volcano级别做了Quota。

• 触发 Volcano Namespace Quota 时，Pod 排队延迟创建

Volcano 监控与报警

Volcano Exporter

• 输出 Task 的队列标签

• 输出队列 Capability

• 输出 Job 的开始完成时间

WatchDog 组件

• 注册 Informer，并收集 Metrics

• 负责任务失败与使用率报警

• 自动更新队列的 Capability

任务状态面板

上层来承载所有job的信息，并且会有一个状态表来表示任务完成情况，以此来大致判断任务的形式。下面的三点是CPU、memory和networks的资源使用情况。除了正坐标轴外，副坐标轴的一些竖线是指它浪费的集群资源。这些浪费的集群资源帮助用户实时判断任务运行状态的节点发生的浪费情况。所以我们需要通过这样的时间序列状态表，来提醒用户。

集群资源面板

通过graph的话，对整体队列资源、 CPU、memory以及所有队列资源的使用，用户需要看到所有节点的资源使用情况，因为有些非常大的消耗任务，比如一个任务有可能需要申请300或500的内存，但并不是所有的信息都支持单个节点内存使用的，所以只有总体的内存使用率是不够的，还需要有每个节点内存使用率。

高并发场景下的挑战与解决方案​

随着场景变多和平台用户的增加，我们发现了一些问题，集群规模单集群计算节点数量200 、存储总量1.5PB，读写带宽15GB/s、同时承载长时间任务（1week）与短时间任务（1min）、Pod 每日增长量10W ~ 30W，这是一个非常恐怖的规模。

问题1：单个Job对象过大

问题：

• 在有大量 Pod 时超过 ETCD Max Request Size (1.5MB)

• 直接调整 Max Request Size，大量的 Object对 ETCD 造成冲击

解决：

• 通过单个 Task 多 Replica 的形式提交任务

• Pod 内部通过 ENV plugin 插件提供的信息，以 Sharding 的形式读取参数

问题二：Out Of Cpu/Memory

问题：

• 节点数少 + 大量短时任务不停调度

• Kubelet PLEG 压力大，Pod Binding 时间过长

问题：

• 节点数少 + 大量短时任务不停调度

• Kubelet PLEG 压力大，Pod Binding 时间过长

• Volcano 默认 session 间隔时间为 1s，造成 Cache Snapshot不一致

• Out of CPU + Out of Memory

解决：

• 增加 Node Binding Task Number

• 在 Session 开始创建 Snapshot 时，跳过 Binding Task Number > 0 的 Node

上文提到各种各样的深度定制，包括bug fix和修改，我们都已提交给了社区，并且我们有一位成员已经成为 Volcano 社区 Approver。非常荣幸能够参与社区共同的改进，也希望更多的开发者能够加入Volcano社区。

本文2021年6月1日首发于容器魔方微信公众号，原文链接鹏城实验室启智章鱼教你彻底摆脱Kubernetes集群资源抢占难题

启智章鱼平台介绍​

启智章鱼（OPENI-OCTOPUS）是一个集群管理和资源调度系统，由鹏城实验室、北京大学 、中国科学技术大学进行开发和维护。

• 完全开源：遵守Open-Intelligence许可

• 利用Kubernetes部署、管理和调度

• 支持在集群运行AI任务作业，支持GPU，NPU，FPGA，华为升腾芯片，寒武纪MLU等硬件

• 适用于AI的高性能网络，支持IB网络

• 提供监控分析工具，包括网络，平台和AI作业的监控分析

• 支持主流的深度学习框架

• 采用微服务结构

最底层为硬件层，可接入多种不同类型的异构硬件，包括CPU、GPU、NPU、FPGA等。这需要对不同的硬件进行适配，以便于上一层的Kubernetes服务识别和统一管理。

往上一层为平台的中间层，左边是管理节点的功能，一个是kubernetes本身的功能，包括编排规划，控制管理，调度方面我们使用的是Volcano。然后通过api-server和我们开发集成的服务通信。

我们开发的rest-server模块负责系统的核心功能，并集成了Grafana,普罗米修斯等监控工具，ES日志工具，Jupyterlab代理，模型仓库等功能。

右边是计算节点的能力，计算节点上有镜像工厂、运维监控、作业监控、kubebox客户端、用户登进容器的Jupyterlab客户端。

最上层是系统所提供的服务，对用户而言它拥有数据引擎，模型仓库，项目中心的能力，还能通过异地互联的方式，为异地用户提供集群服务。

业务场景与挑战​

启智章鱼平台在设立之初直到目前主要是为实验室内外的科研团队服务。它们包含交通、医疗、金融等方面的模型开发，模型训练或者模型推理方面的需求。如一些车辆追踪算法，医疗影像识别，辅助诊断算法，金融领域的量化算法。这些各个领域的算法会用到一些深度学习的算法，对计算资源的要求比较高。

平台要解决传统平台的模型孤岛、数据孤岛、算力孤岛问题。

• 在模型层面，提供多态异构的模型引擎，支持常见的开源计算框架，并提供各种常见计算框架的模型转换的能力。

• 在数据层，提供多源异质数据引擎，支持异构数据融合，并且提供半自动数据标注的能力。

• 在资源层，提供AI分布式计算引擎，一方面是对异构硬件的统一表示，另外的重点是对作业的调度。

业务场景

• 业务以面向实验室内外的科研AI任务为主，包括智慧交通、医疗、金融等领域的算法训练与推理

• 高端异构硬件资源优势，150P+级算力集群和10PB级高速存储

• 支持快速和灵活部署，系统运行可靠稳定，方便外部团队使用

挑战

• 缺少一个高性能计算平台，满足复杂场景的业务诉求

• 高效利用异构硬件资源，支持灵活调度策略，需解决资源抢占难题，避免关键任务资源饿死现象

• 系统架构需可扩展，服务高可用

Why Volcano?​

针对这些挑战，我们在选型时主要考虑有以下几个方面：

1）首先自研还是开源。在调研了目前社区已有的开源项目之后，发现它们能够满足我们的基本诉求和对复杂业务场景的需求。

2）基于减少开发量的考虑，选择拿来主义。我们对比了常见的开源资源调度器。首先是K8S默认调度器，该调度器对批量调度并不友好，不能满足我们的要求。Yarn调度器是基于Hadoop的，而我们现在的架构已经转型为基于k8s，也不符合我们的要求。另外是kube-batch和volcano，kube-batch是volcano的前身，且volcano对深度学习支持比较友好，对各种常见计算框架的任务类型都有支持，另外它有一套插件化的调度策略实现机制，方便实现新的插件来开发我们的特定调度策略。

因此我们选择集成volcano，使用volcano的能力来应对启智章鱼面对的业务场景挑战。具体来说，volcano对我们有以下价值：

• 完善的架构和生态，社区反馈很及时，开发者比较多，发展很快

• 上文提到的插件机制，方便自定义新的调度策略

• Volcano支持任务队列的机制，这对我们很重要。我们基于任务队列，能够将集群进行逻辑分组，方便对用户进行项目制管理。一方面能够对不同项目配置不同限额的计算资源，另一方面能将不同类型的作业分到不同的任务队列中进行管理。对作业和计算资源的管理更加精细化。

• 可以使用Volcano的binpack等插件组成多种多样的调度策略，以binpack插件为例，其使用的装箱算法能够解决资源碎片的问题，能够很好的提高集群的整体使用率。

基于Volcano的二次开发​

Volcano虽然功能很强大，但为了能够进一步应对复杂的业务场景，我们也做了二次开发，新增了一些新的能力。

我们做的第一个二次开发是资源状态的统计与管理功能。这里的资源不单指集群计算资源，也指用户提交作业后，k8s服务中生成的Job、Task、Pod等资源。

我们需要对整个资源的状态信息，状态转换都有很好的掌握，并且可以自定义资源状态转换的条件与回调事件，可以在业务逻辑层订阅自定义的Event与相对应的Policy.

考虑以下的一种业务场景。有一种使用集成学习算法的训练任务，一般可以使用分布式的训练方式。它有一个结合模块，还有若干个体学习器，每个个体学习器使用一种算法来训练任务，结合模块结合各个个体学习器的结果，来输出最终结果。如果结合模块算出了最终的结果，整个训练任务就可以结束。在基于k8s的实现中，使用集成学习的训练作业整体是一个Job，结合模块和各个个体学习器都是这个Job下面的一个Task，Task下面可以再创建一个或者多个副本Pod。我们的场景需求是只要结合模块这个Task运行成功，就让整个Job退出，而不必等到所有的Task都成功再退出。那我们就需要针对这种场景，可以在调度器自定义一种Job退出的策略，并且可以在业务层面去使用。集成学习这个场景需要一种特定的策略，其他场景也需要相应的策略。这就要求我们去二次开发volcano调度器。

上图的交互图显示了启智章鱼，k8s，volcano之间关于作业状态的信息传递。

首先，volcano和启智章鱼都会一直监听k8s所有作业的状态；然后，用户提交了作业到k8s之后，volcano会根据监听到的k8s作业启动的pod状态去更新Job的状态；最后，启智章鱼监听到这些Job的状态改变，会去处理这些状态改变事件。

基于这个交互图，我们发现 问题的关键在于volcano如何去更新Job在k8s中的状态。

我们做了以下几点二次开发来实现目标：

1）实现Job，Task，Replica的三级别状态机

• 资源状态统计与回显更加详细

• 更加细粒度的Job生命周期管理

2）实现自定义Event和Policy，能够解决类似集成学习应用场景的问题，自定义一个Event叫做MainTaskEvent, 在确定的Task运行结束时在调度器发布这个事件来结束整个Job

3）实现生命周期回调钩子，可以在三个级别的状态机的任一状态转移事件中都加入回调钩子，以此支撑多样化的业务场景需求。例如我们的计费功能实现，就是基于Job的开始事件和结束事件来统计Job的运行时长。

Privilege Action

问题

• 任务队列资源饿死现象，大作业一直等待

• 紧急作业、关键作业需要优先调度

• 用户作业可能在线开发，不可随意终止

Volcano已有能力

• 同队列中不同优先级Job的抢占，无法区分Job所来自的租户身份

• 以Pod为单位进行驱逐

• 立即抢占

需求

• 同队列中作业来自不同租户，不同租户拥有不同优先级和抢占权限

• 以Job为单位进行驱逐

• 延时抢占

上图为延时抢占插件的流程图。最左边是插件在调度器的运行逻辑。中间是k8s服务，最右边是启智章鱼的核心模块。

具体的实现是在volcano中去找出具体需要被抢占的作业，这些作业所占用的计算资源要足够满足当前等待的优先作业。然后更新k8s中这些作业的状态，启智章鱼的核心模块一监听到这些状态改变，就会启动定时器来准备驱逐这些任务。如果定期器倒计时还没结束，抢占任务被取消或者抢占任务已经因为其他作业释放资源，满足了运行条件而不需要继续抢占，这个定时器也会被取消。

具体看下我们做了什么开发：

1）为每个作业增加了一个布尔属性，叫Preemt，表示这个作业是否为一个抢占作业。

• 队列内抢占作业只能抢占同个队列中优先级较低的作业。

2）以Job为单位进行驱逐，而不是以Pod为单位驱逐。

• 驱逐待选的Pod按照所属JobID排序，可减少受影响的Job数量

• 由调度器通知启智章鱼，在业务层对Job进行停止

3）延时抢占

• 为Job状态机增加Privileged和WillEvicted状态

• 进入Privileged和WillEvicted状态的Job不可被其他Job抢占

• 如果抢占或被抢占的Job状态发生变化，另一方的状态也要相应改变

收益​

能力增强

• 满足分布式大规模训练任务的需求

• 支持多种AI计算框架

• 插件化调度器，支持自定义开发，适应复杂业务场景

• 多队列调度，实现硬件资源的分组与组间动态资源分配

性能优化

• 硬件资源利用率大幅提高，达到90%以上

• 作业平均调度时延大幅降低，由使用Yarn调度器的平均任务等待时间60秒降到现在的10秒

• 系统稳定增强，集群节点资源利用率平衡度好，减少了节点间因资源使用差异度引起的运维工作

上图为系统在Grafana显示情况：

• 管理120+个节点，总GPU卡数为1.1K张，GPU在超负荷情况下使用率可达90%以上

• 各节点间资源利用率平衡性较好，差异度低于20%

• 2019年上线以来，运行作业数为12w+

本文2021年5月27日首发于容器魔方微信公众号，原文链接小红书基于Volcano的大规模离线与在线推荐模型训练实践

小红书背景介绍​

小红书是国内领先的生活分享社区，在女性用户当中比较受欢迎，现在也有越来越多的潮流男生加入了小红书社区，目前月活超过1亿。小红书是一个UGC社区，每天有大概几十万篇的笔记投稿，近百次的笔记曝光量。

首页的推荐功能是小红书的核心业务场景之一。在小红书刚创建的几年当中，推荐是完全人工精选，没有机器学习模型，也不是千人千面，每个人看到的内容都是差不多的。从2016年开始，我们进行千人千面的推荐探索。2018年上线了第一个基于SparkML和GBDT的推荐机器学习模型，大概只有几万个参数。从2018年底开始，我们加速模型的迭代，到2020年下半年，模型规模已经达到了几千亿参数的级别，我们也上线了在线学习，模型可小时级别更新，在今年4月份已达到了分钟级别，用户的行为可以在一两分钟之内被我们模型所抓获，然后产生更加适合用户的推荐，捕捉到用户更短期的兴趣爱好。

小红书搜索推荐广告场景下的大数据架构​

架构可以分为4个部分，左上角是客户端和在线服务与打点服务之间进行交互。用户在打开小红书APP之后，会请求一个在线服务，在线服务进行推荐，把当时推荐的笔记和请求的特征缓存，将推荐结果返回给客户端，用户在浏览推荐给他的笔记过程中，会产生一系列交互行为，交互行为会变成数据流，经过打点服务，落到原始打点数据流。

左下角主要是有两个任务归因和汇总，它们主要是实时的对用户行为做数据清洗和处理，生成标签数据流。标签数据流和测值数据流会做拼接，生成训练样本，同时也会生成我们大数据主要的三个产品，训练数据、OLAP数据库和离线Hive表。

右上角为在线和离线训练的部分，所谓在线训练会实时的对训练数据进行训练，产生模型的更新数据；离线训练会产生一个全量的模型更新到线上。

行为归因和标签

用户行为的归因和标签任务分为两个部分：归因和标签。归因主要是将用户在打点里每个行为和过去发生的行为关联起来。比如我小红书上看了4篇笔记，做了一个点赞，每篇笔记在打点当中其实是发生在不同的地方，比如发现页上面的曝光就会打点到发现页上面，如果用户有一个点赞，这个点赞其实是发生在笔记详情页，它并不是点击进去之后发生的，那么这个点赞其实也可以在不同的渠道发生，用户可能从发现页看到了这篇笔记，点击进去以后进行了点赞，可以是搜索了一些关键词，从搜索结果里进行了这篇笔记的点赞，同样也会进入到笔记详情页面，也可能从博主的个人页发现了这篇笔记点进去。

打点本身其实并没有告诉我们在点赞之前发生了什么，在归因的过程中，我们会根据用户数据行为流，将点赞之前的用户历史浏览记录，从而判断用户点赞行为的原因，补充归因这一列，这个就是归因。另外，用户关注了一个博主，为什么关注这个博主，在关注博主之前，他看过博主的哪些笔记，其实这些也是通过归因任务将这些标签给打上去的。

标签计算和归因相反，是用户产生某个行为之后，他进行了哪些动作，是对之后发生行为的汇总。用户在发现页浏览了4篇笔记，对于每篇笔记我们都会有几个标签，浏览之后有没有发生点击或点赞，如果点击会进入笔记详情页，在页面上停留了多长时间？这些其实都是我们后续模型训练很重要的标签数据，还有平时生成的用户日常报表，也是依赖这份标签数据的。

搜推广的实时大数据产品

产生标签数据时，大数据其实对于业务而言，主要提供了三个重要的大数据产品：

• 模型训练数据:用来实时训练模型，给出更加精准与实时的用户最新的兴趣爱好

• 用来做即席的数据分析和离线仓库，这两个其实都是通过标签数据来做分析，差别是即时分析是有非常实时需求的，比如在系统中做了任何改动与策略上的变化，我是希望能立刻从多维度切分去观测这个变化起了什么作用。而离线数据仓库更多的是日报或者周报，或者过去半年某些指标产生了什么变化。

在线和离线模型训练

标签数据和特征数据拼接之后产生的训练数据，分别进行离线和在线训练。这里有个差别是离线训练和在线训练用的同一份数据源，拼接之后会放到kafaka,kafaka的数据提供给在线做消费，在线数据消费kafaka后，它其实输出的是一个模型的更新数据流，这里其实是最近上一批次产生的对模型造成变化被实时的发布到在线。离线其实会做批量天级别的训练，会发布一个全量的迁移参数模型，同时更回到线上。

离线批量到在线流式计算的演进？​

Offline batch only

上图为最早的离线批量标签计算流程图，用户发现了点击行为后被收集下来，会落到ODS表，ODS表是原始日志的表，我们是通过Spark任务进行归因和标签计算，这完全是一个离线的批示任务。加工好之后的数据，会形成DW数仓的表，基于DW表我们产生了日报和实验报表的大数据产品。在批量环境下，这个其实是T+1生成的，每次实验的改动，一般到第二天或者第三天才能看完整的报表。

Offline Batch + Online Streaming

随着开发人员不断变多，对业务的实施性要求也逐渐变高，我们就发现了实时的链路，实时的链路是完全基于Flink框架做的。在实时链路中，它是通过流式kafaka输入，将数据输出到kafaka，同时会落到OLAP数据库和实时实验分析。这里我们有遇到一个挑战，同样的Spark框架和Flink框架，它是两个不同的编程框架。比如要判断某一个广告用户的点击是否是有效点击，这个有效点击的逻辑会稍微复杂一点，因为在点击进去之后，要产生互动行为或至少停留三秒以上，才算有效点击。

如果有两条数据流，往往会在离线实现一个逻辑，同时也会在Flink框架里也实现这样一个逻辑,实际上是同一个逻辑实现两遍会产生很多问题，一是有两份工作量，又要在Spark里开发，又要在Flink里开发。还有一个更大的问题是两边开发之后，逻辑可能会不一样。

对于一些比较复杂的场景会存在差别，最终造成报表和申请不一致。还有一些场景，比如数仓离线提出需求，只在Spark任务里实现了这个逻辑，但在离线没有实现，如果需要查看还要再重新实现，这都会造成额外的工作量。因为我们进行升级更新，所有新的标签不在spark上做计算了，完全在实时这条线进行计算。但实时有可能会出中断的问题，在中断之后，可能会从最新的开始，老的数据可能会产生变动。但离线遇到这种问题就比较简单，将每小时数据重新运行，就会产生一份完整的数据。

我们其实要解决一个技术问题:如何让同样实时的Flink训练任务从离线的数仓表里,转成实时的流表，用同样的计算逻辑生成一份新的数据重回再写回这个表，就保证实时和离线的核心逻辑只在实时实现一份即可，解决了两次开发和我数据逻辑不一致的问题。

Offline Training

上图为机器学习模型的训练流程。最早也是只有一个批量的数据计算，数据计算是特征数据和用户行为数据都放在离线的表里面，通过Spark任务去做拼接，拼接完之后形成训练任务，然后学习模型发布上线，整个过程可能每天进行一次。

Online + Offline Training

因为要更加快速的捕捉到用户实时兴趣点，同时对于有些新发布的笔记，要更快启动笔记做出判断，因此我们的模型需要做更加实时更新的需求。所以将其改造成通过Flink来做实时的模型训练，Flink生成数据之后，使用Volcano的调度系统进行实时模型和批量模型更新。

离线训练的优化和多云管理​

上图为小红书在机器学习和大数据的技术栈。小红书因为是一个比较新的公司，我们没有自建的机房，所有的服务器是买的云厂商的云服务，我们大多数业务都通过Kubernetes来管理的。

我们有两个很重要的平台：一个是内部称为Baichuan的流计算平台，主要用来管理上文提到的实时标签计算与在线学习的Flink任务。还有一个是机器学习的任务管理平台，内部称Firefly。我们是基于TensorFlow开发的一些模型训练，会运行在机器学习平台上，同时针对推荐搜索广告的大规模稀疏离散模型训练场景，也基于TensorFlow研究了自己的训练框架LarC，TensorFlow和LarC的框架模型是通过Firefly运行在机器学习平台上。

中间有非常关键的一层，如何将我们的任务调度到Kubernetes集群上，其实原生的Kubernetes对于这种场景存在一个比较大的问题，它是基于单pod来做调度的。但流计算和机器学习的任务，其实并不是单pod任务，是一组pod的job。因此我们开始有一个比较大的痛点，如果有两个job，每个job都有多个pod需要被调度，如果用原生的Kubernetes调度器，比如有10个资源，但是有两个任务，每个任务都需一个pod,但现在只有15个空闲核，每个任务比如说是10个核，加起来是不够的，但调度单个任务其实是可以。

如果用原生的 k8s去做调度，比如一个任务调度上去7个核，另外1个任务调度上去8个核，一共用了15个核，但每个任务其实不能调度完，所以每个任务都没有办法完成整个调度过程。因为它是基于单pod的，调度上去的时候不会把它撤下来，所以这个集群就会卡死。

基于这些痛点我们去做了一些调研，发现Volcano的前身是Kubernetes batch，可以完全解决我们的痛点。因此，我们也参与到Kubernetes batch社区当中，成为了Volcano的忠实用户。

增强型Volcano调度：binpack->task-topology

原生的Volcano支持的调度是binpack的算法。在机器学习训练时，训练任务分两类：一类是worker，主要是做前向和反向的计算，是一个计算型的任务。ps主要的任务是存储参数，是一个内存型的服务。如果用原生开源版的 Volcano，它默认支持的调度算法会优化要减少碎片，所以要把尽量多的任务调到同一个node上，然后会把这个任务调成所有work和ps放在一个node上，这个ps放不下，所以只能放在另外一个node上。

这种场景下，会发生worker和某ps0在一台机器上，他们之间 io没有跨机器，就会比较快，存储量也比较大。但是它运行的速度比较慢，因为被一个慢的 ps拖累了。我们发现把任务变成一个平衡的状态，速度均衡之后，它的整体存储是有比较大提升的。从binpack到task-topology的优化，总共能提升大概10%-20%的任务训练的吞吐。

多云之间的数据流转

在线上的话，我们会把用户分发到不同的AZ上，推荐服务它的特征缓存会存在本地AZ,在用户打点之后，会根据用户请求将用户分发到不同的集群上，分别对不同的用户做标签系统的计算，最终我们会把所有标签系统计算又流转到为我们提供离线训练和服务的云厂商，去进行数据训练的拼接和生成，同时做分布式的模型训练，训练好的模型再被分发到不同的AZ做线上服务。

怎么在这个架构下面做迁移学习？小红书的用户会在首页做流量，这是产生沉淀大量数据的一个场景。它会训练出来一个千亿级别的模型，那如何让推荐生产出来的大模型让搜索广告都能使用？将推荐的模型训练完之后，会把我们训练的推荐的模型，同步到搜索训练的集群上，在搜索集群训练上用搜索的数据，去发现推荐的模型，最终产生搜索的模型同时被发布到线上。如此在小规模的数据训练场景下，能够拿到训练推荐大模型的特点，使得推荐的大模型能够赋能搜索这个场景。

本文2021年1月5日首发于容器魔方微信公众号，原文链接基于Volcano的锐天离线高性能计算最佳实践

Volcano是一个基于Kubernetes的云原生批量计算平台，也是CNCF的首个批量计算项目。

Volcano 主要用于AI、大数据、基因、渲染等诸多高性能计算场景，对主流通用计算框架均有很好的支持。它提供高性能计算任务调度，异构设备管理，任务运行时管理等能力，目前在很多领域都已落地应用。本篇文章以锐天投资基于Volcano进行的离线高性能计算最佳实践为线索，深度解读Volcano在金融领域技术架构中的定制与应用。

Ruitian离线计算集群简介​

锐天投资是一家私募量化基金公司，公司致力于通过多元的程序化交易策略，帮助客户实现资金的增值。锐天的离线计算集群是一个面向策略开发、研究大数据处理任务的集群。集群通过对海量数据进行分析研究，得出优秀的量化模型，用于股票及期货交易。

在锐天成立初期，我们使用业界成熟的 Yarn 调度批处理作业，并使用 Ceph 存储海量数据。随着公司规模的扩大，策略人员使用的环境不断变化，对于不同研究环境的需求促使我们开始调研容器技术来实现多环境研究的问题。

随着近几年 Kubernetes 的成熟稳定，在计算集群中使用容器技术已经几乎等同于使用Kubernetes。但原生的Kubernetes调度器并未提供批处理任务的调度能力，即：

• 支持在一个Job中运行多个Pod

• 支持Job指定到不同的队列，用队列进行公平调度

• 支持一定程度的Gang Scheduling

• 支持指定在多少个pod成功的情况下，任务就被算作成功

• 支持DRF算法

在调研期间，我们发现了Volcano 项目。在满足我们需求的同时，它提供了丰富的调度策略与Job控制能力。 其简洁的结构成为了我们决定从Yarn迁移到Kubernetes的最后一块拼图。

迁移至Volcano​

由于集群用户主要为策略研究人员，他们对Kubernetes缺乏了解。我们希望将Kubernetes的相关细节对外封装，于是开发了一个 Jobctl 作为提交工具，来生成Volcano的Job模板。

Volcano任务模板​

方案1：一个作业多个任务

apiVersion: batch.volcano.sh/v1alpha1
kind: Job
metadata:
    name: awesome-job
spec:
    minAvailable: 1
    tasks:
    - name: simulation1
        replicas: 1
        template:
            spec:
                restartPolicy: Never
                containers:
                - name: worker
                    image: rt-python:latest
          resources:
            requests:
              cpu: 1
              memory: 1Gi
            limits:
              cpu: 1
              memory: 1Gi
                args:
                - bash
                - -c
                - |-
                    python run.py --pickle-file /data/simulation/1.pickle
    - name: simulation2
        replicas: 1
        template:
            spec:
                restartPolicy: Never
                containers:
                - name: worker
                    image: rt-python:latest
          resources:
            requests:
              cpu: 1
              memory: 1Gi
            limits:
              cpu: 1
              memory: 1Gi
                args:
                - bash
                - -c
                - |-
                    python run.py --pickle-file /data/simulation/2.pickle
    - name: simulation3
        replicas: 1
        template:
            spec:
                restartPolicy: Never
                containers:
                - name: worker
                    image: rt-python:latest
          resources:
            requests:
              cpu: 1
              memory: 1Gi
            limits:
              cpu: 1
              memory: 1Gi
                args:
                - bash
                - -c
                - |-
                    python run.py --pickle-file /data/simulation/3.pickle

这个方式可以针对不同的Pod设置不同的参数，并且可以对不同的pod使用不同的镜像，让它们各自负责不同的子任务类型，非常灵活。

由于在大部分情况下，不同的子任务通常负责不同的时间段，互相之间独立没有依赖，通过将 minAvaliable 设置为 1 可以让Pod全部参与调度的同时，Job处于Running状态，便于管理。但是在试运行期间，我们发现有的任务无法提交。排查后发现，有些研究人员的任务并发Pod数量巨大，超过5000。生成出的yaml的大小超过了1.5MiB，已经超出了etcd的默认最大请求大小，因此当任务数量过大时会导致无法提交作业。

考虑到集群Job、Pod数量众多，etcd的原有压力已经很大，我们没有简单的改变默认最大请求大小，而是换了一种思路。

方案2：一个作业一个任务多个副本

由于在大多数情况下，作业里的所有任务仅仅是参数不一致，因此可借助任务的多副本功能，每个任务根据自己副本的id加载对应的参数文件即可，这样就解决了etcd的请求大小限制。

apiVersion: batch.volcano.sh/v1alpha1
kind: Job
metadata:
    name: awesome-job
spec:
    minAvailable: 1
    tasks:
    - name: simulation
        replicas: 10
        template:
            spec:
                restartPolicy: Never
                containers:
                - name: worker
                    image: rt-python:latest
          resources:
            requests:
              cpu: 1
              memory: 1Gi
            limits:
              cpu: 1
              memory: 1Gi
                args:
                - bash
                - -c
                - |-
                    python -u call_module_func.py --pickle-file /data/simulation/`<work-id>`.pickle module.submodule magic_function

call_module_func.py 是一个引导脚本，通过 configmap 挂载进容器，负责以下工作：

• 将 <work-id> 转换成 replicas 当前的 id 号（通过获取容器内的 host 名后缀编号获取，如 host名为 awesome-job-awesome-job-1 ，id 号即为 1）

• 加载 pickle （通过 pvc 挂载进容器） 参数，传递给模块 module.submodule 里的函数 magic_function 运行。

Volcano定制​

minSuccess特性：

我们的大部分任务并不需要Gang Scheduler特性，但是我们需要在所有的子任务成功的情况下，才能够认为整个任务成功。

在这种情况下，minAvailable 这个参数就不能很好的符合我们的需求，于是我们增加了 minSuccess 参数，将判断任务成功的逻辑从minAvailable中解耦合。

minSuccess := ps.job.Job.Spec.MinSuccess
if minSuccess == 0 {
    minSuccess = jobReplicas
}

if status.Succeeded >= minSuccess {
    status.State.Phase = vcbatch.Completed
    return true
}

if status.Succeeded+status.Failed == jobReplicas {
    if status.Failed != 0 {
        status.State.Phase = vcbatch.Failed
    } else {
        status.State.Phase = vcbatch.Completed
    }
    return true
}

autoMemoryScale特性:

使用Volcano提交任务需要指定申请的cpu和memory，而我们的大部分策略人员无法对自己的程序有很好的内存估计。于是我们定制了 autoMemoryScale 功能，监控OOM事件。

如果程序是由于OOM退出的，它将自动扩充内存，重新调度，从而减少策略人员试错参与。

for i := 0; i< int(ts.Replicas); i++ {
    podName := fmt.Sprintf(jobhelpers.PodNameFmt, job.Name, name, i)
    if pod, found := pods[pdName]; found {
        if len(pod.Status.ContainerStatuses) == 0 {
            continue
         }
         
         reason := pod.Status.ContainerStatuses[0].State.Terminated.Reason
         
         if reason == "OOMKilled" {
             podToScaleUp = append(podToScaleUp, pod)
             jobResources := ts.Template.Spec.Containers[0].Resources
             podResources := pod.Spec.Containers[0].Resources
             
             jobReqMem, _ := jobResources.Requests[v1.ResourceMemory]
             podReqMem, _ := podResources.Requests[v1.ResourceMemory]
             
             if podReqMem.Value() >= jobReqMem.Value() {
                 scaleUpResource(jobResources.Requests, job.Spec.ScaleUpJobResourceRate)
                 scaleUpResource(jobResources.Limits, job.Spec.ScaleUpJobResourceRate)
                 ts.Template.Spec.Containers[0].Resources = jobResources
                 job.Spec.Task[taskId] = ts
             }
         }
     }
 }

nodeZone特性:

在原先Yarn的集群中，我们通过分Partition可以强行预留一部分机器给紧急任务使用。同样的特性我们需要迁移到Kubernetes也具备。

开始我们的方案是创建一个单独的 daily 队列，且该队列的权重相对较小。此外我们划分了某些节点，专门给该队列运行，而且指定 daily 队列的任务需使用 nodelSelector 来选择这些节点。

但随后我们发现当集群负载高的情况下，daily 队列能划分到的资源无法完全使用。我们分析发现了如下原因：

假如有三个队列:

name  weight
Q1    45
Q2    45
daily 10

集群整体资源100CPU，100Gi，划分了20CPU，20GiB给 daily 队列。当各个队列高负载的情况下，daily队列由于公平性只能获取10CPU和10Gi资源，即使使用了nodeSelector 也没有办法满足我们的需求。

我们的解决方案是让调度器支持 node-selector（即node-zone），调度器只需负责匹配的节点，且去除掉了daily队列。当某个调度器上的各个队列很满的情况下，并不会影响队列在另一空闲调度器上的资源公平性划分，即如果该空闲调度器仅运行有一个队列，该队列就可以申请使用全部的资源。

对于不同特性的任务，用户需要选择的是不同的 调度器 而非某个特殊的 队列，避免了由于公平性导致的资源使用不充足情形的发生。

于是在 Volcano 中我们实现了选择特定label机器的特性，由多个scheduler实例来负责对多个node节点域进行调度。

sc.nodeInformer.Informer().AddEventHandlerWithResyncPeriod(
    cache.FilteringResourceEventHandler {
        FilterFunc: func(obj interface{}) bool {
            switch v := obj.(type) {
            case *v1.Node:
                nodeZone := v.Labels["node-zone"]
                return nodeZone == sc.nodeZone
            default:
                return false
            }
        },
        Handler: cache.ResourceEventHandlerFuncs {
            AddFunc:   sc.AddNode,
            UpdateFunc: sc.UpdateNode,
            DeleteFunc: sc.DeleteNode,
        },
    },
    0,
)

Volcano 监控​

由于当前Volcano社区提供的监控更多是调度性能指标，我们根据自身需求采集了一些额外的指标，并编写了一个简单的export server提供给我们的监控系统。

• volcano 生成的 Pod 是不带有队列标签的，这就导致了队列资源的搜集变得困难，因此我们特意对每个 task 添加了队列的标签

• 输出队列 Capability

• 输出 Job 的开始和完成时间

有了这些额外指标，就可在 Grafana上构建出集群整体资源、队列资源、节点资源、用户作业的进度等相关的监控信息，实时了解到集群的使用率，也方便问题的排查，尤其为何作业处于Pending状态（可能队列/集群资源申请满了，每个节点剩余资源均不够单个任务申请）。

WatchDog​

对于Volcano资源相关的一些自动化任务，我们编写了一个名为 WatchDog 的组件，从外部进行自动化运维。

队列 Capability 自动更新： Capability是每个队列的资源使用上限，对其维护是一件繁琐的事情，每次新增节点或移除节点均需对其作出调整，所以在WatchDog中，监听节点资源信息，根据队列的百分比配置，动态的更新其 Capability

任务状态自动报警： 当任务完成或失败时，通知用户，便于及时了解到任务运行的状态。

任务资源利用率通知： 在任务状态报警中，通过从监控系统获取任务申请和实际使用资源量，告知用户，便于其调整申请资源，使集群资源利用率提升。

总结​

Volcano 是我们迁移至 Kubernetes 过程中至关重要的组件，其简洁清晰的设计，让我们能非常方便的自己定制化调度行为。

截至目前，Volcano已在锐天生产环境稳定运行半年以上，峰值可调度作业10万+/天。 我们也时刻关注着社区的动态，积极参与项目的开发与设计，同时希望能有更多开源作者能加入到 Volcano 社区的建设中来，让 Volcano 能更加灵活、高效、智能的处理各种复杂作业场景。

公司简介：上海锐天投资公司成立于2013年，是一家重视科学研究和技术积累的量化基金公司。公司拥有业内领先的策略研发和回测平台，数百台高性能服务器组成的自建集群。创始人在全球顶级对冲基金取得相当成绩后归国创业。截至2019年一季度，锐天已跻身国内量化交易领域第一梯队，管理规模逾百亿人民币，管理基金90多支。公司官网：https://www.ruitiancapital.com/

本文2020年12月24日首发于容器魔方微信公众号，原文链接Volcano在中科类脑云OS中的落地实践

类脑AI云平台介绍​

AI开发平台 ：面向AI科研人员，提供不同领域不同应用场景相匹配的全流程技术支撑和解决方案

公共服务平台：面向政府和社会人员，提供人工智能相关的新闻咨询、运营内容等支撑

AI可视化平台：面向管理人员，提供统一的运营数据可视化展示，运筹帷幄

AI社区：面向AI开发者和相关企业的社区平台，提供AI交流、问答、培训服务

类脑云OS架构​

在OS架构中，最底层为硬件平台，硬件平台之上为引擎层。引擎层主要包括调度引擎和数据引擎两部分，提供任务调度和数据管理能力。

引擎层之上为计算层，它提供一系列面向通用场景创建分布式训练任务的接口。

应用层由面向业务的一系列业务系统组成，如模型管理系统、资源管理系统、运维监控系统等。

为什么选择volcano？​

在搭建类脑云OS 2.0时，我们尝试寻找一款生态环境比较好的调度引擎。经过一系列的调研，我们发现Volcano的分布式训练任务重试机制是基于失败场景的，而我们原有的任务重试机制是基于失败次数的；其次，Volcano对深度学习框架的支持比较友好；此外，Volcano有大量高级调度策略 。

另外，我们发现K8s默认的调度机制对批量调度的支持并不友好。Hadoop虽然支持批量任务，但是它的架构比较笨重。因此，基于上面几点我们最终选择了Volcano。

由于在决定引入Volcano调度服务时，我们系统已经完成开发，如何在现有系统里引入Volcano呢？如果直接引入会导致系统计算层和应用层修改较大。

另外，我们在引入前也对Volcano需求进行了分析，发现单机任务和分布式训练任务上Volcano已经支持，但是对调试任务、调试工具集需要做一系列定制开发，所以需要引入一个组件job-server做接口的适配和类似调试工具集的集成开发。

在确定使用Volcano和通过 job server去做任务适配后，我们梳理了Volcano的场景，发现上层的业务是需要知道task详细的运行信息、状态变化信息、历史信息，而Volcano Job可以提供job的运行状态信息，但暂未提供task运行相关信息。

因此我们就面临一个问题：**去定制修改Volcano还是实现Volcano task监控？**当时发现Volcano对新功能的版本迭代是非常快的，如果去做深度的修改，这种源码会给后续版本的升级带来很大的困难。并且我们也希望这个版本随着Volcano升级功能的增强，和它版本迭代一起往上升级，所以我们采用了第二种方案，去监控Volcano task的一些运行状态信息。

下图是一个简单的监控机制，通过Watch的方式去监控API Server里job相关信息的变化和Pod相关信息的变化。

实践思路​

场景

• 创建批量任务

• 批量任务需要具备jupyter lab、tensorboard、code-server、wetty等调试工具集

• 批量任务支持数据存储集优化策略

• 支持训练、量化和模型转换

基于上面的场景，我们做如下的设计：

任务的清理​

场景

• Job运行完成后，清理任务

• 清理该Job附加的能力（jupyter、code-server）

1）当Job结束时，volcano可以自动清理

2）清理能力相关资源（pod、service、ingress）

任务重试​

我们1.0版本设计的初衷是基于次数进行限制，但是后来发现Volcano基于事件触发的机制更加灵活，业务场景也更加合理。因此我们在任务重试方面进行了原有方案的一系列改动，直接采用Volcano的任务重试机制。

• TaskRole中的策略优先级高于Job中的重试策略

• 重试策略中包含Event和Action，Event表示触发条件，

• Action表示条件满足后执行的动作

• maxRetry限定最大重试次数

在实现以上特性的过程中，我们得到了Volcano社区的大力支持。当时遇到的一个问题是RestartTask失效，在当天遇到这个问题时反馈给了社区，当天就得到了解决，这个响应速度是非常快的。

后期计划​

在拓扑调度、基于单机多卡如何选择最好的GPU拓扑结构进行调度这两方面，希望社区能够给予更好的支持。也希望我们和社区共同努力，深化双方在技术、运营等方面的合作，使得社区生态更加繁荣！