假设某在线服务部署在 Kubernetes 集群，使用自定义业务指标驱动水平扩缩容，节点池按需求自动增减；指标采集可能丢点、乱序或延迟，实例启动需要预热，缩容可能中断长连接或批处理。约束：不绑定具体 HPA 实现、云厂商、监控系统或服务网格；不新增消息中间件或配置中心；允许秒级到分钟级最终一致；不能因单个指标抖动导致全局扩缩震荡；缩容不得把未就绪或正在排空的实例计入可用容量。目标：设计副本期望状态、节点容量申请、就绪门禁、扩缩冷却、缩容排空与回流防震荡状态机，使重复调谐幂等、中断可恢复、决策结果可解释。请讨论：1）指标窗口、异常值过滤、最小样本与缺失数据如何影响扩缩判定；2）扩容与缩容是否应采用不对称冷却、步长和超时边界；3）节点池容量不足时请求排队、超时、降级与告警如何收敛；4）缩容时连接排空、PDB、批处理迁移与强制终止边界；5）指标漂移、节点故障、控制器重启后如何恢复并避免回流震荡；6）自动回滚、部分成功、人工介入的判定条件。只讨论协议、状态机、超时与失败边界，不要求具体工具配置或厂商参数。

假设某团队为多个微服务维护一条持续部署流水线，构建产物为不可变容器镜像，通过环境清单按 dev→staging→prod 逐级晋升；不同环境存在配置差异与部分共享依赖。约束：不引入新的制品仓库或配置中心，不绑定具体 CI/CD 工具与云厂商；镜像和制品版本不可变；流水线可能因人工审批、网络中断或节点故障暂停；允许分钟级最终一致，但生产回滚必须可审计且不能扩大故障面。目标：设计制品版本、环境清单、配置快照与部署记录之间的版本绑定和晋升状态机，使重复执行幂等、中断后可恢复、回滚时能明确哪些步骤可逆、哪些只能前滚。请讨论：1）构建产物与环境配置如何绑定，配置快照在晋升时生成还是部署时生成；2）多服务依赖是否需要同批晋升，部分成功如何收敛；3）流水线中断后如何判断续跑、重跑或回滚，如何避免重复部署；4）运行时实际版本与部署记录漂移如何检测和告警；5）生产回滚与数据库迁移、消息格式变更等不可逆操作的边界如何划分，何时必须人工介入。不要求具体语法或工具配置，只讨论协议、状态机、超时与失败边界。

假设某 Kubernetes 集群需对部分节点做内核升级与硬件维护，节点上运行 StatefulSet 有状态应用，使用 ReadWriteOnce 持久卷；数据一部分需迁移前落盘，一部分靠应用内复制同步。约束：不能整体停机，允许 Pod 逐个重建，允许秒级到分钟级不可用但最终一致；存储插件不保证卷可同时挂载多节点；节点可能非计划宕机；不能修改已发布镜像和 StatefulSet 名称。目标：设计节点标记、Pod 驱逐、数据落盘、卷解绑、Pod 重建与数据校验的顺序和状态机，避免双写、脑裂和卷挂载冲突。请讨论：1）节点维护与节点故障如何区分，PDB、污点、驱逐 API 如何配合；2）preStop、terminationGracePeriod 与落盘如何编排，超时强杀边界；3）旧节点未释放 RWO 卷时新 Pod 如何避免挂载冲突；4）应用内复制与存储快照/克隆如何选择并标记可安全迁移；5）驱逐失败、卷卡在 Attach/Detach 时人工介入与强制删除边界。不绑定具体存储插件、Kubernetes 版本或应用框架。

假设某 Kubernetes 集群中的 Operator 负责为一个自定义资源（CR）创建一组有依赖关系的外部对象：先向证书服务申请证书，再创建云负载均衡器并绑定证书，最后写入 DNS 记录；删除时需反向清理。外部云 API 可能超时、限流且不保证幂等；Operator 会因升级或领导权切换重启；不能修改已发布 CRD 的字段名；允许分钟级最终一致，但删除不能无限阻塞命名空间回收。目标是设计 finalizer、外部对象归属标识与创建/删除状态机，使重复调谐不产生重复对象，中断后可继续，对象已不存在时能收敛。请讨论：1）finalizer 的添加、移除与状态子资源如何配合，避免卡在 Terminating；2）外部对象如何命名、打标签或写注册表以支持幂等查询；3）创建成功但本地状态未持久化时如何恢复；4）删除时如何区分“确认不存在”“查询失败”“部分依赖已删”；5）退避、超时、人工介入与强制移除 finalizer 的边界。不绑定具体云厂商、Operator 框架版本或外部 API 规范。

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

最好的产品，诞生于用户的每一次点击与反馈。华为云云容器引擎 CCE 近期围绕大家反馈的远程登录、日志体验等方向进行了专项优化，欢迎体验：cid:link_1  

近日，全球商业技术洞察机构Gartner®正式发布2026年《容器管理魔力象限》报告，华为云凭借执行能力和愿景完整性，蝉联领导者，标志着在全球容器管理领域的领先地位持续获得国际认可。该报告围绕新云原生应用、存量应用容器化、AI训练负载、AI推理及Agent负载、边缘应用、混合云应用等核心场景，对全球主流云服务商进行全面评估。华为云提供业界最完整的容器产品矩阵，覆盖公有云、分布式云、混合云、边缘等场景，已广泛应用于互联网、金融、制造、交通等行业，持续帮助全球客户取得商业成功。面向AI智能体时代，华为云聚焦AI战略并持续加大AI基础设施投入，在业界率先提出Agentic Infra新范式，以容器技术为核心持续完善算力、调度、运行环境与开源生态等基础能力，夯实“硅基黑土地”。CCE智算集群基于华为云软硬芯协同的优势，高效编排灵衢智算超节点(AICS)，实现十万卡级算力池化与统一调度，为大模型训练、推理等AI负载提供稳定的云原生底座。CCE VolcanoNext通智一体化调度引擎通过“训推共池+碎片整合”实现通智混合算力负载调度革新，将资源利用率提升30%以上；在推理场景中，结合Kthena智能路由及Prefill/Decode多角色编排能力，联动EMS高性能KV Cache缓存，进一步提升推理吞吐，实现算力资源的高效利用。AgentSphere打造安全自治的Agent运行底座，提供极速弹性、生态兼容的Agent基础设施。其中，Agent Sandbox凭借羽量级沙箱技术，实现百毫秒级极速启动与每分钟十万级批量创建能力，高效支撑Agent Serving高频调用及Agentic RL大规模并行训练等场景。华为云积极参与全球云原生技术社区的开源生态建设，向CNCF捐赠了Volcano、KubeEdge、Karmada等标杆开源项目，同时面向AI推理与Agent场景发布了Kthena与AgentCube，持续推动全球容器与云原生技术向AI演进。未来，华为云将继续秉持携手创新、成就共享的理念，深化容器与Agentic Infra的融合创新，为Agent应用规模化落地和千行百业智能化升级提供更加开放、高效、可靠的基础设施。来源： Gartner®, Magic Quadrant for Container Management, 2 September 2026阅读报告：https://www.gartner.com/reprints/?id=00ThR00000EdAxMUAV&ct=260908&st=sb 关注魔方公众号，获取更多前沿资讯

9月8日，在KubeCon + CloudNativeCon + OpenInfra Summit + PyTorch Conference China 2026大会现场，云原生计算基金会（CNCF）正式宣布，Karmada晋级为毕业项目。这一里程碑不仅标志着Karmada在技术能力、社区治理与安全实践各领域的高度成熟，更体现了业界对其开源价值与生态影响力的广泛认可，Karmada已成为全球云原生跨云跨集群算力调度与治理的重要基础设施。▲CNCF CTO Chris Aniszczyk宣布 Karmada正式毕业华为云研发总裁王洪利表示：“Karmada迈入毕业阶段，离不开全球贡献者与企业用户的共同推动。面向未来，华为云将秉持开源初心，持续深化与CNCF社区的协同，推进云原生与AI技术深度融合，并进一步面向Agent场景解决跨云大规模通智融合算力调度难题，让多云多集群管理与调度技术成为AI时代产业创新的坚实底座。 ” 引领跨云AI算力池化的技术先驱作为CNCF首个毕业级云原生多云容器编排引擎，Karmada由华为云联合金融、互联网、汽车及出行等多领域头部企业于2021年共同发起，是业界首个聚焦跨集群、跨云编排的开源项目。借助Karmada，企业和开发者可以快速构建无限可扩展的容器资源池，像使用单个集群一样使用多云集群。 自加入CNCF以来，Karmada在全球社区的共同推动下持续演进，正有力支撑企业应对混合云部署、多区域容灾与大规模AI训练推理等复杂场景。与毕业官宣同步发布的Karmada v1.19，其多组件调度与优先级能力直击AI场景痛点。基于优先级的调度特性已提升至Beta并默认开启，帮助平台团队在GPU等资源受限环境中优先保障关键工作负载。企业无需修改现有应用，即可实现跨多个集群、云与区域的统一编排、故障自动恢复与弹性伸缩。凭借对AI训练与推理场景的深度适配，Karmada已成为企业构建跨云AI算力基础设施的核心选择。晋级CNCF毕业级项目后，Karmada也将进一步构建更智能的资源感知控制面，帮助企业应对更大规模、更复杂的跨区域异构资源调度挑战。“当组织在多个集群和GPU受限的AI环境中扩展Kubernetes时，拥有生产就绪的方式来协调整个集群舰队，对运营成功至关重要，”CNCF CTO Chris Aniszczyk表示。“达到CNCF毕业状态，证明Karmada已具备企业所需的技术成熟度、治理和安全工作；我们期待该项目在生态中持续成长。” 持续贡献：从技术开源到产业赋能作为项目的发起组织与核心贡献者，华为云在Karmada的架构设计、关键代码贡献、社区治理及安全审计等环节持续深耕，有力驱动了项目的成熟与演进。作为CNCF唯一的中国创始企业，华为云深度参与CNCF治理，在技术委员会及核心项目的Maintainer团队中均占据重要席位。2024年，华为云技术专家高票当选CNCF中国本土唯一TOC（技术监督委员会）委员席位（全球共11席），并现任CNCF TOC副主席。在推动开源生态建设的同时，华为云将Karmada作为分布式云原生服务（UCS）的核心引擎，落地于智算及混合云生产环境。华为云UCS作为业界首发的分布式云原生服务，依托Karmada构建了覆盖中心Region、专有Region、边缘云、客户数据中心及第三方云等多维基础设施的应用算力供给架构，为云原生工作负载提供跨云跨地域的一致化调度体验。同时，大规模商用场景的持续验证，也反哺Karmada在真实业务压力下不断优化，进一步巩固了其面向生产级分布式云原生场景的稳定性与可靠性。 繁荣生态：全球采用者与贡献者共建Karmada当前拥有来自292家组织的超过1,214名贡献者，GitHub Stars超5,600。其生产采用者覆盖云计算、互联网、通信、AI、旅游、物流、企业IT等众多领域，包括Bloomberg、Wellhub、哔哩哔哩、科大讯飞、携程等40余家公开企业。在诸多用户场景中，Karmada被广泛用于支撑混合云容量调度、多区域弹性扩展、智能流量分发、AI训练与推理、GPU/CPU异构调度、多集群应用交付以及舰队级服务配置分发等核心业务。“当组织规模扩展到单个Kubernetes集群之外时，他们需要在不增加复杂性的情况下实现一致的管理。Karmada通过将熟悉的Kubernetes API扩展到跨集群和云环境，解决了这一问题。该项目拥有来自六家组织的Maintainer，且大量的采用者均在使用它，我们祝贺Karmada成为CNCF毕业项目。”— Chad Beaudin，CNCF TOC Sponsor “Karmada已成为Bloomberg运营弹性云原生基础设施的基础。通过自动化灾难恢复、提升资源利用率，并简化单个Kubernetes集群的管理，它帮助我们的平台工程团队更高效地运营，同时让内部应用团队在部署任务时获得更简单、更一致的体验。作为过去几年与Karmada社区紧密合作的伙伴，我们见证了这个开源项目持续演进，它的毕业反映了其对管理复杂Kubernetes环境的企业组织日益重要的价值。”— Michas Szacillo，Bloomberg流媒体平台工程团队负责人 “在携程，Karmada已成为我们多集群基础设施的关键组成部分，并在生产中带来了显著价值。在不改变现有Kubernetes资源定义的情况下，它使我们能够将多个集群作为统一资源池运营，支持跨集群弹性和故障转移，更高效地将新集群投入生产，并以对应用最小的干扰完成大规模工作负载迁移。这大大降低了大规模运营基础设施的复杂性。随着计算日益跨越区域、云和异构资源，我们相信Karmada将成为可靠、可扩展的云原生与AI基础设施的重要基础。”— 乐鸿辉，携程高级开发专家 开源开放，共建Agentic Cloud坚实底座Karmada从最初的代码提交走向CNCF毕业，是全球数百家企业、上千位贡献者共同推动的结果。这一历程不仅验证了Karmada的技术成熟度，更证明了开源协作在解决复杂基础设施挑战上的独特价值。随着大模型与AI智能体技术的快速演进，云计算正加速迈向智能化时代。面向未来，华为云也将持续与开源社区一道，驱动基础设施迈向面向“Agentic Cloud”的核心底座，让容器具备感知应用意图、自适应调度与跨集群协同的能力的Agentic Container。通过把复杂的底层资源管理下沉为标准的开源能力，帮助开发者更简单、智能地驾驭万卡集群与智能体工作负载，共同开拓云原生在AI时代的全新边界。 关注魔方公众号，获取更多前沿资讯

9月6日至7日，AGNTCon+MCPCon China 2026 将在上海举行。来自全球的开发者、技术专家、开源项目贡献者及行业领袖将汇聚一堂，共同交流智能体Al(AgenticAI)与模型上下文协议(MCP)的最新技术进展和实践经验。华为精彩抢鲜看~  

9月，全球云原生与Al 基础设施顶级盛会 KubeCon+CloudNativeCon+OpenlnfraSummit + PyTorch Conference China 2026 将于中国上海举行，CNCF、OpenlnfraPyTorch三大基金会首次齐聚，云原生、开放基础设施与 AI三大技术生态将在同-会场交汇。访问大会官网，了解更多议程：https://www.lfopensource.cn/kubecon-cloudnativecon-openinfra-summit-pytorch-conference-china  

当 AI Agent 从概念验证走向真实业务与生产环境，工程团队面对的问题正在迅速发生变化：Agent 应该运行在怎样的基础设施之上？企业内部越来越多的 MCP 服务，如何实现高效注册、发现与管理？当一个 Agent 不再足以完成复杂任务，多智能体又该如何真正实现工程化协同2026年9月6日至7日，AGNTCon + MCPCon China 将在上海国际会议中心举行。 作为 AAIF （Agentic AI Foundation）面向开放智能体生态的重要技术大会，活动将汇聚开发者、研究人员、平台建设者、开源社区以及企业技术团队，围绕 MCP、Agent 协议、基础设施、编排、评测、可靠性、安全治理与企业生产环境实践展开深入交流。https://www.lfopensource.cn/mcp-dev-summit-shanghai/本届AGNTCon + MCPCon China，华为三位技术专家将登台进行分享。他们从基础设施、MCP 服务发现到多智能体工程，为开发者带来三个最值得关注的技术方向，直击企业级Agent落地的核心痛点。基础设施：企业级Agent是否需要一套全新的技术栈过去十多年，云原生技术一直是现代应用的基石。但当企业开始在生产环境中部署自主且长时间运行的 Agent 时，一个不得不面对的问题出现了：现有的基础设施，还够用吗？从计算资源、弹性调度、安全隔离到 Agent Runtime，Agentic AI 对底层基础设施提出了与传统应用截然不同的要求。当我们在真实的生产环境中大规模构建和运营智能体系统时，会反复遇到一系列棘手的挑战：长周期状态的管理、工具的安全执行、Agent 行为的可观测与调试、安全边界的定义与人机协同，以及多 Agent 之间的协调。这引出了一个核心议题：企业级智能体究竟只是现有基础设施上的另一种工作负载，还是说它需要全新的底层原语（primitives）与抽象层？为了回答这个问题，在本次大会的圆桌讨论中，来自不同技术栈的基础设施构建者们将同台对话，分享在大规模构建和运营智能体系统过程中的实践经验。其中，Kevin Wang 将作为分享嘉宾，与来自 AWS、Kong Inc. 和腾讯的专家一起，从云原生走向 Agentic AI 的技术演进出发，共同探讨这个越来越现实的问题：企业级 Agent 是否需要一套全新的基础设施技术栈？演讲主题：从云原生走向 Agentic AI：企业需要一套新的基础设施吗？演讲嘉宾：Kevin Wang｜HuaweiCNCF技术监督委员会（TOC）副主席，华为云原生开源 Tech Lead。 MCP：服务越来越多，怎样让 Agent “找得到、连得上”？当企业内部的 MCP Server、Tools 与 Agent 数量持续增加，单纯解决“连接”已经不够。一个更棘手的问题浮出水面：服务如何注册、发现，以及不同运行环境之间如何实现互操作？这并非杞人忧天。据 Anthropic 报告，一个接入了 1,000 个 MCP 工具的智能体，仅工具提示词（tool prompts）就会消耗约 50 万个 Token。而传统的嵌入方法往往会遗漏与查询相关但在语义上并不相似的工具，导致召回率存在天然上限。这就引出了一个核心议题：如何在不耗尽 Token 的前提下，让 Agent 在海量工具中精准、高效地找到所需服务？为了解决这一痛点，在本次大会中，Wei Zheng 将介绍openJiuwen A2X Registry，探讨如何为 MCP 服务提供更高效的注册与发现机制，为 Agent 与工具之间的大规模连接建立更具工程化的基础。华为公开资料也将 A2X Registry 列为 openJiuwen Agent Protocol 中用于 Agent 互操作的重要组成部分。演讲主题：openJiuwen A2X Registry: An Efficient MCP Service Registration and Discovery Solution演讲嘉宾：Wei Zheng｜Huawei华为高级工程师，领导开源项目openJiuwen A2X Registry。 多智能体协同：从“一个 Agent”到“一支 Agent 团队”AI Agent 的工程范式正在持续演进。从 Prompt Engineering 到 Context Engineering，再到当下成为主流的 Harness Engineering，单智能体的"驾驭与治理"已经形成了相对清晰的方法论体系。但当任务复杂度跨越单Agent 的能力边界，需要多个智能体分工协作来完成时，原有的工程方法论便不再适用。如何让多个智能体自主分工、高效沟通、无缝协作？成功的协同模式又如何沉淀、复用并持续演进？这就引出了一个核心议题：AI Agent 工程范式从单智能体走向多智能体团队协同之后，开发和运行方式将发生怎样的下一次飞跃？为了回答这个问题，在本次大会中，程烁（Shuo Cheng） 将带来主题分享，探讨这一新阶段的核心命题——Coordination Engineering（协同工程）。他认为，协同工程不是对 Harness Engineering 的替代，而是其在团队协作维度上的自然延伸。AI Agent 工程范式从单智能体走向多智能体团队协同之后，开发和运行方式可能会再次发生变化。华为支持的 openJiuwen 社区目前也正围绕 Agent Team、团队技能沉淀以及协同自演进等方向展开实践。演讲主题：Coordination Engineering：AI Agent 工程范式的下一次跃迁演讲嘉宾：程烁｜Huawei就职于华为2012实验室，专注于 AI Agent 工程化与多智能体协同方向的探索与落地，是Coordination Engineering 理念在开源社区落地的核心推动者之一。 不止华为：两天大会，深入 Agentic AI 的九大技术方向AGNTCon + MCPCon China 的议程并不只讨论“大模型”或单一 Agent 应用，而是进一步进入 Agent 真正落地时必须解决的工程问题。本届大会设置了九大技术方向，涵盖从开发、协议与基础设施，到测试、可靠性、安全、企业采用及多智能体系统等不同层面： 智能体商业构建 智能体工程 构建可靠的智能体系统 企业落地实践 智能体评估与测试 人机协作 互操作性与标准 MCPCon：聚焦MCP最新演进 多智能体与分布式系统 提前规划两天的技术议程，可以从这里开始：👉了解更大会完整议程https://www.lfopensource.cn/mcp-dev-summit-shanghai/program/schedule/👉了解更多关于九大技术路径议题AI智能体如何真正落地？AGNTCon + MCPCon China揭晓九大技术路径👉了解更多智能体实际部署过程中的关键问题精选议程抢先看｜五场技术分享，直击智能体落地关键问题更多演讲嘉宾、技术分享、案例讨论及工作坊内容，请以大会官方网站公布的信息为准。 75张免费门票限时开放｜现在就行动AAIF Community 微信读者专享：75张 AGNTCon + MCPCon China 免费门票报名时输入微信专属代码：ACH26WECHAT即可享受本次免费参会机会。仅限前75位成功注册者，额满即止。👉立即注册报名，锁定席位（复制链接至浏览器打开）https://www.lfopensource.cn/mcp-dev-summit-shanghai/register/👉查看完整会议议程（复制链接至浏览器打开）https://www.lfopensource.cn/mcp-dev-summit-shanghai/program/schedule/👉了解主题演讲嘉宾（复制链接至浏览器打开）https://www.lfopensource.cn/mcp-dev-summit-shanghai/program/featured-keynote-speakers/ AGNTCon + MCPCon China 2026会议日期： 2026年9月6日至7日 会议场地： 上海国际会议中心 交通地址： 上海市浦东新区滨江大道2727号大会主题：Agentic AI + Model Context Protocol（MCP）从 MCP 和开放协议，到 Agent 工程、基础设施、多智能体系统、可靠性与企业生产实践，两天时间，与正在真正构建 Agentic AI 技术栈的开发者和技术团队面对面。 Agentic AI 的技术栈正在被重新定义。9月6日至7日，上海见。

9月7日至9日，全球云原生与 AI 基础设施顶级盛会 KubeCon + CloudNativeCon + OpenInfra Summit + PyTorch Conference China 2026 将于上海国际会议中心召开，CNCF、OpenInfra、PyTorch 三大基金会首次齐聚，云原生、开放基础设施与 AI 三大技术生态将在同一会场交汇。本届会上，Volcano社区将在议题演讲、展览展示等区域全方位与开发者展开技术交流。 随着AI大模型与Agent应用加速迈入生产环境，传统云原生架构在面对分布式推理部署、异构算力碎片化以及 RL/Agent高并发短生命周期任务时，都难以满足需求。针对低时延和高资源利用率等需求，Volcano社区构建了一套涵盖集群调度、推理服务部署到Agent运行时的完整云原生AI技术栈，实现通智一体化调度。 期待在会上与大家面对面交流 。  Volcano 议题预告  ▍Serving AI at Massive Scale: The Cloud-Native Inference Plane Behind Huawei Celia演讲者：Kevin Wang (CNCF TOC Vice Chair, Lead of Cloud Native Open Source, Huawei )时间地点：9月9日 11:00-11:30 | Mandarin Hall I议题看点：深入解析华为小艺（Celia）背后的云原生推理面架构。探讨华为如何依托云原生技术打造高并发、高可用的大规模 AI 推理服务平台，并分享在大规模真实业务场景下的调度优化与算力运维实践经验▍Volcano: A Unified Scheduling Platform for Cloud Native AI演讲者：Zicong Chen ( Volcano Maintainer, Software Engineer, Huawei Cloud); DongYang Wang(Cloud Native AI Infrastructure Engineer, SenseTime)时间地点：9月9日16:15-16:45 | 5B + C议题看点：详细剖析 Volcano 作为统一调度平台的核心架构与演进路径。分享如何通过 Volcano 统一管理和调度异构算力资源，兼顾云原生 AI 场景中复杂且多样的训练、推理及 Batch 工作负载，提升整体集群利用率▍Accelerating RL with AgentCube: Cloud-Native Multi-Agent Collaboration演讲者：Zhencheng Lee (Senior Cloud Develop Engineer, Huawei Cloud)时间地点：9月9日11:00-11:20 | 5B + C议题看点：聚焦强化学习（RL）与多智能体（Multi-Agent）协同场景的性能瓶颈。探讨如何结合 AgentCube 极速沙箱技术与弹性预热池，解决多 Agent 高并发运行时的容器拉起延迟，从而全面加速多智能体环境下的训练与协同执行▍Beyond Model Sharding: Atomic Scheduling and Disaggregated LLM Serving with LeaderWorkerSet演讲者：Kay Yan (Principal Software Engineer, DaoCloud) ；Zicong Chen( Volcano Maintainer, Huawei Cloud )时间地点：9月8日13:45-14:15  |  5B + C议题看点：超越传统的模型切分技术，探讨大模型服务中基于 LeaderWorkerSet 的原子调度模式。同时深入分析 Prefill-Decode（PD）分离式大模型推理架构的技术细节与最佳落地实践。  Volcano 展台交流  ▍CNCF 项目展区:展位位置： Grand Ballroom I CNCF 展区 T-2 Volcano 展台开放时间：  9月8日 15:00-19:00；9月9日 13:15 - 15:30展台亮点：Volcano 社区核心人员驻场，面对面交流云原生 AI 统一调度、Agent 极速拉起与异构算力管理的最新成果与行业案例，欢迎现场来聊▍展商展区同时，在大会的华为展区“面向 Agentic AI 的容器基础设施”展台，您也可以现场体验Volcano社区企业级最新应用，解锁容器 AI 新引擎：展位位置： Grand Ballroom 1 华为展区开放时间：  9月8日 10:30-19:00；9月9日 10:30-15:30 🌋 Volcano （cid:link_0）是 CNCF 首个批量计算项目，也是业界领先的云原生统一调度平台。Volcano 已从批量调度引擎演进为通智融合调度系统，面向 AI 训练、大模型推理、Agentic AI、大数据、基因测序等多样化工作负载提供统一的高性能调度能力，对 Spark、Flink、Ray、TensorFlow、PyTorch、Kubeflow、MPI、PaddlePaddle、MindSpore 等主流计算框架均有完善支持。社区在GitHub上已获得 6.9k+ Star 和 2.4K+ Fork，参与贡献企业包括华为、AWS、百度、腾讯、京东、小红书、bilibili 等。9月8日-9日上海，KubeCon + CloudNativeCon + OpenInfra Summit + PyTorch Conference China 2026 现场见！更多精彩议题，访问大会官网程：https://www.lfopensource.cn/kubecon-cloudnativecon-openinfra-summit-pytorch-conference-china/program/schedule/ 关注魔方公众号，获取更多前沿资讯

华为云容器引擎 CCE 近期推出多项核心能力新增和升级，从 AI 容器、备份中心、Gateway API、集群自动升配、负载感知调度等全面进化您的云原生体验，助力业务高效、稳定、安全地运行。即刻访问体验：cid:link_1 

9月8日至9日，全球云原生与 AI 基础设施顶级盛会 KubeCon + CloudNativeCon + OpenInfra Summit + PyTorch Conference China 2026 将于上海国际会议中心举行，CNCF、OpenInfra、PyTorch 三大基金会首次齐聚，云原生、开放基础设施与 AI 三大技术生态将在同一会场交汇。本届大会值得关注的变化，是焦点从“模型能力”推进到了“Agent 规模化落地”——当 Agent 成为企业生产力的组成部分，从算力调度到智能体平台，技术栈的各层能力都在向 Agent 场景持续优化和适配。作为战略级赞助商，华为将在会上全方位分享从算力底座到智能体应用等开源创新与产业实践，既有通智融合调度、多云算力池化、云边AI协同、Agentic AI 容器等开源基础设施层面的深耕，也有企业级智能体平台的商用赋能。本文与你一探究竟： ▍01 面向 AI 训推、RL、Agent 的全场景统一调度大模型与智能体应用正加速迈向生产环境，传统云原生架构在面对万卡扩展性、异构算力碎片化以及 RL/Agent 高并发短生命周期任务时，面临高延迟与资源浪费等挑战。针对这些智算瓶颈，华为云开源技术团队协同社区伙伴，以 CNCF Volcano 为内核，给出了一套解法——构建一条从集群调度、推理服务到 Agent 运行时的完整云原生 AI 技术栈，实现通智一体化调度：调度层，夯实通智一体调度基座：Volcano 在成熟的云原生批量调度能力基础上，面向高并发、短生命周期的 Agent 任务推出 Agent Scheduler，通过多 Worker 并行调度与乐观并发控制提升调度效率；结合 NodeShard 动态节点分片与队列管理，实现 Batch Scheduler 和 Agent Scheduler 的资源协同，兼顾训练作业的规模化运行与推理、Agent 任务的快速响应，形成训推一体、通智协同的调度最佳实践。推理层，突破大模型推理瓶颈：面向 LLM 生产部署的推理服务平台 Kthena 支持 PD 分离部署与PD场景下的自动扩缩容。支持多种可组合的流量路由策略，兼容 vLLM/SGLang 等主流推理引擎， 在复杂对话场景下可帮助企业降低 20% 以上的全局延迟。运行时层，专为 AI Agent 打造的弹性沙箱引擎：Volcano 社区面向 Agent 工作负载的 AgentCube，原生支持 AI Agent 的轻量级与有状态运行时；以预热池（Warm Pool）技术实现隔离容器毫秒级拉起，为多 Agent 并发协同提供类 Serverless 的极速体验。现场相关议题，欢迎关注：🎙️ 议题：Serving AI at Massive Scale: The Cloud-Native Inference Plane Behind Huawei Celia[1]  (Kevin Wang, CNCF TOC Vice Chair , Tech Lead of Cloud Native Open Source， Huawei )🎙️议题：Volcano: A Unified Scheduling Platform for Cloud Native AI[2] ( Zicong Chen, Volcano Maintainer, Software Engineer at Huawei Cloud; DongYang, WangCloud Native AI Infrastructure Engineer,SenseTime)🎙️ 议题：Accelerating RL with AgentCube: Cloud-Native Multi-Agent Collaboration[3]（Zhencheng Lee,Senior Cloud Develop Engineer at Huawei Cloud）🎙️议题：Beyond Model Sharding: Atomic Scheduling and Disaggregated LLM Serving with LeaderWorkerSet[4] (Kay Yan， Principal Software Engineer, DaoCloud； Zicong Chen , Volcano Maintainer, Software Engineer at Huawei Cloud）📍 欢迎打卡 Volcano 社区展台（9月8日15:00-19:00，9月9日 13:15-15:30，T-2，Grand Ballroom I ） 与技术大咖面对面，来自华为云等企业的社区专家将现场探讨云原生 AI 调度的前沿方向与实践经验。 ▍02 打破资源边界，跨云 AI 算力池化算力不应该被困在单一集群里。当企业同时拥有公有云、私有云与边缘节点，算力管控的复杂度随拓扑同步上升：训练任务需要弹性，推理任务需要就近，业务高峰需要冗余。云原生多云编排引擎 Karmada  正成为企业构建跨云“超级 AI 算力池”的核心纽带，让算力在不同环境之间按需流动：海量 AI 任务跨集群动态分发：通过 Karmada 统一联邦控制面，根据公有云、私有云及边缘端的异构算力空闲度，自动分发大规模 AI 训练与推理任务，让算力匹配任务，而不是让任务迁就集群。生产级高可用与渐进式交付：联合 Argo 实现单一声明式规范下的跨云 Canary 灰度发布；支持有状态工作负载在集群故障时平滑迁移与数据恢复，为跨云生产环境提供可靠性保障。🎙️ 议题：Building a Multi-Cluster Progressive Delivery Platform with Karmada & Argo[5] (Zhuang Zhang, Karmada Maintainer, Software Engineer at Huawei  Cloud)🎙️ 议题：Karmada Project Lightning Talk[6]（Hongcai Ren, Karmada Maintainer，Senior Software Engineer at Huawei Cloud; Maintainer, Yiheng Ci ）🎙️ 议题：Multi-cluster Orchestration System: Karmada Updates and Use Cases[7]（Hongcai Ren, Karmada Maintainer，Senior Software Engineer at Huawei Cloud; Zongqing Li,Senior Cloud-Native R&D Engineer, Trip.com ）📍 华为云技术人员将在 Karmada 社区展台（9月8日 10:30-14:30, 9月9日 10:30-12:45, T-2,Grand Ballroom I ） 驻场，与现场开发者共同探讨分布式云原生与多云 AI 算力池化的技术与案例，欢迎现场交流。 ▍03 云边协同：KubeEdge驱动边缘AI规模化演进作为 CNCF 首个毕业的云原生边缘计算项目，KubeEdge 已广泛应用于交通、能源、制造、航天、汽车等各行各业。本届大会，来自华为云，Harmony Cloud 和 VMware 的 KubeEdge TSC 成员将联合带来“毕业报告”式的深度分享。核心架构层面，解析 KubeEdge 如何通过松耦合设计高效管理海量边缘节点与应用；落地实践层面，直面智慧城市、工业物联网 (IIoT)、边缘人工智能、机器人和零售等多个行业的实际部署案例场景真实挑战，分享应对策略；生态层面，解读全新发布的 Certified KubeEdge 一致性认证体系及社区治理的最新动态，为计划规模化落地边缘AI的企业提供参考路径。🎙️ 议题：Solving Industrial Challenges with KubeEdge: A Post-Graduation Report[8]（Yue Bao, Senior Software Engineer at Huawei Cloud; Huan Wei, Senior Technical Director, Harmony Cloud; Yin Ding, Engineering Leader at VMware ） ▍04 赋能企业级智能落地，华为云 AgentArts 等产品重磅亮相作为本届 KubeCon 的重要看点之一，华为云智果 AgentArts 智能体平台、 华为云果办 OfficeAce 办公智能体 、openJiuwen 等一系列智能体相关的产品与创新技术也将重磅亮相。华为云智果（AgentArts）是面向企业级 AI Agent 的全生命周期工程与运行底座，助力企业快速构建、部署和运营能自主执行任务的AI智能体。它向下纳管计算与模型资源，提供完整的 Agent 托管能力。向上对编排、运行与运维进行标准化，通过引入多层控制器、自进化、Agent 认证鉴权、Agent 记忆、会话级隔离、动态令牌和精细化权限控制等机制，解决 Agent 落地生产环境时的工程化与合规难题，为智能体的高并发调度、复杂流程执行、数据安全合规及自动化运维提供标准化、可观测的 Harness 基础设施支撑。openJiuwen 与 AgentArts 内核同源度超过 90%，通过开放核心框架和底层能力，大幅降低了企业及软件开发服务商的二次开发门槛，支持开发者基于开源版本构建本地化、兼容企业生态的智能体应用。其 WorkSwarm 蜂群智能体的多任务模式与高效协同，结合 Coordination Engineering 的多智能体标准化范式 与 Agent Swarm 的双层协同自演进机制，在底层算力亲和加速的保障下 ，全面助力智能体快速构建与应用，携手行业伙伴共同打造智能体生态。华为云果办（OfficeAce）是一款面向个人与企业用户的办公全场景智能体，以AI重构桌面办公体验，通过自动化处理重复事务、智能整合信息及协作辅助，为企业员工打造具备专业 Skills 技能的 Agent 专家团队，将用户从繁琐操作中解放出来，大幅提升办公效率；同时，面向企业提供智能体接入、统一运营、安全治理等企业级能力，推动 AI 从单点办公辅助融入真实业务流程，实现规模化应用。🎙️ 议题：openJiuwen A2X Registry: An Efficient MCP Service Registration and Discovery Solution[9] ( Wei Zheng,Senior Engineer, Huawei)🎙️ 议题：Coordination Engineering：The Next Leap of AI Agent Engineering Paradigm[10] (Shuo Cheng, Agent Technical Expert, Huawei)📍 欢迎亲临华为云“智能体全栈平台 Full-Stack Agent Platform”展台（9月8日-9日，Grand Ballroom I 华为展区），现场体验华为云智能体平台从开发、部署到运营的全流程能力。 ▍05 AI 算力底座：面向 Agentic AI 的容器基础设施作为全球云原生与 AI 领域的先驱者与 CNCF 创始成员，华为云凭借多年来的产业实践和技术创新，引领面向 Agentic AI 的容器基础设施，为企业级 Agent 运行提供调度、弹性与安全的一体化支撑，并以丰富的商用落地实践，为智能体规模化应用持续赋能：在调度层面，基于 Volcano 实现 CPU 与 GPU 异构算力的统一调度，满足 AI 训练、推理及 Agent 任务对计算资源的差异化需求。在安全隔离层面，升级 Agent Sandbox 安全沙箱技术，实现轻量级隔离与亚秒级极速冷启动，为高频工具调用与动态代码执行提供全链路安全保障。弹性层面，依托 CCE Turbo 的极速扩容、资源预热与异构算力加速能力，结合 CCE Autopilot 与 CCI 的 Serverless 容器弹性，提供从资源预热、亚秒级扩容到超大资源池的端到端弹性能力，从容应对 Agent 任务突发流量与资源洪峰。同时，华为云 AI 容器团队持续参与 Volcano、Karmada、KubeEdge、Kmesh 等开源社区的贡献与建设，推动云原生技术生态从 AI Native 向 Agentic Native 演进。📍 欢迎打卡 KubeCon China 2026 “面向 Agentic AI 的容器基础设施”展台（9月8日-9日，Grand Ballroom 1 华为展区）， 现场直击 CCE Autopilot + CCI 秒级弹性伸缩与 Agent Sandbox 安全隔离实效，解锁企业级容器 AI 新引擎。从开源社区的前沿探索到企业级商用落地，华为云全栈架构创新极致重构 AI 算力底座，让智能体跑在坚实的算力底座上，也让平台能力真正转化为企业生产力，为千行万业在 Agentic AI 时代的智能化转型提供澎湃动力。期待与您共赴 KubeCon + CloudNativeCon + OpenInfra Summit + PyTorch Conference China 2026，共探 Agent 时代无尽可能！👉 访问大会官网获取完整议程：https://www.lfopensource.cn/kubecon-cloudnativecon-openinfra-summit-pytorch-conference-china/program/schedule/议题索引[1] Serving AI at Massive Scale: The Cloud-Native Inference Plane Behind Huawei Celia:https://www.lfopensource.cn/kubecon-cloudnativecon-openinfra-summit-pytorch-conference-china/program/schedule/?id=1224671[2] Volcano: A Unified Scheduling Platform for Cloud Native AI: https://www.lfopensource.cn/kubecon-cloudnativecon-openinfra-summit-pytorch-conference-china/program/schedule/?id=1222060[3] Accelerating RL with AgentCube: Cloud-Native Multi-Agent Collaboration: https://www.lfopensource.cn/kubecon-cloudnativecon-openinfra-summit-pytorch-conference-china/program/schedule/?id=1304033[4] Beyond Model Sharding: Atomic Scheduling and Disaggregated LLM Serving with LeaderWorkerSet: https://www.lfopensource.cn/kubecon-cloudnativecon-openinfra-summit-pytorch-conference-china/program/schedule/?id=1222146[5] Building a Multi-Cluster Progressive Delivery Platform with Karmada & Argo: https://www.lfopensource.cn/kubecon-cloudnativecon-openinfra-summit-pytorch-conference-china/program/schedule/?id=1225153[6] Karmada Project Lightning Talk: https://www.lfopensource.cn/kubecon-cloudnativecon-openinfra-summit-pytorch-conference-china/program/schedule/?id=1222021[7] Multi-cluster Orchestration System: Karmada Updates and Use Cases:https://www.lfopensource.cn/kubecon-cloudnativecon-openinfra-summit-pytorch-conference-china/program/schedule/?id=1222012[8] Solving Industrial Challenges with KubeEdge: A Post-Graduation Report: https://www.lfopensource.cn/kubecon-cloudnativecon-openinfra-summit-pytorch-conference-china/program/schedule/?id=1225125[9] openJiuwen A2X Registry: An Efficient MCP Service Registration and Discovery Solution:https://www.lfopensource.cn/mcp-dev-summit-shanghai/program/schedule/?id=1242199[10] Coordination Engineering：The Next Leap of AI Agent Engineering Paradigm: https://www.lfopensource.cn/mcp-dev-summit-shanghai/program/schedule/?id=1227642 关注魔方公众号，获取更多前沿资讯

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