北京时间2025年11月4日，KubeEdge 发布 1.22.0 版本。新版本对 Beehive 框架以及 Device Model 做了优化升级，同时对边缘资源管理能力做了提升。KubeEdge v1.22.0 新增特性：新增 hold/release 机制控制边缘资源更新 Beehive框架升级，支持配置子模块重启策略  基于物模型与产品概念的设备模型能力升级边缘轻量化 Kubelet 新增 Pod Resources Server 和 CSI Plugin 特性开关C语言版本的 Mapper-Framework 支持升级 K8s 依赖到1.31  新特性概览  ▍新增 hold/release 机制控制边缘资源更新在自动驾驶、无人机和机器人等应用场景中，我们希望在边缘能够控制对边缘资源的更新，以确保在未得到边缘设备管理员的许可下，这些资源无法被更新。在1.22.0版本中，我们引入了 hold/release 机制 来管理边缘资源的更新。在云端，用户可以通过对 Deployment、StatefulSet 和 DaemonSet 等资源添加edge.kubeedge.io/hold-upgrade: "true"的annotation，表示对应的 Pod 在边缘更新需要被 hold。在边缘，被标记了edge.kubeedge.io/hold-upgrade: "true"的 Pod 会被暂缓被处理。边缘管理员可以通过执行以下命令来释放对该 Pod 的锁，完成资源更新。keadm ctl unhold-upgrade pod <pod-name>也可以执行以下命令解锁边缘节点上所有被 hold 的边缘资源keadm ctl unhold-upgrade node💭 注意：使用keadm ctl命令需要启动 DynamicController 和 MetaServer 开关。更多信息可参考：cid:link_1cid:link_2▍Beehive框架升级，支持配置子模块重启策略在1.17版本中，我们实现了 EdgeCore 模块的自重启，可以通过全局配置来设置边缘模块的重启。在1.22版本中，我们对 Beehive 框架进行了升级优化，支持边缘子模块级别的重启策略配置。同时我们统一了 Beehive 各子模块启动的错误处理方式，对子模块能力标准化。更多信息可参考：https://github.com/kubeedge/kubeedge/pull/6444cid:link_3▍基于物模型与产品概念的设备模型能力升级 目前的 Device Model 基于物模型概念设计，而在传统 IoT 中，设备通常采用物模型、产品和设备实例三层结构进行设计，可能导致用户在实际使用中产生困惑。在 1.22.0 版本中，我们结合物模型与实际产品的概念，对设备模型的设计进行了升级。从现有的设备实例中提取了protocolConfigData ,  visitors字段到设备模型中，设备实例可以共享这些模型配置。同时，为了降低模型分离的成本，设备实例可以重写覆盖以上配置。更多信息可参考：cid:link_4cid:link_5▍边缘轻量化 Kubelet 新增 Pod Resources Server 和 CSI Plugin 特性开关 在之前的版本中，我们在 EdgeCore 集成的轻量化 Kubelet 中移除了 Pod Resources Server 能力，但在一些使用场景中，用户希望恢复该能力以实现对Pod的监控等。同时，由于 Kubelet 默认启动 CSI Plugin，离线环境下启动 EdgeCore 会由于 CSINode 创建失败而导致失败。在 1.22.0 版本中，我们在轻量化 Kubelet 中新增了 Pod Resources Server 和 CSI Plugin 特性开关，如果您需要启用 Pod Resources Server 或关闭 CSI Plugin，您可以在 EdgeCore 配置中添加如下特性开关：apiVersion: edgecore.config.kubeedge.io/v1alpha2kind: EdgeCoremodules:  edged:    tailoredKubeletConfig:      featureGates：        KubeletPodResources: true        DisableCSIVolumePlugin: true...更多信息可参考：cid:link_6cid:link_7cid:link_8▍C语言版本 Mapper-Framework 支持 在1.20.0版本中，我们在原有的 go 语言版本 Mapper 工程基础上，新增了 Java 版本的 Mapper-Framework。由于边缘 IoT 设备通信协议的多样性，很多边缘设备驱动协议都是基于 C语言实现的，因此在新版本中，KubeEdge 提供了 C语言版本的 Mapper-Framework，用户可以访问 KubeEdge 主仓库的feature-multilingual-mapper-c分支，利用 Mapper-Framework 生成 C语言版本的自定义 Mapper 工程。更多信息可参考：cid:link_9cid:link_10▍升级 K8s 依赖到1.31新版本将依赖的 Kubernetes 版本升级到v1.31.12，您可以在云和边缘使用新版本的特性。更多信息可参考：cid:link_11▍致谢感谢 KubeEdge 社区技术指导委员会 (TSC)、各 SIG 成员对 v1.22 版本开发的支持与贡献，未来 KubeEdge 将持续在新场景探索与支持、稳定性、安全性、可扩展性等方面持续发展与演进！▍相关链接Release Notes：cid:link_0 添加小助手k8s2222回复KubeEdge进群

LFX Mentorship 计划，由 Linux Foundation 组织，从19年开始为 CNCF 各个开源社区中的开发人员持续提供带薪实习和指导。往年已获20k+申请，发起1500+课题，毕业超千名实习生，发放超过320万美金报酬。2025年秋季申请时间为 7月31日-8月12日，远程实习将从9月8日开始为期三个月。参与到 LFX Mentorship 计划中，为开源项目做贡献、获得开源社区的认可同时，完成工作还能获取报酬 (位于中国的开发者报酬为$3000美金，约合￥20000人民币）。 今年 KubeEdge 社区在 LFX Mentorship 计划中准备了多个课题，感兴趣的读者可于8月12日前点击阅读全文，或到官方平台申请：https://mentorship.lfx.linuxfoundation.org/  KubeEdge社区介绍  KubeEdge 社区已经连续5年参与 LFX Mentorship 计划，过去已为学员提供30+个项目。KubeEdge 是业界首个云原生边缘计算框架、云原生计算基金会内部唯一毕业级边缘计算开源项目。在 GitHub 获得 8.2k+Stars和2.3k+Fork，吸引了全球来自35+国家的120+贡献组织及1800+开发者。近年来，KubeEdge 社区持续开拓创新，完成业界最大规模云原生边云协同高速公路项目（统一管理10万边缘节点/50万边缘应用）、业界首个云原生星地协同卫星、业界首个云原生车云协同汽车、业界首个云原生油田项目，开源业界首个分布式协同 AI 框架 Sedna 及业界首个边云协同终身学习范式、开源业界首个分布式协同 AI 基准测试 Ianvs。在 LFX Mentorship 2025秋季计划，KubeEdge 期待再次和计算机领域新生力量一起，开拓数字未来。   面向对象  秋季计划申请者需在2025年8月12日前在 LFX 官网完成 Mentee 注册及项目申请。若被接收作为 Mentee，您将能在开源社区经验丰富、积极贡献的 Mentor 指导下为开源项目做出贡献。依据官方规定[1]，对 Mentee 的申请者有以下要求:计划开始时至少年满18周岁所在单位和组织不禁止该实习未参加另外的 Linux Mentorship 计划开发者以个人身份参与（在校或已毕业均可）具备所注册国家中工作权利且所注册国家未被计划禁止 (中国已获许可)并非社区中高于最低限度贡献成员（如Maintainer、Recurring Contributor）满足具体所属项目中提及的其它前置需求  课题参与方式  根据官方安排 [2]，LFX Mentorship 2025年秋季活动流程如下：Mentee 注册与项目申请 7月31日-8月12日申请者评审及人事工作 8月13日-8月26日实习启动及任务发放 9月8日中期考核及首次津贴支付 10月14日结项考核、实习生报告提交，最终津贴支付批准 11月25日 活动结束 11月28日申请者需要在8月12日前完成 Mentee 注册和项目申请，流程详见 [3]：https://docs.linuxfoundation.org/lfx/mentorship/mentee-guide/how-to-apply实习申请结果预计将在8月27日通知到申请人。主线开发日期为2025年9月8日 – 11月28日，全程线上协作，无需线下参与。结项需要在2025年9月28日前以 PR 的形式提交到项目所在的开源社区仓库中并完成合并。  KubeEdge课题   最后，向各位申请者推荐 CNCF KubeEdge 社区下列课题：▍KubeEdge: Deep Integration with AMD Edge Nodes (2025 Term 3)课题描述：AMD 芯片凭借其强大的 x86 架构、卓越的计算性能和先进的 NPU，在工业自动化、车载系统和高性能边缘计算等领域展现出显著潜力。将 AMD 强大的通用和异构计算能力引入 KubeEdge 生态系统，对于处理日益复杂和延迟敏感的边缘 AI 应用至关重要。然而，KubeEdge 与 AMD 高性能边缘平台之间的深度集成、性能优化和最佳实践，特别是它们内置的 NPU 和其他硬件加速单元，仍需系统性的探索和验证。本项目旨在建立 KubeEdge 与 AMD 边缘节点之间的完整链接，从硬件部署到 NPU 加速构建一个综合的边缘计算解决方案，从而极大丰富 KubeEdge 的硬件生态系统。预计输出件：支持 KubeEdge 边缘节点运行在 AMD 芯片上，并成功部署边缘应用通过 KubeEdge 调度和管理 AMD NPU 资源，以实现边缘 AI 推理应用的性能加速实现节点、应用和 NPU 的监控和指标收集使用 KubeEdge 实现从云到 AMD 边缘节点的完整平台设置、配置和管理完成硬件兼容性测试，并输出技术文档或博客前置技能：KubeEdge, Go, Linux, Hardware Integration, AI/ML课题导师：Hongbing Zhang (@HongbingZhang)hongbing.zhang@daocloud.ioShelley Bao (@Shelley-BaoYue)baoyue2@huawei.com课题链接：https://mentorship.lfx.linuxfoundation.org/project/15043686-0866-4d5a-9016-3a6cbfd448fcGithub Issue：https://github.com/kubeedge/kubeedge/issues/6429▍KubeEdge: Device Anomaly Detection Framework (2025 Term 3)课题描述：当前的 KubeEdge 平台使用三种状态来表示设备状态：期望状态、观察到的期望状态和报告状态。平台上显示的设备状态完全依赖于 Mapper，该组件负责从设备端收集和报告数据。然而，由于 Mapper 实现的局限性、物理设备故障、网络延迟以及潜在的网络攻击，平台上显示的设备状态可能无法准确反映设备的实际状态。在 KubeEdge 平台中，如果应用程序依赖于设备状态进行决策，那么状态表示的不一致可能导致不良后果。因此，本项目旨在为 KubeEdge 设计一个设备状态异常检测框架。通过探索设备状态之间的因果关系，该框架将建立轻量级的异常检测能力，并提供一个全面的工具链，包括数据收集、模型训练、实时异常检测和结果可视化。预计输出件：通用的设备异常检测框架，支持用户自定义的检测算法完整的技术设计文档，包括模型选择、训练流程，以及训练和在线检测组件的详细架构图机器学习模型及相应的异常检测算法，能够捕捉设备状态之间的因果关系，并使用标准框架进行训练和测试集成到 KubeEdge 设备状态报告工作流程中的在线异常检测模块，通过模型推理钩子实现实时分析前置技能：KubeEdge,  IoT，Machine Learning课题导师：Liwei Shen (@meixiezichuan)shenliwei@fudan.edu.cnElias Wang (@wbc6080)wangbincheng4@huawei.com课题链接：https://mentorship.lfx.linuxfoundation.org/project/8cf4ff37-e638-4b73-a5a1-521806ac8db1Github Issue：https://github.com/kubeedge/kubeedge/issues/6312▍KubeEdge: Deploy Small Language Models & OPEA Integration (2025 Term 3)课题描述：KubeEdge 作为一个基于 Kubernetes 生态系统构建的本地边缘计算平台，提供了可靠的云边通信、边缘自治和物联网设备集成等能力。然而，其在边缘支持智能模型的能力尚未在实际场景中得到系统验证和实践。本研究旨在探讨使用 KubeEdge 在边缘节点上部署和运行小语言模型的可行性和性能。预计输出件：验证 KubeEdge 在边缘的模型部署能力。在边缘节点上部署和测试 vLLM 和 llama.cpp 等模型引擎，并提供实际示例和详细文档，以便部署小型语言模型探索 KubeEdge 与 OPEA 平台之间的集成方案。将 KubeEdge 与 OPEA 的模型注册中心和工作流调度器连接，以支持从云到边缘节点的自动化模型分发和部署前置技能：KubeEdge, LLM, Golang, Python课题导师：Hongbing Zhang (@HongbingZhang)hongbing.zhang@daocloud.ioElias Wang (@wbc6080)wangbincheng4@huawei.com课题链接：https://mentorship.lfx.linuxfoundation.org/project/2e9d0538-0941-4f10-8c52-9afd6294e16eGithub Issue：https://github.com/kubeedge/kubeedge/issues/6428▍KubeEdge: Comprehensive Example Restoration for Ianvs (2025 Term 3)课题描述：Ianvs 是 KubeEdge SIG AI 的分布式基准测试工具包，随着越来越多的贡献者参与，目前已有 25 个示例，且数量仍在增加。然而，由于依赖关系的演变和验证机制的影响，KubeEdge Ianvs 面临着日益突出的可用性问题。随着合作社区 Python 版本、第三方库和 Ianvs 特性的改进，部分历史示例无法执行。这导致用户报告的问题增多、贡献者时感困惑、未经测试 PR 影响特性功能、过时文档与实际能力不符等。如果不进行干预，这些示例可能会对边缘 AI 开发者，尤其是新手，带来开发阻碍。因此，我们尝试通过优化示例来提升 Ianvs 的可用性。预计输出件：发现和修复示例中的错误，包括依赖清单、License 扫描和运行时配置文档优化，包括重新设计教程，提供可复现的逐步指南，并发布面向开发者的调试手册，以应对常见故障构建一个 CI 流水线，使用 GitHub Actions 测试多个 Python 版本下的示例，关键的 Ianvs/Upstream 更新，并阻止破坏经过验证示例的 PR前置技能：Python, Benchmark, KubeEdge-Ianvs, AI/ML课题导师：Zimu Zheng (@MooreZheng)zimu.zheng@huawei.comShijing Hu (@hsj576)sjhu21@m.fudan.edu.cn课题链接：https://mentorship.lfx.linuxfoundation.org/project/82d71e63-2e1e-48d6-8c93-91c9e8bf8d5dGithub Issue：https://github.com/kubeedge/ianvs/issues/230▍KubeEdge: Industrial Benchmark Dataset for Ianvs (2025 Term 3)课题描述：随着工业制造通过机器人技术、自适应生产线和智能测试系统的进步加速数字化转型，云边协作已成为在复杂操作环境中部署具身智能的关键推动力。现代工业对具身智能的要求不仅限于基本任务执行，还扩展到多模态感知与决策集成、动态环境适应和分布式设备编排。现有的基准测试框架在评估工业环境中固有的场景特定具身属性方面存在局限。本项目利用 KubeEdge-Ianvs 协作 AI 框架，整合领域特定的测试数据集、仿真环境和定量指标，以建立一个认证的工业级评估基础设施，用于具身智能系统。预计输出件：通过对现有资源/示例进行系统分类和重组，开发一个工业级具身智能数据集部署基准算法并引入指标，以在 KubeEdge-Ianvs 中建立性能基准前置技能：Python, Benchmark, Dataset, Embodied Intelligence课题导师：Zimu Zheng (@MooreZheng)zimu.zheng@huawei.comMengzhuo Chen (@IcyFeather233)icyfeather@foxmail.com课题链接：https://mentorship.lfx.linuxfoundation.org/project/c066ac53-5435-4057-a84c-0e0be62e8b65Github Issue：https://github.com/kubeedge/ianvs/issues/197 如果对课题内容有任何问题，欢迎在 GitHub 仓库提交 Issue 或者添加社区小助手微信向社区提问。扫码回复“KubeEdge” 进入技术群 今年秋季，KubeEdge 社区期待在 LFX Mentorship 见到您！ Reference：[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/blob/main/programs/lfx-mentorship/2025/03-Sep-Nov/README.md[3] LFX Mentorship - Mentee Application Guideline: https://docs.linuxfoundation.org/lfx/mentorship/mentee-guide/how-to-apply 【更多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地址 : https://github.com/kubeedge/kubeedgeSlack地址 : 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为期三个月的项目开发正式拉开序幕。历经导师、社区、组委会三轮审核，共有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/ 

北京时间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/

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 学习后记得小试牛刀，看看测评效果~ 华为云云原生王者之路-黄金课程测评 华为云云原生王者之路-钻石课程测评 华为云云原生王者之路-王者课程测评

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

边缘节点出现问题，KubeEdge是怎么进行处理的

调用KubeEdge服务兼容不匹配，该怎么解决？

开源之夏介绍开源之夏是由中国科学院软件研究所“开源软件供应链点亮计划”发起并长期支持的一项暑期开源活动，旨在鼓励在校学生积极参与开源软件的开发维护，培养和发掘更多优秀的开发者，促进优秀开源软件社区的蓬勃发展，助力开源软件供应链建设。学生通过远程线上协作方式，通过社区资深导师指导，参与到开源社区各组织项目开发中，收获证书及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/

作者：王彬丞&杨志佳&刘家伟针对新版本 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/

    关注容器魔方获取更多华为云参会动态

作者：王彬丞&杨志佳&刘家伟针对新版本 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/

KubeEdge作为业界首个云原生边缘计算框架、云原生计算基金会（CNCF）唯一毕业级边缘计算开源项目，自2018年开源以来，吸引了全球来自30+国家的16万+开发者，当前已广泛应用于交通、工业制造、智能CDN、金融、航天、汽车、油气等行业。为了给社区用户和开发者带来更优质的体验，提供更完备的云原生边缘计算能力，社区在此发起2025年需求征集。请您抽时间填写我们的需求征集问卷，提出您宝贵的意见与建议，也欢迎加入社区，共建开放、创新的社区。KubeEdge社区2025年需求征集：https://shimo.im/forms/25q5Xpw5NXfPVr3D/fill  扫码提交需求KubeEdge社区      【更多KubeEdge资讯推荐】玩转KubeEdge保姆级攻略——环境搭建篇玩转KubeEdge保姆级攻略——环境搭建篇《玩转KubeEdge保姆级攻略——环境搭建篇》课程主要介绍如何通过华为云服务快速搭建一套KubeEdge边缘计算开发平台及部署Sedna、EdgeMesh等KubeEdge生态组件。课程免费学习链接：cid:link_0KubeEdge社区介绍：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/

北京时间2025年1月21日，KubeEdge 发布1.20.0版本。新版本针对大规模、离线等边缘场景对边缘节点和应用的管理、运维等能力进行了增强，同时新增了多语言 Mapper-Framework 的支持。   KubeEdge v1.20.0 新增特性：支持批量节点操作 多语言 Mapper-Framework 支持 边缘 keadm ctl 新增 pods logs/exec/describe 和 Devices get/edit/describe 能力解耦边缘应用与节点组，支持使用 Node LabelSelector边云通道支持 IPv6升级 k8s 依赖到1.30   新特性概览   ▍支持批量节点操作在之前的版本中，keadm 工具仅支持单个节点的安装与管理，然而在边缘场景中，节点数量通常比较庞大，单个节点的管理难以满足大规模场景的需求。在1.20.0版本中，我们提供了批量节点操作和运维的能力。基于这个能力，用户仅需要使用一个配置文件，即可通过一个控制节点（控制节点可以登录所有边缘节点）对所有边缘节点进行批量操作和维护。keadm 当前版本支持的批量能力包括 join, reset 和 upgrade。# 配置文件配置要求参考如下 keadm: download: enable: true # <Optional> Whether to download the keadm package, which can be left unconfigured, default is true. if it is false, the 'offlinePackageDir' will be used. url: "" # <Optional> The download address of the keadm package, which can be left unconfigured. If this parameter is not configured, the official github repository will be used by default. keadmVersion: "" # <Required> The version of keadm to be installed. for example: v1.19.0 archGroup: # <Required> This parameter can configure one or more of amd64/arm64/arm. - amd64 offlinePackageDir: "" # <Optional> The path of the offline package. When download.enable is true, this parameter can be left unconfigured. cmdTplArgs: # <Optional> This parameter is the execution command template, which can be optionally configured and used in conjunction with nodes[x].keadmCmd. cmd: "" # This is an example parameter, which can be used in conjunction with nodes[x].keadmCmd. token: "" # This is an example parameter, which can be used in conjunction with nodes[x].keadmCmd. nodes: - nodeName: edge-node # <Required> Unique name, used to identify the node arch: amd64 # <Required> The architecture of the node, which can be configured as amd64/arm64/arm keadmCmd: "" # <Required> The command to be executed on the node, can used in conjunction with keadm.cmdTplArgs. for example: "{{.cmd}} --edgenode-name=containerd-node1 --token={{.token}}" copyFrom: "" # <Optional> The path of the file to be copied from the local machine to the node, which can be left unconfigured. ssh: ip: "" # <Required> The IP address of the node. username: root # <Required> The username of the node, need administrator permissions. port: 22 # <Optional> The port number of the node, the default is 22. auth: # Log in to the node with a private key or password, only one of them can be configured. type: password # <Required> The value can be configured as 'password' or 'privateKey'. passwordAuth: # It can be configured as 'passwordAuth' or 'privateKeyAuth'. password: "" # <Required> The key can be configured as 'password' or 'privateKeyPath'. maxRunNum: 5 # <Optional> The maximum number of concurrent executions, which can be left unconfigured. The default is 5.` # 配置文件参考用例 (各字段具体值请根据实际环境进行配置) keadm: download: enable: true url: cid:link_11/releases/download/v1.20.0 # If this parameter is not configured, the official github repository will be used by default keadmVersion: v1.20.0 archGroup: # This parameter can configure one or more of amd64\arm64\arm - amd64 offlinePackageDir: /tmp/kubeedge/keadm/package/amd64 # When download.enable is true, this parameter can be left unconfigured cmdTplArgs: # This parameter is the execution command template, which can be optionally configured and used in conjunction with nodes[x].keadmCmd cmd: join--cgroupdriver=cgroupfs--cloudcore-ipport=192.168.1.102:10000--hub-protocol=websocket--certport=10002--image-repository=docker.m.daocloud.io/kubeedge--kubeedge-version=v1.20.0--remote-runtime-endpoint=unix:///run/containerd/containerd.sock token: xxx nodes: - nodeName: ubuntu1 # Unique name arch: amd64 keadmCmd: '{{.cmd}} --edgenode-name=containerd-node1 --token={{.token}}' # Used in conjunction with keadm.cmdTplArgs copyFrom: /root/test-keadm-batchjoin # The file directory that needs to be remotely accessed to the joining node ssh: ip: 192.168.1.103 username: root auth: type: privateKey # Log in to the node using a private key privateKeyAuth: privateKeyPath: /root/ssh/id_rsa - nodeName: ubuntu2 arch: amd64 keadmCmd: join--edgenode-name=containerd-node2--cgroupdriver=cgroupfs--cloudcore-ipport=192.168.1.102:10000--hub-protocol=websocket--certport=10002--image-repository=docker.m.daocloud.io/kubeedge--kubeedge-version=v1.20.0--remote-runtime-endpoint=unix:///run/containerd/containerd.sock # Used alone copyFrom: /root/test-keadm-batchjoin ssh: ip:192.168.1.104 username: root auth: type: password passwordAuth: password: ***** maxRunNum: 5 # 用法 (保存以上文件，例如保存为 config.yaml) # 在控制节点下载最新版本 keadm, 执行以下命令进行使用 keadmbatch-c config.yaml更多信息可参考：cid:link_3cid:link_4cid:link_10 ▍多语言 Mapper-Framework 支持由于边缘 IoT 设备通信协议的多样性，用户可能需要使用 Mapper-Framework 生成自定义 Mapper 插件来纳管边缘设备。当前 Mapper-Framework 只能生成 go 语言版本的 Mapper 工程，对于部分不熟悉 go 语言的开发者来说使用门槛仍然较高。因此在新版本中，KubeEdge 提供了 Java 版本的 Mapper-Framework，用户可以访问 KubeEdge 主仓库的feature-multilingual-mapper分支，利用 Mapper-Framework 生成 Java 版的自定义 Mapper 工程。更多信息可参考：cid:link_11/pull/5773cid:link_5 ▍边缘 keadm ctl 新增 pods logs/exec/describe 和 Devices get/edit/describe 能力在v1.17.0版本中，我们新增了 keadm ctl 子命令，支持在离线场景下对边缘 pod 进行查询和重启。在v1.20中我们对该命令做了进一步增强，支持 pod 的logs/exec/describe等功能，用户在边缘可对 pod 进行日志查询、pod 资源详细信息查询、进入容器内部等操作。同时还新增了对 device 的操作，支持 device 的get/edit/describe的功能，可以在边缘获取 device 列表、device 的详细信息查询、在边缘离线场景下对 device 进行编辑操作。如下所示，新增的 keadm ctl 子命令功能均在 MetaServer 中开放了 Restful 接口，并与 K8s ApiServer 对应的接口完全兼容。[root@edgenode1 ~] # keadm ctl -h Commands operating on the data plane at edge Usage: keadm ctl [command] Available Commands: ... describe Show details of a specific resource edit Edit a specific resource exec Execute command in edge pod get Get resources in edge node logs Get pod logs in edge node ...更多信息可参考：cid:link_6cid:link_7 ▍解耦边缘应用与节点组，支持使用 Node LabelSelectorEdgeApplication 可以通过节点组覆盖部署定义（如副本、镜像、命令和环境），Pod 流量在节点组内闭环（EdgeApplication 管理的 Deployment 共用一个 Service）。但在实际场景中，需要批量操作的节点范围与需要相互协作的节点范围并不相同。例如在智慧园区的场景中，每个城市都有很多个智慧园区，我们需要应用的流量在一个智慧园区内闭环，但应用批量管理的范围可能是城市级，也可能是省级。我们在EdgeApplication CRD中为节点标签选择器添加了一个新的targetNodeLabels字段，该字段将允许应用程序根据节点标签进行部署，并且覆盖特定的字段，YAML 定义如下：apiVersion: apps.kubeedge.io/v1alpha1 kind: EdgeApplication metadata: name: edge-app namespace: default spec: workloadTemplate: {...} workloadScope: # New field: targetNodeLabels targetNodeLabels: - labelselector: - matchExpressions: - key: "region" operator: In values: - "HangZhou" overriders: {...}更多信息可参考：Issue: cid:link_2Pull Request: cid:link_8 ▍边云通道支持 IPv6我们在官网的文档中提供了一份配置指南，介绍了 KubeEdge 如何在 Kubernetes 集群中让云边 hub 隧道支持 IPv6。文档地址：https://kubeedge.io/docs/advanced/support_ipv6 ▍升级 K8s 依赖到 v1.30 新版本将依赖的 Kubernetes 版本升级到v1.30.7，您可以在云和边缘使用新版本的特性。更多信息可参考：cid:link_9  本升级注意事项  从v1.20开始，EdgeCore的配置项edged.rootDirectory的默认值将会由/var/lib/edged切换至/var/lib/kubelet。如果您需要继续使用原有路径，可以在使用 keadm 安装 EdgeCore 时设置--set edged.rootDirectory=/var/lib/edged。 ▍致谢感谢 KubeEdge 社区技术指导委员会 (TSC)、各 SIG 成员对v1.20版本开发的支持与贡献，未来 KubeEdge 将持续在新场景探索与支持、稳定性、安全性、可扩展性等方面持续发展与演进！ ▍相关链接Release Notes：cid:link_1  扫码回复“KubeEdge” 进入技术群    【更多KubeEdge资讯推荐】玩转KubeEdge保姆级攻略——环境搭建篇玩转KubeEdge保姆级攻略——环境搭建篇《玩转KubeEdge保姆级攻略——环境搭建篇》课程主要介绍如何通过华为云服务快速搭建一套KubeEdge边缘计算开发平台及部署Sedna、EdgeMesh等KubeEdge生态组件。 课程免费学习链接：cid:link_0 KubeEdge社区介绍：KubeEdge是业界首个云原生边缘计算框架、云原生计算基金会（CNCF）唯一毕业级边缘计算开源项目，社区已完成业界最大规模云原生边云协同高速公路项目（统一管理10万边缘节点/50万边缘应用）、业界首个云原生星地协同卫星、业界首个云原生车云协同汽车、业界首个云原生油田项目，开源业界首个分布式协同AI框架Sedna及业界首个边云协同终身学习范式，并在持续开拓创新中。 KubeEdge网站 :  https://kubeedge.ioGitHub地址 : cid:link_11Slack地址 : 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/

LFX Mentorship 计划，由 Linux Foundation 组织，从19年开始为 CNCF 各个开源社区中的开发人员持续提供带薪实习和指导。往年已获16w+申请，发起1200+课题，毕业近千名实习生，发放超过300万美金报酬。2025年春季申请时间为 2月5日-2月18日，远程实习将从3月3日开始为期三个月。参与到 LFX Mentorship 计划中，为开源项目做贡献、获得开源社区的认可同时，完成工作还能获取报酬 (位于中国的开发者报酬为$3000美金，约合￥20000人民币）。今年 KubeEdge 社区在 LFX Mentorship 计划中准备了多个课题，感兴趣的读者可于2月18日前点击阅读全文，或到官方平台申请：strongcid:link_14/strong  KubeEdge社区介绍 KubeEdge 社区已经连续5年参与 LFX Mentorship 计划，过去已为学员提供25+个项目。KubeEdge 是业界首个云原生边缘计算框架、云原生计算基金会内部唯一毕业级边缘计算开源项目。在 GitHub 获得 8k+Stars和2.2k+Fork，吸引了全球来自35+国家的100+贡献组织及16万+开发者。近年来，KubeEdge 社区持续开拓创新，完成业界最大规模云原生边云协同高速公路项目（统一管理10万边缘节点/50万边缘应用）、业界首个云原生星地协同卫星、业界首个云原生车云协同汽车、业界首个云原生油田项目，开源业界首个分布式协同 AI 框架 Sedna 及业界首个边云协同终身学习范式、开源业界首个分布式协同 AI 基准测试 Ianvs。在 LFX Mentorship 2025春季计划，KubeEdge 期待再次和计算机领域新生力量一起，开拓数字未来。   面向对象 春季计划申请者需在2025年2月18日前在 LFX 官网完成 Mentee 注册及项目申请。若被接收作为 Mentee，您将能在开源社区经验丰富、积极贡献的 Mentor 指导下为开源项目做出贡献。依据官方规定[1]，对 Mentee 的申请者有以下要求:计划开始时至少年满18周岁所在单位和组织不禁止该实习未参加另外的 Linux Mentorship 计划开发者以个人身份参与（在校或已毕业均可）具备所注册国家中工作权利且所注册国家未被计划禁止 (中国已获许可)并非社区中高于最低限度贡献成员（如Maintainer、Recurring Contributor）满足具体所属项目中提及的其它前置需求   课题参与方式  根据官方安排 [2]，LFX Mentorship 2025年春季活动流程如下：Mentee 注册与项目申请 2月5日-2月18日申请者评审及人事工作 2月19日-2月25日实习启动及任务发放 3月3日中期考核及首次津贴支付 4月16日结项考核、实习生报告提交，最终津贴支付批准 5月28日 活动结束 5月30日申请者需要在2月18日前完成 Mentee 注册和项目申请，流程详见 [3]：cid:link_8实习申请结果预计将在 2 月 26 日通知到申请人。主线开发日期为2025年3月3日 – 5月28日，全程线上协作，无需线下参与。结项需要在2025年5月28日前以 PR 的形式提交到项目所在的开源社区仓库中并完成合并。   KubeEdge课题    最后，向各位申请者推荐 CNCF KubeEdge 社区下列课题：▍KubeEdge: Enhance KubeEdge testing coverage (2025 Term 1)课题描述：为更好地维护代码质量并减少缺陷的引入，本课题希望将单元测试覆盖率提高到60%到70%（目前单元测试覆盖率为38.69%）。需要注意的是，除了要求 KubeEdge 整体的单元测试覆盖率满足要求外，每个核心代码目录（cloud/、edge/、keadm/和pkg/）的单元测试覆盖率也需要超过60%。预计输出件：UT 覆盖率提升至60%-70%前置技能：KubeEdge, Go, Testing课题导师：Elias Wang (@wbc6080)wangbincheng4@huawei.comFisher Xu (@fisherxu)fisherxu1@gmail.com课题链接：cid:link_2Github Issue：cid:link_9 ▍KubeEdge: KubeEdge Dashboard Enhancement - BFF (2025 Term 1)课题描述：为 KubeEdge Dashboard 设计的 BFF（Backend for Frontend） 中间层，旨在连接前端 UI 层与 KubeEdge 后端 API，作为数据的中转和处理中心，为前端提供一个专门设计的后端服务，简化前端的数据获取逻辑并提升性能与安全性。此外，为了让开发者更快速地体验并部署Dashboard，我们需要与 kubeedge/keink 项目进行深度集成，仅需一条命令即可启动 Dashboard 环境，实现对功能的完整演示和验证。预计输出件：一键运行与持续集成一键部署： 借助 keink 项目，仅需一条命令即可快速拉取并运行 Daily 发布的容器镜像，让开发者或体验者无需额外环境配置。持续发布机制： Daily 镜像能够持续整合最新的功能更新和修复，开发者可以及时获取最新版本，快速验证和测试功能，从而优化研发流程。数据处理: 对从后端获取的数据进行统一的格式化、过滤和处理，以满足前端的展示需求，避免在前端编写重复或复杂的逻辑。错误处理与重试（可选）前置技能：KubeEdge, JavaScript, React课题导师：Chen Su (@ghosind)ghosind@gmail.comElias Wang (@wbc6080)wangbincheng4@huawei.com课题链接：cid:link_3Github Issue：cid:link_10 ▍KubeEdge: Domain-specific large model benchmarks: the edge perspective (2025 Term 1)课题描述：业界通用大模型基准测试往往聚焦于云。随着大模型进入规模化应用时代，云端为大模型提供了基础设施和服务。客户进一步提出了边缘侧的针对性应用需求，包括个性化、数据合规性和实时性，使得不同边侧单位往往构建自有行业大模型或知识库。但目前针对边侧数据开展的大模型基准测试并未成型。由于数据在不同边缘的分布，预计通用大模型在多样边侧行业场景将产生大幅性能波动。本课题旨在为边缘AI服务和应用定位行业大模型性能波动，以便用于匹配特定大模型、定位问题乃至选择适用边侧场景。预计输出件：行业大模型边侧测试数据集、测试套件、使用说明（进阶) 测试指标设计与开发（进阶）测试方法研究，测试调研与研究报告前置技能：KubeEdge-Ianvs, Python, LLMs课题导师：Zimu Zheng (@MooreZheng)zimu.zheng@hotmail.comShijing Hu (@hsj576)sjhu21@m.fudan.edu.cn课题链接：cid:link_4Github Issue：cid:link_12 ▍KubeEdge: Enhance Dependency Management and Documentation for KubeEdge-Ianvs (2025 Term 1)课题描述：Ianvs目前正面临着较为紧迫的依赖管理问题。随着 Python 版本、依赖库以及 Ianvs 特性的持续演进，许多先前的 examples 已无法运行，导致大量相关的 Issue 被提出；现有的项目文档中也存在不少过时内容，这对新用户来说较为困扰。Ianvs 需要对已有 examples 的依赖进行梳理，并构建一套更加完善的依赖管理机制，降低新用户上手Ianvs的门槛。预计输出件：更加完善的 Contributing Guide基于大语言模型云边协同推理示例打造的全新 Quick Start Example其他 Paradigm 依赖修复和文档完善前置技能：KubeEdge, Python课题导师：Yu Fan (@FuryMartin)furymartin9910@outlook.comShijing Hu (@hsj576)sjhu21@m.fudan.edu.cn课题链接：cid:link_5Github Issue：cid:link_13 ▍KubeEdge: Community Website Comprehensive Upgrade Project: Homepage Renewal… (2025 Term 1)课题描述：为提高 KubeEdge 官网的用户体验和访问效率，官网优化项目将聚焦于首页设计优化、新页面的增加以及社区资源的改进。该项目的目标是提升网站的易用性、增加用户粘性，并通过增强培训内容和硬件兼容性支持，吸引更多用户使用 KubeEdge。预计输出件：官网首页的设计与优化，包含设计和代码更新新增页面：课程培训视频的展示，包含设计和代码更新新增页面：”硬件兼容”展示页，包含设计和代码更新partner 页面设计与优化，包含设计和代码更新优化社区资源，改善文档和入门体验，确保用户能够轻松上手并有效使用  KubeEdge。前置技能：KubeEdge, JavaScript, Docusaurus课题导师：Hongbing Zhang (@HongbingZhang)hongbing.zhang@daocloud.ioShelley Bao (@Shelley-BaoYue)baoyue2@huawei.com课题链接：cid:link_6Github Issue：cid:link_11如果对课题内容有任何问题，欢迎在 GitHub 仓库提交 Issue 或者添加社区小助手微信向社区提问。扫码回复“KubeEdge” 进入技术群今年春季，KubeEdge 社区期待在 LFX Mentorship 见到您！ 参考资料：[1] LFX Mentorship - Application Requirement：cid:link_7 [2] LFX Mentorship - Program Readme：cid:link_0[3] LFX Mentorship - Mentee Application Guideline：cid:link_8  【更多KubeEdge资讯推荐】玩转KubeEdge保姆级攻略——环境搭建篇玩转KubeEdge保姆级攻略——环境搭建篇《玩转KubeEdge保姆级攻略——环境搭建篇》课程主要介绍如何通过华为云服务快速搭建一套KubeEdge边缘计算开发平台及部署Sedna、EdgeMesh等KubeEdge生态组件。课程免费学习链接：cid:link_1KubeEdge社区介绍：KubeEdge是业界首个云原生边缘计算框架、云原生计算基金会（CNCF）唯一毕业级边缘计算开源项目，社区已完成业界最大规模云原生边云协同高速公路项目（统一管理10万边缘节点/50万边缘应用）、业界首个云原生星地协同卫星、业界首个云原生车云协同汽车、业界首个云原生油田项目，开源业界首个分布式协同AI框架Sedna及业界首个边云协同终身学习范式，并在持续开拓创新中。 KubeEdge网站 :  https://kubeedge.ioGitHub地址 : cid:link_15Slack地址 : 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/