• [热门活动] 5月27日截止 | Volcano社区2025夏季LFX Mentorship欢迎你的加入
    由Linux Foundation组织的LFX Mentorship计划,从19年开始为CNCF各个开源社区中的开发人员持续提供带薪实习和指导。往年已获20K+申请,发起1300+课题,毕业1000+实习生,发放超过310万美金报酬。LFX Mentorship 2025 Term 2 Mentee 报名正在进行,截止时间为太平洋夏令时 5 月 27 日星期二上午 11:00 (18:00 UTC),远程实习将从 6 月 9 日开始为期三个月。参与到LFX Mentorship计划中,为开源项目做贡献、获得开源社区的认可同时,完成工作还能获取报酬 (位于中国的开发者报酬为$3000美金,约合¥20000人民币)。Volcano社区在LFX Mentorship的课题申请正在火热进行中,欢迎前往官方平台申请: https://mentorship.lfx.linuxfoundation.org/ 🏷️ 需要留意的是, LFX Mentorship 2025 面向在校及已毕业申请者同时开放,而在校学生可同时关注Volcano开源之夏《大咖领路+高额奖金!Volcano社区开源之夏8大课题邀你挑战 》获取更多暑期开源社区工作机会。 Volcano社区介绍 Volcano 是业界首个云原生批量计算引擎,也是 CNCF 首个和唯一的批量计算项目。Volcano 云原生批量计算项目主要用于 AI、大数据、基因、渲染等诸多高性能计算场景,对主流通用计算框架均有很好的支持。社区已吸引5.8万+全球开发者,并获得4.7k Star 和1.1K+Fork,参与贡献企业包括华为、AWS、百度、腾讯、博云、京东、小红书、第四范式、bilibili等。社区地址:https://github.com/volcano-sh/volcano目前,Volcano在人工智能、大数据、基因测序等海量数据计算和分析场景已得到广泛应用,完成对 Spark、Flink、Ray 、Tensorflow、PyTorch、Argo、MindSpore、Paddlepaddle 、Kubeflow、MPI、Horovod、Mxnet、KubeGene等众多主流计算框架的支持,并构建起完善的上下游生态。在LFX Mentorship 2025 Term 2 ,Volcano期待与你协作开拓AI大数据等场景调度的更多可能。面向对象  LFX Mentorship 2025 Term 2申请者需在2025年5月27日前在LFX官网完成Mentee注册及项目申请。若被接收作为Mentee,您将能在开源社区经验丰富、积极贡献的Mentor指导下为开源项目做出贡献。依据官方规定[1],对Mentee申请者有以下要求:计划开始时至少年满18周岁所在单位和组织不禁止该实习未参加另外的Linux Mentorship计划开发者以个人身份参与(在校或已毕业均可)具备所注册国家中工作权利且所注册国家未被计划禁止 (中国已获许可)并非社区中高于最低限度贡献成员(如Maintainer、Recurring Contributor)满足具体所属项目中提及的其它前置需求课题参与方式 根据官方安排 [2],LFX Mentorship 2025年夏季活动流程如下:Mentee报名申请:5月15日-5月27日申请者审核期: 5月28日-6月3日申请者入选通知: 6月4日实习启动: 6月9日中期考核:7月15日首次津贴支付 :7月16日结项考核、实习生报告提交,最终津贴支付批准 :8月26日-27日活动结束 :8月29日申请指南详见 [3]:https://docs.linuxfoundation.org/lfx/mentorship/mentee-guide/how-to-apply实习申请结果预计将在 6 月 4 日通知到申请人。主线开发日期为2025年6月9日-8月26日,全程线上协作,无需线下参与。结项需要在2025年8月26日前以 PR 的形式提交到项目所在的开源社区仓库中并完成合并。 Volcano课题   在LFX Mentorship 2025 Term 2,CNCF Volcano社区带来以下课题:▍Enhance JobFlow Functionality课题描述:Volcano 社区引入了 JobFlow 来解决作业间的依赖关系。通过 JobTemplate 和 JobFlow API ,用户可以声明和编排多个 Volcano 作业,并利用顺序执行、并行执行、条件执行、分支执行和循环执行等控制流原语。JobFlow 旨在促进 AI、大数据和 HPC 工作负载向云原生环境的迁移。当前的 JobFlow 功能需要进一步增强,以满足更复杂的实际场景需求。参考:https://github.com/volcano-sh/volcano/tree/master/docs/design/jobflow预期成果:1. 支持在 JobFlow 中引用 JobTemplate 时修改其参数,例如更改容器镜像版本、调整资源限制等。2. 在 JobFlow 中为失败的作业实现可配置的重试机制,例如支持指数退避重试策略、设置最大重试次数等。3. 引入更丰富的控制流语句,例如 if、switch 和 for 语句,例如基于上游任务状态的条件分支、特定任务集的迭代执行等。前置技能:Kubernetes,Volcano,GO课题导师:Xuzheng Chang(@Monokaix )2536818783@qq.comDong Jiang (@dongjiang1989)dongjiang2010@gmail.com 课题链接:https://mentorship.lfx.linuxfoundation.org/project/6e853798-e2a3-445f-89f4-63c2e5acc58b▍Implement Volcano Scheduler Simulator课题描述:对于 Kubernetes 和 Volcano 调度器的用户来说,调度过程通常像一个黑盒。理解调度决策的执行过程以及评估调度器的功能和性能(尤其是在引入新的调度功能时)可能颇具挑战性。搭建一个功能齐全的 Kubernetes 集群并生成真实的工作负载来观察调度行为可能非常耗时且比较消耗资源。用户需要一种轻量级且高效的方法来验证调度器变更的正确性和性能影响,无需搭建一个真实集群,即可完成模拟调度。预期成果:1. 实现一个能够模拟 Volcano 调度器核心调度逻辑的 Volcano 调度器模拟器。2. 该模拟器应该能够接收模拟的 Kubernetes 集群状态(例如,节点、Pod、队列)和 Volcano 配置作为输入。3. 模拟器应输出模拟调度结果,包括 Pod 被调度到的节点,以及决策过程信息(例如,考虑的节点、筛选和评分结果)。4. (可选)模拟器可以提供基本的性能指标输出,例如模拟调度延迟。5. 提供清晰的使用文档和示例,方便用户验证功能前置技能:Kubernetes, Go, Volcano课题导师:Xuzheng Chang(@Monokaix )2536818783@qq.comlowang-bh(@lowang-bh)lhui_wang@163.com课题链接:https://mentorship.lfx.linuxfoundation.org/project/017774aa-f821-49c6-b701-fef1a0fae17b▍Enhance Volcano Dashboard UX and Functionality课题描述:Volcano Dashboard 是 Volcano 资源的前端展示平台。目前,它支持 Volcano 作业、队列和 Pod 等资源,但编辑通常需要使用原始 YAML 格式,这对于修改或创建新资源并不方便。为了提升用户体验,本项目旨在增强 Dashboard 的交互性和用户友好性,并支持显示层级队列和超节点 (HyperNode) 资源。预期成果:1. 改进资源显示和编辑界面,提供更友好的交互方式,例如使用表单或可视化编辑器代替直接编辑 YAML 格式来创建和修改资源。2. 支持显示层级队列和超节点资源,并提供鼠标点击展开/折叠功能,以便清晰地可视化资源关系。3. 优化用户界面设计,提升美观度和易用性。4. 重构后端代码,提高可维护性和可扩展性。5. 显示资源的关键信息和完整信息,并可在视图之间切换。6. (可选)支持更多资源类型的显示和管理。前置技能:Kubernetes, React, Node.js, JS课题导师:Xuzheng Chang(@Monokaix )2536818783@qq.comZicong Chen (@JesseStutler )jesseincomparable@hotmail.com课题链接:https://mentorship.lfx.linuxfoundation.org/project/e81c895a-69f9-4c63-b4fe-e9352c3fa2e7▍Enhance Volcano Official Documentation课题描述:随着 Volcano 功能的不断丰富以及与更广泛生态系统集成的不断深入,社区文档需要不断更新迭代,以提供更优质的用户指南和体验。清晰全面的文档有助于用户快速上手 Volcano,并降低使用和配置成本。目前,部分文档分散在 GitHub 仓库中,需要迁移至官网,为用户提供统一的入口。预期成果:1. 将 GitHub 仓库中尚未上线的文档迁移至官网。2. 详细讲解 Volcano Scheduler、Volcano Controller、Volcano Agent 和 Volcano Admission 组件的功能,包括其各自启动参数的含义。3. 补充核心功能(例如 JobFlow 和 vGPU 虚拟化)的文档。4. 添加“最佳实践”部分,提供在各种场景下使用 Volcano 的建议和配置示例。5. 添加“故障排除”部分,用于收集和整理常见问题及其解决方案。前置技能:Technical Writing, Markdown,Git,Hugo or other static site generators课题导师:Xuzheng Chang(@Monokaix )2536818783@qq.comZicong Chen (@JesseStutler )jesseincomparable@hotmail.com课题链接:https://mentorship.lfx.linuxfoundation.org/project/a8bafeea-f608-4e73-9a44-ca60c309536f 如果对课题内容有任何问题,欢迎向课题导师发送邮件或在GitHub仓库提交Issue提问。扫码回复“Volcano” 进入技术群参考资料[1] LFX Mentorship - Application Requirement: https://docs.linuxfoundation.org/lfx/mentorship/mentee-guide/am-i-eligible [2] LFX Mentorship - Program Readme: https://github.com/cncf/mentoring/tree/main/programs/lfx-mentorship/2025/02-Jun-Aug[3] LFX Mentorship - Mentee Application Guideline: https://docs.linuxfoundation.org/lfx/mentorship/mentee-guide/how-to-applyVolcano 是业界首个云原生批量计算引擎,也是 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
  • [热门活动] 华为邀您相聚KubeCon China 2025,共绘云原生新一个十年
    6月10日-11日,由Linux基金会、云原生计算基金会(CNCF)联合主办的KubeCon+CloudNativeConChina2025将于中国香港盛大召开。作为全球云原生与开源顶级会议,大会汇聚世界顶尖技术专家与前沿企业,深入Kubernetes、云原生架构、人工智能、开源生态系统等领域的技术与应用创新探讨,促进行业领导者、项目维护者和最终用户之间的合作,共绘云原生新一个十年。更多云原生技术动向关注容器魔方【更多华为云云原生干货推荐】华为云云原生王者之路集训营华为云云原生王者之路集训营为帮助广大技术爱好者快速掌握云原生相关技能,华为云云原生团队与华为云学院联合CNCF开源软件大学启动人才培养计划,推出《华为云云原生王者之路集训营》,从云原生基础知识介绍到最佳实践讲解、底层原理和方案架构深度剖析,层层深入,满足不同云原生技术基础和学习目标人群的需求。本课程还精选数十个企业典型应用场景,作为学员上机实践案例,帮助学员将所学技术快速与企业业务相结合,服务于企业生产。点击免费参加华为云云原生王者之路集训营:cid:link_3 学习后记得小试牛刀,看看测评效果~ 华为云云原生王者之路-黄金课程测评 华为云云原生王者之路-钻石课程测评 华为云云原生王者之路-王者课程测评
  • [公告] Kmesh v1.1.0 正式发布!官网焕新升级
    我们非常高兴地宣布 Kmesh v1.1.0 版本正式发布,这是Kmesh社区在过去三个月共同努力的成果。在此,我们特别感谢 LFX Mentorship 的贡献者,他们的贡献对推动此版本的发布至关重要。在 v1.0.0 的基础上,此版本对 Kmesh 的架构、可观察性和生态系统集成进行了重大改进。Kmesh 官方网站经过了全面的重新设计,提供了直观的界面和精简的文档,以增强用户和开发者的体验。此外,我们还重构了 DNS 模块并添加了长连接指标,从而能够更深入地洞察更多流量模式。在 Kernel-Native 模式下,我们减少了对内核的侵入式修改。另外,我们使用全局变量替换 BPF 配置映射,以简化底层复杂性。与 Istio 1.25 的兼容性也经过了严格的验证,确保与该版本的 Istio 实现无缝互操作。值得注意的是,长期以来一直存在的 TestKmeshRestart E2E 测试用例不稳定问题,通过对底层 BPF 程序的长期调查和重构,已得到解决,标志着运行时可靠性的飞跃。  Kmesh v1.1.0 版本主要特性  网站全新改版Kmesh 官方网站经过了彻底的重新设计,提供了更直观的用户体验,改进了文档,重新组织了内容层次结构,并简化了导航。在处理上一次迭代中的反馈时,我们专注于可以提升用户体验的关键领域。之前的界面存在一些可用性问题,偶尔会导致查找比较困难。我们的博客模块尤其需要关注,因为它的内容组织和视觉层次结构已经影响了内容的可发现性和可读性。从工程角度来看,我们认识到可以通过更好的组件组织和更系统的样式方法来改进代码结构,因为现有的实现随着时间的推移已经变得越来越复杂,难以维护。为了解决这些问题,我们转向了 React 和 Docusaurus,这是一个对开发人员更加友好的现代文档框架。这使我们能够创建模块化组件,并通过可重用性消除冗余代码。 Docusaurus 提供专为文档和博客设计的内置导航系统,以及版本控制的文档功能。我们实现了文档的多语言支持,添加了高级搜索功能,并彻底重构了内容结构。这些举措显著提升了用户体验,使 Kmesh 网站对所有用户来说都更易于访问,也更具价值。长连接指标在此版本之前,Kmesh 仅在 TCP 连接终止和建立期间提供访问日志,其中包含有关连接的详细信息,例如发送和接收的字节数、数据包丢失、RTT 和重传次数。Kmesh 还提供特定于工作负载和服务的指标,例如发送和接收的字节数、丢失的数据包、最小 RTT 以及 Pod 打开和关闭的总连接数。这些指标仅在连接关闭后更新。在此版本中,我们实现了 TCP 长连接的访问日志和指标,并开发了一种持续的监控和报告机制,可在长连接整个生命周期内捕获详细的实时数据。访问日志会定期报告,其中包含报告时间、连接建立时间、发送字节数、接收字节数、丢包率、RTT、重传次数和状态等信息。长连接还会定期报告发送字节数、接收字节数、丢包率和重传次数等指标。DNS 重构当前的 DNS 进程包含 CDS 刷新进程。因此,DNS 与内核原生模式深度耦合,无法在双引擎模式下使用。在 1.1 版本中,我们重构了 Kmesh 的 DNS 模块。DNS 中循环遍历刷新队列的数据不再是一个包含 CDS 的结构,而是变成了一个域名,因此 DNS 模块不再关心 Kmesh 模式,只提供待解析的主机名。BPF 配置映射优化Kmesh 已删除专用的 kmesh_config_map BPF map,该map之前存储了全局运行时配置,例如 BPF 日志记录级别和监控开关。现在,这些设置通过全局变量进行管理。利用全局变量可以简化 BPF 配置管理,从而提高运行时效率和可维护性。优化内核原生模式,减少对内核的侵入式修改内核原生模式需要大量侵入式内核重构才能实现基于 HTTP 的流量控制。其中一些修改可能会对内核产生重大影响,这使得内核原生模式难以在实际产品中部署和使用。为了解决这个问题,我们同步修改了内核原生模式下的内核以及相关的 ko 和 eBPF。通过本次版本的优化,在内核 5.10 中,内核修改限制为四个,在内核 6.6 中,内核修改减少为只有一个。最后一个修改将尽可能地被消除,最终目标是在原生版本 6.6 及以上版本上运行内核原生模式。Istio 1.25 兼容性验证Kmesh 已验证与 Istio 1.25 的兼容性,并在 CI 中添加了相应的端到端测试。Kmesh 社区负责在 CI 中对三个 Istio 版本进行验证,因此 Istio 1.22 的端到端测试已从 CI 中移除。  关键 Bug 修复  1. kmeshctl 安装waypoint错误: https://github.com/kmesh-net/kmesh/issues/1287 2. TestKmeshRestart flaky问题: https://github.com/kmesh-net/kmesh/issues/1192  致 谢 贡 献 者  Kmesh v1.1.0 版本包含了来自14位贡献者的118次代码提交,在此对各位贡献者表示由衷的感谢:我们始终以开放中立的态度发展 Kmesh,持续打造 Sidecarless 服务网格业界标杆方案,服务千行百业,促进服务网格健康有序的发展。Kmesh 当前正处于高速发展阶段,我们诚邀广大有志之士加入!参考资料[1] Kmesh Release v1.1.0: https://github.com/kmesh-net/kmesh/releases/tag/v1.1.0[2] Kmesh GitHub: https://github.com/kmesh-net/kmesh[3] Kmesh Website: https://kmesh.net/扫码添加社区小助手回复Kmesh进交流群【更多华为云云原生干货推荐】华为云云原生王者之路集训营华为云云原生王者之路集训营为帮助广大技术爱好者快速掌握云原生相关技能,华为云云原生团队与华为云学院联合CNCF开源软件大学启动人才培养计划,推出《华为云云原生王者之路集训营》,从云原生基础知识介绍到最佳实践讲解、底层原理和方案架构深度剖析,层层深入,满足不同云原生技术基础和学习目标人群的需求。本课程还精选数十个企业典型应用场景,作为学员上机实践案例,帮助学员将所学技术快速与企业业务相结合,服务于企业生产。点击免费参加华为云云原生王者之路集训营:cid:link_3 学习后记得小试牛刀,看看测评效果~ 华为云云原生王者之路-黄金课程测评 华为云云原生王者之路-钻石课程测评 华为云云原生王者之路-王者课程测评
  • [技术干货] KubeEdge-Ianvs v0.3.0版本:大模型与数据集发布,支持行业大模型、协同推理范式及智能体等算法
    北京时间2025年4月10日,KubeEdge-Ianvs v0.3.0版本正式发布。在智能涌现的大模型时代,云边协同技术是保障实时性能、确保安全合规、承接定制化需求和资源高效利用的关键。本文探讨云边协同人工智能在大模型时代的边侧场景壁垒问题、云边协同架构问题及边侧需求多样化问题。面向这三大问题,文章重点介绍 KubeEdge-Ianvs v0.3.0 版本中基于大模型的全新功能升级,包括行业大模型基准测试。除支持一站式流程、多种数据格式及第三方工具等基础大模型评测能力外,开发对大模型进行政务领域、具身智能领域、代码领域及边缘系统领域的基准测试,开源对应2k+政务数据集 (Gov-aff)、2.5k+具身智能数据集 (Cloud-Robotics)、以及指标和测试工具;大模型协同推理范式。发布大模型云边协同推理范式及其查询路由、投机解码算法,发布多边协同推理范式,开源对应示例代码和使用文档;大模型自适应系列算法。开发了个性化智能体算法、多模态联合学习算法以及未知任务终身学习算法,开源对应示例代码和使用文档。 一、背景:云边大模型基准测试三大问题  随着大模型在各行业加速落地,实时性、定制化、安全合规及资源受限等实际需求不断涌现,越来越多的应用需要云边协同技术将强大的大模型能力延展到边缘侧。然而,大模型跨云边的测试、协同优化以及性能验证,往往缺乏统一标准和成熟工具,KubeEdge SIG AI 识别在开发与部署落地过程中的三大问题:问题1:场景壁垒问题。行业大模型大量应用于边侧特定领域,而现有基准测试通常围绕通用大语言模型、通用视觉大模型等开展,通用基准测试的测试集、测试指标乃至测试环境用于政务、具身、代码、边缘系统等特定行业领域往往出现巨大误差,对相关产品质量评估存在挑战。问题2:云边协同架构问题。随着大模型推理业务场景的不断拓展,单一云端或静态边缘模型难以满足高时效、低成本和个性化的实际需求。虽然 KubeEdge SIG AI 历史项目中包含云边协同推理范式,但仅适用于视觉深度学习,在大模型尤其是自然语言大模型场景,云边各模块已不再适用。问题3:边侧需求多样化问题。现有基准测试通常围绕通用大模型开展,但边侧场景往往存在边缘定制化、多种模态和开放世界未知任务等情况,对通用大模型的边侧适应性诉求及冲突愈发尖锐。二、解决方案:围绕大模型全面升级  为了解决上述挑战,KubeEdge-Ianvs v0.3.0  版本带来了三项关键升级:方案1:行业大模型基准测试。支持大语言模型本地部署和公共 API 接口(如 OpenAI)测试,支持政务、具身、代码、边缘系统四大领域的行业大模型能力测试,开源对应测试集、指标和测试工具方案2:大模型协同推理范式。开发高效的大语言模型云边协同推理架构,集成查询路由、投机解码等前沿算法,推理加速20%+,显著降低推理资源消耗。支持多边联合推理范式,覆盖分布式推理场景方案3:发布自适应系列算法。新增个性化 LLM Agent、多模态联合学习、未知任务终身学习等算法模块。覆盖更多真实应用需求,助力大模型能力持续演进👇🏻下面深入解读三大升级功能:▍1. 行业大模型基准测试图1 KubeEdge-Ianvs大模型基准测试架构如前述,传统基准测试是针对通用模型设计,其评测方法迁移到边侧垂直领域时,表现出测试集适配性不足、评价指标偏差显著且验证环境兼容性差等系统性缺陷,这已对行业专用模型的精准性能评估形成实质性障碍。对应地,KubeEdge-Ianvs v0.3 分别基于大模型及行业领域进行功能升级。首先,KubeEdge-Ianvs v0.3 为本地和云端多类型大模型提供评测工具集,为后续高阶大模型评测奠定基础。在基础功能中,开发者和企业可快速获取模型跨场景真实能力数据,支撑大模型落地前的全流程验证与优化。提供一站式 Benchmark 接口:为不同类型的大模型基准测试提供统一接口,支持自定义 Prompt 模板、多样化推理场景(零样本、少样本、检索增强等)开箱即用,支持主客观评测、自动统计及评测报告自动生成。兼容多种数据格式与任务类型:支持主流 json/jsonl 格式的数据文件,摆脱传统 index 文件限制。适配自然语言、多模态、视觉等多领域测试数据。一体化集成第三方工具:对接开源测试工具 OpenCompass,涵盖百余主流标准 Benchmarks,支持主流公有云大模型 API 调用及本地模型测试。进一步地,由于高阶大模型大量应用于边侧特定行业领域,KubeEdge-Ianvs 支持高阶大模型基准测试,包括政务、代码和边缘系统领域。政务领域基准测试:开源政务领域首个政务问答测试数据集(GovAff[1] )及对应套件(CGAUE[2]),测试数据集包含1600道选择题和1045道主观题,贴合各地政策问答,附设计文档[3]及期刊论文[4]。图2 KubeEdge-Ianvs政务大模型基准测试CGAUE架构具身智能领域基准测试:开源具身智能领域测试数据集 (Cloud-Robotics)[5][6]及其对应套件[7],测试数据集包含30类对象2500+图像,套件则集成了基于 RFNet 等预训练大模型的多模态联合学习能力,附设计文档[8]及测试示例[7]。图3 KubeEdge-Ianvs具身智能数据集Cloud-Robotics边缘系统领域基准测试:通过测量 CPU 负载和带宽消耗等关键指标,评估大模型在边缘设备上的性能,了解边缘部署的资源需求和局限性,附设计文档[9]、测试示例[10]及测试样本[11]。代码领域基准测试:针对编程、问答、推理等多样化测试,评测结果可通过准确率、BLEU 等主流指标一站式输出,附设计文档[12]及测试示例[13]。▍2. 大模型协同推理范式随着大模型推理业务向多元场景延伸,传统纯云架构与边缘部署模式暴露出推理时延冗余、分布式成本失控及服务个性化受限等典型矛盾。KubeEdge SIG AI 原有云边协同推理虽然在视觉深度学习领域实现了初步整合应用,但在处理大模型时,其核心框架组件出现功能适配断层,此类技术瓶颈正制约大模型在智能客服、工业质检等场景的端到端产业化部署。对应地,KubeEdge-Ianvs v0.3 版本发布大模型云边协同推理范式及多边协同推理范式。图4 大模型云边协同推理范式架构大模型云边协同推理范式。Ianvs v0.3 引入先进的云-边协同推理范式,通过灵活分配推理任务,实现云端算力与边缘设备高效协作,适配各种网络条件和设备异构环境,广泛支持政务、工业物联网、智慧城市等多种垂直应用部署。详见设计文档[14]及示例[15]。该范式引入查询路由机制,通过评估请求的复杂程度,自动判断是否应该在云端大型模型还是边端小型模型完成,查询路由 (Query-Routing)降低至少 50% 的首字时延,同时还能带来额外12.38% (相比 Qwen 自身) 和 8.23%(相比 gpt-4o-mini) 的绝对精度提升。图5 大模型云边协同推理-查询路由机制该范式支持 state-of-the-art 投机解码(Speculative Decoding)算法EAGLE (ICML’24),通过目标模型 (Target Model) 和草稿模型 (Draft Model) 协作,在不影响推理准确性的前提下,将大型 LLM 推理加速到2x以上,极大提升系统推理速度。详见设计文档[16]及示例[17]。图6 投机解码算法示例该范式支持多种推理引擎,支持 transformers, vLLM, EAGLE 等丰富的推理引擎,并可根据需要快速支持其他推理引擎。该范式还支持多样指标统计,包括对精度(Accuracy), 首字时延(Time-to-First-Token, TTFT),吞吐量(Throughput),Token 数等指标的监测记录。图7 多边协同推理范式架构多边协同推理范式。以行人追踪为例,利用 Graph Scheduling 与 ByteTrack 模型优化,实现多设备分布式联合推理,支持特殊场景下(如园区安防、工业生产线)AI 能力的端到端协同部署。详见设计文档[18]及示例[19]。图8 多边协同推理示例▍3. 大模型场景新算法支持当前大模型基准评测仍然偏重于通用模型评估,未能有效覆盖边缘计算环境本地化需求,诸如边缘定制化、多种模态和开放世界未知任务等情况普遍存在。这些边缘原生需求与通用模型能力边界之间的矛盾正持续升级,凸显出云边协同通用模型算法及测试的理论缺失与实践空白。KubeEdge-Ianvs v0.3全面升级了大模型适配能力,集成多项创新算法,让 AI 真正“因场而变”,实现从基础推理到个性化、多模态与终身学习的全场景覆盖。个性化大模型智能体算法。基于 Bloom 等主流大模型,结合用户自身数据与任务,实现边缘侧的任务个性化优化。支持单任务定制化训练,让每个终端都能拥有独特的 AI 助手,覆盖如客户交互、智能问答、定制自动化等场景。该算法可无缝对接云边协同推理框架,在保证隐私和响应速度的前提下,最大化个体或组织的智能服务体验。详见设计文档[20]及示例[21]。图9 个性化大模型智能体架构与示例未知任务终身学习算法。面对快速变化的应用环境和任务需求,Ianvs 提供了基于预训练模型的“未知任务处理”与终身学习算法。能够自动适配新任务,实现模型的增量学习和知识迁移,让大模型在不断变化的现实世界中,持续保持领先的泛化能力和处理效率。详见设计文档[22]及示例[23]。图10 未知任务终身学习算法架构与示例三、Release Note  如果读者对于本次版本发布的更多细节感兴趣,欢迎查阅 KubeEdge Ianvs v0.3.0 Release Note[24]。后续 KubeEdge SIG AI 将发布系列文章,陆续具体介绍新版本升级的特性,欢迎各位读者继续关注社区动态及持续关注 KubeEdge-Ianvs,获取前沿开源数据集、基准测试和云边 AI 创新动态!🔗 开源仓库 GitHub 地址:https://github.com/kubeedge/ianvs 相关链接:[1] The Chinese Government Affairs Dataset (GovAff) : https://www.kaggle.com/datasets/kubeedgeianvs/the-government-affairs-dataset-govaff/[2] 政务大模型基准测试套件 (Chinese Gov. Affairs Understanding Evaluation Benchmark, CGAUE): https://github.com/kubeedge/ianvs/tree/main/examples/government/singletask_learning_bench[3] 政务大模型基准测试设计文档: https://github.com/kubeedge/ianvs/blob/main/docs/proposals/scenarios/llm-benchmarks/llm-benchmarks-zh.md[4] 边侧大模型基准测试:政务大模型初探: https://d.wanfangdata.com.cn/periodical/zdhbl202502037[5] The Cloud-Robotics Dataset: https://www.kaggle.com/datasets/kubeedgeianvs/cloud-robotics#[6] The Cloud-Robotics Dataset 数据集介绍: https://github.com/kubeedge/ianvs/blob/main/docs/proposals/scenarios/Cloud-Robotics/Cloud-Robotics_zh.md[7] 具身智能领域基准测试示例: https://github.com/kubeedge/ianvs/tree/main/examples/Cloud_Robotics/singletask_learning_bench/Semantic_Segmentation[8] 具身智能领域基准测试设计文档: https://github.com/kubeedge/ianvs/blob/main/docs/proposals/scenarios/Cloud_robotics/single_task_learning.md[9] 边侧系统基准测试设计文档: https://github.com/kubeedge/ianvs/blob/main/docs/proposals/scenarios/llm-benchmark-suite/llm-edge-benchmark-suite.md [10] 边侧系统基准测试示例:: https://github.com/kubeedge/ianvs/tree/main/examples/llm-edge-benchmark-suite [11] 边侧系统基准测试样本: https://github.com/kubeedge/ianvs/tree/main/examples/llm_simple_qa [12] 代码大模型基准测试设计文档: https://github.com/kubeedge/ianvs/blob/main/docs/proposals/scenarios/Smart_Coding/Smart%20Coding%20benchmark%20suite%20Proposal.md [13] 代码大模型测试示例: https://github.com/kubeedge/ianvs/tree/main/examples/smart_coding/smart_coding_learning_bench[14] 大模型云边协同推理设计文档: https://github.com/kubeedge/ianvs/blob/main/docs/proposals/algorithms/joint-inference/cloud-edge-collaboration-inference-for-llm.md [15] 大模型云边协同推理示例: https://github.com/kubeedge/ianvs/tree/main/examples/cloud-edge-collaborative-inference-for-llm[16] 大模型云边协同推理-投机解码算法设计文档: https://github.com/kubeedge/ianvs/blob/main/docs/proposals/algorithms/joint-inference/cloud-edge-speculative-decoding-for-llm.md[17] 大模型云边协同推理-投机解码示例:  https://github.com/kubeedge/ianvs/tree/main/examples/cloud-edge-collaborative-inference-for-llm[18] 多边协同推理示例: https://github.com/kubeedge/ianvs/blob/main/docs/proposals/algorithms/multi-edge-inference/Heterogeneous%20Multi-Edge%20Collaborative%20Neural%20Network%20Inference%20for%20High%20Mobility%20Scenarios.md[19] 多边协同推理示例: https://github.com/kubeedge/ianvs/tree/main/examples/MOT17/multiedge_inference_bench/pedestrian_tracking [20] 个性化大模型智能体设计文档: https://github.com/Frank-lilinjie/ianvs/blob/main/docs/proposals/algorithms/single-task-learning/Personalized%20LLM%20Agent%20based%20on%20KubeEdge-Ianvs%20Cloud-Edge%20Collaboration.md [21] 个性化大模型智能体示例: https://github.com/kubeedge/ianvs/tree/main/examples/llm-agent/singletask_learning_bench[22] 未知任务终身学习算法设计文档: https://github.com/kubeedge/ianvs/blob/main/docs/proposals/algorithms/lifelong-learning/Unknown_Task_Processing_Algorithm_based_on_Lifelong_Learning_of_Ianvs.md[23] 未知任务终身学习算法示例: https://github.com/kubeedge/ianvs/tree/main/examples/cityscapes/lifelong_learning_bench/unseen_task_processing-GANwithSelfTaughtLearning[24] KubeEdge-Ianvs v0.3.0 Release Note: cid:link_0【更多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_1Slack地址 : 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/
  • [技术干货] KubeEdge-Sedna v0.7.0 发布:联合推理引擎原生集成K8S HPA,系统稳定性全面升级
    本文以智慧工业园区为例,探讨了云边协同AI在案例实践过程发现的高峰期资源调度问题、系统维护时的“幽灵实例”、及底座版本问题。文章重点介绍北京时间 2025年4月20日,KubeEdge-Sedna 发布的 v0.7.0 版本。此版本为联合推理提供原生的HPA(Horizontal Pod Autoscaling)支持、联合推理与联邦学习控制器功能优化、底座架构升级。本文重点展示了 KubeEdge-Sedna v0.7.0 版本升级的主要内容,包括:联合推理支持 HPA:在人工智能快速发展的背景下,深度学习模型对计算资源的需求呈现显著波动,尤其在高峰期更为突出。为此,本次更新引入 HPA(Horizontal Pod Autoscaling)机制,该技术通过实时监控系统负载,动态调节推理实例数量,有效保障高并发场景下的系统稳定性。升级后的 HPA 不仅适配云边协同架构,还可无缝兼容 Sedna 历史版本,显著提升了系统扩展性和资源利用率。控制器优化与增强:本次更新也迎来了联合推理与联邦学习控制器的重要优化。针对以往版本中存在的任务删除不彻底、实例重建不及时等问题,本次更新通过引入 Deployment 管理机制,实现了推理任务的动态伸缩与生命周期管理。此外,联邦学习任务的控制器也得到了改进,在稳定性上有了重大提升。底座架构升级:本次更新同步将 Kubernetes 版本升级至 v1.30.7,Golang 版本升级至 v1.22.9。以及一系列问题修复,大幅提升 Sedna 整体性能与可靠性。一、背景:以智慧工业园区为例  截止2025年,KubeEdge Sedna 相关算法及系统已应用于20+案例中。在中国、印度多项大型智慧工业园区案例中,KubeEdge Sedna 使能的边缘 AI 安全帽检测系统持续保障工地安全生产。随着接入的工地和摄像头数量不断增加,系统面临着高峰期资源调度问题、系统维护时的“幽灵实例”问题、底座版本架构问题。问题1:高峰期的资源调度。在每天早班和晚班交接时段,工地出入口的人员流动量激增,边缘节点的安全帽检测请求量比平时增长300%,导致系统响应延迟增加50%,影响了对违规未戴安全帽行为的实时识别和预警。引入 HPA 机制后,系统能够根据 CPU 利用率自动扩展检测实例,将响应时间控制在可接受范围内;而在非高峰时段,系统又会自动缩减实例数量,整体节省了40%的计算资源成本。问题2:系统维护时的“幽灵实例”。在系统升级或维护期间,删除旧的安全帽检测任务后,系统中常常残留检测实例。这些“幽灵实例”会导致新检测任务无法正常创建,运维团队不得不花费大量时间手动清理残留资源。更棘手的是,如果误删了正在运行的检测实例,系统无法自动重建,导致部分区域的安全帽检测中断数小时,存在安全隐患。问题3:底座版本陈旧。随着部署时间过去,底座 Kubernetes 版本、Golang  版本均有功能升级,但 KubeEdge Sedna 仍在使用数年前的陈旧版本,存在性能和可靠性风险。  二、解决方案:智慧工业园区的AI升级之路  为了解决上述挑战,sedna v0.7.0 版本带来了三项关键升级方案1:引入了 HPA(Horizontal Pod Autoscaling)机制,能根据实际负载自动调节检测实例数量方案2:优化了控制器,实现了检测实例的自动清理和重建方案3:将 Kubernetes 版本升级至 v1.30.7,Golang 版本升级至 v1.22.9,并修复一系列问题新版本在各地工业园区应用中效果显著在人员流动高峰期,系统能够自动感知负载变化,及时增加检测实例,确保安全帽检测的实时性和准确性;在低峰期,系统自动释放多余资源,极大降低了运维成本。系统维护时,无需再手动清理残留实例,新检测任务可以顺利创建和运行,即使发生误删,系统也能自动重建检测实例,保障工地安全管理的连续性和可靠性。底座版本实现无缝升级,大幅提升 Sedna 整体性能与可靠性。👇🏻下面详细介绍实现方案:▍1. 联合推理原生支持 HPA 能力图1 HPA架构:以联合推理为例HPA 是 k8s (Kubernetes )原生提供的 pod 动态扩缩容能力,详细可参考 horizontal-pod-autoscale[1],其可以直接应用于 Deployment[2]或者 StatefulSet[3] 等 k8s 原生资源,为了直接复用 HPA 能力且与老版本 Sedna 兼容,本次更新我们将联合推理的 pod 实例采用 Deployment 进行管理 (详细内容在后续介绍),这样,我们就可以直接在联合推理范式的 API 中引入 HPA 的配置。联合推理范式的 API 设计可参见 附录1: HPA API 设计。其设计中,HPA 的配置与 k8s 的原生配置保持一致,用户可以直接参考 HPA 官方文档[1]进行配置。HPA 的配置支持 “同时在云边配置”、“只在云配置”、“只在边配置”以及“不配置”四种模式。当用户不配置时,将与 Sedna 历史版本使用完全一致。🔗具体方案设计以及实现请参考:proposal[4] 、implementation[5]🔗使用案例参考:附录2: HPA 配置示例▍2. 联合推理&联邦学习控制器优化图2 联合推理控制器优化联合推理方案设计:推理任务可以认为是一种无状态工作负载,因此可以利用 Kubernetes 的本地组件 Deployment 来实现 Pod 生命周期管理。通过使用 k8s 的 Informer 机制来监听推理任务的变化事件,然后通过调用addDeployment/deleteDeployment/updateDeployment等函数对 Deployment 资源进行对应的操作。此外,这一改变也可以直接对接上一章节提到的 HPA 能力,实现推理实例的动态伸缩。🔗更多细节请参考:proposal[6]、implementation[7]图3 联邦学习控制器优化联邦学习方案设计:在 Sedna 中,联邦学习属于一种训练任务,其会涉及到一些中间态的参数保存,其 pod 实例存在先后次序关系(即重新启动的 pod 实例可能需要访问上次失败 pod 的中间参数),因此其不再适合使用 Deployment 进行管理。所以对于联邦学习的控制器优化,依然采用原始方案,对其进行改进优化。🔗更多细节请参考:proposal[8] 、implementation[9]▍3. 底座架构升级本次升级将 Sedna 的 k8s 和 go 版本升级到了与 kubeedge 保持一致,并移除了大量 k8s 中已经废弃的函数和工具包。🔗更多详细信息请参考:Upgrade K8s and Go versions[10]本次升级也修复一系列问题,提高系统稳定性修复对象搜索范式中的级联删除问题:PR #443[11]修复联邦学习任务无法删除问题:PR #467[12]修复 helm chart 包中 crd 未更新问题:PR #472[13]修复 github CI 中的工作流版本问题:PR #475[14] 三、Release Note  如果读者对于本次版本发布的更多细节感兴趣,欢迎查阅 Sedna v0.7.0 Release Note[15]。后续 KubeEdge SIG AI 将发布系列文章,陆续具体介绍新版本升级的特性,欢迎各位读者继续关注社区动态。相关链接:[1] Pod 水平自动扩缩: https://kubernetes.io/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale/[2] Deployments: https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/deployment/[3] StatefulSet: https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/statefulset/[4] joint-inference-hpa.md: https://github.com/kubeedge/sedna/blob/main/docs/proposals/joint-inference-hpa.md[5] feature: hpa for jointinference : https://github.com/kubeedge/sedna/pull/465 [6] sedna-controller-enhancement.md: https://github.com/kubeedge/sedna/blob/main/docs/proposals/sedna-controller-enhancement.md[7] JointInferenceService controller enhancement: https://github.com/kubeedge/sedna/pull/445[8] sedna-controller-enhancement.md: https://github.com/kubeedge/sedna/blob/main/docs/proposals/sedna-controller-enhancement.md [9] Sedna FederatedLearning controller enhancement: https://github.com/kubeedge/sedna/pull/446 [10] Upgrade K8s and Go versions: https://github.com/kubeedge/sedna/pull/462 [11] fix objectsearch bug of joint delete: https://github.com/kubeedge/sedna/pull/443 [12] fix FederatedLearningJob delete error: https://github.com/kubeedge/sedna/pull/467 [13] fix helm crd can not generete error: https://github.com/kubeedge/sedna/pull/472 [14] update workfow actions from v2 to v4: https://github.com/kubeedge/sedna/pull/475 [15] Sedna v0.7.0 release: https://github.com/kubeedge/sedna/releases/tag/v0.7.0 附录1:HPA API设计// HPA describes the desired functionality of the HorizontalPodAutoscaler.type HPA struct { // +optional MinReplicas *int32`json:"minReplicas,omitempty"` MaxReplicas int32`json:"maxReplicas"` // +optional Metrics []autoscalingv2.MetricSpec `json:"metrics,omitempty"` // +optional Behavior *autoscalingv2.HorizontalPodAutoscalerBehavior `json:"behavior,omitempty"`}// EdgeWorker describes the data a edge worker should havetype EdgeWorker struct { Model SmallModel `json:"model"` HardExampleMining HardExampleMining `json:"hardExampleMining"` Template v1.PodTemplateSpec `json:"template"` // HPA describes the desired functionality of the HorizontalPodAutoscaler. // +optional HPA *HPA `json:"hpa"`}// CloudWorker describes the data a cloud worker should havetype CloudWorker struct { Model BigModel `json:"model"` Template v1.PodTemplateSpec `json:"template"` // HPA describes the desired functionality of the HorizontalPodAutoscaler. // +optional HPA *HPA `json:"hpa"`}附录2:HPA 配置示例apiVersion: sedna.io/v1alpha1kind: JointInferenceServicemetadata: name: helmet-detection-inference-example namespace: defaultspec: edgeWorker: hpa: maxReplicas: 2 metrics: - resource: name: cpu target: averageUtilization: 50 type: Utilization type: Resource minReplicas: 1 model: name: "helmet-detection-inference-little-model" hardExampleMining: name: "IBT" parameters: - key: "threshold_img" value: "0.9" - key: "threshold_box" value: "0.9" template: spec: nodeName: $Edge-NodeName hostNetwork: true dnsPolicy: ClusterFirstWithHostNet containers: - image: kubeedge/sedna-example-joint-inference-helmet-detection-little:v0.5.0 imagePullPolicy: IfNotPresent name: little-model env: # user defined environments - name: input_shape value: "416,736" - name: "video_url" value: "rtsp://localhost/video" - name: "all_examples_inference_output" value: "/data/output" - name: "hard_example_cloud_inference_output" value: "/data/hard_example_cloud_inference_output" - name: "hard_example_edge_inference_output" value: "/data/hard_example_edge_inference_output" resources: # user defined resources requests: memory: 64M cpu: 50m limits: memory: 2Gi cpu: 500m volumeMounts: - name: outputdir mountPath: /data/ volumes: # user defined volumes - name: outputdir hostPath: # user must create the directory in host path: /joint_inference/output type: Directory cloudWorker: hpa: maxReplicas: 5 metrics: - resource: name: cpu target: averageUtilization: 20 type: Utilization type: Resource minReplicas: 1 model: name: "helmet-detection-inference-big-model" template: spec: nodeName: $Cloud-NodeName dnsPolicy: ClusterFirstWithHostNet containers: - image: kubeedge/sedna-example-joint-inference-helmet-detection-big:v0.5.0 name: big-model imagePullPolicy: IfNotPresent env: # user defined environments - name: "input_shape" value: "544,544" resources: # user defined resources requests: cpu: 1024m memory: 2Gi limits: cpu: 1024m memory: 2Gi附录3:HPA 部署效果[root@master-01 ~]# kubectl get hpa -wNAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGEhpa-helmet-detection-inference-example-deployment-cloud Deployment/helmet-detection-inference-example-deployment-cloud 37%/20% 1 5 3 92shpa-helmet-detection-inference-example-deployment-edge Deployment/helmet-detection-inference-example-deployment-edge 348%/50% 1 2 2 92shpa-helmet-detection-inference-example-deployment-cloud Deployment/helmet-detection-inference-example-deployment-cloud 37%/20% 1 5 4 106shpa-helmet-detection-inference-example-deployment-edge Deployment/helmet-detection-inference-example-deployment-edge 535%/50% 1 2 2 106shpa-helmet-detection-inference-example-deployment-cloud Deployment/helmet-detection-inference-example-deployment-cloud 18%/20% 1 5 4 2m1shpa-helmet-detection-inference-example-deployment-edge Deployment/helmet-detection-inference-example-deployment-edge 769%/50% 1 2 2 2m1shpa-helmet-detection-inference-example-deployment-cloud Deployment/helmet-detection-inference-example-deployment-cloud 12%/20% 1 5 4 2m16s[root@master-01 jointinference]# kubectl get poNAME READY STATUS RESTARTS AGEhelmet-detection-inference-example-deployment-cloud-7dffd47c6fl 1/1 Running 0 4m34shelmet-detection-inference-example-deployment-cloud-7dffd4dpnnh 1/1 Running 0 2m49shelmet-detection-inference-example-deployment-cloud-7dffd4f4dtw 1/1 Running 0 4m19shelmet-detection-inference-example-deployment-cloud-7dffd4kcvwd 1/1 Running 0 5m20shelmet-detection-inference-example-deployment-cloud-7dffd4shk86 1/1 Running 0 5m50shelmet-detection-inference-example-deployment-edge-7b6575c52s7k 1/1 Running 0 5m50shelmet-detection-inference-example-deployment-edge-7b6575c59g48 1/1 Running 0 5m20s【更多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开源之夏Karmada社区6项课题邀您共创
    开源之夏是由中国科学院软件研究所“开源软件供应链点亮计划”发起并长期支持的一项暑期开源活动,旨在鼓励在校学生积极参与开源软件的开发维护,培养和发掘更多优秀的开发者,促进优秀开源软件社区的蓬勃发展,助力开源软件供应链建设。学生通过远程线上协作方式,通过社区资深导师指导,参与到开源社区各组织项目开发中,收获证书及8000/12000元奖金。活动官网:https://summer-ospp.ac.cn/云原生多云容器引擎Karmada社区今年为同学们带来6项课题,欢迎高校同学选报,报名于5月9日启动,截止时间6月9日18:00 (UTC+8)。 Karmada 社区介绍 Karmada (https://github.com/karmada-io)是业界首个多云多集群容器编排项目,云原生计算基金会(CNCF)孵化级项目。Karmada 社区由华为云、工商银行、小红书、中国一汽等八家企业联合发起,于2021年4月正式开源。Karmada 的贡献者来自世界各地,覆盖全球22个国家和地区的60多家组织。截至目前,项目在开源软件项目托管平台 GitHub 已收获超过4.8k Star。作为开放的多云多集群容器编排引擎,Karmada 旨在帮助用户在多云环境下部署和运维业务应用。凭借兼容 Kubernetes 原生 API 的能力,Karmada 可以平滑迁移单集群工作负载,并且仍可保持与 Kubernetes 周边生态工具链协同。 Karmada社区开源之夏2025课题 课题一:Karmada 禁止同一资源被多个资源跟随分发项目编码:255c40195项目难度:进阶/Advanced课题导师:XiShanYongYe-Chang导师联系邮箱:changzhen5@huawei.com项目简述:Karmada (Kubernetes Armada) 是一个 Kubernetes 管理系统,它使您能够在多个 Kubernetes 集群和云平台中运行云原生应用程序,而无需更改应用程序。通过使用 Kubernetes 原生 API 并提供高级调度功能,Karmada 实现了真正的开放式、多云 Kubernetes。Karmada 支持资源的跟随分发,例如 configmap 资源不需要创建额外的 PropagationPolicy 进行分发,可以直接跟随 deployment 资源进行分发。根据用户的使用反馈,有的用户不会涉及到单个资源被多个资源依赖分布的场景,但也有的用户会使用,比如共享同一个秘籍拉取镜像。在 Karmada 中,如果允许同一个资源被多个资源跟随分发,会给用户带来一定的风险。因此我们需要对这些风险进行分析,来思考是否可以通过某种方式来化解,或者明确禁止用户这样做。Track issue: https://github.com/karmada-io/karmada/issues/6000项目链接:https://summer-ospp.ac.cn/org/prodetail/255c40195 (请在PC端打开,下同)课题二:Karmada cluster failover 优化项目编码:255c40205项目难度:基础/Basic项目社区导师:whitewindmills导师联系邮箱:jayfantasyhjh@gmail.com项目简述:Karmada (Kubernetes Armada) 是一个 Kubernetes 管理系统,它使您能够在多个 Kubernetes 集群和云平台中运行云原生应用程序,而无需更改应用程序。通过使用 Kubernetes 原生 API 并提供高级调度功能,Karmada 实现了真正的开放式、多云 Kubernetes。Cluster Failover 特性旨在显著提升多集群环境下业务的可用性。作为一项关键且功能丰富的特性,我们始终高度重视用户反馈,并持续对其进行迭代优化,致力于为用户打造更卓越的使用体验。本次项目我们计划对 Failover 特性进行了一次大规模的全面升级。 在该项目中,我们计划对 Failover 特性的架构进行了深度调整。为集群故障机制添加了明确的约束条件,从而能够统一管控因集群故障引发的资源迁移行为,确保迁移过程更加规范有序。在可配置性方面,我们从系统配置和策略 API 定义等多个维度进行了优化,为用户提供了更广泛的自定义空间,能够满足多样化的业务需求。Track issue: https://github.com/karmada-io/karmada/issues/6317项目链接:https://summer-ospp.ac.cn/org/prodetail/255c40205课题三:Karmadactl init 支持设置组件启动参数项目编码:255c40243项目难度:基础项目社区导师:张壮导师联系邮箱:m17799853869@163.com项目简述:Karmada (Kubernetes Armada) 是一个 Kubernetes 管理系统,它使您能够在多个 Kubernetes 集群和云平台中运行云原生应用程序,而无需更改应用程序。通过使用 Kubernetes 原生 API 并提供高级调度功能,Karmada 实现了真正的开放式、多云 Kubernetes。Karmadactl init 用于用户自定义安装 Karmada 控制面组件。组件启动参数是指在启动软件或服务时传递给可执行文件的参数,这些参数用于控制组件的行为、配置运行环境或指定特定的操作模式。它们可以影响从日志级别、监听端口到性能调优选项等多个方面。具体的作用取决于每个参数的设计目的和使用场景。因此,我们计划在命令 karmadactl init 中引入支持设置组件启动参数的能力,提高用户可自定义程度。项目链接:https://summer-ospp.ac.cn/org/prodetail/255c40243课题四:Karmada 官方文档体系优化与国际化建设项目编码:255c40339项目难度:基础项目社区导师:任洪彩导师联系邮箱:qdurenhongcai@163.com项目简述:Karmada (Kubernetes Armada) 是一个 Kubernetes 管理系统,它使您能够在多个 Kubernetes 集群和云平台中运行云原生应用程序,而无需更改应用程序。通过使用 Kubernetes 原生 API 并提供高级调度功能,Karmada 实现了真正的开放式、多云 Kubernetes。作为 CNCF 孵化的多云编排核心项目,Karmada 的官方文档体系直接影响着全球开发者对多云集群管理技术的采用效率与社区贡献意愿。本项目旨在构建符合 CNCF 标准的文档体系,通过重构知识架构、补充场景化指南、实现中英实时同步,并引入交互式工具链,系统性降低多云编排技术的使用门槛。项目链接:https://summer-ospp.ac.cn/org/prodetail/255c40339课题五:为 Karmada Dashboard 引入自动化测试项目编码:255c40413项目难度:基础项目社区导师:船长导师联系邮箱:samzong.lu@gmail.com项目简述:Karmada (Kubernetes Armada) 是一个 Kubernetes 管理系统,它使您能够在多个 Kubernetes 集群和云平台中运行云原生应用程序,而无需更改应用程序。通过使用 Kubernetes 原生 API 并提供高级调度功能,Karmada 实现了真正的开放式、多云 Kubernetes。Karmada Dashboard 已经发布第一个正式的版本。为了保证Karmada Dashboard 可以在快速迭代的过程中保证功能的稳定性,因此希望可以为Karmada Dashboard引入自动化测试的能力,结合CI能力,保证每次提交代码时运行自动化测试用例,保证Karmada Dashboard 功能的稳定性。 由于Karmada Dashboard是一个全栈项目(包含了go后端、react前端、npm组件包),设计自动化测试需要了解的技术栈相对较多。项目链接:https://summer-ospp.ac.cn/org/prodetail/255c40413课题六:在Karmada Dashboard中集成Karmada-MCP-Server项目编码:255c40415项目难度:基础项目社区导师:warjiang导师联系邮箱:1096409085@qq.com项目简述:Karmada (Kubernetes Armada) 是一个 Kubernetes 管理系统,它使您能够在多个 Kubernetes 集群和云平台中运行云原生应用程序,而无需更改应用程序。通过使用 Kubernetes 原生 API 并提供高级调度功能,Karmada 实现了真正的开放式、多云 Kubernetes。自OpenAI推出大模型以来,各个领域都在尝试落地大模型应用。MCP协议是Anthropic公司推出的一个标准化协议,旨在通过标准化的方式将各个垂直领域的能力快速、标准化的接入到现有的工作流中。Karmada 社区也尝试探索大模型落地的方案,比如结合MCP协议开发了Karmada-MCP-Server,在支持MCP协议的客户端中通过自然语言完成多集群管理的工作。但是现有的使用方式用户做诸多配置,相对复杂,同时考虑到MCP是标准协议。 因此我们希望可以在Karmada Dashboard中整合Karmada-MCP-Server,通过ChatUI的形式为用户提供开箱即用的大模型能力,提升集群管理效率。项目链接:https://summer-ospp.ac.cn/org/prodetail/255c40415  如何报名开源之夏Karmada课题?报名对象本活动面向年满 18 周岁的高校在校学生。在9月30日开发结束之前,学生需保持在校学生状态。若已收到研究生或博士生录取通知,可提供录取通知书及相关说明材料。中国籍学生参与活动时需提供有效期内的身份证、学生证、教育部学籍在线验证报告(学信网)或在读证明。外籍学生参与活动时需提供护照,同时提供录取通知书、有效期内的学生证、在读证明等文件。学生报名时间学生可在系统(https://summer-ospp.ac.cn/)注册账号并填写个人资料提交审核。资料审核通过的学生 5月9日 起可在系统提交项目申请书,学生课题申请截止时间为6月9日18:00。学生可以收获什么?结识开源界小伙伴和技术大牛获得社区导师的专业指导,与开源项目开发者深度交流丰富项目实践经验,提升项目开发技能,为工作履历增光添彩为学习方向提供参考,为职业发展积累人脉通过结项考核的学生将获得结项奖金和结项证书(基础难度税前8000元RMB,进阶难度税前12000元RMB),更有机会获选优秀学生▍Karmada社区联系对课题感兴趣的同学,请直接📧邮件对应课题导师,更快了解、锁定课题,您也可以添加社区小助手微信,进入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)
  • [公告] 「哔哩哔哩」正式加入 Karmada 用户组!携手社区共建多集群生态
    Karmada 社区非常高兴地宣布哔哩哔哩正式加入Karmada 用户组[1](Karmada Adopter Group),成为该开源社区的重要成员。作为云原生计算基金会(CNCF)旗下的开源项目,Karmada 致力于为用户提供强大的多集群管理和调度能力,帮助企业在复杂的分布式环境中实现高效的应用部署和管理。哔哩哔哩的加入将进一步丰富 Karmada 社区的生态,并为项目的持续创新注入新的动力。 关于哔哩哔哩 哔哩哔哩[2],简称“B站”,一个有用有趣的综合性视频社区,被用户们亲切地称为“百科全书式的网站、没有围墙的图书馆,成长道路上的加油站,创作者的舞台”。截止2024年第四季度,B站日均活跃用户达1.03亿,月活跃用户达3.4亿。围绕用户、创作者和内容,B站构建了一个源源不断产生优质内容的生态系统。中国最优秀的专业创作者都聚集在B站创作内容,涵盖生活、游戏、时尚、知识、音乐等数千个品类和圈层,引领着流行文化的风潮,成为中文互联网极其独特的存在。在此基础之上,B站提供了移动游戏、直播、付费内容、广告、漫画、电商等商业化产品服务,并对电竞、虚拟偶像等前沿领域展开战略布局。公司于2018年3月登陆美国纳斯达克,并于2021年3月在港交所二次上市。  关于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] 哔哩哔哩: https://www.bilibili.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.io👉Karmada 是CNCF 首个多云多集群容器编排项目(孵化级),旨在帮助用户像使用单个集群一样轻松管理跨云多集群,让基于 Karmada 的多云方案无缝融入云原生技术生态。社区吸引了来自华为、道客、浙江大学、腾讯、中国电子云、滴滴、Zendesk、携程等100多家公司的全球贡献者,广泛分布于20+国家和地区。Karmada 现已在华为云、道客、兴业数金、中国移动、中国联通、携程、360集团、新浪、中通快递等众多企业单位生产应用,为企业提供从单集群到多云架构的平滑演进方案。Karmada官网:https://karmada.io/项目地址:https://github.com/karmada-io/karmadaSlack地址:https://slack.cncf.io/(#karmada)
  • [热门活动] 开源之夏2025重磅来袭!KubeEdge社区18项课题报名启动
    开源之夏介绍开源之夏是由中国科学院软件研究所“开源软件供应链点亮计划”发起并长期支持的一项暑期开源活动,旨在鼓励在校学生积极参与开源软件的开发维护,培养和发掘更多优秀的开发者,促进优秀开源软件社区的蓬勃发展,助力开源软件供应链建设。学生通过远程线上协作方式,通过社区资深导师指导,参与到开源社区各组织项目开发中,收获证书及8000/12000元奖金。活动官网:https://summer-ospp.ac.cn/开源之夏学生报名将于5月9日正式开启。KubeEdge 云原生边缘计算社区已连续6年参与开源之夏,在本届开源之夏共带来18个精选课题,包括AI大模型、机器学习、深度学习、工业物联网、系统研发与集成等多个领域,由来自高校、产业等资深学者、产业巨擘与技术领英组成的导师带队,引领同学们迈向顶尖开发者之路。历届开源之夏 KubeEdge 社区课题聚焦行业前沿方向,为学生职业生涯增添浓墨重彩的一笔,KubeEdge 学生已连续多年入选组委会官方优秀学生。为帮助学生更好地了解与选报课题,KubeEdge 社区将于5月14日、5月15日开展课题线上宣讲会(详见下文),同学们不可错过。▍KubeEdge云原生边缘计算社区KubeEdge(https://github.com/kubeedge)是业界首个云原生边缘计算框架、云原生计算基金会(CNCF)唯一毕业级边缘计算开源项目。KubeEdge 连接云原生和边缘计算生态,聚焦于提供一致的云边资源协同、数据协同、智能协同和应用协同体验,为边缘计算领域的应用提供更好的支持和解决方案,在全球已拥有1800+贡献者和120+贡献组织,在 GitHub 获得 8.1k+Stars 和 2.3k+Forks。KubeEdge 社区持续开拓创新,目前已完成业界最大规模云原生边云协同高速公路项目(统一管理10万边缘节点/50万边缘应用)、业界首个云原生星地协同卫星、业界首个云原生车云协同汽车、业界首个云原生油田项目,开源业界首个分布式协同 AI 框架 Sedna 及业界首个边云协同终身学习范式。▍KubeEdge开源之夏2025课题项目1:KubeEdge设备管理实践案例优化项目编号:2598a0305项目难度:基础/Basic导师联系:王彬丞 wangbincheng4@huawei.com项目简述:目前 KubeEdge 在边缘 IoT 设备管理领域提出了基于物模型的设备管理 API,并构建了 mapper 开发框架 mapper-framework,实现 IoT 设备的云原生化管理。随着 KubeEdge Device IoT 能力日趋成熟,需要构建针对最新版本的最佳实践案例,并对旧版本的案例进行迭代优化,为用户使用提供参考。项目链接:https://summer-ospp.ac.cn/org/prodetail/2598a0305 (请在PC端打开,下同)项目2:面向工业制造的具身智能基准测试套件项目编号:2598a0349项目难度:进阶/Advanced导师联系:郑子木 zimu.zheng@huawei.com项目简述:随着工业制造智能化进程加速以及工业机器人、柔性产线、检测装备持续升级,云边协同成为支撑具身智能系统在复杂生产场景中落地的关键技术。当前工业领域对具身智能服务的需求已从单一任务执行向高精度感知决策、实时动态适应性、跨设备协同控制等方向演进,但通用具身智能基准测试普遍缺乏对工业场景具身特性的针对性评价,本项目基于 KubeEdge-Ianvs 协同人工智能基准测试框架,配套工业场景测试数据集、测试环境和性能指标,构建面向工业制造的行业级具身智能测试能力。项目链接:https://summer-ospp.ac.cn/org/prodetail/2598a0349项目3:支持在Windows OS上使用KubeEdge部署工具keadm项目编号:2598a0315项目难度:基础/Basic导师联系:胡炜 wei.hu@daocloud.io项目简述:keadm 是 KubeEdge 的安装部署工具,可以使用 keadm join/reset/upgrade 等子命令对 KubeEdge 边缘组件 EdgeCore 进行安装、重置、升级等操作。在工业场景中有很多设备使用 Windows 操作系统,而且许多企业级应用(如 .NET Framework、IIS、SQL Server等)依赖 Windows 生态,无法直接迁移到  Linux。为了让企业能在统一平台上管理混合操作系统,Kubernetes 和 Containerd 都已支持 Windows,EdgeCore 也已经能在 Windows 上正常运行及工作。然而由于 keadm 工具依旧没有适配 windows,目前 EdgeCore 在 Windows 上只能手动使用二进制包启动,运维管理存在着很多问题。本课题需要重新设计如何用 keadm 工具和边缘子命令操作 EdgeCore 在 Windows 设备上的部署升级等,进行生命周期管理。项目链接:https://summer-ospp.ac.cn/org/prodetail/2598a0315项目4:基于c语言实现MapperFramework项目编号:2598a0320项目难度:进阶/Advanced导师联系:杨志佳 2938893385@qq.com项目简述:KubeEdge 的 Mapper-Framework 提供了全新的 Mapper 自动生成框架,集成了 DMI 设备管理面与数据面能力。目前 KubeEdge 多语言 Mapper-Framework 已实现了 golang 和 java 版,然而在 IoT 领域,边缘端侧设备驱动大多是基于C语言编写的,因此在本课题中,我们希望能够给予C语言实现 Mapper-Framework,为用户提供基于C语言的设备驱动 Mapper,提升用户开发效率。项目链接:https://summer-ospp.ac.cn/org/prodetail/2598a0320项目5:从 kubeedge-ianvs 迁移联合推理大模型 example 至 kubeedge-sedna项目编号:2598a0311项目难度:基础/Basic导师联系:唐明 ming.tang@daocloud.io项目简述:Sedna 是一个通用的云边协同 AI 平台,能够便捷地在云端和边缘部署、管理各类 AI 模型。当前,Sedna 已支持多种 AI 协同范式,包括联合推理、联邦学习、增量学习和终生学习,并在多个行业场景中实现了落地应用。我们已针对传统判别式模型,提供了丰富的协同范式案例,帮助用户快速搭建符合自身需求的应用。随着案例数量的增加,用户对模型性能评估的需求也日益增长。为此,我们推出了 kubeedge-ianvs 基准测试平台,为模型在部署到 Sedna 之前提供标准化的测试流程,确保其性能满足生产环境要求。近年来,大语言模型(LLM)在云边协同场景下的应用逐渐增多,ianvs 项目中已孵化出多个优秀的云边协同大语言模型案例。然而,Sedna 平台目前尚未提供相关的大语言模型应用案例,导致有此类需求的用户缺乏参考和借鉴。因此,本项目旨在将 kubeedge-ianvs 中优秀的联合推理大语言模型案例迁移至 Sedna 平台,丰富 Sedna 的应用案例库,为开发云边协同大语言模型的用户提供实践参考。同时,在迁移过程中,我们将梳理和总结案例迁移中遇到的问题,为后续实现案例自动化迁移和 Sedna 框架的持续优化提供依据和建议。项目链接:https://summer-ospp.ac.cn/org/prodetail/2598a0311项目6:基于现实设备产品的边缘设备模型设计项目编号:2598a0334项目难度:进阶/Advanced导师联系:jiawei  jiawei.liu@daocloud.io项目简述:当前 KubeEdge 对设备模型的定义比较简单,起到的实质作用并不大,而且其设计在使用时会让使用者产生困扰。在传统 IOT 中,设备会被设计成:物模型、产品、设备实例,由于历史原因,现在拆成3类对象的成本会很大,而且这么细粒度的抽象意义也不是很大,因此我们将模型定义成现实设备产品的概念(物模型+产品),即用于描述一种设备产品的规格、连接协议、属性获取方式等,这样设备的实例就可以共享这些配置,无非连接的地址对于不同的设备配置不一样。这样的设计,能一定程度的复用配置信息,并且定位更加的清晰。项目链接:https://summer-ospp.ac.cn/org/prodetail/2598a0334项目7:基于KubeEdge-Ianvs的大模型联邦微调算法项目编号:2598a0326项目难度:进阶/Advanced导师联系:胡创 hchuchuang@gmail.com项目简述:随着大语言模型(LLM)在医疗、金融、政务等多个隐私敏感行业的广泛应用,利用本地数据对 LLM 进行微调以满足领域定制化需求成为趋势。传统的联邦学习方法在面对 LLM 的超大参数量与计算成本时显得力不从心。目前 KubeEdge-Ianvs 及 KubeEdge-Sedna 已支持协同推理和协同训练方式,但并未支持大模型联邦微调。为此,本项目拟在 KubeEdge-Ianvs 框架下构建一个联邦学习范式流程以及支持参数高效微调的大模型联邦微调算法。未来可能利用 KubeEdge-Sedna 的边缘节点调度、资源管理能力,实现低通信、低计算、高适配性的大模型联邦学习流程。项目链接:https://summer-ospp.ac.cn/org/prodetail/2598a0326项目8:基于KubeEdge-Ianvs的多LLM云边路由范式:面向具身智能应用项目编号:2598a0350项目难度:进阶/Advanced导师联系:胡时京 sjhu21@m.fudan.edu.cn项目简述:当前,大模型研究面临算力垄断、训练成本高企和技术路径单一等挑战,“路由 LLM(Routing LLM)”范式为突破这些瓶颈提供了新思路。该范式通过智能调度和协同多个开源(及闭源)小模型,以“组合创新”替代传统“规模竞赛”,具备异构兼容、多目标优化和灵活部署等多重优势。例如,它能够兼容 GPT-4、Llama 等多类模型,实现性能、成本和风险的动态权衡,并可按需快速定制针对如代码生成、医疗问答等场景的解决方案,而无需从头训练大模型。KubeEdge-Ianvs 目前已支持云边协同推理,可视为“多 LLM 云边路由”的一种雏形,未来在云+边多模型的智能协同必将成为 LLM 性能优化的重要趋势。本项目将基于 KubeEdge-Ianvs,进一步拓展和实现多 LLM 云边路由能力,打造支持多模型注册、调度、分发与动态路由的开源平台,为云边智能推理和产业实际应用提供创新高效的技术路径。项目链接:https://summer-ospp.ac.cn/org/prodetail/2598a0350项目9:基于KubeEdge-Ianvs的VLA微调数据配比优化算法项目编号:2598a0359项目难度:进阶/Advanced导师联系:苏敬勇 sujingyong@hit.edu.cn项目简述:视觉-语言-动作(Vision-Language-Action, VLA)模型在机器人操作和具身智能等领域获得广泛应用,其中 VLA 模型在云侧训练、边侧推理是具身智能领域的一种常见范式。但是如何在训练过程中合理配置多源异构数据以提升模型在复杂任务中的泛化能力,成为亟需解决的问题。相比计算机视觉与自然语言处理领域,VLA 数据配比策略的研究仍然薄弱,当前多采用静态经验权重或均匀混合,难以适应不同数据子域对特定下游任务的差异化贡献。尽管已有如 OpenVLA、Re-Mix 等在数据加权方面的探索,复杂多模态 VLA 任务下的数据配比仍缺乏系统性方案。为此,本项目拟依托 KubeEdge-Ianvs 分布式协同 AI 基准测试框架,构建一套面向 VLA 任务的数据配比优化流程,结合 Ianvs 提供的仿真、超参搜索、评测报告等工具,探索多源数据在具身智能训练中的合理配比,推动 VLA 模型在机器人与具身智能应用中的泛化能力与训练效率的提升。项目链接:https://summer-ospp.ac.cn/org/prodetail/2598a0359项目10:物理一致可交互室内仿真场景生成:基于KubeEdge-Ianvs实现项目编号:2598a0424项目难度:进阶/Advanced导师联系:蒋晨阳 787773295@qq.com项目简述:边缘计算业务下的具身智能场景生成往往在云侧协助具身智能模型训练,训练所得的具身智能模型部署到边侧推理。目前已有诸多研究致力于室内场景生成问题,如 ProcTHOR、PhyScene、HOLODECK 等,通过自动构建三维室内环境,广泛应用于具身智能仿真任务。然而,这些仿真平台在物理交互属性上与真实世界存在显著差距,缺乏对物体形变反馈、力觉反馈、触觉反馈、温度反馈等多维物理特性的建模。例如,当机械臂接触窗帘时,窗帘应展现出柔性形变、相应的反馈力、触觉信号乃至热传导特性,这些在当前仿真环境中难以真实还原。如何在生成高保真物理场景的同时,赋予场景内物体与现实世界一致的可交互性与物理属性,仍是亟需解决的关键问题。为此,本项目计划基于 KubeEdge-Ianvs 分布式协同基准测试框架,构建一套物理一致的可交互室内仿真场景生成流程。借助 Ianvs 提供的仿真控制、超参搜索、性能评测等工具,系统性评估和优化仿真场景中的物理属性建模效果,助力合成高质量具身智能训练数据,提升模型在复杂交互任务中的泛化能力,加速具身智能系统的训练与迭代。项目链接:https://summer-ospp.ac.cn/org/prodetail/2598a0424项目11:基于KubeEdge-Ianvs的政务智能体基准测试项目编号:2598a0360项目难度:进阶/Advanced导师联系:陈孟卓 icyfeather@foxmail.com项目简述:随着云边协同大模型技术的快速发展,其在政务场景中的应用潜力日益凸显。政务服务的智能化升级涉及政府内部协同、公众服务及企业服务三大核心场景,亟需通过大模型技术提升效率与服务质量。然而,政务场景具有高度的专业性、规范性和安全性要求,现有的大模型评测体系缺乏针对政务垂直领域的标准化评估方法,导致技术落地面临准确性、合规性及场景适配性等挑战。因此,本项目旨在基于 KubeEdge-Ianvs 分布式协同框架,构建面向政务场景的智能体评测 Pipeline 与 Benchmark,为政务智能化提供可量化、可复用的能力评估工具,推动大模型技术在政务服务、政府办公、城市治理等典型场景中的安全高效应用。项目链接:https://summer-ospp.ac.cn/org/prodetail/2598a0360项目12:基于KubeEdge-Ianvs云边协同推理的大模型隐私保护算法项目编号:2598a0388项目难度:进阶/Advanced导师联系:沈家星 jiaxingshen@ln.edu.hk项目简述:随着大型语言模型(LLM)在各行业的广泛应用,用户隐私保护成为关键挑战。传统云端 LLM 部署要求用户将敏感提示上传至远程服务器,造成严重隐私风险。本项目旨在基于 KubeEdge-Ianvs 的云边协同推理框架,开发一个大模型隐私保护算法,在边缘侧对敏感提示进行不可逆变换处理,确保即使使用最先进的嵌入重构攻击也无法恢复原始数据。项目链接:https://summer-ospp.ac.cn/org/prodetail/2598a0388项目13:KubeEdge Dashboard前端组件升级优化项目编号:2598a0405项目难度:基础导师联系:Hongbing hongbing.zhang@daocloud.io项目简述:升级优化 dashboard 前端组件及性能,重点优化 ProTable、TableView 等公用表单组件。另外可考虑引入 mui 新加入的 Dashboard Layout 等组件。项目链接:https://summer-ospp.ac.cn/org/prodetail/2598a0405项目14:优化KubeEdge Dashboard数据处理逻辑,引入新特性项目编号:2598a0406项目难度:基础/Basic导师联系:Chen Su ghosind@gmail.com项目简述:在现有 KubeEdge Dashboard 的基础上,优化其数据处理逻辑。建立数据处理中间层,用于对数据进行预处理,并引入数据筛选、排序、分页等新功能,用以提升用户前端性能及用户体验。项目链接:https://summer-ospp.ac.cn/org/prodetail/2598a0406项目15:基于 KubeEdge 的云边视频流通信机制扩展项目编号:2598a0410项目难度:进阶导师联系:沈立炜 shenliwei@fudan.edu.cn项目简述:随着远程感知、视觉识别等边缘智能场景的持续发展,对于云边之间实时视频流传输的支持需求日益增长。然而,KubeEdge 现有的云边通信主要面向日志和控制信号的传输,缺乏对流式数据(如实时视频流)的支持,限制了以视觉为核心的应用在复杂网络环境下的落地与拓展。本项目将在 KubeEdge 框架基础上扩展新的通信机制以支持边缘节点稳定向云端推送视频流,并围绕流式数据在典型边缘场景中的传输问题,探索更具弹性和资源效率的通信方式。项目将关注在多源请求环境下的链路共享、传输稳定性和连接管理问题,使得 KubeEdge 具备视觉数据流通信能力,从而进一步支撑船岸远程监控等应用场景。项目链接:https://summer-ospp.ac.cn/org/prodetail/2598a0410项目16:基于 KubeEdge 的主题化设备数据发布/订阅框架项目编号:2598a0411项目难度:进阶导师联系:崔云娜 21110240061@m.fudan.edu.cn项目简述:在工业物联网场景中,设备数据的实时发布与灵活订阅是支撑 AI 分析(如预测性维护、工艺优化)和精细化运维(如故障告警响应、能效监控)的关键基础。通过主题化数据分发和动态路由策略,可精准区分高优先级事件(如设备异常)与低优先级属性数据(如能耗统计),避免混合传输导致的解析负担和响应延迟。统一的发布/订阅机制能简化多协议设备接入、提升边缘-云协同效率,为智能化应用提供低时延、高可靠的数据供给,同时满足动态扩容场景下的灵活扩展需求。为此,本项目旨在设计并实现一套基于 KubeEdge 的统一主题化设备数据发布/订阅系统,通过定义层级化主题模型(如 sensor/temperature, camera/objectDetected等)),实现动态订阅机制与边缘-云协同路由策略,支持应用按主题灵活订阅数据、事件数据(高优先级实时推送)与属性数据(低优先级批量传输)的分类处理,最终与 KubeEdge 的 DeviceTwin 等原生组件集成,提升工业物联网场景中数据分发的实时性、灵活性与可扩展性。项目链接:https://summer-ospp.ac.cn/org/prodetail/2598a0411项目17:KubeEdge Dashboard UI优化与多语言(中文)支持项目编号:2598a0414项目难度:基础导师联系:chuanhao 15221580643@163.com 项目简述:全面优化 KubeEdge Dashboard 的 UI 体验,统一界面风格、提升交互友好性,并引入中文语言包支持。针对页面结构、交互逻辑、表单体验等方面进行逐步改进,使其更加贴合用户使用习惯。同时提供国际化方案基础框架,未来可拓展至更多语言。项目链接:https://summer-ospp.ac.cn/org/prodetail/2598a0414项目18:面向隐私-效用评测的云边协同大模型仿真环境项目编号:2598a0389项目难度:进阶/Advanced导师联系:江山 jiangsh73@mail.sysu.edu.cn项目简述:用户隐私保护是边侧大模型应用一大关键需求,这是因为传统云端 LLM 部署要求用户将敏感提示上传至远程服务器,造成严重隐私风险。然而,纯边缘部署的轻量级模型性能有限。本项目旨在基于 KubeEdge-Ianvs 的云边协同推理过程,对隐私保护和模型效用进行量化权衡,并提供仿真方法。 项目链接:https://summer-ospp.ac.cn/org/prodetail/2598a0389▍如何报名开源之夏KubeEdge课题?报名对象本活动面向年满 18 周岁的高校在校学生。在9月30日开发结束之前,学生需保持在校学生状态。若已收到研究生或博士生录取通知,可提供录取通知书及相关说明材料。中国籍学生参与活动时需提供有效期内的身份证、学生证、教育部学籍在线验证报告(学信网)或在读证明。外籍学生参与活动时需提供护照,同时提供录取通知书、有效期内的学生证、在读证明等文件。学生报名时间学生可在系统(https://summer-ospp.ac.cn/)注册账号并填写个人资料提交审核。资料审核通过的学生 5月9日 起可在系统提交项目申请书,学生课题申请截止时间为6月9日18:00。学生可以收获什么?结识开源界小伙伴和技术大牛获得社区导师的专业指导,与开源项目开发者深度交流丰富项目实践经验,提升项目开发技能为学习方向提供参考,为职业发展积累人脉通过结项考核的学生将获得结项奖金和结项证书(基础难度税前8000元RMB,进阶难度税前12000元RMB),更有机会获选优秀学生如何快速选定课题?对 KubeEdge 社区开源之夏课题感兴趣的同学,欢迎通过本文上方导师邮箱,提前联系导师沟通锁定课题。为方便同学们更快了解与找到最适合自己的课题方向,KubeEdge 社区将于5月14日、5月15日特别组织18个课题线上宣讲会,大咖导师空降,帮你更快速了解课题,欢迎同学们通过以下方式参会: 开源之夏2025KubeEdge社区课题宣讲如群满,请添加社区小助手微信k8s2222,回复KubeEdge开源之夏进入宣讲群 KubeEdge宣讲第一场:2025.05.14 周三下午16:00SIG Device-IoT,SIG Cluster-Lifecycle,Example,Dashboard等课题KubeEdge宣讲第二场:2025.05.15 周四下午16:30 SIG AI课题学生参会统一链接:https://zoom.us/my/kubeedge添加社区小助手微信k8s2222回复KubeEdge开源之夏咨询 这个夏天,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/
  • [热门活动] 大咖领路+高额奖金!Volcano社区开源之夏8大课题邀你挑战
    开源之夏是由中国科学院软件研究所“开源软件供应链点亮计划”发起并长期支持的一项暑期开源活动,旨在鼓励在校学生积极参与开源软件的开发维护,培养和发掘更多优秀的开发者,促进优秀开源软件社区的蓬勃发展,助力开源软件供应链建设。学生通过远程线上协作方式,通过社区资深导师指导,参与到开源社区各组织项目开发中,收获证书及8000/12000元奖金。活动官网:https://summer-ospp.ac.cn/Volcano云原生批量计算社区已连续6年加入开源之夏。今年社区为同学们带来8项课题,欢迎高校同学选报,报名将于5月9日正式启动,截止时间6月9日18:00 (UTC+8)。Volcano是业界首个云原生批量计算社区,也是 CNCF 首个及唯一孵化级批量计算项目。Volcano主要用于 AI、大数据、基因、渲染等诸多高性能计算场景,完成对 Spark、Flink、Ray、Tensorflow、PyTorch、Argo、MindSpore、Paddlepaddle 、Kubeflow、MPI、Horovod、Mxnet、KubeGene 等众多主流计算框架的支持。社区已吸引5.8万+全球开发者,获得4.6k+Star 和1100+ Fork。Volcano现已在60多家企业中实现了生产落地,广泛应用于互联网、人工智能、自动驾驶、大数据处理、高性能计算、金融、娱乐、医疗、财经传媒、生命科学等多个行业和场景。🏷️ 社区地址:https://github.com/volcano-sh/volcano   开源之夏 2025 Volcano 课题介绍   课题一:面向云原生场景的Device Plugin GPU虚拟化与型号上报统一管理项目编号:253ba0225项目难度:基础/Basic项目社区导师:archlitchi导师联系邮箱:391013634@qq.com项目简述:Volcano Device Plugin 目前分别在不同分支提供了 GPU 虚拟化(基于较旧上游版本)和 GPU 型号上报(基于较新 v0.16.1 版本)两项重要功能。为了解决由此带来的维护和使用不便,本项目计划将这两项能力整合到统一的代码分支中,并进行适当重构。最终目标是提供一个功能完备、接口统一的 Device Plugin,更好地支持云原生环境下的 GPU 资源虚拟化和精细化管理,提升用户体验并促进社区协作。项目链接:https://summer-ospp.ac.cn/org/prodetail/253ba0225课题二:增强Volcano Agent以支持Cgroup V2与Systemd项目编号:253ba0247项目难度:基础/Basic项目社区导师:guoqinwill导师联系邮箱:gq411will@163.com项目简述:Volcano Agent 是云原生混部场景下的核心 SLO (Service Level Objective) Agent,通过统一调度、资源隔离和动态资源超卖等机制提高了资源利用率,并通过 OoS (Out-of-Service) 保障机制确保高优先级任务的服务质量。当前,Volcano Agent 主要支持 Cgroup v1,这与目前主流操作系统逐步迁移至 Cgroup v2 和 Systemd 的趋势不符,同时也限制了与配置不同 cgroup-driver 的 Kubelet 节点的兼容性,阻碍了端到端混部能力的完整实现。本项目旨在增强 Volcano Agent 的基础能力,使其能够原生支持 Cgroup v2 和 Systemd。通过适配新的资源管理机制,Volcano Agent 将能更好地与现代操作系统集成,并与配置不同 cgroup-driver 的 Kubelet 节点协同工作,为用户提供一致的混部体验,从而进一步完善其在云原生混部场景下的资源管理和 SLO 保障能力。项目链接:https://summer-ospp.ac.cn/org/prodetail/253ba0247课题三:Volcano准入控制从Webhook到声明式策略的演进与迁移项目编号:253ba0259项目难度:基础/Basic项目社区导师:JesseStutler导师联系邮箱:jessestutler97@gmail.com项目简述:当前,Volcano 依赖大量的 Webhook 组件对 Kubernetes 集群中的 Pod、VCJob、Queue 等核心资源进行准入控制,包括验证资源的有效性(Validating)和根据策略进行默认值设置或修改(Mutating)。虽然 Webhook 机制能够实现灵活的准入控制逻辑,但在 Kubernetes 高版本集群中,引入了更高效且与 CRD 深度集成的声明式准入控制方案,例如 Kubebuilder 对 CEL (Common Expression Language) 的支持,以及 Kubernetes 原生的 ValidatingAdmissionPolicy 和 MutatingAdmissionPolicy API。本项目旨在对 Volcano 现有的准入控制机制进行现代化改造,核心目标是将当前由 Webhook 实现的部分或全部准入控制逻辑迁移到这些声明式的策略定义中。通过利用 CEL 在 CRD 层面定义校验规则,以及使用 ValidatingAdmissionPolicy 和 MutatingAdmissionPolicy API 实现更灵活的资源准入控制,可以减少外部 Webhook 调用的开销,潜在地提升 Volcano 的性能,并简化准入控制策略的管理和维护。此外,为了保证与不同 Kubernetes 集群版本的兼容性,本项目还需要考虑在 Helm 安装时提供灵活的部署选项。对于不支持 CEL 和 Admission Policy API 的旧版本集群,应继续使用现有的 Webhook 机制。而对于支持这些新特性的高版本集群,则默认或可选地启用新的声明式准入控制模式。通过本次项目的实施,Volcano 将能够更好地融入现代 Kubernetes 生态,提升在高版本集群中的运行效率和可维护性,并为未来的准入控制策略扩展奠定基础。项目链接:https://summer-ospp.ac.cn/org/prodetail/253ba0259课题四:Volcano 原生异构资源管理:集成昇腾 NPU 调度插件项目编号:253ba0293项目难度:进阶/Advanced项目社区导师:lowang-bh导师联系邮箱:lhui_wang@163.com项目简述:Volcano 作为首个云原生批量计算平台,旨在提供对包括 GPU、NPU、x86、ARM 等异构资源的统一管理和调度能力。目前,针对昇腾 NPU 资源的调度支持以独立插件的形式在昇腾社区维护,这导致用户在使用 Volcano 调度 NPU 时需要依赖外部组件,增加了复杂性和维护成本。本项目旨在将昇腾社区维护的 NPU 调度逻辑作为 Volcano 社区的原生插件进行集成和统一管理。通过将现有的独立插件迁移到 Volcano 社区并进行重构,使其完全融入 Volcano 的架构体系,用户将能够更方便地在 Volcano 框架内直接使用 NPU 调度能力,无需额外依赖和维护第三方组件。项目链接:https://summer-ospp.ac.cn/org/prodetail/253ba0293课题五:Volcano 子项目 CI/CD 流程、Helm 发布与自动化测试体系建设项目难度:253ba0295项目难度:基础/Basic项目社区导师:box导师联系邮箱:wszwbsddbk@gmail.com项目简述:随着 Volcano 社区的不断发展,涌现出越来越多的新子项目,例如 descheduler、volcano-global、dashboard 等。然而,这些新创建的子项目目前普遍缺乏完善的 CI/CD(持续集成/持续交付)流水线 workflow、自动化 Helm 发布包构建流程以及充分的自动化测试覆盖(包括单元测试 UT 和端到端测试 E2E)。基础设施的缺失会影响项目的开发效率、代码质量、发布流程的标准化以及最终产品的稳定性。本项目旨在为 Volcano 社区中尚未具备完整 CI/CD、Helm 发布和自动化测试体系的新子项目进行全面的基础设施建设。目标是建立一套标准化的流程和工具链,使得新子项目能够快速地实现自动化构建、测试、打包和发布,并具备足够的自动化测试覆盖以保障代码质量。项目链接:https://summer-ospp.ac.cn/org/prodetail/253ba0295课题六:Volcano 大规模场景性能瓶颈分析与持续优化项目难度:253ba0300项目难度:进阶/Advanced项目社区导师:李鑫导师联系邮箱:hwdefcom@outlook.com项目简述:性能一直是 Volcano 社区高度关注并持续优化的关键领域。随着用户使用场景的日益丰富、集群规模的不断扩大以及 Volcano 功能的逐步增强,对 Volcano 在大规模场景下的性能提出了越来越高的要求。尽管 Volcano 在早期已经进行了一系列性能优化工作,但为了更好地应对未来的挑战,进一步提升其在大规模场景下的性能至关重要。本项目旨在深入分析 Volcano 在大规模场景下的性能瓶颈,并制定和实施持续的优化策略。具体而言,将借助现有的开源工具,例如 Kubernetes 模拟器 KWOK 以及调度器性能压测工具等,对 Volcano 在处理大规模批量下发 Deployment 和 Volcano Job 等典型场景下的性能表现进行细致的分析。通过性能指标采集与分析、性能瓶颈识别、阶段耗时分析、开源工具应用、优化方案制定与实施、性能回归测试以及持续性能监控与告警等环节,全面提升 Volcano 在大规模场景下的性能,为用户提供更稳定、更高效的任务调度服务。项目链接:https://summer-ospp.ac.cn/org/prodetail/253ba0300课题七:基于 Hugo 的 Volcano 官网重构与功能定制开发项目难度:253ba0307项目难度:基础/Basic项目社区导师:常旭征导师联系邮箱:cxz2536818783@gmail.com项目简述:Volcano 社区的官方网站 (https://github.com/volcano-sh/website和https://volcano.sh/) 是用户了解、使用和参与 Volcano 项目的关键入口。当前网站基于 Hugo 静态站点生成器构建,但在用户界面、用户体验和功能性方面仍有提升空间。本项目旨在对 Volcano 官网进行前端功能的深度开发与用户界面和用户体验的全面升级,重点在于增强文档的搜索和导航能力,优化现有的文档版本管理机制,构建全新的用户展示平台(Adopter Group 页面),并进行整体的用户界面和交互体验优化。此外,本项目还将涵盖对核心组件和功能的文档进行细致的更新和完善,确保文档的准确性和实用性。本课题的目标是增强 Volcano 官网的功能性与用户体验。项目链接:https://summer-ospp.ac.cn/org/prodetail/253ba0307课题八:基于数据依赖的任务编排与 Volcano Global 调度项目难度:253ba0314项目难度:进阶/Advanced项目社区导师:汪洋导师联系邮箱:wysea1990@163.com项目简述:Volcano Global 作为 Volcano 社区新发布的多集群调度平台,旨在为 AI、大数据、HPC 等高性能计算任务提供跨集群的统一调度能力,目前已支持队列和作业优先级、以及多租户公平调度。然而,在大数据场景下,任务之间往往存在复杂的数据依赖关系,例如任务 C 依赖任务 A 生成的数据。当前 Volcano Global 尚不支持此类依赖约束,导致在跨集群调度时,任务的实际可调度性受限于数据在目标集群上的可用性。运维人员需要人工分析和配置任务与数据源的对应关系,这不仅效率低下,还容易导致集群负载不均衡。尤其是在跨数据中心场景下,由于无法直接跨集群读写数据,需要通过平台的数据同步管道来保证数据安全,使得数据依赖的满足更加复杂。本项目旨在为 Volcano Global 设计并实现一个可插拔的第三方依赖检测机制,以支持大数据任务的数据依赖约束调度。该机制允许用户在任务定义中声明其所需的数据表(或其他数据源)以及目标集群,通过外挂的依赖检测插件,Volcano Global 可以在调度时查询集群的数据可用性,从而将任务调度到满足其数据依赖的集群上。项目链接:https://summer-ospp.ac.cn/org/prodetail/253ba0295▍如何报名开源之夏Volcano课题?报名对象本活动面向年满 18 周岁的高校在校学生。在9月30日开发结束之前,学生需保持在校学生状态。若已收到研究生或博士生录取通知,可提供录取通知书及相关说明材料。中国籍学生参与活动时需提供有效期内的身份证、学生证、教育部学籍在线验证报告(学信网)或在读证明。外籍学生参与活动时需提供护照,同时提供录取通知书、有效期内的学生证、在读证明等文件。学生报名时间学生可在系统(https://summer-ospp.ac.cn/)注册账号并填写个人资料提交审核。资料审核通过的学生 5月9日 起可在系统提交项目申请书,学生课题申请截止时间为6月9日18:00。学生可以收获什么?结识开源界小伙伴和技术大牛获得社区导师的专业指导,与开源项目开发者深度交流丰富项目实践经验,提升项目开发技能,为工作履历增光添彩为学习方向提供参考,为职业发展积累人脉通过结项考核的学生将获得结项奖金和结项证书(基础难度税前8000元RMB,进阶难度税前12000元RMB),更有机会获选优秀学生▍Volcano社区技术交流与联系Volcano社区开源之夏2025交流群添加社区小助手k8s2222回复Volcano开源之夏咨询【更多Volcano干货推荐】Volcano云原生批量计算公开课Volcano云原生批量计算公开课Volcano云原生批量计算公开课由CNCF首个批量计算社区Volcano核心贡献者开发,通过理论学习+实践操作,帮助学习者由浅入深了解批量计算原理和生产场景应用,晋升批量计算达人!点击免费学习Volcano云原生批量计算公开课(https://edu.huaweicloud.com/roadmap/cloudnative.html)社区介绍:Volcano 是业界首个云原生批量计算引擎,也是 CNCF 首个和唯一的批量计算项目。项目主要用于 AI、大数据、基因、渲染等诸多高性能计算场景,对主流通用计算框架均有很好的支持。目前,Volcano在人工智能、大数据、基因测序等海量数据计算和分析场景已得到快速应用,已完成对 Spark、Flink、Tensorflow、PyTorch、Argo、MindSpore、Paddlepaddle 、Kubeflow、MPI、Horovod、Mxnet、KubeGene、Ray 等众多主流计算框架的支持,并构建起完善的上下游生态。Volcano官网:https://volcano.shGitHub: https://github.com/volcano-sh/volcano每周例会:https://zoom.us/j/91804791393
  • [公告] Bilibili、中电信人工智能科技、商汤科技、联通云等正式加入Volcano社区用户组
    北京时间2025年4月23日,哔哩哔哩、中电信人工智能科技、商汤科技、联通云等多家行业领军企业共同宣布加入Volcano[1]社区用户组。这一重要合作将重点推动AI训练推理、大数据分析等业务场景在云原生平台的规模化落地,标志着Volcano社区在技术创新和生态建设方面取得重大突破。通过本次合作,各方将充分发挥各自在人工智能、云计算等领域的技术优势,共同构建开放、协同、创新的云原生开源生态。这不仅将加速企业级云原生解决方案的实践应用,也将为开发者社区提供更完善的技术支持和发展平台。Volcano社区将持续优化平台能力,携手合作伙伴推动云原生技术在各行业的深入应用。关于Volcano社区用户组Volcano作为业界首个云原生批量计算引擎,已经在60多家企业中实现了生产落地,广泛应用于互联网、人工智能、自动驾驶、大数据处理、高性能计算、金融、娱乐、医疗、财经传媒、生命科学等多个行业和场景。随着Volcano社区生态圈的不断扩大,越来越多的用户表达了加入社区的强烈意愿。为了帮助用户快速融入社区,加速落地实践,Volcano社区在前期已经携手11家首批合作伙伴,共同启动了社区共建计划[2]。Volcano社区共建计划现已升级为Volcano社区用户组[3](Adopter Group),旨在与社区用户建立更紧密的合作关系,携手共建开放、繁荣、创新的社区生态。有关Volcano社区用户组的详细信息,请参阅:https://github.com/volcano-sh/community/tree/master/adopter-group首批加入的合作伙伴[4] 包括:百度、博云、第四范式、唯品会、锐天投资、中科类脑、品览、360、网易数帆、喜马拉雅、BOSS直聘。Bilibili、中电信人工智能科技、商汤科技、联通云等正式加入▍关于BilibiliBilibili(简称B站)成立于2009年,是一家提供视频、直播、游戏、广告等业务的互联网公司。借助Volcano的批调度、队列等高阶能力,B站的AI、大数据等业务实现了高效的资源调度管理和平滑的云原生迁移。目前,Volcano已在B站内部的AI平台上实现了稳定的生产落地。通过Volcano Job API,B站对海量视频编解码任务进行了有效的调度和管理。同时,借助Volcano的PodGroup调度抽象和层级队列等功能,B站成功将大数据业务从Spark、Yarn迁移到云原生平台。B站的工程师团队,包括@Wang-Kai、@LivingCcj、@WulixuanS、@bufan,贡献了队列优先级、性能优化等核心特性,为Volcano社区的发展提供了重要支持。▍关于中电信人工智能科技中电信人工智能科技成立于2023年,是中国电信旗下专注于大数据及人工智能业务的科技型、能力型、平台型专业公司。公司致力于人工智能领域核心技术攻坚、前沿技术研发和产业空间拓展,成功自研了星辰AI大模型、星海智算中台、星河AI平台等创新应用成果。中电信人工智能科技的星海多模态融合PaaS底座,通过高效算力管理调度、高性能存算分离技术、高容错大模型运维技术、网络虚拟化技术、多模态数据汇聚加工等技术,成为构建高质量数据加工和AI训练推理基础设施的坚实底座。该平台在24年支撑了中国电信星辰千亿万亿参数大模型在全国产万卡训练集群上的全训练生命周期,并在内外部训推场景上大规模应用。其中高效算力管理调度构建在Volcano基础上,并密切与Volcano社区合作开发,实现了多级队列管理、AI训练推理任务调度、网络拓扑感知、断点续训等能力,大幅提升集群资源利用率。中电信AI公司的工程师团队,包括@Xu-Wentao、@weapons97和@zhutong196,贡献了网络拓扑感知调度、层级队列等核心特性。中电信AI公司PaaS研发总监杨磊表示:“ 中电信TAP平台基于Volcano实现了AI与大数据场景的全栈调度支持,在AI领域,通过多级队列调度与GPU算力池化技术,显著提升分布式训练效率;在大数据场景中,灵活调度Spark、Flink等异构计算引擎,打破资源孤岛。感谢Volcano社区的技术沉淀与开放协作,期待与社区共同协作,为上层应用提供更灵活的算力管理与调度能力。”▍关于商汤科技作为人工智能软件公司,商汤科技以“坚持原创,让AI引领人类进步”为使命,持续引领人工智能前沿研究,打造更具拓展性和普惠性的人工智能软件平台,推动经济、社会和人类发展。同时,商汤科技注重吸引和培养顶尖人才,共同塑造未来。在技术实践方面,商汤科技采用Volcano进行AI工作负载的调度和管理,深度利用Volcano Job等特性统一管理并高效分发AI任务。通过Volcano Job对AI工作负载的统一抽象,能够支持主流AI计算框架,并借助其重启策略,在AI训练场景中实现细粒度的故障恢复和灵活的任务重启。此外,商汤科技的工程师@kingeasternsun和@zhengxinwei在Volcano社区中积极参与性能优化等工作,为提升调度效率和系统稳定性做出了重要贡献。商汤科技SenseCore IaaS 产品技术负责人项铁尧表示:“ Volcano 是一个由 CNCF 托管的云原生批量计算平台,它弥补了 Kubernetes 在 AI、HPC 和大数据工作负载方面缺失的关键能力。Volcano通过高阶的批量调度、公平资源分配和弹性扩展等特性增强了原生 Kubernetes能力,显著提升了集群利用率和效率。通过支持异构硬件(GPU、NPU 等),并与 TensorFlow 和 Spark 等框架无缝集成,Volcano 简化了大规模任务的编排,同时降低了基础设施开销。作为超大规模 AI 训练/推理基础设施的先驱,SenseCore IaaS 利用 Volcano 为分布式深度学习和大规模并行工作负载提供极致的效率。通过与 PyTorch、Ray 和其他领先框架无缝集成,并针对 GPU、NPU 和异构硬件进行优化,SenseCore 使企业能够更快地进行训练、更智能地扩展,并以前所未有的效率部署尖端 AI 技术。Volcano 专为大规模 AI/ML 而构建,通过智能调度、弹性扩展和公平共享资源管理增强了 Kubernetes,使其成为下一代 AI 基础架构的核心支撑。凭借 SenseCore 久经考验的编排能力和 Volcano 的开源敏捷性,团队可以专注于突破性创新,摆脱基础架构的限制。”▍关于联通云联通云成立于2013年,是中国联通旗下的云服务品牌,由联通云数据有限公司研发,是全球领先的云计算服务商,云服务器提供商。联通云以云计算国家队、数字化转型算力引擎的责任担当,立足自主创新,实现全新升级,树立“安全数智云”品牌形象,形成了“安全可靠、云网一体、数智相融、专属定制、多云协同”的特色优势,提供“联接+感知+计算+智能”的算网一体化服务,打造数字经济“第一算力引擎”。联通云的工程师团队,包括@sailorvii和@linuxfhy,贡献了vGPU虚拟化等核心特性。联通云容器团队负责人王琦表示:“ 容器团队选择 Volcano 作为调度器,基于多维度的综合考量。在资源管理方面,Volcano 对各类资源的把控细致入微。它不仅能精准洞悉 CPU、内存、存储等常规资源的使用情况,提升资源整体利用率,在 GPU 资源调度上更是表现卓越。Volcano 具备强大的 GPU 感知调度能力,支持多种GPU调度方式。在任务编排领域,Volcano 支持复杂任务拓扑结构,能依据任务间的依赖关系有序启动和停止容器,保障业务流程顺畅运转。” 欢迎加入Volcano用户组加入Volcano社区用户组将获得以下权益:直接交流机会:针对用户的特殊场景进行交流与分析,直接解决问题并保护项目隐私。分析落地过程中的疑难问题,提升问题解决效率。直接反馈技术迭代需求,获得更快速的响应。官方媒体宣传机会:入选项目将在官方平台展示。在项目落地过程中,社区将在关键里程碑节点协助进行媒体推广。提升技术影响力的机会:项目完成并落地后,社区会对主要贡献者表示真挚谢意。公司(或组织)Logo有机会在官方网站上展示。获得线上/线下技术分享机会。获得在KubeCon Volcano专题环节发言的机会。有机会联合主办技术峰会、沙龙、Meetup等社区活动。 结 语随着Bilibili、中电信人工智能科技、商汤科技、联通云等用户的加入,Volcano社区的生态圈进一步扩大。这些用户和伙伴的加入不仅为社区带来了丰富的实践经验和技术创新,也为Volcano在云原生领域的持续发展注入了新的活力。未来,Volcano社区将继续与更多合作伙伴携手,共同推动云原生技术的进步,为各行各业提供更高效、更灵活的云原生AI资源调度与管理支持。相关资料 [1] Volcano 官网: https://volcano.sh/ [2] Volcano社区共建计划: https://volcano.sh/zh/blog/volcano-community-co-construction-program/ [3] Volcano用户组: https://github.com/volcano-sh/community/tree/master/adopter-group [4] 华为云携手11家合作伙伴启动Volcano社区共建计划: https://mp.weixin.qq.com/s/LIzk0sPakgt6wVr2CPtAlg【更多Volcano干货推荐】Volcano云原生批量计算公开课Volcano云原生批量计算公开课Volcano云原生批量计算公开课由CNCF首个批量计算社区Volcano核心贡献者开发,通过理论学习+实践操作,帮助学习者由浅入深了解批量计算原理和生产场景应用,晋升批量计算达人!点击免费学习Volcano云原生批量计算公开课社区介绍:Volcano 是业界首个云原生批量计算引擎,也是 CNCF 首个和唯一的批量计算项目。项目主要用于 AI、大数据、基因、渲染等诸多高性能计算场景,对主流通用计算框架均有很好的支持。目前,Volcano在人工智能、大数据、基因测序等海量数据计算和分析场景已得到快速应用,已完成对 Spark、Flink、Tensorflow、PyTorch、Argo、MindSpore、Paddlepaddle 、Kubeflow、MPI、Horovod、Mxnet、KubeGene、Ray 等众多主流计算框架的支持,并构建起完善的上下游生态。Volcano官网:https://volcano.shGitHub: https://github.com/volcano-sh/volcano每周例会:https://zoom.us/j/91804791393扫码添加社区小助手回复Volcano进交流群
  • [技术干货] KubeEdge边缘设备管理系列(六):Mapper-Framework开发示例
    作者:王彬丞&杨志佳&刘家伟针对新版本 Device-IoT 领域的更新,我们计划推出一系列的文章对这些特性进行详细的介绍,大致的文章大纲为:1. 基于物模型的设备管理 API 设计与实现2. DMI 数据面能力设计与实现3. Mapper 开发框架 Mapper-Framework 设计与实现4. 如何使用 Mapper 完成视频流数据处理5. 如何使用 Mapper 实现设备数据写入6. 如何从头开发一个 Mapper(以 modbus 为例)在本系列的前几篇文章中,我们详细介绍了基于物模型的设备管理 API、DMI 数据面能力的增强、Mapper-Framework 开发框架的原理、使用 Mapper 进行视频流数据采集上报以及设备数据写入等核心特性,作为系列文章的最终部分,我们将展示如何从零开始开发一个 Mapper 工程,并通过该工程实现对边缘设备的管理。  定义Device CRD  用户需要按照 KubeEdge v1beta1 版本的 Device CRD 定义,以物模型的形式构建 device-model 与 device-instance,具体的定义细节可以参考本系列的第一篇文章。👇🏻 以下是一个具体的示例:apiVersion: devices.kubeedge.io/v1beta1kind: DeviceModelmetadata: name: temperature-modelspec: properties: - name: temp # define device property description: The temperature collected by the sensor type: INT # date type of device property accessMode: ReadWrite protocol: modbus # protocol for device, need to be same with device instance首先,我们定义了一个名为 temperature-model 的 device-model,该模型用于定义一类温度传感器的共同特性。在这个示例中,temperature-model 描述了温度传感器的一个重要属性 temp。该属性表示温度传感器采集到的温度值,数据类型为 int。此外,设备的通信协议采用了 Modbus 协议,并且 temp 属性的访问方式被设置为“读写”模式。这意味着,Mapper 将会对从设备采集到的数据进行归一化或其他处理后,返回标准化的结果。apiVersion: devices.kubeedge.io/v1beta1kind: Devicemetadata: name: temperature-instance-01 labels: model: temperature-modelspec: deviceModelRef: name: temperature-model protocol: protocolName: modbus configData: serialPort: '/dev/ttyS0' baudRate: 9600 dataBits: 8 parity: even stopBits: 1 nodeName: edge-node properties: - name: temp visitors: protocolName: modbus configData: register: HoldingRegister offset: 2 limit: 1 scale: 1 isSwap: true isRegisterSwap: true reportCycle: 10000 collectCycle: 10000 reportToCloud: true pushMethod: mqtt: address: tcp://127.0.0.1:1883 topic: temperature qos: 0 retained: false接下来,我们定义了一个名为 temperature-instance-01 的 device-instance,代表一个实际的 Modbus 温度传感器设备。在定义中,spec.protocol 字段需要具体说明设备的通信协议参数,在示例中使用 Modbus 协议,并为其定义了典型的通信参数,如串口、波特率等。Mapper 将根据这些参数与设备进行通信,完成数据的采集与交互。在 spec.properties 字段中,我们定义了与设备模型中一致的 temp 属性,并进一步细化了访问方式。在 visitors 字段中,我们详细列出了 temp 属性的访问方式,包括寄存器类型、寄存器地址以及偏移量等信息。根据这些定义,Mapper 会准确地访问设备的寄存器,从而获取所需的数据。最后,在 spec.properties.pushMethod 字段中,我们定义了设备数据的推送方式。DMI 数据面支持将设备数据推送到多种目标,包括数据库、用户应用等。具体的推送方式可以参考本系列的第二篇文章。  构建Modbus Mapper工程如果开发者需要构建自定义的 Mapper 插件,可以通过 KubeEdge 的 Mapper-Framework 子仓库生成 Mapper 工程模板。接下来,开发者只需根据设备的具体信息,填充设备初始化、数据采集等功能,即可完成自定义 Mapper 插件的构建。👇🏻 以下是相关示例:1、生成 Mapper 工程开发者首先通过 git clone 命令克隆 KubeEdge 的 Mapper-Framework 仓库[1] ,随后使用 git checkout 指令切换到稳定版本(目前支持的版本为1.16至1.20)并执行 make generate 命令,输入自定义 Mapper 的名称及是否处理流数据等信息,最终生成 Mapper 工程:生成的 modbus mapper 工程将会被构建到 Mapper-Framework 的同级目录,工程结构可以参考本系列的第三篇文章中提供的详细说明。2、实现设备驱动功能在大多数情况下,开发者需要填充 Mapper 工程中的 driver 目录下的两个文件以及 Mapper 的配置文件。主要的工作集中在 devicetype.go 和 driver.go 文件中。在 devicetype.go 文件中,开发者需要填充设备协议的配置信息及属性访问的字段,而在 driver.go 文件中,需要实现设备初始化、数据获取等具体功能。👇🏻 以下是相关文件的示例:type ProtocolConfig struct { ProtocolName string `json:"protocolName"` ConfigData `json:"configData"`}type ConfigData struct { // TODO: add your protocol config data SerialPort string `json:"serialPort"` DataBits int `json:"dataBits"` BaudRate int `json:"baudRate"` Parity string `json:"parity"` StopBits int `json:"stopBits"`}type VisitorConfig struct { ProtocolName string `json:"protocolName"` VisitorConfigData `json:"configData"`}type VisitorConfigData struct { // TODO: add your visitor config data DataType string `json:"dataType"` Register string `json:"register"` Offset uint16 `json:"offset"` Limit int `json:"limit"` Scale float64 `json:"scale"` IsSwap bool `json:"isSwap"` IsRegisterSwap bool `json:"isRegisterSwap"`}在 devicetype.go 文件中,开发者需要填充协议参数(如 ConfigData)和属性访问参数(如 VisitorConfigData)。这些定义必须与 device-instance 中的字段保持一致,以确保 Mapper 能正确解析来自 device-instance 配置文件的参数值,从而实现设备与应用之间的数据交互。var clients *sync.Mapvar clientInit sync.Oncefunc initMap() { clientInit.Do(func() { if clients == nil { clients = new(sync.Map) } })}func NewClient(protocol ProtocolConfig) (*CustomizedClient, error) { client := &CustomizedClient{ ProtocolConfig: protocol, deviceMutex: sync.Mutex{}, // TODO initialize the variables you added } return client, nil}func (c *CustomizedClient) InitDevice() error { initMap() klog.Infoln("SerialPort : ", c.ProtocolConfig.SerialPort) v, ok := clients.Load(c.ProtocolConfig.SerialPort) if ok { c.ModbusClient = v.(modbus.Client) return nil } handler := modbus.NewRTUClientHandler(c.ProtocolConfig.SerialPort) handler.BaudRate = c.ProtocolConfig.BaudRate handler.DataBits = c.ProtocolConfig.DataBits handler.Parity = parity(c.ProtocolConfig.Parity) handler.StopBits = c.ProtocolConfig.StopBits client := modbus.NewClient(handler) clients.Store(c.ProtocolConfig.SerialPort, &client) c.ModbusClient = client return nil}func (c *CustomizedClient) GetDeviceData(visitor *VisitorConfig) (interface{}, error) { c.deviceMutex.Lock() defer c.deviceMutex.Unlock() var results []byte var err error switch visitor.Register { case "CoilRegister": results, err = c.ModbusClient.ReadCoils(visitor.Offset, uint16(visitor.Limit)) case "DiscreteInputRegister": results, err = c.ModbusClient.ReadDiscreteInputs(visitor.Offset, uint16(visitor.Limit)) case "HoldingRegister": results, err = c.ModbusClient.ReadHoldingRegisters(visitor.Offset, uint16(visitor.Limit)) case "InputRegister": results, err = c.ModbusClient.ReadInputRegisters(visitor.Offset, uint16(visitor.Limit)) default: return nil, errors.New("Bad register type") } klog.V(2).Info("Get result: ", results) return results, err}func (c *CustomizedClient) StopDevice() error { // TODO: stop device // you can use c.ProtocolConfig err := c.ModbusClient.Close() if err != nil { return err } return nil}在 driver.go 文件中,开发者根据 devicetype.go 中解析得到的协议配置字段和属性访问参数,实现设备驱动的具体功能。例如,在上面的示例中,我们实现了 Modbus 设备的初始化、数据获取以及设备停止等功能。具体实现需要根据所使用设备的协议和操作需求进行定制。除了设备驱动的实现外,开发者还需要修改 Mapper 的配置文件 config.yaml。一般来说,开发者只需填充 Mapper 的协议名字段(protocol)即可:grpc_server: socket_path: /etc/kubeedge/modbus.sockcommon: name: Modbus-mapper version: v1.13.0 api_version: v1.0.0 protocol: modbus # TODO add your protocol name address: 127.0.0.1 edgecore_sock: /etc/kubeedge/dmi.sock   部署自定义Mapper插件完成自定义 Mapper 工程的构建后,接下来就可以进行编译并将其部署到 KubeEdge 集群中。目前,推荐使用两种部署方式:二进制部署和 Deployment 部署。➤ 二进制部署二进制部署适合在开发和调试阶段使用。这种方式操作简便,适合快速运行和排查错误。通过以下命令,开发者可以直接在本地编译并运行 Mapper 插件:go run cmd/main.go --v <log level,like 3> --config-file <path to config yaml>在这条命令中,--v 参数用来设置日志级别,日志级别越高,输出的信息越详细;--config-file 参数则指定了 Mapper 配置文件的路径。➤ Deployment 部署当 Mapper 插件经过充分调试并能够稳定运行后,建议将其以容器的形式部署到 KubeEdge 集群中。通过使用 Mapper-Framework 生成的 Dockerfile,开发者可以构建 Docker 镜像并创建 Kubernetes Deployment,以便在生产环境中稳定运行。👇🏻 以下是一个示例 Deployment 配置:apiVersion: apps/v1kind: Deploymentmetadata: name: modbus-mapperspec: replicas: 1 selector: matchLabels: app: demo template: metadata: labels: app: demo spec: nodeName: edge-node # replace with your edge node name containers: - name: demo volumeMounts: # Required, mapper need to communicate with grpcclient and get the config - name: test-volume mountPath: /etc/kubeedge image: modbus-mapper:v1.0.0 # Replace with your mapper image name imagePullPolicy: IfNotPresent resources: limits: cpu: 300m memory: 500Mi requests: cpu: 100m memory: 100Mi command: ["/bin/sh","-c"] args: ["/kubeedge/main --config-file /kubeedge/config.yaml --v 4"] volumes: - name: test-volume hostPath: path: /etc/kubeedge type: Directory完成自定义 Mapper 插件的部署后,用户可以向集群创建 device-model 和 device-instance 资源,随后 Mapper 将收到通知并开始进行设备的管理,定期获取设备数据并进行推送。这样,就完成了边缘设备的云原生化管理,使设备的生命周期、数据采集、处理和推送过程都能够在云原生架构下高效、可靠地进行。通过本系列技术文章的深入探讨,我们全面分析了 KubeEdge 在 Device-IoT 领域的创新与实践,重点涵盖了基于物模型的设备管理 API、DMI 数据面能力的增强、Mapper-Framework 的设计与实现、使用 Mapper 完成视频流数据处理、设备数据写入以及自定义 Mapper 工程开发的实际案例。这些内容充分展示了 KubeEdge 如何有效推动边缘计算与物联网技术的融合,为边缘设备的云原生化管理提供了切实可行的解决方案。随着物联网设备的日益普及以及边缘计算需求的持续增长,KubeEdge 在设备管理和数据处理方面的独特优势将愈发突出。通过这一系列功能的实现,KubeEdge 为物联网设备的管理、数据流的处理以及边缘计算任务的执行提供了强大支持。我们期待更多开发者加入 KubeEdge 社区,共同为全球的边缘计算生态贡献力量。 相关链接:[1] Mapper-Framework 仓库:cid:link_6扫码回复“KubeEdge”进入技术交流群【更多KubeEdge资讯推荐】玩转KubeEdge保姆级攻略——环境搭建篇玩转KubeEdge保姆级攻略——环境搭建篇《玩转KubeEdge保姆级攻略——环境搭建篇》课程主要介绍如何通过华为云服务快速搭建一套KubeEdge边缘计算开发平台及部署Sedna、EdgeMesh等KubeEdge生态组件。课程免费学习链接:cid:link_5KubeEdge社区介绍:KubeEdge是业界首个云原生边缘计算框架、云原生计算基金会(CNCF)唯一毕业级边缘计算开源项目,社区已完成业界最大规模云原生边云协同高速公路项目(统一管理10万边缘节点/50万边缘应用)、业界首个云原生星地协同卫星、业界首个云原生车云协同汽车、业界首个云原生油田项目,开源业界首个分布式协同AI框架Sedna及业界首个边云协同终身学习范式,并在持续开拓创新中。KubeEdge网站 :  https://kubeedge.ioGitHub地址 : cid:link_7Slack地址 : 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/
  • [热门活动] 华为云亮相 KubeCon Europe 2025,共启云原生下一个十年
    由 Linux 基金会、云原生计算基金会 (CNCF)主办的全球云原生与开源顶级盛会 KubeCon + CloudNativeCon Europe 2025 [1] 近日于欧洲顺利落下帷幕。本届大会汇聚全球12000+参会者和4000多家与会企业,为期4天的日程包含300余场Keynote与Session,于泰晤士河畔共绘云原生与AI前沿技术图谱,共建云原生技术与应用繁荣生态。华为云在本届大会上携云原生与AI技术创新成果与展览展示精彩亮相,与全球开发者探讨云原生 AI 基础设施、多集群编排调度、边缘 AI、流量治理等开源领域发展成果与产业应用。正如会场随处可见的英伦风 Slogan “Mind the CrashLoop”,技术火花在欧洲碰撞,并为全球智能化演进注入新锐动能。作为云原生领域的先锋创新者与践行者,华为云对 Kubernetes、Istio 等社区的贡献一直位居全球前列,先后主导开源了业界首个智能边缘计算项目 KubeEdge、业界首个云原生 AI 调度引擎 Volcano、业界首个云原生多云容器编排引擎 Karmada 等多个 CNCF 项目,并持续带来了 Kuasar、Kmesh 等项目创新,拥有在任 CNCF 技术监督委员会 TOC 成员,多个 CNCF 项目技术委员会,治理委员会成员及核心 Maintainer 席位。下面,一起看看华为云在本次大会上的精彩分享。全球顶尖技术领袖,共启云原生下一个十年3月31日大会前一天,与会的 CNCF 技术监督委员会成员(TOC)[2] 集体亮相 Maintainer Summit,拉开本届KubeCon大会序幕。CNCF TOC 是云原生计算基金会的最高技术治理组织,由全球顶尖云原生技术专家组成,负责制定CNCF技术战略、审核项目准入与毕业、协调跨项目协作并推动生态演进,引领全球云原生技术方向。会上,TOC成员们介绍了委员会发展动向、GB、最终用户社区、入选标准等话题,和现场Maintainers畅聊未来协作与技术发展。Kevin Wang (右三)Lead of Cloud Native Open Source Team, Huawei Cloud; CNCF TOC  同时,CNCF Technical Advisory Groups 也正为云原生下一个十年倾注准备。在《 Preparing for the Next 10 Years in Cloud Native》演讲中,CNCF TOC 代表成员分享和讨论了全新的TAG结构、涉及的领域以及如何利用新的TAG来实现技术理念并带来ROI。华为云云原生团队开源负责人,中国本土唯一TOC成员王泽锋联合发表演讲,共启云原生下一个十年。 携手客户伙伴,华为云多领域前沿技术精彩亮相▍ AI基础设施构建与效能优化当前,大模型技术的快速发展正推动着模型参数和训练数据规模的持续增长,这给分布式训练系统的网络性能带来了新的挑战。作为CNCF认证的 Cloud-Native AI五大核心项目之一,Volcano项目针对LLMs训练与推理场景,提出了基于网络拓扑感知的高性能调度方案,该方案通过对任务调度算法和资源管理模型的深度优化,有效提升了分布式训练任务的执行效率。在网络拓扑感知、资源调度等方面,Volcano展现出了显著的技术优势,为AI大模型的训练和推理提供了更高效的底层支持。在本次技术大会上,Volcano社区核心维护者团队带来了精彩的技术分享。华为云云原生团队开源负责人王泽锋,Volcano社区Maintainer常旭征在议题《Cloud Native AI: Harness the Power of Advanced Scheduling for High-Performance AI/ML Training》[3] 中向与会者详细解读了Volcano在智能调度领域的最新突破,包括:基于拓扑感知的任务调度带来的性能提升方案、多集群AI任务调度、云原生混部等。这些创新成果为大规模模型训练提供了强有力的底层支撑。同时,受资源可用性、平台规模、高可用性保障以及业务资源池整合等关键因素影响,多集群AI基础设施已成为行业普遍选择。在实际生产部署中,通过实施智能调度策略配置、优化工作负载管理机制以及采用拓扑感知调度技术,能够有效平衡资源利用率与工作负载优先级,满足不同类型AI工作负载的差异化需求,从而显著提升AI训练和推理任务的整体效率。在《Balancing Cost and Efficiency: Day2 Optimization of Multi-Cluster AI Infrastructure》[4] 专题演讲中,王泽锋深入分享了多集群AI基础设施的持续优化实践,重点探讨了Day2阶段运维中的关键技术挑战和解决方案,为与会者提供了宝贵的实践经验参考。▍ 边云AI协同创新与应用随着5G网络、工业互联网、人工智能等技术的快速发展,边缘计算在推动数智化转型中发挥了重要作用,也迎来了诸多全新的挑战。来自华为云的云原生技术专家徐飞、鲍玥、王彬丞携手DaoCloud、谐云、Second State 等社区伙伴带来了云原生边缘计算的最新发展趋势分享。在系列演讲中,KubeEdge技术专家们就应对管理大规模异构边缘节点的关键挑战,在网络不稳定的情况下对 K8s List-watch 进行优化,避免频繁 relist 对服务端带宽的影响,如何使用KubeEdge和WasmEdge无缝管理边缘和云上的云原生LLM工作负载,如何通过协同算法实现跨云和边缘的灵活AI任务部署,以满足对实时性、准确性和隐私的多样化需求等边缘技术创新与应用领域进行了细致解析与探讨。今年,KubeEdge作为CNCF毕业项目参会,吸引了与会者的广泛关注,从零开始打造多元协作的开源社区成为现场开发者与企业关心的话题。KubeEdge的维护者们向与会者分享了KubeEdge的技术规划、社区治理、开发者成长和项目维护等方面的关键战略及毕业后的社区更新,介绍了KubeEdge在各种边缘环境(如智慧城市、工业物联网、边缘AI、机器人和零售)中的成功案例和见解。KubeEdge技术分享及演讲材料详见:主会场议题[5] ; 同场活动议题[6]▍ 多集群技术面向AI应用全景Karmada 是一个 Kubernetes 管理系统,让用户能够跨多个 Kubernetes 集群和云运行云原生应用程序。本届大会上,华为云云原生团队技术专家,Karmada社区 Maintainer 任洪彩联合社区伙伴在分享了 Karmada 的核心功能、生产环境案例以及过去一年的功能更新。在 KubeCon 前一日的 Maintainer Summit 上,Karmada 的社区用户与开发者,包括来自 Bloomberg 等的用户伙伴,共同组织了Karmada Project Meeting,就社区的发展的路线、特性研发、生产应用展开深度探讨。值得一提的是,本次大会上,Bloomberg 团队与社区深度合作,探讨了如何在多集群 K8s 上构建弹性数据管道,在多集群 K8s 上进行智能调度有状态工作负载、提高弹性和确保故障转移等复杂情况下的 Karmada 应对策略,以及如何利用 Karmada 支持其他有状态用例。Karmada 技术分享及演讲材料详见:Karmada议程 [7]▍ 云原生AI时代的 “ 流量 ” 密码云原生AI浪潮下,流量治理效能及安全性的重要性尤为凸显。Service Mesh 为云原生应用带来了透明的治理功能,虽然服务网格已经成为微服务管理的事实标准,但传统的 sidecar 实现面临着严峻的挑战:巨大的资源开销(内存/CPU消耗30-50%)和时延,Sidecar 生命周期与应用紧耦合,运维成本复杂。Kmesh[8] 将流量治理下沉内核 eBPF,提供高性能无边车服务网格解决方案,为业界带来流量治理创新的架构演进。通过战略性地将 eBPF 与远程代理集成,Kmesh 与基于边车的网格相比,资源消耗减少了90%。此新一代架构在保持完整的 Istio API 兼容性的同时,实现了10倍的 CPU 使用率提升、2倍的连接数提升和1.5倍的延迟优化,提供了传统服务网格的生产就绪替代方案。华为云云原生团队专家徐中虎,Kmesh 社区核心成员田慕阳在会上诠释了这一稳定易用的高性能 Sidecarless 服务网格方案。 持续开放创新,共启AI-Native Cloud体验在 N350 华为展台,华为云向与会者展示了 AI-Native Cloud 创新产品,“ AI 计算云服务”、“加速数智融合”、“ Serverless 云原生基础设施”等主题展屏与专家讲解,将 AI 驱动的产品和产业生态娓娓道来。云容器实例(CCI)[9]、云容器引擎(CCE)[10] 、分布式云原生服务(UCS)[11] 等AI原生基础设施产品也在本次云原生盛会上备受关注。与此同时,华为云及社区伙伴讲解专家,也在 KubeEdge、Volcano、Karmada、Kmesh 等 CNCF 项目展台,与参会者们面对面畅谈云原生边缘 AI、智能调度、多云容器、流量治理等技术创新发展趋势与行业应用。Mind the CrashLoop!持续开放创新,华为云领先构筑AI-Native 基础设施,加速企业数智化转型。作为CNCF在亚洲唯一创始成员,华为云早自2015年起,就投身于云原生社区建设,贡献多项 K8s 关键技术特性,在 Istio 等社区代码贡献量连续多年排名亚洲 No.1。结合在云原生领域的长期深耕与创新,华为云在云原生 Al 、Serverless 架构、多云和混合云战略、云边端协同等领域均有领先的商用级产品,以技术革新为驱动,打造业界领先的云原生解决方案,连续八次中国容器软件市场份额 TOP1,为企业数智化转型提供强大动力。通过持之以恒的产业实践、贡献投入与生态合作,我们期待共同促进云原生产业生态的繁荣,共赢更加创新、智能的未来。我们的实践也将不断向 AI-Native 的云演进,加速全球智能化发展。 相关资料[1] KubeCon + CloudNativeCon Europe 2025: https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/[2] CNCF 技术监督委员会成员(TOC): https://www.cncf.io/people/technical-oversight-committee/[3] Cloud Native AI: Harness the Power of Advanced Scheduling for High-Performance AI/ML Training》: https://sched.co/1td1E[4] 《Balancing Cost and Efficiency: Day2 Optimization of Multi-Cluster AI Infrastructure》: https://sched.co/1tx7c[5] KubeEdge 主会场议题: https://kccnceu2025.sched.com/?searchstring=KubeEdge[6] KubeEdge同场活动议题: https://colocatedeventseu2025.sched.com/?searchstring=KubeEdge[7] Karmada议程: https://kccnceu2025.sched.com/?searchstring=Karmada[8] Kmesh: https://kmesh.net/en/[9] 云容器实例(CCI): cid:link_4[10] 云容器引擎(CCE): cid:link_5[11] 华为云 UCS: cid:link_6 【更多华为云云原生干货推荐】华为云云原生王者之路集训营华为云云原生王者之路集训营为帮助广大技术爱好者快速掌握云原生相关技能,华为云云原生团队与华为云学院联合CNCF开源软件大学启动人才培养计划,推出《华为云云原生王者之路集训营》,从云原生基础知识介绍到最佳实践讲解、底层原理和方案架构深度剖析,层层深入,满足不同云原生技术基础和学习目标人群的需求。本课程还精选数十个企业典型应用场景,作为学员上机实践案例,帮助学员将所学技术快速与企业业务相结合,服务于企业生产。点击免费参加华为云云原生王者之路集训营:cid:link_3 学习后记得小试牛刀,看看测评效果~ 华为云云原生王者之路-黄金课程测评 华为云云原生王者之路-钻石课程测评 华为云云原生王者之路-王者课程测评
  • [热门活动] KubeCon Europe 2025 | 一图速览华为云精彩议程
        关注容器魔方获取更多华为云参会动态
  • [技术干货] KubeEdge边缘设备管理系列(五):Mapper-Framework设备数据写入
    作者:王彬丞&杨志佳&刘家伟针对新版本 Device-IoT 领域的更新,我们计划推出一系列的文章对这些特性进行详细的介绍,大致的文章大纲为:1. 基于物模型的设备管理 API 设计与实现2. DMI 数据面能力设计与实现3. Mapper 开发框架 Mapper-Framework 设计与实现4. 如何使用 Mapper 完成视频流数据处理5. 如何使用 Mapper 实现设备数据写入6. 如何从头开发一个 Mapper(以 modbus 为例)  在上一篇文章中,我们介绍了通过 Mapper-Framework 实现摄像头设备的纳管以及视频流数据处理的功能,显著提升了设备数据的采集和读取能力,使数据面的能力进一步增强。 然而,在实际的生产环境中,设备管理不仅涉及数据的读取,还可能需要将处理后的数据回写到设备,以执行特定的控制指令或调整运行参数。因此在KubeEdge 1.19版本中,Mapper-Framework 增强了对设备的管理能力,新增了设备数据写入的功能,使边缘设备的管控更加完善。  Device Method API 简介  从物模型的传统定义来看,设备的参数按照功能类型通常分为三类:属性(Property):用于描述设备状态,例如温度传感器所读取的环境温度、插座的开关状态等。方法(Method):设备可被外部调用并执行的方法,例如调整设备参数等。事件(Event):描述设备上报云端的事件。在本系列的第一篇文章中,我们已经在 v1beta1 版本的设备管理 API 中引入了设备属性(Property) 的定义,使用户可以获取设备的状态。而在 KubeEdge 1.19 版本中,我们进一步扩展了 API,引入了设备方法(Device Method),允许用户调用设备方法实现对设备属性的动态控制。Device Method 的 API 定义如下:// DeviceMethod describes the specifics all the methods of the device. type DeviceMethod struct { // Required: The device method name to be accessed. It must be unique. Name string `json:"name,omitempty"` // Define the description of device method. // +optional Description string `json:"description,omitempty"` // PropertyNames are list of device properties that device methods can control. // Required: A device method can control multiple device properties. PropertyNames []string `json:"propertyNames,omitempty"` }在 Device Method 的设计中,它主要由以下三个核心字段构成:➤ Name:用于标识设备方法,在同一device-instance 内,每个方法的名称必须是唯一的。➤ Description:用于说明该方法的具体用途。➤ PropertyNames:定义该方法能够操作的设备属性列表,一个方法可以控制多个设备属性下面是一个 device-instance 配置文件示例,展示了如何添加 Device Method:apiVersion: devices.kubeedge.io/v1beta1 kind: Device metadata: name: sensor-tag-instance-02 namespace: default spec: deviceModelRef: name: sensor-tag-model nodeName: edge-node properties: - name: temperature visitors: ... methods: - name: setValue description: This method aim to writing values to device properties propertyNames: - temperature - name2这里我们为 sensor-tag-instance-02 的设备定义了一个 setValue 方法,该方法允许用户修改 temperature 和 name2 这两个设备属性的值。需要注意的是,在 device-instance 配置文件中定义的 Device Method 仅是方法的框架性定义,具体的功能实现仍然需要在 mapper 设备驱动层完成。  Mapper-Framework    设备数据写入接口  用户通过 Device Method API 定义设备方法的框架之后,需要在 mapper 设备驱动层根据预定义的方法,实现相应的数据写入逻辑。为简化用户操作,1.19版本的 Mapper-Framework 实现了设备写入的接口:func (c *CustomizedClient) DeviceDataWrite(visitor *VisitorConfig, deviceMethodName string, propertyName string, data interface{}) error { // TODO: add the code to write device's data // you can use c.ProtocolConfig and visitor return nil }具体来说,用户可以调用 device-instance CRD 中设备协议配置信息(ProtocolConfig)以及设备属性访问配置(VisitorConfig),实现对设备寄存器的写入操作。例如,在 Modbus 设备中,用户可以根据 VisitorConfig 访问特定的 Modbus 寄存器地址并写入新值,进而控制设备的运行状态。 Mapper-Framework Restful API 能力增强  在KubeEdge 1.19版本中,Mapper-Framework 扩展了 Restful API,使用户可以更加便捷地查询和调用 Device Method,具体功能如下:➤ 获取设备的所有设备方法Url: https://{mapper-pod-ip}:{mapper-api-port}/api/v1/devicemethod/{deviceNamespace}/{deviceName} Response: { "Data": { "Methods": [ { "Name": "setValue", "Path": "/api/v1/devicemethod/default/random-instance-01/setValue/{propertyName}/{data}", "Parameters": [ { "PropertyName": "random-int", "ValueType": "int" } ] } ] } }从 Response 中可以看出,目标 device 拥有名为 setValue 的 Device Method,可以通过 Path 中显示的字段进行调用。此外,setValue method 可以用来控制 random-int 这一设备属性。➤ 创建设备数据写入请求Url: https://{mapper-pod-ip}:{mapper-api-port}/api/v1/devicemethod/{deviceNamespace}/{deviceName}/{deviceMethodName}/{propertyName}/{data} Response: { "statusCode": 200, "Message": "Write data ** to device ** successfully." }用户通过 Restful API 发起设备数据写入请求有两种方式:1)边缘端调用用户可以直接在边缘节点上,通过 Mapper Pod 暴露的 Restful API 发送请求,直接与设备交互,实现低延迟的本地控制。2)云端调用在云端,用户可以借助 EdgeMesh 等组件,将请求从云端转发至对应的边缘节点,然后由 Mapper 处理并执行设备写入操作。无论采用哪种调用方式,Mapper 在接收到设备数据写入请求后,会执行以下操作:解析请求内容,获取目标设备、目标方法及其参数。调用设备驱动层中的 DeviceDataWrite 功能,按照定义的协议与设备进行通信。完成设备属性的写入,更新设备状态。截至目前,本系列文章已经系统地介绍了 KubeEdge SIG Device-IoT 自1.15版本以来的核心特性,包括:基于物模型的设备管理 API, 能够更全面的描述物理设备。DMI 数据面能力增强Mapper-Framework 开发框架原理,用于简化用户开发自定义 mapper 插件。使用 Mapper 进行视频流数据采集与上报,支持摄像头等设备的数据接入。使用 Mapper 进行设备数据写入,增强边缘设备管理能力。在本系列的最后一篇文章中,我们将向大家展示如何从零开始基于 Mapper-Framework 开发一个 Modbus 协议的 Mapper 插件,并详细讲解如何定义设备模型、构建 Mapper 工程、实现设备驱动、获取并推送设备数据,从而帮助开发者更高效地构建和集成自定义 Mapper 组件。    扫码回复“KubeEdge”进入技术交流群 【更多KubeEdge资讯推荐】玩转KubeEdge保姆级攻略——环境搭建篇玩转KubeEdge保姆级攻略——环境搭建篇《玩转KubeEdge保姆级攻略——环境搭建篇》课程主要介绍如何通过华为云服务快速搭建一套KubeEdge边缘计算开发平台及部署Sedna、EdgeMesh等KubeEdge生态组件。课程免费学习链接:cid:link_4KubeEdge社区介绍:KubeEdge是业界首个云原生边缘计算框架、云原生计算基金会(CNCF)唯一毕业级边缘计算开源项目,社区已完成业界最大规模云原生边云协同高速公路项目(统一管理10万边缘节点/50万边缘应用)、业界首个云原生星地协同卫星、业界首个云原生车云协同汽车、业界首个云原生油田项目,开源业界首个分布式协同AI框架Sedna及业界首个边云协同终身学习范式,并在持续开拓创新中。KubeEdge网站 :  https://kubeedge.ioGitHub地址 : cid:link_5Slack地址 : 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/
  • [技术干货] Karmada v1.13 版本发布!新增应用优先级调度能力
    Karmada 是开放的多云多集群容器编排引擎,旨在帮助用户在多云环境下部署和运维业务应用。凭借兼容 Kubernetes 原生 API 的能力,Karmada 可以平滑迁移单集群工作负载,并且仍可保持与 Kubernetes 周边生态工具链协同。  Karmada v1.13 版本[1]现已发布,本版本包含下列新增特性:新增应用优先级调度功能,可用于保证关键作业时效性新增应用调度暂停与恢复功能,可用于构建多集群队列系统Karmada Operator 功能持续演进Karmada 控制器性能优化提升Karmada Dashboard 首个版本发布!开启多云编排可视化新篇章   新特性概览  应用优先级调度当前,Karmada 调度器调度负载时遵循 FIFO 策略,按照负载进入调度队列的次序依次调度。但在某些场景,比如AI训练类作业平台,用户希望工作负载能够按照优先级进行调度。这样当高优先级、紧急任务进入调度队列时,可以实现“插队”的效果,从而确保关键业务的时效性与服务质量。从 v1.13.0 版本起,用户使用 PropagationPolicy 分发负载时可以指定调度优先级(.spec.SchedulePriority 字段)。SchedulePriority 会指向用户事先配置的优先级类,Karmada 解析该优先级类并获取对应的优先级数值,值越大,调度优先级越高。例如,需要在环境中部署 A,B 两种应用,应用A 负责在线交易这类对实时性要求高的业务,而应用B 负责定期日志清理等非紧急且对时间不敏感的业务。为确保在资源紧张时,应用A 能优先被调度,可以给应用A 配置较大的优先级类。应用A 的优先级类和 PropagationPolicy 配置:apiVersion:scheduling.k8s.io/v1 kind:PriorityClass metadata: name:high-priority value:1000000 --- apiVersion:policy.karmada.io/v1alpha1 kind:PropagationPolicy metadata: name:propagation-a spec: schedulePriority: priorityClassSource:KubePriorityClass priorityClassName:high-priority placement: clusterAffinity: clusterNames: -member1 resourceSelectors: -apiVersion:apps/v1 kind:Deployment name:application-a应用B 的优先级类和 PropagationPolicy 配置:apiVersion: scheduling.k8s.io/v1 kind:PriorityClass metadata: name:low-priority value:1 --- apiVersion:policy.karmada.io/v1alpha1 kind:PropagationPolicy metadata: name:propagation-b spec: schedulePriority: priorityClassSource:KubePriorityClass priorityClassName:low-priority placement: clusterAffinity: clusterNames: -member1 resourceSelectors: -apiVersion:apps/v1 kind:Deployment name:application-b 通过上述配置,当调度队列同时存在应用A 和 应用B 的工作负载时,应用A 会被优先调度,即便应用B 先进入队列。更多有关应用优先级调度的资料请参考:应用优先级调度[2]  应用调度暂停与恢复应用从 Karmada 控制面分发到成员集群大致可以分为两个环节:应用调度:Karmada 调度器根据分发策略为应用选择合适的集群。应用分发:Karmada 控制器按照调度结果将应用分发到指定的集群。Karmada 现已支持应用调度及分发过程的启停控制,这一能力为用户提供了灵活的调度管理手段。基于此,用户可根据实际业务需求,构建定制化的高级调度策略。例如,可将其与业务发布流程相结合,实现联邦应用跨集群的滚动升级;也可结合工作负载优先级,达成队列与工作负载的优先级调度。其中应用分发环节的暂停与恢复是在 v1.11.0 版本引入的功能,详细请参考:应用分发暂停与恢复[3]。而在 v1.13.0 版本,Karmada 正式引入了应用调度环节的暂停与恢复。社区在字段 ResourceBinding.Spec.Suspension 中新增了字段 Scheduling,用于控制应用调度的暂停与恢复。当 Suspension.Scheduling 为 true 时,应用调度暂停。当 Suspension.Scheduling 为 false 时,应用调度恢复。此功能可以与第三方系统集成,通过控制 ResourceBinding 的 Suspension.Scheduling 的字段值,实现对应用调度过程的精准控制。例如,在创建 ResourceBinding 时,可通过 webhook 将 Suspension.Scheduling 设置为 true 以暂停调度;随后,可对应用进行优先级排序、容量规划等操作;待相关操作完成后,设置 Suspension.Scheduling 为 false 即可恢复调度,最终实现有序调度/资源配额管理等高级能力。更多有关应用调度暂停与恢复的资料请参考:应用调度暂停与恢复能力[4] Karmada Operator 功能持续演进本版本持续增强 Karmada Operator,新增以下功能:支持配置 API Server 边车容器:用户可通过此功能为 Karmada API Server 配置边车容器,从而集成辅助服务。例如,可集成 KMS 插件[5],实现静态数据加密。更多有关 API Server 边车容器配置的资料请参考:支持配置 API Server 边车容器[6]支持配置组件优先级类:用户可通过自定义 Karmada CR 为控制平面组件指定优先级类,确保关键组件以适当的优先级进行调度,从而提升 Karmada 系统的可靠性和稳定性。更多有关组件优先级类配置的资料请参考:如何为 Karmada 控制平面组件配置优先级类[7]以上新特性进一步提升了 Karmada Operator 的可配置性,满足用户多样化需求。 Karmada 控制器性能优化提升随着 Karmada 被业界广泛采纳,以及部署的规模不断提升,性能优化也成了 Karmada 关注和发力的重要方向。社区成立了性能优化团队,专门分析和优化 Karmada 关键组件的性能,并已取得了显著的成效。在版本 v1.13.0,Karmada 的性能优化主要集中在控制器,减少大规模数据部署场景下,控制器重启时的性能开销。为了验证性能优化的成效,社区准备了 12C CPU, 28G RAM 的物理机,并部署了 1000 个 Deployments 和 1000个 Configmaps,共生成 2000 个 ResourceBindings。在重启组件 karmada-controller-manager 后,收集 workqueue 的指标,结果如下:对于 Detector 控制器:队列 Reconcile 时间降低了60%。对于 binding-controller 控制器:队列 Reconcile 时间降低了25%。这些指标显示了在版本 v1.13.0,控制器 Detector 和 binding-controller 在重启场景下存量资源重新编排的性能有了显著的提升。 Karmada Dashboard 首个版本发布经过数位热心开发者的持续努力,Karmada Dashboard 终于迎来了具有里程碑意义的第一个版本(v0.1.0)!这一版本标志着 Karmada 在可视化管理领域迈出了重要的一步。Karmada Dashboard 是一款专为 Karmada 用户设计的图形化界面工具,旨在简化多集群管理的操作流程,提升用户体验。通过 Dashboard,用户可以直观地查看集群状态、资源分布以及任务执行情况,同时还能轻松完成配置调整和策略部署。Karmada Dashboard v0.1.0 主要功能包括:集群管理: 提供集群接入和状态概览,包括健康状态、节点数量等关键指标。资源管理:业务资源配置管理,包括命名空间、工作负载、服务等。策略管理:Karmada 策略管理,包括分发策略、差异化策略等。更多有关 Karmada Dashboard 的资料请参考:Karmada Dashboard[8] 致谢贡献者Karmada v1.13 版本包含了来自 41 位贡献者的 205 次代码提交,在此对各位贡献者表示由衷的感谢:贡献者列表:   参考资料[1] Karmada v1.13 版本: https://github.com/karmada-io/karmada/releases/tag/v1.13.0[2] 应用优先级调度: https://github.com/karmada-io/karmada/tree/master/docs/proposals/scheduling/binding-priority-preemption[3] 应用分发暂停与恢复: https://karmada.io/docs/next/userguide/scheduling/resource-propagating/#suspend-and-resume-of-resource-propagation[4] 应用调度暂停与恢复能力: https://github.com/karmada-io/karmada/tree/master/docs/proposals/scheduling-suspension[5] KMS 插件: https://kubernetes.io/docs/tasks/administer-cluster/kms-provider/[6] 支持配置 API Server 边车容器: https://github.com/karmada-io/karmada/tree/master/docs/proposals/karmada-operator/api-server-sidecard-containers[7] 如何为 Karmada 控制平面组件配置优先级类: https://karmada.io/zh/docs/administrator/configuration/priority-class-configuration/#%E5%A6%82%E4%BD%95%E4%B8%BA-karmada-%E6%8E%A7%E5%88%B6%E5%B9%B3%E9%9D%A2%E7%BB%84%E4%BB%B6%E9%85%8D%E7%BD%AE%E4%BC%98%E5%85%88%E7%BA%A7%E7%B1%BB[8] Karmada Dashboard: cid:link_1  添加社区小助手进入Karmada交流群 👉Karmada 是CNCF 首个多云多集群容器编排项目(孵化级),旨在帮助用户像使用单个集群一样轻松管理跨云多集群,让基于 Karmada 的多云方案无缝融入云原生技术生态。社区吸引了来自华为、道客、浙江大学、腾讯、中国电子云、滴滴、Zendesk、携程等100多家公司的全球贡献者,广泛分布于20+国家和地区。Karmada 现已在华为云、道客、兴业数金、中国移动、中国联通、携程、360集团、新浪、中通快递等众多企业单位生产应用,为企业提供从单集群到多云架构的平滑演进方案。Karmada官网:https://karmada.io/项目地址:https://github.com/karmada-io/karmadaSlack地址:https://slack.cncf.io/(#karmada)
总条数:166 到第
上滑加载中