北京时间 2026 年 10 月 14 日，Volcano v1.16.0 正式发布。v1.16.0新增 NamespaceQueue 和 fairshare 插件。NamespaceQueue 支持租户在自己的命名空间内使用 Volcano 的层级队列能力，在管理员授权的资源范围内配置队列配额、组织队列层级。fairshare 则将同一队列内各命名空间的历史资源用量纳入调度排序，改善多团队共享资源时的公平性。本次版本还进一步拓展了 HyperNode 生态。使用其他调度器的平台，可以单独部署 HyperNode 控制器，复用拓扑发现逻辑、维护超节点及其层级关系，再通过 HyperNode API 将拓扑信息接入自己的调度流程。对于使用 Volcano 的推理服务，新增的 PodGroup 拓扑反亲和规则则可以将多个实例分散到不同超节点，降低实例集中在同一故障域的风险。调度性能方面，新增的 Unschedulable Job Cache 缓存作业的调度失败原因，在阻塞条件未变化时跳过重复检查。节点打分、缓存更新与队列查询也有优化，进一步提升调度效率。此外，v1.16.0 还包含 Kubernetes 1.36 适配、批量 Pod 调度时的负载估算、DRA 打分，以及异构资源和稳定性方面的改进。   版本亮点  提升调度性能与可扩展性：新增 Unschedulable Job Cache 减少积压场景下的重复检查，同时优化节点打分、缓存更新与队列查询。新增 NamespaceQueue 支持租户在命名空间内管理队列层级：租户可在自己的命名空间内使用层级队列，在管理员授权的资源范围内管理配额和资源分配。新增 fairshare 改善租户间的长期公平性：面向多个租户按命名空间隔离并共享同一队列的场景，引入类似 Slurm 的历史用量衰减机制。通过 PodGroup 拓扑反亲和分散部署业务实例：可以要求多个实例必须分散到不同拓扑域，也可以设置优先分散的调度偏好。拓展 HyperNode 生态以支持更多调度系统：其他调度器可复用社区已有的拓扑发现和超节点管理逻辑，无需同时运行 Volcano 的其他组件。  重点特性  ▍1. 提升调度性能与可扩展性v1.16.0 新增 Unschedulable Job Cache，改善大量作业等待资源时的调度性能，同时优化节点打分、缓存更新与队列查询。Unschedulable Job Cache :队列配额不足、缺少满足要求的 GPU 节点、节点标签不匹配等因素，都可能导致作业持续等待。在阻塞条件未变化的情况下，逐轮执行相同检查会产生额外调度开销。随着等待作业积压，这些重复检查还会延迟满足调度条件的作业获得资源。UnschedulableJobCache 记录作业未通过的调度检查，并根据插件声明的事件判断重试时机。阻塞条件未变化时，调度器跳过相应的重复检查，收到相关事件后再按正常流程重新评估作业。该机制减少了无效重试，提升了积压场景下可调度作业的调度效率。主要能力：按原因跳过检查：根据记录的调度失败原因，跳过入队检查、整个作业或部分任务的重复评估，同时遵守 Gang 约束。条件变化后重试：例如，节点标签变化后重新检查节点亲和性，资源释放后重试资源不足的作业，队列配置变化后重新检查配额。存储和 DRA 插件也可以通过事件 hint 唤醒相关作业。未覆盖的情况继续逐轮检查：仅当所有拒绝该作业的插件均提供能够安全判断重试时机的事件 hint 时，才缓存该作业。其余情况仍按原有流程逐轮评估，确保重试机会不受影响。不改变 Gang 和队列资源计算：缓存中的作业仍参与资源需求计算，队列资源与 Gang 条件保持原有检查方式。作业唤醒后仍需通过完整调度检查。保留兜底重试：未收到相关事件时，watchdog 会在等待超过设定时长后触发重试，默认五分钟。缓存仅保存在内存中，调度器重启后重新建立。该特性默认关闭，可通过调度器 feature gate 开启：helm upgrade --install volcano volcano-sh/volcano \  --namespace volcano-system --create-namespace --version 1.16.0 \  --set custom.scheduler_feature_gates="UnschedulableJobCache=true"目前已接入 predicates 封装的上游插件 hint，以及 Resource Fit、proportion 和非层级 capacity。因层级 capacity 检查未通过而等待的作业，以及其他缺少 hint 的插件所阻塞的作业，仍会在每轮调度中检查。排查运行情况时，可开启按 Job 记录的调试指标，查看跳过检查、事件唤醒和 watchdog 重试的次数。相关资料：PR：cid:link_16、cid:link_17设计与性能验证：Unschedulable Job Cache (cid:link_7)使用指南：启用 Unschedulable Job Cache (cid:link_1)感谢贡献者：@JesseStutler此外，节点打分支持多个插件在同一次节点遍历中完成评分，降低多插件场景下的打分开销。节点更新与队列查询也减少了不必要的对象拷贝和遍历。(PR: cid:link_18、cid:link_19、cid:link_20)性能与可扩展性将持续优化。后续将结合基准测试和生产反馈，持续优化调度流程、缓存与事件处理、状态更新等环节。▍2. 新增 NamespaceQueue 支持租户在命名空间内管理队列层级不同平台采用不同的租户模型。有的平台通过集群级 Queue 为租户划分资源池，也有的平台以 namespace 作为团队或项目的管理边界，希望租户在各自命名空间内配置队列配额和层级关系。NamespaceQueue 面向后一种场景，让队列管理与租户的资源管理范围保持一致。NamespaceQueue 将 Volcano 的层级队列能力扩展到命名空间。管理员通过集群 Queue 的 spec.allowedNamespaces 授权资源访问范围后，租户可在自己的命名空间内创建队列、建立父子队列层级，并配置 capability、deserved、guarantee、reclaimable 等资源属性。管理员负责资源池授权，租户在授权范围内管理内部配额与队列层级。队列名称在命名空间内隔离，不同命名空间可使用相同名称。该特性默认关闭。使用下面的 Helm 参数后，控制器、调度器和 admission webhook 会同时启用 NamespaceQueue。使用 chart 默认调度配置时，还会自动切换到层级 capacity：helm upgrade --install volcano volcano-sh/volcano \  --namespace volcano-system --create-namespace --version 1.16.0 \  --set custom.namespace_queue_enable=true先创建命名空间和允许接入的集群 Queue，再创建租户队列：apiVersion: v1kind: Namespacemetadata:  name: team-a---apiVersion: scheduling.volcano.sh/v1beta1kind: Queuemetadata:  name: researchspec:  capability:    cpu: "100"    memory: "200Gi"  deserved:    cpu: "100"    memory: "200Gi"  allowedNamespaces:  -team-a---apiVersion: scheduling.volcano.sh/v1beta1kind: NamespaceQueuemetadata:  name: training  namespace: team-aspec:  parent: cluster/research  capability:    cpu: "40"    memory: "80Gi"  deserved:    cpu: "40"    memory: "80Gi"  reclaimable: true管理员还需通过 RBAC 授予租户在本命名空间内操作 namespacequeues 的权限。确认 NamespaceQueue 的 Ready=True、Authorized=True 后，team-a 中的 Job 或 PodGroup 即可使用下面的引用：spec:  queue: namespace/training提交作业时，不带前缀的队列名仍指向原有的集群 Queue。设置 NamespaceQueue 的父队列时，cluster/<name> 指向集群 Queue，普通名称则指向同命名空间内的 NamespaceQueue。使用 NamespaceQueue 需要启用层级 capacity，不应同时启用 proportion。相关资料：PR：cid:link_21、cid:link_22)使用指南：NamespaceQueue 用户指南(https://volcano.sh/zh-Hans/docs/UserGuide/user_guide_how_to_use_namespace_queue)设计文档：命名空间级队列(cid:link_11)感谢贡献者：@gitGurugu▍3. 新增 fairshare 改善租户间的长期公平性Volcano 原有的资源共享与配额治理主要围绕集群级 Queue 展开，适合为租户分配独立队列的模型。另一类平台以 namespace 作为团队或项目的隔离边界，多个租户向同一个 Queue 提交作业，需要在队列内部获得公平的调度机会。两种模型对应不同的资源管理需求。在共享队列中，仅依据当前资源分配量排序，难以反映各租户一段时间内的累计消耗。例如，一个团队持续提交 GPU 作业，已有作业完成后又继续占用释放的资源，后续加入的团队可能长期等待。新增的 fairshare 插件借鉴 Slurm 的 fair-share 思路，以 namespace 标识租户，记录同一队列内各命名空间的累计资源用量（资源数量与使用时长的乘积），优先调度历史用量较少的命名空间。历史用量按指数衰减，默认半衰期为四小时，较早用量对调度排序的影响逐步降低。fairshare 可与 DRF 配合使用，将历史资源用量作为当前资源分配之外的补充排序依据。插件通过调整等待作业的顺序改善公平性，也可按需限制新作业入队，不会抢占运行中的作业。用户可配置生效队列、统计资源类型，以及是否通过 ConfigMap 持久化历史用量。调度配置示例：actions: "enqueue, allocate, backfill"tiers:- plugins:  - name: priority  - name: gang  - name: conformance  - name: fairshare    arguments:      fairshare.targetQueues: "gpu-queue"      fairshare.resourceKey: "nvidia.com/gpu"      fairshare.halfLifeMinutes: "240"      fairshare.enableEnqueueGate: "false"      fairshare.persistState: "false"- plugins:  - name: drf  - name: capacity  - name: predicates  - name: nodeorder配置时应将 fairshare 排在 drf 之前，否则作业顺序可能由 DRF 优先决定。如需保持 PriorityClass 的排序优先级，应将 priority 排在前面。历史用量持久化与入队限制默认关闭。相关资料：特性 PR：cid:link_23设计文档：Fair Share Scheduling (cid:link_13 )使用指南：fairshare 插件 (cid:link_4)特性贡献者：@dmildh-absci▍4. 通过 PodGroup 拓扑反亲和分散部署业务实例推理服务运行多个实例时，同一实例的 Pod 通常需要在拓扑上集中部署，以减少通信开销，不同实例则需要分散到不同故障域，降低单个超节点故障的影响。原有 networkTopology 可以限制一个 PodGroup 内部的调度范围，但多个 PodGroup 仍可能集中在同一个超节点。新增的 group-topology-affinity 插件可以约束不同 PodGroup 之间的调度位置。用户可通过标签选择器匹配需要分散部署的 PodGroup，并指定机架、超节点等 HyperNode 层级。required 规则强制将匹配的 PodGroup 部署到不同拓扑域，preferred 规则则优先选择不同拓扑域。结合 networkTopology，可同时满足实例内部集中部署与实例之间分散部署的需求。选择范围既可以限于当前命名空间，也可以通过 namespace selector 扩展到其他命名空间。在现有调度插件列表中加入以下配置，并保留原有 action 和其他插件：- name: group-topology-affinity  arguments:    weight:10- name: network-topology-aware  arguments:    weight: 10假设 HyperNode 拓扑中已有 supernode 层级，可以为需要分散部署的每个 PodGroup 配置相同规则，并分别设置名称：apiVersion: scheduling.volcano.sh/v1beta1kind: PodGroupmetadata:  name: inference-a  namespace: default  labels:    app:model-aspec:  minMember: 2  queue: default  networkTopology:    mode: hard    highestTierName:supernode  topologyAffinity:    podGroupAntiAffinity:      required:      - podGroupSelector:          matchLabels:            app: model-a        topologyTierName: supernode成员 Pod 需要使用 schedulerName: volcano，并通过 scheduling.k8s.io/group-name 注解关联对应 PodGroup。选择器匹配的是 PodGroup 标签。每条规则必须在 topologyTierName 和 topologyTier 中选择一个，偏好规则还需设置 1 到 100 的权重。当前规则只在 allocate 阶段生效，backfill 调度的 BestEffort Pod 不受这些规则约束。目前还不支持 SubGroup 之间的亲和与反亲和、跨 PodGroup 亲和，以及运行中 Pod 的自动迁移。相关资料：PR：cid:link_24设计文档：PodGroup 拓扑亲和性设计 (cid:link_8)使用指南：PodGroup 反亲和性 (cid:link_3)感谢贡献者：@wangyang0616▍5. 拓展 HyperNode 生态以支持更多调度系统使用其他调度器的平台，也需要发现集群拓扑、维护超节点及其层级关系。此前，这些平台若需复用 HyperNode，仍需运行 Volcano 的 controller manager。v1.16.0 新增 HyperNode 控制器独立部署方式，为其他调度系统集成拓扑发现与超节点管理能力提供支持，进一步拓展 HyperNode 生态。平台可单独部署 HyperNode 控制器，复用社区已有的 UFM、节点标签等拓扑发现方式，由控制器自动创建和更新 HyperNode 资源，维护超节点及其层级关系。其他调度器通过 HyperNode API 获取拓扑信息，并结合业务需求实现拓扑感知调度，无需同时运行 Volcano 调度器和其他控制器。独立控制器与原有集成模式共用拓扑发现和 HyperNode 管理逻辑，后续社区增加的发现方式也可以在两种模式中复用。不同调度系统可共享拓扑发现与超节点管理能力，各平台的相关改进也可贡献到同一套实现中。本次提供了独立的 vc-hypernode-controller-manager 二进制、镜像和 Helm Deployment。chart 可选择 controller-manager、standalone 或 disabled 模式，默认仍由原有 controller manager 管理 HyperNode。只部署 HyperNode 控制器时，可以使用：helm upgrade --install volcano volcano-sh/volcano \  --namespace volcano-system --create-namespace --version 1.16.0 \  --set custom.hypernode_controller_mode=standalone \  --set custom.controller_enable=false \  --set custom.scheduler_enable=false \  --set custom.admission_enable=false拓扑发现仍通过 custom.controller_config_override 配置。如果要保留其他 Volcano 组件，只需调整 HyperNode 模式。从现有部署切换时，先设置为 disabled，等待 controller manager 完成滚动更新，再启用 standalone，确保同一时间只有一个进程管理 HyperNode。相关资料：PR：cid:link_25、cid:link_26设计文档：HyperNode 控制器独立部署 (cid:link_5)使用指南：部署独立 HyperNode 控制器 (cid:link_0)拓扑发现配置：HyperNode Auto Discovery (cid:link_2)感谢贡献者：@wangyang0616  其他值得关注的增强  ▍批量 Pod 调度时的负载估算监控指标存在采集与更新延迟。批量调度 Pod 时，新分配的任务可能尚未反映在监控数据中，调度器可能因此低估节点负载，继续向这些节点分配任务。usage 插件新增 session 级的 shadow load cache，预估尚未反映在监控数据中的 Pod 的 CPU 和内存用量。节点打分时，调度器综合考虑预估用量与实际监控值，减少指标延迟导致的负载误判。缓存保留每个 Pod 的预估值，回滚时扣除对应原值，避免重新计算引入资源用量偏差。可在现有调度配置中补充以下插件参数，同时保留监控数据源配置：- name: usage  enablePredicate: false  arguments:    usage.weight: 5    cpu.weight: 1    memory.weight: 1    estimator:      request_ratio: 0.7      burst_ratio: 0      risk_threshold: 0.6      risk_factor: 1.2      be_cpu: 250m      be_mem: 200Mi用户可以通过 request_ratio、burst_ratio 和 risk_factor 等参数调整估算方式，也可以设置 BestEffort Pod 的固定预估用量。插件根据 metrics.interval 识别可能尚未反映在监控数据中的 Pod，该值默认为 30 秒。相关资料：PR #5314 (cid:link_27 )、Usage-Based Scheduling (cid:link_9)。感谢贡献者 @3th4novo。▍按 NodeGroup 设置队列资源限额通过 NodeGroup 插件新增的队列注解，用户可分别设置队列在各 NodeGroup 中的资源使用上限。例如，先使用固定资源池，达到队列在该池中的限额后，再将新增任务调度到其他允许使用的资源池。metadata:  annotations:    volcano.sh/nodegroup-resource-limits: |      {"fixed": {"cpu": "100", "memory": "200Gi"}, "overflow": {"cpu": "50"}}只限制注解中列出的资源项，未配置的资源不受额外限制。子队列不会继承父队列的这项配置，需要限制用量的队列应各自设置注解。相关资料：PR #5461 (cid:link_28)、NodeGroup 使用指南 (cid:link_6)。感谢贡献者 @ruanwenjun。▍基于 Pod 级分配信息提高 NUMA 资源判断准确性原有节点级 NUMA 汇总信息难以准确区分资源释放和新任务分配。如果节点上的 Pod 释放 CPU 时，另一批 Pod 已完成调度但尚未由 kubelet 分配资源，汇总数据的变化可能导致调度器误判可用 CPU，进而错误拒绝实际满足 NUMA 策略的任务。Numatopology 新增 spec.podAllocations，记录 Pod UID、名称、命名空间及各容器的资源分配，CPU 使用 cpuset 表示。调度器结合 Pod 级实际分配与尚待分配的任务，更新节点 NUMA 资源视图，减少资源信息失真导致的 NUMA 策略误判。细粒度信息也便于定位容器的 CPU 分配与资源占用。使用该能力需配套支持新字段的 resource-exporter。( PR :cid:link_29、cid:link_30)▍DRA 与异构资源调度DRA 打分：调度使用 DRA 优先级设备请求的 Pod 时，接入上游 DynamicResources 的打分及归一化逻辑。( PR :cid:link_31)HAMi Ascend 软切分：接入 hami-vnpu-core，支持设备内存虚拟化与算力时间片共享，需要配套的设备插件和运行时。完整配置请参考 vNPU 使用指南 ( cid:link_10)。( PR : cid:link_32、cid:link_33)Ascend 健康检查：根据 allocatable 设备信息判断 vNPU 健康状态。( PR :cid:link_34)vGPU 选择与一致性修复：新增按 GPU UUID 设置允许和排除列表的注解，并修复绑定与回滚过程中的设备分配元数据一致性问题。( PR : cid:link_35、cid:link_36)▍HyperNode 发现与拓扑调度一致性拓扑更新与发现：修正 HyperNode 更新时的拓扑重建行为，避免 informer 缓存延迟导致重复创建 HyperNode，并在 UFM endpoint 配置缺失或类型错误时返回错误而非触发 panic。( PR :cid:link_37、cid:link_38、cid:link_39)抢占与回收后的拓扑选择：保留并优先处理跨调度周期的 SubJob HyperNode nomination，未启用 hard 拓扑约束的作业也会遵循该结果，使 Gang 抢占或回收释放的资源能够按预期用于后续放置。( PR :cid:link_40、cid:link_41)▍Grove 与 KubeRay 接入多级 Gang 调度Grove 和 KubeRay 已接入 Volcano 的多级 Gang 调度能力，为不同角色和副本提供更细粒度的调度支持。Grove：已合入 Volcano 调度后端，将不同角色映射为 PodGroup 内的 SubGroup，支持按角色设置 Gang 约束。( PR :cid:link_61)KubeRay：已合入 SubGroupPolicy 支持，将 Ray worker group 的副本配置转换为 Gang 约束，支持按完整副本进行调度，包括由多个 Pod 组成的多主机副本。( PR : cid:link_15 )两项集成目前都侧重于 Gang 约束，尚未接入 SubGroup 级网络拓扑感知调度。注：多级 Gang 调度自 Volcano v1.14 起已支持，并不限定于 v1.16。▍Kubernetes 兼容与运行管理v1.16.0 支持 Kubernetes 1.36，依赖版本升级到 Kubernetes 1.36.1，源码构建需要 Go 1.26。存储绑定改用上游 VolumeBinding 实现，并同步更新客户端代码、RBAC、安装清单和 CI 配置。( PR : cid:link_42)运维方面，用户可以调整负责更新 Job、Task 状态的 worker 数量，并通过新增指标查看队列中的工作负载状态和调度器提交的驱逐事务。Volcano agent 也支持 Pod 级资源配置，计算资源请求时会计入原生 sidecar 与 Pod overhead。( PR :cid:link_43 、cid:link_44、cid:link_45、cid:link_46、cid:link_47)新增的 inqueue 资源指标可展示已准入但尚未运行的作业预留的 CPU、内存和标量资源，帮助定位队列配额不足的原因。( PR :cid:link_48)▍稳定性与正确性修复修复准入失败后仍占用 inqueue 预留资源的问题，以及 scheduling gate 预留资源未计入祖先队列的问题。( PR :cid:link_49、cid:link_50)避免已完成的 PodGroup 在 Pod 删除后重新进入队列并预留资源，也避免正在终止的任务退回 Inqueue 状态。( PR :cid:link_51、cid:link_52)修复 PVC informer 尚未同步导致 Pod 无法进入正常调度的问题，以及重建 Pod 被写入旧 PodGroup 注解的问题。( PR :cid:link_53、cid:link_60)修复 Agent Scheduler 提前退出时的队列处理，以及占位节点导致的增量快照空指针问题。( PR :cid:link_54、cid:link_55)资源回收在提交前重新检查设备可用性，避免提交无法满足设备需求的回收决策。( PR :cid:link_56)修正节点打分与 PreFilter 的插件接入，确保批量预计算和跳过检查的结果按预期生效。( PR ：cid:link_57、cid:link_58、cid:link_59)▍安全修复v1.16.0 修复了 GHSA-j38h-7pfq-cxmw (cid:link_12)。在 DRA 容量计算中，过大的设备数量或最小任务数可能导致长时间循环计算。计算过程持续持有缓存锁时，也会阻塞其他命名空间作业的调度。通过 ResourceClaim 触发该问题，需要集群支持 DRA 并显式开启 DRAConsumableCapacity，用户还需有权限创建带容量维度的 ExactCount 请求，以及引用该请求的 Pod。修复后，容量计算改用乘法，不再按用户指定的数量逐次累加，同时加强数量校验和溢出处理。受影响版本为 v1.15.0 和 v1.15.1，修复已随 v1.15.2 首次发布，v1.16.0 同样包含修复。风险等级为中危，CVSS 6.5，使用受影响版本的用户应及时升级。感谢 @thc1006 报告并修复该问题，以及 @JesseStutler 协调安全公告发布。  升级注意事项  v1.16.0 正式发布后，可通过 Helm 或安装清单升级：helm repo add volcano-sh https://volcano-sh.github.io/helm-chartshelm repo updatehelm upgrade volcano volcano-sh/volcano \  --namespace volcano-system --version 1.16.0kubectl apply -f https://raw.githubusercontent.com/volcano-sh/volcano/v1.16.0/installer/volcano-development.yaml使用 NamespaceQueue 或新的 PodGroup、Numatopology 字段前，应同步更新 CRD、RBAC 和控制面组件。NamespaceQueue 与 UnschedulableJobCache 默认关闭。NamespaceQueue 依赖层级 capacity，而本次缓存实现暂不缓存层级 capacity 的拒绝结果。启用 fairshare 前应检查插件顺序，启用拓扑反亲和性前应确认其生效范围。自定义拓扑插件需要适配 HyperNodeGradientResult 并重新构建，同时检查 Kubernetes 1.36 集成接口的变化。源码构建需要 Go 1.26。将 HyperNode 切换到独立控制器时，应先完成 disabled 模式的滚动更新，再启用 standalone。现有 Volcano CRD 增加了 Helm 卸载保留注解，但本次新增的 NamespaceQueue CRD 尚未带有该注解。重新安装前应确认资源保留与归属。▍参考链接本文介绍 v1.16.0 的主要能力，完整 API 变化、问题修复、依赖更新及维护项请参考 Release Note。Release Note: cid:link_14完整变更记录: https://github.com/volcano-sh/volcano/compare/v1.15.0...v1.16.0  致 谢  Volcano v1.16 共有 65 位贡献者参与。衷心感谢每一位贡献者在功能开发、问题修复、测试、文档和评审中的投入，推动 Volcano 持续提升调度能力与稳定性！参与本次版本合并 PR 的作者包括：@106umao@3th4novo@A69SHUBHAM@aeron-gh@agrawalcodes@Aliexe-code@Aman-Cool@anxkhn@archlitchi@autsu@avinxshKD@bhuvan-somisetty@CapThunder19@choosen23@copilot-swe-agent@DarkestSky@dependabot@devzizu@dmildh-absci@DSFans2014@FAUST-BENCHOU@gitGurugu@goyalankit@gucardona@hajnalmt@halcyon-r@harshrajdebug@hzxuzhonghu@iamtanishqjain@JesseStutler@kitianFresh@kryz73@kube-gopher@kubeboiii@linuxfhy@magic-peach@miantalha45@moezdil@netliomax25-code@omlahore@OneSizeFitsQuorum@PrasannaMishra001@Psykii22@r0hansaxena@ranxi2001@ruanwenjun@safiya2610@shettythrishal328-dev@shivansh-gohem@songmingming0827@SquareCatFirst@t2wang@Tau721@thc1006@togettoyou@vanshika2720@vivek41-glitch@vzhou-p@wangyang0616@WHOIM1205@xiezhayang@xuezhaojun@yash-pokhriyal@YiD11@yuanhuaiwang  关注魔方公众号，获取更多前沿资讯

由 Linux Foundation 组织的 LFX Mentorship 计划[1]，从 2019 年开始为 CNCF 各个开源社区中的开发人员持续提供带薪实习和指导。该项目往年已获 2w+ 申请，累计课题量 2200+，毕业实习生 1500+，发放超过 390 万美金报酬。LFX Mentorship 2026 秋季 ( Term 3 ）申请时间为8月3日 – 8月18日（23:59 UTC )，正式研发工作将从 9 月 7 日开始为期三个月。参与到LFX Mentorship计划中，为开源项目做贡献、获得开源社区认可的同时，完成工作还能获取报酬 (位于中国的开发者报酬为3000美金，约合20000人民币）。Volcano社区在LFX Mentorship计划的课题申请正在火热进行中，感兴趣的开发者即日起可前往官网申请（在校/在职符合条件均可）:🔍 https://mentorship.lfx.linuxfoundation.org/   Volcano 社区介绍  Volcano （cid:link_7）是 CNCF 首个批量计算项目，也是业界领先的云原生统一调度平台。Volcano 已从批量调度引擎演进为通智融合调度系统，面向 AI 训练、大模型推理、Agentic AI、大数据、基因测序等多样化工作负载提供统一的高性能调度能力，对 Spark、Flink、Ray、TensorFlow、PyTorch、Kubeflow、MPI、PaddlePaddle、MindSpore 等主流计算框架均有完善支持。社区在GitHub上已获得 6.9k+ Star 和 2.4K+ Fork，参与贡献企业包括华为、AWS、百度、腾讯、京东、小红书、bilibili 等。在大模型/AI 推理领域，Volcano Kthena 依托社区在集群拓扑感知与大规模算力调度的优势，结合 KV Cache 感知路由与 Prefill/Decode 分离等高级特性，通过算力与时延的极限优化，显著提升 GPU/NPU 资源利用率与系统吞吐，从而高效解决生产环境中 LLM 大规模部署与服务的核心挑战，助力用户释放模型推理与服务的算力潜能。期待与你在LFX Mentorship 2026 秋季计划协作开拓AI大数据、LLM大模型推理等场景应用的更多可能。  面 向 对 象 本期计划申请者需2026年8月18日前在LFX官网[1]完成Mentee注册及项目申请。若被接收作为Mentee，您将能在开源社区经验丰富、积极贡献的Mentor指导下参与开源社区共建。依据官方规定，对Mentee申请者有以下要求[2]:在参加该计划时您至少年满18周岁所在单位和组织不禁止该实习未参加另外的Linux Mentorship计划开发者以个人身份参与（在校或已毕业均可）具备所注册国家中工作权利且所注册国家未被计划禁止 (中国已获许可)满足具体所属项目中提及的其它前置需求  课题参与方式  根据官方安排 [3]，LFX Mentorship 2026 Term3（秋季） 申请及实习流程如下：Mentee注册与项目申请：8月3日-8月18日（00:00 UTC/23:59 UTC)申请者审核期： 8月19日-9月1日（18:00 UTC)申请者入选通知：9月2日-9月4日实习正式开始：9月7日中期考核：10月20日（18:00 UTC)首次津贴支付：10月21日结项评估：11月24日（18:00 UTC)最终津贴支付批准：11月25日本期结束最终日期：11月27日参与者如有意向如何申请？流程详见 [4]：https://docs.linuxfoundation.org/lfx/mentorship/mentee-guide/how-to-apply主线开发日期为2026年9月7日-11月24日，全程线上协作，无需线下参与。结项需要在2026年11月24日前以 PR 的形式提交到项目所在的开源社区仓库中并完成合并。  欢迎申报 Volcano 课题  今年秋季，Volcano 社区带来以下 4 个课题，欢迎各位申请者加入：▍Volcano 通用 xPU 拓扑感知调度课题描述：当前，Volcano 主要根据 Node 上 xPU 资源的总量进行调度，但对 GPU、NPU 等加速设备之间的物理互联关系缺少感知。对于通信密集型 AI 作业，仅仅满足设备数量并不意味着能够获得合适的通信拓扑。例如，一台 16 卡 NPU 服务器可能包含两个相互独立的 8 卡 HCCS 互联域。如果一个互联域空闲 6 张卡，另一个空闲 2 张卡，那么 Node 上虽然共有 8 张空闲 NPU，却无法满足“8 张卡位于同一互联域”的调度要求。NVLink、NVSwitch 以及其他 xPU 高速互联也存在类似问题。多机训练场景还需要区分两类拓扑：普通多节点集群中，NVLink、NVSwitch 或 HCCS 仅存在于单个 Node 内，节点之间通过 InfiniBand 或 RoCE 通信；GB200 NVL72 等系统中，多个 Kubernetes Node 上的 GPU 通过机架级 NVLink 背板组成同一个跨节点高速互联域。本课题将在 Volcano 中实现通用的 xPU 拓扑感知调度能力。调度器需要在 Pod 绑定之前感知设备拓扑及其可用状态，根据作业需求选择合适的 HyperNode 或跨节点互联域、Node、节点内设备互联域以及具体设备。拓扑信息的来源与调度逻辑需要解耦。调度器通过统一接口消费标准化的拓扑信息，底层可以来自 Node Annotation、拓扑 CRD、Device Plugin 配套组件、厂商接口或 DRA ResourceSlice。课题前期可以使用 KWOK 和模拟拓扑数据完成开发及验证，不依赖真实的 NVL72 等硬件环境。预期产出：设计并实现厂商无关的 xPU 拓扑模型及拓扑信息接入接口，统一表达节点内设备互联域、跨节点高速互联域、设备状态以及与 HyperNode 的关系。实现可选的 xPU 拓扑感知调度插件，根据互联域的实际可用设备进行过滤和打分，并支持具体设备选择、Gang 级资源预留及失败回滚。将设备拓扑及其空闲、已分配、已预留和异常状态集成到 Volcano 现有调度缓存中，通过索引和增量更新控制调度开销。基于 KWOK 构建功能和性能测试，覆盖单节点多互联域、无跨节点 xPU 背板的多机作业，以及 NVL72 风格的跨节点互联场景。输出单元测试、集成或 E2E 测试、性能测试报告、使用文档及拓扑接入指南。若条件允许，可进一步对接模拟或真实 Device Plugin，但不作为课题验收的硬性要求。前置技能：熟练使用 Go，具备实际的 Kubernetes 开发经验熟悉 Kubernetes 调度器、控制器或资源管理机制具备 GPU、NPU 或其他 xPU 的使用和资源管理经验了解分布式 AI 作业、Gang 调度或设备拓扑者优先了解 Volcano、Kubernetes Device Plugin、DRA、NVLink、NVSwitch、HCCS 等技术者优先具备测试、性能分析或调度算法开发经验者优先课题导师：Zicong Chen（ @JesseStutler ）jessestutler97@gmail.comYang Wang（ @wangyang0616 ）wangyang8216@gmail.comJoão Azevedo（ @devzizu ）jazevedo960@gmail.comHajnal Mate（ @hajnalmt ）hajnalmt@gmail.com原始 Issue：cid:link_2课题申请入口：https://mentorship.lfx.linuxfoundation.org/project/087b7172-482e-4ae8-af7a-a27f56fbe09f ▍支持 Pod 原地滚动更新功能课题描述：目前，Kthena 的 RollingUpdate 策略主要通过删除旧资源、创建新资源的方式更新工作负载。这种方式适用于任意 Pod 模板变更，但当更新内容仅为容器image时，会带来不必要的资源开销。Kubernetes 支持直接修改现有 Pod 中容器的image。更新后，Kubelet 会重新启动受影响的容器，同时保留原有 Pod 对象。本项目计划为 ModelServing 增加明确的原地滚动更新（Inplace Rolling Update）策略，并完善其安全性、服务可用性、异常恢复及状态展示等相关语义，从而降低镜像更新成本，提升模型服务升级效率。预期产出：完成原地滚动更新功能的设计提案，并在 Kthena 社区会议中进行分享；完成相关功能的代码实现；补充对应的单元测试和端到端测试；编写并完善用户使用指南。 Device Plugin，但不作为课题验收的硬性要求。前置技能：Go 语言开发；熟悉 Kubernetes 基础概念及工作负载更新机制；对云原生、容器编排或模型服务方向感兴趣；具备良好的开源协作与沟通能力。课题导师：ZhenCheng Lee（ @LiZhenCheng9527 ）lizhencheng6@huawei.comJinYu Zhou（ @FAUST-BENCHOU ）2319109590@qq.com原始 Issue：cid:link_3课题申请入口：https://mentorship.lfx.linuxfoundation.org/project/6c797658-daa1-40d6-b24c-3bf496e75755 ▍Volcano Dashboard：Kthena 资源管理与运维可观测性课题描述：Volcano Dashboard 已支持 Job、Queue、Pod 和 PodGroup 等资源的查看与管理，但目前尚未覆盖 Volcano 推理子项目 Kthena 的相关资源。用户在管理和排查 Kthena 工作负载时，仍然需要依赖 kubectl 或其他工具，难以在统一界面中查看服务状态、路由配置、发布进度以及相关资源之间的关系。本课题将在 Volcano Dashboard 中增加对 Kthena 的支持，重点覆盖 ModelServing、ModelBooster、ModelRoute 和 ModelServer 等核心资源，并结合实际运维需求完善资源管理、状态展示和问题排查能力。除了基本的资源列表和详情页面，Dashboard 还需要清晰展示资源 Conditions、实例状态、发布进度、路由关系，以及 Kthena 资源与 Pod、PodGroup、Queue 等底层资源之间的关联。用户可以通过统一界面了解 Kthena 工作负载的整体运行情况，并快速定位服务异常、发布失败或路由配置问题。预期产出：在 Volcano Dashboard 中支持 ModelServing、ModelBooster、ModelRoute 和 ModelServer 等主要 Kthena 资源，提供与现有 Dashboard 风格一致的列表、详情和必要的管理操作。展示 Kthena 资源的 Conditions、实例状态、发布进度和路由信息，并支持在 Kthena 资源与相关 Pod、PodGroup、Queue 等对象之间快速导航。完善 Kthena 的运维和问题排查体验，通过服务健康状态、路由关系和关联资源信息，帮助用户理解工作负载当前状态并定位异常。完成所需的 Kubernetes RBAC 和部署配置调整，并补充自动化测试、用户文档和使用示例。前置技能：熟悉 TypeScript、React 和 Next.js具备 Kubernetes API 和 RBAC 的实际使用经验了解 Kubernetes CRD 及资源状态管理机制具备 Web 管理平台或可观测性功能开发经验了解 Volcano、Kthena 或 AI 推理系统者优先具备自动化测试、技术设计和开源协作经验者优先课题导师：ZhenCheng Lee（ @LiZhenCheng9527 ）lizhencheng6@huawei.comKuldeep Singh（ @de6p ）de6p97@gmail.comZicong Chen（ @JesseStutler ）jessestutler97@gmail.com原始 Issue：cid:link_1课题申请入口：https://mentorship.lfx.linuxfoundation.org/project/b2d21cb7-4380-4375-9384-ca791e652f0d ▍构建支持 KVCache 的调度器端到端（E2E）测试套件课题描述：Kthena Router 已具备较为完善的调度器插件端到端测试框架，目前覆盖 Prefix Cache、Least Request、Least Latency、LoRA Affinity、Random 和 GPU Usage 等调度策略。KVCache 感知调度器插件虽然已经实现，但仍缺少覆盖完整运行链路的端到端测试，包括 Router、模拟后端、Tokenization、ZMQ 事件以及 Redis 等组件之间的协作。本项目计划基于现有 Router 插件测试框架，构建一套可复用的 KVCache 感知调度器 E2E 测试套件。除了验证实际路由行为外，还将提供通用的环境搭建、缓存状态注入、运行状态观测和结果断言工具，为后续新增 KVCache 调度测试场景提供基础设施支持。预期产出：在 test/e2e/router/ 目录下构建可复用的 KVCache 感知 E2E 测试套件。提供 llm-d-sim、ZMQ Bridge、Redis、缓存状态注入、请求生成和路由结果断言等共享 Fixture 与辅助工具。验证完整的数据链路：通过 ZMQ 分发 KV Cache 所有权事件，检查 Redis 中生成的映射关系，并确认 Router 在副本评分和路由决策时能够正确使用这些信息。提供可独立运行该测试套件的专用命令或 Make Target。编写相关文档，帮助贡献者快速添加新的 KVCache 感知测试场景。将测试套件集成至 CI，确保环境能够稳定、确定性地清理，并在测试失败时输出 Router、Redis、ZMQ 和后端状态等有效诊断信息。前置技能：GoKubernetes基于 Kind 的 E2E 测试RedisZMQ可观测性与指标监控分布式系统调试课题导师：Jinyu Zhou（ GitHub:@FAUST-BENCHOU ; LFX ID：@benchou8 ）2319109590@qq.comJprakash（ GitHub:@katara-Jayprakash LFX ID：@lfxkatara1 ）katarajayprakash@icloud.com原始 Issue：cid:link_4 课题申请入口：https://mentorship.lfx.linuxfoundation.org/project/16e5821d-2ae3-4145-a729-1b0c755b613b  更多Volcano课题，请访问LFX Mentorship官网；对课题有任何问题，欢迎直接向课题导师发送邮件或在GitHub仓库提交Issue提问。附：相关指引链接[1] LFX Mentorship计划官网及申报入口: https://mentorship.lfx.linuxfoundation.org/#projects_all[2] LFX Mentorship - Application Requirement: https://docs.linuxfoundation.org/lfx/mentorship/mentee-guide/am-i-eligible[3] LFX Mentorship - Program Readme: cid:link_0[4] LFX Mentorship - Mentee Application Guideline: https://docs.linuxfoundation.org/lfx/mentorship/mentee-guide/how-to-apply[5] Volcano GitHub: cid:link_5[6] Volcano/Kthena GitHub: cid:link_6关注容器魔方，获取更多前沿资讯

Kubernetes 默认调度器主要根据 Pod 的资源申请量来选择节点。但在真实集群中，资源申请量不一定等于实际使用量。当用户批量下发 Pod、滚动升级或扩缩容时，这种判断偏差会被放大，容易造成节点热点甚至 OOM。华为云云容器引擎 CCE （下简称 CCE ) Volcano 调度器提供的负载感知调度能力，将节点真实 CPU、内存负载纳入调度决策，让新负载更合理地分布到集群中。 ▍为什么需要负载感知调度1. Pod Request 值与真实资源使用错配业务的资源申请量和实际使用量经常不一致。比如 Java 类业务在启动阶段可能瞬时占用大量 CPU，但稳定运行后资源消耗下降；有些任务内存申请得比较保守，实际使用量远低于 Request；更有甚者， BestEffort Pod 没有 Request 和 Limit，调度器无法从资源声明中判断它们会消耗多少资源。2. 监控数据更新和调度决策之间存在时间差短时间批量创建 Pod 时，调度器可能已经连续把多个 Pod 分配到同一个节点，但这些新 Pod 的资源消耗还没有进入监控曲线。此时节点看起来仍然很空，后续 Pod 可能继续被调度到这个节点。等负载真正跑起来后，节点已经变成热点。3. 批量下发和滚动升级会放大偏差单个 Pod 调度不准，影响可能有限。但 Deployment 批量创建、滚动升级、扩缩容会在短时间内触发多次调度决策。如果每次都基于错配的集群状态，就容易把一批新负载集中放到少数节点上。在真实客户的 CCE 生产集群中，目前业务的内存 Request 和 Limit 通常相差 2G，典型业务可能配置 Request = 12G，Limit = 14G。滚动变更时，如果某个节点因旧 Pod 删除导致真实内存水位短暂下降，例如从 60% 降到 40%，调度器在多个节点的可分配资源都满足的情况下，容易连续选择这个瞬时低水位节点。这会导致新 Pod 集中调度，等业务真正启动并接近实际内存使用后，该节点又迅速变成热点，最终造成节点间负载不均和发布过程中的稳定性风险。▍CCE 负载感知调度架构核心方案在 CCE 生产集群中，华为云在 Volcano 负载感知调度插件（Usage）中率先集成了云原生监控插件与影子负载机制。它不仅能够实时拉取节点的真实 CPU 与内存利用率，还引入了影子负载缓存与 Pod 资源预估模型，将静态指标与动态感知有机结合，保障集群高效平稳运行。▲ CCE Volcano 负载感知调度架构1. 引入真实负载CCE Volcano 负载感知调度插件可以从 CCE 云原生监控插件中获取节点当前 CPU、内存使用率，让调度器知道节点现在的真实资源利用率。2. 引入影子负载对于已经被调度、但还没有被监控系统采集到的 Pod，CCE Volcano 会在调度器内部维护一份 Shadow Load Cache，提前把这些 Pod 对节点造成的压力计入调度决策。3. 引入 Pod 资源预估对于即将调度的新 Pod，CCE Volcano 会根据 Request、Limit、Burst、BestEffort 默认值以及风险系数，估算它可能带来的 CPU 和内存压力。4. 把这些信息接入调度流程在调度时，节点判断不再只依赖静态资源声明，而是综合考虑：节点综合负载 = 真实监控负载 + 影子负载 + 新 Pod 预估压力CCE Volcano 调度框架的两个关键阶段会分别使用上述信息：Predicate 阶段：Usage 插件根据真实负载阈值过滤高压节点；NodeOrder 阶段：综合负载参与节点打分，综合负载越低得分越高，综合负载越高得分越低▍关键实现要点1. 影子负载缓存解决监控滞后问题影子负载缓存记录当前调度 Session 中已经调度、正在绑定、刚 Running 但尚未进入监控窗口的 Pod。这样即使监控指标还没刷新，调度器也能知道某个节点已经被分配了新的负载，避免后续 Pod 继续集中落到同一个节点上。2. Pod 资源预估公式对于有 Request 和 Limit 的 Pod，CCE Volcano 通过下面的方式估算资源压力： Pod Estimate= (request × request_ratio + (limit - request） × burst_ratio)× applied_risk_factor变量含义request/ limitPod 声明的 Request / Limit 值request_ratioRequest 部分的权重，默认 0.7burst_ratio突发量（limit − request）部分的权重，默认 0applied_risk_factor动态风险系数：当节点综合水位 < risk_threshold 时取 1；≥ risk_threshold 时取 risk_factor（默认 1.2）3. 高水位风险保护让调度更保守当节点综合水位超过 risk_threshold 后，后续考虑调度到该节点的 Pod 预估值会乘以 risk_factor。这意味着节点越热，调度器越保守，从而降低继续堆叠负载的概率。变量含义risk_threshold触发风险系数的节点综合水位线，默认60%。risk_factor节点综合水位达 risk_threshold 后，后续调度到该节点的 Pod 预估值所乘的放大系数，默认1.2。4. 预估值回滚一致性CCE Volcano 会在 Pod 加入影子负载时保存快照，记录它当时估算了多少 CPU、多少内存、落在哪个节点。发生回滚时，直接按快照扣回，而不是重新计算。这样即使节点水位或风险系数在中间发生变化，也能保证加减一致。5. 支持业务化调优Usage 插件的默认预估值为：Burstable / Guaranteed Pod 取 CPU 0.7 * request、内存 0.7 * request；BestEffort Pod 取 CPU 250m、内存 200Mi。但实际生产环境中，不同业务对资源的使用方式差异很大，每批下发的作业资源属性也不一致。CCE Volcano 提供了从 0 到 Limit 值可配的 Pod 资源预估值配置项，用户可在不同业务场景下灵活配置，实现作业的准确均衡调度。下面是一个配置示例：actions: "enqueue, allocate, backfill"tiers: - plugins: - name: usage enablePredicate: false arguments: usage.weight: 5 cpu.weight: 1 memory.weight: 1 thresholds: cpu: 80 mem: 80 estimator: request_ratio: 0.7 burst_ratio: 0 risk_threshold: 0.6 risk_factor: 1.2 be_cpu: 250m be_mem: 200Mimetrics: type: prometheus address: http://prometheus:9090 interval: 30s参数说明参数含义默认值enablePredicate真实负载阈值生效方式。true（默认）= 硬约束，达阈值后该节点不再调度新任务；false = 软约束，达阈值后新任务优先调度到未达阈值节点，但该节点仍允许调度。本示例设为 false 以演示软约束下的打分效果。trueusage.weightUsage 插件在 NodeOrder 阶段对节点打分的权重。1cpu.weight / memory.weight增大对应资源种类的均衡权重。1 / 1thresholds.cpu/ thresholds.mem节点真实利用率阈值，超过后按 enablePredicate 的约束方式调度新工作负载（已运行工作负载不受影响，需配合 enablePredicate 使用）。80 / 80request_ratioRequest 占 Pod 预估值的权重。0.7burst_ratio突发量（Limit − Request）占 Pod 预估值的权重。0risk_threshold触发风险系数的节点综合水位线。0.6risk_factor节点综合水位达 risk_threshold 后，后续调度到该节点的 Pod 预估值所乘的放大系数。1.2be_cpu / be_memBestEffort Pod 的默认 CPU / 内存估算值。250m / 200Mi▍效果验证下面将介绍如何在华为云CCE集群上验证这个特性的效果。在华为云 CCE 集群使用 Volcano 负载感知调度能力1. 开启负载感知调度关于监控插件的配置，负载感知调度功能开启等操作请参考 CCE Volcano 负载感知调度官方文档：cid:link_22. 环境准备CCE集群环境信息：2 个 4U16G 节点，四个 4U8G 节点。功能验证所需插件在指定两个 4U16G 节点调度并安装完成之后，把两个 4U16G 节点置为不可调度。3. 验证调度效果环境现状通过下发三个指定节点调度的 Deployment，分别有 10/6/2 个副本。每个副本都为 CPU Request=200m, Limit=250m Memory Request=500Mi, Limit=600Mi 并加压到 Request 值这样可以构造集群上节点1占了60%，节点2占35%，节点3占10%，节点4空的情况。执行操作下发一个含 20 个副本的 Deployment，每个副本 CPU Request=200m、Limit=250m，Memory Request=500Mi、Limit=600Mi；加压方式模拟 Java 业务的真实压力曲线：启动陡增后回落到平稳水位；在 Deployment 稳定运行后，进行两次滚动升级操作。预期结果集群 4 个可调度节点初始压力不均匀。下发 Deployment 时，调度器应在调度每个 Pod 时实时考虑：集群中每个节点的真实压力；同一 Session 中之前已调度的 Pod 对集群产生的压力（影子负载）。这样才能在调度完整批副本后，把负载均分到 4 个节点，使四节点内存与 CPU 水位相近，且运行一段时间后无 OOM。两次滚动升级后，各节点压力也应保持相对平均。实际结果批量下发一批新负载后的结果。第一次滚动升级后的调度结果：第二次滚动升级后的调度结果：可以看到在批量下发和滚动升级之后，调度结果都在四个节点中平均分布，符合打散一批负载在集群中各节点分布的预期。▍演进方向Volcano 负载感知调度特性当前已覆盖 CPU 和内存资源，后续可从三个方向扩展：异构资源扩展：在 AI 训练、推理、视频处理等场景中，GPU/NPU 利用率、显存、设备队列等待时间都会影响调度质量，仅看 CPU 和内存已不够。未来把影子负载与风险估算扩展到这些指标上。节点池粒度负载感知：生产集群常按节点池区分规格、可用区、业务类型或成本模型。只看单节点，可能留下节点池层面的冷热不均，后续可加入节点池级别的负载感知。预估模型自适应：当前 request_ratio / burst_ratio 等参数需用户静态配置，未来可结合历史负载曲线做自适应估计，进一步降低调参成本▍总结负载感知调度解决的是生产环境中经常遇到的问题：Pod 申报的资源和真实消耗不总是一致，监控指标也不总是和调度决策同步，从而导致资源错配。Volcano Usage 插件把真实指标、节点阈值、节点打分、影子负载、资源预估与回滚一致性串接到同一条调度链路中：真实指标：CCE Volcano 从 CCE 云原生监控插件主动拉取节点真实压力；影子负载：覆盖节点上尚未纳入监控范围的 Pod 的预估值；资源预估：使不同 QoS 等级的 Pod 占用都能被合理量化；快照回滚：保证 Deallocate 之后增减一致，不留下错误记录。对用户而言，负载感知调度的价值比较直接：批量新建、滚动升级、扩缩容时，不容易把新负载继续堆到即将变热的节点上；当业务 Request 值不够准确时，也可通过参数调整调度策略，实现更稳健的均衡调度。华为云 CCE 团队结合大规模生产集群的真实打磨，沉淀出这一负载感知调度方案。同时，作为 Volcano 社区的核心贡献者，团队已将相关的代码与特性贡献至 Volcano 开源社区，以推动云原生调度技术的持续演进。 参考资料CCE Volcano 负载感知调度官方文档：cid:link_2Kubernetes 调度框架文档：https://kubernetes.io/docs/concepts/scheduling-eviction/ 关注魔方公众号，获取更多前沿资讯 

Kubernetes 默认调度器主要根据 Pod 的资源申请量来选择节点。但在真实集群中，资源申请量不一定等于实际使用量。当用户批量下发 Pod、滚动升级或扩缩容时，这种判断偏差会被放大，容易造成节点热点甚至 OOM。华为云云容器引擎 CCE （下简称 CCE ) Volcano 调度器提供的负载感知调度能力，将节点真实 CPU、内存负载纳入调度决策，让新负载更合理地分布到集群中。▍为什么需要负载感知调度1. Pod Request 值与真实资源使用错配业务的资源申请量和实际使用量经常不一致。比如 Java 类业务在启动阶段可能瞬时占用大量 CPU，但稳定运行后资源消耗下降；有些任务内存申请得比较保守，实际使用量远低于 Request；更有甚者， BestEffort Pod 没有 Request 和 Limit，调度器无法从资源声明中判断它们会消耗多少资源。2. 监控数据更新和调度决策之间存在时间差短时间批量创建 Pod 时，调度器可能已经连续把多个 Pod 分配到同一个节点，但这些新 Pod 的资源消耗还没有进入监控曲线。此时节点看起来仍然很空，后续 Pod 可能继续被调度到这个节点。等负载真正跑起来后，节点已经变成热点。3. 批量下发和滚动升级会放大偏差单个 Pod 调度不准，影响可能有限。但 Deployment 批量创建、滚动升级、扩缩容会在短时间内触发多次调度决策。如果每次都基于错配的集群状态，就容易把一批新负载集中放到少数节点上。在真实客户的 CCE 生产集群中，目前业务的内存 Request 和 Limit 通常相差 2G，典型业务可能配置 Request = 12G，Limit = 14G。滚动变更时，如果某个节点因旧 Pod 删除导致真实内存水位短暂下降，例如从 60% 降到 40%，调度器在多个节点的可分配资源都满足的情况下，容易连续选择这个瞬时低水位节点。这会导致新 Pod 集中调度，等业务真正启动并接近实际内存使用后，该节点又迅速变成热点，最终造成节点间负载不均和发布过程中的稳定性风险。▍CCE 负载感知调度架构核心方案在 CCE 生产集群中，华为云在 Volcano 负载感知调度插件（Usage）中率先集成了云原生监控插件与影子负载机制。它不仅能够实时拉取节点的真实 CPU 与内存利用率，还引入了影子负载缓存与 Pod 资源预估模型，将静态指标与动态感知有机结合，保障集群高效平稳运行。▲ CCE Volcano 负载感知调度架构1. 引入真实负载CCE Volcano 负载感知调度插件可以从 CCE 云原生监控插件中获取节点当前 CPU、内存使用率，让调度器知道节点现在的真实资源利用率。2. 引入影子负载对于已经被调度、但还没有被监控系统采集到的 Pod，CCE Volcano 会在调度器内部维护一份 Shadow Load Cache，提前把这些 Pod 对节点造成的压力计入调度决策。3. 引入 Pod 资源预估对于即将调度的新 Pod，CCE Volcano 会根据 Request、Limit、Burst、BestEffort 默认值以及风险系数，估算它可能带来的 CPU 和内存压力。4. 把这些信息接入调度流程在调度时，节点判断不再只依赖静态资源声明，而是综合考虑：节点综合负载 = 真实监控负载 + 影子负载 + 新 Pod 预估压力CCE Volcano 调度框架的两个关键阶段会分别使用上述信息：Predicate 阶段：Usage 插件根据真实负载阈值过滤高压节点；NodeOrder 阶段：综合负载参与节点打分，综合负载越低得分越高，综合负载越高得分越低▍关键实现要点1. 影子负载缓存解决监控滞后问题影子负载缓存记录当前调度 Session 中已经调度、正在绑定、刚 Running 但尚未进入监控窗口的 Pod。这样即使监控指标还没刷新，调度器也能知道某个节点已经被分配了新的负载，避免后续 Pod 继续集中落到同一个节点上。2. Pod 资源预估公式对于有 Request 和 Limit 的 Pod，CCE Volcano 通过下面的方式估算资源压力： Pod Estimate= (request × request_ratio + (limit - request × burst_ratio)× applied_risk_factor变量含义request/ limitPod 声明的 Request / Limit 值request_ratioRequest 部分的权重，默认 0.7burst_ratio突发量（limit − request）部分的权重，默认 0applied_risk_factor动态风险系数：当节点综合水位 < risk_threshold 时取 1；≥ risk_threshold 时取 risk_factor（默认 1.2）3. 高水位风险保护让调度更保守当节点综合水位超过 risk_threshold 后，后续考虑调度到该节点的 Pod 预估值会乘以 risk_factor。这意味着节点越热，调度器越保守，从而降低继续堆叠负载的概率。变量含义risk_threshold触发风险系数的节点综合水位线，默认60%。risk_factor节点综合水位达 risk_threshold 后，后续调度到该节点的 Pod 预估值所乘的放大系数，默认1.2。4. 预估值回滚一致性CCE Volcano 会在 Pod 加入影子负载时保存快照，记录它当时估算了多少 CPU、多少内存、落在哪个节点。发生回滚时，直接按快照扣回，而不是重新计算。这样即使节点水位或风险系数在中间发生变化，也能保证加减一致。5. 支持业务化调优Usage 插件的默认预估值为：Burstable / Guaranteed Pod 取 CPU 0.7 * request、内存 0.7 * request；BestEffort Pod 取 CPU 250m、内存 200Mi。但实际生产环境中，不同业务对资源的使用方式差异很大，每批下发的作业资源属性也不一致。CCE Volcano 提供了从 0 到 Limit 值可配的 Pod 资源预估值配置项，用户可在不同业务场景下灵活配置，实现作业的准确均衡调度。下面是一个配置示例：actions: "enqueue, allocate, backfill"tiers: - plugins: - name: usage enablePredicate: false arguments: usage.weight: 5 cpu.weight: 1 memory.weight: 1 thresholds: cpu: 80 mem: 80 estimator: request_ratio: 0.7 burst_ratio: 0 risk_threshold: 0.6 risk_factor: 1.2 be_cpu: 250m be_mem: 200Mimetrics: type: prometheus address: http://prometheus:9090 interval: 30s参数说明参数含义默认值enablePredicate真实负载阈值生效方式。true（默认）= 硬约束，达阈值后该节点不再调度新任务；false = 软约束，达阈值后新任务优先调度到未达阈值节点，但该节点仍允许调度。本示例设为 false 以演示软约束下的打分效果。trueusage.weightUsage 插件在 NodeOrder 阶段对节点打分的权重。1cpu.weight / memory.weight增大对应资源种类的均衡权重。1 / 1thresholds.cpu/ thresholds.mem节点真实利用率阈值，超过后按 enablePredicate 的约束方式调度新工作负载（已运行工作负载不受影响，需配合 enablePredicate 使用）。80 / 80request_ratioRequest 占 Pod 预估值的权重。0.7burst_ratio突发量（Limit − Request）占 Pod 预估值的权重。0risk_threshold触发风险系数的节点综合水位线。0.6risk_factor节点综合水位达 risk_threshold 后，后续调度到该节点的 Pod 预估值所乘的放大系数。1.2be_cpu / be_memBestEffort Pod 的默认 CPU / 内存估算值。250m / 200Mi▍效果验证下面将介绍如何在华为云CCE集群上验证这个特性的效果。在华为云 CCE 集群使用 Volcano 负载感知调度能力1. 开启负载感知调度关于监控插件的配置，负载感知调度功能开启等操作请参考 CCE Volcano 负载感知调度官方文档：cid:link_12. 环境准备CCE集群环境信息：2 个 4U16G 节点，四个 4U8G 节点。功能验证所需插件在指定两个 4U16G 节点调度并安装完成之后，把两个 4U16G 节点置为不可调度。3. 验证调度效果环境现状通过下发三个指定节点调度的 Deployment，分别有 10/6/2 个副本。每个副本都为 CPU Request=200m, Limit=250m Memory Request=500Mi, Limit=600Mi 并加压到 Request 值这样可以构造集群上节点1占了60%，节点2占35%，节点3占10%，节点4空的情况。执行操作下发一个含 20 个副本的 Deployment，每个副本 CPU Request=200m、Limit=250m，Memory Request=500Mi、Limit=600Mi；加压方式模拟 Java 业务的真实压力曲线：启动陡增后回落到平稳水位；在 Deployment 稳定运行后，进行两次滚动升级操作。预期结果集群 4 个可调度节点初始压力不均匀。下发 Deployment 时，调度器应在调度每个 Pod 时实时考虑：集群中每个节点的真实压力；同一 Session 中之前已调度的 Pod 对集群产生的压力（影子负载）。这样才能在调度完整批副本后，把负载均分到 4 个节点，使四节点内存与 CPU 水位相近，且运行一段时间后无 OOM。两次滚动升级后，各节点压力也应保持相对平均。实际结果批量下发一批新负载后的结果。第一次滚动升级后的调度结果：第二次滚动升级后的调度结果：可以看到在批量下发和滚动升级之后，调度结果都在四个节点中平均分布，符合打散一批负载在集群中各节点分布的预期。▍演进方向Volcano 负载感知调度特性当前已覆盖 CPU 和内存资源，后续可从三个方向扩展：异构资源扩展：在 AI 训练、推理、视频处理等场景中，GPU/NPU 利用率、显存、设备队列等待时间都会影响调度质量，仅看 CPU 和内存已不够。未来把影子负载与风险估算扩展到这些指标上。节点池粒度负载感知：生产集群常按节点池区分规格、可用区、业务类型或成本模型。只看单节点，可能留下节点池层面的冷热不均，后续可加入节点池级别的负载感知。预估模型自适应：当前 request_ratio / burst_ratio 等参数需用户静态配置，未来可结合历史负载曲线做自适应估计，进一步降低调参成本▍总结负载感知调度解决的是生产环境中经常遇到的问题：Pod 申报的资源和真实消耗不总是一致，监控指标也不总是和调度决策同步，从而导致资源错配。Volcano Usage 插件把真实指标、节点阈值、节点打分、影子负载、资源预估与回滚一致性串接到同一条调度链路中：真实指标：CCE Volcano 从 CCE 云原生监控插件主动拉取节点真实压力；影子负载：覆盖节点上尚未纳入监控范围的 Pod 的预估值；资源预估：使不同 QoS 等级的 Pod 占用都能被合理量化；快照回滚：保证 Deallocate 之后增减一致，不留下错误记录。对用户而言，负载感知调度的价值比较直接：批量新建、滚动升级、扩缩容时，不容易把新负载继续堆到即将变热的节点上；当业务 Request 值不够准确时，也可通过参数调整调度策略，实现更稳健的均衡调度。华为云 CCE 团队结合大规模生产集群的真实打磨，沉淀出这一负载感知调度方案。同时，作为 Volcano 社区的核心贡献者，团队已将相关的代码与特性贡献至 Volcano 开源社区，以推动云原生调度技术的持续演进。 参考资料CCE Volcano 负载感知调度官方文档：cid:link_1Kubernetes 调度框架文档：https://kubernetes.io/docs/concepts/scheduling-eviction/ 关注魔方公众号，获取更多前沿资讯添加社区小助手k8s2222，进入CCE技术交流群

随着大模型向长上下文（Long-Context）和复杂推理任务演进，Prefill-Decode（预填充-解码，简称 PD）分离架构已成为提升集群整体吞吐量的标准实践。然而，在分布式架构下，将庞大的 KVCache 从 Prefill 节点跨网络传输至 Decode 节点，往往会带来显著的通信开销，成为制约系统性能的新瓶颈。业界优秀的开源 LLM 推理增强系统 Mooncake 凭借其对 KVCache 的全局池化管理与跨节点复用能力，有效解决了这一难题。作为一款云原生环境下的分布式推理负载编排引擎，Kthena 在 v0.4.0 版本中已全面支持基于 vLLM 和 Mooncake 的 PD 分离部署，并深度针对华为昇腾（Ascend）NPU 集群进行了硬件级优化。▍解决 KVCache 传输痛点：Mooncake 的核心价值在传统的 PD 分离方案中，每次请求都需要在节点间进行点对点的 KVCache 搬运。而 Kthena 引入 Mooncake 后，系统具备了以下关键能力：全局 KVCache 池化：将集群中分布在各个节点（特别是高算力的昇腾节点）的内存与显存统一管理，构建分布式的 KVCache 存储池。跨节点复用：对于具有相同前缀（Prefix）的请求，Mooncake 可以直接复用已生成的 KVCache，显著降低重复的 Prefill 计算开销。降低 TTFT（Time to First Token，首Token延迟）：通过高效的底层传输与缓存命中，长上下文场景下有效降低首Token延迟。▍Kthena 中的分布式编排与昇腾硬件加速在 Kubernetes 环境中手动配置复杂的 PD 分离与 Mooncake 组件是一项繁琐的工作。Kthena 将这种复杂的分布式拓扑抽象为声明式的 API，并与华为昇腾硬件底座深度融合：1. 精细化的节点调度与资源分配Kthena 允许用户根据 Prefill 和 Decode 的不同计算特征进行资源编排：Prefill 阶段（计算密集型）：自动调度至具备高计算吞吐量的昇腾节点，利用 NPU 的并行张量运算能力快速生成初始 KVCache。Decode 阶段（显存/内存密集型）：调度至配备大容量内存的昇腾节点，专注于自回归的 Token 生成。2. 基于 HCCL 的底层通信优化在 KVCache 的实际传输链路上，Kthena 结合了华为集合通信库（HCCL）。通过 NPU 专用的网络接口和通信协议，系统能够在支持 NPU 的节点之间实现更低延迟的数据交换，确保 Mooncake 的高速缓存读取不受底层网络限制。▍实战：在集群中启用分离推理通过以下步骤，您可以快速在配备昇腾 NPU 的 K8s 集群中部署基于 Mooncake Connector的分离式deepseek-v4推理服务。1. 部署 ModelServing（编排工作负载）首先，创建 ModelServing 资源[1]以拉起预填充和解码的具体工作负载。该配置定义了预填充角色和解码角色，并分配了针对 NPU 优化的容器及硬件资源。kubectl apply -f https://raw.githubusercontent.com/volcano-sh/kthena/main/examples/models/deepseek-v4-flash/modelserving.yaml2. 创建推理路由策略ModelServer（配置网络拓扑）接下来，创建 ModelRoute和ModelServer 资源[2]。这一步负责创建模型路由规则和KV Connector感知，包含感知Prefill、Decode不同角色的工作负载，以及传输层的流量策略。cat <<EOF | kubectl apply -f - apiVersion: networking.serving.volcano.sh/v1alpha1 kind: ModelRoute metadata: name: deepseek-v4 namespace: default spec: modelName: "deepseek_v4" rules: - name: "default" targetModels: - modelServerName: "deepseekv4-pd" --- apiVersion: networking.serving.volcano.sh/v1alpha1 kind: ModelServer metadata: name: deepseekv4-pd namespace: default spec: inferenceEngine: vLLM model: "deepseek_v4" workloadPort: port: 7100 protocol: http workloadSelector: matchLabels: modelserving.volcano.sh/name: deepseekv4-pd pdGroup: groupKey: "modelserving.volcano.sh/group-name" prefillLabels: modelserving.volcano.sh/role: prefill decodeLabels: modelserving.volcano.sh/role: decode trafficPolicy: timeout: "300s" retry: attempts: 3 retryInterval: "150ms" kvConnector: type: mooncake EOF3. 验证部署与测试完成上述三个 CRD 的部署后，PD分离推理即搭建完成。您可以通过调用 Chat API 来测试预填充和解码服务是否正常通信：curl --location 'http://${ENDPOINT}/v1/chat/completions' \ --header 'Content-Type: application/json' \ --data '{ "model": "deepseek_v4", "messages": [ { "role": "user", "content": "Where is the capital of China?" } ], "stream": false }'(注：请将 ${ENDPOINT} 替换为您的实际Kthena Router入口的IP 地址和端口。)如果收到正确的响应文本，即表明预填充服务已成功将生成的 KV 缓存通过底层通信层传输给解码服务，分离推理架构正在按预期高效工作。▍结 语随着各类推理框架对 PD 分离和 KVCache 优化的持续跟进，分布式推理架构的落地标准正在不断提高。Kthena 通过集成 Mooncake 并结合昇腾 NPU 的硬件级优化，为开发者提供了一个开箱即用的分布式推理负载编排解决方案，旨在以客观的工程指标提升 LLM 在生产环境中的实际运行效率。了解完整的部署指南与架构细节，欢迎访问 Kthena [3]官方文档或访问 GitHub 仓库 (volcano-sh/kthena[4])。 相关链接：[1]  Deepseek-v4部署脚本 modelserving:cid:link_0[2]  Deepseek-v4部署脚本 router: cid:link_1[3]  Kthena官网: https://kthena.volcano.sh/[4]  volcano-sh/kthena GitHub: cid:link_3 欢迎Star★，Fork，来 Kthena 社区一起玩转LLM推理！ 关注魔方公众号，获取更多前沿资讯添加社区小助手k8s2222，进入技术交流群

随着大模型技术的飞速发展，AI Agent 正从概念走向生产。与传统的批处理任务或推理服务不同，Agent 工作负载呈现出独特的运行特征——间歇性活跃、极低延迟敏感、多轮会话状态持久化。然而，现有的 Kubernetes 调度体系主要面向批处理和长运行服务设计，难以有效应对这类"潮汐式"交互负载：空闲时资源白白占用，唤醒时又无法做到亚秒级响应，状态管理更是一大痛点。AgentCube[1] 正是为解决这一矛盾而生。作为 Volcano社区[2]的子项目，AgentCube 专为 AI Agent 工作负载打造了专用的控制面与数据面，核心优势体现在四个方面：极速启动—— 通过 Warm Pool （预热池）机制预先创建并暂停一批沙箱，当 Agent 请求到来时以 "Claim-and-Go" 的方式进行毫秒级分配，消除冷启动瓶颈。高效调度 —— 借助 Volcano Agent Scheduler 的乐观并发控制与精简调度策略，大幅提升调度吞吐，并能与 Volcano 原有的 Batch Scheduler 无缝协作，确保 Agent 与传统批处理作业的统一调度与资源协调。原生会话管理 —— 以 Session ID 为核心路由标识，会话到来时自动识别并路由请求至对应沙箱，并在沙箱休眠时自动唤醒，保障多轮交互的上下文连续性。安全隔离 —— 为每个会话分配独立沙箱，确保计算、内存与文件系统的端到端隔离，防止跨租户数据泄露。同时支持以安全容器运行 Agent，借助安全运行时技术实现内核级强隔离。本文将聚焦 AgentCube 在华为云 CCE（云容器引擎）上的实践，探讨如何将 AgentCube 的调度能力与 CCE 的基础设施深度结合，为 AI Agent 应用提供高效、稳定的云原生运行底座。关于AgentCube的原理可通过设计文档[3]或往期文章[4]了解。  环境准备  已经创建好了一个1.29或更高版本的CCE集群确保本地安装的python版本>=3.11安装SDK[5] ： pip install agentcube_sdk  安装 AgentCube 插件  AgentCube目前已上架华为云 CCE 插件市场。可通过登录CCE控制台[6]进入集群插件中心界面，找到AgentCube插件进行配置安装。 AgentCube主要组件：workloadmanager：管理AgentRuntime和CodeInterpreter的生命周期。agentcube-router：API 网关，代理客户端请求到沙箱实例。volcano-agent-scheduler：调度器组件，提供低延迟和高吞吐的负责调度。agent-sandbox-controller：管理AgentSandbox资源。安装时需要设置如下参数：redis.addr：Redis的地址，必须配置。redis.password：Redis的密码，必须配置。agentSandbox.install：是否自动安装agent-sandbox。AgentCube插件运行时依赖 agent-sandbox[7]，当参数配置为true时会自动安装。如果集群已手动安装了agent-sandbox，则可配置为false跳过安装。agentSandbox.extensions：是否启用agent-sandbox的extension controller。volcano.scheduler.enabled：是否安装volcano agent-scheduler调度器。由于AgentCube运行时依赖Redis维护会话状态和索引，从稳定性和可扩展性考虑，建议购买和使用华为云分布式缓存服务 DCS[8]。此外，如果要在集群外访问 AgentCube，可为workloadmanager和agentcube-router的Service绑定ELB Ingress。  开始使用  ▍步骤一：环境变量设置export WORKLOAD_MANAGER_URL="http://workloadmanager-addr:workloadmanager-port" export ROUTER_URL="http://agentcube-router-addr:agentcube-router-port"其中workloadmanager-addr、workloadmanager-service-nodeport为workload-manager的访问地址和端口，agentcube-router-addr、agentcube-router-port为agentcube-router的访问地址和端口。▍步骤二：使用CodeInterpreterCodeInterpreter是AgentCube两大核心能力之一（另一个是AgentRuntime），是专为执行 LLM 生成的不可信代码而设计的受限运行时。通过收窄模板配置、内置 JWT 认证和预热池加速，在保障安全隔离的同时实现毫秒级启动，适用于代码解释器等沙箱执行场景。部署CodeInterpreter首先创建文件code-interpreter.yaml：apiVersion: runtime.agentcube.volcano.sh/v1alpha1kind: CodeInterpretermetadata:  name: my-codeinterpreter  namespace: defaultspec:  template:    # runtimeClassName: kata    # 若使用安全容器，则可配置runtimeClassName为kata或kuasar-vmm（需要有支持安全运行时的节点）    image: swr.ap-southeast-3.myhuaweicloud.com/container/picod:latest    # 使用 PicoD 镜像，当前示例使用的镜像仅支持执行shell和python代码    resources:      requests:        cpu: "100m"        memory: "128Mi"      limits:        cpu: "500m"        memory: "512Mi"  sessionTimeout: "15m"      # 空闲 15 分钟后超时  maxSessionDuration: "8h"   # 最大会话时长 8 小时  warmPoolSize: 5    # 预热 5 个 Pod执行部署：kubectl apply -f code-interpreter.yaml验证是否部署成功：kubectl get codeinterpreter部署完成后，等待一段时间执行kubectl get pods |grep my-codeinterpreter可以看到已经预热出了5个CodeInterpreter。远程执行第一份代码创建python脚本quickstart.py：import osfrom agentcube import CodeInterpreterClientWORKLOAD_MANAGER_URL = os.getenv('WORKLOAD_MANAGER_URL', 'http://workloadmanager.agentcube.svc.cluster.local:8080')ROUTER_URL = os.getenv('ROUTER_URL', 'http://agentcube-router.agentcube.svc.cluster.local:8080')with CodeInterpreterClient(name="my-codeinterpreter", namespace="default") as client:    result = client.run_code("python", "print('Hello from AgentCube!')")    print(result)上述python脚本会连接到上一步部署的CodeInterpreter，启动一个隔离的沙箱会话，向其发送一段待执行的 Python 代码片段，并打印输出结果。执行python quickstart.py开始运行，输出：2026-06-05 15:25:22,584 | INFO | agentcube.code_interpreter | Creating new session...2026-06-05 15:25:22,790 | INFO | agentcube.code_interpreter | Session created: 900923f4-4d1c-4383-ac6b-331c5ec83acbHello from AgentCube!2026-06-05 15:25:22,921 | INFO | agentcube.code_interpreter | Deleting session 900923f4-4d1c-4383-ac6b-331c5ec83acb...尝试在一个会话中连续执行代码在步骤三中，我们创建的 CodeInterpreter 仅运行了单次代码便自动结束了会话。但在真实的业务场景中，我们往往需要处理多轮连续交互。接下来，我们将通过一个更具实战价值的进阶示例，来展示 AgentCube 的会话保持能力。创建python脚本longtask.py：import osfrom agentcube import CodeInterpreterClientWORKLOAD_MANAGER_URL = os.getenv('WORKLOAD_MANAGER_URL', 'http://workloadmanager.agentcube.svc.cluster.local:8080')ROUTER_URL = os.getenv('ROUTER_URL', 'http://agentcube-router.agentcube.svc.cluster.local:8080')def session_reuse_workflow():    # 步骤 1：创建会话并写入数据    print("step 1: Create a session and write initial data.")    client1 = CodeInterpreterClient(        name='my-codeinterpreter',        namespace='default',        workload_manager_url=WORKLOAD_MANAGER_URL,        router_url=ROUTER_URL,    )    # 写入多个文件    client1.write_file("100", "counter.txt")    client1.write_file("[]", "results.json")    session_id = client1.session_id    print(f"session ID: {session_id}")    print("The file system status has been saved.\n")    # 注意：不调用 client1.stop()，让会话保持活跃    # 步骤 2：复用会话，读取并处理数据    print("step 2: Reusing sessions and processing data.")    client2 = CodeInterpreterClient(        name='my-codeinterpreter',        namespace='default',        workload_manager_url=WORKLOAD_MANAGER_URL,        router_url=ROUTER_URL,        session_id=session_id,  # 复用会话    )    code = """import jsonimport time# 读取计数器with open('counter.txt') as f:    counter = int(f.read().strip())print(f"current count: {counter}")# 增加计数counter += 1with open('counter.txt', 'w') as f:    f.write(str(counter))# 读取结果列表with open('results.json') as f:    results = json.load(f)# 添加新结果results.append({    'timestamp': time.time(),    'counter': counter})# 保存结果with open('results.json', 'w') as f:    json.dump(results, f, indent=2)print(f"new count: {counter}")print(f"result count: {len(results)}")"""    result = client2.run_code("python", code)    print(f"{result}\n")    # 步骤 3：查看文件系统状态    print("step 3: Verifying the File System Statuses")    files = client2.list_files(".")    print(f"Files in session: {[f['name'] for f in files]}\n")    # 清理会话    client2.stop()    print("session is deleted")if __name__ == "__main__":    session_reuse_workflow()上述python脚本首先创建了一个会话，往CodeInterpreter中上传了两个文件counter.txt和results.json。然后并不立即关闭会话，而是使用第一次创建会话时返回的session_id（会话ID）再次创建了一个客户端并远程执行代码。执行python longtask.py开始运行，输出如下：step 1: Create a session and write initial data.2026-06-05 15:45:03,386 | INFO | agentcube.code_interpreter | Creating new session...2026-06-05 15:45:03,775 | INFO | agentcube.code_interpreter | Session created: eda5f22f-ad7d-4d95-9adf-b74dbf015051session ID: eda5f22f-ad7d-4d95-9adf-b74dbf015051The file system status has been saved.step 2: Reusing sessions and processing data.2026-06-05 15:45:03,893 | INFO | agentcube.code_interpreter | Reusing existing session: eda5f22f-ad7d-4d95-9adf-b74dbf015051current count: 100new count: 101result count: 1step 3: Verifying the File System StatusesFiles in session: ['.bashrc', '.profile', 'counter.txt', 'picod', 'results.json', 'script_1780645503894.py']2026-06-05 15:45:04,072 | INFO | agentcube.code_interpreter | Deleting session eda5f22f-ad7d-4d95-9adf-b74dbf015051...session is deleted可以看到3轮请求的session_id是相同的，说明 AgentCube 识别到了请求所属中的会话ID，将所有请求都代理到了同一个CodeInterpreter实例而非创建新的。且第2、3轮请求能够读取到第1轮请求上传的文件，说明这个CodeInterpreter实例并没有被销毁和重建，它的整个运行时状态——包括文件系统、内存中的变量、进程上下文等，都在请求之间完整保留。这正是 CodeInterpreter 区别于无状态函数调用的核心优势。▍步骤三：使用AgentRuntime有别于 CodeInterpreter，AgentRuntime 支持完整的 PodSpec 自定义，适用于对话、工具调用等常规 Agent 场景。部署AgentRuntime创建agent.py、requirements.txt文件，其中agent.py文件内容为官方提供的Agent示例代码[9]，requirements.txt如下：agentcube_sdk使用如下Dockerfile制作Agent容器镜像，并将制作好的镜像上传华为云SWR。FROM python:3.11-slimWORKDIR /app# 复制依赖文件COPY requirements.txt .# 安装 Python 依赖RUN pip install --no-cache-dir -r requirements.txt# 复制应用代码COPY agent.py /app/# 暴露端口EXPOSE8080# 运行应用CMD ["python", "/app/agent.py"]创建文件agent-runtime.yaml：apiVersion: runtime.agentcube.volcano.sh/v1alpha1kind: AgentRuntimemetadata:  name: my-agent-app  namespace: defaultspec:  targetPort:    - pathPrefix: "/"      port: 8080      protocol: "HTTP"  podTemplate:    labels:      app: my-agent-app    spec:      schedulerName: default-scheduler    # 如果开启安装了volcano agent-scheduler调度器，可配置为agent-scheduler      containers:        - name: my-agent-app          image: {{agent image}}    # 构建好并上传华为云SWR的Agent容器镜像          env:            - name: WORKLOAD_MANAGER_URL              value: http://workloadmanager.agentcube.svc.cluster.local:8080            - name: ROUTER_URL              value: http://agentcube-router.agentcube.svc.cluster.local:8080            - name: CODEINTERPRETER_NAME              value: my-codeinterpreter            - name: CODEINTERPRETER_NAMESPACE              value: default          readinessProbe:            httpGet:              path: /health              port: 8080            periodSeconds: 5  sessionTimeout: "15m"             # 空闲 15 分钟后超时  maxSessionDuration: "8h"          # 最大会话时长 8 小时status: {}执行部署:kubectl apply -f agent-runtime.yaml验证是否部署成功:kubectl get agentruntime输出:NAME           AGEmy-agent-app   1m说明部署成功，my-agent-app为我们创建的Agent的名字。与Agent进行对话创建python脚本chatToAgent.py：from agentcube.agent_runtime import AgentRuntimeClientimport osimport timeROUTER_URL = os.getenv('ROUTER_URL', 'http://agentcube-router.agentcube.svc.cluster.local:8080')def test_conversation():    # 第一轮对话    agent_client1 = AgentRuntimeClient(        agent_name='my-agent-app',        namespace='default',        router_url=ROUTER_URL,        timeout=500,        connect_timeout=120.0    )    # 记录会话ID，后续对话复用    session_id = agent_client1.session_id    result = agent_client1.invoke(        payload={"prompt": "Introduce yourself"},    )    print(f"response: {result}\n")    time.sleep(1)    # 第二轮对话    agent_client2 = AgentRuntimeClient(        agent_name='my-agent-app',        namespace='default',        router_url=ROUTER_URL,        timeout=500,        connect_timeout=120.0,        session_id=session_id    )    result = agent_client2.invoke(        payload={"prompt": "What can you do?"},    )    print(f"response: {result}\n")    time.sleep(1)    # 第三轮对话    agent_client3 = AgentRuntimeClient(        agent_name='my-agent-app',        namespace='default',        router_url=ROUTER_URL,        timeout=500,        connect_timeout=120.0,        session_id=session_id    )    result = agent_client3.invoke(        payload={"prompt": "Write a Python function for me"},    )    print(f"response: {result}\n")if __name__ == "__main__":    test_conversation()上述python脚本首先创建了一个对话，对话的对象是上一步创建的my-agent-appAgent应用，然后连续发起3次对话。输出如下：2026-06-05 16:33:28,396 | INFO | agentcube.agent_runtime | Bootstrapping AgentRuntime session...2026-06-05 16:33:29,771 | INFO | agentcube.agent_runtime | AgentRuntime session created: cdb9f642-fcfd-4d96-b024-c49b8fc4baf3response: {'response': 'Hello Agent received: Introduce yourself', 'agent': 'hello-agent', 'timestamp': '2026-06-05T08:33:29.839193', 'original_prompt': 'Introduce yourself'}2026-06-05 16:33:30,812 | INFO | agentcube.agent_runtime | Reusing AgentRuntime session: cdb9f642-fcfd-4d96-b024-c49b8fc4baf3response: {'response': 'Hello Agent received: What can you do?', 'agent': 'hello-agent', 'timestamp': '2026-06-05T08:33:30.912573', 'original_prompt': 'What can you do?'}2026-06-05 16:33:31,886 | INFO | agentcube.agent_runtime | Reusing AgentRuntime session: cdb9f642-fcfd-4d96-b024-c49b8fc4baf3response: {'response': 'Hello Agent received: Write a Python function for me', 'agent': 'hello-agent', 'timestamp': '2026-06-05T08:33:31.989551', 'original_prompt': 'Write a Python function for me'}可以看到3次对话的session_id是相同的，说明 AgentCube 识别到了请求所属中的会话ID，将所有请求都代理到了同一个AgentRuntime实例。  总 结  AgentCube 以极速启动、高效调度、原生会话管理、安全隔离四大核心能力，补齐了 K8s 集群承载 AI Agent 工作负载的短板。华为云 CCE 将持续集成 AgentCube ，为用户打造低延迟、高吞吐、强隔离的高性能 AI Agent 运行底座。 相关链接[1] AgentCube GitHub仓库: cid:link_7[2] Volcano官网: https://volcano.sh[3] AgentCube设计文档: cid:link_3[4] Kubernetes 跑 AI Agent，缺的不只是算力——AgentCube 补上了什么: cid:link_6[5] Python SDK: cid:link_4[6] 华为云CCE控制台: cid:link_1[7] AgentSandbox: cid:link_5[8] 华为云分布式缓存服务 DCS: cid:link_2[9] Agent示例代码: cid:link_0 关注魔方公众号，获取更多前沿资讯添加社区小助手k8s2222，进入技术交流群

随着大模型技术的飞速发展，AI Agent 正从概念走向生产。与传统的批处理任务或推理服务不同，Agent 工作负载呈现出独特的运行特征——间歇性活跃、极低延迟敏感、多轮会话状态持久化。然而，现有的 Kubernetes 调度体系主要面向批处理和长运行服务设计，难以有效应对这类"潮汐式"交互负载：空闲时资源白白占用，唤醒时又无法做到亚秒级响应，状态管理更是一大痛点。AgentCube[1] 正是为解决这一矛盾而生。作为 Volcano社区[2]的子项目，AgentCube 专为 AI Agent 工作负载打造了专用的控制面与数据面，核心优势体现在四个方面： 极速启动—— 通过 Warm Pool （预热池）机制预先创建并暂停一批沙箱，当 Agent 请求到来时以 "Claim-and-Go" 的方式进行毫秒级分配，消除冷启动瓶颈。高效调度 —— 借助 Volcano Agent Scheduler 的乐观并发控制与精简调度策略，大幅提升调度吞吐，并能与 Volcano 原有的 Batch Scheduler 无缝协作，确保 Agent 与传统批处理作业的统一调度与资源协调。原生会话管理 —— 以 Session ID 为核心路由标识，会话到来时自动识别并路由请求至对应沙箱，并在沙箱休眠时自动唤醒，保障多轮交互的上下文连续性。安全隔离 —— 为每个会话分配独立沙箱，确保计算、内存与文件系统的端到端隔离，防止跨租户数据泄露。同时支持以安全容器运行 Agent，借助安全运行时技术实现内核级强隔离。本文将聚焦 AgentCube 在华为云 CCE（云容器引擎）上的实践，探讨如何将 AgentCube 的调度能力与 CCE 的基础设施深度结合，为 AI Agent 应用提供高效、稳定的云原生运行底座。关于AgentCube的原理可通过设计文档[3]或往期文章[4]了解。  环境准备  已经创建好了一个1.29或更高版本的CCE集群确保本地安装的python版本>=3.11安装SDK[5] ： pip install agentcube_sdk  安装 AgentCube 插件  AgentCube目前已上架华为云 CCE 插件市场。可通过登录CCE控制台[6]进入集群插件中心界面，找到AgentCube插件进行配置安装。 AgentCube主要组件： workloadmanager：管理AgentRuntime和CodeInterpreter的生命周期。agentcube-router：API 网关，代理客户端请求到沙箱实例。volcano-agent-scheduler：调度器组件，提供低延迟和高吞吐的负责调度。agent-sandbox-controller：管理AgentSandbox资源。安装时需要设置如下参数：redis.addr：Redis的地址，必须配置。redis.password：Redis的密码，必须配置。agentSandbox.install：是否自动安装agent-sandbox。AgentCube插件运行时依赖 agent-sandbox[7]，当参数配置为true时会自动安装。如果集群已手动安装了agent-sandbox，则可配置为false跳过安装。agentSandbox.extensions：是否启用agent-sandbox的extension controller。volcano.scheduler.enabled：是否安装volcano agent-scheduler调度器。由于AgentCube运行时依赖Redis维护会话状态和索引，从稳定性和可扩展性考虑，建议购买和使用华为云分布式缓存服务 DCS[8]。此外，如果要在集群外访问 AgentCube，可为workloadmanager和agentcube-router的Service绑定ELB Ingress。  开始使用  ▍步骤一：环境变量设置export WORKLOAD_MANAGER_URL="http://workloadmanager-addr:workloadmanager-port" export ROUTER_URL="http://agentcube-router-addr:agentcube-router-port"其中workloadmanager-addr、workloadmanager-service-nodeport为workload-manager的访问地址和端口，agentcube-router-addr、agentcube-router-port为agentcube-router的访问地址和端口。▍步骤二：使用CodeInterpreterCodeInterpreter是AgentCube两大核心能力之一（另一个是AgentRuntime），是专为执行 LLM 生成的不可信代码而设计的受限运行时。通过收窄模板配置、内置 JWT 认证和预热池加速，在保障安全隔离的同时实现毫秒级启动，适用于代码解释器等沙箱执行场景。部署CodeInterpreter首先创建文件code-interpreter.yaml：apiVersion: runtime.agentcube.volcano.sh/v1alpha1kind: CodeInterpretermetadata:  name: my-codeinterpreter  namespace: defaultspec:  template:    # runtimeClassName: kata    # 若使用安全容器，则可配置runtimeClassName为kata或kuasar-vmm（需要有支持安全运行时的节点）    image: swr.ap-southeast-3.myhuaweicloud.com/container/picod:latest    # 使用 PicoD 镜像，当前示例使用的镜像仅支持执行shell和python代码    resources:      requests:        cpu: "100m"        memory: "128Mi"      limits:        cpu: "500m"        memory: "512Mi"  sessionTimeout: "15m"      # 空闲 15 分钟后超时  maxSessionDuration: "8h"   # 最大会话时长 8 小时  warmPoolSize: 5    # 预热 5 个 Pod执行部署：kubectl apply -f code-interpreter.yaml验证是否部署成功：kubectl get codeinterpreter部署完成后，等待一段时间执行kubectl get pods |grep my-codeinterpreter可以看到已经预热出了5个CodeInterpreter。远程执行第一份代码创建python脚本quickstart.py：import osfrom agentcube import CodeInterpreterClientWORKLOAD_MANAGER_URL = os.getenv('WORKLOAD_MANAGER_URL', 'http://workloadmanager.agentcube.svc.cluster.local:8080')ROUTER_URL = os.getenv('ROUTER_URL', 'http://agentcube-router.agentcube.svc.cluster.local:8080')with CodeInterpreterClient(name="my-codeinterpreter", namespace="default") as client:    result = client.run_code("python", "print('Hello from AgentCube!')")    print(result)上述python脚本会连接到上一步部署的CodeInterpreter，启动一个隔离的沙箱会话，向其发送一段待执行的 Python 代码片段，并打印输出结果。执行python quickstart.py开始运行，输出：2026-06-05 15:25:22,584 | INFO | agentcube.code_interpreter | Creating new session...2026-06-05 15:25:22,790 | INFO | agentcube.code_interpreter | Session created: 900923f4-4d1c-4383-ac6b-331c5ec83acbHello from AgentCube!2026-06-05 15:25:22,921 | INFO | agentcube.code_interpreter | Deleting session 900923f4-4d1c-4383-ac6b-331c5ec83acb...尝试在一个会话中连续执行代码在步骤三中，我们创建的 CodeInterpreter 仅运行了单次代码便自动结束了会话。但在真实的业务场景中，我们往往需要处理多轮连续交互。接下来，我们将通过一个更具实战价值的进阶示例，来展示 AgentCube 的会话保持能力。创建python脚本longtask.py：import osfrom agentcube import CodeInterpreterClientWORKLOAD_MANAGER_URL = os.getenv('WORKLOAD_MANAGER_URL', 'http://workloadmanager.agentcube.svc.cluster.local:8080')ROUTER_URL = os.getenv('ROUTER_URL', 'http://agentcube-router.agentcube.svc.cluster.local:8080')def session_reuse_workflow():    # 步骤 1：创建会话并写入数据    print("step 1: Create a session and write initial data.")    client1 = CodeInterpreterClient(        name='my-codeinterpreter',        namespace='default',        workload_manager_url=WORKLOAD_MANAGER_URL,        router_url=ROUTER_URL,    )    # 写入多个文件    client1.write_file("100", "counter.txt")    client1.write_file("[]", "results.json")    session_id = client1.session_id    print(f"session ID: {session_id}")    print("The file system status has been saved.\n")    # 注意：不调用 client1.stop()，让会话保持活跃    # 步骤 2：复用会话，读取并处理数据    print("step 2: Reusing sessions and processing data.")    client2 = CodeInterpreterClient(        name='my-codeinterpreter',        namespace='default',        workload_manager_url=WORKLOAD_MANAGER_URL,        router_url=ROUTER_URL,        session_id=session_id,  # 复用会话    )    code = """import jsonimport time# 读取计数器with open('counter.txt') as f:    counter = int(f.read().strip())print(f"current count: {counter}")# 增加计数counter += 1with open('counter.txt', 'w') as f:    f.write(str(counter))# 读取结果列表with open('results.json') as f:    results = json.load(f)# 添加新结果results.append({    'timestamp': time.time(),    'counter': counter})# 保存结果with open('results.json', 'w') as f:    json.dump(results, f, indent=2)print(f"new count: {counter}")print(f"result count: {len(results)}")"""    result = client2.run_code("python", code)    print(f"{result}\n")    # 步骤 3：查看文件系统状态    print("step 3: Verifying the File System Statuses")    files = client2.list_files(".")    print(f"Files in session: {[f['name'] for f in files]}\n")    # 清理会话    client2.stop()    print("session is deleted")if __name__ == "__main__":    session_reuse_workflow()上述python脚本首先创建了一个会话，往CodeInterpreter中上传了两个文件counter.txt和results.json。然后并不立即关闭会话，而是使用第一次创建会话时返回的session_id（会话ID）再次创建了一个客户端并远程执行代码。执行python longtask.py开始运行，输出如下：step 1: Create a session and write initial data.2026-06-05 15:45:03,386 | INFO | agentcube.code_interpreter | Creating new session...2026-06-05 15:45:03,775 | INFO | agentcube.code_interpreter | Session created: eda5f22f-ad7d-4d95-9adf-b74dbf015051session ID: eda5f22f-ad7d-4d95-9adf-b74dbf015051The file system status has been saved.step 2: Reusing sessions and processing data.2026-06-05 15:45:03,893 | INFO | agentcube.code_interpreter | Reusing existing session: eda5f22f-ad7d-4d95-9adf-b74dbf015051current count: 100new count: 101result count: 1step 3: Verifying the File System StatusesFiles in session: ['.bashrc', '.profile', 'counter.txt', 'picod', 'results.json', 'script_1780645503894.py']2026-06-05 15:45:04,072 | INFO | agentcube.code_interpreter | Deleting session eda5f22f-ad7d-4d95-9adf-b74dbf015051...session is deleted可以看到3轮请求的session_id是相同的，说明 AgentCube 识别到了请求所属中的会话ID，将所有请求都代理到了同一个CodeInterpreter实例而非创建新的。且第2、3轮请求能够读取到第1轮请求上传的文件，说明这个CodeInterpreter实例并没有被销毁和重建，它的整个运行时状态——包括文件系统、内存中的变量、进程上下文等，都在请求之间完整保留。这正是 CodeInterpreter 区别于无状态函数调用的核心优势。▍步骤三：使用AgentRuntime有别于 CodeInterpreter，AgentRuntime 支持完整的 PodSpec 自定义，适用于对话、工具调用等常规 Agent 场景。部署AgentRuntime创建agent.py、requirements.txt文件，其中agent.py文件内容为官方提供的Agent示例代码[9]，requirements.txt如下：agentcube_sdk使用如下Dockerfile制作Agent容器镜像，并将制作好的镜像上传华为云SWR。FROM python:3.11-slimWORKDIR /app# 复制依赖文件COPY requirements.txt .# 安装 Python 依赖RUN pip install --no-cache-dir -r requirements.txt# 复制应用代码COPY agent.py /app/# 暴露端口EXPOSE8080# 运行应用CMD ["python", "/app/agent.py"]创建文件agent-runtime.yaml：apiVersion: runtime.agentcube.volcano.sh/v1alpha1kind: AgentRuntimemetadata:  name: my-agent-app  namespace: defaultspec:  targetPort:    - pathPrefix: "/"      port: 8080      protocol: "HTTP"  podTemplate:    labels:      app: my-agent-app    spec:      schedulerName: default-scheduler    # 如果开启安装了volcano agent-scheduler调度器，可配置为agent-scheduler      containers:        - name: my-agent-app          image: {{agent image}}    # 构建好并上传华为云SWR的Agent容器镜像          env:            - name: WORKLOAD_MANAGER_URL              value: http://workloadmanager.agentcube.svc.cluster.local:8080            - name: ROUTER_URL              value: http://agentcube-router.agentcube.svc.cluster.local:8080            - name: CODEINTERPRETER_NAME              value: my-codeinterpreter            - name: CODEINTERPRETER_NAMESPACE              value: default          readinessProbe:            httpGet:              path: /health              port: 8080            periodSeconds: 5  sessionTimeout: "15m"             # 空闲 15 分钟后超时  maxSessionDuration: "8h"          # 最大会话时长 8 小时status: {}执行部署:kubectl apply -f agent-runtime.yaml验证是否部署成功:kubectl get agentruntime输出:NAME           AGEmy-agent-app   1m说明部署成功，my-agent-app为我们创建的Agent的名字。与Agent进行对话创建python脚本chatToAgent.py：from agentcube.agent_runtime import AgentRuntimeClientimport osimport timeROUTER_URL = os.getenv('ROUTER_URL', 'http://agentcube-router.agentcube.svc.cluster.local:8080')def test_conversation():    # 第一轮对话    agent_client1 = AgentRuntimeClient(        agent_name='my-agent-app',        namespace='default',        router_url=ROUTER_URL,        timeout=500,        connect_timeout=120.0    )    # 记录会话ID，后续对话复用    session_id = agent_client1.session_id    result = agent_client1.invoke(        payload={"prompt": "Introduce yourself"},    )    print(f"response: {result}\n")    time.sleep(1)    # 第二轮对话    agent_client2 = AgentRuntimeClient(        agent_name='my-agent-app',        namespace='default',        router_url=ROUTER_URL,        timeout=500,        connect_timeout=120.0,        session_id=session_id    )    result = agent_client2.invoke(        payload={"prompt": "What can you do?"},    )    print(f"response: {result}\n")    time.sleep(1)    # 第三轮对话    agent_client3 = AgentRuntimeClient(        agent_name='my-agent-app',        namespace='default',        router_url=ROUTER_URL,        timeout=500,        connect_timeout=120.0,        session_id=session_id    )    result = agent_client3.invoke(        payload={"prompt": "Write a Python function for me"},    )    print(f"response: {result}\n")if __name__ == "__main__":    test_conversation()上述python脚本首先创建了一个对话，对话的对象是上一步创建的my-agent-appAgent应用，然后连续发起3次对话。输出如下：2026-06-05 16:33:28,396 | INFO | agentcube.agent_runtime | Bootstrapping AgentRuntime session...2026-06-05 16:33:29,771 | INFO | agentcube.agent_runtime | AgentRuntime session created: cdb9f642-fcfd-4d96-b024-c49b8fc4baf3response: {'response': 'Hello Agent received: Introduce yourself', 'agent': 'hello-agent', 'timestamp': '2026-06-05T08:33:29.839193', 'original_prompt': 'Introduce yourself'}2026-06-05 16:33:30,812 | INFO | agentcube.agent_runtime | Reusing AgentRuntime session: cdb9f642-fcfd-4d96-b024-c49b8fc4baf3response: {'response': 'Hello Agent received: What can you do?', 'agent': 'hello-agent', 'timestamp': '2026-06-05T08:33:30.912573', 'original_prompt': 'What can you do?'}2026-06-05 16:33:31,886 | INFO | agentcube.agent_runtime | Reusing AgentRuntime session: cdb9f642-fcfd-4d96-b024-c49b8fc4baf3response: {'response': 'Hello Agent received: Write a Python function for me', 'agent': 'hello-agent', 'timestamp': '2026-06-05T08:33:31.989551', 'original_prompt': 'Write a Python function for me'}可以看到3次对话的session_id是相同的，说明 AgentCube 识别到了请求所属中的会话ID，将所有请求都代理到了同一个AgentRuntime实例。  总 结  AgentCube 以极速启动、高效调度、原生会话管理、安全隔离四大核心能力，补齐了 K8s 集群承载 AI Agent 工作负载的短板。华为云 CCE 将持续集成 AgentCube ，为用户打造低延迟、高吞吐、强隔离的高性能 AI Agent 运行底座。 相关链接[1] AgentCube GitHub仓库: cid:link_7[2] Volcano官网: https://volcano.sh[3] AgentCube设计文档: cid:link_3[4] Kubernetes 跑 AI Agent，缺的不只是算力——AgentCube 补上了什么: cid:link_6[5] Python SDK: cid:link_4[6] 华为云CCE控制台: cid:link_1[7] AgentSandbox: cid:link_5[8] 华为云分布式缓存服务 DCS: cid:link_2[9] Agent示例代码: cid:link_0 关注魔方公众号，获取更多前沿资讯添加社区小助手k8s2222，进入技术交流群

随着批量训练、推理、AI Agent、HPC、大数据等多种负载在同一Kubernetes集群中混合部署，调度器需要在资源竞争更加激烈的环境下做出更高质量的决策，同时保持作业级语义、队列公平性、拓扑亲和性与运行稳定性。Volcano v1.15.0 现已正式发布，围绕这些方向，在调度核心、异构资源管理、多调度器协同与性能可观测等方面进行了增强。本次最值得关注的新增能力是 Gang-Aware Preemption and Resource Reclamation：抢占决策在抢占方与被抢占方两侧均以Gang为整体进行评估——抢占方按Gang整体进行放置，被抢占候选者同样按Gang粒度进行排序和评估，优先驱逐冗余副本，避免逐Pod随机驱逐打断多个训练任务而抢占方自身仍无法启动的情况。此外，v1.15.0在capacity插件中引入了DRA队列配额，新增了可插拔的多分片策略框架以及Benchmark与性能可观测工具，支持Kubernetes 1.35，并在NodeGroup调度优先级、Agent Scheduler稳定性、GPU/vGPU及队列准入控制等方面做了补充增强。Release Note: cid:link_11  Volcano v1.15.0 版本亮点  本次发布主要围绕以下方向展开：Gang-Aware Preemption and Resource Reclamation：以Job/Gang为粒度组织被抢占候选，区分冗余副本与关键副本，优先驱逐冗余副本减少任务扰动，并在驱逐前模拟整体放置确认抢占方能成功启动，避免逐Pod抢占打断多个训练任务而抢占方自己也无法运行的情况。DRA Queue Quota：capacity插件将DRA ResourceClaim纳入Volcano现有的队列容量模型，让DRA设备资源也能通过队列配额管理。Pluggable Multi-Sharding Policy：Sharding Controller支持通过ConfigMap组合多种分片策略，并支持运行时热加载。Volcano Benchmark框架：提供一键化性能测试环境搭建和报告输出，支持Kind/KWOK及已有集群。Scheduling Gates for Queue Admission：区分"队列配额不足"和"集群资源不足"，避免autoscaler因队列限额触发不必要的扩容。此外，v1.15.0还包含Kubernetes 1.35支持、NodeGroup preferred ordering、Agent Scheduler稳定性增强、GPU/vGPU增量增强以及安全修复。它们会在后文简要介绍，对生产可用性和生态兼容性同样重要。  重点特性  ▍1. Gang-Aware Preemption and Resource Reclamation（Alpha）在大模型训练、HPC等分布式任务中，一个Job往往需要多个Pod同时运行才有意义。如果抢占只按单个Pod进行决策，就可能从多个正在运行的训练任务里各抢一个Pod——表面上释放了资源，实际上既把多个任务都打断了，发起抢占的Gang也未必能凑齐minAvailable成功启动。v1.15.0引入Gang-Aware Preemption and Resource Reclamation，让抢占方和被抢占方在决策时都以Gang为整体来考量，避免出现"释放了一堆Pod，但谁都没跑起来"的情况。在被抢占方一侧，Volcano以Job/Gang为粒度组织被抢占候选，而不是把所有Pod看成可互换的抢占对象。每个候选Job的Pod被区分为冗余副本（超出minAvailable的部分）和关键副本，调度器优先选择冗余副本——驱逐它们不会打断任务——尽量避免触碰关键副本。这与原有action逐Pod选择、不区分破坏代价的方式有本质区别。在抢占方一侧，调度器逐步累计可释放的资源，当累计量足以覆盖抢占方Gang的整体需求时，先做放置模拟——在释放后的资源视图上验证抢占方Gang能否整体调度成功——只有模拟通过才真正执行驱逐。这样不会出现"抢了一堆Pod结果抢占方还是起不来"的情况。不论是否启用HyperNode拓扑，这套机制都能减少随机抢占带来的任务扰动。启用HyperNode拓扑后，Volcano还会将victim搜索限定在选定的拓扑范围内，避免跨拓扑域抢占。该特性目前为Alpha，需要显式配置gangPreempt和gangReclaim两个新的action。后续版本会继续评估是否将Gang-Aware驱逐机制与原有preempt、reclaim action合并。配置示例：actions: "enqueue, allocate, backfill, gangPreempt, gangReclaim"tiers:- plugins:  - name: priority  - name: gang  - name: drf  - name: predicates  - name: nodeorder - name: binpack相关资料：相关PR：cid:link_13,  cid:link_14,  cid:link_15设计文档：Gang-Aware Eviction Design:cid:link_5设计文档：EvictableFn Evolution for Gang Eviction:cid:link_2感谢社区开发者：@vzhou-p▍2. DRA Queue QuotaKubernetes Dynamic Resource Allocation（DRA）为设备资源申请提供了更灵活的模型。此前版本的Volcano已经支持调度使用DRA资源的Pod，但队列quota尚未覆盖DRA ResourceClaim。v1.15.0在capacity插件中补齐了这一能力，将DRA资源纳入Volcano已有的队列配额体系。用户仍然可以使用capability、deserved、guarantee容量模型管理队列资源，无需为DRA单独维护一套quota API。目前支持两类资源管控：基于DeviceClass的整卡/整设备数量配额基于可消费设备维度的配额，如虚拟GPU core、显存等当多个Pod引用同一个共享ResourceClaim时，Volcano会自动去重，避免同一份资源被重复计入队列用量。这样，集群管理员可以用同一套队列容量模型统一管理CPU、内存、扩展资源以及DRA设备资源。配置示例：tiers:- plugins:  - name: capacity    arguments:      capacity.DynamicResourceAllocationEnable: true      capacity.DRAConsumableCapacityEnable: trueapiVersion: scheduling.volcano.sh/v1beta1kind: Queuemetadata:  name: ml-teamspec:  capability:    cpu: "100"    memory: "200Gi"    "deviceclass/gpu.nvidia.com": "8"    "cores.deviceclass/hami-core-gpu.project-hami.io": "800"    "memory.deviceclass/hami-core-gpu.project-hami.io": "320Gi"相关资料：相关PR：cid:link_16设计文档：DeviceClass Quota Support in Capacity Plugin:cid:link_7使用文档：DeviceClass Quota User Guide:cid:link_6感谢社区开发者：@xu-wentao▍3. Pluggable Multi-Sharding Policy（Alpha）在多调度器架构下，不同调度器通常面向不同类型的工作负载，对候选节点的范围也有不同要求。v1.15.0对Sharding Controller进行了增强，支持以可插拔的策略流水线组合多种分片逻辑。每个scheduler shard可以配置一组有序的策略，覆盖filter、score、select等阶段。内置策略包括：allocation-rate：根据节点资源利用率进行过滤和打分warmup：优先处理warmup节点node-limit：限制每个shard的节点数量范围策略通过ConfigMap配置，支持运行时热加载。如果新配置校验失败，系统会沿用上一份有效配置，避免线上变更引入风险。这让多调度器的节点分片能够更灵活地适配不同集群规模和业务类型，也为后续扩展更多sharding policy提供了清晰的接口。配置示例：custom:  sharding_configmap_enable: true  sharding_configmap_data: |    schedulerConfigs:      - name: volcano        type: volcano        policies:          - name: allocation-rate            weight: 1            arguments:              minCPUUtil: 0.0              maxCPUUtil: 0.6          - name: node-limit            arguments:              minNodes: 1              maxNodes: 100      - name: agent-scheduler        type: agent        policies:          - name: allocation-rate            weight: 1            arguments:              minCPUUtil: 0.7              maxCPUUtil: 1.0          - name: warmup            weight: 2相关资料：相关PR：cid:link_17, cid:link_18, cid:link_19使用文档：How to Configure Sharding via ConfigMap: cid:link_3感谢社区开发者：@lixmgl, @agrawalcodes▍4. Volcano Benchmark框架调度器的性能优化离不开稳定、可复现的测试基线。v1.15.0新增了Benchmark框架，支持一键部署测试环境、运行标准场景并输出性能报告。该框架支持两类环境：本地Kind + KWOK环境，用于开发者快速复现和分析调度性能问题已有Kubernetes集群，用于用户在真实环境中评估Volcano的调度吞吐和延迟测试场景覆盖VolcanoJob Gang调度、普通Pod调度、KWOK拓扑标签、HyperNode生成等，配合scheduler/controller metrics、audit-exporter报告和Grafana dashboard，可以帮助快速定位调度性能瓶颈。对于新接触Volcano的用户，也可以借助该框架在自己的集群中运行一轮测试，快速了解实际的调度吞吐和延迟表现。使用示例：cd benchmarkmake setup VOLCANO_VERSION=v1.15.0make test-gang-env JOBS=10 REPLICAS=100 MIN_AVAILABLE=100make cleanup-all相关资料：相关PR：cid:link_20, cid:link_21, cid:link_22,  cid:link_23使用文档：Benchmark README:cid:link_9感谢社区开发者：@JesseStutler, @3th4novo▍5. Scheduling Gates for Queue Admission（Alpha）当Pod因为队列容量不足而无法调度时，Cluster Autoscaler或Karpenter可能将这些Pod误判为集群资源不足，从而触发不必要的扩容。v1.15.0引入Scheduling Gates for Queue Admission。用户通过annotation为Pod开启后，当队列容量不足时，Volcano会通过Kubernetes原生的schedulingGates机制阻止Pod进入调度，使其对autoscaler不可见，从而不会触发扩容。等队列释放出容量后，Volcano再移除gate，Pod恢复正常调度流程。这样可以有效区分"队列配额不足"和"集群资源不足"两种情况，避免因队列quota限制导致的无效扩容。该特性目前为Alpha，需要同时在scheduler和webhook-manager中开启SchedulingGatesQueueAdmission。配置示例：helm install volcano volcano/volcano --namespace volcano-system --create-namespace \  --set custom.scheduler_feature_gates="SchedulingGatesQueueAdmission=true" \  --set custom.admission_feature_gates="SchedulingGatesQueueAdmission=true"apiVersion: v1kind: Podmetadata:  name: queue-gated-pod  annotations:    scheduling.volcano.sh/queue-allocation-gate: "true"spec:  schedulerName: volcano  containers:  - name: worker    image: nginx相关资料：相关Issue：cid:link_12相关PR：cid:link_25/pull/5033,cid:link_24设计文档：Gate-Controlled Scheduling for Cluster Autoscalers Compatibility: cid:link_4使用文档：How to Use Scheduling Gates for Queue Admission: cid:link_1感谢社区开发者：@devzizu  其他值得关注的增强  ▍Kubernetes 1.35支持v1.15.0更新了Kubernetes依赖、生成代码、fake client、informer、volumebinding集成、CI/lint工具链以及兼容性文档，支持Kubernetes 1.35。▍NodeGroup preferred orderingNodeGroup plugin新增enablePreferredOrder，Queue中preferredDuringSchedulingIgnoredDuringExecution的顺序会影响调度打分。靠前的NodeGroup会获得更高分数，适合“优先使用固定资源池，资源不足时再fallback到弹性资源池”的场景。配置示例：tiers:- plugins:  - name: nodegroup    arguments:      enablePreferredOrder: trueapiVersion: scheduling.volcano.sh/v1beta1kind: Queuemetadata:  name: bigdataspec:  affinity:    nodeGroupAffinity:      preferredDuringSchedulingIgnoredDuringExecution:      - spark-fixed      - spark-serverless相关配置可参考：cid:link_0▍Agent Scheduler稳定性增强v1.15.0修复了Agent Scheduler多worker乐观并发冲突、共享action实例复用framework/cycle state、CSI manager注册缺失、binder节点优先级处理以及E2E duration metric等问题，并补充了相关E2E覆盖。这些修复主要提升了延迟敏感型AI Agent工作负载的调度稳定性。▍GPU/vGPU增量增强v1.15.0对deviceshare plugin做了多项增强，包括GPU exclusive支持、vGPU preemption支持，以及在不允许共享时避免同一PodGroup内的Pod使用同一张物理vGPU设备。▍安全修复v1.15.0包含webhook request body size mitigation，用于修复CVE-2026-44247相关的拒绝服务风险。该修复限制admission webhook请求体大小，避免超大请求导致webhook server内存耗尽。  总 结  Volcano v1.15.0的核心变化是Gang-Aware Preemption and Resource Reclamation，将抢占决策从逐Pod粒度提升到Gang粒度，在抢占方与被抢占方两侧同时进行整体性评估，减少分布式训练场景下因随机驱逐导致的连锁任务失败。DRA Queue Quota将DRA设备资源纳入已有的队列容量模型，使异构资源与CPU、内存在配额管理上保持一致。Pluggable Multi-Sharding Policy、Benchmark框架与Agent Scheduler稳定性修复，则分别完善了多调度器协同、性能基线建立与延迟敏感负载调度方面的工程能力。Volcano将继续面向AI训练、推理、Agent、HPC与大数据等混合部署场景，持续完善统一调度平台的调度能力与工程质量。  升级注意事项 可以通过Helm或YAML方式升级到v1.15.0：helm repo updatehelm upgrade volcano volcano-sh/volcano --version 1.15.0kubectl apply -f https://raw.githubusercontent.com/volcano-sh/volcano/v1.15.0/installer/volcano-development.yaml当前Gang-Aware Preemption and Resource Reclamation特性为Alpha阶段，需要显式配置gangPreempt和gangReclaim两个新的action。当前不推荐在同一个scheduler action list中同时配置新的gangPreempt/gangReclaim和旧的preempt/reclaim action。Scheduling Gates for Queue Admission为Alpha，需要同时在scheduler和webhook-manager中开启。DRA scheduling integration默认开启，以对齐Kubernetes 1.34+的DRA默认行为。如需关闭，可设置predicate.DynamicResourceAllocationEnable: false。DRA Queue Quota依赖Kubernetes DRA支持和可用的DRA driver。  参考链接  本文重点介绍v1.15.0的主要能力。完整的API Changes、Bug Fixes、依赖更新、测试与维护项和贡献者列表，请参考正式Release Note及相关文档。Release Note: cid:link_11Full Changelog: cid:link_10  致 谢  Volcano v1.15共有43位社区贡献者参与。衷心感谢每一位贡献者，是你们的努力让Volcano不断进步，成为更强大、更稳定的统一调度平台！  🌋 Volcano 是 CNCF 首个批量计算项目，也是业界领先的云原生统一调度平台。Volcano 已从批量调度引擎演进为通智融合调度系统，面向 AI 训练、大模型推理、Agentic AI、大数据、基因测序等多样化工作负载提供统一的高性能调度能力，对 Spark、Flink、Ray、TensorFlow、PyTorch、Kubeflow、MPI、PaddlePaddle、MindSpore 等主流计算框架均有完善支持。社区在GitHub上已获得 6.6k+ Star 和 1.3K+ Fork，参与贡献企业包括华为、AWS、百度、腾讯、京东、小红书、bilibili 等。欢迎参与社区贡献：Volcano官网： https://volcano.sh GitHub: cid:link_25 每周例会：https://zoom.us/j/91804791393关注魔方公众号，获取更多前沿资讯添加社区小助手k8s2222，进入技术交流群

由Linux Foundation组织的LFX Mentorship计划[1]，从2019年开始为CNCF各个开源社区中的开发人员持续提供带薪实习和指导。该项目往年已获2w+申请，发起2000+课题，毕业实习生1400+，发放超过380万美金报酬。LFX Mentorship 2026 夏季(Term 2）申请时间为5月5日 – 5月19日（11:00 PDT；18:00 UTC)，远程实习将从 6 月 8 日开始为期三个月。参与到LFX Mentorship计划中，为开源项目做贡献、获得开源社区的认可同时，完成工作还能获取报酬 (位于中国的开发者报酬为3000美金，约合20000人民币）。Volcano社区在LFX Mentorship计划的课题申请正在火热进行中，感兴趣的开发者即日起可前往官方平台申请（在校/在职符合条件可）:https://mentorship.lfx.linuxfoundation.org/  Volcano 社区介绍  Volcano 是 CNCF 首个批量计算项目，也是业界领先的云原生统一调度平台。Volcano 已从批量调度引擎演进为通智融合调度系统，面向 AI 训练、大模型推理、Agentic AI、大数据、基因测序等多样化工作负载提供统一的高性能调度能力，对 Spark、Flink、Ray、TensorFlow、PyTorch、Kubeflow、MPI、PaddlePaddle、MindSpore 等主流计算框架均有完善支持。社区在GitHub上已获得 6.5k+ Star 和 1.3K+ Fork，参与贡献企业包括华为、AWS、百度、腾讯、京东、小红书、bilibili 等。社区地址：🌋 https://github.com/volcano-sh在LFX Mentorship 2026夏季计划，Volcano期待与你协作开拓AI大数据、LLM大模型推理等场景调度的更多可能。  面 向 对 象 本期计划申请者需2026年5月19日前在LFX官网[1]完成Mentee注册及项目申请。若被接收作为Mentee，您将能在开源社区经验丰富、积极贡献的Mentor指导下为开源项目做出贡献。依据官方规定，对Mentee申请者有以下要求[2]:在参加该计划时您至少年满18周岁所在单位和组织不禁止该实习未参加另外的Linux Mentorship计划开发者以个人身份参与（在校或已毕业均可）具备所注册国家中工作权利且所注册国家未被计划禁止 (中国已获许可)满足具体所属项目中提及的其它前置需求  课题参与方式  根据官方安排 [3]，LFX Mentorship 2026 年 Term2 申请及实习流程如下：Mentee注册与项目申请：5月5日-5月19日（11:00 AM PDT/18:00 UTC)申请者审核期： 5月20日-6月2日（11:00 AM PDT/18:00 UTC)申请者入选通知：6月3日实习正式开始：6月8日中期考核：7月21日（11:00 AM PDT/18:00 UTC)首次津贴支付：7月22日结项考核、实习报告提交：8月25日（11:00 AM PDT/18:00 UTC)最终津贴支付批准：8月26日本期结束最终日期：8月31参与者如有意向如何申请？流程详见 [4]：https://docs.linuxfoundation.org/lfx/mentorship/mentee-guide/how-to-apply实习申请结果预计将在6 月 3 日通知到申请人。主线开发日期为2026年6月8日-8月25日，全程线上协作，无需线下参与。结项需要在2026年8月25日前以 PR 的形式提交到项目所在的开源社区仓库中并完成合并。  Volcano 项目课题  欢迎各位申请者申报CNCF Volcano社区课题：▍支持 Namespace 级别的 Queue课题描述：Volcano 当前的 Queue 是集群级别的资源，只有集群管理员才有权限创建和修改。这在多租户场景下对普通租户不太友好：租户通常只拥有自己 namespace 下的权限，但也想用上 Queue 提供的能力（资源共享、capability/guarantee/deserved、队列层级等）来管理自己的作业，而不是每改一次都要依赖集群管理员。本课题会在 Volcano 中引入 namespace 级别的 NamespaceQueue。NamespaceQueue 从 cluster 级别的 Queue 派生，语义和使用方式与 cluster Queue 保持一致，租户可以直接在自己的 namespace 下创建和管理队列，并像使用 cluster Queue 一样把 PodGroup/Job 关联到 NamespaceQueue 上进行调度。对不使用这个特性的用户，原有 cluster Queue 的行为和 API 完全不受影响。预期产出：新增 namespace 级别的 NamespaceQueue CRD，从 cluster 级别的 Queue 派生，capability/guarantee/deserved、队列层级等字段语义保持一致租户不需要集群管理员权限，就能在自己 namespace 下创建和管理 NamespaceQueuePodGroup/Job 支持引用 NamespaceQueue，调度行为与引用 cluster Queue 一致NamespaceQueue 的资源统计、status、事件等能够正常工作与原有 cluster Queue 和 scheduling.volcano.sh/queue-name annotation 兼容，老用户可以平滑迁移覆盖核心流程和异常场景的 E2E 测试Volcano 官网和代码仓库的用户文前置技能：GoKubernetes（CRD、controller、RBAC）熟悉 Volcano（scheduler、queue、PodGroup/Job 等）E2E 测试（Ginkgo）GitHub workflow 与 shell 脚课题导师：Zicong Chen（@JesseStutler ）jessestutler97@gmail.comHajnal Máté （@hajnalmt）hajnalmt@gmail.comJoão Azevedo （@devzizu）jazevedo960@gmail.com原始Issue：cid:link_2/issues/5251课题申请入口：https://mentorship.lfx.linuxfoundation.org/project/9e582ac4-4e12-4fcc-a1cd-27855d79730a▍Kthena Router 支持第三方模型 API课题描述：目前 Volcano/Kthena Router 已经能够很好地支持集群内部的路由能力。但在与用户的交流中,部分用户提出希望能够对接外部的大语言模型 API。因此,Kthena 社区计划借助本期 LFX,让 Router 具备访问第三方 LLM API 的能力。预期结果：设计提案(Proposal)代码实现(包含单元测试;如能补充端到端测试更佳。但考虑到外部 LLM API 通常不会提供长期、稳定的免费访问,端到端测试不作为强制要求)用户指南及相关文前置技能：Go、Kubernetes、网络、LLM课题导师：Zengzeng Yao（@yaozengzeng ）yaozengzeng@huawei.com原始Issue：cid:link_3/issues/939课题申请入口：https://mentorship.lfx.linuxfoundation.org/project/baa6fb1f-58c9-4255-849c-21aca35ce5e1▍Kthena Router 性能基准测试(Benchmark)课题描述：Kthena Router 是 Volcano/Kthena 项目中的 LLM 路由组件,负责将推理请求转发到集群内(以及即将支持的)第三方模型后端。随着 Kthena 逐步走向成熟,社区需要一套可复现的基准测试,用来在真实的 LLM 流量模式下衡量 Router 的性能特征(吞吐、延迟、TTFT、资源占用),并在版本迭代中及时发现性能回退。本项目希望设计并实现一套面向 Kthena Router 的基准测试框架,产出完整的测试报告。如果在过程中发现明显的瓶颈或可优化点,还需要与 Maintainer 协作,将代码层面的优化合入上游。预期产出：一套可复用的 Kthena Router 基准测试框架(压测客户端、场景配置、指标采集、结果汇总),可在本地乃至 CI 中运行。一组覆盖典型 LLM 路由模式的测试场景(不同的 QPS、prompt/response 长度、并发数、后端数量、路由策略等)。端到端测试流程文档化为 runbook(集群准备、mock/真实后端、运行方式、结果解读)。一份基准测试报告,包含吞吐、TPOT、TTFT、GPU/CPU/内存等指标,以及瓶颈分析。针对识别到的明显瓶颈进行优化并提交上游 PR,附上优化前后的性能对比数据前置技能：Go、Kubernetes、性能基准测试与性能剖析(pprof)、对 LLM 推理及 HTTP/gRPC 路由有基本了解。课题导师：Zengzeng Yao（@yaozengzeng ）yaozengzeng@huawei.comZhonghu Xu （@hzxuzhonghu ）zhhxu2011@gmail.com原始Issue：cid:link_3/issues/942课题申请入口：https://mentorship.lfx.linuxfoundation.org/project/1cf34cb5-3520-4f15-81c8-4258cb9abcb9▍支持多 AgentCube 协同能力课题描述：目前, Volcano社区AgentCube项目 在 Code Interpretation和 Agent Runtime场景下都只会拉起单个 Agent。然而,当前我们已经进入多 Agent 协作的时代。因此,AgentCube 计划支持多 Agent 编排,使多个 Agent 能够围绕同一个任务进行协作,并由 AgentCube 统一管理这些 Agent 的生命周期。预期结果：设计提案(Proposal)代码实现(包含单元测试和端到端测试)用户指南及其他相关文前置技能：Go、Kubernetes、Agent课题导师：Zhonghu Xu （@hzxuzhonghu ）zhhxu2011@gmail.com原始Issue：cid:link_1/issues/301课题申请入口：https://mentorship.lfx.linuxfoundation.org/project/9e7dd1c1-5d14-4c5e-af43-83454099e490更多Volcano课题，请访问LFX Mentorship官网[1]；对课题感兴趣/有任何问题，欢迎直接向课题导师发送邮件或在GitHub仓库提交Issue提问。今年夏季，Volcano社区期待在 LFX Mentorship 见到您！ 附：相关指引链接[1] LFX Mentorship计划官网及申报入口: https://mentorship.lfx.linuxfoundation.org/#projects_all[2] LFX Mentorship - Application Requirement: https://docs.linuxfoundation.org/lfx/mentorship/mentee-guide/am-i-eligible[3] LFX Mentorship - Program Readme: cid:link_0[4] LFX Mentorship - Mentee Application Guideline: https://docs.linuxfoundation.org/lfx/mentorship/mentee-guide/how-to-apply[5] Volcano GitHub: cid:link_2[6] Volcano/Kthena GitHub: cid:link_3[7] Volcano/AgentCube GitHub: cid:link_1 关注魔方公众号，获取更多前沿资讯添加社区小助手k8s2222，进入Volcano技术交流群

在刚刚闭幕的 KubeCon + CloudNativeCon Europe 2026 上，全球开源精英与产业力量齐聚阿姆斯特丹，共同见证了云原生领域的又一次浪潮。本届大会以“Keep Cloud Native Moving”为主题，传递出一个清晰的信号：云原生已远超资源编排的范畴，正加速进化为AI——尤其是LLM与Agentic AI——的核心运行底座。  开放创新，共建面向 Agentic AI 的智能原生基础设施  作为 CNCF 的持续贡献者与全球云原生产业的引领者，华为云本次参会以 “Powering the Agentic Future” 为核心主旨，全方位展示了面向 Agentic AI 的“智能原生”基础设施开源创新与产品方案。通过多场深度技术演讲、沉浸式展区互动以及前沿技术研讨，华为云向全球开发者系统分享了在 AI 全生命周期管理、大规模异构算力调度、分布式推理流量治理、高性能服务网格等关键方向上的技术突破与实践经验，共同码写云原生在智能时代的新篇章。▍Volcano：从 AI 全生命周期调度到 Agent 韧性底座随着 Agentic AI 的兴起，基础设施面临着从“作业调度”向“复杂智能体编排”的转变。作为业界顶尖的云原生AI调度引擎，Volcano 构建从大规模训练到 Agent 编排的 AI 全生命周期调度底座，并于 2025 年重点推出了 面向 LLM 推理的 Kthena 与 面向 AI Agent 工作负载的高性能编排层 AgentCube 两个备受瞩目的子项目，在技术层面高性能适配 Agentic AI 应用要求。在工作负载层：Volcano-Global 将海量训练作业拆分到多个集群，突破了单集群的限制；Kthena 提供企业级 LLM 服务，并支持 vLLM 等框架；AgentCube 快速实现Agent工作负载调度。在基础设施层，Volcano 通过 DRA 集成、HyperNode 发现、GPU 共享和异构池化，提供现代化的资源抽象，实现高效的任务到加速器映射。▲ Breaking the Monolith: Decomposing and Governing Giant LLM Jobs Across Clusters - Kevin Wang, Huawei通过打通完整 AI 生命周期的统一调度能力，Volcano 提供强大的调度能力和高吞吐量，能够协调各种工作负载，超越批处理作业的限制，实现多调度器协同，高效应对人工智能快速发展过程中的训练、推理和 Agent 工作负载运行在孤立的系统中造成的资源效率低等难题。这不仅是调度算法的优化，更是云原生 AI 基础设施的一次范式重构，为 Agentic Future 提供了稳健、高效的运行动力。▲ 华为云开源技术专家 Zhonghu Xu（上）、Zicong Chen(左）、ZengZeng Yao（右）发表Volcano及Kthena、AgentCube 议题更多Volcano议题演讲精彩内容，欢迎关注后续技术解析。▍Karmada：跨越云端边界，构建面向 AI 的多集群管理架构本届大会，来自华为云的 Karmada 维护者 Hongcai Ren 等组织了专场 Project Meeting ，与开发者与用户深度探讨了多集群扩展性、工作负载分发及社区发展路标，强化了分布式云原生的协作生态。携手Bloomberg、携程等生产用户，Karmada 社区也在分论坛上分享了社区过去一年的关键演进。Karmada 正在从“多集群管理工具”进化为“多集群AI编排底座”：应用优先级调度、联邦资源配额、有状态应用故障迁移等能力持续增强生产级稳定性；AI 作业调度增强与 Volcano Global 的协同，则为超大规模 LLM 任务的跨集群拆分与统一调度提供了坚实基础。同时，Karmada Dashboard 正式发布、Operator 能力持续增强，显著提升了多集群场景的可观测性与运维体验。▲ Karmada 社区专场会议与议题演讲在 ArgoCon 论坛上，华为云开源技术专家联合用户伙伴分享了 Karmada 与 Argo 生态整合的最佳实践。针对混合云多集群场景下渐进式交付缺乏全局协调能力的痛点，他们展示了如何通过 Karmada 与 Argo CD、Argo Rollouts 的整合，构建“定义一次，安全交付到任意集群”的统一平台。通过金丝雀发布示例，现场演示了集成架构与完整工作流，既保留了 Argo 在单集群渐进式交付的成熟能力，又借助 Karmada 的跨集群编排能力，将渐进式交付扩展至全局多集群。该方案已在生产环境中验证，为企业多云应用交付提供了可复用的实践范本。▲ From Canary To Global: Unified Progressive Delivery for Hybrid Cloud With Karmada & Argo - Zhuang Zhang, Huawei & Karmada PartnerKarmada 的成熟度与可靠性已在 Bloomberg、携程等复杂生产环境中得到充分验证，社区用户组成员突破40+。未来，Karmada 社区将持续聚焦 AI 工作负载的跨集群编排能力，与 Volcano、Kueue 等项目深度协同，共同构建面向AI多集群场景的统一管理与控制面▍Kmesh：基于 Rust 的数据面创新，引领Sidecarless服务网格服务网格的性能开销一直是大规模分布式系统痛点，尤其是在对时延极其敏感的 AI 推理场景中。Kmesh 独辟蹊径地采用了内核级、Sidecarless 的架构。通过将服务治理逻辑下沉至 OS 内核（基于 eBPF 技术），Kmesh 实现了近乎零开销的网络转发，极大地降低了服务间通信的时延。▲ Optimize Sidecarless Service Mesh With A Brand-New Rust-Based Proxy - Zengzeng Yao, Huawei Cloud；Kmesh Maintainer华为云开源技术专家分享了在 Kmesh 社区的技术创新成果。针对现有 Sidecarless 服务网格方案中 L7 流量处理依赖 Envoy waypoint 所带来的性能瓶颈与内存管理难题，包括不可预测的内存泄漏和生产环境调试复杂性。Kmesh 引入基于 Rust 重构的 Orion，作为 waypoint 与 Kmesh 深度集成后，Orion 与 Kmesh 的 eBPF L4 处理能力形成合力，构建了覆盖 L4 与 L7 的统一高性能 Sidecarless 服务网格。这一方案既延续了 Kmesh 在 L4 层的极致性能优势，又通过 Rust 的安全内存模型解决了 L7 代理在长期运行中的稳定性隐患，为服务网格在AI时代高吞吐、低延迟场景下的规模化落地提供了全新路径。▍边缘智算引擎，KubeEdge 赋能万物智能正如会上的演讲议题“KubeEdge Everywhere: From Graduation to Global Adoption”，KubeEdge 的行业应用近年来呈爆炸式增长。作为首个从 CNCF 毕业的云原生边缘项目，KubeEdge 自 2024 年晋级后，社区的功能更新、治理更新以及实践案例，充分验证了在边缘 AI 和行业工作负载管理方面的强大性能，其强大的边云协同能力，为千行百业的智慧场景提供了可落地的云原生边缘基础设施技术方案。来自DaoCloud、谐云、Google、华为云的技术专家共建了 KubeEdge 系列议题，与此同时，KubeEdge  Project Pavilion 吸引了大量关于边缘 AI 落地场景的讨论。▲ KubeEdge 应用于大会 Keynote 议题演讲中的滑翔机  展区零距离——智算引擎全栈体验  在华为展台，华为云向与会者展示了面向 Agentic AI 时代的智能原生基础设施解决方案。展区围绕 Agentic AI 基础设施与开发者展开深度互动，通过全新一代 CCE 智算集群、华为云 Agent 全栈平台、华为云容器领导力等产品与内容展示，呈现了从云原生基础设施到 AI 时代工作负载最佳运行底座的全栈能力，共同探讨智能原生未来图景。同时，华为云技术团队也分别在 Volcano、Karmada、Kmesh 等多个项目展台驻场，从多集群编排到AI调度，从服务网格到K8s生态，通过现场答疑、案例讲解与代码演示，与开发者进行开源技术创新与应用的面对面深度技术交流。作为云原生与 AI 领域的先驱者，华为云深耕 Kubernetes 等核心技术十余年，在 AI 浪潮中打造面向未来的AI原生基础设施，构建 AI Infra、Agent Infra 等算力底座，支撑 AI 大模型与 Agent 智能体应用需求。凭借多年来的产业实践和技术创新，华为云连续5年蝉联国内容器软件市场份额 TOP1，获选 Gartner 容器管理魔力象限领导者，Omdia 产品战略与执行全球第一，技术实力获全球权威认可。  Powering the Agentic Future  这场阿姆斯特丹的思想碰撞，是云原生基础设施与 Agentic AI 的一场“双向奔赴”；云原生底层逻辑正在升级重塑，成为支撑智能时代运行的“数字神经系统”。在迈向 Agentic Future 的征途中，我们将持续开放创新，让算力更高效、让治理更简洁、让智能更无处不在。期待与全球开源力量并肩，在智能原生的时代浪潮中，跑出加速创新的时代脚步。 更多云原生技术动向关注容器魔方

 ▍1. 前言随着大语言模型（LLM）日益成为现代应用的核心，支持它们的基础设施必须不断演进，以满足苛刻的性能、可扩展性和成本要求。在生产环境中部署 LLM 面临着独特的挑战：模型需要大量资源，推理工作负载变化显著，用户期望低延迟和高吞吐量。传统的负载均衡器和 API 网关虽然在传统 Web 服务中表现出色，但缺乏智能路由 AI 推理流量所需的感知能力。Kthena[1] Router 正面应对这些挑战。它是一个 Kubernetes 原生的独立推理Router，专为 LLM 服务工作负载而设计。与通用代理或负载均衡器不同，Kthena Router 具有模型感知能力，根据推理引擎的实时指标做出智能路由决策。这使得其能够实现复杂的流量管理策略，显著提高吞吐量、降低延迟并降低运营成本。Kthena Router 能够与现有 API 网关基础设施无缝集成，同时提供专为 AI 工作负载设计的高级功能：模型感知路由：利用推理引擎（vLLM、SGLang、TGI）的实时指标做出智能路由决策LoRA 感知负载均衡：智能路由到已加载所需 LoRA Adapter 的 Pod，将数百毫秒的 Adapter Swap 延迟降低到接近零高级调度算法：包括Prefix Cache感知、KV Cache感知和公平性调度等PD分离：原生支持 xPyD（x-prefill/y-decode）部署模式Kthena Router 作为独立二进制文件部署，极简依赖，确保轻量级运行和简单部署。它持续监控推理引擎指标，以获取有关模型状态的实时信息，包括当前加载的 LoRA Adapter、KV Cache 利用率、请求队列长度和延迟指标（TTFT/TPOT）。这种实时感知能力使 Router 能够做出传统负载均衡器根本无法实现的最优路由决策。▍2. 架构Kthena Router 实现了一个清晰的模块化架构，专为性能和可扩展性而设计。该系统由几个核心组件协同工作，提供智能请求路由。Kthena Router 架构2.1 核心组件概述Router： 负责接收、处理和转发请求的核心执行框架。它协调所有其他组件之间的交互，并维护从初始接收到最终响应的请求生命周期。Listener： 管理 HTTP/HTTPS 监听器并处理指定端口上的传入流量。它为不同协议提供灵活的配置，并可以绑定到多个地址以服务各种类型的请求。监听器确保高效的连接处理，并支持流式和非流式请求模式。Controller： 一个 Kubernetes 原生组件，用于同步和处理 Pod 和自定义资源（CR），例如 ModelRoute 和 ModelServer。Controller监视集群中的变化，并相应地更新Router的内部状态，确保路由决策始终基于当前的集群拓扑。Filters： 包含两个关键子模块，在请求到达后端之前处理请求：Auth：处理流量认证和授权，支持 API Key、JWTRateLimit：管理全面的速率限制策略，包括输入token和输出token限制Backend： 提供访问各种推理引擎的抽象层。它掩盖了不同框架（如 vLLM、SGLang 和 TGI）之间Metrics接口访问方法和Metrics命名约定的差异，向调度器提供统一的接口。Metrics Fetcher： 持续从模型 Pod 上运行的推理引擎端点收集实时Metrics。它收集关键性能数据，包括：KV Cache利用率当前加载的 LoRA Adapter请求队列长度延迟指标（TTFT，TPOT）Datastore： 一个统一的数据存储层，提供对 ModelServer 到 Pod 关联、Base Model/LoRA 配置和运行时Metrics的高效访问。它作为所有路由相关信息的中央存储库，并支持实时更新的回调。Scheduler： Router的大脑，实现复杂的流量调度算法。它由一个调度框架和各种可插拔的调度算法插件组成。该框架集成并运行不同的调度插件，以过滤和评分与 ModelServer 对应的 Pod 集合，选择全局最优的 Pod 作为最终访问目标。Kthena Router 组件▍3. Router APIKthena Router 的路由行为由两个关键的自定义资源定义（CRD）控制：ModelServer 和 ModelRoute。这些声明式 API 允许您使用熟悉的 Kubernetes 模式定义复杂的路由策略。3.1 ModelRouteModelRoute 根据请求特征定义流量路由规则。它根据模型名称、LoRA Adapter、HTTP Header和其他条件确定哪些 ModelServer 应该处理请求。关键字段包括：ModelName：要在传入请求中匹配的模型名称LoRAAdapters：此路由支持的 LoRA 适配器名称列表Rules：有序的路由规则列表，每个规则包含：ModelMatch：匹配请求的条件（Header、URI 等）TargetModels：要路由到的 ModelServer 列表，可选权重RateLimit：基于token的速率限制配置有关 ModelRoute 的更多详细信息，请参阅 定义[2]。3.2 ModelServerModelServer 定义推理服务实例及其访问策略。它标识运行模型的 Pod，指定正在使用的推理框架，并定义如何处理流量。关键字段包括：WorkloadSelector：通过标签标识 Pod，并支持 PD（prefill-decode）组规范Model：指定服务器托管的Base Model名称InferenceFramework：指示推理引擎（vLLM、SGLang、TGI 等）WorkloadPort：定义推理服务监听的端口TrafficPolicy：配置超时、重试策略和其他流量处理行为KVConnector：为 PD 分离部署指定 KV Connector类型（HTTP、Nixl、LMCache、Mooncake）有关 ModelServer 的更多详细信息，请参阅 定义[3]。3.3 示例：基于HTTP Header的多模型路由对于分层服务产品，根据头将用户路由到不同大小的模型：apiVersion: networking.serving.volcano.sh/v1alpha1kind: ModelRoutemetadata: name: deepseek-multi-models namespace: defaultspec: modelName: "deepseek-multi-models" rules: - name: "premium" modelMatch: headers: user-type: exact: premium targetModels: - modelServerName: "deepseek-r1-7b" - name: "default" targetModels: - modelServerName: "deepseek-r1-1-5b"---apiVersion: networking.serving.volcano.sh/v1alpha1kind: ModelServermetadata: name: deepseek-r1-7b namespace: defaultspec: workloadSelector: matchLabels: app: deepseek-r1-7b workloadPort: port: 8000 model: "deepseek-ai/DeepSeek-R1-Distill-Qwen-7B" inferenceEngine: "vLLM" trafficPolicy: timeout: 10s---apiVersion: networking.serving.volcano.sh/v1alpha1kind: ModelServermetadata: name: deepseek-r1-1-5b namespace: defaultspec: workloadSelector: matchLabels: app: deepseek-r1-1-5b workloadPort: port: 8000 model: "deepseek-ai/DeepSeek-R1-Distill-Qwen-1.5B" inferenceEngine: "vLLM" trafficPolicy: timeout: 10s流量处理过程：请求到达，模型名称为 "deepseek-multi-models"Router检查HTTP Header中是否存在 user-type: premium高级用户 → 路由到更大的 7B 模型以获得更好的质量普通用户 → 路由到更小的 1.5B 模型以提高成本效率测试高级路由：curl http://$ROUTER_IP/v1/completions \ -H "Content-Type: application/json" \ -H "user-type: premium" \ -d '{"model": "deepseek-multi-models", "prompt": "Explain quantum computing"}'这个示例演示了 ModelRoute 和 ModelServer CRD 如何通过标准 Kubernetes API 提供对复杂路由策略的灵活声明式控制。▍4. 核心功能4.1 智能调度插件真正将 Kthena Router 与传统负载均衡器区分开的是其一套模型感知调度插件。这些插件利用实时推理引擎指标做出智能路由决策，显著提高性能。4.1.1 LoRA 亲和性调度LoRA（低秩适应）Adapter 能够在不重新部署 Base Model 的情况下实现微调的模型行为。然而，加载和卸载 Adapter 会引入延迟。LoRA 亲和性插件通过智能路由最小化这种开销。工作原理：持续跟踪每个 Pod 上当前加载的 LoRA Adapter 状态将需要特定 LoRA 的请求优先路由到已加载该 Adapter 的 Pod通过缓存命中避免 Adapter 加载/卸载操作优势：消除 Adapter Swap 延迟: 将数百毫秒的 Adapter 切换延迟降至接近零提高响应速度: 避免动态加载 Adapter 带来的额外等待时间支持多 LoRA 场景: 高效处理多个 LoRA Adapter 的混合工作负载4.1.2 Least Latency 调度Least Latency 插件根据实时延迟指标将请求路由到响应最快的 Pod，优化用户体验和整体生成速度。工作原理：持续监控推理引擎的延迟指标综合评估 TTFT（首 token 时间）和 TPOT（每输出 token 时间）将请求路由到延迟最低的 Pod动态适应 Pod 性能变化关键指标：TTFT（首 token 时间）: 影响流式响应和用户感知延迟TPOT（每输出 token 时间）: 决定整体生成速度和吞吐量4.1.3 Least Request 调度Least Request 插件基于请求队列状态进行负载均衡，将请求路由到最不繁忙的 Pod，确保均匀的负载分布。工作原理：监控推理引擎的 num_requests_running 和 num_requests_waiting 指标计算每个 Pod 的总待处理工作负载（运行中 + 等待中）将新请求路由到负载最低的 Pod动态平衡各 Pod 之间的工作分配优势：防止热点: 避免部分 Pod 过载而其他 Pod 空闲均衡负载: 确保所有 Pod 的利用率趋于一致提高吞吐量: 通过最优负载分配最大化整体处理能力4.1.4 GPU Usage 调度GPU Usage 插件基于 GPU 缓存使用率进行负载均衡，将请求路由到缓存压力较小的 Pod，优化 GPU 资源利用率。工作原理：持续监控每个 Pod 的 GPU 缓存使用率指标计算可用缓存容量：score = (1.0 - GPU缓存使用率) × 100  优先将请求路由到 GPU 缓存使用率较低的 Pod避免因缓存耗尽导致的性能下降和请求失败优势：防止缓存溢出: 避免将请求发送到缓存已满的 Pod提高稳定性: 减少因缓存不足导致的请求失败和重试负载均衡: 确保 GPU 缓存资源在所有 Pod 间均衡使用提升吞吐量: 保持各 Pod 在最优缓存利用率区间运行4.1.5 Prefix Cache 感知调度现代推理引擎（如 vLLM 和 SGLang）实现 Prefix Cache 机制，将常用的 Prompt 前缀缓存起来以避免冗余计算。Prefix Cache 感知插件通过智能路由策略最大化前缀缓存的命中率，显著提升推理性能。核心机制：滚动哈希生成:将 Prompt 按固定大小（默认 64 字节）划分为块使用 xxHash 算法为每个块生成滚动哈希每个哈希值结合前一个块的哈希，形成依赖链哈希匹配时保证所有前置块也匹配，实现高效前缀识别内存缓存存储:使用三层映射结构：模型 → 哈希 → Pod采用 LRU（最近最少使用）缓存策略管理内存自动清理过期条目，保持缓存效率默认缓存容量 50,000 条，返回 Top-5 最佳匹配智能评分算法:根据前缀匹配长度对 Pod 评分评分公式：score = (匹配块数 / 总块数) × 100 优先选择具有最长匹配前缀的 Pod提高缓存命中率和推理效率适用场景：多轮对话系统，用户在同一 session 中发送多个相关请求具有固定 system prompt 的应用场景问答系统中频繁使用相同上下文的查询4.1.6 KV Cache Aware 调度KV Cache Aware 插件是一个高级调度插件,通过基于token级别的块匹配来智能路由请求,最大化 KV 缓存命中率。与简单监控缓存利用率不同,该插件实现了细粒度的内容感知调度,显著提升性能。核心机制：Token 块哈希:将传入的prompt分词后按固定大小(默认128个token)划分为块使用 SHA-256 为每个块生成标准化哈希值支持可配置的最大块数(默认128块)以平衡性能和准确性分布式缓存跟踪:使用 Redis 维护全局的块到 Pod 映射Redis key 格式: matrix:kv:block:{model}@{hash}  每个 key 存储包含该块的 Pod 列表及其缓存时间戳通过 Redis Pipeline 批量查询实现高效的分布式协调智能评分算法:查找每个token块在哪些 Pod 上已缓存从第一个块开始计算连续匹配长度优先选择具有最长连续匹配前缀的 Pod评分公式: score = (匹配块数 / 总块数) × 100Tokenizer 集成:支持多种tokenizer backend(本地和远程 vLLM)自动处理不同模型的分词差异确保一致的token到块的映射优势：精确匹配: 不仅考虑缓存容量,还考虑实际缓存的内容避免冷启动: 将请求路由到已经处理过相似prompt的 Pod提升吞吐量: 减少重复计算,在long system prompt场景下可实现 2.73 倍吞吐量提升降低延迟: TTFT 可降低 73.5%,显著改善用户体验更多技术细节请参考 KV Cache Aware 插件设计文档[4]。4.1.7 插件配置这些插件通过调度器框架协同工作。您可以通过Router配置来配置启用哪些插件及其相对权重。调度器框架按顺序运行启用的插件：Filter：插件过滤不合适的 Pod（例如，缓存不足、错误的 LoRA）Score：插件根据其条件对剩余 Pod 评分Select：为请求选择得分最高的 Pod这种可组合的架构允许您根据特定的工作负载需求定制路由行为。4.2 公平性调度公平性调度确保基于token消耗历史在用户之间公平分配资源。工作原理：跟踪每个用户每个模型的累积token使用量（输入 + 输出）分配与历史使用量成反比的请求优先级将请求排队并按优先级顺序处理防止任何单个用户垄断资源用例：具有共享基础设施的多租户平台具有公平共享策略的研究集群需要基于使用量的节流的 SLA 驱动系统4.3 PD分离支持对于高级部署模式，Kthena Router 原生支持PD分离（xPyD），其中计算密集型的Prefill阶段与token生成Decode阶段分离。工作原理：从 ModelServer CRD 识别 PD 组配置将Prefill请求路由到Prefill优化的 Pod通过可配置的连接器（HTTP、Nixl 等）传输 KV 缓存状态将Decode请求路由到Decode优化的 Pod对客户端透明地协调两阶段过程优势：通过将工作负载特征与硬件匹配来优化硬件利用率通过为每个阶段使用专用硬件来减少延迟通过更好的资源分配提高成本效率4.4 基于token的RateLimitKthena Router 提供全面的RateLimit功能，以保护您的推理基础设施免受过载，并确保跨用户的公平资源分配。Input token限制：控制每个用户或 API 密钥的传入prompt token速率Output token限制：限制生成的token以管理计算成本Local RateLimit：在每个Router实例基础上实施限制。Global RateLimit：使用 Redis 等中央存储在所有Router实例之间实施共享限制。4.5 可观测性Kthena Router 提供为生产 LLM 服务设计的全面可观测性功能：指标：在 /metrics endpoint公开详细指标，包括请求延迟、token消耗、调度器插件性能和RateLimit统计信息结构化访问日志：以 JSON 或文本格式记录完整的请求生命周期，包括路由决策、用时分布和token跟踪Debug endpoint：提供 /debug/config_dump/* API 来检查内部状态、ModelRoute/ModelServer 配置和实时 Pod 等指标标准集成：与 Prometheus、Grafana、ELK 等可观测性堆栈无缝协作，用于监控、告警和故障排除▍5. 性能Kthena Router 中的 ScorePlugin 模块利用可配置的可插拔架构来实现推理请求的多维评分和智能路由。为了演示智能调度的影响，我们基于 DeepSeek-R1-Distill-Qwen-7B 模型构建了一个标准化的基准测试环境，以评估不同调度策略在长短system prompt场景下的性能。实验结果表明，在long system prompt场景中，KV Cache Aware Plugin + Least Request Plugin 组合实现了 2.73 倍的吞吐量，并将 TTFT 延迟降低了 73.5%，显著优化了整体推理服务性能，验证了Cache感知调度对大规模模型推理的核心价值。5.1 实验设置使用 DeepSeek-R1-Distill-Qwen-7B 模型构建了标准化的基准测试环境，以评估不同调度策略的性能。表 1：实验环境配置5.2 Long System Prompt Scenario（4096 token）表 2：性能指标 - Long System Prompt ▍6. 结论Kthena Router 代表了 LLM 服务基础设施的重大飞跃。通过超越简单的负载均衡，实现模型感知、指标驱动的路由，它释放了以前无法实现的显著性能改进和成本节省。它是开源的，现在就可以使用。Kthena文档[5]提供了安装、配置和部署的全面指南。Kthena-router 示例目录[6]包含用于常见场景的即用型配置。无论您是运行单个模型还是管理复杂的多租户 LLM 平台，Kthena Router 都提供了最大化性能、最小化成本和提供卓越用户体验所需的智能路由功能。作者 | YaoZengzeng   相关链接[1] Kthena: https://kthena.volcano.sh/[2] ModelRoute 定义: cid:link_1[3] ModelServer定义: cid:link_2[4] KV Cache Aware 插件设计文档: cid:link_3[5] Kthena文档: https://volcano-sh.github.io/kthena/[6] Kthena-router 示例目录: cid:link_4 扫码进群，社区小助手k8s2222

Volcano[1] 社区 v1.14 现已正式发布。随着 AI 业务形态从单一的离线训练向在线推理、Agent 智能体等多元化场景延伸，调度系统面临着前所未有的挑战。v1.14[2] 通过架构级的创新，在保持大规模批量计算优势的同时，补齐了对延迟敏感型业务的调度短板，向着 “AI训推、RL、Agent全场景统一调度平台” 的目标迈出了坚实一步。  版本亮点  📌 v1.14.0 版本带来以下重磅更新：统一调度平台架构多调度器架构升级：动态节点分片机制 (Alpha)AI Agent 工作负载极速调度能力 (Alpha)网络拓扑感知调度增强HyperNode 级 Binpack 策略SubGroup 级精细化拓扑感知PodGroup 与 SubGroup 多层级 Gang SchedulingVolcano Job 分区支持混部能力增强全面支持通用操作系统（Ubuntu、CentOS 等）Cgroup V2 全面适配CPU 动态压制基于 Cgroup V2 的内存 QoS支持 CPU Burst支持 systemd driver 自动检测异构硬件支持昇腾 vNPU 调度（支持 MindCluster 和 HAMi 模式）Volcano Global 增强HyperJob 多集群作业自动拆分数据感知多集群调度Volcano Dashboard 增强PodGroup 全景可视化Job / Queue 全生命周期管理▍多调度器架构升级：动态节点分片机制 (Alpha)随着 Volcano 承载的工作负载类型日益丰富、规模持续扩大，单一调度器架构逐渐显露瓶颈。批量训练、AI Agent、微服务等不同类型的工作负载，对调度时延、资源利用模式的诉求各不相同。单调度器难以兼顾，而静态资源划分又会造成利用率低下。新引入的 Sharding Controller 构建了一套可扩展的多调度器架构，能够根据集群实时状态，为每个调度器动态计算候选节点池。与传统的静态分区不同，Sharding Controller 采用动态计算的方式划分资源，而非强制硬隔离。这种灵活机制让 Volcano 真正成为"一个平台调度所有负载"的统一调度平台，同时保持高吞吐、低时延。核心能力：动态分片策略：支持多种策略来计算动态候选节点池。当前版本率先支持基于 CPU 利用率的分片策略，并采用了可扩展的架构设计，以便未来轻松集成更多分片算法。节点池化管理：引入 NodeShard CRD，为特定调度器管理专属的动态候选节点池。支持大规模集群：通过在多个调度器之间灵活分配负载，天然适配大规模集群场景。多调度器协同：支持多种调度器组合的无缝协作。无论是部署多个 Batch Scheduler 进行负载分担，还是混合部署 Agent Scheduler 与 Batch Scheduler 以应对不同业务需求，都能灵活适配。配置示例：# Sharding Controller 启动参数--scheduler-configs="volcano:volcano:0.0:0.6:false:2:100,agent-scheduler:agent:0.7:1.0:true:2:100"--shard-sync-period=60s--enable-node-event-trigger=true# 参数格式: name:type:min_util:max_util:prefer_warmup:min_nodes:max_nodes🔗 相关 PR：cid:link_9设计文档：Sharding Controller Design[3]感谢社区开发者：@ssfffss, @Haoran, @qi-min▍AI Agent 工作负载极速调度 (Alpha)AI Agent 类业务对时延极度敏感，任务创建频繁且生命周期短，对调度器的响应速度和吞吐量提出了严苛要求。原生 Volcano Batch Scheduler 专为批量计算设计，按固定周期处理 Pod，难以满足 Agent 场景的毫秒级响应需求。为打造兼容批量计算与延迟敏感型业务的统一调度平台，v1.14 引入了专用的 Agent Scheduler。它通过 Sharding Controller 与批量调度器协同工作，各司其职又无缝配合，真正实现"一个平台、多种负载"。核心能力：极速调度通道：专为延迟敏感型负载（如 AI Agent）打造的独立调度器，提供极致响应速度。多 Worker 并行处理：采用多 Worker 并发消费调度队列的架构，大幅提升调度吞吐量。乐观并发控制：引入 Conflict-Aware Binder 机制，在实际绑定前预先解决冲突，减少无效操作。增强型调度队列：优化队列机制，支持紧急任务重试，确保关键任务不阻塞。统一平台融合：通过 Sharding Controller 与批量调度器无缝协作，共享集群资源。 🔗 相关 PR：  https://github.com/volcano-sh/volcano/pull/4804,  cid:link_11,  cid:link_12设计文档：Agent Scheduler Design[4]感谢社区开发者：@qi-min, @JesseStutler, @handan-yxh▍网络拓扑感知调度增强Volcano v1.14.0 对网络拓扑感知调度进行了进一步增强，满足分布式工作负载（包括 LLM 训练、推理、HPC 和其他网络密集型应用）日益增长的需求。核心增强：SubGroup 级精细化拓扑感知：支持在 SubGroup / Partition 粒度设置网络拓扑约束，调度颗粒度更精细。灵活的网络层级约束：新增 highestTierName，支持按名称指定允许跨越的最高网络层级。多层级 Gang Scheduling：同时支持 PodGroup 级别和 SubGroup 级别的 Gang Scheduling，确保分布式任务的整体性。Volcano Job 分区：支持将 Job 拆分为多个分区（Partition），便于管理 TP/PP/DP 等并行策略，并优化网络亲和性。HyperNode 级 Binpacking：在 HyperNode（如交换机、机架）层级进行资源装箱，减少网络碎片，提升通信效率。配置示例 - Volcano Job：apiVersion:batch.volcano.sh/v1alpha1 kind:Job metadata: name:llm-training-job spec: networkTopology: mode:hard highestTierAllowed:2 # 整个 Job 最多跨越 Tier 2 HyperNode tasks: - name:trainer replicas:8 partitionPolicy: totalPartitions:2 # 拆分为 2 个分区 partitionSize:4 # 每个分区 4 个 Pod minPartitions:2 # 至少需要 2 个分区 networkTopology: mode:hard highestTierAllowed:1 # 单个分区必须在 Tier 1 内 template: spec: containers: - name:trainer image:training-image:v1 resources: requests: nvidia.com/gpu:8 🔗 相关 PR：  cid:link_13,  cid:link_14,  cid:link_15,  cid:link_16,  cid:link_17设计文档：Network Topology Aware Scheduling[5]感谢社区开发者：@ouyangshengjia, @3sunny, @zhaoqi, @wangyang0616, @MondayCha, @Tau721▍混部能力全面升级：支持通用操作系统本次发布对 Volcano 的混部能力进行了全面改进，其中一个重要里程碑是：Volcano 混部能力正式支持通用操作系统（Ubuntu、CentOS 等），不再局限于 OpenEuler。这意味着更多用户可以使用 Volcano Agent 实现在离线混部，提升集群整体资源利用率。CPU 动态压制 (CPU Suppression)在线业务流量通常具有潮汐特性。为了在保障在线业务 SLA 的同时最大化资源利用，离线 Pod 的 CPU 配额需要随在线用量动态调整：在线用量高时压制离线配额，用量回落时逐步恢复，实现自适应的资源分配。核心设计：根据节点可分配 CPU 和实时用量，动态调整 BestEffort root cgroup 的 CPU 配额。采用"监控-事件-处理"架构，并实施保守更新策略，有效抑制抖动。配置示例：cpuThrottlingConfig: enable:true cpuThrottlingThreshold:80 # BE 配额上限为可分配 CPU 的 80% cpuJitterLimitPercent:1 # 配额变化超过 1% 才触发更新 cpuRecoverLimitPercent:10 # 单次恢复上限 10%内存 QoS (Cgroup V2)基于 Cgroup V2 实现混部场景的内存隔离。新增 ColocationConfiguration CRD，支持为指定工作负载配置内存 QoS 策略。核心能力：New API：通过标签选择器定义内存隔离策略的 ColocationConfiguration CRD动态计算：memory.high = pod.limits.memory * highRatio %memory.low = pod.requests.memory * lowRatio %memory.min = pod.requests.memory * minRatio %统一接口：可靠检测和支持 Cgroup V2 环境使用示例：apiVersion:config.volcano.sh/v1alpha1 kind:ColocationConfiguration metadata: name:colo-config1 spec: selector: matchLabels: app:offline-test memoryQos: highRatio:100 # memory.high = memory.limits * 100% lowRatio:50 # memory.low = memory.requests * 50% minRatio:0 # memory.min = memory.requests * 0%CPU Burst 与 Cgroup V2 全面支持CPU Burst 能力已扩展至通用操作系统。同时，Volcano Agent 现已全面适配 Cgroup V2 环境，支持自动检测 Cgroup 版本及驱动类型（如 systemd driver），无需人工干预即可在现代 Linux 发行版上无缝运行。 🔗 相关 PR： cid:link_18,  cid:link_19,  cid:link_20,  cid:link_21设计文档：CPU Throttle Design[6], Agent Cgroup V2 Adaptation[7]感谢社区开发者：@Haibara-Ai97, @JesseStutler, @ouyangshengjia▍昇腾 vNPU 调度v1.14 原生集成了昇腾 vNPU（虚拟 NPU）调度能力，实现昇腾 AI 处理器在多个工作负载之间的高效算力复用。提供两种模式，灵活适配不同部署场景。支持模式：1. MindCluster 模式集成自 Ascend MindCluster 调度插件：https://gitcode.com/Ascend/mind-cluster支持昇腾 310P 系列的动态虚拟化2. HAMi 模式由 HAMi 社区开发同时支持昇腾 310 和 910 系列支持异构昇腾集群（910A、910B2、910B3、310P）调度器配置：# MindCluster 模式 - name:deviceshare arguments: deviceshare.AscendMindClusterVNPUEnable:true # HAMi 模式 - name:deviceshare arguments: deviceshare.AscendHAMiVNPUEnable:true deviceshare.SchedulePolicy:binpack # 或 spread 🔗 相关 PR： cid:link_22,  cid:link_23使用文档：How to Use vNPU[8] 感谢社区开发者：@JackyTYang, @DSFans2014▍Volcano Global 增强Volcano Global v0.3.0 引入了两个重要功能，通过基于计算资源和数据局部性的智能调度，显著扩展了 Volcano Global 对 AI/ML 和大数据工作负载的能力。HyperJob：多集群作业自动拆分随着 AI 训练工作负载规模和复杂性的增长，企业越来越面临跨多个异构集群管理大规模训练作业的挑战。HyperJob 是构建在 Volcano Job 之上的更高级抽象。它组合多个 Volcano Job 模板，将训练能力扩展到单集群边界之外，同时保留每个集群内现有 Volcano Job 的全部能力。核心能力：Karmada 深度集成：自动生成 PropagationPolicy，精准配置集群亲和性与副本调度。状态统一聚合：将各集群子任务状态汇总为统一的 HyperJob 状态，全局可观测。自动资源生成：根据 ReplicatedJob 定义自动创建 VCJob 和 PropagationPolicy。HyperJob 资源示例（跨 2 个集群拆分大规模训练作业，共 256 个 GPU）：apiVersion:training.volcano.sh/v1alpha1 kind:HyperJob metadata: name:llm-training spec: replicatedJobs: - name:trainer replicas:2 templateSpec: tasks: - name:worker replicas:128 template: spec: containers: - name:trainer image:training-image:v1 resources: requests: nvidia.com/gpu:1数据感知调度在 AI 训练和大数据分析等高性能计算场景中，任务执行不仅依赖计算资源，还严重依赖数据资源。在多集群环境中，调度器可能会将任务分派到与数据源物理距离较远的集群，导致跨地域带宽成本过高和 I/O 延迟过高。数据感知调度框架引入 DataDependencyController，打通了逻辑数据需求与物理集群分布的壁垒。通过外部插件（如 Amoro）实时获取数据分布信息，自动将调度约束注入 Karmada，实现"计算随数据而动"的全自动工作流。核心能力：插件化架构：可扩展支持 Amoro、Hive、S3 等多种数据系统。声明式 API：DataSourceClaim / DataSource CRD，采用"声明-缓存"模式。自动亲和注入：将数据局部性转化为 ClusterAffinity 约束，注入 ResourceBinding。详见： Volcano Global v0.3.0 Release Notes[9]感谢社区开发者：@JesseStutler, @fx147, @Monokaix, @zhoujinyu, @anryko, @tanberBro▍Volcano Dashboard v0.2.0Volcano Dashboard v0.2.0 对资源管理能力进行了重大增强，使得通过 Web 界面管理 Volcano 资源更加便捷。核心增强：PodGroup 全景可视化：跨命名空间查看、搜索、过滤 PodGroup，支持 YAML 语法高亮。Job 生命周期管理：直接在界面创建、删除 Volcano Job，操作更便捷。Queue 管理增强：在线编辑 Queue 配额、权重，支持 YAML 直接修改。安全加固：默认配置 SELinux、Seccomp、非 root 运行及禁止提权，保障生产安全。详见： Volcano Dashboard v0.2.0 Release Notes[10]感谢社区开发者：@vzhou-p, @Shrutim1505, @JesseStutler, @karanBRAVO, @Sayan4444, @jayesh9747, @Alivestars24, @kuldeep, @Monokaix▍调度器稳定性与性能提升Reclaim 重构与增强对 Reclaim Action 进行了全面重构，并修复了 Capacity Plugin 中的关键逻辑问题，大幅提升多租户集群资源回收的准确性、稳定性和性能。主要改进：Reclaim Action 重构：重构了 reclaim 工作流，提高代码可读性、可维护性和测试覆盖率。增强的 Capacity Plugin 逻辑：修复了 reclaimableFn 和 preemptiveFn，正确处理标量资源并防止错误的抢占决策。稳定性提升：解决了资源计算中的边缘情况，防止调度死循环和误驱逐。 🔗 相关 PR： cid:link_24,  cid:link_25,  cid:link_26感谢社区开发者：@guoqinwill, @hajnalmt▍支持 Kubernetes 1.34Volcano 版本紧跟 Kubernetes 社区。v1.14 已全面支持最新的 Kubernetes v1.34，并通过完整的单元测试和 E2E 测试保障功能与稳定性。🔗 相关 PR：cid:link_27感谢社区开发者：@suyiiyii, @tunedev  总结：Volcano v1.14.0 — AI 时代的统一调度平台  Volcano v1.14 是一个里程碑式的版本。通过引入多调度器架构和 Agent Scheduler，Volcano 正式迈入统一调度平台新阶段，既能高效处理批量 AI 训练，又能满足 AI Agent 的极致时延要求。网络拓扑感知增强、通用操作系统混部支持、昇腾 vNPU 集成，进一步夯实了 Volcano 在 AI 基础设施领域的领先地位。同时，Volcano Global v0.3.0 通过 HyperJob 实现大规模分布式训练和数据感知调度，扩展了多集群能力。Volcano Dashboard v0.2.0 通过全面的资源管理功能显著改善了用户体验。立即体验 Volcano v1.14，共启 AI 时代统一调度新篇章！v1.14.0 发布地址：cid:link_8Volcano Global v0.3.0 发布地址：cid:link_6Volcano Dashboard v0.2.0 发布地址：cid:link_7   致   谢   Volcano v1.14 生态版本（含 Volcano Global v0.3.0、Dashboard v0.2.0）共有 55 位社区贡献者参与。衷心感谢每一位贡献者：相关链接[1] Volcano: https://volcano.sh/en/[2] Volcano v1.14.0: cid:link_8[3] Sharding Controller Design: cid:link_2[4] Agent Scheduler Design: cid:link_5[5] Network Topology Aware Scheduling: cid:link_0[6] CPU Throttle Design: cid:link_3[7] Agent Cgroup V2 Adaptation: cid:link_1[8] How to Use vNPU: cid:link_4[9] Volcano Global v0.3.0 Release Notes: cid:link_6[10] Volcano Dashboard v0.2.0 Release Notes: cid:link_7 扫码回复“Volcano” 进入技术群

作者：Kthena MaintainersKthena 是一个专为 Kubernetes 设计的云原生、高性能 LLM 推理路由和编排、调度系统。作为 Volcano 的子项目，Kthena[1] 致力于帮助 Volcano[2] 扩展除 AI 训练之外的边界，打造训推一体的完整解决方案。Kthena v0.3.0[3] 现已正式发布，标志着 Kthena 已经成为一个更加健壮且具有可扩展性的 AI 推理平台。此版本在 ModelServing、Router 和 ModelBooster 方面引入了重大增强。核心亮点包括：与 LeaderWorkerSet 的无缝集成、针对 PD 分离（Prefill-Decode Disaggregation）的高级网络拓扑感知调度，以及完善的 Router 可观测性框架。此外，本版本还带来了原生的 ModelServing 版本控制、对 vLLM 数据并行部署的支持，以及完整的 Router E2E测试套件，确保了生产环境的高稳定性和可靠性。  关键新特性概览  LeaderWorkerSet 支持：集成 LeaderWorkerSet (LWS) API，实现对分布式推理工作负载的高级管理。角色级 Gang 调度与拓扑感知：利用 Volcano 的 subGroupPolicy 新特性，实现精细化的角色级 Gang 调度和网络拓扑感知。ModelServing 分区版本控制：引入了基于 Revision 的原生 ModelServing 版本控制系统。Router 可观测性与调试：提供完善的 Router 可观测性文档和框架，并新增专用调试端口。增强的滚动更新：支持 maxUnavailable 参数，可调节更新速度以实现更快地发布。插件支持：为 ModelServing 提供灵活的插件架构，用于注入自定义配置逻辑。▍ModelServing 角色支持 LeaderWorkerSet分布式推理工作负载通常需要复杂的拓扑结构，其中一个 Leader Pod 管理多个 Worker Pod。手动配置这些关系容易出错。通过集成 Kubernetes LeaderWorkerSet (LWS) API，Kthena 简化了这些工作负载的部署和管理。核心能力：直接集成：ModelServing 角色（Role）现在可以利用 LWS 自动管理 Leader-Worker 组。简化拓扑：降低了定义需要严格协调的分布式推理服务的复杂性。相关内容：🧩 PR:cid:link_4cid:link_5贡献者: @zhiweideren▍角色级 Gang 调度与拓扑感知在 Prefill-Decode (PD) 分离场景中，Prefill 实例和 Decode 实例之间的通信开销至关重要。确保这些实例在物理位置上更接近（例如在同一个交换机或机架下）可以显著提升性能。Kthena 现在通过 Volcano 的 subGroupPolicy 实现了对 Gang 调度和网络拓扑感知的精细化、角色级控制。核心能力：声明式拓扑策略：直接在 ModelServing 规范中为整个 ServingGroup（groupPolicy）以及单个角色（rolePolicy）配置不同的网络拓扑限制。自动 Pod 分组：Controller自动为 Pod 打上 modelserving.volcano.sh/role 和 modelserving.volcano.sh/role-id 标签，使 Volcano 能够形成子组（subGroup）以进行精确的拓扑感知放置。性能优化：通过将相关任务部署在网络邻近的节点上，最小化角色间通信延迟并最大化带宽利用率，适用于高强度分布式推理任务。角色级 Gang 调度：subGroupPolicy 还强制执行角色级 Gang 调度，确保属于特定角色（例如所有 prefill-0 Pod）的所有 Pod 作为一个原子单元共同调度。这保证了角色不会出现部分部署的情况，这对于分布式推理工作负载的正确性至关重要。💡 注意：此特性需要针对 subGroupPolicy 支持的 Volcano v1.14+ 版本。相关内容：提案: Network Topology[4]🧩 PR: cid:link_6贡献者: @LiZhenCheng9527▍ModelServing 分区版本控制Kthena ModelServing 中的 partition 字段定义了滚动更新的边界，允许你对更新过程进行分区，以便在更新一部分 ServingGroup 的同时，让其他部分保持在旧版本。这主要用于金丝雀部署、分阶段发布以及在需要严格控制更新顺序的有状态应用中进行灰度更新。核心能力：Revision 追踪：自动追踪 ModelServing 配置的变更。分区保护：支持基于分区的更新，确保发布过程中的服务连续性。回滚：轻松回退到之前稳定的 Revision。相关内容：🧩 PR: cid:link_7cid:link_8cid:link_9贡献者: @FAUST-BENCHOU, @LiZhenCheng9527▍Router 可观测性与调试对推理 Router 的深度洞察对于诊断延迟问题和确保 SLA 合规性至关重要。新的可观测性框架和调试端口为运维人员提供了必要的工具。核心能力：调试端口：专用端口（默认 15000），用于实时查看路由表和上游健康状况。综合指标：提供详细的文档和配置，用于监控请求延迟、吞吐量和错误率。端到端测试：鲁棒的 E2E 测试框架涵盖了大多数路由场景，确保了可靠性。相关内容： 🧩PR & Issue:cid:link_10cid:link_11cid:link_2贡献者: @yashisrani, @FAUST-BENCHOU, @YaoZengzeng, @katara-Jayprakash  其他显著变化  [ModelServing] 支持 ModelServing 滚动更新中的 maxUnavailable 参数（@LiZhenCheng9527） PR: https://github.com/volcano-sh/kthena/pull/640 [ModelServing] 实现扩展插件框架（@hzxuzhonghu） PR: cid:link_13 [ModelServing] 支持 vLLM 数据并行部署和专家并行（Expert Parallel）模式[CLI] 为 PD 分离使用场景添加模板 (@huntersman） PR: cid:link_3 [Client] 使客户端 QPS 和 Burst 可配置 （@FAUST-BENCHOU） PR: cid:link_14 [Webhooks] 在 Helm chart 中默认启用 ModelServing Webhook （@VanderChen） PR: cid:link_15  [Infra] 通过 hack/local-up-kthena.sh 实现源码一键部署 （@FAUST-BENCHOU PR: cid:link_16  此外，Kthena v0.3.0 还对多项bug进行了修复，感谢 @WHOIM1205 @LiZhenCheng9527 @VanderChen @hzxuzhonghu @FAUST-BENCHOU。📌 即刻访问体验 Kthena v0.3.0: cid:link_1   贡献者  感谢所有为此次Release做出贡献的伙伴：  相关资料[1] Kthena: https://kthena.volcano.sh/[2] Volcano: https://volcano.sh/en/[3] Kthena v0.3.0: cid:link_1[4] Network Topology: cid:link_0 添加社区小助手回复“Kthena”进入技术交流群

今天，Volcano 社区[1]很高兴地宣布新的子项目 AgentCube。基于 Volcano 在大规模高性能计算调度领域多年的生产实践积累，AgentCube 将这种高并发、高吞吐的调度能力延伸至 AI 领域，构建了一套面向智能体（Agent）工作负载的 Serverless 编排层，旨在为高并发、长会话、对延迟极度敏感的智能体（Agent）工作负载提供 Serverless 化的编排与极速调度能力。  从 Kubernetes 到 Agent Native  随着大语言模型（LLM）技术的成熟，技术架构正从“无状态推理”向“自主智能体（Autonomous Agents）”演进。在这一进程中，Kubernetes 凭借其成熟的生态和对异构算力的标准化管理，已成为构建 AI 基础设施的事实标准。虽然原生 Kubernetes 提供了通用的容器编排原语以及多样化的工作负载抽象，但在面对 AI Agent 这种“高并发、短时效、强状态依赖”的新型负载时，仍存在着显著的粒度错配与机制缺位：1. 启动延迟与交互体验的矛盾： Agent 的交互通常要求毫秒级响应。然而，原生的 K8s Pod 启动流程（调度、IP 分配、镜像拉取、容器启动）往往在秒级甚至分钟级。对于需要频繁拉起 Code Interpreter（代码解释器）或临时子 Agent 的场景，这种冷启动延迟是用户无法接受的。2. 资源利用率的挑战：Agent 是典型的密集型负载。在一次会话中，90% 的时间 Agent 可能都在等待 LLM 生成 Token 或等待外部工具响应。如果在 K8s 上为每个 Agent 独占一个 Pod，会导致大量的 CPU/Memory 资源在等待期间被闲置浪费，却无法被其他任务复用。3. 会话状态管理的缺失：K8s 对“无状态（Stateless）”工作负载天然友好，但 Agent 高度依赖“上下文（Context/Memory）”。在原生 K8s 中，Pod 重启意味着内存数据丢失，开发者被迫在应用层通过外部存储重建上下文，这带来了巨大的复杂性和网络开销。4. 安全隔离难题：高级 Agent（如 Data Analyst）需要运行由 LLM 生成的不可信代码。但普通的 runC 容器如果运行 rm -rf / 具有极高风险。企业级 Agent 平台迫切需要一种既能快速启动，又能提供强隔离（如 MicroVM）的沙箱环境。为了在 Kubernetes 坚实的算力底座之上，填补上述机制空白，AgentCube 应运而生。  AgentCube 是什么？AgentCube 是一个构建在 Volcano 之上的高性能 AI Agent 编排层。它通过扩展 Kubernetes API，将 Agents 和 Tools（Code Interpreters、BrowserUse等） 提升为集群的一等公民。它不仅仅是一个 CRD，更是一套 面向 Agent 的 Serverless 操作系统。▍核心架构与抽象AgentCube 引入了两个核心的 CRD 来定义 Agent 工作负载：1. AgentRuntime: 面向长会话、复杂的对话式 Agent。支持定义会话的生命周期、资源配额以及持久化策略。2. CodeInterpreter: 面向短任务、高频的代码执行环境。强调“用完即毁”和极致的安全隔离，天然适配 MicroVM（如 Kuasar, Kata Containers, Firecracker）。AgentCube后续还将提供BrowserUse、ComputerUse、MobileUse等工作负载抽象支持。  AgentCube 关键技术亮点  为了解决上述痛点，AgentCube 在架构设计上引入了多项创新：▍1. 极速启动为了消除冷启动的挑战，AgentCube 实现了 Warm Pool（预热池） 机制。系统会预先启动并暂停一组持有基础环境的 MicroVM 沙箱。当 Agent 请求到来时，AgentCube 能够通过 "Claim-and-Go" 的方式，在毫秒级将预热的沙箱分配给会话，实现近乎零延迟的启动体验。▍2. 极速调度借助 Volcano 的 Agent Scheduler，AgentCube显著提升了Agent调度的吞吐和时延。高吞吐、低时延： 针对 Agent 突发流量，采用了乐观并发控制和精简的调度策略，大幅提升调度 TPS。统一调度支持： Volcano 的 Agent Scheduler 可以与原有的 Batch Scheduler 无缝配合，在协调 Agent 与传统的 Batch 作业潜在调度冲突的同时，确保整体集群的资源利用率和关键业务的 SLA。▍3. 原生会话管理AgentCube 引入了 Session ID 作为核心路由标识，便于保证业务上下文的连续性。请求路由： AgentCube Router 能够识别请求中的 x-agentcube-session-id，自动将其路由到对应的活跃沙箱。自动的沙箱激活： 当前会话对应的沙箱处于休眠状态时，AgentCube Router 能够自动激活沙箱。基于会话的端到端隔离： AgentCube 会自动为每个会话分配独立的沙箱环境，确保计算、内存与文件系统的完全隔离，防止跨租户的数据泄露。▍4. Serverless 化的弹性伸缩AgentCube 能够根据会话的活跃度自动管理沙箱生命周期。闲置的沙箱会被自动回收或休眠，释放物理资源供其他高优先级任务使用，真正实现资源按需分配与极致利用。  AgentCube 架构概览  AgentCube 采用了经典的控制面与数据面分离的架构设计，确保了系统的高可用性与扩展性：数据面 : 由 AgentCube Router 承载。它作为流量入口，负责鉴权、限流以及基于 Session ID 的智能路由。对于新会话，它向控制面申请资源；对于活跃会话，它直接将请求转发至对应的 Sandbox (MicroVM)。控制面 : 核心组件 Workload Manager 负责沙箱的全生命周期管理。它监控预热池 (Warm Pool) 的水位，自动补充 MicroVM 实例，并根据会话活跃度策略（如 TTL）执行沙箱的回收与垃圾清理。调度层: 集成 Volcano Agent Scheduler，通过异步并行调度和乐观锁机制，实现高并发下的毫秒级资源分配。  生态协作：共建标准化的 Agent 基础设施  作为开源中立的基础设施项目，AgentCube 旨在通过标准接口连接上下游生态，协作解决从容器编排到智能体应用落地的“最后一公里”难题。1. 南向兼容：基于标准接口的运行时适配AgentCube 坚持开放架构设计，通过深度集成 kubernetes-sigs/agent-sandbox 接口及 OCI 标准，实现对底层异构运行时的统一抽象与无感适配。运行时解耦： 支持通过 RuntimeClass 机制接入 Kuasar、Kata Containers、Firecracker 等安全容器技术，允许用户根据安全与性能需求灵活选择底层隔离方案。前沿探索： 社区正在评估 Wasm (WebAssembly) 技术，计划在未来版本中探索其在极轻量级 Agent 任务中的应用，以提供更多样化的算力供给。2. 北向集成：服务主流Agent框架在应用层，AgentCube 致力于成为 Dify、LangChain、CrewAI、LlamaIndex 等Agent框架的标准基础设施底座，相关适配工作正在快速迭代中。声明式管理： 将通过 Operator 模式提供声明式资源接口，帮助上层框架剥离底层的沙箱预热池管理与网络配置等逻辑。统一底座： 目标是实现业务编排与资源调度的解耦，使不同框架开发的应用能复用同一套云原生运维体系，降低基础设施的维护成本与碎片化程度。  灵活接入：兼顾开发与运维体验  AgentCube 设计了分层的接入接口，旨在同时满足上层业务开发者与底层平台工程师的诉求，让基础设施不再成为黑盒。1. 面向 Agent 开发者：标准 API 接入为了进一步降低接入门槛，AgentCube 提供了开箱即用的 Python SDK[2]。开发者无需深入理解 Kubernetes 的复杂概念，即可像调用本地函数一样申请、执行和释放沙箱。这使得 AgentCube 能够轻松集成到 Dify、LangChain、CrewAI、LlamaIndex 等主流框架中。📄 示例1：在agent代码中动态拉起一个CodeInterpreter并运行临时代# python from agentcube import CodeInterpreterClient # Initialize client (uses env vars for configuration) with CodeInterpreterClient() as client: # 1. Run a simple shell command print("User: whoami") print(client.execute_command("whoami")) # 2. Execute Python code code = """ import math print(f"Pi is approximately {math.pi:.4f}") """ output = client.run_code("python", code) print(f"Result: {output}")📄 示例2：通过kubectl agentcube命令行工具创建一个Agent# 1. Package an existing agent: kubectl agentcube pack -f examples/hello-agent --agent-name "my-agent" # 2. Build the container image: kubectl agentcube build -f examples/hello-agent # 3. Publish to AgentCube: kubectl agentcube publish \ -f examples/hello-agent \ --image-url "docker.io/username/my-agent" \ # 4. Invoke your agent: kubectl agentcube invoke -f examples/hello-agent --payload '{"prompt": "Hello World!"}' # 5. Check status: kubectl agentcube status -f examples/hello-agent2. 面向平台工程师：声明式 CRD 管理AgentCube 延续了云原生的声明式管理模式。运维团队可以通过 CRD (AgentRuntime, CodeInterpreter) 精细化定义资源池策略，直接复用现有的 Kubernetes 运维体系与工具链进行统一管理。📄 示例：定义一个CodeInterpreter，始终保持 10 个热备沙箱# YAML apiVersion: runtime.agentcube.volcano.sh/v1alpha1 kind: CodeInterpreter metadata: name: simple-codeinterpreter namespace: default spec: template: image: ghcr.io/volcano-sh/picod:latest sessionTimeout: "15m" maxSessionDuration: "8h" warmPoolSize: 10 # 预热水位想亲自体验？完整的安装部署文档与 Demo 示例，请访问 GitHub 仓库：cid:link_1  加入社区  AgentCube 是 Volcano 社区的一部分，遵循开源开放的原则。我们诚挚邀请对 AI Infra、Kubernetes 调度、Serverless 架构 感兴趣的开发者加入我们！GitHub: https://github.com/volcano-sh/agentcube( 欢迎Star ⭐️) Slack: CNCF Slack # volcano 频道Community Meeting: 关注  Volcano 社区双周会 [3]。让我们一起，为 AI Agent 时代构建更强大的基础设施！相关链接[1] Volcano 社区官网: https://volcano.sh/en/[2] Python SDK: cid:link_0[3] Volcano 社区双周会: https://zoom.us/j/91804791393 Volcano 是业界首个云原生批量计算引擎，也是 CNCF 首个和唯一的批量计算项目。项目主要用于 AI、大数据、基因、渲染等诸多高性能计算场景，对主流通用计算框架均有很好的支持。目前，Volcano在人工智能、大数据、基因测序等海量数据计算和分析场景已得到快速应用，已完成对 Spark、Flink、Ray、 Tensorflow、PyTorch、Argo、MindSpore、Paddlepaddle 、Kubeflow、MPI、Horovod、Mxnet、KubeGene 等众多主流计算框架的支持，并构建起完善的上下游生态。Website：https://volcano.shGitHub: cid:link_2每周例会：https://zoom.us/j/91804791393 添加社区小助手回复“Volcano”进入技术交流群

作者：Volcano Maintainers今天，我们激动地向全球开发者和 MLOps 工程师宣布，Volcano 社区迎来了一个新的子项目 Kthena！Kthena 是一个专为 Kubernetes 设计的云原生、高性能 LLM 推理路由和编排、调度系统。它旨在解决在生产环境中大规模编排、部署和服务 LLM 所面临的核心挑战，通过其独特的超节点拓扑感知的亲和性调度，KV Cache 感知的流量调度、Prefill/Decode 分离路由等高级功能，显著提升 GPU/NPU 资源利用率和吞吐，降低推理延迟，赋予企业前所未有的灵活性和控制力。作为 Volcano 的子项目，Kthena 将致力于帮助 Volcano 扩展除 AI 训练之外的边界，打造训推一体的完整解决方案。  LLM 服务化的“最后一公里”困境  大语言模型（LLM）正在以前所未有的速度重塑各行各业，但将其高效、经济地部署在生产环境中，特别是基于 Kubernetes 的云原生平台上，仍然困难重重。开发者们普遍面临以下挑战：1.  资源利用率低：LLM 推理，尤其是其独特的 KV Cache 机制，对 GPU、NPU 显存的占用是动态且巨大的。传统的负载均衡一般采用Round-Robin算法，无法感知这种负载特性，导致 GPU、NPU 资源闲置与请求排队并存，成本高昂。2.  延迟与吞吐量难以兼顾：LLM 推理分为“Prefill”（处理输入提示）和“Decode”（生成 Token）两个阶段，前者是计算密集型，后者是访存密集型。将两者混合调度，常常导致无法针对性优化，影响整体服务的响应速度和吞吐能力。因此PD分离的部署已经成为主流，但如何高效路由和调度，仍是一个难题。3.  多租户与多模型管理复杂：在企业环境中，通常需要同时提供多个不同模型、不同版本或经过 LoRA 微调的模型。如何实现请求的公平调度、优先级管理以及动态路由，是一个复杂的工程难题，业界甚至有些方案将AI网关与大模型一一对应。4.  缺乏K8s原生集成：许多现有的解决方案要么是外部系统，与 Kubernetes 生态割裂；要么过于复杂，无法满足生产级所需的简单易用性和灵活运维。  Kthena：云原生 LLM 推理的智能大脑  为了攻克上述难题，Kthena 应运而生。它并非要取代现有的 LLM 服务框架（如 vLLM, sgLang），而是作为它们上层的智能“交通枢纽”和“调度中心”，深度集成于 Kubernetes 之中。Kthena 架构图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长短、硬件紧密相关，但“按需组合、按场景选型”已被验证有效。  社区展望 / Call for Contribution  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 仓库: cid:link_1Volcano 官网: https://kthena.volcano.sh/社区（加入我们的 Slack）: https://cloud-native.slack.com/archives/C011GJDQS0N让我们一起，为 LLM 插上云原生的翅膀，释放 AI 的全部潜能！ Volcano 是业界首个云原生批量计算引擎，也是 CNCF 首个和唯一的批量计算项目。项目主要用于 AI、大数据、基因、渲染等诸多高性能计算场景，对主流通用计算框架均有很好的支持。目前，Volcano在人工智能、大数据、基因测序等海量数据计算和分析场景已得到快速应用，已完成对 Spark、Flink、Ray、 Tensorflow、PyTorch、Argo、MindSpore、Paddlepaddle 、Kubeflow、MPI、Horovod、Mxnet、KubeGene 等众多主流计算框架的支持，并构建起完善的上下游生态。 更多云原生技术动向关注容器魔方