Karmada 是开放的多云多集群容器编排引擎，旨在帮助用户在多云环境下部署和运维业务应用。凭借兼容 Kubernetes 原生 API 的能力，Karmada 可以平滑迁移单集群工作负载，并且仍可保持与 Kubernetes 周边生态工具链协同。Karmada v1.16[1] 版本现已发布，本版本包含下列新增特性：支持多模板工作负载调度使用 Webster 算法增强副本分配驱逐队列速率限制持续的性能优化这些特性使 Karmada 在处理大规模、复杂的多集群场景时更加成熟和可靠。我们鼓励您升级到 v1.16.0，体验这些新功能带来的价值。  新特性概览  ▍支持多模板工作负载调度当前许多AI/大数据应用由多个组件构成，这些组件之间相互协作以完成复杂的计算任务。例如：FlinkDeployment 包含 JobManager 和 TaskManager；SparkApplication 包含 Driver 和 Executor；RayCluster 包含 Head 和 Worker 节点。在 Karmada v1.16.0 中，我们引入了多模板调度，这是一项全新的能力，使得 Karmada 能够将由多个相互关联组件组成的多模版工作负载完整且统一地调度到具有充足资源的单个成员集群中。此功能建立在 v1.15 版本引入的多模板工作负载资源精确感知[2]功能之上，该支持使 Karmada 能够准确理解复杂工作负载的资源拓扑。在 v1.16 中，调度器利用这些信息来：基于 ResourceQuota 限制来估算成员集群可以容纳的完整的多模板工作负载数；利用成员集群中实际节点的可用资源来预测工作负载的可调度性。当前版本为以下多模板工作负载类型提供了内置的资源解释器：FlinkDeployment (flink.apache.org\v1beta1)SparkApplication (sparkoperator.k8s.io\v1beta2)Job (batch.volcano.sh\v1alpha1)MPIJob (kubeflow.org\v2beta1)RayCluster (ray.io/v1)RayJob (ray.io/v1)TFJob (kubeflow.org\v1)PyTorchJob (kubeflow.org\v1)如果您使用的是其他的自定义多模板工作负载，也可以通过扩展 Karmada 的资源解释器来支持它们。让我们举个简单的例子，假设您有一个 FlinkDeployment，其资源配置如下：apiVersion: flink.apache.org/v1beta1 kind: FlinkDeployment metadata:   name: flink-example spec:   jobManager:     replicas: 1     resource:       cpu: 1       memory: "1024m"   taskManager:     replicas: 2     resource:       cpu: 2       memory: "2048m启用多模板调度功能后，Karmada 会：通过资源解释器准确解析出 JobManager 和 TaskManager 的资源需求；评估每个成员集群是否有足够资源容纳完整的 FlinkDeployment（1 个 JobManager + 2 个 TaskManager）；将整个 FlinkDeployment 调度到单个满足条件的集群。此功能的发布标志着 Karmada 在支持AI/大数据应用方面迈出了重要一步——将精准的资源解释、配额感知计算和跨集群调度融合在一个统一的框架中。▍使用 Webster 算法增强副本分配Karmada 支持多种副本调度策略，如 DynamicWeight、Aggregated 和 StaticWeight，用于在成员集群之间分配工作负载的副本。这些策略的核心在于将集群权重转化为实际副本数量的算法。在之前的版本中，副本分配算法存在一定的局限性：非单调性：当总副本数增加时，某些集群可能意外地获得更少的副本；缺乏强幂等性：相同的输入可能产生不同的输出；不公平的余数分配：在具有相同权重的集群之间分配剩余副本时缺乏合理的优先级策略。在当前版本中，我们引入了 Webster 方法（也称为 Sainte-Laguë 方法）来改进跨集群调度期间的副本分配。通过采用 Webster 算法，Karmada 现在实现了：单调副本分配：增加总副本数绝不会导致任何集群丢失副本，确保行为一致且直观。剩余副本的公平处理：在权重相等的集群间分配副本时，优先考虑当前副本数较少的集群。这种“小优先”方式有助于促进均衡部署，更好地满足高可用性（HA）需求。此次更新增强了跨集群工作负载分配的稳定性、公平性和可预测性，使多集群环境中的副本调度更加稳健。▍驱逐队列速率限制在多集群环境中，当集群发生故障时，资源需要从故障集群中驱逐并重新调度到健康的集群。如果多个集群同时或在短时间内相继发生故障，大量的驱逐和重新调度操作可能会使健康集群和控制平面不堪重负，进而导致级联故障。此版本引入了具有速率限制功能的驱逐队列，用于 Karmada 污点管理器。驱逐队列通过可配置的固定速率参数来控制资源驱逐速率，从而增强故障迁移机制。该实现还提供了用于监控驱逐过程的指标，提高了整体系统的可观测性。这个特性在以下场景特别有用：您需要在大规模故障期间防止级联故障，确保系统不会因为过多的驱逐操作而不堪重负。您希望根据不同环境的特性配置驱逐行为。例如，在生产环境中使用较低的驱逐速率，在开发或测试环境中使用较高的速率。您需要监控驱逐队列的性能，包括待处理驱逐的数量、处理延迟以及成功/失败率，以便调整配置和响应运维问题。驱逐队列的核心特性包括：可配置的固定速率限制：通过 --eviction-rate 命令行参数配置每秒驱逐速率。示例：设置每 2 秒最多驱逐 1 个资源：--eviction-rate=0.5。完善的指标支持：提供队列深度、资源类型、处理延迟、成功/失败率等指标，便于监控和故障排查。通过引入速率限制机制，管理员可以更好地控制集群故障迁移期间的资源调度速率，在保障服务稳定性的同时，提升资源调度的灵活性和效率。有关此功能的详细使用方法，请参阅用户指南：配置驱逐速率限制[3]。▍持续的性能优化在此版本中，性能优化团队继续增强 Karmada 的性能，对控制器进行了重大改进。在 release-1.15 中，我们引入了 controller-runtime 优先级队列[4]，它允许基于 controller-runtime 构建的控制器在重启或主从切换后优先处理最新的变更，从而显著减少服务重启和故障转移期间的停机时间。在 release-1.16 中，我们扩展了这一能力。对于不是基于 controller-runtime 构建的控制器（如 detector controller），我们通过为所有使用异步 worker 的控制器启用优先级队列功能，使它们也能享受到这一优化。测试环境包括 5,000 个 Deployments 及其 PropagationPolicy，并在 karmada-controller-manager 组件中启用了 ControllerPriorityQueue 特性开关。在 karmada-controller-manager 组件重启后、工作队列中仍有大量待处理事件的情况下，手动修改一个 Deployment，其更新事件仍能被控制器快速处理并被同步到成员集群。这些测试结果证明，Karmada 控制器的性能在 v1.16 中得到了很大的提升。未来，我们将继续对控制器和调度器进行系统性的性能优化。有关详细的进展和测试报告，请参阅 PR：[Performance] enable asyncPriorityWorker in all controllers[5]。  致谢贡献者  Karmada v1.16 版本包含了来自 30 位贡献者的 263 次代码提交，在此对各位贡献者表示由衷的感谢：贡献者列表：   相关链接[1] Karmada v1.16: cid:link_0[2] 多模板工作负载资源精确感知: https://karmada.io/blog/2025/09/05/karmada-v1.15/karmada-v1.15#precise-resource-awareness-for-multi-template-workloads[3] 用户指南: 配置驱逐速率限制: https://karmada.io/docs/next/userguide/failover/cluster-failover/#configuring-eviction-rate-limiting[4] controller-runtime 优先级队列: cid:link_1[5] [Performance] enable asyncPriorityWorker in all controllers: cid:link_2 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支持多种资源与任务调度策略，有助于提升应用性能和集群整体资源利用率，CPU资源调度、GPU/NPU异构资源调度以及Volcano调度的主要功能。本系列文章将介绍Volcano调度在华为云云容器引擎CCE中的运用。Volcano是一个基于Kubernetes的批处理平台，提供了机器学习、深度学习、生物信息学、基因组学及其他大数据应用所需要而Kubernetes当前缺失的一系列特性，提供了高性能任务调度引擎、高性能异构芯片管理、高性能任务运行管理等通用计算能力。在华为云云容器引擎CCE使用Volcano的调度中，在替换节点池、节点滚动升级等场景，需要使用新节点池替换旧节点池。在这些场景下，为做到业务不感知，可以在业务触发变更时，将业务的Pod软亲和调度到新的节点池上。这种软亲和调度会尽量将新创建的Pod或者重调度的Pod调度到新的节点池，如果新节点池资源不足，或者新节点池无法调度，也要能将Pod调度到旧节点池上。节点池替换、节点滚动升级等场景中，业务不需要也不应该感知，所以不会在业务负载中声明节点亲和配置，而需要在集群调度层面，使用软亲和方式，在业务变更时将Pod尽量调度到新的节点池上。Volcano的目标是在业务负载未配置节点软亲和时，在调度层将业务的Pod软调度到指定节点上。  调度优先级介绍  节点池软亲和调度，是通过节点池上的标签（Label）进行软亲和，具体是通过给每一个节点进行打分的机制来排序筛选最优节点。📝 原则：尽可能把Pod调度到带有相关标签的节点上。🔍 打分公式如下：score = weight * MaxNodeScore * haveLabel参数说明：weight：节点池软亲和plugin的权重。MaxNodeScore：节点最大得分，值为100。haveLabel：节点上是否存在插件中配置的label，如果有，值为1，如果节点上没有，值为0。  前提条件  ✅ 已创建v1.19.16及以上版本的集群，具体操作请参见购买Standard/Turbo集群。✅ 集群中已安装1.11.5及以上版本的Volcano插件，具体操作请参见Volcano调度器。  配置Volcano节点池软亲和调度策略  1、在节点池上配置用于亲和调度的标签。登录CCE控制台，单击集群名称进入集群。在左侧选择“节点管理”，在右侧选择“节点池”页签。单击节点池名称后的“更新”，在弹出的“更新节点池”页面中配置参数，在“K8s标签”中配置对应的标签。示例如下：2、单击左侧导航栏的“配置中心”，切换至“调度配置”页面，选择Volcano调度器找到对应的“专家模式”，单击“开始使用”。3、设置Volcano调度器配置参数，JSON格式的配置示例如下。... "default_scheduler_conf": { "actions": "allocate, backfill, preempt", "tiers": [ { "plugins": [ { "name": "priority" }, { "name": "gang" }, { "name": "conformance" } ] }, { "plugins": [ { "name": "drf" }, { "name": "predicates" }, { "name": "nodeorder" } ] }, { "plugins": [ { "name": "cce-gpu-topology-predicate" }, { "name": "cce-gpu-topology-priority" }, { "name": "cce-gpu" }, { // 开启节点池亲和性调度 "name": "nodepoolaffinity", // 节点池亲和性调度权重及标签设置 "arguments": { "nodepoolaffinity.weight": 10000, "nodepoolaffinity.label": "nodepool=nodepool1" } } ] }, { "plugins": [ { "name": "nodelocalvolume" }, { "name": "nodeemptydirvolume" }, { "name": "nodeCSIscheduling" }, { "name": "networkresource" } ] } ] }, ...4、 完成以上配置后，单击“确定”。 🌍 Volcano 是业界首个云原生批量计算引擎，也是 CNCF 首个和唯一的批量计算项目。项目主要用于 AI、大数据、基因、渲染等诸多高性能计算场景，对主流通用计算框架均有很好的支持。目前，Volcano在人工智能、大数据、基因测序等海量数据计算和分析场景已得到快速应用，已完成对 Spark、Flink、Ray、 Tensorflow、PyTorch、Argo、MindSpore、Paddlepaddle 、Kubeflow、MPI、Horovod、Mxnet、KubeGene 等众多主流计算框架的支持，并构建起完善的上下游生态。📌 更多Volcano云原生批量计算 技术应用，请访问社区仓库或官网：1️⃣ Volcano云原生批量计算社区官网：https://volcano.sh2️⃣ Volcano GitHub 仓库: cid:link_53️⃣ Volcano云原生批量计算公开课：cid:link_34️⃣ 华为云云容器引擎CCE：cid:link_4 更多云原生技术动向关注容器魔方

华为云云容器引擎CCE支持多种资源与任务调度策略，有助于提升应用性能和集群整体资源利用率，CPU资源调度、GPU/NPU异构资源调度以及Volcano调度的主要功能。本系列文章将介绍Volcano调度在华为云云容器引擎CCE中的运用。Volcano是一个基于Kubernetes的批处理平台，提供了机器学习、深度学习、生物信息学、基因组学及其他大数据应用所需要而Kubernetes当前缺失的一系列特性，提供了高性能任务调度引擎、高性能异构芯片管理、高性能任务运行管理等通用计算能力。集群中的调度是将pending状态的Pod分配到节点运行的过程，在CCE集群之中，Pod的调度依赖于集群中的调度器（kube-scheduler或者Volcano调度器）。调度器是通过一系列算法计算出Pod运行的最佳节点，但是Kubernetes集群环境是存在动态变化的，例如某一个节点需要维护，这个节点上的所有Pod会被驱逐到其他节点，但是当维护完成后，之前被驱逐的Pod并不会自动回到该节点上来，因为Pod一旦被绑定了节点是不会触发重新调度的。由于这些变化，集群在一段时间之后就可能会出现不均衡的状态。为了解决上述问题，Volcano调度器可以根据设置的策略，驱逐不符合配置策略的Pod，让其重新进行调度，达到均衡集群负载、减少资源碎片化的目的。  重调度功能介绍  ▍负载感知重调度（LoadAware）在K8s集群治理过程中，常常会因CPU、内存等高使用率状况而形成热点，既影响了当前节点上Pod的稳定运行，也会导致节点发生故障的几率的激增。为了应对集群节负载不均衡等问题，动态平衡各个节点之间的资源使用率，需要基于节点的相关监控指标，构建集群资源视图，在集群治理阶段，通过实时监控，在观测到节点资源率较高、节点故障、Pod 数量较多等情况时，可以自动干预，迁移资源使用率高的节点上的一些Pod到利用率低的节点上。图1 LoadAware策略示意图 使用该插件时，highThresholds需要大于lowThresholds，否则重调度器无法启用。正常节点：资源利用率大于等于30%且小于等于80%的节点。此节点的负载水位区间是期望达到的合理区间范围。热点节点：资源利用率高于80%的节点。热点节点将驱逐一部分Pod，降低负载水位，使其不超过80%。重调度器会将热点节点上面的Pod调度到空闲节点上面。空闲节点：资源利用率低于30%的节点。▍CPU和内存资源碎片率整理策略（HighNodeUtilization）从分配率低的节点上驱逐Pod。这个策略必须与Volcano调度器的binpack策略或者kube-scheduler调度器的MostAllocated策略一起使用。阈值可以分为CPU和内存两种资源角度进行配置。  前提条件  ✅ 已创建v1.19.16及以上版本的集群，具体操作请参见购买Standard/Turbo集群。✅ 集群中已安装1.11.5及以上版本的Volcano插件，具体操作请参见Volcano调度器。  约束与限制  ❌ 重调度之后的Pod，需要调度器进行调度，重调度器并未进行任何对于Pod和节点的标记行为，所以被驱逐的Pod调度到节点的行为完全被调度器控制，存在驱逐之后，被驱逐的Pod调度到原来节点的可能性。❌ 重调度功能暂不支持Pod间存在反亲和性的场景。如果使用重调度功能驱逐某个Pod后，由于该Pod与其他已运行的Pod存在反亲和性，调度器仍可能将其调度回驱逐前的节点上。❌ 配置负载感知重调度（LoadAware）时，Volcano调度器需要同时开启负载感知调度；配置CPU和内存资源碎片率整理策略（HighNodeUtilization）时，Volcano调度器需要同时开启binpack调度策略。  配置负载感知重调度策略  配置负载感知重调度（LoadAware）时，Volcano调度器需要同时开启负载感知调度，示例步骤如下。1、登录CCE控制台，单击集群名称进入集群。2、单击左侧导航栏的“插件中心”，在右侧找到Volcano调度器，单击“编辑”，在“扩展功能”中开启“重调度”的开关，单击“确定”完成插件配置更新。3、单击左侧导航栏的“配置中心”，通过“调度配置”页面启用负载感知调度。详情请参见负载感知调度。4、在“调度配置”页面，选择Volcano调度器找到对应的“专家模式”，单击“开始使用”。5、配置负载感知重调度策略。使用Volcano 1.11.21及更新版本，JSON格式的重要参数配置示例如下，其他参数请参见控制台“开始使用”中的JSON示例。{ ... "deschedulerPolicy": { "profiles": [ { "name": "ProfileName", "pluginConfig": [ { "args": { "ignorePvcPods": true, "nodeFit": true, "priorityThreshold": { "value": 100 } }, "name": "DefaultEvictor" }, { "args": { "evictableNamespaces": { "exclude": ["kube-system"] }, "metrics": { "type": "prometheus_adaptor" }, "targetThresholds": { "cpu": 80, "memory": 85 }, "thresholds": { "cpu": 30, "memory": 30 } }, "name": "LoadAware" } ], "plugins": { "balance": { "enabled": ["LoadAware"] } } } ] }, "descheduler_enable": "true", "deschedulingInterval": "10m" ... }表1 集群重调度策略关键参数表2 deschedulerPolicy配置参数 6、完成以上配置后，单击“确定”。  配置资源碎片整理策略  配置CPU和内存资源碎片率整理策略（HighNodeUtilization）时，Volcano调度器需要同时开启binpack调度策略，示例步骤如下。1、登录CCE控制台，单击集群名称进入集群。2、单击左侧导航栏的“插件中心”，在右侧找到Volcano调度器，单击“编辑”，在“扩展功能”中开启“重调度”的开关，单击“确定”完成插件配置更新。3、单击左侧导航栏的“配置中心”，通过“调度配置”页面启用装箱策略(binpack)。详情请参见装箱调度（Binpack）。4、在“调度配置”页面，选择Volcano调度器找到对应的“专家模式”，单击“开始使用”。5、配置资源碎片整理策略，JSON格式的重要参数配置示例如下，其他参数请参见控制台“开始使用”中的JSON示例。{... "deschedulerPolicy": { "profiles": [ { "name": "ProfileName", "pluginConfig": [ { "args": { "ignorePvcPods": true, "nodeFit": true, "priorityThreshold": { "value": 100 } }, "name": "DefaultEvictor" }, { "args": { "evictableNamespaces": { "exclude": ["kube-system"] }, "thresholds": { "cpu": 25, "memory": 25 } }, "name": "HighNodeUtilization" } ], "plugins": { "balance": { "enabled": ["HighNodeUtilization"] } } } ] }, "descheduler_enable": "true", "deschedulingInterval": "10m"...}参数说明deschedulingInterval重调度的周期。deschedulerPolicy集群重调度策略，详情请参见表4。表3 集群重调度策略关键参数表4 deschedulerPolicy配置参数 6. 完成以上配置后，单击“确定”。  使用案例  ▍资源碎片整理策略（HighNodeUtilization）使用案例1、单击集群控制台左侧导航栏的“节点管理”，查看集群之中的节点，发现存在部分分配率过低的节点。2、单击左侧导航栏的“配置中心”，在“调度配置”页面，选择Volcano调度器找到对应的“专家模式”，单击“开始使用”。3、编辑Volcano参数，设置CPU和内存的阈值为25。即表示节点的分配率小于25%时，该节点上的Pod会被驱逐。4、设置该策略后，将192.168.44.152节点上的Pod迁移到节点192.168.54.65，达到碎片整理的目的。  常见问题  当输入参数错误时，会有报警事件，例如：输入的配置不符合阈值范围、输入的配置格式不正确。如下图所示，可以按照事件提示进行修改。 🌍 Volcano 是业界首个云原生批量计算引擎，也是 CNCF 首个和唯一的批量计算项目。项目主要用于 AI、大数据、基因、渲染等诸多高性能计算场景，对主流通用计算框架均有很好的支持。目前，Volcano在人工智能、大数据、基因测序等海量数据计算和分析场景已得到快速应用，已完成对 Spark、Flink、Ray、 Tensorflow、PyTorch、Argo、MindSpore、Paddlepaddle 、Kubeflow、MPI、Horovod、Mxnet、KubeGene 等众多主流计算框架的支持，并构建起完善的上下游生态。📌 更多Volcano云原生批量计算 技术应用，请访问社区仓库或官网：Volcano云原生批量计算社区官网：https://volcano.shVolcano GitHub 仓库: cid:link_8Volcano云原生批量计算公开课：cid:link_6华为云云容器引擎CCE：cid:link_7 更多云原生技术动向关注容器魔方

 华为云云容器引擎CCE支持多种资源与任务调度策略，有助于提升应用性能和集群整体资源利用率，CPU资源调度、GPU/NPU异构资源调度以及Volcano调度的主要功能。本系列文章将介绍Volcano调度在华为云云容器引擎CCE中的运用。Volcano是一个基于Kubernetes的批处理平台，提供了机器学习、深度学习、生物信息学、基因组学及其他大数据应用所需要而Kubernetes当前缺失的一系列特性，提供了高性能任务调度引擎、高性能异构芯片管理、高性能任务运行管理等通用计算能力。装箱调度（Binpack）是一种优化算法，以最小化资源使用量为目标，将资源合理地分配给每个任务，使所有资源都可以实现最大化的利用价值。在集群工作负载的调度过程中使用Binpack调度策略，调度器会优先将Pod调度到资源消耗较多的节点，减少各节点空闲资源碎片，提高集群资源利用率。  前提条件  ✅ 已创建v1.19及以上版本的集群，详情请参见购买Standard/Turbo集群。✅ 已安装Volcano插件，详情请参见Volcano调度器。  Binpack功能介绍  Binpack调度算法的目标是最大限度地填满现有节点，尽量避免将Pod调度至空闲节点。具体实现中，调度器会对所有满足条件的节点进行打分，资源利用率越高，得分越高，调度优先级也越高。Binpack算法能够尽可能填满节点，将应用负载靠拢在部分节点，这非常有利于集群节点的自动扩缩容功能。Binpack为Volcano调度器的多个调度插件之一，与其他调度插件协同工作，共同影响节点的最终得分。用户可自定义Binpack插件的全局权重，并分别为CPU、内存基础资源以及 GPU、NPU等扩展资源配置打分权重，从而控制Binpack在调度决策中的影响程度。在计算Binpack得分时，调度器会综合考虑Pod所请求的各类资源，并基于各资源的打分权重进行加权平均，以确定节点的最终得分。  Binpack算法原理  在对节点打分时，Binpack会结合插件的全局权重和各资源维度（如CPU、内存、GPU等）的权重值，计算出节点Binpack得分。节点Binpack得分的计算流程如下：1️⃣ 首先，对Pod请求资源中的每类资源依次打分，以CPU为例，CPU资源在待调度节点的得分信息如下：CPU.weight * (request + used) / allocatable即CPU权重值越高，得分越高，节点资源使用量越满，得分越高。Memory、GPU等资源原理类似。其中：CPU.weight为用户设置的CPU权重request为当前Pod请求的CPU资源量used为当前节点已经分配使用的CPU量allocatable为当前节点CPU可用总量2️⃣ 通过Binpack策略的节点总得分如下：binpack.weight * (CPU.score + Memory.score + GPU.score) / (CPU.weight+ Memory.weight+ GPU.weight) * 100即binpack插件的权重值越大，得分越高，某类资源的权重越大，该资源在打分时的占比越大。其中：binpack.weight为用户设置的装箱调度策略权重CPU.score为CPU资源得分，CPU.weight为CPU权重Memory.score为Memory资源得分，Memory.weight为Memory权重GPU.score为GPU资源得分，GPU.weight为GPU权重 图1 Binpack策略示例3️⃣ 如图1所示，假设集群中存在两个节点，分别为Node 1和Node 2，当前有一个Pod请求了CPU、内存和GPU资源。在调度Pod时，Binpack策略将对两个节点进行打分。假设集群中CPU.weight配置为1，Memory.weight配置为1，GPU.weight配置为2，binpack.weight配置为5。Binpack对Node 1的打分信息如下：各资源按照公式计算得分，具体信息如下：CPU Score：CPU.weight * (request + used) / allocatable = 1 * （2 + 4）/ 8 = 0.75Memory Score：Memory.weight * (request + used) / allocatable = 1 * (4 + 8) / 16 = 0.75GPU Score： GPU.weight * (request + used) / allocatable = 2 * （4 + 4）/ 8 = 2节点总得分按照 binpack.weight * (CPU.score + Memory.score + GPU.score) / (CPU.weight+ Memory.weight+ GPU.weight) * 100 公式进行计算，具体如下：假设binpack.weight配置为5，Node 1在Binpack策略下的得分：5 * （0.75 + 0.75 + 2）/（1 + 1 + 2）* 100 = 437.5Binpack对Node 2的打分信息如下：CPU Score：CPU.weight * (request + used) / allocatable = 1 * （2 + 6）/ 8 = 1Memory Score：Memory.weight * (request + used) / allocatable = 1 * (4 + 8) / 16 = 0.75GPU Score：GPU.weight * (request + used) / allocatable = 2 * （4 + 4）/ 8 = 2Node 2在Binpack策略下的得分：5 * （1 + 0.75 + 2）/（1 + 1 + 2）* 100 = 468.754️⃣ 综上，Node 2得分大于Node 1，按照Binpack策略，Pod将会优先调度至Node 2。  配置装箱调度策略  安装Volcano后，Binpack策略默认生效。如果默认配置无法达到您降低资源碎片的目标，可以通过“配置中心 > 调度配置”页面自定义Binpack策略权重和各资源维度权重值，增加或降低Binpack策略在整体调度中的影响力。1、登录CCE控制台，单击集群名称进入集群。2、在左侧选择“配置中心”，在右侧选择“调度配置”页签。3、在“资源利用率优化调度”配置中，启用装箱策略 (binpack)。名称说明默认值装箱调度策略权重增大该权重值，可提高装箱策略在整体调度中的影响力。10CPU权重增大该权重值，优先提高集群CPU利用率。1内存权重增大该权重值，优先提高集群Memory利用率。1自定义资源类型指定Pod请求的其他自定义资源类型，例如nvidia.com/gpu。增大该权重值，优先提高指定资源的利用率。-4、图2 资源利用率优化调度5、修改完成后，单击“确认配置”。 📌 更多Volcano云原生批量计算 技术应用，请访问社区仓库或官网：Volcano云原生批量计算社区官网：https://volcano.shVolcano GitHub 仓库: cid:link_6Volcano云原生批量计算公开课：cid:link_4华为云云容器引擎CCE：cid:link_5 Volcano 是业界首个云原生批量计算引擎，也是 CNCF 首个和唯一的批量计算项目。项目主要用于 AI、大数据、基因、渲染等诸多高性能计算场景，对主流通用计算框架均有很好的支持。目前，Volcano在人工智能、大数据、基因测序等海量数据计算和分析场景已得到快速应用，已完成对 Spark、Flink、Ray、 Tensorflow、PyTorch、Argo、MindSpore、Paddlepaddle 、Kubeflow、MPI、Horovod、Mxnet、KubeGene 等众多主流计算框架的支持，并构建起完善的上下游生态。 更多云原生技术动向关注容器魔方  

华为云云容器引擎CCE支持多种资源与任务调度策略，有助于提升应用性能和集群整体资源利用率，CPU资源调度、GPU/NPU异构资源调度以及Volcano调度的主要功能。本系列文章将介绍Volcano调度在华为云云容器引擎CCE中的运用。Volcano是一个基于Kubernetes的批处理平台，提供了机器学习、深度学习、生物信息学、基因组学及其他大数据应用所需要而Kubernetes当前缺失的一系列特性，提供了高性能任务调度引擎、高性能异构芯片管理、高性能任务运行管理等通用计算能力。一般情况下，Kubernetes在调度工作负载时会使用自带的默认调度器，若需要使用Volcano调度器的能力，您可以为工作负载指定调度器。关于Kubernetes调度器的详情请参见为Pod指定调度器。  约束与限制  调度大量工作负载的场景下，Volcano会打印较多的日志，建议搭配日志服务使用，否则可能导致日志过多占满所在节点磁盘。  使用Volcano调度工作负载  使用Volcano调度工作负载时，只需要在Pod的spec字段中设置schedulerName参数并指定参数值为volcano，示例如下：1、使用yaml创建queue：apiVersion: scheduling.volcano.sh/v1beta1kind: Queuemetadata:  name: q1spec:  reclaimable: true  weight: 12、在Pod的spec字段中设置schedulerName参数并指定参数值为volcano：apiVersion: apps/v1kind: Deploymentmetadata:  name: nginx  labels:    app: nginxspec:  replicas: 4  selector:    matchLabels:      app: nginx  template:    metadata:      annotations:        # 指定作业到q1队列        scheduling.volcano.sh/queue-name: "q1"        volcano.sh/preemptable: "true"      labels:        app: nginx    spec:      # 指定调度器为Volcano      schedulerName: volcano      containers:      - name: nginx        image: nginx        imagePullPolicy: IfNotPresent        resources:          limits:            cpu: 1            memory: 100Mi          requests:            cpu: 1            memory: 100Mi        ports:        - containerPort: 80 同时，Volcano还支持设置负载所属队列和抢占属性等，可通过Pod的注解实现。目前Volcano支持的Pod注解配置如下：Pod注解说明scheduling.volcano.sh/queue-name: "<queue-name>"指定负载所在队列，其中<queue-name>为队列名称。volcano.sh/preemptable: "true"表示作业是否可抢占。开启后，认为该作业可以被抢占。取值范围：true：开启抢占。（默认为开启状态）false：关闭抢占。 可通过查询Pod详情查看Pod是否由Volcano调度，以及被分配的队列：1、使用以下命令查询Pod详情并获取scheduling.k8s.io/group-name的值：kubectl describe pod <pod_name>Pod的scheduling.k8s.io/group-name值回显如下：2、查看Pod是否由Volcano调度，以及被分配的队列：kubectl describe pg <group_name>回显如下：Spec:  Min Member:  1  Min Resources:    Cpu:     100m    Memory:  100Mi  Queue:     q1Status:  Conditions:    Last Transition Time:  2023-05-30T01:54:43Z    Reason:                tasks in gang are ready to be scheduled    Status:                True    Transition ID:         70be1d7d-3532-41e0-8324-c7644026b38f    Type:                  Scheduled  Phase:                   RunningEvents:  Type    Reason     Age              From     Message  ----    ------     ----             ----     -------  Normal  Scheduled  0s (x3 over 2s)  volcano  pod group is ready 📌 更多Volcano云原生批量计算社区运用，请访问社区仓库或官网：Volcano云原生批量计算社区：https://volcano.shVolcano GitHub: cid:link_2Volcano云原生批量计算公开课：cid:link_0华为云云容器引擎CCE：cid:link_1 Volcano 是业界首个云原生批量计算引擎，也是 CNCF 首个和唯一的批量计算项目。项目主要用于 AI、大数据、基因、渲染等诸多高性能计算场景，对主流通用计算框架均有很好的支持。目前，Volcano在人工智能、大数据、基因测序等海量数据计算和分析场景已得到快速应用，已完成对 Spark、Flink、Ray、 Tensorflow、PyTorch、Argo、MindSpore、Paddlepaddle 、Kubeflow、MPI、Horovod、Mxnet、KubeGene 等众多主流计算框架的支持，并构建起完善的上下游生态。 更多云原生技术动向关注容器魔方 

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

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

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

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