LFX Mentorship 计划，由 Linux Foundation 组织，从19年开始为 CNCF 各个开源社区中的开发人员持续提供带薪实习和指导。往年已获20k+申请，发起2200+课题，毕业超千名实习生，发放超过390万美金报酬。2026年秋季(Term 3）申请时间为8月3日 – 8月18日（23:59 UTC)，远程实习将从 9月 7 日开始为期三个月。参与到 LFX Mentorship 计划中，为开源项目做贡献、获得开源社区的认可同时，完成工作还能获取报酬 (位于中国的开发者报酬为$3100美金，约合￥20916人民币）。 今年 KubeEdge 社区在 LFX Mentorship 计划中准备了多个课题，感兴趣的读者可于即日起前点击阅读全文，或到官方平台申请：https://mentorship.lfx.linuxfoundation.org/  KubeEdge社区介绍 KubeEdge 社区已经连续6年参与 LFX Mentorship 计划，过去已为学员提供30+个项目。KubeEdge 是业界首个云原生边缘计算框架、云原生计算基金会内部唯一毕业级边缘计算开源项目。在 GitHub 获得 8.2k+Stars和2.3k+Fork，吸引了全球来自35+国家的120+贡献组织及1800+开发者。近年来，KubeEdge 社区持续开拓创新，完成业界最大规模云原生边云协同高速公路项目（统一管理10万边缘节点/50万边缘应用）、业界首个云原生星地协同卫星、业界首个云原生车云协同汽车、业界首个云原生油田项目，开源业界首个分布式协同 AI 框架 Sedna 及业界首个边云协同终身学习范式、开源业界首个分布式协同 AI 基准测试 Ianvs。 社区地址：🌍https://github.com/kubeedge/kubeedge在 LFX Mentorship 2026秋季计划，KubeEdge 期待再次和计算机领域新生力量一起，开拓数字未来。   面向对象  秋季计划申请者需在2026年8月18日前在 LFX 官网[1]完成 Mentee 注册及项目申请。若被接收作为 Mentee，您将能在开源社区经验丰富、积极贡献的 Mentor 指导下为开源项目做出贡献。依据官方规定，对 Mentee 的申请者有以下要求[2]:计划开始时至少年满18周岁所在单位和组织不禁止该实习未参加另外的 Linux Mentorship 计划开发者以个人身份参与（在校或已毕业均可）具备所注册国家中工作权利且所注册国家未被计划禁止 (中国已获许可)并非社区中高于最低限度贡献成员（如Maintainer、Recurring Contributor）满足具体所属项目中提及的其它前置需求  课题参与方式  根据官方安排 [3]，LFX Mentorship 2026年秋季活动流程如下：Mentee 注册与项目申请：8月3日-8月18日（00:00 UTC/23:59 UTC)申请者审核期： 8月19日-9月1日（11:00 AM PDT/18:00 UTC)申请者入选通知：9月2日-9月4日实习正式开始：9月7日中期考核：10月20日（11:00 AM PDT/18:00 UTC)首次津贴支付：10月21日结项考核、实习报告提交：11月24日（11:00 AM PDT/18:00 UTC)最终津贴支付批准：11月25日本期结束最终日期：11月27日申请者需要在8月18日前完成 Mentee 注册和项目申请，流程详见 [4]：https://docs.linuxfoundation.org/lfx/mentorship/mentee-guide/how-to-apply 实习申请结果预计将在9月2日—9月4日通知到申请人。主线开发日期为2026年9月7日 – 11月24日，全程线上协作，无需线下参与。结项需要在2026年11月24日前以 PR 的形式提交到项目所在的开源社区仓库中并完成合并。  KubeEdge课题   最后，向各位申请者推荐 CNCF KubeEdge 社区下列课题：▍Modernize KubeEdge Controllers and Admission Webhooks课题描述：KubeEdge 当前的云端 Controller 与 Admission Webhook 使用了不同的实现和部署方式。Controller Manager 已经采用 controller-runtime Manager 和 Reconcile 模型，而 Admission 仍然作为独立命令、HTTP Server、Webhook 注册流程、Deployment 和 Service 运行。当前 Kubebuilder 和 controller-runtime 推荐将 Reconcile Controller 与 Admission Webhook Server 运行在同一个 Controller Manager 进程中，从而统一 Kubernetes Client、Scheme、Cache、生命周期、健康检查、Leader Election、Metrics、日志和证书管理。本项目旨在升级 KubeEdge 的 Go 和 Kubebuilder 相关技术栈，将 controller-runtime、controller-tools 与 KubeEdge 使用的 Kubernetes 版本对齐，把现有 Admission Handler 迁移到 controller-runtime Webhook 框架，并最终将 Controller 与 Admission 能力合并到统一的 Controller Manager 组件中。项目同时将引入自动化依赖漏洞检查和工具链版本管理，增强 KubeEdge 的依赖安全基线。预计输出件：梳理 KubeEdge 当前使用的 Go、Kubernetes、controller-runtime、controller-tools、代码生成、Controller Manager 和 Admission Webhook 实现。根据 KubeEdge 使用的 Kubernetes 版本确定合适的 Go、controller-runtime、controller-tools 和 Kubebuilder 兼容版本。提交设计提案，说明统一 Controller Manager 架构、迁移步骤、兼容策略、证书管理、异常处理和回退方案。   统一升级 go.mod、Builder 镜像、Dockerfile、Makefile、构建脚本、GitHub Actions 和贡献者文档中的 Go 版本。   升级 controller-runtime 及相关 Controller 开发依赖，并确保与 KubeEdge Kubernetes 依赖兼容。   根据需要，将现有 Controller 改造为当前 controller-runtime 推荐的 Reconcile 和 Manager 模式。   将 Admission Webhook Server 集成到 KubeEdge Controller Manager 进程中。将现有 Validating 和 Mutating Admission Handler 迁移为 controller-runtime Admission Handler，或者适用情况下使用 Kubebuilder 风格的 Validator 和 Defaulter。   通过同一个 controller-runtime Manager 统一注册 Controller 和 Webhook，并共享 Scheme、Client、Cache、Logger、健康检查和生命周期。   使用 controller-tools Marker 和声明式 Manifest 替代当前手工创建 WebhookConfiguration 的方式。   在完成功能一致性验证后，合并或移除独立 Admission Command、Deployment、Service、配置、RBAC 和证书处理逻辑。保持现有 Device、DeviceModel、Rule、RuleEndpoint、NodeUpgradeJob 和离线迁移等 Admission 能力。   为统一组件补充 Leader Election、Health、Readiness、Metrics、Graceful Shutdown 和 Webhook 就绪检查。   升级并统一  controller-gen、setup-envtes 和相关代码生成工具。  重新生成并验证 CRD、RBAC、WebhookConfiguration 和 API 生成代码。 为 Reconcile Controller 和 Admission Webhook 增加单元测试及基于 envtest 的集成测试。增加端到端测试，验证组件合并前后的 Controller 和 Admission 行为一致。 接入 govulncheck 等 Go 漏洞检查，并记录漏洞处理规则。   验证 AMD64 和 ARM64 构建链路，确保生成文件和 Vendor 依赖一致。   更新安装、升级、开发和故障排查文档。   发布技术博客或贡献者指南，介绍升级后的 KubeEdge Controller 架构。前置技能：Go; Kubernetes; KubeEdge; Kubebuilder; controller-runtime; controller-tools; Admission Webhook; CRD; GitHub Actions; Docker; Linux课题导师：Wei Hu (@WillardHu)wei.hu@daocloud.ioChuanhao Jin  (@chuanhao jin)jch995321@gmail.com课题链接：https://mentorship.lfx.linuxfoundation.org/project/104f564b-8f94-436b-b52e-8915ff290ef9Github Issue：cid:link_1  ▍Enable RuntimeClass and Confidential Containers on KubeEdge课题描述： Kubernetes RuntimeClass 允许工作负载选择指定的容器运行时处理器，包括标准 OCI 运行时、Kata Containers 和机密容器运行时。目前 KubeEdge 尚未为运行在边缘节点上的工作负载提供完整的 RuntimeClass 支持，因此依赖替代运行时或更强运行时隔离能力的工作负载无法正常部署到边缘节点。本项目旨在为 KubeEdge 实现端到端 RuntimeClass 支持，并结合 Kata Containers 和 Confidential Containers 生态进行验证。学员需要研究 RuntimeClass 资源如何在 KubeEdge 云边组件之间同步、缓存和使用，并确保 Edged 能够正确解析 spec.runtimeClassName，选择对应的运行时处理器。第一阶段聚焦于使用当前支持的 KubeEdge 与 Kata Containers 环境完成 RuntimeClass 验证，识别具体缺失的集成链路。基本 RuntimeClass 流程完成后，可以在具备测试环境和社区支持的情况下，进一步使用 Intel TDX 等技术验证机密工作负载，包括远程证明以及受保护的密钥或 Secret 下发。预计输出件：研究上游 Kubernetes RuntimeClass 工作流程，识别 KubeEdge 在资源同步和运行时选择方面缺失的能力。使用可复现的 KubeEdge 和 Kata Containers 环境验证当前行为。提交设计提案，说明 RuntimeClass 同步、边缘侧缓存、运行时处理器解析、兼容性和异常处理方案。完成所需代码改造，使 RuntimeClass 资源可以从 Kubernetes 控制面同步到 KubeEdge 边缘节点。支持边缘工作负载通过 spec.runtimeClassName 指定运行时。确保 Edged 能够正确选择对应的 CRI Runtime Handler。至少使用一种替代运行时完成验证，例如 Kata Containers。正确处理 RuntimeClass 不存在、配置无效或运行时处理器不可用等情况。增加单元测试和端到端测试，覆盖 RuntimeClass 同步、运行时选择、EdgeCore 重启和云边重新连接。提供可复现的部署清单、配置文件、验证脚本、架构文档和故障排查说明。发布技术博客或用户指南，介绍如何在 KubeEdge 中运行基于 RuntimeClass 的安全工作负载。可选：在 Intel TDX 或其他受支持的机密计算平台上，使用 Confidential Containers Runtime 验证机密工作负载。可选：在 RuntimeClass 和 Confidential Containers 基础集成完成后，演示一个边缘机密 AI 推理场景。前置技能：Go; Kubernetes; KubeEdge; RuntimeClass; Containerd; Container Runtime Interface; Kata Containers; Confidential Containers; Linux; Confidential Computing 课题导师：Hongbing Zhang (@HongbingZhang)hongbing.zhang@daocloud.ioShelley Bao (@Shelley-BaoYue)baoyue2@huawei.com课题链接：https://mentorship.lfx.linuxfoundation.org/project/ef5b6ae6-99be-42e0-aeae-897684b0e9c8Github Issue：cid:link_2 ▍Comprehensive Example Restoration for KubeEdge Ianvs: Phase IV (2026 Term 3)课题描述： Ianvs 充当着 KubeEdge SIG AI 分布式基准测试工具套件的角色。随着越来越多的贡献者参与其中，KubeEdge Ianvs 目前已拥有多达 30 个样例，且这数字仍在不断增长。然而由于AI类依赖包的快速演进和验证机制的复杂性，KubeEdge Ianvs 面临着日益增多的可用性问题。具体地，随着 Python 版本、第三方库及 Ianvs 功能快速迭代，部分历史样例可能变得过时。这也导致用户报告的 Issue 激增，亟需避免被未稳定贡献代码误损原有功能、修复与实际能力不再匹配的文档。若不进行系统干预，对边缘 AI 开发者、尤其是新入行者而言这些样例可能变得难以使用。因此，我们尝试通过全面的样例修复工作来强化 Ianvs 可用性。 预计输出件：诊断和修复多个样例中的错误，包括依赖关系清单、许可证扫描和运行时配置。文档更新，包括修订带有可复现步骤指南的教程，发布以开发人员为重点的常见故障调试演示手册。编写并上传相应的博客到KubeEdge网站。使用GitHub Actions针对多个Python版本、关键的 Ianvs/上游更新来完善CI管道测试示例，并阻止破坏已验证示例的PR。前置技能：Python; Benchmark; KubeEdge-Ianvs; AI/ML 课题导师：Zimu Zheng (@MooreZheng)zimu.zheng@huawei.comKai-Wei Chou (@ken6078)ken60786213@gmail.com 课题链接：https://mentorship.lfx.linuxfoundation.org/project/0a346d47-1eff-480c-990d-fa8bf6d9e24aGithub Issue：cid:link_3 ▍KubeEdge-Ianvs Simulation Sandbox: Environment-Isolated Execution课题描述：对于大多数分布式人工智能方案开发者而言，构建和部署大规模云边协作系统通常既复杂又繁琐。尽管 KubeEdge-Ianvs 目前提供了一个单节点算法测试器，可以使用测试数据集评估准确率指标，但对于大规模节点而言，在实际环境中测量带宽、计算能力和峰值内存等系统级指标却极其困难且成本高昂。此外，在单个共享的 Python 进程中执行所有测试用例很容易引发依赖冲突、路径污染以及致命的内存溢出 (OOM) 崩溃，尤其是在运行 LLM、VLA 和基础模型等高负载模型以及轻量级示例时。为了应对这些挑战，本项目旨在引入一种工业级分布式协作系统仿真方案，该方案采用单机上的工作节点嵌套模式，提供低成本、可扩展的测试能力、强大的环境隔离以及精确的系统级指标分析。预计输出件：恢复仿真核心功能：鉴于之前的提案，恢复并扩展 Ianvs 2022 仿真提案（Ianvs PR #35）及其实现（Ianvs PR #39，已发现 5 个以上缺陷），构建仿真控制器，将每个测试用例隔离在独立的瞬态运行时环境中，并强制执行系统级资源配额和边界控制机制，以限制边缘节点资源（CPU 和内存），从而避免依赖冲突和内存溢出 (OOM) 风险。关键组件包括：仿真控制器环境管理员：在测试用例控制器中引入仿真控制器，以在单台机器上提供工作节点嵌套的工作节点系统，模拟多节点系统。实现仿真环境管理员，以解析系统配置、检查主机环境要求（例如，内存 > 4GB），并自动构建、部署、关闭和删除仿真环境。仿真控制器仿真作业管理器：开发关键的仿真作业管理器，负责算法镜像构建（例如 Docker）、YAML 生成、作业部署/删除以及使用工作进程监控仿真结果列表。同时，部署一个使用临时运行时环境和系统资源配额（CPU 和内存）的隔离执行层，以彻底防止依赖冲突和内存溢出崩溃。使用多维指标验证集群：使用 kind + edgecore + Sedna 一体化脚本完成 KubeEdge 原生集群模拟验证。多维指标集成：将底层系统指标（CPU 利用率、峰值内存、实际运行时间）与上层算法指标对齐，并在现有的 StoryManager 排行榜中统一呈现，从而实现分布式 AI 的端到端综合性能评估。前置技能：KubeEdge; Kubernetes; Docker; Linux Kernel mechanisms; Go; Python; Benchmark; AI/ML; KubeEdge-Sedna; KubeEdge-Ianvs课题导师：Zimu Zheng (@MooreZheng)zimu.zheng@huawei.comShijing Hu (@hsj576)sjhu21@m.fudan.edu.cn课题链接：https://mentorship.lfx.linuxfoundation.org/project/0aca7087-4985-4d22-a7c2-b8d5845e962bGithub Issue：cid:link_4如果对课题内容有任何问题，欢迎在 GitHub 仓库提交 Issue 或者添加社区小助手微信向社区提问。今年秋季，KubeEdge 社区期待在 LFX Mentorship 见到您！Reference：[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

由 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关注容器魔方，获取更多前沿资讯

导读：将一张昇腾 NPU 按算力和显存进行细粒度切分，让空闲算力在多个模型之间弹性共享，空闲时充分利用，竞争时各得其所。本文介绍华为云云容器引擎 CCE 如何通过 FlexNPU 实现 NPU 算力共享，覆盖核心架构、调度策略、隔离机制、共享效果验证及高校教学落地实践。 ▍一、为什么需要 NPU 算力共享整卡分配与模型真实需求不匹配Kubernetes 中传统 NPU 资源通常按整卡申请。一个模型即使仅需整卡 20%～30% 的算力，也必须独占一张物理卡。两张卡均未跑满，但剩余算力难以分配给其他 Pod。对于小参数模型、开发调试、低并发在线服务及教学实验，这种资源浪费尤为突出。简单共享难以避免相互干扰若直接让多个进程共享同一张 NPU 而缺乏资源控制，当某一模型请求突增时，将占用更多执行资源，导致同卡其他模型受到干扰。此类"邻居干扰"使无约束共享方案难以满足多业务共存的诉求。Kubernetes 需要理解算力与显存传统 Device Plugin 仅告知调度器"该节点有 8 张 NPU"。在算力共享场景中，调度器还需掌握：每张卡剩余多少可保障算力每张卡还有多少可用显存当前已创建多少共享实例新实例应放置于哪张物理卡应优先集中放置还是分散放置因此，FlexNPU 不仅是节点侧的设备代理，更需要与 Kubernetes 及 Volcano 调度体系深度协同。 ▍二、CCE FlexNPU 核心方案FlexNPU 面向昇腾硬件生态设计，采用 Client-Server 架构将应用发起的 NPU API 调用与物理设备执行解耦。业务容器不再直接持有 /dev/davinciX 等物理设备，而是通过容器内的 FlexNPU Client 发起调用，由宿主机侧的 aclserver 访问真实 NPU。核心组件包括 flexnpu-device-plugin、flexnpu-runtime、flexnpu-daemon 和容器侧 flexnpu-client，各组件通过共享内存或轻量网络链路完成请求转发。▲ CCE FlexNPU 整体架构 整体调用流程如下：当前，FlexNPU 支持将一张昇腾 910B 细粒度切分为多个 NPU 共享实例，关键规格如下：指标规格算力最小切分比例1%，步长 1%显存最小分配单位128 MiB单卡最大实例数32单机最大实例数128FlexNPU 对算力并非简单的静态硬切分，而是保障下限、弹性共享——设备存在空闲算力时，业务可使用超过申请值的算力；多个业务同时繁忙时，保障每个实例获得约定的算力份额，避免过载业务影响同卡其他模型。1. Device Plugin：将 NPU 变为可声明资源flexnpu-device-plugin 负责将算力与显存抽象为两种 Kubernetes 扩展资源：资源名称含义volcano.sh/flexnpu-core.percentage算力保障比例（%）volcano.sh/flexnpu-memory.128mi显存容量，以 128 MiB 为单位资源申请示例：resources: requests: volcano.sh/flexnpu-core.percentage: "50" volcano.sh/flexnpu-memory.128mi: "300" limits: volcano.sh/flexnpu-core.percentage: "50" volcano.sh/flexnpu-memory.128mi: "300"其中 flexnpu-core.percentage: "50" 表示申请 50% 的算力保障；flexnpu-memory.128mi: "300" 表示申请 300 × 128 MiB = 37.5 GiB 显存。用户由此可根据模型真实需求精确申请资源，而非只能声明"一张 NPU"。2. Volcano 调度：算力、显存与实例数的多维约束CCE Volcano 调度器通过 flexnpuaffinity 插件参与 FlexNPU 资源放置，配置示例如下： - name: flexnpuaffinity arguments: scheduleMode: binpackCCE Volcano 插件提供 binpack 和 spread 两种调度方式：调度方式策略适用场景binpack优先填充已使用的物理卡，保留完整物理卡提升资源利用率spread将负载分散到不同物理卡或节点均衡负载、降低单卡压力以 binpack 为例，调度逻辑为：调度过程中，插件需同时校验以下约束：约束条件说明Pod 申请的算力保障 ≤ 物理卡剩余可分配算力算力维度Pod 申请的显存 ≤ 物理卡剩余显存显存维度单卡实例数 < 32实例槽位单机实例总数 < 128实例槽位设备型号 = Ascend 910B硬件兼容这是一种算力、显存与实例槽位共同参与的多维资源调度，而非简单统计物理卡数量。3. Runtime：容器启动阶段透明注入flexnpu-runtime 工作于 OCI 容器创建链路中。Pod 启动时，它将共享实例所需的运行环境注入业务容器：FlexNPU Client 动态库client.conf 等通信配置共享内存目录共享设备相关配置业务容器不直接挂载真实物理 NPU，真正持有并访问物理设备的是宿主机侧的 aclserver。此举将物理设备控制权保留在宿主机侧，降低业务容器直接操作设备、影响同卡其他实例的风险。4. Client 与 aclserver：API 调用与物理执行解耦FlexNPU Client 以动态链接库形式存在于业务容器内部。当 PyTorch、vLLM 等上层框架调用 aclInit、aclrtMalloc、aclrtMemcpy、aclrtCreateStream 等接口时，请求首先由 FlexNPU Client 接管，Client 将调用类型、参数、虚拟句柄及数据描述传递给宿主机侧的 aclserver，由后者调用真实 Ascend Runtime 完成执行。AI 框架和模型代码无需针对算力共享场景重新开发，通过动态库透明接管底层硬件 API，实现上层应用零侵入。5. 双链路通信降低代理开销FlexNPU 支持两类通信路径：链路类型协议用途TAP 链路TCP/IP实例注册、控制指令、状态交互、轻量参数传递Shared Memory 链路共享内存 (/dev/shm)高频数据交互，Client 与执行端映射同一块共享内存区域相比让大块数据反复经过 Socket 缓冲区，共享内存能够减少内核协议栈处理和进程间数据复制，显著降低代理开销。 ▍三、算力共享的关键：空闲可借，竞争有保FlexNPU 的资源策略并非将一张卡静态切分为若干互不流动的小块。假设同一张 NPU 上部署两个模型：模型 A 申请 25% 算力，模型 B 申请 75% 算力。此处的比例表达的是竞争状态下的算力保障。场景一：仅模型 A 有负载模型 B 当前无任务，卡上存在大量空闲算力。FlexNPU 不会将模型 A 限制在 25%，模型 A 可使用设备上的空闲计算能力，实际使用量最高可达当前可用的整卡算力。因此，较小的资源声明不会令单独运行的模型被限制在少量资源内。场景二：模型 A、B 同时繁忙两个模型均产生大量计算任务时，系统进入资源竞争状态：模型 A：至少获得约定的 25%模型 B：至少获得约定的 75%模型 A 即使持续过载，也无法明显侵占模型 B 的保障份额。这套策略可概括为：空闲可借、竞争归还、保障下限。与固定硬切分相比，避免了实例空闲时资源无法利用的问题；与无约束共享相比，又能在竞争时保护不同业务的算力份额。部署策略空闲资源利用率竞争时算力保障整卡独占低强静态硬切分中强无约束共享高弱FlexNPU 保障型共享高强 ▍四、显存隔离与算力共享的语义差异显存和算力是两种性质不同的资源，需区别对待。显存是容量型资源。 当一个实例申请 32768 MiB 显存时：32768 MiB ÷ 128 MiB = 256Pod 中配置为：volcano.sh/flexnpu-memory.128mi:"256"该额度约束实例可使用的显存容量上限，一个实例的异常显存申请不会侵占其他实例已分配的显存空间。算力是可共享的执行资源。 算力随负载动态流动：状态行为无竞争使用自身保障份额 + 空闲算力有竞争恢复各实例的最低保障因此，FlexNPU 同时实现了：显存容量隔离、算力下限保障、空闲算力弹性复用、同卡业务间算力隔离。 ▍五、效果验证：同卡双模型共享推理实测为验证 FlexNPU 的算力共享与隔离效果，在同一张昇腾 910B 上部署两个模型：模型算力保障显存DeepSeek-R1-Distill-Llama-8B25%32768 MiBQwen2-VL-2B-Instruct75%32768 MiB操作演示：基于华为云CCE进行同卡双模型推理延迟实测 测试方法：持续向 Qwen2-VL-2B-Instruct 发送稳定请求对 DeepSeek-R1-Distill-Llama-8B 逐步增加请求压力同时观察两个模型的端到端推理延迟测试结论：随着 DeepSeek-R1-Distill-Llama-8B 请求压力增加，其自身请求开始排队，推理延迟逐渐上升Qwen2-VL-2B-Instruct 的延迟曲线保持平稳，未随 DeepSeek 的过载同步抬升DeepSeek 的过载未明显侵占 Qwen 已获得的算力保障这表明 FlexNPU 在共享物理资源的同时维持了实例间的保障边界。当 Qwen 当前无负载时，DeepSeek 可使用卡上的空闲算力；当 Qwen 恢复请求后，系统重新保障其 75% 的约定份额。FlexNPU 由此同时实现了：低负载时空闲算力充分流动，高负载时各业务各得其所。 ▍六、高校人工智能教学落地：一台服务器支撑 128 名学生同时在线FlexNPU 已在某高校人工智能教学场景成功落地。在传统整卡模式下，每名学生的实验环境需独占一张 NPU。同时支撑 128 名学生在线开展模型推理、AI 框架实践和课程实验，所需资源为：128 名学生 ÷ 每台 8 张 910B = 16 台 8 卡服务器此方案存在明显问题：单个学生实验通常无法持续跑满整张 910B大量 NPU 在课程等待、代码编辑和低负载推理阶段处于空闲状态实验资源成本高，扩容周期长学生环境之间仍需独立管理和隔离引入 FlexNPU 后，一台配备 8 张 910B 的服务器可切分出最多 128 个 FlexNPU 实例：一名学生 → 一个独立 Pod → 一个 FlexNPU 实例 → 独立算力保障 + 独立显存额度资源规模对比：方案服务器数量可支撑学生数传统整卡独占16 台 × 8 卡 910B128 名FlexNPU 方案1 台 × 8 卡 910B128 名服务器数量降至传统方案的 1/16。教学任务具有典型的间歇性特征：编辑代码 → 等待 → 启动模型 → 短时推理 → 查看结果。并非所有学生都会在同一时刻持续占用设备。FlexNPU 在保障各学生基本算力的同时，将暂时空闲的 NPU 能力提供给正在执行实验的实例，契合教学负载的真实使用规律。同时，每个学生的实验运行于独立 Pod 和共享实例中：显存额度相互隔离算力竞争时有最低保障单个学生任务异常或过载不会无限挤占其他学生的算力教师可通过 Kubernetes 统一创建、回收和管理实验环境对于高校而言，此模式不仅降低了硬件投入，也使课程资源能够按班级规模快速交付，提升实验环境的可管理性和并发能力。 ▍七、典型适用场景场景说明多小模型同卡部署不同模型分别申请所需显存和算力保障，通过 binpack 集中到同一张卡，释放更多完整 NPU在线业务与低优先级任务混部在线服务获得明确算力保障，离线任务使用设备空闲能力；低优先级任务过载时不明显影响在线服务性能AI 开发和测试环境为开发者按需分配小规格共享 NPU，避免调试任务长期占用整卡 ▍八、总结传统整卡分配模式难以适应小模型推理、开发测试、人工智能教学等细粒度资源需求；无约束共享虽可提高利用率，却易产生相互干扰。华为云 CCE FlexNPU 将算力共享、显存隔离与云原生调度统一于同一套体系，其核心价值在于：细粒度切分：算力最小支持 1%，显存以 128 MiB 为单位弹性共享：无竞争时，实例可使用更多空闲算力算力保障：资源竞争时，保障各实例的算力份额显存隔离：防止实例越界占用其他业务的显存云原生调度：通过 Device Plugin 与 Volcano 实现声明式申请与自动放置透明接入：Client-Server 架构，上层模型代码无需修改规模化交付：单卡最多 32 个实例，单机最多 128 个实例在某高校人工智能教学项目中，一台 8 卡 910B 服务器通过 FlexNPU 支撑了 128 名学生同时在线，而传统整卡方案实现相同规模需 16 台 8 卡服务器。FlexNPU 的价值不仅在于将一张物理卡切分为更多实例，更在于：让多个业务共享同一张 NPU 时，空闲算力能够充分流动，资源竞争时又能守住各自的算力份额。 参考资料[1] 华为云 CCE 官方文档: cid:link_0[2] Volcano 调度器项目主页: https://volcano.sh/关注魔方公众号，获取更多前沿资讯

Kthena[1] 是面向高扩展性模型推理的云原生 AI 服务平台。它依托 Volcano[2]在集群拓扑感知与大规模算力调度的优势，结合 KV Cache 感知路由与 Prefill/Decode 分离等高级特性，显著提升 GPU/NPU 资源利用率与系统吞吐，实现算力与时延的极限优化，高效解决生产环境中 LLM 大规模部署与服务的核心挑战，全面释放模型推理与服务的算力潜能。Kthena v1.0.0 现已正式发布。这是 Kthena 在 Kubernetes 原生大模型推理领域迈出的重要一步。本次发布全面聚焦生产就绪能力：提升 Gateway API 路由准确性；为预填充/解码（P/D）分离工作负载提供原生的角色级自动扩缩容，大幅提升资源利用率；提供更安全的角色级滚动更新，保障服务发布零中断；增强Router调度性能；能为多轮对话进行会话加速；通过 Prometheus 指标和示例仪表盘提供更丰富的缓存感知路由可观测性；进一步完善 CLI 使用体验。同时，Kthena v1.0.0 对 autoscaler API 进行了重要整合，正式移除AutoscalingPolicyBinding ，目标配置现在通过 homogeneousTarget、heterogeneousTarget 和 disaggregatedTarget 直接定义在 AutoscalingPolicy 中，带来更纯粹易用的一站式声明配置。  Kthena v1.0.0 版本亮点 ▍核心特性概览AutoscalingPolicy 整合与 P/D 协同式分离扩缩容： 移除 AutoscalingPolicyBinding，将自动扩缩容目标配置统一整合到 AutoscalingPolicy 中；新增的 disaggregatedTarget 支持Perfill/Decode工作负载的角色级协同扩缩容。每个角色均可根据自身指标独立扩缩容，同时通过比例约束，将 P/D 副本比例维持在合理范围内。面向多轮对话的会话加速： Router可以优先处理近期已完成会话的后续请求，从而在高并发对话场景下提高 KV-Cache的命中率。路由调度与可观测性增强： 通过 Pod 级在途请求跟踪、基于 Redis 的多Router状态同步、可配置的 Pod 指标抓取，以及缓存感知 Prometheus 指标，提高调度准确性和运维可观测性。角色级滚动更新可用性控制： 进一步增强 RoleRollingUpdate，现在每个角色都可以通过 maxUnavailable 独立控制升级节奏。Gateway API 与 HTTPRoute 行为修正： Kthena Router现在能够遵循 HTTPRoute 主机名配置，在后端选择和 URL 重写过程中始终使用同一条已匹配的路由规则，并修正 PathPrefix 语义，同时遵循 Gateway 监听器的 allowedRoutes 配置。CLI 与 OpenAI 兼容 API 增强： CLI 提供更丰富的状态信息，并新增对 ModelRoute 和 ModelServer 的支持；Router 新增兼容 OpenAI API 的接口。▍AutoscalingPolicy 整合与 P/D 协同式分离扩缩容Kthena v1.0.0 引入了一套更简洁、更强大的自动扩缩容 API。用户现在可以在单个 AutoscalingPolicy 资源中统一配置扩缩容目标、指标采集方式和扩缩容边界。新的 disaggregatedTarget 模式专为基于Role的工作负载部署提供 P/D 协同自动扩缩容，尤其适用于PD分离部署。Prefill和Decode可以分别依据自身指标作出扩缩容决策，同时由自动扩缩容器应用共享约束，使两侧能够协调扩缩，而不会各自变化并逐渐偏离合理比例。每个角色都可以独立定义副本范围、指标和指标来源；运维人员还可以配置 ratioConstraint，将 P/D 副本比例维持在合理区间内。disaggregatedTarget 配置示例：spec:  disaggregatedTarget:    targetRef:      apiVersion: workload.serving.volcano.sh/v1alpha1      kind: ModelServing      name: vllm-qwen-pd-ms    roles:      prefill:        minReplicas: 1        maxReplicas: 8        metrics:          - name: prefill_waiting_requests            targetValue: "1"        metricSources:          prefill_waiting_requests:            prometheus:              serverURL: http://kube-prometheus-stack-prometheus.test.svc.cluster.local:9090              query: sum(vllm:num_requests_waiting{namespace="autoscale-demo", service="vllm-prefill"})      decode:        minReplicas: 1        maxReplicas: 16        metrics:          - name: decode_gpu_cache_usage            targetValue: "0.75"        metricSources:          decode_gpu_cache_usage:            prometheus:              serverURL: http://kube-prometheus-stack-prometheus.test.svc.cluster.local:9090              query: sum(vllm:gpu_cache_usage_perc{namespace="autoscale-demo", service="vllm-decode"})    ratioConstraint:      numeratorRole: prefill      denominatorRole: decode      minRatio: "0.25"      maxRatio: "1"相关变更：Issue： Proposal of merge autoscalingPolicybingding into autoscalingPolicy  #1172[3]PR：merge autoscalingpolicybinding to autoscalingpolicy #1203[4]Implementation of PD disaggregation auto-scaler #1258[5]贡献者：@LiZhenCheng9527 ▍面向多轮对话工作负载的会话加速Kthena v1.0.0 新增会话加速能力，旨在优化多轮对话、智能体工作流和 RAG 链等后续请求依赖先前响应的场景。在这些工作负载中，后续请求通常会复用较长的公共前缀。如果请求在无关流量之后等待过久，对应后端中的 KV-Cache 可能已被淘汰，进而增加 TTFT。会话加速允许 Router 跟踪近期完成的会话，并在等待队列中优先处理这些会话的后续请求。使用会话加速功能，相较于 llm-d router default 延迟能够降低 20%。该机制与用户公平性调度相互独立，并提供专用的会话加速配置，包括会话请求头选择、等待请求准入上限，以及用于高级缓存命中优化的可选宽限期。此功能旨在提高并发多轮请求下的缓存复用机会，但本身并不进行 KV-Cache 感知调度。若要最大限度发挥 KV-Cache 优势，运维人员还应确保同时使用会话加速和 KV-Cache 感知调度。Helm 配置示例：networking:  kthenaRouter:    sessionBoost:      enabled: true      header: X-Session-ID      maxSessions: 4096      inflightPerPod: 16      gracePeriod: 0s相关变更：Issue：Improve multi-round conversation case #1190[6]PR：session boost queue to optimize multi conversation scenario #1183[7]贡献者：@YaoZengzeng、@hzxuzhonghu、@FAUST-BENCHOU、@LiZhenCheng9527 ▍更智能的路由调度与缓存感知可观测性Router现在可以更好的利用的负载信号进行调度决策。Kthena 能够跟踪每个 Pod 的排队的请求数量，并通过 Redis 在多个Router副本之间同步这些计数器，使 least-request 插件能够依据实时全局负载作出决策，而不再局限于当前Router的本地状态。缓存感知调度的可观测性也得到了显著增强。prefix-cache 和 kvcache-aware 评分插件现在通过Router现有的 /metrics 端点导出 Prometheus 指标，将以往仅记录在 klog 中的信息转化为可查询、带模型标签的时间序列，便于开展压力测试和进行请求调度。为准确衡量缓存效果，Kthena 使用匹配比例直方图取代简单的命中/未命中计数器。kthena_router_prefix_cache_match_ratio 和 kthena_router_kvcache_aware_match_ratio 用于表示提示词中已存在于最佳匹配候选 Pod 上的数据块占比，其中 0 表示完全未命中。运维人员既可以通过 le="0.0" 桶推导缓存命中率，也可以直观了解Cache的实际复用程度。相关变更：Issue：Observability for prefix-cache and kvcache-aware Score Plugins[8]PR：feat(router): add per-pod in-flight request tracking with Redis sync #962[9]Add SGLang tokenizer support for KV-cache-aware scheduling #997[10]router: add observability metrics for prefix-cache and kvcache-aware score plugins #1194[11]feat(router): make pod metrics update interval configurable #1151[12]perf(router): cache parsed prompt to avoid redundant ParsePrompt call #1123[13]fix: parallelize pod metrics scraping loop with bounded concurrency #1255[14]贡献者：@hzxuzhonghu、@blenbot、@kube-gopher、@rajnish-jais、@nabrahma ▍角色级滚动更新可用性控制Kthena v0.4.0 引入了 RoleRollingUpdate，但在角色更新期间，系统会一次性删除 ServingGroup 中某个角色的全部旧副本。只有一个 servingGroup 的时候，会导致服务在角色级发布期间暂时不可用。Kthena v1.0.0 为 RoleRollingUpdate 新增角色级 maxUnavailable 支持。运维人员现在可以使用绝对数量或百分比，为每个角色独立控制更新步长。角色级滚动更新由此具备与 ServingGroup 级更新类似的可用性控制能力。角色级发布配置示例：spec:  rolloutStrategy:    type: RoleRollingUpdate  template:    roles:    - name: prefill      replicas: 2      maxUnavailable: 1      # entryTemplate and workerTemplate omitted    - name: decode      replicas: 4      maxUnavailable: 25%      # entryTemplate and workerTemplate omitted相关变更：Issue：Control the number of unavailable Role replicas in RoleRollingUpdate #1188[15]PR：Role rollingupdate support maxUnavailable settings #1239[16]贡献者：@hzxuzhonghu、@LiZhenCheng9527 ▍Gateway API 与 HTTPRoute 行为修正Kthena Router现在能够更准确地处理 Gateway API 流量。Router会遵循 HTTPRoute.spec.hostnames，在后端选择和 URL 重写过滤器处理过程中始终使用同一条已匹配的 HTTPRoute 规则，并在同一路由内优先选择更具体的路径规则。由此可以避免请求误用其他链路中的后端。本次发布还修正了 Gateway API 的 PathPrefix 匹配语义，并确保Router仅在满足 Gateway 监听器 allowedRoutes 约束时接纳 HTTPRoute。相关变更：PR：feat: honor HTTPRoute hostnames and matched rule selection #1174[17]Fix HTTPRoute PathPrefix matching #1119[18]fix(router): respect Gateway allowedRoutes #1263[19]贡献者：@zhy76、@Monti-27、@avinxshKD ▍CLI 与 OpenAI 兼容 API 增强Kthena CLI 现在能够展示更实用的状态信息，并支持更多资源类型：kthena get model-servings 新增 READY 和 STATUS 列。kthena get model-boosters 新增 STATUS 列。新增对 kthena get model-routes 和 kthena get model-servers 的支持。新增对 kthena describe model-route 和 kthena describe model-server 的支持。Router还新增了兼容 OpenAI API 的 GET /v1/models 端点，以标准列表响应格式返回当前可用的模型名称。相关变更：PR：feat: add STATUS and READY columns to kthena get output #978[20]feat: add CLI support for ModelRoute and ModelServer resources #981[21]feat: support /v1/models endpoint  #996[22]贡献者：@anirudh240、@madmecodes ▍其他功能增强通过设置 scale 子资源标签选择器，为 ModelServing 新增 KEDA/HPA 兼容能力。#839为 controller-manager 新增调试端口，可用于查看缓存中的 ServingGroup 和 Role 配置。#900新增 SGLang Dynamo 模拟器测试覆盖与 SGLang 推理模拟器集成。#920、#1231为Router新增 pprof 端点支持。#1057在 Helm Chart 中新增 controller-manager 的 debugPort 配置。#1032改进 ModelBooster 的 GPU 与离线环境支持。#972、#1141、#1146、#945新增 GPU 使用率插件 E2E 测试覆盖。#1199更新快速入门文档，并推荐用户优先从 ModelServing 开始使用 Kthena。#1260新增 DeepSeek-v4 模型服务示例。#936、#937新增 KV 缓存感知调度器插件文档。#910更加具体版本信息可以查看 Kthena v1.0.0 的 Release Note：cid:link_1Kthena 诚挚邀请广大开发者、运维人员和 AI 基础设施团队体验 Kthena v1.0.0，并与我们共同塑造下一代云原生大模型推理平台。 相关链接[1] Kthena v1.0.0: https://kthena.volcano.sh/[2] Volcano: https://volcano.sh/[3] Proposal of merge autoscalingPolicybingding into autoscalingPolicy #1172: cid:link_4[4] merge autoscalingpolicybinding to autoscalingpolicy #1203: cid:link_5[5] Implementation of PD disaggregation auto-scaler #1258: cid:link_6[6] Improve multi-round conversation case #1190: cid:link_2[7] session boost queue to optimize multi conversation scenario #1183: cid:link_7[8] Observability for prefix-cache and kvcache-aware Score Plugins: cid:link_0[9] feat(router): add per-pod in-flight request tracking with Redis sync #962: cid:link_16[10] Add SGLang tokenizer support for KV-cache-aware scheduling #997: cid:link_17[11] router: add observability metrics for prefix-cache and kvcache-aware score plugins #1194: cid:link_8[12] feat(router): make pod metrics update interval configurable #1151: cid:link_9[13] perf(router): cache parsed prompt to avoid redundant ParsePrompt call #1123: cid:link_10[14] fix: parallelize pod metrics scraping loop with bounded concurrency #1255: cid:link_11[15] Control the number of unavailable Role replicas in RoleRollingUpdate #1188: cid:link_3[16] Role rollingupdate support maxUnavailable settings #1239: cid:link_12[17] feat: honor HTTPRoute hostnames and matched rule selection #1174: cid:link_13[18] Fix HTTPRoute PathPrefix matching #1119: cid:link_14[19] fix(router): respect Gateway allowedRoutes #1263: cid:link_15[20] feat: add STATUS and READY columns to kthena get output #978: cid:link_18[21] feat: add CLI support for ModelRoute and ModelServer resources #981: cid:link_19[22] feat: support /v1/models endpoint #996: cid:link_20 关注魔方公众号，获取更多前沿资讯添加社区小助手k8s2222，进入“Kthena” 技术交流群

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/v1alpha1kind: ModelRoutemetadata:  name: deepseek-v4  namespace: defaultspec:  modelName: "deepseek_v4"  rules:  - name: "default"    targetModels:    - modelServerName: "deepseekv4-pd"---apiVersion: networking.serving.volcano.sh/v1alpha1kind: ModelServermetadata:  name: deepseekv4-pd  namespace: defaultspec:  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: mooncakeEOF3. 验证部署与测试完成上述三个 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_2欢迎Star★，Fork，来 Kthena 社区一起玩转LLM推理！ 关注魔方公众号，获取更多前沿资讯添加社区小助手k8s2222，进入Kthena技术交流群

随着大模型向长上下文（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，进入技术交流群

在云原生时代，Kubernetes集群的运维复杂度正在以指数级增长。Pod频繁重启、节点异常、告警风暴、容量风险……每一类问题背后，都涉及Pod、节点、事件、日志等多层资源的交叉关联，人工定位链路长，判断成本极高。华为云云原生Skills的诞生，正是为了解决这一困境——将专业知识、操作流程和最佳实践转化为可复用的能力单元，让AI Agent具备专业的云原生运维能力。 什么是云原生Skills？Skill是将专业知识、操作流程和最佳实践转化为可复用能力单元的开放范式。在AI Agent体系中，Skill使Agent能够按照预定义的流程和规则，自动执行特定领域的复杂任务。华为云云原生Skills承接该范式，将专家经验沉淀为Agent可调用的能力模块，为企业的云原生运维提供了一条从传统人工排障向 Agentic Ops 演进的新路径，既支持在现有运维体系中嵌入AI提效，也支持为关键业务构建Agent原生的诊断与恢复模式：全栈可观测覆盖：云原生Skills整合CCE、AOM、LTS、ELB、ECS、HSS等云服务的运维能力，可自动汇聚告警、日志、K8s事件、Pod/Node指标形成诊断上下文，覆盖故障诊断、可观测分析、巡检治理、自动恢复等场景。意图驱动的智能诊断：Agent通过读取Skill的description自动理解触发时机，用户只需用自然语言描述故障现象，无需显式指定Skill。Agent即可完成从现象识别、证据采集、根因分析到恢复方案的全流程诊断。场景化编排与闭环：单个Skill内部串联多个操作步骤，自动完成上下文收集、分析和结论输出，一站式闭环。多个Skill可按工作流组合使用，Agent根据任务需要自动选择和调用合适的Skill组合。Agent友好与安全可控：Skill以独立目录提供，可在Web、CLI、API等不同Agent平台上运行，无需为每个平台单独适配。内置风险分级机制与安全护栏，所有删除、扩缩容、drain等变更类操作必须先预览、再经用户确认后方可执行。 从故障诊断到主动治理：典型应用场景全覆盖华为云云原生Skills覆盖了云原生运维的全链路场景：故障诊断：Pod CrashLoopBackOff、节点NotReady、Ingress 502、PVC Pending等常见故障分析。可观测分析：汇聚AOM告警、LTS日志、K8s事件、Pod/Node指标形成诊断上下文。巡检治理：每日集群健康检查、容量趋势预测、成本优化建议、可用性风险扫描。自动恢复：扩缩容、cordon/drain节点、重启ECS、HSS漏洞修复等受控变更。交付方案：容器迁移规划、资源盘点、依赖矩阵分析。集群管理：CCE集群升级规划、工作负载管理、UCS集群纳管与策略治理。 让智能运维落地有声：最佳实践华为云提供了丰富的最佳实践，帮助用户快速上手： ▍实践一：使用AI CLI对CCE工作负载进行故障诊断与恢复  基于用户描述的故障现象（如Pod长时间未就绪、容器频繁重启、镜像拉取失败等），AI Agent自动完成上下文识别、证据采集、根因分析、恢复方案预览、用户确认、恢复执行和结果验证的全流程。 ▍实践二：配置、查询和治理CCE AOM告警 用户用自然语言完成CCE AOM告警规则配置、查询、聚合分析和严重告警根因追查。 AI CLI会自动归并同类告警，帮助用户快速判断“哪些告警最紧急、影响哪些资源、下一步应该查什么”。 ▍实践三：集群定期巡检 通过OpenClaw Agent用自然语言配置周期性巡检任务，自动完成集群健康检查、告警聚合、异常分析、风险分级、报告生成和通知推送。巡检过程只执行只读查询，不会自动执行任何变更动作。 ▍实践四：配置CCE集群秒级弹性至CCI 2.0通过提示词即可自动完成集群预检、插件安装及网络配置，采用预览确认机制，用户确认后执行，支持短时高负载场景下的秒级弹性伸缩。 ▍实践五：ChatOps智能运维 基于Hermes构建生产环境智能运维Agent ，定时扫描现网告警，自动归并分析，生成恢复方案，在手机端确认后执行恢复动作。将“告警发现→归并→上下文采集→根因分析→恢复预览→用户确认→执行恢复→效果验证→结果归档”沉淀为可复用的ChatOps值班能力。 让运维经验可传承、可进化华为云云原生Skill当前已上线云容器引擎CCE服务官网，用户可在各类Agent客户端中安装调用。它将华为云在云原生领域积累的诊断经验与运维最佳实践，封装为开放的能力单元，让企业无需从零构建，即可获得开箱即用的智能运维能力——从诊断到恢复，对话即完成。让AI读懂云原生，让运维回归创造性工作——这正是华为云云原生Skills的使命所在。 立即体验：cid:link_1  

Karmada 是开放的多云多集群容器编排引擎，旨在帮助用户在多云环境下部署和运维业务应用。凭借兼容 Kubernetes 原生 API 的能力，Karmada 可以平滑迁移单集群工作负载，并且仍可保持与 Kubernetes 周边生态工具链协同。Karmada v1.18[1] 版本现已发布，本版本包含下列新增特性：支持混合云场景下的溢出式集群亲和调度引入调度超分保护机制这些更新进一步增强了 Karmada 在混合云和大规模调度场景中的可用性与灵活性。我们鼓励您升级[2] 到 v1.18.0，体验这些新能力带来的价值。  新特性概览  支持混合云场景下的溢出式集群亲和调度在混合云环境中，企业通常会将本地数据中心作为主要资源池，把公有云作为峰值流量到来时的弹性补充资源。此前，Karmada 的 ClusterAffinities 已经支持声明多个候选集群组，但这些集群组在一次调度过程中是互斥的：调度器最终只会选择其中一个集群组，无法在首选资源池容量不足时，将剩余副本继续扩展到补充资源池。Karmada v1.18 引入了引入了Overflow Cluster Affinities 能力，在 ClusterAffinityTerm 中新增 overflowAffinities 字段，用于声明按优先级排列的补充集群组。调度器会优先填满主集群组；当主集群组资源耗尽后，再按声明顺序逐级向补充集群组溢出副本，从而实现“优先使用 IDC，容量不足时再溢出到云”的混合云调度模式。这项能力主要带来以下价值：渐进式溢出：用户可以在同一个 ClusterAffinityTerm 中声明多个补充集群组，调度器会按照顺序逐级扩展调度范围。反向收缩：在缩容场景下，副本会优先从补充集群组回收，从而尽量保留主资源池中的稳定负载。成本优化：让基线工作负载稳定运行在成本更优的本地集群上，只在确有需要时才使用公有云资源承接突发流量。这一能力特别适用于如下场景：弹性 GPU 调度：本地 IDC GPU 集群承载日常推理流量，云上 GPU 集群仅用于承接峰值负载。成本控制：将常态业务留在本地基础设施，借助公有云弹性处理流量波峰。容量规划：用清晰的优先级关系定义资源池使用顺序，减少人工干预。效果图如下:下面是一个精简示例，优先将工作负载调度到 IDC GPU 集群，不足时再溢出到云上 GPU 集群：apiVersion: policy.karmada.io/v1alpha1 kind: PropagationPolicy metadata: name: gpu-inference-overflow spec: resourceSelectors: - apiVersion: apps/v1 kind: Deployment placement: clusterAffinities: - affinityName: idc-gpu clusterNames: - idc-gpu-cluster1 overflowAffinities: - affinityName: cloud-gpu clusterNames: - cloud-gpu-cluster1 - cloud-gpu-cluster2 replicaScheduling: replicaSchedulingType: Divided replicaDivisionPreference: Weighted weightPreference: dynamicWeight: AvailableReplicas更多有关此功能的资料请参考：官方特性文档[3] 和 特性提案[4]。引入调度超分保护机制在大规模多集群环境中，调度器虽然按顺序处理调度请求，但在决定某个集群是否还有可用容量时，需要依赖 karmada-scheduler-estimator 提供的集群容量估算结果。问题在于：调度器刚刚完成一次副本分配后，新的工作负载真正下发到成员集群、创建 Pod 并绑定到节点之间，存在天然的时间窗口。如果在这个窗口内又到来新的调度请求，scheduler-estimator 看到的仍然可能是“旧的容量快照”，从而导致多个连续调度决策重复使用同一份尚未更新的空闲资源，造成资源超卖。最终结果就是：调度阶段看起来成功，但工作负载落地后可能因为资源不足长期 Pending。为了解决这一问题，Karmada v1.18 引入了 Scheduling Overcommit Protection（调度超分保护）。该特性在调度器和估算器之间引入“assume and deduct（先假定、再扣减）”机制：调度器在完成一次调度决策后，会先假定这部分资源已经被占用估算器在后续容量计算时，会把这部分“假定占用”的资源一起考虑进去从而避免后续调度在真实状态尚未更新前重复消耗同一批资源这一特性尤其适用于高吞吐量调度场景，可以显著降低由于状态延迟带来的资源超卖问题，让副本分配结果更贴近成员集群的真实承载能力。当前该特性是 Alpha 特性，默认关闭，并且需要同时在 karmada-scheduler 和 karmada-scheduler-estimator 上启用：--feature-gates=SchedulingOvercommitProtection=true需要注意的是，该特性只对 ReplicaSchedulingType: Divided 且采用容量感知分配策略的场景生效，例如 Aggregated 或 DynamicWeight。对于 Duplicated 模式以及完全静态权重分配的场景，不会产生影响。更多有关此功能的资料请参考：官方特性文档[5]和 调度超分保护[6]。  致谢贡献者  Karmada v1.18 版本包含了来自 31 位贡献者的 144 次代码提交，在此对各位贡献者表示由衷的感谢： 参考资料[1] Karmada v1.18 release: cid:link_3[2] Karmada v1.18 发行说明: cid:link_2[3] 溢出式集群亲和调度特性官方文档: https://karmada.io/docs/userguide/scheduling/propagation-policy#how-overflowaffinities-works[4] 溢出式集群亲和调度提案: cid:link_0[5] 调度超分保护特性官方文档: https://karmada.io/zh/docs/userguide/scheduling/scheduling-overcommit-protection[6] 调度超分保护提案: cid:link_1  关注魔方公众号，获取更多前沿资讯添加社区小助手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 正从概念走向生产。与传统的批处理任务或推理服务不同，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，进入技术交流群

6月5日，2026华为云INSPIRE创想者大会Agentic Infra云基础设施技术论坛在上海圆满落幕。此次论坛以“进化，从AI Infra到Agentic Infra”为主题，汇聚顶尖技术专家、行业精英与生态伙伴，共同探讨Agentic时代AI基础设施的架构设计、技术创新与演进方向。会上，华为云重磅解读“Agentic Infra”技术新范式——“Agentic计算机”，以四大突破极致重构AI算力底座，为中国企业Agent创新发展持续注入强劲动能！▍云计算跨入Token工业时代，基础设施面临范式跃迁▲华为云基础设施云服务产品线总裁鲍亮“Agentic AI时代正在引发计算范式的一系列根本性跃迁。”华为云基础设施云服务产品线总裁鲍亮在致辞中表示，云计算已跨入Token工业时代。因此，华为云提出Agentic Infra新范式，核心是构建“高效Token工厂+通智一体化调度+持续学习+安全自治”四大能力，具体通过灵衢智算集群AICS打造极致效能Token工厂、以存代算提供PB级记忆空间打破Agent记忆瓶颈、AgentSphere提供高性能安全部署运行时、以及Volcano实现通智一体化调度，通过持续做强根技术，与AI智能化的技术深度融合，为千行百业提供最优的Agentic基础设施底座！▍软硬芯深度协同，华为云重磅解读“Agentic计算机”▲华为公司Fellow、云系统首席专家余洲“在Agent时代，云基础设施就是‘Agentic计算机’”华为公司Fellow、云系统首席专家余洲指出，“Agentic计算机”与传统云基础设施相比，其核心变化在于服务对象从人转向AI、面向每天万亿级Token的处理进行整体优化等方面。为此，华为云基于软硬芯协同，以“Agentic计算机”为核心概念，构建了高效的Agentic Infra，并实现四大突破。一是灵衢网络实现多资源一体化，把分散在数百个机柜中的CPU、NPU、SSD和内存互联起来，使它们能够像同一台计算机里的设备一样协同工作；二是超节点规模和带宽持续演进。基于昇腾950，华为云发布1024卡的灵衢智能计算集群（AICS），让算力提升2.6倍；基于灵衢总线和弹性统一内存池，突破了大模型推理的内存墙瓶颈，更灵活地支持万亿参数模型训推；三是推出记忆存储解决方案AMS。依托NPU直通CMS硬件（上下文记忆存储），为Agent提供PB级超大记忆空间，支持KV Cache分层池化，将缓存命中率提升至95%，成本节省高达63%。最后是提供高性能极简网络，实现算力资源和网络IO资源的灵活配比，以及多网合一。基于以上四大核心突破，Agentic计算机能够充分满足更高的推理效率、更长的序列和更快的推理速度的需求。▲华为公司Fellow、华为云服务首席架构师顾炯炯华为公司Fellow、华为云服务首席架构师顾炯炯指出，Agentic AI云基础设施面临小模型单卡吃不满、大模型推理PD分离资源偏科、潮汐效应等因素导致的算力资源利用率低、万卡训练集群故障爆炸半径大等核心困境，传统软硬耦合架构已无法应对。华为云为此推出FlexNPU柔性液态算力创新架构，在业界主流训练和推理框架与昇腾NPU硬件算力层之间引入一层“软件定义调度与虚拟化”软件，实现了多模型及PD推理共卡的算子级的细粒度时空复用，硬件故障隔离以及基于透明快照的极速Serverless弹性，FlexNPU由此带来三重突破：更高效，更敏捷，零宕机，能够大幅降低大模型推理单位Token小模型算力性价比，同时将节点级弹性及硬件故障恢复时间从分钟级降至秒级，从而让用户的每一分算力投入物尽其用，让每一笔Token的支出，不再为空闲算力买单。▍面向Agent时代，通智融合增强智能基础设施▲云原生计算基金会（CNCF）中国区总监陈泽辉云原生计算基金会（CNCF）中国区总监陈泽辉现场分享了一个趋势：CNCF技术栈从云原生平台底座，到今天作为Agentic时代的引擎发展迅速。Kubernetes已经成为标准的AI操作系统，82%的受访企业在生产环境中使用K8s。目前企业优先部署Agentic AI的比例高达74%。从云原生到AI Native，再到现在的Agentic Infra，以Volcano为代表的调度编排成为决胜关键——Agentic不再是工具，而是真正的资源概念。▲CNCF TOC副主席、华为云云原生开源负责人王泽锋CNCF TOC副主席、华为云云原生开源负责人王泽锋表示，Volcano从设计之初就针对训练和推理的工作负载做深层次优化，现在演进到全新的多调度器免锁并行架构：面向Agentic工作负载，采用极简的沙箱调度策略，调度耗时相比原来下降99%；而传统训推工作负载保持采用批量调度策略，在与Agentic调度一致无冲突情况下，仍可获得最优调度结果。在运行时层面，AgentCube + Kuasar的组合实现了端到端冷启动控制在50毫秒以内的突破。此外，Kthena引入更多智能化算法做路由感知，相关能力将在630版本发布，并在Kthena 1.0版本达到正式可商用级别。▍产学研用深度融合，共筑国产Agent基础设施护城河先进架构还需在真实业务场景千锤百炼。论坛现场，行业领军代表分享了与华为云合作的实战成果。▲香港科技大学助理教授、AReaL开源社区负责人袁彬航香港科技大学助理教授、AReaL开源社区负责人袁彬航分享了基于AReaL构建asearcher，训练能够自动使用搜索引擎、通过多轮迭代回答问题的智能体。AReaL不仅在华为云上完成适配，华为云还帮助其在NPU上适配算子和参数传输模块，并完善两个在云原生场景、真实多任务RL训练中非常重要的功能——On-policy蒸馏进最终交付版本以及LoRA适配。未来AReaL2.0将面向智能体开发，提供自适应的演化基座，实现智能体轨迹数据协议、数据代理和动态进化RL模块的完整支持。▲小红书大模型基建部RL引擎负责人杨睿在互联网应用侧，小红书大模型基建部RL引擎负责人杨睿介绍了小红书内部的全异步框架Relax。这是基于全模态统一、生产级框架等三大支柱设计，并通过华为云完成昇腾生态的适配；通过Transfer Queue实现训推解耦，分布式Checkpoint服务保证权重同步耗时占比在5%以内，同时针对多模态训练优化了图片计算复用与混合并行策略。目前，Relax在多模态、全异步实践、Hybrid混合部署以及Agentic RL上已经深度沉淀，未来还将支持潮汐资源下的弹性扩缩。▲面壁智能端侧智能业务总经理周树峰针对端侧部署的需求，面壁智能端侧智能业务总经理周树峰表示，面壁智能从两年前转向端侧和边缘侧，探索在相对小的参数量级上实现对标大尺寸模型的能力，核心是提升智能密度、降低训练与推理开销。2024年9月，面壁智能4B模型已达到3.5水平，随后发布的1.3B超小尺寸模型更是越级挑战。今年，面壁智能将三值量化技术搬到华为昇腾卡上完成训练和推理验证，使模型在保持精度的同时大幅提升速度，已应用于手机、汽车等行业。▲芒果AIGC创新制作中心主任李俊俊在行业应用领域，芒果TV AI产业化中心和智能研究中心副总经理 李俊俊介绍，AI在内容制作上经历了三个阶段：从辅助决策到与创作者实时共创，再到AI成为基础设施。目前，芒果TV推出芒果灵创AIGC创作平台，聚合全域模型，主打可控生成，其中视频模型在进行昇腾适配，它不是抽卡式的生成，而是从内容土壤里长出来的、支持团队协作与成本可控的开放生态，让AI从功能变成了伙伴。面对Agentic时代万亿Token级的复杂任务，传统“堆卡”模式已成过去，取而代之的是一台以Token为粒度、以AI操作为对象、通智融合的“超级计算机”。未来，华为云将致力于把“Agentic Infra”打造为中国AI产业的自主引擎，让智能体真正跑在坚实、高效的国产底座之上，共同开启智能时代的无限可能。 关注魔方公众号，获取更多前沿资讯添加社区小助手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，进入技术交流群