随着云计算进入多云时代，企业逐渐采用混合云或多云架构以提升灵活性、降低供应商依赖风险并优化成本。然而，这一趋势也带来了新的挑战——跨云平台的数据迁移。无论是将本地数据中心迁移至公有云、私有云，还是在不同公有云之间迁移，数据作为核心资产，其迁移过程直接影响业务连续性、数据完整性和安全性。本文将从技术视角出发，结合实战经验，解析跨云数据迁移的关键要素：工具选型、架构设计与避坑策略，助您构建高效、安全的迁移方案。  一、云数据迁移工具对比：如何选择最适合的工具？在跨云迁移中，工具的选择决定了迁移的效率与质量。以下是几类主流工具的对比分析，供参考：选型建议：小规模测试：优先选择轻量化工具快速验证可行性；大规模生产环境：采用组合方案（如数据库专用工具+对象存储工具）；实时同步需求：选择支持CDC技术的工具，并提前测试冲突解决机制。二、架构设计：跨云迁移的核心逻辑与关键步骤成功的跨云迁移离不开科学的架构设计。以下是分阶段实施的关键步骤：  1. 评估与规划阶段数据普查：绘制数据拓扑图，标注所有数据源（数据库、文件服务器、SaaS应用）、数据量及增长趋势；业务影响分析：明确关键业务的RTO（恢复时间目标）和RPO（恢复点目标），例如电商大促期间需保证毫秒级延迟；迁移策略制定：根据数据敏感性和实时性要求，选择“停机窗口冷迁移”“增量同步热迁移”或“双写模式”。2. 高可用性设计冗余链路：在源端和目标端部署代理节点，避免单点故障；数据校验机制：迁移前后计算文件哈希值（MD5/SHA-256）、数据库记录数比对；回滚方案：保留源端快照，并在目标端预置回滚脚本，确保紧急情况下可快速回退。3. 混合云管理架构统一监控平面：通过Prometheus/Grafana等工具监控跨云数据传输速度、错误率、资源占用；权限隔离：基于RBAC模型限制操作员权限，避免越权访问敏感数据；日志审计：记录所有迁移操作日志，满足合规性要求（如GDPR、HIPAA）。4. 性能优化策略压缩算法：使用LZ4、Zstandard等无损压缩算法减少网络传输量；并发控制：根据带宽动态调整线程数，避免拥塞；缓存机制：对频繁访问的数据块进行本地缓存，加速重复传输。三、避坑指南：跨云迁移的常见陷阱与解决方案即使拥有最佳工具和架构，仍需警惕以下潜在风险：  四、实战案例：某电商平台的跨云迁移实践背景：某电商平台因业务扩张需将部分业务从A云迁移至B云，涉及MySQL数据库（5TB）、Redis缓存（1TB）和OSS文件存储（500TB）。实施步骤：评估阶段：通过工具扫描发现大量历史订单表存在外键约束，直接迁移可能导致锁表；方案设计：采用“数据库专用工具+对象存储工具”组合，对订单表进行分片迁移，并启用CDC实时同步；测试验证：在沙箱环境中模拟大促流量，发现Redis集群因跨云延迟导致响应变慢，遂调整为本地缓存+异步同步；正式迁移：选择业务低峰期（凌晨2-4点），分三批次完成迁移，全程耗时6小时，停机时间控制在30分钟内；优化迭代：迁移后通过监控发现B云的磁盘IOPS不足，扩容后性能提升40%。五、结语：工具+架构+经验=成功迁移跨云数据迁移是一项系统工程，工具的选择仅是起点，科学的架构设计和丰富的实战经验才是成功的关键。建议企业在迁移前组建跨部门团队（IT、业务、法务），制定详细的《迁移应急预案》，并预留足够的缓冲时间应对突发状况。未来，随着AI驱动的智能迁移助手兴起，自动化程度将进一步提升，但人类专家对业务逻辑的理解始终是保障迁移质量的核心要素。希望本文能为您的跨云迁移之路提供实用参考！

数字化转型浪潮下，企业面临着公有云弹性扩展与私有云数据控制权的矛盾命题。根据Gartner预测，到2025年将有超过85%的企业采用混合云架构，其中存储系统的融合能力成为关键瓶颈。本文从技术演进视角拆解分布式混合云存储的五大主流架构，揭示不同场景下的最优解法，助您突破传统架构的性能边界与成本桎梏。  一、混合云存储的核心矛盾与设计原则当前企业面临三大核心挑战：1. 数据爆炸性增长：AI训练数据量年增3倍，传统集中式存储难以线性扩展；2. 合规与成本博弈：金融行业监管要求核心数据本地化，但互联网业务需全球低延迟访问；3. 异构工作负载：OLTP事务处理、视频流媒体、冷备份归档等不同IO特征并存。优秀的混合云存储架构应满足：无缝数据流动：支持跨云/边/端的数据迁移与同步；智能分层治理：自动匹配数据生命周期与存储介质；统一管理平面：可视化全局资源调度与策略配置；弹性计费模型：按需使用公有云资源，避免过度预置硬件。二、五大主流分布式混合云存储架构深度剖析1. 联邦式架构（Federated Architecture）技术特征逻辑统一，物理分散：通过元数据服务整合多数据中心存储池；强一致性协议：采用Raft/Paxos算法保证跨站点数据一致；智能路由引擎：基于地理围栏、SLA要求自动选择存储节点。典型场景跨国金融机构：满足各国数据驻留法规，同时提供全球统一命名空间；医疗影像平台：三级医院本地存储DICOM文件，区域中心汇总科研数据。优势与局限  2. 分层式架构（Tiered Architecture）技术特征热/温/冷三级存储：SSD→HDD→磁带库自动分级；机器学习驱动迁移：基于访问频率预测数据冷热程度；缓存预热机制：提前加载高频访问数据至边缘节点。典型场景视频直播平台：实时流媒体存SSD，历史回放转HDD，长期存档归磁带；基因组学研究：原始测序数据存高性能存储，比对结果转低成本归档。优势与局限 3. 对称式双活架构（Active-Active Architecture） 技术特征双向同步复制：主备站点均可独立承接业务流量；仲裁节点机制：引入第三个节点解决脑裂问题；动态负载均衡：根据请求来源自动分配读写流量。典型场景证券交易平台：上海/深圳数据中心互为灾备，保障交易连续性；工业互联网：工厂本地存储生产数据，云端进行大数据分析。优势与局限  4. 边缘协同架构（Edge-Coordinated Architecture）技术特征三级存储拓扑：边缘节点→区域中心→中央云；断网续传能力：网络中断时本地暂存，恢复后同步；轻量化元数据：仅同步必要目录结构，减少带宽消耗。典型场景智慧零售：门店POS机离线收银，联网后批量同步销售数据；车联网：车载终端存储行驶日志，夜间停车时上传至云端。优势与局限  5. 容器化存储网格（Containerized Storage Grid）技术特征Kubernetes CSI集成：存储卷随容器自动漂移；微服务化存储组件：对象网关、元数据服务均容器化部署；声明式API驱动：通过CRD定义存储策略与拓扑关系。典型场景DevOps流水线：构建产物自动存入临时存储，测试完成后转正式库；Serverless函数计算：临时存储中间结果，执行完毕自动清理。优势与局限  三、架构选型决策矩阵  四、未来演进趋势1. 存算分离深化：存储层专注数据管理，计算层聚焦AI推理；2. 量子安全增强：抗量子加密算法嵌入存储层，保护长期冷数据；3. 碳感知存储：根据数据中心PUE动态调整数据存放位置；4. 三维空间扩展：除地理分布外，增加芯片级/机房级冗余维度。结语分布式混合云存储的本质是“数据的精准投放”——在正确的时间、正确的地点、以正确的形式保存数据。企业应根据业务特性构建动态演进的存储体系：对于毫秒级响应的核心交易，采用双活架构；对于PB级非结构化数据，选择分层存储；对于边缘侧设备，部署协同式存储网格。唯有打破“一刀切”的架构思维，才能在数字经济时代掌握数据主权与业务创新的平衡点。

Karmada 社区非常高兴地宣布中科类脑正式加入Karmada 用户组[1]（Karmada Adopter Group），成为该开源社区的重要成员。作为云原生计算基金会（CNCF）旗下的开源项目，Karmada 致力于为用户提供强大的多集群管理和调度能力，帮助企业在复杂的分布式环境中实现高效的应用部署和管理。中科类脑的加入将进一步丰富 Karmada 社区的生态，并为项目的持续创新注入新的动力。  关 于 中 科 类 脑 合肥中科类脑智能技术有限公司[2]成立于2017年，是一家专注于类脑智能技术研发与应用的国家高新技术企业、国家级专精特新“小巨人”企业。公司在机器视觉大模型、小样本学习、因果视觉与因果推理、稳定学习、类脑博弈优化决策等多个人工智能前沿技术领域处于行业先进地位，广泛应用于算力基础设施、智慧能源和算电碳协同发展三大业务领域。中科类脑秉承“推动前沿智能技术落地，助力产业数智升级”的使命，持续推出创新的智能化产品及解决方案，力求打造垂直领域人工智能应用的深度闭环。公司致力于成为全球领先的能源智能服务企业，致力于成为全球AI生态建设者。  关于Karmada用户组  作为连接社区与用户的核心纽带，Karmada 用户组致力于打造一个深度融合、开放协作的高价值平台，推动成员间的高效联动与经验共享。通过技术支持、活动共创及最佳实践交流，Karmada 用户组将持续赋能用户在多云管理领域的能力提升，助力云原生多云多集群生态系统的蓬勃发展。其主要目标和功能包括：分享知识：促进 Karmada 用户之间的经验、挑战和解决方案交流促进协作：提供一个用户可以协作、分享想法并解决共同问题的平台支持用户：提供资源、教程和指导，帮助用户有效利用 Karmada收集反馈：倾听用户声音，以指导 Karmada 未来的发展方向社区活动组织：通过定期 meetup、网络研讨会和其他活动，增强社区参与度截至目前，Karmada 用户组已吸纳来自全球的35+家机构和组织。更多使用场景及案例研究请查阅：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] 中科类脑: http://www.leinao.ai/[3] Karmada Adopter Group 申请加入表单地址: https://github.com/karmada-io/community/issues/new?template=adopter-group-application.yaml Karmada 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进入技术交流群

在数字化转型浪潮中，企业上云已成为必然选择。但面对公有云、私有云、混合云三种主流部署模式，如何权衡成本、安全与性能，找到最适合自身业务的“划算”方案？本文将从技术架构、成本模型、安全合规、弹性扩展等核心维度展开深度解析，助你做出科学决策。 一、成本模型：短期投入vs长期收益，哪种更“省钱”？公有云：按需付费的“轻资产”模式公有云的核心优势是零前期资本支出（CapEx），企业无需自建数据中心，只需按使用量支付费用（如计算、存储、网络资源）。这种模式适合初创企业或业务波动大的场景（如电商大促、游戏峰值流量）。成本优势：弹性伸缩：通过自动扩缩容（AutoScaling）避免资源浪费。例如，某电商在“双11”期间通过公有云弹性扩容，成本比自建IDC降低60%。运维外包：云服务商负责硬件维护、电力、网络等基础设施，企业可专注核心业务。潜在成本陷阱：数据迁移费用：从公有云下载数据可能产生高额流量费。长期锁定风险：若业务稳定后未优化资源使用，公有云总拥有成本（TCO）可能超过私有云。例如，某企业因未关闭闲置的K8s节点，年浪费云费用达40%。私有云：自主可控的“重资产”投资私有云需企业自建数据中心或租赁专属机房，硬件、软件、运维全由自己管理。适合对数据安全、合规要求高的行业（如金融、医疗）。成本优势：长期成本可控：若业务稳定且数据量大，私有云TCO可能低于公有云。例如，某三甲医院通过私有云存储医疗影像，5年总成本比公有云低38%。资源利用率优化：通过虚拟化（如VMwarevSphere）或超融合架构（HCI），将服务器利用率从15%提升至60%，降低单位成本。潜在成本挑战：前期投入高：一台服务器成本约5万-20万元，加上软件授权、运维团队，初始投入可能达数百万元。技术迭代风险：硬件更新换代快，若未及时升级，可能导致性能瓶颈。混合云：平衡成本与灵活性的“中间路线”混合云结合公有云与私有云的优势，核心数据（如数据库、核心应用）放在私有云，弹性需求（如前端应用、大数据分析）放在公有云。成本优势：按需分配资源：例如，某视频平台在春晚直播时，将90%流量导向公有云，私有云仅处理后台任务，成本降低65%。避免单一供应商锁定：通过多云管理工具（如Terraform、Kubernetes），实现资源跨云调度，降低依赖风险。潜在成本复杂度：跨云网络费用：若公有云与私有云不在同一地域，数据同步可能产生高额延迟和流量费。管理成本增加：需同时掌握公有云和私有云（如OpenStack、VMware）技术，人才成本较高。二、安全与合规：数据主权与风险控制的博弈公有云：共享责任模型下的安全挑战公有云的安全遵循“云服务商管基础设施，用户管数据与应用”的共享责任模型。企业需重点关注：数据加密：使用云服务商提供的KMS（密钥管理服务）或自带密钥（BYOK），防止数据泄露。访问控制：通过IAM（身份与访问管理）限制用户权限，避免内部威胁。例如，某企业因未启用VPC私有子网，导致数据库被暴露，损失惨重。合规认证：选择通过ISO27001、SOC2等认证的云服务商，降低合规风险。私有云：自主可控的安全堡垒私有云的安全完全由企业自主管理，可实现：物理隔离：通过专属机房、防火墙、入侵检测系统（IDS）构建多层防御。零信任架构：基于用户身份、设备状态、行为分析动态授权，防止内部攻击。例如，某银行通过私有云部署零信任网络，内部威胁检测率提升至99.2%。合规定制：根据行业要求（如HIPAA、GDPR）定制安全策略，满足严格监管需求。混合云：跨云安全的一致性挑战混合云需统一公有云与私有云的安全策略，避免“安全孤岛”：单点登录（SSO）：通过SAML2.0或OIDC实现跨云身份认证，减少凭证泄露风险。日志整合：使用SIEM（安全信息与事件管理）工具（如Splunk、ELK）集中分析公有云与私有云日志，快速定位威胁。加密数据传输：通过IPsecVPN或SD-WAN确保跨云数据在传输过程中的安全性。三、弹性与性能：如何应对业务波动？公有云：秒级弹性的“无限扩展”公有云的弹性源于其分布式架构和自动化工具：无服务器计算（Serverless）：如服务商函数计算，按调用次数计费，适合事件驱动型应用（如图像处理、实时日志分析）。容器化与K8s：通过EKS、ACK实现应用快速部署与自动扩缩容，应对突发流量。私有云：渐进式弹性的“稳扎稳打”私有云的弹性受限于硬件资源，但可通过以下技术优化：超融合架构（HCI）：将计算、存储、网络集成到单一设备，简化扩展流程。例如，某企业通过NutanixHCI将私有云扩展时间从数天缩短至数小时。容器编排（K8s）：在私有云中部署K8s集群，实现应用水平扩展，但扩展速度慢于公有云。混合云：灵活应变的“变形金刚”混合云的弹性体现在资源跨云调度能力：云爆发（CloudBursting）：私有云资源不足时，自动将部分负载溢出到公有云。例如，某制造企业将CAD设计任务在私有云处理，渲染任务溢出到AWS，整体效率提升40%。边缘计算：通过KubeEdge、IoTEdge将AI推理能力下沉到边缘节点，降低延迟。例如，某汽车厂商用混合云边缘计算将车载AI决策时延从100ms降至10ms，提升驾驶安全性。四、选型建议：结合业务场景，找到“划算”平衡点选公有云：业务波动大、成本敏感、对安全要求中等（如互联网、电商、初创企业）。典型场景：Web应用、移动应用、大数据分析、测试开发环境。选私有云：数据敏感、合规要求高、业务稳定（如金融、医疗、政府）。典型场景：核心数据库、ERP系统、内部办公应用。选混合云：业务复杂、需要灵活扩展、技术团队强（如制造、零售、能源）。典型场景：多云架构、灾备恢复、全球业务部署。结语：没有“最好”，只有“最适合”公有云、私有云、混合云各有优劣，企业需根据自身业务特点、成本预算、安全需求和技术能力综合评估。上云不是终点，而是数字化转型的起点——通过持续优化资源使用、强化安全防护、提升弹性能力，才能真正实现“划算”与“高效”的双赢。 

近期，全球领先的IT市场研究和咨询公司IDC发布了《中国软件定义计算软件市场跟踪，2024H2》报告。报告显示，华为云在2024年中国容器软件市场的份额及增速均位居第一，展现了华为云在云原生领域的领先地位，也体现了客户对华为云的高度认可与信赖。IDC在报告中指出：2024年，容器基础设施软件（CIS）成为整体市场的增长驱动力，预计到2027年将占据SDC软件市场的三分之一。在AI领域，由于其开放性和现代化的功能集，Kubernetes目前已成为AI应用的默认底座。2024年层出不穷的智算中心，大模型平台建设，生成式AI应用构建的项目为容器基础架构软件市场带来新机会。华为云在云原生领域持续创新，在业界率先发布CCE（Cloud Container Engine) （含CCE Turbo/CCE Autopilot）、CCI（Cloud Container Instance）以及UCS（Ubiquitous Cloud Native Service）等多款创新性容器产品，持续引领云原生产业发展。面向AI时代，云原生2.0全面智能化，构建智能驱动的全新一代AI-Native云原生基础设施。CCE智算集群作为CloudMatrix384 超节点的容器底座，提供超节点拓扑感知调度、PD分离扩缩容、AI负载感知的弹性扩缩容及容器极速启动等能力，大幅加速AI训练和推理，提升AI任务运行效率。与此同时，AI技术也在重塑云服务体验，华为云全新发布CCE智能助手，以AI Agent方式嵌入容器使用全流程，贯穿智能问答、智能推荐、智能诊断、智能托管等业务流程，实现容器集群管理的自动化与智能化，助力企业加速创新。 基于前沿技术积累，华为云携手伙伴，以云原生技术为核心驱动力，加速云、AI等前沿技术在各行业的深度融合与落地应用，广泛服务金融、政务、能源、制造等行业客户，助力企业高效构建现代化云原生架构，加速数字化转型进程和智能化升级，释放数字经济新动能。▍在金融领域华为云云原生技术凭借其卓越的性能和创新力，已成为金融行业数字化转型的核心引擎，为金融分布式新核心系统提供了坚实的底座，全方位引领行业智能化升级的潮流，定义了金融领域云原生技术的新高度。目前，华为云已为中国六大银行、12家股份制商业银行及众多保险证券客户提供全方位服务，全球服务金融机构超500家。光大银行基于华为云Stack启动全栈云建设，凭借CCE Turbo和鲲鹏算力两大性能引擎，实现大规模容器集群管理，极大提升资源利用率，彰显了华为云在金融领域的卓越实力。▍在政务云领域华为云自2012年起持续深耕，凭借领先的技术与服务，累计服务超过800个政务云项目，为政府机构数字化转型提供强大动力，显著提升服务民生效率。国家统计局为响应“推动现代化信息技术与统计工作深度融合”的要求，基于华为云Stack打造全新统计云，并首次采用云原生架构。以CCE Turbo为核心的云原生基础设施，凭借其极致弹性，灵活应对全国经济普查、联网直报、住户调查、价格调查等大规模及周期性查询需求。在第五次全国经济普查中，统计云成功完成首次大规模查询实战，成为统计信息化建设的里程碑，彰显华为云在政务云领域的卓越表现和领先地位。▍在制造领域华为以“深耕制造，让智能生根”为价值主张，致力于依托5G、云计算、大数据、人工智能等新ICT技术，赋能传统制造企业，助力制造企业实现研发、生产、供应等业务的智能化，重塑制造行业价值链。长安汽车数智工厂以CCE为底座，打造集团+工厂的云边端协同架构，通过云原生基础设施的弹性、敏捷全面提升C2M模式柔性生产力，支持1万多种整车配置的个性化生产，订单交付周期缩短20%。长安汽车数智工厂的数字化转型先行先试，推动长安汽车率先驶入智造快车道，为汽车行业迈向智能制造提供了重要参考。未来，华为云将持续聚焦云原生技术创新、产品升级以及生态繁荣，继续携手全球客户，将领先的技术与行业知识相结合，助力企业数智化转型，成就卓越企业，共赴智能未来。 更多云原生技术动向关注容器魔方  【更多华为云云原生干货推荐】华为云云原生王者之路集训营华为云云原生王者之路集训营为帮助广大技术爱好者快速掌握云原生相关技能，华为云云原生团队与华为云学院联合CNCF开源软件大学启动人才培养计划，推出《华为云云原生王者之路集训营》，从云原生基础知识介绍到最佳实践讲解、底层原理和方案架构深度剖析，层层深入，满足不同云原生技术基础和学习目标人群的需求。本课程还精选数十个企业典型应用场景，作为学员上机实践案例，帮助学员将所学技术快速与企业业务相结合，服务于企业生产。点击免费参加华为云云原生王者之路集训营：cid:link_3 学习后记得小试牛刀，看看测评效果~ 华为云云原生王者之路-黄金课程测评 华为云云原生王者之路-钻石课程测评 华为云云原生王者之路-王者课程测评

7月1日起，开源之夏2025为期三个月的项目开发正式拉开序幕。历经导师、社区、组委会三轮审核，共有18位海内外高校同学在激烈的竞争中脱颖而出，成功中选KubeEdge社区任务，中选学生将在社区导师的指导下，完成项目开发。KubeEdge 社区期待和计算机领域新生力量一起薪火相传，共启云原生边缘计算无限可能。中选名单公示重要时间节点一览学生指南：https://blog.summer-ospp.ac.cn/help/student%20guide# 关于开源之夏“开源之夏（英文简称 OSPP）”是中国科学院软件研究所“开源软件供应链点亮计划”指导下的系列暑期活动，由中国科学院软件研究所和华为技术有限公司共同主办，旨在鼓励在校学生积极参与开源软件的开发维护，培养和发掘更多优秀的开发者，促进优秀开源软件社区的蓬勃发展，助力开源软件供应链建设。  社区小助手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/ 

7月1日，开源之夏2025为期三个月的项目开发正式拉开序幕。历经导师、社区、组委会三轮审核，共有6位海内外高校同学在激烈的竞争中脱颖而出，欢迎同学们的加入！成功中选Karmada社区任务的同学，将在社区导师的指导下，开启云原生多云多集群前沿课题共创。# 中选名单公示（Karmada）# 重要时间节点一览 学生指南：https://blog.summer-ospp.ac.cn/help/student%20guide# 关于开源之夏“开源之夏（英文简称 OSPP）”是中国科学院软件研究所“开源软件供应链点亮计划”指导下的系列暑期活动，由中国科学院软件研究所和华为技术有限公司共同主办，旨在鼓励在校学生积极参与开源软件的开发维护，培养和发掘更多优秀的开发者，促进优秀开源软件社区的蓬勃发展，助力开源软件供应链建设。 Karmada 是CNCF 首个多云多集群容器编排项目(孵化级），旨在帮助用户像使用单个集群一样轻松管理跨云多集群，让基于 Karmada 的多云方案无缝融入云原生技术生态。社区吸引了来自华为、道客、浙江大学、腾讯、中国电子云、滴滴、Zendesk、携程等100多家公司的全球贡献者，广泛分布于20+国家和地区。Karmada 现已在华为云、道客、兴业数金、中国移动、中国联通、携程、360集团、新浪、中通快递等众多企业单位生产应用，为企业提供从单集群到多云架构的平滑演进方案。 添加社区小助手k8s2222回复Karmada进入技术交流群 Karmada官网：https://karmada.io/项目地址：https://github.com/karmada-io/karmadaSlack地址：https://slack.cncf.io/（#karmada）

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