Volcano 是一个基于Kubernetes的云原生批处理平台，提供了机器学习、深度学习、生物信息学、基因组学及其他大数据应用所需要而Kubernetes当前缺失的一系列特性，提供了高性能任务调度引擎、高性能异构芯片管理、高性能任务运行管理等通用计算能力。  Volcano Scheduler  Volcano Scheduler是负责Pod调度的组件，它由一系列action和plugin组成。action定义了调度各环节中需要执行的动作；plugin根据不同场景提供了action 中算法的具体实现细节。Volcano Scheduler具有高度的可扩展性，您可以根据需要实现自己的action和plugin。图1 Volcano Scheduler工作流 Volcano Scheduler的工作流程如下：客户端提交的Job被调度器识别到并缓存起来。周期性开启会话，一个调度周期开始。将没有被调度的Job发送到会话的待调度队列中。遍历所有的待调度Job，按照定义的次序依次执行enqueue、allocate、preempt、reclaim、backfill等动作，为每个Job找到一个最合适的节点。将该Job 绑定到这个节点。action中执行的具体算法逻辑取决于注册的plugin中各函数的实现。关闭本次会话。  Volcano自定义资源  Pod组（PodGroup）：Pod组是Volcano自定义资源类型，代表一组强关联Pod的集合，主要用于批处理工作负载场景，比如Tensorflow中的一组ps和worker。队列（Queue）：容纳一组PodGroup的队列，也是该组PodGroup获取集群资源的划分依据。作业（Volcano Job，简称vcjob）：Volcano自定义的Job资源类型。区别于Kubernetes Job，vcjob提供了更多高级功能，如可指定调度器、支持最小运行Pod数、 支持task、支持生命周期管理、支持指定队列、支持优先级调度等。Volcano Job更加适用于机器学习、大数据、科学计算等高性能计算场景。应用扩缩容优先级策略（Balancer与BalancerPolicyTemplate）：开启Volcano应用扩缩容优先级策略后，将会在集群中新增两类CRD资源，其中BalancerPolicyTemplate用来进行优先级策略定义，Balancer用来申明扩缩容优先级的作用范围。一个Balancer CR资源对应一个BalancerPolicyTemplate CR资源，两者结合共同申明哪些工作负载使用了哪些优先级策略。详情请参见应用扩缩容优先级策略。 Volcano 是业界首个云原生批量计算引擎，也是 CNCF 首个和唯一的批量计算项目。项目主要用于 AI、大数据、基因、渲染等诸多高性能计算场景，对主流通用计算框架均有很好的支持。目前，Volcano在人工智能、大数据、基因测序等海量数据计算和分析场景已得到快速应用，已完成对 Spark、Flink、Ray、 Tensorflow、PyTorch、Argo、MindSpore、Paddlepaddle 、Kubeflow、MPI、Horovod、Mxnet、KubeGene 等众多主流计算框架的支持，并构建起完善的上下游生态。更多信息，请访问：Volcano云原生批量计算社区：https://volcano.shVolcano GitHub: cid:link_2Volcano云原生批量计算公开课：cid:link_0华为云云容器引擎CCE：cid:link_1 添加云原生小助手k8s2222进入技术交流群

华为云云容器引擎CCE支持多种资源与任务调度策略，有助于提升应用性能和集群整体资源利用率。本文将重点介绍CPU资源调度、GPU/NPU异构资源调度以及Volcano调度的主要功能。  CPU调度  CCE提供CPU管理策略，可为应用分配完整的物理CPU核，从而提升性能并降低调度延迟。功能描述参考文档CPU管理策略当节点上运行大量CPU密集型Pod时，工作负载可能会在不同的CPU核之间迁移。对于CPU敏感型应用，可通过Kubernetes提供的CPU管理策略为其分配独占物理核，从而提升性能并降低调度延迟。CPU管理策略增强型CPU管理策略在传统的CPU管理策略基础上，该策略新增Burstable Pod（要求CPU的Request和Limit值都是正整数）的智能调度能力，允许这类Pod优先使用特定CPU，而非完全独占。增强型CPU管理策略  GPU调度  CCE为集群中的GPU异构资源提供调度能力，从而实现资源的精细化分配与高效利用，满足不同类型工作负载对GPU算力的差异化需求，提升整体集群的调度效率与业务运行性能。功能描述参考文档Kubernetes默认GPU调度该调度模式可以指定Pod申请的GPU显卡数量，支持申请设置为小于1的数量，实现多个Pod共享使用GPU。使用Kubernetes默认GPU调度GPU虚拟化GPU虚拟化能够动态对GPU设备显存与算力进行划分，单个GPU卡最多虚拟化成20个GPU虚拟设备。相对于静态分配来说，虚拟化的方案更加灵活，最大程度保证业务稳定的前提下，可以完全由用户自己定义使用的GPU量，提高GPU利用率。GPU虚拟化GPU监控GPU指标可分为CCE提供的GPU监控指标和DCGM提供的GPU监控指标。通过Prometheus和Grafana，可以实现这些GPU指标的全面监测，从而优化计算性能，快速定位故障，合理调度资源，进而提升GPU利用率并降低运维成本。GPU监控GPU弹性伸缩CCE支持通过GPU指标配置工作负载和节点弹性伸缩策略，从而实现资源的动态调度与优化，提高计算效率，保障业务稳定运行，并有效降低运维成本。GPU弹性伸缩GPU故障处理当GPU资源出现故障时，CCE集群会及时上报事件，并根据事件信息提供单GPU故障隔离功能，确保其他正常GPU继续提供服务，最大限度降低业务影响。GPU故障处理  NPU调度  CCE为集群中的NPU异构资源提供调度能力，从而实现对推理和图像识别等工作的高效处理。功能描述参考文档NPU芯级独占调度该调度模式可以根据Pod申请的NPU数量，为工作负载提供NPU资源。NPU芯级独占调度NPU拓扑感知调度该调度模式指结合昇腾AI处理器和节点间的拓扑结构灵活匹配调度策略，其能够有效减少计算资源碎片和网络拥塞，最大化提升NPU算力利用率。NPU拓扑感知调度NPU虚拟化NPU虚拟化指将通过资源虚拟化的方式将物理机中配置的NPU（昇腾AI产品）切分为多个虚拟NPU（vNPU），并挂载至容器中使用，以实现对硬件资源的灵活切分与动态管理。NPU虚拟化NPU监控当集群中包含NPU节点时，监控NPU指标可以帮助用户识别性能瓶颈、优化资源利用率、快速定位异常，从而提升系统的整体稳定性和效率。在CCE Standard和Turbo集群中，您可以使用npu-exporter组件将dcmi/hccn tool采集的NPU指标数据上传至云原生监控系统，实现NPU资源的实时监控与告警，从而提升系统的可靠性和性能。NPU监控  Volcano调度  Volcano是一个基于Kubernetes的批处理平台，提供了机器学习、深度学习、生物信息学、基因组学及其他大数据应用所需要而Kubernetes当前缺失的一系列特性，提供了高性能任务调度引擎、高性能异构芯片管理、高性能任务运行管理等通用计算能力。功能描述参考文档使用Volcano调度工作负载一般情况下，Kubernetes在调度工作负载时会使用自带的默认调度器，若需要使用Volcano调度器的能力，您可以为工作负载指定调度器。使用Volcano调度工作负载资源利用率优化调度针对计算资源进行优化的调度策略，可以有效减少各节点资源碎片，最大化地提高计算资源的利用率。资源利用率优化调度业务优先级保障调度根据业务的重要性和优先级，设置自定义的策略对业务占用的资源进行调度，确保关键业务的资源优先级得到保障。业务优先级保障调度AI任务性能增强调度根据AI任务的工作性质、资源的使用情况，设置对应的调度策略，可以增强集群业务的吞吐量，提高业务运行性能。AI任务性能增强调度任务队列调度通过队列资源管理机制，动态分配集群资源，确保高优先级任务优先执行，同时优化资源利用率和作业吞吐量。任务队列调度NUMA亲和性调度Volcano可解决调度程序NUMA拓扑感知的限制，实现以下目标：避免将Pod调度到NUMA拓扑不匹配的节点。将Pod调度到NUMA拓扑的最佳节点。NUMA亲和性调度应用扩缩容优先级策略通过应用扩缩容优先级策略，可以精确控制Pod在不同类型节点上的扩容与缩容顺序，从而实现资源管理的最优化。应用扩缩容优先级策略应用紧凑型缩容策略Volcano调度器会依据设定的紧凑型缩容策略，对由Deployment（也间接包括ReplicaSet）及其他指定工作负载类型管理的Pod进行评分。Pod所在节点的NPU占用率越低，其得分也越低。缩容时，控制器优先移除得分较低的Pod，若存在多个得分相同的Pod，则随机驱逐相应数量的Pod。这样有助于提高后续调度的成功率和整体NPU资源的使用效率。应用紧凑型缩容功能  云原生混部  云原生混部解决方案围绕Volcano和Kubernetes生态，帮助用户提升资源利用率，实现降本增效。功能描述参考文档动态资源超卖根据在线作业和离线作业类型，通过Volcano调度将集群中申请而未使用的资源（即申请量与使用量的差值）利用起来，实现资源超卖和混合部署，提升集群资源利用率。动态资源超卖基于Pod实例画像的资源超卖提供一种超卖算法，能够持续采集节点上Pod的CPU和内存利用率，统计资源使用的概率分布，并在一定置信度下评估节点资源占用。算法综合考虑资源使用的整体水平及波动，能够计算出稳定的超卖量，从而减少资源竞争，避免业务波动引起的Pod频繁驱逐。相比直接基于节点实时CPU和内存利用率的算法，该算法能有效减少超卖量波动，提升对突发资源尖峰的覆盖能力，从而在保障业务性能相对稳定的同时实现资源超卖。基于Pod实例画像的资源超卖CPU Burst弹性限流提供一种可以短暂突破CPU Limit值的弹性限流机制，以降低业务长尾响应时间，可以有效提升时延敏感型业务的服务质量。CPU Burst弹性限流出口网络带宽保障平衡在线业务与离线业务对出口网络带宽的使用，保证在线业务有足够的网络带宽。出口网络带宽保障 更多信息，请访问： 华为云云容器引擎CCE：cid:link_26Volcano云原生批量计算社区：https://volcano.shVolcano GitHub: cid:link_28Volcano云原生批量计算公开课：cid:link_25 添加云原生小助手k8s2222进入技术交流群  

📝摘要：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进入技术交流群    

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 

云原生计算基金会（CNCF）多云容器编排引擎 Karmada 宣布，彭博（Bloomberg）[1]正式加入 Karmada 用户组[2]。Karmada 致力于为用户提供强大的多集群管理和调度能力，帮助企业在复杂的分布式环境中实现高效的应用部署和管理。Bloomberg 的加入将进一步加强 Karmada 社区，为项目的持续创新带来新的活力，标志着 Karmada 在社区发展和多样化生产环境中采用的又一个重要里程碑。   关于 Bloomberg  彭博（Bloomberg）是全球商业与金融信息领域的领军者，提供值得信赖的数据、新闻与深度洞察，为市场注入透明度、提升效率并维护公平性。Bloomberg 借助可靠的技术解决方案，助力全球金融生态系统中具有影响力的各方建立连接，帮助客户做出更明智的决策，并促进更高效的协作。Bloomberg 采用 Karmada 管理本地训练集群，并调度 GPU/CPU 工作负载，更多技术细节请参考 KubeCon + CloudNativeCon 演讲分享：Bloomberg’s Journey to Improve Resource Utilization in a Multi-Cluster Platform- Yao Weng, Leon Zhou[3]Bloomberg's Journey to Manage a Multi-Cluster Training Application with Karmada - Y. Zhang, W. Lai[4]Flink on Karmada: Building Resilient Data Pipelines on Multi-Cluster K8s - Michas Szacillo & Wang Li[5]AI Workload Preemption in a Multi-Cluster Scheduling System at Bloomberg - Leon Zhou & Wei-Cheng Lai[6]Multi-cluster Orchestration System: Karmada Updates and Use Cases - Hongcai Ren & Joe Nathan Abellard[7]  关于 Karmada 用户组  Karmada 用户组是一个由在其环境中成功采用 Karmada 的组织和用户组成的社区。成员分享他们的经验、最佳实践和反馈，以帮助改进 Karmada 并培育一个充满活力的协作生态系统。成为 Karmada 用户组成员具有以下几个优势：社区认可：作为云原生多集群管理领域的领导者来展示您的组织，在 CNCF 和 Karmada 社区中获得知名度。促进协作：与其他采用者建立联系，分享最佳实践，并在实际用例和解决方案上进行协作。保持信息同步：及时接收重要更新通知，包括关键功能、错误修复和安全建议。技术影响力构建：受邀参与 Karmada 相关活动，包括 KubeCon + CloudNativeCon、网络研讨会和聚会。职位发布：有机会在 Karmada 社区支持的职位公告板上发布与 Karmada 相关的职位空缺（目前暂不可用）。扩展商业机会：与 Karmada 生态系统的其他成员建立潜在的商业联系和合作。截至目前，Karmada 用户组已吸纳来自全球的40+家机构和组织。更多使用场景及案例研究请查阅：https://karmada.io/adopters  欢迎加入用户组  Karmada 用户组对当前正在生产环境中使用 Karmada 的最终用户和供应商开放。这包括：最终用户：在其生产环境中运行 Karmada 的组织。供应商：提供基于 Karmada 的产品或服务，并有客户在生产环境中使用这些产品或服务的公司。当前，加入 Karmada 用户组对社区贡献没有硬性要求，Karmada 鼓励成员积极参与社区活动，分享经验与见解。然而，请注意，未来可能会要求成员对 Karmada 社区做出一定的贡献，以维持其用户组成员身份。这种贡献可以包括但不限于代码提交、文档编写、问题修复、使用案例分享等。访问下方 Karmada 用户组申请表单 [8]，提交 issue 申请，即可接收申请进度。手机端可扫描下方二维码快捷填写申请表单。 扫码申请加入用户组Karmada（https://karmada.io/）是CNCF首个跨云跨集群容器编排引擎，由华为云、工商银行、小红书、中国一汽等八家企业联合发起。该项目于2021年4月正式开源，同年9月正式成为CNCF官方项目。Karmada的贡献企业与贡献者遍布全球22个国家和地区的100多个组织，包括华为、道客、浙江大学、腾讯、滴滴、Bloomberg、Yunhorn、携程等。截至目前，该项目在GitHub上已获得5.1k+Star。如需了解更多关于 Karmada Adopter Group 的信息，请联系: Maintainer Mailing Listcncf-karmada-maintainers@lists.cncf.io更多信息，请访问：[1] 彭博（Bloomberg）: https://www.techatbloomberg.com/opensource/[2] Karmada 用户组: https://github.com/karmada-io/community/tree/main/adopter-group[3] Bloomberg’s Journey to Improve Resource Utilization in a Multi-Cluster Platform- Yao Weng, Leon Zhou: https://www.youtube.com/watch?v=lMtCSaHI9Uk[4] Bloomberg's Journey to Manage a Multi-Cluster Training Application with Karmada - Y. Zhang, W. Lai: https://www.youtube.com/watch?v=PmaiEKpM1-Q[5] Flink on Karmada: Building Resilient Data Pipelines on Multi-Cluster K8s - Michas Szacillo & Wang Li: https://www.youtube.com/watch?v=mqXZ2T-jWuU[6] AI Workload Preemption in a Multi-Cluster Scheduling System at Bloomberg - Leon Zhou & Wei-Cheng Lai: https://www.youtube.com/watch?v=LrL5AcS2d5g[7] Multi-cluster Orchestration System: Karmada Updates and Use Cases - Hongcai Ren & Joe Nathan Abellard: https://www.youtube.com/watch?v=rbVV8WIJYww[8] Karmada Adopter Group 申请加入表单地址: https://github.com/karmada-io/community/issues/new?template=adopter-group-application.yaml 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进入技术交流群 

华为云云容器引擎 CCE Autopilot 集群是一款兼容 Kubernetes 并支持客户免运维的 Serverless 版集群。客户无需购买和管理节点，只需关注应用业务逻辑的实现，大幅降低运维成本，提升应用可靠性与扩展性。CCE Autopilot 适用于敏态业务快速创新、潮汐业务弹性伸缩、批量计算等多种场景，助力企业应对多样化需求。 链接访问体验：cid:link_0 

9 月 13-14 日，GOSIM HANGZHOU 2025 大会将在杭州隆重启幕。本次大会由 GOSIM 全球开源创新汇主办、CSDN 承办，以国际化、社区化、强互动为特色，深入聚焦开源与 AI 的前沿技术与跨界创新。继中国上海、荷兰代尔夫特、中国北京、法国巴黎之后，GOSIM Hangzhou 2025是该系列活动的第五站，即将在西湖之畔点燃新一轮创新热情。大会汇聚来自全球超过 1500 名一线开源开发者和 100 多位海内外资深专家，带来 100 余场高质量技术分享。华为云云原生开源技术专家将在AI 模型 × 基础设施、端侧 AI 工作坊、互动展区等会场带来议题演讲与技术讲解，深度探讨云原生技术创新和产业实践，欢迎现场交流。     议 题 1   议题：赋能云原生AI：基于Volcano调度器破解大规模语言模型部署难题论坛：AI 模型 × 基础设施时间地点：9月13日 15:00 - 15:20（Room 338，3F）讲师：Zicong Chen，华为云研发工程师, Volcano Reviewer, lws Contributor议题简介：随着大型语言模型（LLM）的规模化，多节点分布式训练与推理已成为必然。然而，这带来了双重挑战：首先，在默认调度器下，由LeaderWorkerSet等工具管理的分布式作业，因无法进行“成组调度”而常陷入资源死锁。其次，现代AI集群复杂的网络拓扑对通用调度器是不可见的，常因任务组被分散调度而导致通信效率低下，影响性能。本次分享将深入介绍基于Volcano的解决方案。我们将演示Volcano如何通过其原生的Gang Scheduling能力解决死锁问题，并通过一个实际案例，展示新版LWS是如何自动创建PodGroup来无缝集成。更进一步，我们将介绍Volcano提出的HyperNode（超节点）统一拓扑抽象。调度器通过HyperNode来理解底层的复杂网络结构，并根据作业提交时指定的约束，将其精准地调度到符合要求的特定网络拓扑性能域中，确保最佳性能。同时，本议题还将介绍实际案例，并探讨子组级别（sub-group level）拓扑感知调度、多集群网络拓扑感知调度，自动化网络拓扑感知等持续发展方向。     议 题 2   议题：边缘 AI：探索 KubeEdge 的可能性与价值论坛：边缘 AI 工作坊时间地点：9月13日 16:30 - 16:55（Room B01，B1）讲师：Yue Bao，华为云高级工程师, KubeEdge Maintainer议题简介：边缘 AI 通过在本地处理数据实现实时、低延迟推理，从而解锁各行各业的变革性应用。随着云原生技术的进步，边缘 AI 正在发展成为强大的云边协同范式，支持在边缘和云之间动态编排 AI 工作负载，从而优化性能、准确性和隐私。KubeEdge 的分布式边云协同 AI 框架 Sedna 支持在边缘和云环境中无缝部署 AI 模型。在本次演讲中，我们将探讨 KubeEdge 如何利用 Sedna 在边缘实现高效的推理和自动化。       云原生展区    同时，华为云云原生开源技术专家也将在展区（杭州市西湖区珊瑚沙东路9号白金汉爵大酒店二楼·云原生展位）与大家面对面交流KubeEdge、Volcano、Karmada、Kmesh、Kuasar等项目技术应用与产品最新实践。添加社区小助手k8s2222，提前关注展区有奖互动。 容器魔方小助手GOSIM HANGZHOU 2025 不仅是技术交流的平台，更是智能时代科技变革的重要契机。全球顶尖技术领袖、前沿企业与开源社区将齐聚一堂，重量级项目集中亮相，前沿思想碰撞迸发，技术与实践成果深度分享，共同呈现一场高规格、高密度、高能量的科技盛会。更多精彩内容及参会方式，请关注大会官网。大会官网：https://hangzhou2025.gosim.org/9 月 13- 14 日，GOSIM HANGZHOU 2025大咖云集，精彩纷呈欢迎亲临现场与全球开源资深大咖面对面交流！

Karmada[1] 是开放的多云多集群容器编排引擎，旨在帮助用户在多云环境下部署和运维业务应用。凭借兼容 Kubernetes 原生 API 的能力，Karmada 可以平滑迁移单集群工作负载，并且仍可保持与 Kubernetes 周边生态工具链协同。Karmada v1.15 [2] 版本现已发布，本版本包含下列新增特性：多模板工作负载的资源精确感知集群级故障迁移功能增强结构化日志Karmada 控制器和调度器性能显著提升  新特性概览  ▍多模板工作负载的资源精确感知Karmada 利用资源解释器获取工作负载的副本数和资源请求，并据此计算工作负载所需资源总量，从而实现资源感知调度，联邦配额管理等高阶能力。这种机制在传统的单模板工作负载中表现良好。然而，许多AI大数据应用的工作负载  CRD（如 FlinkDeployments，PyTorchJob 和 RayJob 等）包含多个 Pod 模板或组件，每个组件都有独特的资源需求。由于资源解释器仅能处理单个模板的资源请求，无法准确反映不同模板间的差异，导致多模板工作负载的资源计算不够精确。在这个版本中，Karmada 强化了对多模板工作负载的资源感知能力，通过扩展资源解释器，Karmada 现在可以获取同一工作负载不同模板的副本数和资源请求，确保数据的精确性。这一改进也为多模板工作负载的联邦配额管理提供了更加可靠和精细的数据支持。假设你部署了一个 FlinkDeployment，其资源相关配置如下:spec:  jobManager:    replicas: 1    resource:      cpu: 1      memory: 1024m  taskManager:    replicas: 1    resource:      cpu: 2      memory: 2048m通过 ResourceBinding，你可以查看资源解释器解析出的 FlinkDeployment 各个模板的副本数以及资源请求。spec:  components:  - name: jobmanager    replicaRequirements:      resourceRequest:        cpu: "1"        memory: "1.024"    replicas: 1  - name: taskmanager    replicaRequirements:      resourceRequest:        cpu: "2"        memory: "2.048"    replicas: 1此时，FederatedResourceQuota 计算的 FlinkDeployment 占用的资源量为： status:     overallUsed:       cpu: "3"       memory: 3072m注意：该特性目前处于 Alpha 阶段，需要启用 MultiplePodTemplatesScheduling 特性开关才能使用。随着多模板工作负载在云原生环境中的广泛应用，Karmada 致力于对其提供更强有力的支持。在接下来的版本中，我们将基于此功能进一步加强对多模板工作负载的调度支持，提供更加细粒度的资源感知调度——敬请期待更多更新！更多有关此功能的资料请参考：多 Pod 模板支持[3]▍集群级故障迁移功能增强在之前的版本中，Karmada 提供了基本的集群级故障迁移能力，能够通过自定义的故障条件触发集群级别的应用迁移。为了满足有状态应用在集群故障迁移过程中保留其运行状态的需求，Karmada 在 v1.15 版本支持了集群故障迁移的应用状态中继机制。对于大数据处理应用（例如 Flink），利用此能力可以从故障前的 checkpoint 重新启动，无缝恢复到重启前的数据处理状态，从而避免数据重复处理。社区在 PropagationPolicy/ClusterPropagationPolicy API 中的 .spec.failover.cluster 下引入了一个新的 StatePreservation 字段， 用于定义有状态应用在故障迁移期间保留和恢复状态数据的策略。结合此策略，当应用从一个故障集群迁移到另一个集群时，能够从原始资源配置中提取关键数据。状态保留策略 StatePreservation 包含了一系列 StatePreservationRule 配置，通过 JSONPath 来指定需要保留的状态数据片段，并利用关联的 AliasLabelName 将数据传递到迁移后的集群。以 Flink 应用为例，在 Flink 应用中，jobID 是一个唯一的标识符，用于区分和管理不同的 Flink 作业（jobs）。当集群发生故障时，Flink 应用可以利用 jobID 来恢复故障前作业的状态，从故障点处继续执行。具体的配置和步骤如下：apiVersion: policy.karmada.io/v1alpha1kind: PropagationPolicymetadata:  name: foospec:  #...  failover:    cluster:      purgeMode: Directly      statePreservation:        rules:          - aliasLabelName: application.karmada.io/cluster-failover-jobid           jsonPath: "{ .jobStatus.jobID }"迁移前，Karmada 控制器将按照用户配置的路径提取 job ID。迁移时，Karmada 控制器将提取的 job ID 以 label 的形式注入到 Flink 应用配置中，比如 application.karmada.io/cluster-failover-jobid : <jobID>。运行在成员集群的 Kyverno 拦截 Flink 应用创建请求，并根据 jobID  获取该 job 的 checkpoint 数据存储路径，比如  /<shared-path>/<job-namespace>/<jobId>/checkpoints/xxx，然后配置 initialSavepointPath 指示从save point 启动。Flink 应用根据 initialSavepointPath 下的 checkpoint 数据启动，从而继承迁移前保存的最终状态。该能力广泛适用于能够基于某个 save point 启动的有状态应用程序，这些应用均可参考上述流程实现集群级故障迁移的状态中继。注意：该特性目前处于 Alpha 阶段，需要启用 StatefulFailoverInjection 特性开关才能使用。功能约束：应用必须限定在单个集群中运行；迁移清理策略（PurgeMode）限定为 Directly，即需要确保故障应用在旧集群上删除之后再在新集群中恢复应用，确保数据一致性。▍结构化日志日志是系统运行过程中记录事件、状态和行为的关键工具，广泛用于故障排查、性能监控和安全审计。Karmada 组件提供丰富的运行日志，帮助用户快速定位问题并回溯执行场景。在先前版本中，Karmada 仅支持非结构化的文本日志，难以被高效解析与查询，限制了其在现代化观测体系中的集成能力。Karmada 在 1.15 版本引入了结构化日志支持，可通过 --logging-format=json 启动参数配置 JSON 格式输出。结构化日志示例如下：{  "ts":“日志时间戳”,  "logger":"cluster_status_controller",  "level": "info",  "msg":"Syncing cluster status",  "clusterName":"member1"}结构化日志的引入显著提升了日志的可用性与可观测性：高效集成：可无缝对接 Elastic、Loki、Splunk 等主流日志系统，无需依赖复杂的正则表达式或日志解析器。高效查询：结构化字段支持快速检索与分析，显著提升故障排查效率。可观察性增强：关键上下文信息（如集群名、日志级别）以结构化字段呈现，便于跨组件、跨时间关联事件，实现精准问题定位。可维护性提升：结构化日志使开发者和运维人员在系统演进过程中更易于维护、解析和调整日志格式，保障日志体系的长期稳定与一致性。▍Karmada 控制器和调度器性能显著提升在本次版本中，Karmada 性能优化团队继续致力于提升 Karmada 关键组件的性能，在控制器和调度器方面取得了显著进展。控制器方面，通过引入优先级队列，控制器能够在重启或切主后优先响应用户触发的资源变更，从而显著缩短服务重启和故障切换过程中的停机时间。测试环境包含 5,000 个 Deployment、2,500 个 Policy 以及 5,000 个 ResourceBinding。在控制器重启且工作队列中仍有大量待处理事件的情况下，更新 Deployment 和 Policy。测试结果显示，控制器能够立即响应并优先处理这些更新事件，验证了该优化的有效性。注意：该特性目前处于 Alpha 阶段，需要启用 ControllerPriorityQueue 特性开关才能使用。调度器方面，通过减少调度过程中的冗余计算，降低远程调用请求次数，Karmada 调度器的调度效率得到了显著提升。测试记录了在开启精确调度组件 karmada-scheduler-estimator 情况下，调度 5,000 个 ResourceBinding 所用的时间，结果如下：调度器吞吐量 QPS 从约 15 提升至约 22，性能提升达 46%；gRPC 请求次数从约 10,000 次减少至约 5,000 次，降幅达 50%。这些测试证明，在 1.15 版本中，Karmada 控制器和调度器的性能得到了极大提升。未来，我们将继续对控制器和调度器进行系统性的性能优化。相关的详细测试报告，请参考 [Performance] Overview of performance improvements for v1.15[4]   致谢贡献者  Karmada v1.15 版本包含了来自 39 位贡献者的 269 次代码提交，在此对各位贡献者表示由衷的感谢：贡献者列表： 参考资料[1] Karmada: https://karmada.io/[2] Karmada v1.15: https://github.com/karmada-io/karmada/releases/tag/v1.15.0[3] 多 Pod 模板支持: https://github.com/karmada-io/karmada/tree/master/docs/proposals/scheduling/multi-podtemplate-support[4] [Performance] Overview of performance improvements for v1.15: https://github.com/karmada-io/karmada/issues/6516 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进入技术交流群 

华为云CCE智能助手是依托盘古大模型与DeepSeek等领先LLM技术构建的全栈AI驱动的智能服务助手，贯穿智能问答、智能推荐、智能诊断、智能优化等全流程容器使用场景，辅助您提升运维和管理效率。当前已支持智能问答、智能诊断与恢复等能力。  云容器引擎CCE服务意见反馈链接直达：cid:link_0 

云计算BU通用计算服务产品部 2026届应届生招聘➯ 部门介绍在云计算的浪潮中，我们在Kubernetes等云原生技术领域有10余年的技术积累。我们致力于成为技术创新先锋，通过云原生容器化技术，为企业数字化转型提供强大动力。让云无处不在，让智能无所不及，共建智能世界云底座。品牌引领：连续5年云容器软件市场份额国内TOP1，Gartner容器管理魔力象限领导者，Omdia评价产品战略与执行全球第一，业务遍布国内外互联网、金融、政企等多个领域。技术创新：云原生基金会国内唯一初始成员，全球首位CNCF技术监督委员会华人副主席，CNCF基础设施技术负责人，CNCF工作负载技术负责人。主导开源 KubeEdge、Volcano、Karmada、Kuasar、Kmesh等多个云原生开源项目。华为云容器与Serverless团队持续构建AI基础设施，加大在云原生 AI、Serverless架构、多云和混合云战略、云边端协同、函数计算等领域的战略投入，以技术革新为驱动，打造业界领先的云原生解决方案。团队基于云原生技术构建大规模训推一体AI基础设施，助力华为云内外部在汽车、互联网、金融等领域的多个客户实现AI创新。热忱欢迎优秀学子加入我们!  更多云原生技术动向关注容器魔方  【更多华为云云原生干货推荐】华为云云原生王者之路集训营华为云云原生王者之路集训营为帮助广大技术爱好者快速掌握云原生相关技能，华为云云原生团队与华为云学院联合CNCF开源软件大学启动人才培养计划，推出《华为云云原生王者之路集训营》，从云原生基础知识介绍到最佳实践讲解、底层原理和方案架构深度剖析，层层深入，满足不同云原生技术基础和学习目标人群的需求。本课程还精选数十个企业典型应用场景，作为学员上机实践案例，帮助学员将所学技术快速与企业业务相结合，服务于企业生产。点击免费参加华为云云原生王者之路集训营：cid:link_3 学习后记得小试牛刀，看看测评效果~ 华为云云原生王者之路-黄金课程测评 华为云云原生王者之路-钻石课程测评 华为云云原生王者之路-王者课程测评