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技术交流群

| 核心变化：从“仅支持并行文件系统”到“同时支持对象桶&并行文件系统”对于许多开发者而言，obsfs 一直是连接本地文件系统与华为云 OBS的关键工具，但在过去，其“不支持挂载对象存储桶”的限制，让不少习惯使用标准对象存储（OBS Bucket）的开发者感到困扰，不得不在数据访问方式上做出妥协。近期，华为云 OBS 服务对 obsfs 工具进行了重大升级，正式支持将标准的对象存储桶挂载至本地文件系统。这一改变，意味着开发者现在可以像访问本地目录一样，直接操作对象存储桶中的海量数据，为 AI 训练、大数据分析等场景提供了全新的存储访问路径。这一变化最直接的影响是：覆盖更广的使用场景：你可以直接对项目中已有的、正在使用的对象桶进行操作，无需为了使用 obsfs 而额外创建或迁移数据到并行文件系统。降低使用门槛：使得更多开发者可以零成本地尝试用本地文件系统的方式管理云上对象存储。| obsfs 对象桶挂载：能解决什么问题？简单来说，obsfs 是一款基于 FUSE 的文件系统工具，它的核心价值在于零代码改造。无论是日志收集脚本、数据处理任务，还是传统的 Web 应用，都无需修改任何文件读写逻辑，就能将数据持久化到 OBS。新能力带来的典型适用场景包括：日志、归档数据的自动上传：将本地日志目录挂载为 OBS 桶，新产生的日志文件自动进入云存储。数据分析与处理的输入输出：在 Spark、Hadoop 等计算任务中，直接将 OBS 作为数据源和结果存储池。遗留系统的存储云化：对于难以改造的老旧应用，通过挂载方式无缝将数据迁移至 OBS。不过需要了解的是，由于对象桶本身的对象语义限制（不支持追加写、随机写），obsfs 通过 FUSE 层模拟了文件操作。任何“修改”在后台实际是“新对象覆盖旧对象”的适配行为。因此，它更适用于顺序读写的场景，而非高并发、小文件频繁读写的数据库类应用。| 实战：三步挂载，体验新能力如何快速体验这个新能力？以下是将一个 OBS 对象桶挂载到本地的具体操作步骤。1. 获取与安装 obsfsobsfs 支持直接下载和编译两种方式。详细步骤参考官网：方式一：下载并安装obsfs方式二：通过编译生成obsfs2. 初始化访问密钥创建一个密钥文件，用于存放你的 OBS 访问密钥（AK/SK），并设置权限为 600 以确保安全。初始化访问密钥3. 执行挂载命令挂载命令格式：./obsfs obs桶名 本地挂载目录 -o url=区域终端节点地址 -o passwd_file=密钥文件路径 -o bucket_type=object -o multipart_size=128 -o 其他挂载参数假设你有一个名为 my-obs-bucket 的 OBS 对象桶，想挂载到本地 /mnt/obs 目录。执行以下命令即可：./obsfs my-obs-bucket /mnt/obs -o url=obs.cn-south-1.myhuaweicloud.com -o passwd_file=/etc/passwd-obsfs -o bucket_type=object注意这里的关键变化：-o bucket_type=object 参数，用于显式声明挂载的是对象桶。这是使用新能力时必须指定的参数，用以区分以往的并行文件系统挂载。挂载成功后，执行 df -h 就能看到你的对象桶已作为一个文件系统挂载在本地。之后，无论是 cp、mv、rm 等常规文件操作，还是你的应用程序通过标准文件接口读写数据，都会直接映射到 OBS 桶中。| 核心设计解析：对象桶挂载的工作原理与注意事项理解 obsfs 对象桶模式的设计逻辑，能帮助你更好地使用它，避免踩坑。1. 回写模式与数据持久性对象桶挂载采用回写模式。数据会先写入本地临时文件（由 tmpdir 或 use_cache 控制）。在默认情况下，只有当应用调用 close() 关闭文件时，才会触发实际上传，close() 返回成功表示数据已持久化到 OBS。因此，进程异常退出（如 kill -9、断电）可能导致未关闭文件的数据永久丢失。针对大文件的优化：对于超大文件上传，可以通过 -o max_dirty_data=1024（单位MB）等参数设置阈值，当本地未上传的脏数据量超过该值时，obsfs 会自动触发流式分段上传，将已写入的数据提前上传，避免 close() 时因全量重传导致长时间阻塞。实践建议：对于关键数据，务必检查 close() 的返回值；对持久性要求极高的场景，可考虑使用 fsync() 定期刷新（需权衡性能）；大文件场景下合理设置 max_dirty_data 和 multipart_size 参数以优化上传效率。2. 缓存机制与性能调优obsfs 提供多个缓存参数，用以提升性能：use_cache：指定本地磁盘缓存目录。启用后，读写的数据会缓存到本地，重复读取时性能显著提升。建议指向高性能的本地 SSD。multipart_size 与 parallel_count：分别控制分段上传的大小和并发线程数，调整这两个参数可以有效利用网络带宽，提升大文件的吞吐量。max_stat_cache_size：控制文件属性（大小、修改时间等）的缓存条目数，减少对 OBS 的 HEAD 请求，提升 ls -l 等操作的响应速度。3. 数据一致性与多挂载点需要注意的是，一个 OBS 桶可以同时挂载到多台服务器上，但各挂载点之间互不感知。obsfs 本身不提供文件锁机制，也无法感知 OBS 的多版本控制。因此，如果多个客户端并发写入同一个文件，可能出现数据覆盖或一致性问题，需要在应用层通过其他方式（如分布式锁）来协调。| 结语从仅支持并行文件系统，到 2026 年 6 月起新增对标准对象桶的挂载支持，obsfs 的这次升级，本质上是将一套统一的本地文件系统访问接口，覆盖到了 OBS 中更广泛、更常用的存储类型上。它为开发者提供了一种零侵入、低成本的云存储接入方式，尤其为那些希望利用云存储但代码改造困难的场景，提供了一条平滑的迁移路径。当然，你也要认识到它在随机写、强一致性场景下的局限，并将其用在合适的地方。关于 obsfs 的完整参数列表和最佳实践，欢迎查阅华为云官方文档。如果你在挂载过程中遇到问题，也欢迎在华为云开发者社区发帖交流，共同探讨。 相关链接：[1] obsfs 开源 GitHub 仓库：cid:link_5[2] obsfs 官方工具指南：cid:link_3[3] 挂载对象存储桶详细指导：cid:link_4

开发者专属免费考证福利来了！【云学堂·云原生技术实战营】活动正式开营！集齐5个微认证兑换云原生入门级开发者认证证书。 一、【活动时间】2026年 06月 15日 - 2026年 09月 30日二、【报名链接】cid:link_1三、【活动福利】1、每通过1门微认证考试→获得对应华为云官方微认证证书2、通过指定5门云原生微认证→免费兑换华为云云原生入门级开发者认证证书3、一键免费领取华为云码道体验版，开启你的编码自动驾驶模式！四、参与流程Step1、AI智能编码辅助工具体验，0 门槛上手，小白也能变大神​！支持 Java/Python/Go 等 7 种主流语言，代码生成、注释、调试、翻译一键搞定！一键免费领取体验版：https://developer.huaweicloud.com/codeartsco.html?source=dmznteducation&sourcead=dmznthd，立即体验，开启你的编码自动驾驶模式！ Step2、集齐5个微认证证书免费兑换云原生入门级开发者认证证书序号认证名称（含免费激活入口）1云原生基础设施之容器入门2云原生基础设施之容器进阶3基于CCE Kubernetes编排实战4CCE网络与存储实战5云容器快速搭建网站通过序号1-5微认证且获得证书后，点此兑换云原生入门级开发者证书（我的认证→我的证书兑换）【考试说明】1、云原生5个微认证无需购买，点击表格中认证名称进入认证详情页，点击“免费激活”按钮即可，如考试未通过可再次点击“免费激活”。2、云原生5个微认证需要理论考试≥70分+实验考试≥60分才算考试通过。3、考试通过后第1个自然日后将发放证书，可前往我的学堂- 我的证书查看证书编号和下载电子证书。 不管是入门新手、在校同学还是职场开发者，都可以一站式学练考！

随着大模型向长上下文（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  

开发者专属免费考证福利来了！【云学堂·云原生技术实战营】活动正式开营！集齐5个微认证兑换云原生入门级开发者认证证书。 一、【活动时间】2026年 06月 15日 - 2026年 09月 30日二、【报名链接】cid:link_1三、【活动福利】1、每通过1门微认证考试→获得对应华为云官方微认证证书2、通过指定5门云原生微认证→免费兑换华为云云原生入门级开发者认证证书3、一键免费领取华为云码道体验版，开启你的编码自动驾驶模式！四、参与流程Step1、AI智能编码辅助工具体验，0 门槛上手，小白也能变大神​！支持 Java/Python/Go 等 7 种主流语言，代码生成、注释、调试、翻译一键搞定！一键免费领取体验版：https://developer.huaweicloud.com/codeartsco.html?source=dmznteducation&sourcead=dmznthd，立即体验，开启你的编码自动驾驶模式！ Step2、集齐5个微认证证书免费兑换云原生入门级开发者认证证书序号认证名称（含免费激活入口）1云原生基础设施之容器入门2云原生基础设施之容器进阶3基于CCE Kubernetes编排实战4CCE网络与存储实战5云容器快速搭建网站通过序号1-5微认证且获得证书后，点此兑换云原生入门级开发者证书（我的认证→我的证书兑换）【考试说明】1、云原生5个微认证无需购买，点击表格中认证名称进入认证详情页，点击“免费激活”按钮即可，如考试未通过可再次点击“免费激活”。2、云原生5个微认证需要理论考试≥70分+实验考试≥60分才算考试通过。3、考试通过后第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，进入技术交流群

摘要 本文介绍了基于 KubeEdge-Ianvs 分布式协同AI基准测试框架的大语言模型联邦微调系统。该系统针对企业应用大模型面临的算力门槛高、数据孤岛严重等挑战，通过联邦学习实现"数据不动模型动"的隐私保护训练模式。系统集成 LoRA 和 P-Tuning 两种参数高效微调技术，大幅降低通信成本和计算开销，支持 FedAvg 和 FedAvgM 聚合算法，并创新性地设计了 GPU 感知任务调度机制以避免显存溢出。在 MedQuad 医疗问答数据集上的实验验证了不同 PEFT 方法与聚合算法组合的有效性，为垂直领域的联邦大模型应用提供了可行方案。本文还提供了详细的安装配置和使用教程，帮助用户快速上手联邦大模型微调实践。代码请见：cid:link_1一、背 景近年来，以大语言模型（LLM）为代表的人工智能技术迅猛发展，ChatGPT、LLaMA、GLM 等模型在自然语言理解、代码生成、智能问答等任务中展现出卓越能力，推动各行业迈向智能化新阶段。这些模型不仅能够理解复杂的语义，还能进行创造性的内容生成，为各行各业带来了前所未有的智能化机遇。然而，企业在实际落地大语言模型过程中仍面临两大核心挑战，制约技术普及并可能加剧数字鸿沟。这些挑战不仅制约了技术的普及，更可能加剧数字鸿沟，让 AI 的红利难以惠及更广泛的群体。📌 挑战一：算力门槛高，中小企业难以承担大语言模型训练对算力需求巨大，通常需数十亿至千亿级参数，依赖大规模 GPU 集群持续运行数周乃至数月。据估算，训练一个类似 GPT-3 规模的模型，成本可能高达数百万美元。高昂的资源投入使大模型能力逐渐成为大型科技公司的专属优势。对于资源有限的中小企业而言，即便拥有宝贵的行业数据和应用场景，也往往因算力不足难以自主完成模型训练，限制了技术普惠与创新多样性。📌 挑战二: 数据孤岛困境,高质量数据难以整合高质量训练数据是大模型能力的核心基础。大语言模型的强大能力，很大程度上依赖于海量、多样化的训练数据。然而现实情况是，真正有价值的数据往往分散在不同的企业、机构和组织中，形成了一个个难以逾越的"数据孤岛"。这种数据分散的局面，源于多重因素：隐私合规要求：医疗、金融等领域的敏感数据受到严格的法律保护，不能随意共享或传输商业竞争壁垒：企业积累的私有数据往往是核心竞争力，难以对外开放数据主权意识：各方对数据控制权的重视，使得数据集中面临信任难题更为严峻的是，研究表明互联网上的公开数据可能即将耗尽。随着大模型训练需求的持续增长，如何在保护隐私的前提下，合理利用分散在各方的私有领域数据，已成为行业亟需解决的关键问题。破局方向：联邦学习赋能大模型微调。面对这些挑战，联邦学习(Federated Learning)为我们开辟了一条创新路径。联邦学习作为一种隐私保护的协同机器学习范式，通过“数据不动模型动”的方式，使各参与方本地数据保留不动，仅交换模型参数或梯度信息，实现多方协同训练。这种技术范式带来的价值是多维度的：在资源层面：联邦学习允许多个企业汇聚各自的算力资源，采用分布式的方式共同承担大模型训练的计算负担。一家企业可能无力独立训练大模型，但十家、百家企业的算力聚合，就能让 AI 能力的获取不再是大公司的专利。这种"众人拾柴火焰高"的协作模式，有望打破算力垄断，推动AI的普惠化发展。在数据层面：联邦学习通过同态加密、安全多方计算、差分隐私等密码学和隐私保护技术，在保护各方数据隐私和安全的前提下，充分挖掘分散数据的集体智慧。各参与方既能贡献自己的数据价值，又无需担心隐私泄露，真正实现了"数据可用不可见"。在合规层面：联邦学习天然契合数据保护法规的要求，为跨机构、跨地域的数据协作提供了合法合规的技术方案，让数据要素的价值释放有了坚实的制度保障。联邦学习与大语言模型结合形成联邦大模型学习（FedLLM），进一步引入参数高效微调技术（如 LoRA、P-Tuning），显著降低通信与计算开销。这一技术融合不仅继承了联邦学习的隐私保护优势，还针对大模型的特点进行了创新性的优化设计。联邦大模型学习通过参数高效微调(如 LoRA、P-Tuning)等技术，大幅降低了通信成本和计算开销，使得在联邦场景下训练和微调大模型成为可能。这为企业提供了突破资源和数据瓶颈的可行方案，更开启了 AI 协作发展的新时代。该方案使中小企业能够与行业领先者协同构建领域大模型，医院之间可以在保护患者隐私的前提下，协作提升医疗 AI 的诊断能力；金融机构可以联合建立更精准的风控模型，而无需担心客户数据的泄露风险。二、基于KubeEdge-Ianvs的大模型联邦微调算法实现本项目基于 KubeEdge-Ianvs 分布式协同 AI 基准测试框架，设计并实现了一套完整的联邦大模型微调系统。该系统充分继承了 Ianvs 的模块化架构优势，并针对大语言模型的特点进行了专门优化，在保持原有 federated learning 范式完全向后兼容的前提下，构建了适用于大规模语言模型的联邦学习解决方案。▍2.1 总体架构设计整体架构采用分层设计理念，从底层到上层依次为测试环境管理层、测试用例控制层和故事管理层，如图1所示。测试环境管理层负责基准测试指标的定义与计算，新增支持 ROUGE-1、ROUGE-2、ROUGE-L、BLEU-4 等自然语言生成评估指标，同时提供数据预处理和分割工具，支持 JSONL 格式的大语言模型数据集处理，并实现联邦场景下的数据分区策略以模拟真实的数据分散情况。测试用例控制层基于现有的联邦学习范式扩展实现了全新的联邦大模型微调算法，标准化了联邦微调的完整训练和评估流程，采用模块化设计使得用户只需指定相关模型与聚合接口即可完成算法配置。故事管理层则为用户提供直观的排行榜视图和详细的测试报告，支持跨联邦轮次的 LLM 基准指标可视化，便于算法性能的横向对比和纵向追踪。图1 整体架构设计在核心技术方案上，系统针对大语言模型参数规模庞大、全量微调成本高昂的问题，集成了 LoRA 和 P-Tuning 两种主流的参数高效微调技术，如图2所示。 LoRA 通过在权重矩阵中插入低秩可训练适配器，仅需训练极少量额外参数（通常小于1%模型参数量），推理时无需合并即可保持原模型结构。P-Tuning 则在嵌入层学习连续的提示向量，仅修改输入表示，对不同任务具有良好的灵活性且参数量更小，适合资源受限场景。根据实验数据，LoRA 方式的通信成本与 P-Tuning-v2 的通信成本均小于1%，这种数量级的降低使得联邦大模型学习在实际生产环境中具备了可行性。图2 算法设计方案系统支持 FedAvg 和 FedAvgM 两种聚合算法供用户根据场景灵活选择。FedAvg 对客户端模型参数进行加权平均，权重通常基于各客户端的数据量，简单高效且适合同构场景。FedAvgM 则在服务器端引入动量机制，提供更稳定的收敛性能，在非独立同分布数据下表现更优。每轮训练中，仅 LoRA 适配器或 P-Tuning 提示向量在客户端与服务器间传输，原始 LLM 的主体参数始终冻结，既保护了模型知识产权，又极大降低了通信负担。针对传统联邦学习多线程方法在大模型场景下容易导致 GPU 显存溢出的问题，系统创新性地设计了 GPU 感知任务调度机制。该机制将所有客户端训练任务放入全局任务队列，为每个可见 GPU 启动专属工作线程，线程通过 torch.cuda.set_device 绑定到特定设备后采用 FIFO 方式逐个处理客户端任务，训练完成后立即释放显存。这种设计确保每个 GPU 同时只加载一个 LoRA 增强模型，使得峰值显存使用量可预测且恒定，同时严格的 FIFO 顺序保证所有 GPU 得到均衡利用。实践证明，该调度器能够在单个节点的多 GPU 环境（如4×Nvidia A100）上稳定运行数十个7B参数级别的 LLM 客户端微调任务，避免 OOM 错误，实现了固定内存上限、负载均衡和线性扩展的设计目标。系统的完整训练流程如图3所示。从初始化阶段开始，服务器加载预训练大模型（如ChatGLM-6B、LLaMA等）并初始化全局 LoRA 适配器或 P-Tuning 提示向量，配置联邦参数包括客户端数量、通信轮次和聚合策略等。进入迭代训练阶段后，每一轮都经历客户端采样、模型分发、本地训练、参数上传、安全聚合和性能评估等步骤。服务器从所有客户端中采样参与本轮训练的子集，将当前全局适配器或提示向量下发给选中的客户端，各客户端在私有数据上执行 PEFT 微调更新本地适配器参数，随后将训练后的适配器参数上传至服务器，服务器使用选定的聚合算法更新全局模型并在测试集上评估性能。当达到预设轮次或性能指标后停止训练，将最终的全局适配器与基础模型结合并部署到实际应用环境。整个流程中，原始训练数据始终保留在各客户端本地，仅交换模型参数，真正实现了"数据不动模型动"的隐私保护目标。图3 任务时序图▍2.2 案例分析为了全面验证系统的有效性，我们在 MedQuad 医疗问答数据集上进行了深入的实验研究[1]。实验采用 ChatGLM-6B 作为基础大语言模型，该模型包含60亿参数，在中文理解与生成任务上表现优异。硬件配置方面，单机4张 NVIDIA A100 GPU。联邦配置模拟4个客户端参与学习，训练总轮次设置为5轮。评估指标采用自然语言生成领域的标准体系，包括衡量单词级别重叠度的 ROUGE-1、衡量二元组重叠度的 ROUGE-2、基于最长公共子序列的 ROUGE-L，以及评估 n-gram 精确匹配度的 BLEU-4 指标。图4 医疗联邦示例图5 部分实验效果展示从图4的排行榜可以看出，FedAvg-LoRA 组合取得了最佳性能，在所有评估指标上均位列第一，ROUGE-1 达到0.3283，ROUGE-2 为0.0965，ROUGE-L 为0.1907，BLEU-4 为0.0525。对比相同聚合算法下的不同微调方法，LoRA 始终优于 P-Tuning，以 FedAvg 为例，LoRA 方案在 ROUGE-1 指标上比 P-Tuning 高出13.5%，在 ROUGE-2 上优势更为明显，提升了34.2%。这种差异源于两种方法的本质区别：LoRA 通过在模型权重矩阵中注入低秩适配器能够更深入地调整模型内部表征，而 P-Tuning 仅在输入层学习连续提示，在医疗问答这类需要深度理解专业术语和复杂语义的任务中，LoRA 的优势得以充分体现。聚合算法方面，FedAvg 与 FedAvgM 的对比结果揭示了有趣的交互作用：在 LoRA 场景下 FedAvg 显著优于 FedAvgM（ROUGE-1相差12.8%），但在 P-Tuning 场景下两者性能相当接近（差距仅为0.8%），这表明 FedAvgM 的动量机制在 LoRA 较大的参数空间中可能引入额外不稳定性，而在 P-Tuning 的低维参数空间中则能更好发挥平滑作用。实验结果为实践应用提供了明确指导：资源充足时推荐 FedAvg-LoRA 获得最佳性能，资源受限场景下 FedAvgM-P-Tuning 能够在保持稳定收敛的同时最小化通信开销，数据异构场景则建议优先尝试 FedAvgM 应对非独立同分布挑战。值得注意的是，所有方案的 ROUGE-2 和 BLEU-4 指标相对较低，反映了医疗问答任务需要生成精确匹配的专业术语和复杂句式的固有难度，未来可探索引入领域知识增强、对比学习等技术进一步提升联邦大模型在垂直领域的表现。通信成本分析揭示了 PEFT 方法的巨大优势。LoRA 方法仅需传输 3.6MB 的参数，占模型总参数的0.058%，这意味着在 10Mbps 的网络下单次通信仅需约3秒，相比全量微调通信成本降低了1724倍，极其适合带宽受限的边缘设备或跨地域联邦学习。P-Tuning-v2 虽然参数量为是 LoRA 的1.25倍。 三、基于KubeEdge-lanvs的使用教程在本章中，我们通过运行 Ianvs 联邦学习的 FedLLM-PEFT 样例向大家讲解基于 KubeEdge-Ianvs 实现大语言模型联邦微调的基本流程。Ianvs 安装流程以及联邦学习更详细的介绍可以参考：Ianvs官方文档[2]。▍3.1 准备环境首先确保您的系统满足以下要求：Python 3.8.18PyTorch 2.4.1+cu118兼容 CUDA 的 GPU（建议使用 Nvidia A100 80GB）建议 32GB 以上内存我们需要配置好联邦学习的数据集，先创建数据集的文件夹，注意如果你把数据集放到别的位置，本教程中的部分路径配置也要一并修改。mkdir /data cd /data mkdir fedllm_datasets cd fedllm_datasets下载 MedQuad 医疗问答数据集：# 从HuggingFace下载数据集 wget https://huggingface.co/datasets/keivalya/MedQuad-MedicalQnADataset/resolve/main/train.jsonl wget https://huggingface.co/datasets/keivalya/MedQuad-MedicalQnADataset/resolve/main/test.jsonl💭 注意：下载原始 JSONL 文件后，需要创建测试拆分，并删除冗余的 qtype 字段。数据集格式应为每行一个 JSON 对象，至少包含 question 和 answer 两个字段：{"question": "What is diabetes?", "answer": "Diabetes is a chronic disease..."}配置好数据集后，我们需要安装 Ianvs 和相关依赖。首先克隆 Ianvs 仓库：cd /ianvs/project git clone cid:link_2git cd ianvs安装系统依赖和 Ianvs 核心依赖：# 安装Ianvs核心 sudo python setup.py install # 安装PEFT相关依赖 pip install transformers==4.30.0 pip install peft==0.4.0 pip install datasets==2.12.0 pip install accelerate==0.20.3 pip install sentencepiece==0.1.99 pip install protobuf==3.20.3我们使用 ChatGLM-6B 作为基础大语言模型，需要先下载模型权重：cd /ianvs/project mkdir models cd models # 从HuggingFace下载ChatGLM-6B模型 git lfs install git clone https://huggingface.co/THUDM/chatglm-6b▍3.2 配置文件修改示例代码放在[3]下，我们需要修改相关配置文件中的路径。首先配置算法参数，编辑 algorithm/algorithm.yaml：# 修改模型路径 modules: -type: "basemodel" name: "model" url: "/ianvs/project/ianvs/examples/federated-llm/fedllm-peft/algorithm/model.py" hyperparameters: model_name: "/ianvs/project/models/chatglm-6b" save_dir: "/ianvs/project/fedllm_output" initial_model_url: "/ianvs/project/models/chatglm-6b" peft_method: "lora"# 可选"lora" 或"ptuning" batch_size: 1 learning_rate: 0.0001 local_epochs: 2 -type: "aggregation" name: "FedAvg-PEFT" url: "/ianvs/project/ianvs/examples/federated-llm/fedllm-peft/algorithm/FedAvg-PEFT.py"然后配置测试环境，编辑 testenv/testenv.yaml：# 修改数据集路径 dataset: train_data: "/data/fedllm_datasets/train.jsonl" test_data: "/data/fedllm_datasets/test.jsonl" # 配置联邦学习参数 round: 5 gpu_num: 4 client_number: 4 if_mode_llm: true # 配置评估指标路径 metrics: -name: "rouge1_metric" url: "/ianvs/project/ianvs/examples/federated-llm/fedllm-peft/testenv/rouge1_metric.py" -name: "rouge2_metric" url: "/ianvs/project/ianvs/examples/federated-llm/fedllm-peft/testenv/rouge2_metric.py" -name: "rougel_metric" url: "/ianvs/project/ianvs/examples/federated-llm/fedllm-peft/testenv/rougel_metric.py" -name: "bleu4_metric" url: "/ianvs/project/ianvs/examples/federated-llm/fedllm-peft/testenv/bleu4_metric.py"最后配置基准测试作业，编辑 benchmarkingjob.yaml：workspace: "/ianvs/project/fedllm_workspace" testenv: "/ianvs/project/ianvs/examples/federated-llm/fedllm-peft/testenv/testenv.yaml" algorithm: "/ianvs/project/ianvs/examples/federated-llm/fedllm-peft/algorithm/algorithm.yaml" rank: sort_by: "rouge1_metric" visualization: mode: "select_all"▍3.3 运行联邦微调配置完成后，设置 Python 路径并运行基准测试：# 设置Python路径 export PYTHONPATH=$PYTHONPATH:/ianvs/project/ianvs/examples/federated-llm/fedllm-peft # 运行FedAvg-LoRA联邦微调 cd /ianvs/project/ianvs ianvs -f examples/federated-llm/fedllm-peft/benchmarkingjob.yaml▍3.4 尝试不同配置如果想尝试不同的 PEFT 方法或聚合算法，只需修改 algorithm.yaml 中的相应参数：# 使用P-Tuning代替LoRA： peft_method: "ptuning" # 使用FedAvgM代替FedAvg： aggregation: name: "FedAvgM-PEFT" url: "/ianvs/project/ianvs/examples/federated-llm/fedllm-peft/algorithm/FedAvgM-PEFT.py" hyperparameters: beta: 0.7 server_lr: 1.0▍3.5 查看结果训练完成后，结果将保存在工作目录中，包括：排行榜显示不同算法组合的性能对比详细的评估指标（ROUGE-1、ROUGE-2、ROUGE-L、BLEU-4）训练日志和模型检查点您可以在/ianvs/project/fedllm_workspace目录下查看完整的实验报告和可视化结果。相关链接[1] MedQuad医疗问答数据集实验研究：HuggingFace- keivalya/MedQuad-MedicalQnADataset[2] Ianvs官方文档：cid:link_0[3] 配置文件示例代码：/ianvs/project/ianvs/examples/federated-llm/fedllm-peft 参考文献[1] McMahan, H. B., Moore, E., Ramage, D., Hampson, S., & Aguera y Arcas, B. Communication-Efficient Learning of Deep Networks from Decentralized Data. In AISTATS, 2017[2] Hsu, T.-M. H., Qi, H., & Brown, M. Measuring the Effects of Non-Identical Data Distribution for Federated Visual Classification. arXiv:1909.06335, 2019[3] Fan, T., Kang, Y., Ma, G., Chen, W., Wei, W., Fan, L., & Yang, Q. FATE-LLM: A Industrial Grade Federated Learning Framework for Large Language Models. In Symposium on Advances and Open Problems in Large Language Models (LLM@IJCAI'23), 2023[4] Liu, X., Ji, K., Fu, Y., et al. P-Tuning v2: Prompt Tuning Can Be Comparable to Fine-tuning Universally Across Scales and Tasks. arXiv:2110.07602, 2021[5] KubeEdge. Ianvs: Distributed Synergy AI Benchmarking Framework. GitHub repository: cid:link_2 关注魔方公众号，获取更多前沿资讯添加社区小助手k8s2222，进入技术交流群