Karmada是开放的多云多集群容器编排引擎，旨在帮助用户在多云环境下部署和运维业务应用。凭借兼容 Kubernetes 原生 API 的能力，Karmada 可以平滑迁移单集群工作负载，并且仍可保持与 Kubernetes 周边生态工具链协同。Karmada v1.14 版本[1] 现已发布，本版本包含下列新增特性：新增联邦资源配额管理能力，用于多租户场景下资源治理新增定制化污点管理能力，消除隐式集群故障迁移Karmada Operator 功能持续演进Karmada 控制器性能显著提升 新 特 性 概 览 ▍联邦资源配额管理在多租户的云基础设施中，配额管理是确保资源公平分配和防止超额使用的关键。尤其在多云多集群环境下，分散的配额系统往往导致资源监控困难和管理割裂，因此实现跨集群的联邦配额管理成为提升资源治理效率的核心要素。此前，Karmada 通过 FederatedResourceQuota 将全局配额分配至成员集群，由各集群本地实施配额管控。本次版本升级增强了联邦配额管理能力，新增控制平面全局配额检查机制，支持直接在控制平面进行全局资源配额校验。该功能特别适用于以下场景：您需要从统一位置跟踪资源消耗和限制，而无需关注集群级别的分配情况。您希望通过验证配额限制来避免超额的任务提交。注意：该特性目前处于 Alpha 阶段，需要启用 FederatedQuotaEnforcement Feature Gate 才能使用。假设您想设置总体 CPU 限制为 100，您可以按照如下配置进行定义：apiVersion: policy.karmada.io/v1alpha1kind: FederatedResourceQuotametadata: name: team-foo namespace: team-foospec: overall: cpu: 100一旦应用，Karmada 将开始监控和执行 test 命名空间的 CPU 资源限制。假设您应用了一个需要 20 个 CPU 的新 Deployment。联邦资源配额的状态将更新为如下所示：spec: overall: cpu: 100status: overall: cpu: 100 overallUsed: cpu: 20如果您应用的资源超过 100 个CPU的限制，该资源将不会被调度到您的成员集群。有关此功能的详细用法，可以参考特性使用文档：Federated ResourceQuota[2]。▍定制化污点管理在 v1.14 之前的版本中，当用户启用故障转移功能时，系统在检测到健康状态异常后会自动向集群添加一个 NoExecute effect 污点，从而触发目标集群上所有资源的迁移。在这个版本中，我们对系统中潜在的迁移触发因素进行了全面审查。所有隐含的集群故障转移行为已被消除，并且引入了针对集群故障机制的明确约束条件。这使得因集群故障而引发的资源迁移能够得到统一管理，进一步增强了系统的稳定性和可预测性。集群故障条件是通过评估出现故障的集群对象的状态条件来确定的，以便应用污点，这一过程可以称为“Taint Cluster By Conditions”。此版本引入了一个新的 API - ClusterTaintPolicy，它允许用户自定义规则，以便在预定义的集群状态条件得到满足时，为目标集群添加特定的污点。对于更复杂的集群故障判断场景，用户可以直接实现一个自定义的“集群污点控制器”，以控制如何向集群对象添加或移除污点。ClusterTaintPolicy 是一种 Cluster scope 资源，下面我们给一个简单的例子来说明它的用法：apiVersion: policy.karmada.io/v1alpha1kind: ClusterTaintPolicymetadata: name: detect-cluster-notreadyspec: targetClusters: clusterNames: - member1 - member2 addOnConditions: - conditionType: Ready operator: NotIn statusValues: - "True" - conditionType: NetworkAvailable operator: NotIn statusValues: - "True" removeOnConditions: - conditionType: Ready operator: In statusValues: - "True" - conditionType: NetworkAvailable operator: In statusValues: - "True" taints: - key: not-ready effect: NoSchedule - key: not-ready effect: NoExecute上面的例子描述了一个针对 member1 和 member2 集群的 ClusterTaintPolicy 资源，当集群的状态条件同时满足 Type 为 Ready 和 NetworkAvailable 的 condition value 不等于 True 时，会为目标集群添加污点 {not-ready:NoSchedule} 与 {not-ready:NoExecute}；当集群的状态条件同时满足 Type 为 Ready 和 NetworkAvailable 的 condition value 等于 True 时，会移除目标集群上的污点 {not-ready:NoSchedule} 和 {not-ready:NoExecute}。有关此功能的详细用法，可以参考特性使用文档：集群污点管理[3]。▍Karmada Operator 功能持续演进本版本持续增强 Karmada Operator，新增以下功能：支持配置 Leaf 证书有效期。支持 Karmada 控制平面暂停调谐。支持为 karmada-webhook 组件配置 feature gates。支持为 karmada-apiserver 组件执行 loadBalancerClass 以选择特定的负载均衡实现。引入 karmada_build_info 指标来展示构建信息，以及一组运行时指标。这些改进使得karmada-operator更加灵活且可定制，提高了整个Karmada系统的可靠性和稳定性。▍Karmada 控制器性能显著提升自 1.13 版本发布以来，Karmada adopters 自发组织起来对 Karmada 性能进行优化。如今，一个稳定且持续运作的性能优化团队 SIG-Scalability 已经组建，致力于提升 Karmada 的性能与稳定性。感谢所有参与者付出的努力。如果大家有兴趣，随时欢迎大家加入。在本次版本中，Karmada 实现了显著的性能提升，尤其是在 karmada-controller-manager 组件中。为验证这些改进，实施了以下测试设置：测试设置包括 5000 个 Deployment，每个 Deployment 都与一个相应的 PropagationPolicy 配对，该策略将其调度到两个成员集群。每个 Deployment 还依赖一个唯一的 ConfigMap，它会与Deployment 一起分发到相同的集群。这些资源是在 karmada-controller-manager 组件离线时创建的，这意味着在测试期间 Karmada 首次对它们进行同步。测试结果如下：冷启动时间（清空工作队列）从约 7 分钟缩短至约 4 分钟，提升了 45%。资源检测器：平均处理时间的最大值从 391 毫秒降至 180 毫秒（提升了 54%）。依赖分发器：平均处理时间的最大值从 378 毫秒降至 216 毫秒（提升了 43%）。执行控制器：平均处理时间的最大值从 505 毫秒降至 248 毫秒（提升了 50%）。除了更快的处理速度，资源消耗也显著降低：CPU使用率从 4 - 7.5 核降至 1.8 - 2.4 核（降幅 40% - 65%）。内存峰值使用量从 1.9 GB 降至 1.47 GB（降幅 22%）。这些数据证明，在 1.14 版本中，Karmada 控制器的性能得到了极大提升。未来，我们将继续对控制器和调度器进行系统性的性能优化。相关的详细测试报告，请参考 [Performance] Overview of performance improvements for v1.14[4] 。 致 谢 贡 献 者 Karmada v1.14 版本包含了来自 30 位贡献者的 271 次代码提交，在此对各位贡献者表示由衷的感谢：贡献者列表：相关链接[1] Karmada v1.14 版本: https://github.com/karmada-io/karmada/releases/tag/v1.14.0[2] Federated ResourceQuota: https://karmada.io/zh/docs/userguide/bestpractices/federated-resource-quota/[3] 集群污点管理: https://karmada.io/docs/next/userguide/failover/cluster-taint-management/[4] [Performance] Overview of performance improvements for v1.14: https://github.com/karmada-io/karmada/issues/6394Karmada 是CNCF 首个多云多集群容器编排项目(孵化级），旨在帮助用户像使用单个集群一样轻松管理跨云多集群，让基于 Karmada 的多云方案无缝融入云原生技术生态。社区吸引了来自华为、道客、浙江大学、腾讯、中国电子云、滴滴、Zendesk、携程等100多家公司的全球贡献者，广泛分布于20+国家和地区。Karmada 现已在华为云、道客、兴业数金、中国移动、中国联通、携程、360集团、新浪、中通快递等众多企业单位生产应用，为企业提供从单集群到多云架构的平滑演进方案。添加社区小助手k8s2222回复Karmada进入技术交流群Karmada官网：https://karmada.io/项目地址：https://github.com/karmada-io/karmadaSlack地址：https://slack.cncf.io/（#karmada）

北京时间2025年6月18日，KubeEdge 发布1.21.0版本。新版本对节点任务框架（节点升级、镜像预下载）做了全面更新，并新增云端更新边缘配置的能力，同时 Dashboard 新增对 keink 的集成，支持一键部署，在易用性、管理运维能力上做了全面增强。KubeEdge v1.21.0 新增特性：全新节点任务 API 以及实现节点组流量闭环优化 支持在云端更新边缘配置集成 kubeedge/keink，支持一键部署 Dashboard  新特性概览  ▍全新节点任务API以及实现 当前 KubeEdge 中的节点任务资源（节点升级、镜像预下载）的状态设计较为复杂，可读性较差。此外，在执行节点任务的过程中，一些错误不会被记录到状态中导致无法定位任务失败的原因。因此我们对节点状态和运行流程进行了重新设计，设计目标如下：定义一个新的节点任务的状态结构，使其更易于用户和开发者理解跟踪整个流程的错误信息，将其写入状态中展示开发一个更合理的节点任务流程框架在新的设计中，节点任务的状态由总阶段（phase）和各节点执行任务的状态（nodeStatus）组成。节点任务的阶段（phase）有四个枚举值分别为：Init、InProgress、Completed 或 Failure，该值通过每个节点的执行状态计算所得。节点执行任务的状态由阶段（phase）、节点执行的动作流（actionFlow）、节点名称（nodeName）、执行动作流以外的错误原因（reason）以及业务相关的一些字段（如镜像预下载任务的每个镜像下载状态）组成。节点执行任务的阶段（phase）有五个枚举值分别为：Pending、InProgress、Successful、Failure 和 Unknown。动作流是一个数组结构，记录了每个动作（action）的执行结果，状态（Status）复用了 Kubernetes 的 ConditionStatus，用 True 和 False 表示动作的成功或失败，并且记录了动作的失败原因（reason）和执行时间（time）。👇🏻 节点升级任务的状态 YAML 样例如下：status: nodeStatus: - actionFlow: - action: Check status: 'True' time: '2025-05-28T08:12:01Z' - action: WaitingConfirmation status: 'True' time: '2025-05-28T08:12:01Z' - action: Backup status: 'True' time: '2025-05-28T08:12:01Z' - action: Upgrade status: 'True' time: '2025-05-28T08:13:02Z' currentVersion: v1.21.0 historicVersion: v1.20.0 nodeName: ubuntu phase: Successful phase: Completed我们对节点任务的云边协作流程也进行了重新设计。为了避免 CloudCore 多实例导致的节点任务更新产生并发冲突，我们将节点任务的初始化和节点任务的状态计算放在 ControllerManager 中处理，因为 ControllerManager 总是单实例运行的。👇🏻 具体流程如下：1. 当节点任务 CR 被创建后，ControllerManager 会初始化匹配的节点的状态；2. CloudCore 只会处理 ControllerManager 处理过的节点任务资源，通过执行器（Executor）和下行控制器（DownstreamController）将节点任务下发给节点；3. EdgeCore 接收到节点任务后，通过运行器（Runner）执行动作，并将每个动作的执行结果上报给 CloudCore；4. CloudCore 通过上行控制器（UpstreamController）接收动作运行的结果并将结果更新到节点任务的状态中；5. ControllerManager 监听节点任务资源的变化计算整个节点任务的状态进行更新。在整个处理流程中，我们将流程中可能产生的错误都记录并更新到了节点任务资源状态的原因字段中。更多信息可参考：cid:link_0/blob/master/docs/proposals/edge-node-tasks-status-enhancement.mdcid:link_0/issues/5999cid:link_0/issues/6211cid:link_0/issues/6273▍节点组流量闭环优化 在 KubeEdge 1.21.0 中，我们对节点组的流量闭环功能进行了全面优化，使其功能更完善、使用更灵活。这一功能的核心能力是：通过一个 Service 实现“节点组内应用只能访问同组内应用服务，无法访问其他节点组的服务。借助该机制，用户可以轻松实现边缘多区域间的网络隔离，确保不同区域的应用服务之间互不干扰。➤ 应用场景举例：以连锁门店为例，企业可将全国各地的门店按区域划分为多个节点组（如华东、华北、西南等），每个区域的门店部署相同类型的应用（如库存管理、收银系统），但业务数据互相隔离。通过流量闭环功能，系统可自动限制服务访问范围，仅在节点组内互通，避免跨区域访问，无需额外配置网络策略。流量闭环功能为可选项。如果用户不希望开启节点组间的流量隔离，只需在 EdgeApplication 中不配置 Service 模板，系统则不会启用该能力，应用依然可以按原有方式进行通信。👇🏻 使用样例：apiVersion: apps.kubeedge.io/v1alpha1kind: NodeGroupmetadata: name: beijingspec: nodes: - node-1 - node-2---apiVersion: apps.kubeedge.io/v1alpha1kind: NodeGroupmetadata: name: shanghaispec: nodes: - node-3 - node-4---apiVersion: apps.kubeedge.io/v1alpha1kind: EdgeApplicationmetadata: name: test-service namespace: defaultspec: workloadScope: targetNodeGroups: - name: beijing overriders: resourcesOverriders: - containerName: container-1 value: {} - name: shanghai overriders: resourcesOverriders: - containerName: container-1 value: {} workloadTemplate: manifests: - apiVersion: v1 kind: Service metadata: name: test-service namespace: default spec: ipFamilies: - IPv4 ports: - name: tcp port: 80 protocol: TCP targetPort: 80 selector: app: test-service sessionAffinity: None type: ClusterIP - apiVersion: apps/v1 kind: Deployment metadata: labels: kant.io/app: '' name: test-service namespace: default spec: replicas: 1 selector: matchLabels: app: test-service template: metadata: labels: app: test-service spec: containers: - name: container-1 ... terminationGracePeriodSeconds: 30 tolerations: - effect: NoSchedule key: node-role.kubernetes.io/edge operator: Exists使用样例更多信息可参考：cid:link_0/pull/6097cid:link_0/pull/6077▍支持在云端更新边缘配置 相较于登录每个边缘节点手动更新 EdgeCore 的配置文件 edgecore.yaml，能够直接从云端更新 edgecorer.yaml 要更便利。尤其是对于批量节点操作，同时更新多个边缘节点的配置文件，能够提高管理效率，节约很多运维成本。在v1.21.0中，我们引入了ConfigUpdateJob CRD，允许用户在云端更新边缘节点的配置文件。CRD 中的 updateFields 用于指定需要更新的配置项。👇🏻 CRD 示例：apiVersion: operations.kubeedge.io/v1alpha2kind: ConfigUpdateJobmetadata: name: configupdate-testspec: failureTolerate: "0.3" concurrency: 1 timeoutSeconds: 180 updateFields: modules.edgeStream.enable: "true" labelSelector: matchLabels: "node-role.kubernetes.io/edge": "" node-role.kubernetes.io/agent: ""💭 注意：该特性在1.21中默认关闭，如需使用，请启动云端的 controllermamager 和 taskmanager 以及边缘端的 taskmanager 模块 更新边缘配置会涉及 EdgeCore 重启更多信息可参考：cid:link_0/pull/6024cid:link_0/pull/6338▍集成kubeedge/keink，支持一键部署Dashboard新版本对 Dashboard 进行了增强，为 KubeEdge 控制面板设计了一个 BFF（Backend for Frontend）层，以连接前端用户界面层和 KubeEdge 后端 API。它作为数据传输和处理中心，提供专用的后端服务，简化了前端的数据检索逻辑，提高了性能和安全性。此外，为了让开发人员快速体验和部署 kubeedge，我们与 kubeedge/keink 项目深度集成。只需一条命令，在 dashboard 上就能快速启动 kubeedge 环境，对其功能进行完整的演示和验证。更多信息可参考：https://github.com/kubeedge/dashboard/pull/50 版本升级注意事项 ▍节点任务新版本默认开启 v1alpha2 版本的节点任务，CRD 定义会向下兼容，如果想继续使用 v1alpha1 版本的 NodeUpgradeJob 和 ImagePrePullJob，可以通过设置ControllerManager 和 CloudCore 的特性门切换。ControllerManager 添加启动参数--feature-gates=disableNodeTaskV1alpha2CloudCore 修改配置文件kubectl edit configmap -n kubeedge cloudcore修改配置内容：apiVersion: cloudcore.config.kubeedge.io/v1alpha2 kind: CloudCore+ featureGates:+ disableNodeTaskV1alpha2: true ...💭 注意：v1alpha2 版本节点任务的 CRD 能兼容 v1alpha1，但是它们不能相互切换，v1alpha1 的代码逻辑会破坏 v1alpha2 节点任务 CR 的数据。v1alpha1 的节点任务基本不会再进行维护，v1.23 版本后将删除 v1alpha1 版本节点任务的相关代码。另外，节点任务在边端已成为一个默认关闭的 Beehive 模块，如果要正常使用节点任务功能的话，需要修改边端 edgecore.yaml 配置文件开启： modules: ...+ taskManager:+ enbale: true▍边缘节点升级我们对 Keadm 边缘节点升级的相关命令（备份、升级、回滚）做了调整：1. 升级命令不会自动执行备份命令，备份命令需要手动触发；2. 升级命令隐藏了业务相关的参数，v1.23 版本后会清理废弃的代码；3. 升级的相关命令都使用三级命令： keadm edge upgrade keadm edge backup keadm edge rollback▍致谢感谢 KubeEdge 社区技术指导委员会 (TSC)、各 SIG 成员对 v1.21 版本开发的支持与贡献，未来 KubeEdge 将持续在新场景探索与支持、稳定性、安全性、可扩展性等方面持续发展与演进！▍相关链接Release Notes：cid:link_0/blob/master/CHANGELOG/CHANGELOG-1.21.md【更多KubeEdge资讯推荐】玩转KubeEdge保姆级攻略——环境搭建篇玩转KubeEdge保姆级攻略——环境搭建篇《玩转KubeEdge保姆级攻略——环境搭建篇》课程主要介绍如何通过华为云服务快速搭建一套KubeEdge边缘计算开发平台及部署Sedna、EdgeMesh等KubeEdge生态组件。课程免费学习链接：https://connect.huaweicloud.com/courses/learn/course-v1:HuaweiX+CBUCNXNX022+Self-paced/aboutKubeEdge社区介绍：KubeEdge是业界首个云原生边缘计算框架、云原生计算基金会（CNCF）唯一毕业级边缘计算开源项目，社区已完成业界最大规模云原生边云协同高速公路项目（统一管理10万边缘节点/50万边缘应用）、业界首个云原生星地协同卫星、业界首个云原生车云协同汽车、业界首个云原生油田项目，开源业界首个分布式协同AI框架Sedna及业界首个边云协同终身学习范式，并在持续开拓创新中。KubeEdge网站 :  https://kubeedge.ioGitHub地址 : cid:link_0Slack地址 : https://kubeedge.slack.com邮件列表 : https://groups.google.com/forum/#!forum/kubeedge每周社区例会 : https://zoom.us/j/4167237304Twitter : https://twitter.com/KubeEdge文档地址 : https://docs.kubeedge.io/en/latest/

一行代码，都是改变世界的火种；每一次尝试，都在为数字未来写下注脚。从鸿蒙初启到星辰大海，从盘古开天到智能大潮，我们始终相信：技术的力量，始于微小，成于坚持。2025 年 6 月 20 日-22 日，华为云开源诚邀你共赴东莞松山湖，在华为开发者大会（HDC 2025）的舞台上，与全球开发者一起，用代码编织智慧时代的经纬。华为云开源将会在本次大会给广大开发者带来 1 场专题论坛、2 个展台、7 场开发者实操活动，让开发者“听到、看到、做到“，沉浸式体验开源技术的魅力。开源专题论坛将由华为云首席架构师顾炯炯领衔演讲，本场论坛议题与业界热点话题紧扣，包含了 Serverless、云原生、前端 AI 应用、开源开发者等话题。大会期间，前沿科技将与创新 idea 激情碰撞，你在这里可以聆听行业大咖的奇思妙想，参与头脑风暴式的研讨交流。更有精心设计的多种开发者实操活动，助力你提升技能、拓展人脉、解锁新机遇。开源专题论坛：AI+开源，赋能开发者迈向 AI 时代➤ 开源应用解决方案亮相展台，AI+前端会碰撞出什么样的火花？本次华为云开源专属展岛将重点展示“云原生应用解决方案“和”前端智能化解决方案“。展台现场由技术专家面对面带你深入解读相关技术内核，demo 实操帮助你直观感受产品力。前端智能化解决方案展区更是为广大开发者带来了两款前端新开源应用 TinyVue 和 MateChat，使开发者轻松开发接入 AI 大模型，助力用户搭建前端智能化交互场景。➤ 挑战自我，就来解锁开发者活动本次大会还为开发者打造了丰富多彩的开源主题开发者活动，涵盖了 AI、前端开发、微服务、数据库等前沿技术领域，贴合不同开发者的技术进阶需求。参与者将能够近距离汲取行业大咖的前沿经验与深度洞见，通过实操活动实现技能提升。无论是初涉行业的技术新手，还是深耕领域多年的资深专家，均能在本次大会上找到自己的舞台。更多活动信息可登录华为开发者大会2025官网查看，欢迎开发者预约报名开源专题论坛，积极参与开发者活动。我们诚挚地邀请每一位怀揣开源热忱的开发者共赴这场年度盛会，携手探索、学习与成长。东莞松山湖，期待与你相见！👉 华为开发者大会2025参会直达：➤  华为开发者大会2025官网：cid:link_7➤【专题论坛】智能驱动的全新一代AI-Native云原生基础设施: https://developer.huawei.com/home/hdc/agenda/trackDetail?type=agenda004&A-code=421795d727874808a44aa9efd7450f07➤【专题论坛】AI+开源：赋能开发者迈向AI时代: https://developer.huawei.com/home/hdc/agenda/trackDetail?type=agenda004&A-code=ae63c0c8312c4b3598910e575576d3e9更多云原生技术动向关注容器魔方【更多华为云云原生干货推荐】华为云云原生王者之路集训营华为云云原生王者之路集训营为帮助广大技术爱好者快速掌握云原生相关技能，华为云云原生团队与华为云学院联合CNCF开源软件大学启动人才培养计划，推出《华为云云原生王者之路集训营》，从云原生基础知识介绍到最佳实践讲解、底层原理和方案架构深度剖析，层层深入，满足不同云原生技术基础和学习目标人群的需求。本课程还精选数十个企业典型应用场景，作为学员上机实践案例，帮助学员将所学技术快速与企业业务相结合，服务于企业生产。点击免费参加华为云云原生王者之路集训营：cid:link_6 学习后记得小试牛刀，看看测评效果~ 华为云云原生王者之路-黄金课程测评 华为云云原生王者之路-钻石课程测评 华为云云原生王者之路-王者课程测评

大家好！作为一个不太搞笑的华为云研发攻城妹 👩‍💻以下是小编精心准备的参会邀请⏱ 辛苦您花费2.5分钟阅读如果已有参会计划，小编诚挚邀请您来参加我们的专题论坛~ 华为开发者大会2025（简称HDC 2025）将于6月20日~6月22日在东莞举办听说今年HDC有XX场专题论坛，咱们的论坛是哪一个？（具体有几场小编也没数过，总而言之，就是很丰富！）#我们的论坛名字是#智能驱动的全新一代AI-Native云原生基础设施#我们见面的时间#2025年6月22日 9:30-10:30#我们见面的地点是#@东莞松山湖 –溪流背坡村 H8-2C11听说除了华为云全新一代AI-Native云基础设施干货分享以外，还有两位重磅嘉宾？是的，没错！#他们是#以“打造有生命的AI”为使命的超参数科技和将“帮大家吃得更好，生活更好”作为愿景的美团分别带来游戏AI和零售科技领域，基于AI-Native云原生基础设施的落地实践听说云原生开源大神Kevin Wang，也会来咱们论坛？是的，没错！#Kevin Wang#王泽锋华为云云原生开源负责人，CNCF技术监督委员会副主席聊技术，行！见大咖，安排！听干货，没问题！ 早起的鸟儿有虫吃，早起的你，（小编）有（等）我（你）们（来）！6月22日 9:30-10:30东莞溪流背坡村H8-2C11不见不散！🔖 前方高能 🔖AI-Native云原生基础设施开源项目也一样有“料”如果你是云原生开源隐藏玩家欢迎同时将以下专题论坛加入行程【专题论坛】AI+开源：赋能开发者迈向AI时代6月21日 13:30-14:30溪流背坡村H8-1C11社区有矿，等你来挖！👉 华为开发者大会2025参会直达：➤  华为开发者大会2025官网：cid:link_7➤【专题论坛】智能驱动的全新一代AI-Native云原生基础设施: https://developer.huawei.com/home/hdc/agenda/trackDetail?type=agenda004&A-code=421795d727874808a44aa9efd7450f07➤【专题论坛】AI+开源：赋能开发者迈向AI时代: https://developer.huawei.com/home/hdc/agenda/trackDetail?type=agenda004&A-code=ae63c0c8312c4b3598910e575576d3e9更多云原生技术动向关注容器魔方【更多华为云云原生干货推荐】华为云云原生王者之路集训营华为云云原生王者之路集训营为帮助广大技术爱好者快速掌握云原生相关技能，华为云云原生团队与华为云学院联合CNCF开源软件大学启动人才培养计划，推出《华为云云原生王者之路集训营》，从云原生基础知识介绍到最佳实践讲解、底层原理和方案架构深度剖析，层层深入，满足不同云原生技术基础和学习目标人群的需求。本课程还精选数十个企业典型应用场景，作为学员上机实践案例，帮助学员将所学技术快速与企业业务相结合，服务于企业生产。点击免费参加华为云云原生王者之路集训营：cid:link_6 学习后记得小试牛刀，看看测评效果~ 华为云云原生王者之路-黄金课程测评 华为云云原生王者之路-钻石课程测评 华为云云原生王者之路-王者课程测评

华为云开发者大会(HDC)将于6月20日-22日分别在东莞篮球中心和东莞松山湖举行,华为云云原生基础设施专题论坛诚邀您光临。更多云原生技术动向关注容器魔方【更多华为云云原生干货推荐】华为云云原生王者之路集训营华为云云原生王者之路集训营为帮助广大技术爱好者快速掌握云原生相关技能，华为云云原生团队与华为云学院联合CNCF开源软件大学启动人才培养计划，推出《华为云云原生王者之路集训营》，从云原生基础知识介绍到最佳实践讲解、底层原理和方案架构深度剖析，层层深入，满足不同云原生技术基础和学习目标人群的需求。本课程还精选数十个企业典型应用场景，作为学员上机实践案例，帮助学员将所学技术快速与企业业务相结合，服务于企业生产。点击免费参加华为云云原生王者之路集训营：cid:link_3 学习后记得小试牛刀，看看测评效果~ 华为云云原生王者之路-黄金课程测评 华为云云原生王者之路-钻石课程测评 华为云云原生王者之路-王者课程测评

6月10日-11日，云原生计算基金会（CNCF）旗舰会议 KubeCon+CloudNativeCon China 2025 在中国香港盛大召开。华为云云原生技术团队在主题演讲, 分论坛，圆桌等多个会场带来10+场精彩演讲，深度分享云原生 AI 调度、智能边缘、多云容器、数据库、流量治理等领域前沿技术成果，领先构建 AI-Native 云原生基础设施，加速行业智能化升级。    开源生态引领AI时代技术跃迁  ▍Towards Clouds of AI Clusters会上，华为首席开源联络官， CNCF 基金会董事任旭东带来 “Towards Clouds of AI Clusters” Keynote 主题演讲，深度分享了AI原生时代的算力集群技术演进趋势，及华为在异构集群管理、云边协同AI、超大规模调度等领域的应用实践。任旭东表示，当前企业在管理 AI 工作负载时，仍面临严峻挑战，尤其是在大模型训练、推理中对算力规模和集群协同的极高要求。应对大模型背后的算力困局，不仅需要异构硬件的高效协同，更依赖开源技术栈和分布式范式，如数据并行、模型并行、流水线并行进行深度支持，对异构算力的全栈兼容，最终才能在降低单位训练推理成本的同时，加速万亿参数级模型的商业化落地进程。华为通过 openEuler、Volcano、Karmada、KubeEdge 等开源项目，从硬件驱动到集群资源调度实现算力设备的统一管理，支持 HyperNode 与多集群拓扑感知调度，并对 PyTorch / TensorFlow / MindSpore 等主流框架、大语言模型（ LLMs ）及智能体开发场景提供统一支持的全栈开源基础设施解决方案。▍Volcano+Karmada 驱动 B 站亿级月活云原生AI调度华为云云原生开源负责人，CNCF 技术监督委员会副主席王泽锋联合 Bilibili 资深研发工程师许龙，发表 “Optimizing AI Workload Scheduling: Bilibili's Journey to an Efficient Cloud Native AI Platform” Keynote 主题演讲，深入探讨 B 站人工智能工作负载调度优化实践。Bilibili 拥有上亿月活用户，围绕视频业务覆盖搜索推荐、图像处理、视频编解码等多种应用场景。在 AI 技术深度渗透视频处理、模型训练等场景的当下，B站面对负载多样性、多集群管理等算力挑战，构建了以 Volcano 和 Karmada 为核心的调度框架：单集群侧通过 Volcano 实现 Workload 统一调度，引入等价类调度与 JobSet 对象优化性能；多集群层用 Karmada 支撑在线任务联邦调度，自研轻量系统解决离线高吞吐需求。结合 GPU 共享调度、编解码混合等三种模式，在提升资源利用率的同时，为 B 站 AI 应用落地提供了高效的云原生算力支撑。▍Volcano 助力科大讯飞实现AI基础设施突破，赢得 CNCF 最终用户案例会上，华为云云原生团队高级工程师常旭征联合科大讯飞平台架构师董江，发表 “Scaling Model Training with Volcano: iFlytek's Kubernetes Breakthrough” Keynote主题演讲，分享基于 Volcano 的云原生 AI 训练资源调度优化方案。科大讯飞在大规模模型训练中借助 Volcano 实现关键突破：通过构建基于 Volcano 的统一计算平台，集成 AirFlow / Spark 等传统任务框架，以队列机制解决多租户资源公平分配问题，同时运用 Gang 调度、Binpack 算法及拓扑感知策略，将 GPU 利用率提升 40% 以上，故障恢复时间缩短 70%，资源干扰率降低 50%，保障业务稳定性和资源使用灵活性。Volcano 是华为云发起开源的业界首个云原生批量计算引擎，也是 CNCF 首个批量计算项目，主要用于 AI、大数据、基因、渲染等诸多高性能计算场景，能力涵盖队列与资源管理、统一作业 API、多样化调度策略、在离线混部、GPU 虚拟化、异构算力支持及性能优化等关键领域。针对当前大规模AI集群的性能问题，Volcano 新增基于 HyperNode 的网络拓扑感知调度策略，大幅提升人工智能训练和推理效率。  Cloud Native for AI，云原生使能大规模人工智能产业发展  ▍Karmada：破解AI任务部署多集群编排难题，支撑大规模数据平台的弹性与可靠性Karmada 作为云原生多云多集群管理引擎备受用户与开发者欢迎。来自华为云的Karmada 社区 Maintainer 任洪彩，围绕 Karmada 的技术更新、核心特性、实际应用案例及社区生态展开，讲解了近期版本中备受关注的应用跨集群滚动更新，有状态应用故障迁移，优先级调度机制，Dashboard，联邦资源配额等特性。同时，华为云技术团队也与 Bloomberg 进行了社区合作交流。 Bloomberg 分享了其利用 Karmada 构建弹性数据分析平台的实践经验，展示了 Karmada 在多集群管理场景下的优势性能。通过功能迭代和生态扩展，Karmada 解决了企业在跨集群管理中的核心挑战，Bloomberg 等企业的实践证明，Karmada 能够有效支撑大规模数据平台的弹性与可靠性需求，未来在 AI 训练、边缘计算等场景的拓展值得期待。▍KubeEdge 赋能多领域、多场景边云协同AI智算来自华为云云原生团队的KubeEdge社区Maintainer鲍玥，携手社区伙伴，带来4场云原生边缘计算技术演讲，议题涵盖KubeEdge大规模实现、落地案例分享以及社区治理工作等多个方向。在 “KubeEdge 社区新特性解读及多元场景案例” 、“使用混沌工程构建超大规模云原生边缘系统” 、“KubeEdge 深度探索：架构、用例和项目毕业动态” 系列议题中，KubeEdge分享了社区在智慧物流、机器人编排等领域的行业案例，介绍了项目在边缘场景中发挥的统一化管理、边缘自愈、实时性等优势，同时也带来了社区最新的新特性，包括支持批量边缘节点管理，全新DashBoard，子项目Sedna支持HPA等，以及在支持大规模场景的探索实践。作为 CNCF 首个云原生边缘计算毕业级项目，KubeEdge 的毕业旅程备受关注，在“ KubeEdge毕业探索：从零开始构建多元化、协作型开源社区”圆桌中，KubeEdge TSC 等技术专家， 共同向参会者分享总结了 KubeEdge 在社区发展与毕业历程中所做的工作，从技术成熟度、采用率、社区多样化、中立性等多个角度探讨社区健康发展的关键要素，并对 KubeEdge 毕业后的工作进行了规划与展望。▍Kmesh:内核级流量治理引擎, 高效应对大规模流量应用需求Kmesh 是集高性能、低开销及安全可靠于一身的内核级云原生流量治理引擎。本次大会上，来自华为云的 Kmesh 社区技术专家徐中虎一行，在 4 场议题演讲中分享，涵盖 Service Mesh 高性能、低底噪、安全性，易用性方面的探讨。本着轻量、易用、应用无侵入的设计原则，Kmesh 使用 eBPF 将 Service Mesh 彻底革命，推出业界极具竞争力的 Sidecarless 方案，在性能和可靠性上遥遥领先于业界相关竞品。Kmesh 从高性能、低开销技术愿景出发，借助 kfunc，内核原生模式将流量治理能力完全下沉到 Kernel Space。同时，为解决 Service Mesh 重启升级影响用户业务稳定性的问题，Kmesh 用 eBPF prog 和 BPF Map 与 Kmesh Daemon 运行进程分离的方式，实现重启升级不影响业务已有连接，减了 Service Mesh 对业务稳定性的影响。Kmesh 创新性地利用 Linux 内核的 XDP 技术，在网络包进入内核协议栈之前就进行快速处理，极大地降低了时延，提高了吞吐，克服了在处理大规模流量时，用户态鉴权存在的瓶颈，实现了服务间极致的鉴权性能。▍openGemini：高性能时序数据库，降低企业业务成本openGemini 是一款高性能时序数据库，主要面向物联网，车联网和运维监控等场景，为用户提供海量时序数据的高效存储和查询。openGemini 目前已经在能源、电力、航空航天、devops、物联网、车联网、矿山、大宗物流等 9 大领域应用落地。本届 KubeCon China，openGemini 正式以 CNCF Sandbox 项目的身份参与。会上，来自华为云的 openGemini 社区 Maintainer 向宇，向与会者在介绍了openGemini 技术特性与未来规划，并重点介绍了数据多副本及流式计算两个重要新特性，多副本可满足多数业务对数据可靠性的需求，同时社区将流式计算融入内核，简化业务架构，降低业务成本。   智能驱动的新一代AI-Native云原生基础设施   云原生已迈入全面智能化的新阶段，华为云通过AI重构云原生，打造更适合AI应用的基础设施，为用户带来全新的智能化使用体验。在华为云展区，讲解专家向与会者展示了AI-Native的云原生基础设施，包括 UCS，CCI，CCE Autopilot，CCE Turbo 等多个行业级云原生代表产品，并介绍在 KubeEdge、Volcano、Karmada、Kuasar、openGemini、Kmesh 等业界首创开源项目中的技术创新成果。作为云原生与 AI 领域的先驱者，华为云凭借多年来的产业实践和技术创新，连续8次蝉联中国容器软件市场份额第一，Omdia 评价产品战略与执行全球第一，打造业界领先的云原生解决方案，为企业数智化转型提供强大动力。开源生态加速 AI 时代技术革新，驱动行业智能化跃迁。从 Cloud Native 到 AI Native，技术创新助力产业可持续发展，我们期待与您共建繁荣云原生生态，携手全球企业与开发者，共赢产业智能未来。更多云原生技术动向关注容器魔方【更多华为云云原生干货推荐】华为云云原生王者之路集训营华为云云原生王者之路集训营为帮助广大技术爱好者快速掌握云原生相关技能，华为云云原生团队与华为云学院联合CNCF开源软件大学启动人才培养计划，推出《华为云云原生王者之路集训营》，从云原生基础知识介绍到最佳实践讲解、底层原理和方案架构深度剖析，层层深入，满足不同云原生技术基础和学习目标人群的需求。本课程还精选数十个企业典型应用场景，作为学员上机实践案例，帮助学员将所学技术快速与企业业务相结合，服务于企业生产。点击免费参加华为云云原生王者之路集训营：cid:link_3 学习后记得小试牛刀，看看测评效果~ 华为云云原生王者之路-黄金课程测评 华为云云原生王者之路-钻石课程测评 华为云云原生王者之路-王者课程测评

随着AI大模型技术的快速发展，企业对计算资源利用效率和应用性能的要求日益提高。在AI、大数据及高性能计算（HPC）等复杂应用场景下，如何高效利用GPU等异构加速器、保障系统高可用性并精细化管理资源，是Volcano社区[1]持续探索和创新的核心方向。Volcano[2]  的每一次版本迭代，都是对这些挑战的积极回应。在来自全球30余个国家、超过1000名开发者、近40000次贡献的共同建设下，Volcano已在国内外60多家企业的生产环境中得到应用，其调度性能与资源管理能力在实践中获得了广泛认可。Volcano社区现已正式发布 v1.12 版本[3] ，新版本聚焦于AI与大数据等前沿场景的核心需求，带来了一系列关键特性与体验优化：新版本亮点一览网络拓扑感知调度 (Alpha): 优化大规模AI训练与推理任务部署，通过感知网络拓扑减少跨交换机通信，提升运行效率。GPU虚拟化方案增强: 在原有vCUDA方案基础上，新增对NVIDIA GPU动态MIG切分的支持，为用户提供软件与硬件两种虚拟化选择，实现更灵活、高效的GPU资源共享。DRA支持: 增强异构资源管理的灵活性与能力。Volcano Global支持队列容量管理: 在多集群环境下，支持对租户队列的资源配额（capability）进行统一限制和管理。安全性全面增强: 从API访问控制到容器运行时权限，实施多维度安全加固，提升系统稳健性。大规模场景性能优化: 通过减少不必要的Webhook调用等手段，有效提升高并发任务处理效率。增强通用工作负载的Gang调度控制: 现已支持通过Annotation为Deployment、StatefulSet等通用工作负载自定义Gang调度所需的最小成员数（minAvailable），提供了更精细的Gang Scheduling调度策略。Job Flow功能增强: 提升了内置工作流编排引擎的健壮性与可观测性。以及更多稳定性与易用性改进。我们相信，v1.12版本的这些更新将进一步提升任务调度的智能化水平、资源利用效率和系统的整体性能，帮助用户更好地应对AI和大数据时代的挑战。  核心功能详解  ▍网络拓扑感知调度 (Alpha Release)Volcano 的网络拓扑感知调度功能，在 v1.11 中作为预览版发布后，现已在 v1.12 中达到 Alpha 发布状态。此功能旨在优化大规模训练和推理场景（如模型并行训练、Leader-Worker 推理）中 AI 任务的部署。它通过将任务调度到同一网络拓扑性能域内，减少跨交换机通信，从而显著提升任务效率。Volcano 使用 HyperNode CRD 来抽象和表示异构硬件网络拓扑，并支持层级结构以方便管理。v1.12 版本集成了以下关键特性：HyperNode 自动发现 (HyperNode Auto-Discovery)： Volcano 提供了集群网络拓扑的自动发现能力。用户可配置发现类型，系统将自动创建和维护反映集群真实网络拓扑的层级 HyperNode。目前支持 InfiniBand (IB) 网络下通过 UFM (Unified Fabric Manager) 接口获取网络拓扑信息，并自动更新 HyperNode。未来计划支持 RoCE 等更多网络协议。 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 匹配节点。相关参考文档：网络拓扑感知调度介绍与使用[4]网络拓扑感知调度设计文档[5]网络拓扑自动发现设计文档[6]网络拓扑自动发现使用文档[7]Related PRs: https://github.com/volcano-sh/volcano/pull/3874, https://github.com/volcano-sh/volcano/pull/3894, https://github.com/volcano-sh/volcano/pull/3969, https://github.com/volcano-sh/volcano/pull/3971, https://github.com/volcano-sh/volcano/pull/4068, https://github.com/volcano-sh/volcano/pull/4213, https://github.com/volcano-sh/volcano/pull/3897, https://github.com/volcano-sh/volcano/pull/3887由衷感谢社区开发者: @ecosysbin, @weapons97, @Xu-Wentao, @penggu，@JesseStutler, @Monokaix对该特性的贡献！▍GPU 虚拟化支持动态 MIG 切分Volcano 提供的 GPU 虚拟化功能支持按显存和算力申请部分 GPU 资源，通过与 Device Plugin 配合实现硬件隔离，从而提升 GPU 利用率。传统 GPU 虚拟化通过拦截 CUDA API 方式限制 GPU 使用。NVIDIA Ampere 架构引入的 MIG (Multi-Instance GPU) 技术允许将单个物理 GPU 划分为多个独立实例。然而，通用 MIG 方案通常预先固定实例大小，存在资源浪费和灵活性不足的问题。Volcano v1.12 提供了动态 MIG 切分与调度能力，可根据用户申请的 GPU 用量实时选择合适的 MIG 实例大小，并使用 Best-Fit 算法减少资源浪费。同时支持 BinPack 和 Spread 等 GPU 打分策略，以减少资源碎片并提升 GPU 利用率。用户可使用统一的 volcano.sh/vgpu-number、volcano.sh/vgpu-cores、volcano.sh/vgpu-memory API 申请资源，无需关注底层实现。设计文档：Dynamic MIG 设计文档[8]使用文档：Dynamic MIG 使用文档[9]Related PRs: https://github.com/volcano-sh/volcano/pull/4290, https://github.com/volcano-sh/volcano/pull/3953由衷感谢社区开发者: @sailorvii, @archlitchi 对该特性的贡献！▍支持 DRA (Dynamic Resource Allocation)Kubernetes DRA (Dynamic Resource Allocation，动态资源分配) 是一项内置的 Kubernetes 功能，旨在提供一种更灵活、更强大的方式来管理集群中的异构硬件资源，例如 GPU、FPGA、高性能网卡等。它解决了传统设备插件 (Device Plugin) 在某些高级场景下的局限性。Volcano v1.12 增加了对 DRA 的支持，允许集群动态分配和管理外部资源，增强了 Volcano 与 Kubernetes 生态系统的集成能力及资源管理的灵活性。使用文档：在Volcano中启用DRA[10]Related PR: https://github.com/volcano-sh/volcano/pull/3799由衷感谢社区开发者: @JesseStutler 对该特性的贡献！▍Volcano Global 支持队列容量管理队列是 Volcano 的核心概念。为支持多集群和多租户场景下的租户配额管理，Volcano 在 v1.12 中扩展了其全局队列容量管理能力。现在，用户可以在多集群环境中统一限制租户的资源使用，其配置方式与单集群场景一致：通过在队列配置中设置 capability 字段来限制租户配额。Related PR: https://github.com/volcano-sh/volcano-global/pull/16由衷感谢社区开发者: @tanberBro 对该特性的贡献！▍安全性增强Volcano 社区持续关注安全性。在 v1.12 中，除了对 ClusterRole 等敏感权限的精细控制外，还修复了以下潜在安全风险并进行了加固：HTTP Server 设置超时时间： Volcano 各组件的 Metric 和 Healthz 端点均已设置服务器端的 ReadHeader、Read、Write 超时，避免资源长时间占用。(PR: https://github.com/volcano-sh/volcano/pull/4208)跳过 SSL 证书验证时增加警告日志： 当客户端请求设置insecureSkipVerify为 true时，添加警告日志，建议生产环境启用 SSL 证书验证。(PR: https://github.com/volcano-sh/volcano/pull/4211)默认关闭 Volcano Scheduler 的 pprof 端点： 为避免敏感程序信息泄露，默认关闭用于定位问题的 Profiling 数据端口。(PR: https://github.com/volcano-sh/volcano/pull/4173)移除不必要的文件权限： 移除 Go 源文件不必要的执行权限，保持文件最小权限。(PR: https://github.com/volcano-sh/volcano/pull/4171)为容器设置 Security Context 并以非 Root 权限运行： 所有 Volcano 组件均以非 Root 权限运行，并增加了 seccompProfile, SELinuxOptions，设置 allowPrivilegeEscalation避免容器提权，同时仅保留必要的 Linux Capabilities，全面限制容器权限。(PR: https://github.com/volcano-sh/volcano/pull/4207)限制 HTTP 请求返回体大小： 针对 Extender Plugin 和 Elastic Search Service 发送的 HTTP 请求，限制其返回体大小，避免资源过度消耗导致的 OOM 等问题。(披露地址: https://github.com/volcano-sh/volcano/security/advisories/GHSA-hg79-fw4p-25p8)▍大规模场景性能提升Volcano 持续优化性能。新版本在不影响功能的前提下，默认移除和关闭了部分非必要的 Webhook，提升了大规模批创建场景下的性能：默认关闭 PodGroup 的 Mutating Webhook： 在创建 PodGroup 未指定队列时，可从 Namespace 读取进行填充。由于该场景不常见，故默认关闭此 Webhook。用户可按需开启。任务提交时的队列状态校验从 Pod 迁移到 PodGroup： 当队列处于关闭状态时，不允许提交任务。原校验逻辑在创建 Pod 时进行，而 Volcano 的调度基本单位是 PodGroup，将校验迁移至 PodGroup 创建时更为合理。因 PodGroup 数量少于 Pod，此举可减少 Webhook 调用，提升性能。Related PRs: https://github.com/volcano-sh/volcano/pull/4128, https://github.com/volcano-sh/volcano/pull/4132由衷感谢社区开发者: @Monokaix 对该特性的贡献！▍多种负载类型支持 Gang 调度Gang 调度是 Volcano 的核心能力。对于 Volcano Job 和 PodGroup 对象，用户可直接设置 minMember 来定义所需最小副本数。在新版本中，用户可通过在 Deployment、StatefulSet、Job 等其他类型工作负载上设置 Annotation scheduling.volcano.sh/group-min-member 来指定所需最小副本数。这意味着在使用 Volcano 调度时，要么指定数量的副本全部调度成功，要么一个也不调度，从而为多种负载类型实现了 Gang 调度。例如，为 Deployment 设置 minMember=10：apiVersion: apps/v1 kind: Deployment metadata: name: volcano-group-deployment annotations: # Set min member=10 scheduling.volcano.sh/group-min-member: "10"Related PR: https://github.com/volcano-sh/volcano/pull/4000由衷感谢社区开发者: @sceneryback  对该特性的贡献！▍Job Flow 功能增强Job Flow 是 Volcano 提供的轻量级 Volcano Job 工作流编排框架。在 v1.12 版本中，Job Flow 进行了以下增强：新增监控指标： 增加了对成功和失败的 Job Flow 数量的度量支持。DAG 合法性校验： 引入了对 Job Flow DAG (有向无环图) 结构进行合法性校验的功能。状态同步问题修复： 解决了 Job Flow 状态同步不准确的问题。Related PRs: https://github.com/volcano-sh/volcano/pull/4169, https://github.com/volcano-sh/volcano/pull/4090, https://github.com/volcano-sh/volcano/pull/4135, https://github.com/volcano-sh/volcano/pull/4169由衷感谢社区开发者: @dongjiang1989 对该特性的贡献！▍多租户场景下更细粒度的权限控制Volcano 原生支持多租户环境，并重视多租户场景下的权限控制。在新版本中，Volcano 增强了对 Volcano Job 的权限控制，增加了只读和读写的 ClusterRole，用户可根据需要为不同租户分配不同的读写权限，以实现权限隔离。Related PR: https://github.com/volcano-sh/volcano/pull/4174由衷感谢社区开发者: @Hcryw 对该特性的贡献！▍支持 Kubernetes 1.32Volcano 版本紧随 Kubernetes 社区版本。v1.12 支持最新的 Kubernetes v1.32 版本，并通过完整的 UT 和 E2E 测试用例确保功能和可靠性。如需参与 Volcano 对新 Kubernetes 版本的适配工作，请参考：adapt-k8s-todo[11]。Related PR: https://github.com/volcano-sh/volcano/pull/4099由衷感谢社区开发者: @guoqinwill, @danish9039 对该特性的贡献！▍队列监控指标增强Volcano 队列新增了多项关键资源度量指标。现在支持对 CPU、Memory 及扩展资源的请求量 (request)、已分配量 (allocated)、应得量 (deserved)、容量 (capacity) 和 实际容量 (real_capacity) 等指标进行监控与可视化，提供队列关键资源状态的详细视图。Related PR: https://github.com/volcano-sh/volcano/pull/3937由衷感谢社区开发者:  @zedongh 对该特性的贡献！▍支持模糊测试模糊测试 (Fuzz Testing) 是一种自动化软件测试技术。Volcano 在新版本中引入了模糊测试框架，对关键函数单元进行了模糊测试，并使用 Google 开源的 OSS-Fuzz 模糊测试框架进行持续测试，旨在提前发现潜在漏洞和缺陷，增强 Volcano 的安全性和健壮性。Related PR: https://github.com/volcano-sh/volcano/pull/4205由衷感谢社区开发者: @AdamKorcz 对该特性的贡献！▍稳定性增强新版本中修复了多项稳定性问题，包括队列容量设置不合理导致的 Panic、层级队列校验失败、PodGroup 无意义刷新以及 StatefulSet 副本为0时仍占用队列资源等问题，进一步提升了系统在复杂场景下的稳定运行能力。Related PRs:https://github.com/volcano-sh/volcano/pull/4273, https://github.com/volcano-sh/volcano/pull/4272, https://github.com/volcano-sh/volcano/pull/4179, https://github.com/volcano-sh/volcano/pull/4141, https://github.com/volcano-sh/volcano/pull/4033, https://github.com/volcano-sh/volcano/pull/4012, https://github.com/volcano-sh/volcano/pull/3603由衷感谢社区开发者: @halcyon-r,  @guoqinwill, @JackyTYang, @JesseStutler, @zhutong196, @Wang-Kai, @HalfBuddhist 的贡献！  升级前注意事项  在升级到 Volcano v1.12 之前，请注意以下改动：PodGroup Mutating Webhook 默认关闭： 在 v1.12 中，PodGroup 的 Mutating Webhook 默认处于关闭状态。若您有依赖此行为（创建 PodGroup 未指定队列时从 Namespace 填充）的特定工作流，请确保在升级后手动开启此 Webhook。队列状态校验迁移及行为变更： 任务提交时的队列状态校验逻辑已从 Pod 创建阶段迁移到 PodGroup 创建阶段。当队列处于关闭状态时，系统将在 PodGroup 创建时即阻止任务提交。然而，如果在队列关闭后继续向该队列提交独立的 Pod（非通过 PodGroup 提交），这些 Pod 可以提交成功，但 Volcano Scheduler 将不会对其进行调度。Volcano Scheduler pprof 端点默认禁用： 出于安全增强考虑，Volcano Scheduler 的 pprof 端点在此版本中默认禁用。如需使用，可通过 Helm 参数 custom.scheduler_pprof_enable=true 或命令行参数 --enable-pprof=true 显式启用。  总结与展望  Volcano v1.12 版本的发布，得益于社区贡献者和用户的共同努力。此版本在 AI 任务调度、GPU 资源利用率、异构资源管理、安全性以及大规模场景下的性能与稳定性等多个方面进行了增强。v1.12 版本旨在提升用户在云原生环境中运行 AI、大数据等批量计算任务的性能和效率。我们建议用户升级并体验新版本，并欢迎通过社区渠道提供使用反馈与改进建议。未来，Volcano 社区将继续关注 CNAI 和大数据等领域的核心需求，持续进行迭代。  未来展望与需求征集  Volcano 社区始终致力于构建更加强大、灵活和易用的批量计算平台，并积极响应快速发展的技术趋势与用户需求。在接下来的版本迭代中，我们计划重点投入以下方向：深化网络拓扑感知调度能力：在v1.12 Alpha版本的基础上，我们将持续演进网络拓扑感知能力。重点包括提供对RoCE网络的自动发现支持、节点标签的智能识别与利用，并向更细粒度的任务级（Task-level）拓扑感知调度迈进。同时，我们也将积极探索和实现更多高级调度特性，以应对复杂AI训练等场景的极致性能需求。相关issue:HyperNode based binpack scheduling policy needed[12]Support task level network topology constrain[13]Support identifying network topology from node labels and converted into hyperNode resources[14]Network-topology-aware scheduling optimization: node reordering for tasks[15]引入高级资源管理机制：重点开发和完善作业重调度（Rescheduling）与资源预留（Resource Reservation）功能。这将有助于更灵活地应对集群动态负载变化，保障关键任务的资源确定性，并进一步提升整体集群的资源利用效率。相关issue:GPU fragmentation across nodes and Job/Pod rescheduling strategy request[16]增强队列调度灵活性：提供队列级别的调度策略（Queue-level Scheduling Policy）精细化配置能力。用户将能根据不同业务队列的特性、优先级和SLA需求，更灵活地定制其调度行为和资源分配策略。相关issue：volcano supports queue-level scheduling policies[17]深化生态协同与集成：我们将积极推进与Kubernetes上游社区及其他云原生项目的协作。例如，推动LWS（Leader Worker Set）与Volcano的集成，以便更好地为分布式应用提供Gang Scheduling能力。相关issue：Support custom scheulder to enable gang scheduling[18]我们热忱欢迎更多优秀的开源项目与Volcano携手，共同构建和繁荣云原生批量计算生态。拓展异构硬件支持与合作：加强与硬件生态伙伴的合作，如昇腾（Ascend）的Device Plugin和DRA Driver的适配与优化，以及与主流GPU厂商在DRA Driver上的协作，确保Volcano能高效、稳定地调度和管理各类前沿异构加速器资源。JobFlow工作流能力提升：持续优化Volcano内置的轻量级工作流引擎JobFlow。计划增强其在复杂作业依赖管理、状态监控、错误处理及用户自定义扩展等方面的能力，为用户提供更强大、更易用的工作流编排解决方案。相关issue：Support JobFlowTemplate CRD[19]Enhance JobFlow Functionality[20]引入Volcano调度模拟器，提升调度透明度与可测试性：为提升调度过程的透明度并简化测试验证，Volcano计划引入调度模拟器。这一工具将允许用户在轻量级环境中，通过灵活配置模拟集群状态（节点、Pod、队列配置等），精准复现Volcano核心调度流程——从队列选择、节点过滤与打分到最终绑定。通过输出详尽的调度日志及可选的性能分析，模拟器将极大地便利开发者测试新特性，帮助用户深入理解和验证Volcano在不同场景下的调度行为，并高效评估各类调度策略的实际影响。相关issue：Implement Volcano Scheduler Simulator[21]     社区参与  以上 Roadmap 为社区的初步规划。我们欢迎开发者和用户通过以下渠道参与讨论，为 Volcano 的发展贡献新的想法和建议。GitHub Issues: 在 Volcano GitHub 仓库中创建 kind/feature 类型的 Issue，详细说明您的使用场景和功能期望。社区交流: 参与社区会议，或在微信交流群/Slack 频道及邮件列表中发起讨论，与开发者和社区成员进行交流。Roadmap 共建: 针对我们提出的 Roadmap 或您认为重要的其他特性，欢迎随时提出建议。  致谢贡献者  Volcano v1.12 版本包含了来自46位社区贡献者的上百次代码提交，在此对各位贡献者表示由衷的感谢，贡献者GitHub ID：参考资料[1] Volcano Website: https://volcano.sh[2] Volcano GitHub: https://github.com/volcano-sh/volcano[3] Volcano社区正式发布 v1.12 版本: https://github.com/volcano-sh/volcano/releases/tag/v1.12.0[4] 网络拓扑感知调度介绍与使用: https://volcano.sh/en/docs/network_topology_aware_scheduling/[5] 网络拓扑感知调度设计文档: https://github.com/volcano-sh/volcano/blob/master/docs/design/Network%20Topology%20Aware%20Scheduling.md[6] 网络拓扑自动发现设计文档: https://github.com/volcano-sh/volcano/blob/master/docs/design/hyperNode-auto-discovery.md[7] 网络拓扑自动发现使用文档: https://github.com/volcano-sh/volcano/blob/master/docs/user-guide/how_to_use_hypernode_auto_discovery.md[8] Dynamic MIG 设计文档: https://github.com/volcano-sh/volcano/blob/master/docs/design/dynamic-mig.md[9] Dynamic MIG 使用文档: https://volcano.sh/zh/docs/gpu_virtualization/[10] 在Volcano中启用DRA: https://volcano.sh/zh/docs/unified_scheduling/#2-1-2-%E5%9C%A8volcano%E4%B8%AD%E5%90%AF%E7%94%A8dra-dynamic-resource-allocation[11] adapt-k8s-todo: https://github.com/volcano-sh/volcano/pull/4318[12] HyperNode based binpack scheduling policy needed: https://github.com/volcano-sh/volcano/issues/4331[13] Support task level network topology constrain: https://github.com/volcano-sh/volcano/issues/4188[14] Support identifying network topology from node labels and converted into hyperNode resources: https://github.com/volcano-sh/volcano/issues/4145[15] Network-topology-aware scheduling optimization: node reordering for tasks: https://github.com/volcano-sh/volcano/issues/4233[16] GPU fragmentation across nodes and Job/Pod rescheduling strategy request: https://github.com/volcano-sh/volcano/issues/3948[17] volcano supports queue-level scheduling policies: https://github.com/volcano-sh/volcano/issues/3992[18] Support custom scheulder to enable gang scheduling: https://github.com/kubernetes-sigs/lws/issues/407[19] Support JobFlowTemplate CRD: https://github.com/volcano-sh/volcano/issues/4098[20] Enhance JobFlow Functionality: https://github.com/volcano-sh/volcano/issues/4275[21] Implement Volcano Scheduler Simulator: https://github.com/volcano-sh/volcano/issues/4276Volcano 是业界首个云原生批量计算引擎，也是 CNCF 首个和唯一的批量计算项目。项目主要用于 AI、大数据、基因、渲染等诸多高性能计算场景，对主流通用计算框架均有很好的支持。目前，Volcano在人工智能、大数据、基因测序等海量数据计算和分析场景已得到快速应用，已完成对 Spark、Flink、Ray、 Tensorflow、PyTorch、Argo、MindSpore、Paddlepaddle 、Kubeflow、MPI、Horovod、Mxnet、KubeGene 等众多主流计算框架的支持，并构建起完善的上下游生态。Website：https://volcano.shGitHub: https://github.com/volcano-sh/volcano每周例会：https://zoom.us/j/91804791393添加社区小助手回复“Volcano”进入技术交流群

[ 中国，香港，2025年6月10日 ] 云原生计算基金会（CNCF）宣布，科大讯飞赢得 CNCF 最终用户案例研究竞赛。CNCF致力于构建可持续的云原生软件生态，科大讯飞凭借其在 Volcano 上的创新应用脱颖而出，获得本次殊荣，于6月10日至11日在香港举行的KubeCon + CloudNativeCon China 大会上，分享其大规模 AI 模型训练的成功经验。作为专注于语音和语言 AI 的中国科技公司，科大讯飞在业务快速增长过程中遇到了扩展难题。调度效率低导致 GPU 资源利用不足，工作流管理复杂，团队间资源争抢激烈，这些问题拖慢了研发进度，也给基础设施带来压力。使用 Volcano 后，科大讯飞实现了弹性调度、基于 DAG 的工作流和多租户隔离，简化了操作流程，显著提升了资源利用率。“在使用 Volcano 之前，跨团队协调大规模 GPU 集群训练就像不断‘灭火’，资源瓶颈、任务失败和复杂的训练管道调试层出不穷，”科大讯飞高级平台架构师 DongJiang 表示。“Volcano 让我们拥有更灵活的控制权，能够高效可靠地扩展 AI 训练。CNCF 对我们的认可令我们倍感荣幸，我们也很期待在 KubeCon + CloudNativeCon China 现场与更多同行分享我们的实践经验。”Volcano 是基于 Kubernetes 构建的云原生批处理系统，专为 AI/机器学习训练、大数据处理和科学计算等高性能工作负载设计。它提供先进的调度功能，如任务编排、资源公平分配和队列管理，能够高效管理大规模分布式任务。自 2020 年加入 CNCF Sandbox 项目，2022 年晋升为 Incubating 阶段项目，Volcano 已成为处理计算密集型任务的关键工具。随着 AI 需求不断增长，科大讯飞选择 Volcano 来应对训练基础设施日益复杂和庞大的挑战。工程团队需要更高效的资源分配方案，管理多阶段复杂训练工作流，减少任务中断，并保障不同团队的公平资源使用。借助 Volcano，他们实现了：GPU 利用率提升 40%，显著降低基础设施成本和计算资源闲置。任务失败恢复速度提升 70%，确保训练过程不中断。超参数搜索加速 50%，推动更快的迭代和创新。CNCF 首席技术官 Chris Aniszczyk 表示：“科大讯飞的案例展示了开源技术如何解决复杂且关键的规模化挑战。通过 Volcano 提升 GPU 效率和优化训练工作流，他们降低了成本，加快了开发，并在 Kubernetes 平台上构建了更可靠的 AI 基础设施，这对所有致力于 AI 领先的组织都至关重要。”随着 AI 工作负载变得更加复杂和资源密集，科大讯飞的实践证明，Volcano 等云原生工具能够帮助团队简化运营、提升扩展能力。其在 KubeCon + CloudNativeCon China 的分享，带来如何在 Kubernetes 环境下更有效管理分布式训练的实用经验，参考Keynote议题：https://kccncchn2025.sched.com/event/23EWS?iframe=no本文转载自CNCFVolcano 是业界首个云原生批量计算引擎，也是 CNCF 首个和唯一的批量计算项目。项目主要用于 AI、大数据、基因、渲染等诸多高性能计算场景，对主流通用计算框架均有很好的支持。目前，Volcano在人工智能、大数据、基因测序等海量数据计算和分析场景已得到快速应用，已完成对 Spark、Flink、Ray、 Tensorflow、PyTorch、Argo、MindSpore、Paddlepaddle 、Kubeflow、MPI、Horovod、Mxnet、KubeGene 等众多主流计算框架的支持，并构建起完善的上下游生态。Website：https://volcano.shGitHub: https://github.com/volcano-sh/volcano每周例会：https://zoom.us/j/91804791393添加社区小助手回复“Volcano”进入技术交流群

告别传统终端的“负重前行”，拥抱云端工作的“轻盈自在”！ HDC.2025 CloudDevice未来算力嘉年华CloudDevice@云手机体验官招募启动啦！限时领取云手机一个月体验特权！👉  CloudDevice体验官领取方式1、扫描文末CloudDevice云手机体验二维码，立领云手机VIP体验权（1个月）2、参与反馈活动抽奖，更有机会获得CloudDevice“下一代终端优先体验权”、至尊云手机VIP体验(6个月)及其他精美小礼物等!🚀技术亮点端云协同技术：超竞品时延降低，操作丝滑媲美本地设备跨端自由流转：手机、电脑、PC多端协同，算力随需调用安全加密：独立空间隔离数据，隐私与性能双重保障诚邀您体验华为云aPaaS新一代云终端产品—CloudDevice，共同开启终端管理的崭新篇章！扫码即领云手机，加入用户群参与反馈还可抽奖赢豪礼~*最终活动解释权归华为云aPaaS服务产品部所有

6 月 10 日-11 日，云原生计算基金会（CNCF）旗舰会议 KubeCon + CloudNativeCon China 2025 ，将在中国香港盛开召开。作为全球云原生与开源顶级会议，大会汇聚全球顶尖开源开发者、技术领袖、企业代表及终端用户，围绕 Kubernetes、云原生架构、人工智能及开源生态展开深入交流与分享，为参与者呈现一场前沿技术的学习与交流盛宴。KubeEdge云原生边缘计算社区即将亮相 KubeCon + CloudNativeCon China 2025。KubeEdge是业界首个云原生边缘计算框架、CNCF唯一毕业级边缘计算开源项目。KubeEdge 连接云原生和边缘计算生态，聚焦于提供一致的云边资源协同、数据协同、智能协同和应用协同体验，为边缘计算领域的应用提供更好的支持和解决方案，在全球已拥有1800+贡献者和120+贡献组织，在 GitHub 获得 8.1k+Stars 和 2.3k+Forks。  KubeEdge 议题看点  本届大会上，来自华为云、DaoCloud、谐云、QingCloud等KubeEdge社区技术专家，将带来多场云原生边缘计算技术演讲、圆桌讨论，与全球开发者与企业，畅聊云原生边缘计算技术创新与应用，赋能多领域、多场景边云协同AI智算，敬请期待！▍KubeEdge Updates and Use Cases in Multiple Scenarios演讲嘉宾：Yue Bao, Huawei Cloud时间：Tuesday June 10, 2025 11:49 - 11:54 HKT会场：Level 16 | Grand Ballroom I技术看点： KubeEdge是业界首个云原生开源边缘计算项目，已于去年实现CNCF毕业。在本次会议中，我们将分享毕业以来社区治理的新特性和进展。KubeEdge 已广泛应用于智能交通、智慧城市、智慧园区、智慧能源、智慧工厂、智慧银行、智慧站点、CDN等行业，为用户提供一体化的边缘云端协同解决方案。本次演讲还将分享10+个KubeEdge在各行业的用户案例，帮助用户了解云原生边缘计算和边缘AI的实践经验。议程链接：https://sched.co/1xjzK▍Building Ultra-Large-Scale Cloud Native Edge Systems Using Chaos Engineering演讲嘉宾：Yue Bao, Huawei Cloud & Yue Li, DaoCloud时间：Tuesday June 10, 2025 13:45 - 14:15 HKT会场：Level 19 | Crystal Court II技术看点： 5G网络、工业互联网和人工智能等技术的快速发展，使边缘计算在推动数字化转型中发挥了重要作用。每项新技术在带来好处的同时，也带来了挑战。首先，大量异构边缘设备的出现，包含了广泛的设备类型。其次，边缘设备往往处于不稳定和复杂的物理和网络环境中，例如带宽受限、高延迟等，如何克服这些挑战，构建稳定、大规模的边缘计算平台是需要解决的问题。KubeEdge是一个开源的边缘计算框架，它将Kubernetes的功能从中心云扩展到边缘。现在，由KubeEdge提供支持的Kubernetes集群可以稳定支持10万个边缘节点，管理超过100万个Pod。在本次分享中，我们将分享大规模异构边缘节点管理中的关键挑战，并讲述如何在大规模边缘节点中使用ChaosMesh使KubeEdge更可靠。议程链接：https://sched.co/1x5hu▍KubeEdge DeepDive: Architecture, Use Cases, and Project Graduation Updates演讲嘉宾：Yue Bao, Huawei Cloud & Hongbing Zhang, DaoCloud时间：Wednesday June 11, 2025 11:45 - 12:15 HKT会场：Level 21 | Pearl Pavilion技术看点： 在本次分享中，KubeEdge项目维护者将概述KubeEdge的架构及其特定于行业的用例。议题首先简要介绍边缘计算及其在物联网和分布式系统中日益增长的重要性。然后，维护者将深入探讨KubeEdge的核心组件和架构，展示它如何扩展Kubernetes的功能以高效地管理边缘计算工作负载。他们将分享已在各种边缘环境（如智慧城市、工业物联网、边缘AI、机器人和零售）中部署KubeEdge的组织的成功案例和见解，强调切实的好处和变革的可能性。此外，会议还将介绍认证的KubeEdge一致性测试、硬件测试、KubeEdge课程和认证，讨论KubeEdge项目中的技术进步和社区治理，并分享项目毕业状态的最新更新。议程链接：https://sched.co/1x5hQ▍Exploring KubeEdge Graduation: Build a Diverse and Collaborative Open Source Community From Scratch演讲嘉宾： Yue Bao & Fei Xu, Huawei Cloud; Hongbing Zhang, DaoCloud; Huan Wei, Hangzhou HarmonyCloud; Benamin Huo, QingCloud时间：Wednesday June 11, 2025 14:30 - 15:00 HKT会场：Level 19 | Crystal Court II技术看点： 当前，开源项目的健康性，特别是供应商多样性和中立性成为讨论的一个关键话题。由于缺乏供应商多样性，许多项目面临挑战，威胁到其可持续性。越来越清楚的是，在项目成长过程中建立正确的治理结构和项目团队至关重要。在本场圆桌中，我们将讨论KubeEdge社区毕业之旅的经验教训，重点讨论技术规划、社区治理、开发者成长和项目维护方面的关键策略。欢迎参与我们的讨论，探讨如何建立一个多供应商和多样化的社区，以及如何将这份经验应用到不同的行业。议程链接：https://sched.co/1x5jw更多云原生边缘计算相关议题，欢迎关注大会官网。KubeEdge邀您共聚KubeCon + CloudNativeCon  China 2025！ 添加小助手k8s2222回复KubeEdge进群【更多KubeEdge资讯推荐】玩转KubeEdge保姆级攻略——环境搭建篇玩转KubeEdge保姆级攻略——环境搭建篇《玩转KubeEdge保姆级攻略——环境搭建篇》课程主要介绍如何通过华为云服务快速搭建一套KubeEdge边缘计算开发平台及部署Sedna、EdgeMesh等KubeEdge生态组件。课程免费学习链接：https://connect.huaweicloud.com/courses/learn/course-v1:HuaweiX+CBUCNXNX022+Self-paced/aboutKubeEdge社区介绍：KubeEdge是业界首个云原生边缘计算框架、云原生计算基金会（CNCF）唯一毕业级边缘计算开源项目，社区已完成业界最大规模云原生边云协同高速公路项目（统一管理10万边缘节点/50万边缘应用）、业界首个云原生星地协同卫星、业界首个云原生车云协同汽车、业界首个云原生油田项目，开源业界首个分布式协同AI框架Sedna及业界首个边云协同终身学习范式，并在持续开拓创新中。KubeEdge网站 :  https://kubeedge.ioGitHub地址 : cid:link_0Slack地址 : https://kubeedge.slack.com邮件列表 : https://groups.google.com/forum/#!forum/kubeedge每周社区例会 : https://zoom.us/j/4167237304Twitter : https://twitter.com/KubeEdge文档地址 : https://docs.kubeedge.io/en/latest/

6 月 10 日-11 日，由云原生计算基金会（CNCF）和 Linux 基金会联合主办的 KubeCon + CloudNativeCon China 2025 ，将在中国香港盛开召开。Kmesh技术团队将在本届KubeCon China 上带来多个精彩议题，覆盖云原生流量治理Sidecarless创新方案、流量治理认证、Kmesh行业实践等多个用户关心的技术话题，欢迎现场一聚！Kmesh（https://github.com/kmesh-net/kmesh）是集高性能、低开销及安全可靠于一身的内核级云原生流量治理框架。基于可编程内核 + eBPF实现的高性能流量治理引擎，采用Sidecarless架构，用户无需在数据面部署代理组件，即可实现服务网格场景下服务间多跳变一跳的服务访问，相比业界方案性能提升3~5倍。  KubeCon China 2025 Kmesh 议题看点  以下是Kmesh在本次大会上的精彩议题：▍Revolutionizing Sidecarless Service Mesh With eBPF演讲嘉宾：Zhonghu Xu & Muyang Tian, Huawei时间：Tuesday June 10, 2025 15:30 - 16:00 HKT会场：Level 19 | Crystal Court II技术看点： 众所周知服务网格sidecar引入了大量的资源开销，对内存和CPU利用率产生不利影响。此外，sidecars 与工作负载的紧耦合使生命周期管理变得复杂。本议题将对比Istio、Ambient和cilium的优缺点，并演示eBPF和可编程内核模块如何显著缓解这些问题。同时，本议题也将介绍几个关于采用它来提高微服务性能，同时最小化基础设施升级期间对应用程序的中断的用例。议程链接：https://sched.co/1x5iI▍Best Practices for Upgrading Service Mesh Seamlessly 演讲嘉宾：Hang Yin, Alibaba Cloud & Zhencheng Lee, Huawei 时间：Tuesday June 10, 2025 15:51 - 15:56HKT会场：Level 16 | Grand Ballroom I技术看点： Service Mesh正在蓬勃发展，新版本总是包含令人兴奋的功能和重要的CVE修复，为用户带来可观的好处。然而，由于Service Mesh升级或重启导致的服务流量中断，导致系统不稳定，仍然是Service Mesh在生产环境中使用的主要障碍。在大多数sidecar模型中，升级服务网格的数据平面会导致重新部署服务；在某些情况下，这几乎是不可接受的，因为某些业务应用程序可能会面临巨大的冷启动成本。即使对于方兴未艾的sidecarless模式，仍然需要解决中断现有用户连接的问题，这需要做出艰难的选择。本主题将从实际案例出发，由来自华为云和阿里云的技术专家将与用户分享真实生产场景下Service Mesh无缝升级的实践经验。议程链接：https://sched.co/1x5iU▍High-Performance Cloud Native Traffic Authentication Solutions 演讲嘉宾：Muyang Tian & Zengzeng Yao, Huawei时间：Wednesday June 11, 2025 16:15 - 16:45HKT会场：Level 19 | Crystal Court II技术看点： 云计算和微服务架构快速发展，高效且安全地管理服务之间的通信已成为一项关键挑战。传统的网络流量认证方法往往成为性能瓶颈，尤其是在处理大规模数据流时。本议题介绍了一个创新的解决方案——利用Linux内核技术XDP (eXpress Data Path)实现服务到服务通信的高效流量认证。我们将深入研究如何使用XDP在数据包进入系统的协议栈之前对其进行快速过滤和处理，从而显著降低延迟并提高整体系统吞吐量。此外，我们还将分享Kmesh等项目的实际应用经验，包括但不限于性能调优、安全注意事项以及与其他网络安全策略的集成。议程链接：https://sched.co/1x5kE   欢迎莅临Kmesh展位交流  Kmesh技术专家将于6月11日早上时段，与大家在CNCF Project Pavilion与大家面对面畅聊，请记得我们的展位号：P-7Kmesh 始终以开放中立的态度发展社区，持续打造 Sidecarless 服务网格业界标杆方案，服务千行百业，促进服务网格健康有序的发展。期待与您在 KubeCon + CloudNativeCon China 2025 见面，共同探讨云原生流量治理更优选择！Kmesh社区地址[1] Kmesh GitHub: https://github.com/kmesh-net/kmesh[2] Kmesh Website: https://kmesh.net/ 扫码添加社区小助手回复Kmesh进交流群【更多华为云云原生干货推荐】华为云云原生王者之路集训营华为云云原生王者之路集训营为帮助广大技术爱好者快速掌握云原生相关技能，华为云云原生团队与华为云学院联合CNCF开源软件大学启动人才培养计划，推出《华为云云原生王者之路集训营》，从云原生基础知识介绍到最佳实践讲解、底层原理和方案架构深度剖析，层层深入，满足不同云原生技术基础和学习目标人群的需求。本课程还精选数十个企业典型应用场景，作为学员上机实践案例，帮助学员将所学技术快速与企业业务相结合，服务于企业生产。点击免费参加华为云云原生王者之路集训营：cid:link_3 学习后记得小试牛刀，看看测评效果~ 华为云云原生王者之路-黄金课程测评 华为云云原生王者之路-钻石课程测评 华为云云原生王者之路-王者课程测评

6 月 10 日-11 日，由云原生计算基金会（CNCF）和 Linux 基金会联合主办的 KubeCon + CloudNativeCon China 2025 ，将在中国香港盛大召开。作为 Linux 基金会旗下云原生与开源顶级盛会，大会汇聚全球顶尖技术专家与前沿企业，共同开启这场技术盛宴。华为云一直是云原生技术创新的践行者，先后主导开源了业界首个智能边缘计算项目 KubeEdge、业界首个云原生 AI 调度引擎 Volcano、业界首个云原生多云容器编排引擎 Karmada 等多个 CNCF 项目，并持续带来了 Kuasar、Kmesh、openGemini 等项目创新。基于云原生容器技术，华为云云原生团队领先构建 AI-Native云原生基础设施，在业界首发多个云原生革命性产品，Omdia评价产品战略与执行全球第一，并连续8次蝉联中国容器软件市场份额第一，打造业界领先的云原生解决方案，为企业数智化转型提供强大动力。本次大会上，华为将带来多场主题演讲与技术分享，覆盖云原生AI 调度、智能边缘、多云容器、数据库、流量治理等领域的前沿技术与解决方案，与您共创云原生 × AI 的无限可能！更多云原生技术动向关注容器魔方【更多华为云云原生干货推荐】华为云云原生王者之路集训营华为云云原生王者之路集训营为帮助广大技术爱好者快速掌握云原生相关技能，华为云云原生团队与华为云学院联合CNCF开源软件大学启动人才培养计划，推出《华为云云原生王者之路集训营》，从云原生基础知识介绍到最佳实践讲解、底层原理和方案架构深度剖析，层层深入，满足不同云原生技术基础和学习目标人群的需求。本课程还精选数十个企业典型应用场景，作为学员上机实践案例，帮助学员将所学技术快速与企业业务相结合，服务于企业生产。点击免费参加华为云云原生王者之路集训营：cid:link_3 学习后记得小试牛刀，看看测评效果~ 华为云云原生王者之路-黄金课程测评 华为云云原生王者之路-钻石课程测评 华为云云原生王者之路-王者课程测评

2025年盛夏，让我们以代码为契，共同追问技术为何而生--在华为开发者大会的星空下,没有商业胜负的喧嚣，唯有千万行代码汇聚的纯粹答案: 让世界变得更好。HDC 2025，6月20日-22日，东莞松山湖，期待与您相见!

Karmada 社区非常高兴地宣布小红书正式加入Karmada 用户组[1]（Karmada Adopter Group），成为该开源社区的重要成员。作为云原生计算基金会（CNCF）旗下的开源项目，Karmada 致力于为用户提供强大的多集群管理和调度能力，帮助企业在复杂的分布式环境中实现高效的应用部署和管理。小红书的加入将进一步丰富 Karmada 社区的生态，并为项目的持续创新注入新的动力。   关 于 小 红 书  小红书[2]是年轻人的生活方式平台，由毛文超和瞿芳于2013年在上海创立。小红书以“Inspire Lives 分享和发现世界的精彩”为使命，用户可以通过短视频、图文等形式记录生活点滴，分享生活方式，并基于兴趣形成互动。小红书借助Karmada构建其多云 IT 基础设施，打造面向应用的统一平台入口，应对业务的飞速发展进程中的集群和资源管理挑战，提升应用跨集群分发与弹性能力，做好应用跨集群调度，实现多集群场景下的联邦自动化运维，进一步升级云原生基础架构。更详细的案例分享请参考 KubeCon China 2024 的演讲，《多集群助力小红书打造面向混合云的高可用弹性架构》：https://youtu.be/05M7bqj2VJE?si=0H7EjmBnTvjIv_ih   关于Karmada用户组  作为连接社区与用户的核心纽带，Karmada 用户组致力于打造一个深度融合、开放协作的高价值平台，推动成员间的高效联动与经验共享。通过技术支持、活动共创及最佳实践交流，Karmada 用户组将持续赋能用户在多云管理领域的能力提升，助力云原生多云多集群生态系统的蓬勃发展。其主要目标和功能包括：分享知识：促进 Karmada 用户之间的经验、挑战和解决方案交流促进协作：提供一个用户可以协作、分享想法并解决共同问题的平台支持用户：提供资源、教程和指导，帮助用户有效利用 Karmada收集反馈：倾听用户声音，以指导 Karmada 未来的发展方向社区活动组织：通过定期 meetup、网络研讨会和其他活动，增强社区参与度截至目前，Karmada 用户组已吸纳来自全球的30+家机构和组织。更多使用场景及案例研究请查阅：https://karmada.io/adopters   欢迎加入用户组   任何在生产环境中使用 Karmada 的公司，其开发者均可申请加入 Karmada 用户组。无论您是最终用户还是云厂商，我们都欢迎您的加入。最终用户：指在其内部 IT 基础设施中直接部署和使用 Karmada 进行多云或多集群管理的企业或组织。这些公司利用 Karmada 作为关键技术底座来管理和优化算力资源。供应商：指那些将 Karmada 集成到他们的产品或服务中，以提供给其他企业或组织使用的公司。加入 Karmada 用户组，您可以与面临类似挑战的同行建立联系并分享 Karmada 实践经验，一同探索多云多集群生态，包括但不限于以下内容：社区技术支持：包括且不限于方案评估、日常运维、问题定位、版本升级等社区支持公司知名度提升：您的公司和团队将获得全球范围内更多的曝光机会技术影响力构建：邀请共建技术演讲，包括 KubeCon 等海内外业界大会，Karmada 社区伙伴举办的线上、线下系列会议保持信息同步：及时接收重要信息更新，包括新版本的关键特性、重要 Bug 修复、安全风险等内容，确保您的项目能够第一时间受益于新的改进和增强。顶尖人才招募：利用社区渠道招聘宣传，全球范围内精准招募优秀人才拓展商业机会：与 Karmada 生态系统其他成员建立潜在的商业联系和合作当前，加入 Karmada 用户组对社区贡献没有硬性要求，我们鼓励成员积极参与社区活动，分享经验与见解。然而，请注意，未来可能会要求成员对 Karmada 社区做出一定的贡献，以维持其用户组成员身份。这种贡献可以包括但不限于代码提交、文档编写、问题修复、使用案例分享等。访问下方 Karmada 用户组申请表单 [3]，提交 issue 申请，即可接收申请进度。手机端可扫描下方二维码快捷填写申请表单。扫码申请加入用户组更多信息，请访问：[1] Karmada Adopter Group 详细信息，请查阅: https://github.com/karmada-io/community/tree/main/adopter-group[2] 小红书: www.xiaohongshu.com[3] Karmada Adopter Group 申请加入表单地址: https://github.com/karmada-io/community/issues/new?template=adopter-group-application.yamlKarmada Adopter Group 欢迎您的加入！期待与您共同创建一个友好而活跃的空间，共享知识、最佳实践和经验，为企业与社区发展缔造更多可能。如需了解更多关于Karmada Adopter Group的信息，请联系: Maintainer Mailing Listcncf-karmada-maintainers@lists.cncf.ioKarmada 是CNCF 首个多云多集群容器编排项目(孵化级），旨在帮助用户像使用单个集群一样轻松管理跨云多集群，让基于 Karmada 的多云方案无缝融入云原生技术生态。社区吸引了来自华为、道客、浙江大学、腾讯、中国电子云、滴滴、Zendesk、携程等100多家公司的全球贡献者，广泛分布于20+国家和地区。Karmada 现已在华为云、道客、兴业数金、中国移动、中国联通、携程、360集团、新浪、中通快递等众多企业单位生产应用，为企业提供从单集群到多云架构的平滑演进方案。添加社区小助手k8s2222回复Karmada进入技术交流群Karmada官网：https://karmada.io/项目地址：https://github.com/karmada-io/karmadaSlack地址：https://slack.cncf.io/（#karmada）

▍调研背景Kubernetes SIG-Multicluster 正在提议为 central cluster 制定一个标准化定义[1]（目前在 Karmada[2] 中称为“Host Cluster”），以统一 Karmada、OCM、clusternet、kubefleet、MCO、KubeAdmiral 等多集群管理项目之间的术语。此倡议旨在减少生态系统的碎片化，提高跨项目的互操作性。Karmada 社区[3]有可能修改当前在使用的 Concept (即 Host Cluster)，为了评估其对用户的影响，特发起了本次社区调研。您的反馈将直接影响 Karmada 与 SIG-Multicluster 提案的一致性，并指导我们的兼容性策略。▍调研目的了解是否有用户将 Karmada Concept 用于产品界面，例如API、可视化UI、产品文档等，如存在此情况请务必反馈。征集用户对术语的偏好（Host Cluster vs. Hub Cluster 等）。 ▍参与方式在 Karmada issue 137 留下您对此问题的评论，或填写在线问卷。本次调研截止日期为2025年6月10日。方式1：在 Karmada issue 137 直接评论：https://github.com/karmada-io/community/issues/137方式2：参与在线问卷，问卷地址：https://docs.google.com/forms/d/e/1FAIpQLSdsFibCZlkOo6xVCx-FlFcAwghy2YgT9DhFP4h7jrLxnn_PNA/viewform相关链接[1] standardized definition for the central cluster: https://github.com/kubernetes/community/pull/8210[2] Karmada: https://karmada.io/[3] Karmada 社区: https://github.com/karmada-io/karmada添加社区小助手k8s2222回复Karmada进入技术交流群👉Karmada 是CNCF 首个多云多集群容器编排项目(孵化级），旨在帮助用户像使用单个集群一样轻松管理跨云多集群，让基于 Karmada 的多云方案无缝融入云原生技术生态。社区吸引了来自华为、道客、浙江大学、腾讯、中国电子云、滴滴、Zendesk、携程等100多家公司的全球贡献者，广泛分布于20+国家和地区。Karmada 现已在华为云、道客、兴业数金、中国移动、中国联通、携程、360集团、新浪、中通快递等众多企业单位生产应用，为企业提供从单集群到多云架构的平滑演进方案。Karmada官网：https://karmada.io/项目地址：https://github.com/karmada-io/karmadaSlack地址：https://slack.cncf.io/（#karmada）