📝摘要：Volcano云原生批量计算社区在业界率先提出网络拓扑感知调度（Network Topology Aware Scheduling）策略，通过统一的网络拓扑API和智能调度策略，解决大规模数据中心AI训练任务的网络通信性能问题，同时引入了基于节点标签（Label）的 超节点HyperNode 自动发现机制。该功能为用户提供了一种通用且灵活的方式来描述网络拓扑，将复杂的拓扑管理工作转变为简单的节点标签管理，确保在复杂工作负载管理中的实用性和易用性，为AI时代的基础设施提供关键调度支撑。Volcano （https://volcano.sh）是业界首个云原生批量计算引擎，也是 CNCF 首个和唯一的批量计算项目。作为云原生批量计算领域的事实标准，Volcano已经在AI、大数据及高性能计算 (HPC) 等多种场景中获得广泛应用，吸引了来自30多个国家的800多名贡献者，累计代码提交数万次。Volcano已在国内外60+企业进行了生产落地，赢得了用户的广泛赞誉，为业界提供了云原生批量计算的卓越实践标准与解决方案。本文解析Volcano社区的网络拓扑感知调度能力。早在2025年1月Volcano社区发布的v1.11版本中，社区聚焦AI与大数据的核心需求，推出网络拓扑感知调度、多集群AI作业调度等重磅特性，显著提升AI训练与推理任务的性能。同时，在离线混部与动态资源超卖及负载感知重调度功能进一步优化资源利用率，确保在线业务的高可用性。此外，弹性层级队列为大数据场景提供了更灵活的调度策略。    网络拓扑感知调度：优化AI大模型训练性能   在AI大模型训练场景中，模型并行（Model Parallelism）将模型分割到多个节点上，训练过程中这些节点需要频繁进行大量数据交互。此时，节点间的网络传输性能往往成为训练的瓶颈，显著影响训练效率。数据中心的网络类型多样，如InfiniBand (IB)、RoCE、NVSwitch等，且网络拓扑复杂，通常包含多层交换机。两个节点间跨的交换机越少，通信延迟越低，吞吐量越高。因此，用户希望将工作负载调度到具有最高吞吐量和最低延迟的最佳性能域，尽可能减少跨交换机的通信，以加速数据交换，提升训练效率。为此，Volcano提出了网络拓扑感知调度（Network Topology Aware Scheduling）策略，通过统一的网络拓扑API和智能调度策略，解决大规模数据中心AI训练任务的网络通信性能问题。▍统一的网络拓扑API：精准表达网络结构为了屏蔽数据中心网络类型的差异，Volcano定义了新的CRD HyperNode来表示网络拓扑，提供了标准化的API接口。与传统的通过节点标签（label）表示网络拓扑的方式相比，HyperNode具有以下优势：语义统一：HyperNode提供了标准化的网络拓扑描述方式，避免了标签方式的语义不一致问题。层级结构：HyperNode支持树状层级结构，能够更精确地表达实际的网络拓扑。易于管理：集群管理员可以手动创建HyperNode，或通过网络拓扑自动发现工具维护HyperNode。一个HyperNode表示一个网络拓扑性能域，通常映射到一个交换机。多个HyperNode通过层级连接，形成树状结构。例如，下图展示了由多个HyperNode构成的网络拓扑：叶子HyperNode（s0、s1、s2、s3）：子节点为集群中的真实节点。非叶子HyperNode（s4、s5、s6）：子节点为其他HyperNode。在这种结构中，节点间的通信效率取决于它们之间的HyperNode层级跨度。例如：node0和node1同属于s0，通信效率最高。node1和node2需要跨两层HyperNode（s0→s4→s1），通信效率较低。node0和node4需要跨三层HyperNode（s0→s4→s6），通信效率最差。💬 HyperNode配置示例以下是一个叶子HyperNode和非叶子HyperNode的配置示例：💬 叶子HyperNode示例：apiVersion: topology.volcano.sh/v1alpha1kind: HyperNodemetadata: name: s0spec: tier: 1 # HyperNode层级，层级越低通信效率越高 members: # 子节点列表 - type: Node # 子节点类型为Node selector: exactMatch: # 精确匹配 name: node-0 - type: Node selector: regexMatch: # 正则匹配 pattern: node-[01]💬 非叶子HyperNode示例：apiVersion: topology.volcano.sh/v1alpha1kind: HyperNodemetadata: name: s6spec: tier: 3 # HyperNode层级 members: # 子节点列表 - type: HyperNode # 子节点类型为HyperNode selector: exactMatch: # 精确匹配 name: s4 - type: HyperNode selector: exactMatch: name: s5▍ 基于网络拓扑的感知调度策略Volcano Job和PodGroup可以通过 networkTopology 字段设置作业的拓扑约束，支持以下配置：mode：支持 hard 和 soft 两种模式。hard：硬约束，作业内的任务必须部署在同一个HyperNode内。soft：软约束，尽可能将作业部署在同一个HyperNode下。highestTierAllowed：与 hard 模式配合使用，表示作业允许跨到哪层HyperNode部署。例如，以下配置表示作业只能部署在2层及以下的HyperNode内（如s4或s5），否则作业将处于Pending状态：spec:  networkTopology:    mode: hard    highestTierAllowed: 2通过这种调度策略，用户可以精确控制作业的网络拓扑约束，确保作业在满足条件的最佳性能域运行，从而显著提升训练效率。  网络拓扑感知调度 (Alpha Release) 在Volcano v1.12 中, 网络拓扑感知调度功能达到 Alpha 发布状态。此功能旨在优化大规模训练和推理场景（如模型并行训练、Leader-Worker 推理）中 AI 任务的部署。它通过将任务调度到同一网络拓扑性能域内，减少跨交换机通信，从而显著提升任务效率。Volcano 使用 超节点HyperNode CRD 来抽象和表示异构硬件网络拓扑，并支持层级结构以方便管理。v1.12 版本集成了以下关键特性：Volcano超节点 HyperNode 自动发现 (HyperNode Auto-Discovery)： Volcano 提供了集群网络拓扑的自动发现能力。用户可配置发现类型，系统将自动创建和维护反映集群真实网络拓扑的层级 HyperNode。目前支持 InfiniBand (IB) 网络下通过 UFM (Unified Fabric Manager) 接口获取网络拓扑信息，并自动更新 HyperNode。未来计划支持 RoCE 等更多网络协议。 Volcano超节点 HyperNode 优选策略 (Prioritized HyperNode Selection)： 引入了基于节点级别和 HyperNode 级别的打分策略，累加后作为 HyperNode 的最终得分。 节点级别 (Node-level)： 建议配置 BinPack 插件以优先填满 HyperNode，减少资源碎片。 超节点HyperNode 级别 (HyperNode-level)： 优先选择层级更低的 HyperNode 以获得更优性能，因其涉及的跨交换机次数较少；对于相同层级的 HyperNode，包含更多任务的 HyperNode 得分更高，旨在减少 HyperNode 级别的资源碎片。 支持通过 Label Selector 匹配节点 (Support for Label Selector Node Matching)： HyperNode 叶子节点与集群中的物理节点关联，支持以下三种匹配策略： 精确匹配 (Exact Match)： 直接匹配节点名称。 正则匹配 (Regex Match)： 通过正则表达式匹配节点名称。 标签匹配 (Label Match)： 通过标准 Label Selector 匹配节点。  Volcano v1.13 提供更灵活的网络拓扑发现机制  Volcano v1.13 提供更灵活的网络拓扑发现机制，并增强对主流AI计算框架的兼容性。继v1.12 版本中正式推出了网络拓扑感知调度能力，并率先实现了基于 InfiniBand (IB) 网络的 UFM 自动发现机制后，v1.13版本引入了基于节点标签（Label）的 超节点HyperNode 自动发现机制。该功能为用户提供了一种通用且灵活的方式来描述网络拓扑，将复杂的拓扑管理工作转变为简单的节点标签管理。该机制允许用户在 volcano-controller-configmap 中定义拓扑层级与节点标签的对应关系。Volcano 控制器会周期性地扫描集群中的所有节点，并根据其标签自动完成以下工作：自动构建拓扑：根据节点上的一组标签，从上至下（例如：机架 -> 交换机 -> 节点）自动构建出多层 HyperNode 拓扑结构。动态维护：当节点的标签发生变化，或节点被添加、移除时，控制器会自动更新 HyperNode 的成员和结构，确保拓扑信息始终与集群状态保持一致。支持多种拓扑类型：允许用户同时定义多种独立的网络拓扑，以适应不同的硬件集群（如 GPU 集群、NPU 集群等）或不同的网络分区。💬 配置示例：# volcano-controller-configmap.yamlapiVersion: v1kind: ConfigMapmetadata: name: volcano-controller-configmap namespace: volcano-systemdata: volcano-controller.conf: | networkTopologyDiscovery: - source: label enabled: true interval: 10m # 发现周期 config: networkTopologyTypes: # 定义一个名为 topology-A 的拓扑类型 topology-A: # 定义拓扑层级，顺序从上到下 - nodeLabel: "volcano.sh/hypercluster"# 顶层 HyperNode - nodeLabel: "volcano.sh/hypernode" # 中间层 HyperNode - nodeLabel: "kubernetes.io/hostname"# 底层物理节点 通过在 Volcano 控制器的 ConfigMap 中添加 label 源即可启用此功能。以下配置定义了一个名为 topology-A 的三层拓扑结构：顶层 (Tier 2) ：由 volcano.sh/hypercluster 标签定义。中间层 (Tier 1) ：由 volcano.sh/hypernode 标签定义。底层 ：物理节点，由 Kubernetes 内置的 kubernetes.io/hostname 标签标识。当一个节点被打上如下标签时，它将被自动识别并归入 cluster-s4 -> node-group-s0 的拓扑路径下：# 节点 node-0 的标签labels: kubernetes.io/hostname: node-0 volcano.sh/hypernode: node-group-s0 volcano.sh/hypercluster: cluster-s4基于label的网络拓扑自动发现功能具有出色的通用性与灵活性，不依赖于特定的网络硬件（如 IB），因此适用于各类异构集群，并允许用户通过标签灵活定义任意深度的层级结构。它将复杂的拓扑维护工作转变为简单的节点标签管理，实现了自动化，从而显著降低运维成本和出错风险。此外，该机制能够动态适应集群节点和标签的变化，无需人工干预即可实时保持拓扑信息的准确性。📌 使用文档请参考：HyperNode Auto Discovery：cid:link_0相关PR：cid:link_1▍将网络拓扑感知调度能力扩展至 Kubernetes 标准工作负载在Volcano v1.13 版本中，Volcano 的网络拓扑感知调度能力不再局限于 Volcano Job。现在，也可以为 Kubernetes 的标准工作负载（如 Deployment、StatefulSet 等）配置网络拓扑约束。该功能通过 Pod 模板中的注解（Annotation）实现。当为 Deployment 或 StatefulSet 的 Pod 模板添加网络拓扑相关的注解后，Volcano 的 podgroup-controller 会自动为这些 Pod 创建一个PodGroup，并将注解中定义的网络拓扑约束继承到 PodGroup 的规约（Spec）中，从而在调度时应用相应的网络亲和性策略。可以通过以下两个注解来配置网络拓扑感知调度：Annotation Key描述示例值topology.volcano.sh/network-topology-mode定义网络拓扑约束的模式。hard 表示强制约束，Pod 必须满足拓扑要求才能被调度；soft 表示软约束，调度器会尽量满足，但不强制。默认为 hard。"hard"topology.volcano.sh/network-topology-highest-tier指定允许调度的最高网络层级。例如，设置为 "2" 表示 Pod 可以被调度到 2层及以下的HyperNode上，但不能调度到更高层级的HyperNode。"2"💬 Deployment 配置示例以下示例展示了如何为一个 Deployment 配置网络拓扑感知调度。调度器将把该 Deployment 的 Pod 调度到网络层级不超过 2 的节点上：apiVersion: apps/v1kind: Deploymentmetadata: name: network-aware-deploymentspec: replicas: 3 selector: matchLabels: app: my-app template: metadata: labels: app: my-app annotations: # 设置网络拓扑为硬约束 topology.volcano.sh/network-topology-mode: "hard" # 设置允许调度的最高网络层级为 2 topology.volcano.sh/network-topology-highest-tier: "2" spec: # 必须指定调度器为 volcano schedulerName: volcano containers: - name: main-container image: nginx:latest resources: requests: cpu: "1" memory: "1Gi" limits: cpu: "1" memory: "1Gi"Volcano社区网络拓扑感知调度能力大大提升了Volcano在复杂工作负载管理中的实用性和易用性，为AI时代的基础设施提供关键调度支撑。更多Volcano社区网络拓扑感知调度能力，可以访问🔗社区地址：cid:link_2  更多云原生技术动向关注容器魔方 

CNCF 云原生多云容器编排引擎 Karmada 再迎社区用户组新成员，共绩科技[1]正式加入。 Karmada 致力于为用户提供强大的多集群管理和调度能力，帮助企业在复杂的分布式环境中实现高效的应用部署和管理。 共绩科技的加入将进一步加强 Karmada 社区，为项目的持续创新带来新的活力，标志着社区发展及 Karmada 在多样化生产环境中采用的又一个重要里程碑。   关于共绩科技  共绩科技 2023 年成立于清华，专注于构建融合算力与电力的智能调度网络，旨在提供平价、可靠、绿色的算力服务，使 AI 技术真正普及至每个人。 通过精细调度算法，共绩科技已为多家 AIGC 领军企业及科研机构提供高效算力，目标提升资源利用率 60% 。作为一群清华背景的年轻创新者，他们在 2023 年秋季获得奇绩创坛等投资，正引领算力革命，开启普惠科技新篇章。  关于 Karmada 用户组  作为连接社区与用户的核心纽带，Karmada 用户组致力于打造一个深度融合、开放协作的高价值平台，推动成员间的高效联动与经验共享。通过技术支持、活动共创及最佳实践交流，Karmada 用户组将持续赋能用户在多云管理领域的能力提升，助力云原生多云多集群生态系统的蓬勃发展。成为 Karmada 用户组成员具有以下优势：社区认可：作为云原生多集群管理领域的领导者来展示您的组织，在 CNCF 和 Karmada 社区中获得知名度；促进协作：与其他采用者建立联系，分享最佳实践，并在实际用例和解决方案上进行协作；保持信息同步：及时接收重要更新通知，包括关键功能、错误修复和安全建议；活动参与：受邀参与 Karmada 相关活动，包括 KubeCon + CloudNativeCon、网络研讨会和聚会；职位发布：有机会在 Karmada 社区支持的职位公告板上发布与 Karmada 相关的职位空缺（暂不可用）；扩展商业机会：与 Karmada 生态系统的其他成员建立潜在的商业联系和合作。您可以在 GitHub 社区仓库中了解更多关于 Karmada 用户组[2] 的信息， 并在 karmada.io/adopters [3] 查看完整的公开的采用者列表。截至目前，Karmada 用户组已吸纳来自全球的 40+ 家机构和组织。更多使用场景及案例研究请查阅：https://karmada.io/adopters   欢迎加入用户组   Karmada 用户组对当前正在生产环境中使用 Karmada 的最终用户和供应商开放。这包括：最终用户：在其生产环境中运行 Karmada 的组织；供应商：提供基于 Karmada 的产品或服务，并有客户在生产环境中使用这些产品或服务的公司。您是否在生产环境中使用 Karmada 并有兴趣加入 Karmada 用户组？访问下方 Karmada 用户组申请表单 [4]，提交 issue 申请，即可接收申请进度。手机端可扫描下方二维码快捷填写申请表单。扫码申请加入用户组Karmada（https://karmada.io/）是 CNCF 首个跨云跨集群容器编排引擎，由华为云、工商银行、小红书、中国一汽等八家企业联合发起。Karmada的贡献企业与贡献者遍布全球 22 个国家和地区的 100 多个组织，包括华为、道客、浙江大学、腾讯、滴滴、Bloomberg、Yunhorn、携程等。截至目前，项目在 GitHub 上已获得 5.2k+Star。如需了解更多关于 Karmada Adopter Group 的信息，可添加社区小助手 k8s2222，或邮件联系:Maintainer Mailing Listcncf-karmada-maintainers@lists.cncf.io 更多信息，请访问：[1] 共绩科技: https://www.gongjiyun.com/[2] Karmada 用户组: https://github.com/karmada-io/community/tree/main/adopter-group[3] Karmada 采用者列表: http://karmada.io/adopters[4] Karmada 用户组申请表单: cid:link_0 Karmada 是CNCF 首个多云多集群容器编排项目(孵化级），旨在帮助用户像使用单个集群一样轻松管理跨云多集群，让基于 Karmada 的多云方案无缝融入云原生技术生态。社区吸引了来自华为、道客、浙江大学、腾讯、中国电子云、滴滴、Zendesk、携程等100多家公司的全球贡献者，广泛分布于20+国家和地区。Karmada 现已在华为云、道客、兴业数金、中国移动、中国联通、携程、360集团、新浪、中通快递等众多企业单位生产应用，为企业提供从单集群到多云架构的平滑演进方案。Karmada 官网：https://karmada.io/GitHub 地址：https://github.com/karmada-io/karmadaSlack 地址：https://slack.cncf.io/（#karmada）  添加社区小助手k8s2222回复Karmada进入技术交流群 

当地时间11月12日，‌在北美亚特兰大召开的 KubeCon + CloudNativeCon North America 2025 大会上，华为云云原生开源负责人王泽锋被全球顶级开源组织云原生计算基金会（ Cloud Native Computing Foundation，简称 CNCF ）授予 “ 终身成就奖 ”（Lifetime Achievement Award）。▲ CNCF 终身成就奖颁奖（左：王泽锋 右：Chris Aniszczyk, CNCF CTO  ）该奖项是 CNCF 最高级别个人荣誉，旨在嘉奖通过技术贡献、社区治理与生态推动对云原生领域产生持久、深远影响的成员。作为该奖项迄今仅有的三位获奖者之一，王泽锋同时成为国内首位获此荣誉的技术专家，这一殊荣不仅是对其杰出成就的高度认可，更标志了华为云云原生、乃至中国开源力量在全球云原生领域的重大突破与卓越影响力。▍持续深耕，创新构建云原生开源项目范式作为中国首位 Kubernetes Maintainer，王泽锋自 2015 年云原生技术尚处于萌芽阶段便开始深耕云原生领域。2015-2018 年，他主导了包括 nodeAffinity、podAffinity、taint-toleration、IPVS-proxy、Kubernetes Federation（即后来的Kubefed）、Poseidon及cluster-api-provider-openstack 等 Kubernetes 多个关键特性与子项目的设计与研发。这些技术创新即刻获得了开源社区的积极响应，并在随后数年中逐步成为企业云原生平台应用的实践标准，展现出持续的业务价值与技术影响力。▲ 华为云云原生开源生态发展2018-2023年，王泽锋所在团队联合发起多个云原生行业代表开源项目：KubeEdge 成为 CNCF 首个云原生边缘计算毕业级开源项目，广泛应用于交通、能源、通信、金融、工业制造、CDN、智慧园区等各行各业，提供领先的边云协同AI智算方案；Volcano 作为业界首个云原生批量计算引擎，在 AI、大数据、HPC等场景展现出显著的技术优势，为 AI 大模型的训练和推理提供了更高效的底层支持；Karmada 是业界首个云原生多云容器编排项目，已被国内外企业大规模生产使用，公开生产落地用户 40+，为云原生多云多集群算力提供强劲动力；持续开源创新：Kurator 为用户提供一体化分布式云原生开源管理能力，Kuasar 多沙箱容器运行时实现云原生业务场景全覆盖，Kmesh 内核级云原生流量治理框架打造 Sidecarless 服务网格业界标杆方案。这些项目填补了相应领域的技术空白，加速云原生普及进程，促进了产业生态的繁荣发展。▍作为 CNCF TOC 副主席，引领全球云原生技术演进2024 年，王泽锋高票当选 CNCF TOC （Technical Oversight Committee）委员，并于 2025 年 5 月成功当选 TOC 副主席，为云原生社区提供技术领导，引领全球云原生技术方向。▲ 2025年5月王泽锋当选 CNCF TOC 副主席，TOC 主席 Karena Angell 致贺任职期间，他推动了多项关键工作：更新CNCF毕业与孵化标准，完成多个项目孵化与毕业尽职调查；组织 KubeCon China 2024 Maintainer 会议、筹备 2025 维护者峰会的 TOC 内容等系列工作，有效促进了全球维护者与 TOC 的协同，对构建和支持 CNCF 技术及社区在全球的健康发展发挥了关键作用。▍开源生态加速AI 时代技术革新，驱动行业智能化跃迁王泽锋所在的华为云云原生团队是全球最早参与 Kubernetes、Istio 等云原生开源项目及产品化的团队之一。华为云提供业界最完整的容器产品矩阵，并率先发布CCE Turbo、CCE Autopilot、云容器实例 CCI 以及分布式云原生服务UCS等多款容器创新产品，连续 5 年蝉联中国容器软件市场份额第一（IDC 2024），入选Gartner®《 2025 容器管理魔力象限 》领导者。开源生态加速 AI 时代技术革新，相信华为云构建的全新一代 AI-Native 云原生基础设施将进一步驱动行业智能化跃迁。▍见证中国开源力量崛起从早期社区贡献者到 CNCF 技术领袖，王泽锋的轨迹与中国云原生技术的崛起历程紧密交织。这份荣誉既是对王泽锋十余年坚持的肯定，更是对中国开源生态的认可。随着云原生与AI技术的深度融合，华为云云原生团队将持续以开源创新推动产业进步。 更多云原生技术动向关注容器魔方  

北京时间2025年11月4日，KubeEdge 发布 1.22.0 版本。新版本对 Beehive 框架以及 Device Model 做了优化升级，同时对边缘资源管理能力做了提升。KubeEdge v1.22.0 新增特性：新增 hold/release 机制控制边缘资源更新 Beehive框架升级，支持配置子模块重启策略  基于物模型与产品概念的设备模型能力升级边缘轻量化 Kubelet 新增 Pod Resources Server 和 CSI Plugin 特性开关C语言版本的 Mapper-Framework 支持升级 K8s 依赖到1.31  新特性概览  ▍新增 hold/release 机制控制边缘资源更新在自动驾驶、无人机和机器人等应用场景中，我们希望在边缘能够控制对边缘资源的更新，以确保在未得到边缘设备管理员的许可下，这些资源无法被更新。在1.22.0版本中，我们引入了 hold/release 机制 来管理边缘资源的更新。在云端，用户可以通过对 Deployment、StatefulSet 和 DaemonSet 等资源添加edge.kubeedge.io/hold-upgrade: "true"的annotation，表示对应的 Pod 在边缘更新需要被 hold。在边缘，被标记了edge.kubeedge.io/hold-upgrade: "true"的 Pod 会被暂缓被处理。边缘管理员可以通过执行以下命令来释放对该 Pod 的锁，完成资源更新。keadm ctl unhold-upgrade pod <pod-name>也可以执行以下命令解锁边缘节点上所有被 hold 的边缘资源keadm ctl unhold-upgrade node💭 注意：使用keadm ctl命令需要启动 DynamicController 和 MetaServer 开关。更多信息可参考：cid:link_1cid:link_2▍Beehive框架升级，支持配置子模块重启策略在1.17版本中，我们实现了 EdgeCore 模块的自重启，可以通过全局配置来设置边缘模块的重启。在1.22版本中，我们对 Beehive 框架进行了升级优化，支持边缘子模块级别的重启策略配置。同时我们统一了 Beehive 各子模块启动的错误处理方式，对子模块能力标准化。更多信息可参考：https://github.com/kubeedge/kubeedge/pull/6444cid:link_3▍基于物模型与产品概念的设备模型能力升级 目前的 Device Model 基于物模型概念设计，而在传统 IoT 中，设备通常采用物模型、产品和设备实例三层结构进行设计，可能导致用户在实际使用中产生困惑。在 1.22.0 版本中，我们结合物模型与实际产品的概念，对设备模型的设计进行了升级。从现有的设备实例中提取了protocolConfigData ,  visitors字段到设备模型中，设备实例可以共享这些模型配置。同时，为了降低模型分离的成本，设备实例可以重写覆盖以上配置。更多信息可参考：cid:link_4cid:link_5▍边缘轻量化 Kubelet 新增 Pod Resources Server 和 CSI Plugin 特性开关 在之前的版本中，我们在 EdgeCore 集成的轻量化 Kubelet 中移除了 Pod Resources Server 能力，但在一些使用场景中，用户希望恢复该能力以实现对Pod的监控等。同时，由于 Kubelet 默认启动 CSI Plugin，离线环境下启动 EdgeCore 会由于 CSINode 创建失败而导致失败。在 1.22.0 版本中，我们在轻量化 Kubelet 中新增了 Pod Resources Server 和 CSI Plugin 特性开关，如果您需要启用 Pod Resources Server 或关闭 CSI Plugin，您可以在 EdgeCore 配置中添加如下特性开关：apiVersion: edgecore.config.kubeedge.io/v1alpha2kind: EdgeCoremodules:  edged:    tailoredKubeletConfig:      featureGates：        KubeletPodResources: true        DisableCSIVolumePlugin: true...更多信息可参考：cid:link_6cid:link_7cid:link_8▍C语言版本 Mapper-Framework 支持 在1.20.0版本中，我们在原有的 go 语言版本 Mapper 工程基础上，新增了 Java 版本的 Mapper-Framework。由于边缘 IoT 设备通信协议的多样性，很多边缘设备驱动协议都是基于 C语言实现的，因此在新版本中，KubeEdge 提供了 C语言版本的 Mapper-Framework，用户可以访问 KubeEdge 主仓库的feature-multilingual-mapper-c分支，利用 Mapper-Framework 生成 C语言版本的自定义 Mapper 工程。更多信息可参考：cid:link_9cid:link_10▍升级 K8s 依赖到1.31新版本将依赖的 Kubernetes 版本升级到v1.31.12，您可以在云和边缘使用新版本的特性。更多信息可参考：cid:link_11▍致谢感谢 KubeEdge 社区技术指导委员会 (TSC)、各 SIG 成员对 v1.22 版本开发的支持与贡献，未来 KubeEdge 将持续在新场景探索与支持、稳定性、安全性、可扩展性等方面持续发展与演进！▍相关链接Release Notes：cid:link_0 添加小助手k8s2222回复KubeEdge进群

  Karmada 是开放的多云多集群容器编排引擎，旨在帮助用户在多云环境下部署和运维业务应用。凭借兼容 Kubernetes 原生 API 的能力，Karmada 可以平滑迁移单集群工作负载，并且仍可保持与 Kubernetes 周边生态工具链协同。Karmada 贡献者广泛分布于 20+ 国家和地区，为企业提供从单集群到多云架构的平滑演进方案。在KCD 杭州站 x OpenInfra Days China 2025，Karmada 社区将在 AI 专场，与您探讨云原生多集群解决方案。演讲主题：多模板遇上多集群：基于 Karmada 的AI大数据应用的资源治理与智能调度演讲嘉宾：Zhuang Zhang (@zhzhuang-zju)，华为云研发工程师，Karmada社区技术专家议题时间：11月15日（周六） 16:45 - 17:15 ·  浙大森林会议中心议题简介：当前，AI 与大数据应用已成为企业技术创新的核心驱动力，这类应用普遍由多个协同组件构成（如作业协调、任务执行等），呈现出典型的“多模板应用”特征——即一个应用或任务会定义多个不同类型的 Pod 模板，每个模板具有不同的资源需求和副本规模，共同组成一个逻辑整体。随着业务规模扩大和容灾需求提升，多集群部署已成为主流趋势。然而，这一演进也带来了严峻的挑战：如何精准感知一个由多个模板组成的应用整体对计算、内存等资源的复合需求？如何在众多集群中智能选择最合适的部署集群来提高资源利用率？不同业务团队间的资源配额又该如何有效控制与协调，确保公平性与隔离性？这些难题制约着 AI 应用在多集群环境下的高效、稳定运行。为更好地支撑 AI 场景下的多集群管理，Karmada 社区在吸纳了大量用户实践反馈的基础上，持续演进其核心能力，逐步补全了多模板应用在跨集群调度与租户资源管理方面的关键拼图。如今，Karmada 凭借其强大的扩展性和精细化的控制能力，已成为众多厂商构建AI应用多集群发布与管理平台的重要技术选型，有效支撑了其 AI 业务的规模化与敏捷化发展。本次分享将深入介绍Karmada为应对上述挑战而设计的核心特性，揭示 Karmada 如何提供一套端到端的多模板工作负载的多集群管理方案。 KCD 杭州站 × OpenInfra Days China 2025 当三秋桂子遇见分布式计算，当十里荷花碰撞微服务架构，这座被马可波罗誉为"世界最美丽华贵之天城"的数字经济之城，即将迎来一场重量级技术盛宴 —— KCD 杭州站与 OpenInfra Days China 的首次携手。KCD（Kubernetes Community Days，Kubernetes 社区日）由本土社区组织，得到云原生计算基金会（CNCF）的支持；OID（OpenInfra Days，开放基础设施开发者日）由本地用户组主办，获 OpenInfra 基金会支持。两者均包含主题演讲、分组会议，汇聚了开源生态的用户和开发者，旨在促进教育、协作和交流。今年这场由两大社区联合发起的开创性融合盛会，标志着云计算领域两大核心基础设施技术的深度协作与创新。它不仅充分展现开源社区的开放精神和跨社区协作的强大力量，更将共同推动 AI 与云计算技术的进步与发展。11 月，让我们相聚这座“淡妆浓抹总相宜”的城市，与全球云原生、人工智能及基础设施技术精英共赴盛会，在思想碰撞中书写技术创新的新篇章。扫描二维码免费注册，锁定限量席位门票包含所有论坛入场资格，免费午餐、茶歇及活动周边礼品活动核心信息活动时间：2025 年 11 月 15 日活动地点：中国 · 杭州 · 浙大森林会议中心主办单位 ：KCD Hangzhou 2025 组委会OpenInfra 中国用户组支持单位：云原生计算基金会（CNCF）OpenInfra 基金会核心亮点速览首次跨界联动：Kubernetes Community Day（KCD）与 OpenInfra Days（OID）打破社区边界，实现在中国本土的首次联手，汇聚两大生态资源，实现 “1+1>2” 的学习体验。顶级阵容分享：行业顶尖专家与实战领袖组成 Speaker 团，拒绝空泛理论，只传落地干货，助力高效吸收核心知识。四大专题 + 40 余场演讲：从近百个议题投稿中，精挑细选出最实战、最干货、最具价值的演讲。围绕当下热门技术方向，设置四大专题论坛，AI/ML 技术创新，云原生技术实践，算力基础设施，安全与可信计算，精准匹配不同需求。议程全公开，超强 Speaker 阵容抢先看   Karmada 是CNCF 首个多云多集群容器编排项目(孵化级），旨在帮助用户像使用单个集群一样轻松管理跨云多集群，让基于 Karmada 的多云方案无缝融入云原生技术生态。社区吸引了来自华为、道客、浙江大学、腾讯、中国电子云、滴滴、Zendesk、携程等100多家公司的全球贡献者，广泛分布于20+国家和地区。Karmada 现已在华为云、道客、兴业数金、中国移动、中国联通、携程、360集团、新浪、中通快递等众多企业单位生产应用，为企业提供从单集群到多云架构的平滑演进方案。Karmada 官网：https://karmada.io/GitHub 地址：cid:link_0Slack 地址：https://slack.cncf.io/（#karmada）添加社区小助手k8s2222回复Karmada进入技术交流群    

CCE Autopilot 是否提供对新兴技术或者趋势的支持和集成？

使用CCE Autopilot进行容器管理时，又哪些安全特性？

CCE Autopilot 如何与云原生生态进行集成？

ConfigMap在CCI Pod中的作用是什么？

CCI cloudbursting目前是否存在哪些局限性？

CCI CloudBursting解决方案如何实现基础设施免运维？

Karmada 非常高兴地宣布 Scatter Lab[1] 正式加入 Karmada 用户组[2]，成为社区的重要成员。 作为云原生计算基金会（CNCF）旗下的项目，Karmada 致力于为用户提供强大的多集群管理和调度能力，帮助企业在复杂的分布式环境中实现高效的应用部署和管理。 Scatter Lab 的加入将进一步加强 Karmada 社区，为项目的持续创新带来新的活力，标志着 Karmada 社区发展和在多样化生产环境中采用的又一个重要里程碑。 关于 Scatter Lab Scatter Lab 是一家致力于通过尖端自然语言处理和生成式人工智能技术重塑娱乐体验的韩国科技公司。公司目前以 Zeta 为核心产品，这是一款沉浸式 AI 聊天娱乐平台，于 2024 年 4 月正式上线。Zeta 通过让用户与 AI 角色共同创作动态、个性化的叙事内容，重新定义了用户参与方式——从被动消费内容转变为实时、主动的共创体验。上线一年内，Zeta 注册用户已突破 200 万，月活跃用户达 80 万，用户日均使用时长超过 2 小时 40 分钟。Zeta 的核心技术是 Scatter Lab 自主研发的 AI 模型 Spotwrite-1。该模型不仅追求语言连贯性，更专注于“趣味性”，通过创造力、不可预测性，甚至可控的“幻觉”机制，为用户提供引人入胜的互动体验。公司已实现从数据、训练到应用的全栈垂直整合，兼顾高性能与成本效率。值得一提的是，Scatter Lab 自 2024 年第四季度起已连续六个季度实现盈利，在 AI 消费领域展现出罕见的快速增长与可持续商业化能力。秉持 “让 AI 成为人类叙事中的真正伙伴” 这一愿景，Scatter Lab 正以 Zeta 为起点，向全球市场拓展，首站为日本，致力于塑造下一代“AI 原生娱乐”的未来。  关于 Karmada 用户组  作为连接社区与用户的核心纽带，Karmada 用户组致力于打造一个深度融合、开放协作的高价值平台，推动成员间的高效联动与经验共享。通过技术支持、活动共创及最佳实践交流，Karmada 用户组将持续赋能用户在多云管理领域的能力提升，助力云原生多云多集群生态系统的蓬勃发展。其主要目标和功能包括：分享知识：促进 Karmada 用户之间的经验、挑战和解决方案交流促进协作：提供一个用户可以协作、分享想法并解决共同问题的平台支持用户：提供资源、教程和指导，帮助用户有效利用 Karmada收集反馈：倾听用户声音，以指导 Karmada 未来的发展方向社区活动组织：通过定期 meetup、网络研讨会和其他活动，增强社区参与度截至目前，Karmada 用户组已吸纳来自全球的 40+ 家机构和组织。更多使用场景及案例研究请查阅：https://karmada.io/adopters   欢迎加入用户组   任何在生产环境中使用 Karmada 的公司，其开发者均可申请加入 Karmada 用户组。无论您是最终用户还是云厂商，我们都欢迎您的加入。最终用户：指在其内部 IT 基础设施中直接部署和使用 Karmada 进行多云或多集群管理的企业或组织。这些公司利用 Karmada 作为关键技术底座来管理和优化算力资源。供应商：指那些将 Karmada 集成到他们的产品或服务中，以提供给其他企业或组织使用的公司。加入 Karmada 用户组，您可以与面临类似挑战的同行建立联系并分享 Karmada 实践经验，一同探索多云多集群生态，包括但不限于以下内容：社区技术支持：包括且不限于方案评估、日常运维、问题定位、版本升级等社区支持公司知名度提升：您的公司和团队将获得全球范围内更多的曝光机会技术影响力构建：邀请共建技术演讲，包括 KubeCon 等海内外业界大会Karmada 社区伙伴举办的线上、线下系列会议保持信息同步：及时接收重要信息更新，包括新版本的关键特性、重要 Bug 修复、安全风险等内容，确保您的项目能够第一时间受益于新的改进和增强顶尖人才招募：利用社区渠道招聘宣传，全球范围内精准招募优秀人才拓展商业机会：与 Karmada 生态系统其他成员建立潜在的商业联系和合作当前，加入 Karmada 用户组对社区贡献没有硬性要求，我们鼓励成员积极参与社区活动，分享经验与见解。然而，请注意，未来可能会要求成员对 Karmada 社区做出一定的贡献，以维持其用户组成员身份。这种贡献可以包括但不限于代码提交、文档编写、问题修复、使用案例分享等。访问下方 Karmada 用户组申请表单 [3]，提交 issue 申请，即可接收申请进度。手机端可扫描下方二维码快捷填写申请表单。 扫码申请加入用户组更多信息，请访问：[1]Scatter Lab: https://www.scatterlab.co.kr/ko/intro[2]Karmada 用户组: cid:link_1[3]Karmada Adopter Group 申请加入表单地址: cid:link_0Karmada Adopter Group 欢迎您的加入！期待与您共同创建一个友好而活跃的空间，共享知识、最佳实践和经验，为企业与社区发展缔造更多可能。如需了解更多关于 Karmada Adopter Group 的信息，请联系:Maintainer Mailing Listcncf-karmada-maintainers@lists.cncf.io Karmada 是CNCF 首个多云多集群容器编排项目(孵化级），旨在帮助用户像使用单个集群一样轻松管理跨云多集群，让基于 Karmada 的多云方案无缝融入云原生技术生态。社区吸引了来自华为、道客、浙江大学、腾讯、中国电子云、滴滴、Zendesk、携程等100多家公司的全球贡献者，广泛分布于20+国家和地区。Karmada 现已在华为云、道客、兴业数金、中国移动、中国联通、携程、360集团、新浪、中通快递等众多企业单位生产应用，为企业提供从单集群到多云架构的平滑演进方案。Karmada 官网：https://karmada.io/GitHub 地址：https://github.com/karmada-io/karmadaSlack 地址：https://slack.cncf.io/（#karmada）添加社区小助手k8s2222回复Karmada进入技术交流群

云原生加速向 Serverless 演进，业界将 Serverless 容器分为 Serverless Kubernetes 集群和 Serverless 器实例两种形态。华为云 Serverless 云原生基础设施致力于持续简化用户体验，帮助用户专注于构建应用程序，而无须管理集群以及资源，加速业务创新。   华为云云容器实例 CCI：cid:link_0 

Secret 在CCI pod中起到什么作用？

CCI pod是否支持多租户隔离？