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

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

2024年12月18日，由中国科学技术协会科学技术传播中心、中国计算机学会、中国通信学会、中国科学院软件研究所联合主办，CSDN 承办的开源创新榜评选活动圆满落幕。KubeEdge 作为业界首个云原生边缘计算项目以及 CNCF 唯一正式毕业的边缘计算开源项目，以其卓越的创新性、贡献度和影响力，从200多个竞争项目中脱颖而出，荣获2024开源创新榜优秀开源项目之首。2024开源创新榜评选活动由王怀民院士担任评委会主任，带领全国各学会、大学、科研院所、企业、开源基金会、行业联盟等近20位开源专家，面向中国开源行业领域，遴选具有创新性、贡献度和影响力的开源项目、社区、应用场景与开源事件，进一步激励更多企业和开发者参与开源生态建设，推动开源技术繁荣和发展。  KubeEdge 于2018年11月正式开源，2019年作为首个云原生边缘项目被接受为 CNCF Sandbox 项目，在2020年9月晋升为孵化项目，并于2024年10月从 CNCF 正式毕业，是第三个由中国企业开源的毕业项目。KubeEdge 项目致力于将 Kubernetes 的容器化应用编排能力无缝扩展至边缘主机，为边缘计算提供强大的基础设施支持。它基于 Kubernetes 构建，不仅覆盖了云端与边缘端之间的网络连接、应用部署和元数据同步，还通过高效的架构设计，显著提升了边缘计算场景中的可靠性与性能。目前，KubeEdge 将云原生生态扩展到了数据中心之外的更多场景和行业，广泛应用于 CDN、智能交通、智慧能源、智慧零售、智慧园区、智能汽车、航空航天、智能物流、金融、化工、电力、区块链等各领域，完成了业界最大规模云原生边云协同高速公路收费站管理项目、业界首个云原生星地协同卫星、业界首个云原生车云协同汽车、业界首个云原生智慧零售管理、业界首个云原生金融管理等行业代表项目。基于云原生边缘计算领域的独特优势，KubeEdge 得到了伙伴和用户的高度认可。此次荣获“优秀开源项目”奖项，既是对 KubeEdge 技术实力的高度认可，也彰显了社区在合作精神、开放性和追求卓越方面的努力与成就。这一荣誉离不开每一位社区成员的辛勤付出和无私奉献。未来，KubeEdge 社区将保持开放治理模式和协作理念，进一步改善用户体验，提供更可靠和稳定的服务。我们也诚邀更多的开发者和用户加入 KubeEdge 社区，共同探索边缘计算的未来，共创辉煌。   【更多KubeEdge资讯推荐】玩转KubeEdge保姆级攻略——环境搭建篇玩转KubeEdge保姆级攻略——环境搭建篇《玩转KubeEdge保姆级攻略——环境搭建篇》课程主要介绍如何通过华为云服务快速搭建一套KubeEdge边缘计算开发平台及部署Sedna、EdgeMesh等KubeEdge生态组件。课程免费学习链接：cid:link_0KubeEdge社区介绍：KubeEdge是业界首个云原生边缘计算框架、云原生计算基金会内部唯一孵化级边缘计算开源项目,社区已完成业界最大规模云原生边云协同高速公路项目（统一管理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/

12月27日，“The Future of KubeEdge” KubeEdge 毕业主题研讨会在上海成功举办。来自上海开源信息技术协会、华为云、DaoCloud、Intel、南京腾优科技、FatCoupon Technology、中碳普惠云、复旦大学、上海对外经贸大学、上海工程技术大学等多家机构、企业、高校代表及贡献者出席，就 KubeEdge 毕业后的社区规划展开深入研讨，持续聚力技术与运营协同创新，助力云原生边缘计算产业升级发展。  回顾 KubeEdge 的发展历程，从 2018 年 11 月正式开源，2019 年作为首个云原生边缘项目被接受为 CNCF Sandbox 项目， 2020 年 9 月晋升为孵化项目，并于2024年成功毕业，成为CNCF首个毕业级云原生边缘计算项目，一路走来，社区持续开源创新，将云原生生态扩展到了数据中心之外的更多场景和行业，为业内带来了多个行业首发应用，广泛覆盖 CDN、智能交通、智慧能源、智慧零售、智慧园区、汽车、航空航天、智能物流、金融、化工、电力、区块链等领域。 ▲ KubeEdge 项目里程碑 会上，KubeEdge 联合创始人，华为云云原生开源负责人王泽锋介绍了全球云原生开源生态与运作模式，并分享了 KubeEdge 发展历程中的核心技术与典型案例。CNCF 毕业项目是国际开源生态的领军者，KubeEdge 从 CNCF 毕业已迈入了成熟新阶段。基于在云原生边缘计算领域的独特优势，KubeEdge 期待在未来为整个云原生生态系统缔造更广阔的可能性。 ▲ KubeEdge联合创始人，华为云云原生开源负责人王泽锋 KubeEdge TSC，DaoCloud 首席运营官张红兵在会上分享了 KubeEdge 长期以来的社区治理及运营策略。通过系统化建立社区治理架构，严格执行高效的开发者协同机制，开展深度的工程化验证，社区有序促进技术持续创新与升级。与此同时，社区也通过开发者实训、公开课、峰会、研讨会等系列形式，为社区开发者们构建多元化的学习、参与和成长路径，打造社区活跃生态。 ▲ KubeEdge TSC，DaoCloud 首席运营官张红兵 毕业是社区的里程碑，同时也对技术创新和运营发展提出了更高的要求。在小组讨论环节，各位代表集思广益，从企业、高校、开发者各个视角，就社区未来发展深入探讨，涵盖 Scalability、Node、Device-IoT、AI、Netwoking、Security、UI、Cluster-Lifecycle、Testing、EdgeSite、Release、Docs、Robotics 等多个 SIG 的技术创新方向，持续升级社区运营治理，促进 KubeEdge 与产业发展生态融合。 未来，KubeEdge 社区将保持开放治理模式和协作理念，进一步升级用户体验，提供更可靠和稳定的服务。社区成功毕业离不开每一位社区伙伴、用户与开发者的协作与贡献，期待与您携手共建，加速社区生态协同发展，共同引领云原生边缘计算迈向产业应用新高度。

作者：王彬丞&杨志佳&刘家伟针对新版本 Device-IoT 领域的更新，我们计划推出一系列的文章对这些特性进行详细的介绍，大致的文章大纲为：基于物模型的设备管理 API 设计与实现DMI 数据面能力设计与实现Mapper 开发框架 Mapper-Framework 设计与实现如何使用 Mapper 完成视频流数据处理如何使用 Mapper 实现设备数据写入如何从头开发一个 Mapper（以 modbus 为例） 在上一篇文章中，我们为适应用户对边缘设备管理的需求，设计实现了基于物模型的设备管理 API。在此基础上，我们完善了 DMI 数据面的能力，提供边缘端处理设备数据的多种方式，让 KubeEdge 能够更灵活、标准化的管理边缘设备。本篇文章是系列文章的第二篇，将详细介绍v1.15.0版本在 DMI 数据面的一些工作。DMI 数据面能力支持 在1.12版本中，KubeEdge 设计了设备管理框架——DMI。DMI 框架提供了统一的设备管理相关接口，设备应用开发者和使用者可以通过实现 DMI 中的标准化接口完成设备管理，让边缘设备以微服务的形式提供服务，更加贴合云原生。➤ DMI 的架构图如下图所示：DMI 框架中一个重要的特性是设备管理面与设备数据面解耦。设备管理面基于 Device CRD 承载设备本身的生命周期管理，如图中黄色线条；设备数据面则让设备数据通过微服务的方式向数据消费者应用提供，拥有多种数据推送方式，如图中蓝色线条。DMI 设备管理面数据主要包括设备的元数据、设备属性、配置、生命周期等，其特点是相对比较稳定，创建后信息更新较少，这类数据会通过云边通道进行传递。设备数据面数据则主要为设备传感器采集到的设备数据，相比于管理面数据来说数据量较大，若通过云边通道传输可能会造成通道阻塞，影响集群正常功能。v1.15.0版本中 DMI 数据面功能得到完善，通过数据面能以多样化的方式推送设备数据，相比通过云边通道传输数据更加合理。  DMI 数据面能力支持 ➤ DMI 数据面系统架构如下图所示：在v1.15.0版本更新后，DMI 数据面支持如图中四种方式处理推送设备数据：1、推送至用户应用。按照 v1beta1 版本的 Device Instance API 定义，用户能够在 Device Instance 配置文件中配置 pushMethod 字段，以 HTTP 或者 MQTT 的方式定时将设备数据推送到用户应用中。2、推送至用户数据库。最新版本的 KubeEdge DMI 内置 InfluxDB、Redis、TDengine、MySQL 数据库的数据推送方式，用户能够在 Device Instance 配置文件中 dbMethod 字段设置相应数据库的参数，将设备数据定时传入数据库。3、推送至云端。用户能够设置 Device Instance 配置文件中 reportToCloud 字段决定是否将设备数据推送至云端。4、用户能够通过 Mapper 提供的 RESTful API 主动拉取设备数据。以下是一个使用 DMI 数据面能力处理设备数据的 Device Instance 配置文件示例：apiVersion: devices.kubeedge.io/v1beta1 kind:Device ... spec: properties: -name:temp collectCycle:10000 # The frequency of reporting data to the cloud. once every 10 seconds reportCycle:10000 # The frequency of data push to user applications or databases. reportToCloud:true # Device data will be reported to cloud desired: value:"100" pushMethod: mqtt: # define the MQTT config to push device data to user app address:tcp://127.0.0.1:1883 topic:temp qos:0 retained:false dbMethod: influxdb2: # define the influx database config to push device data to user database influxdb2ClientConfig: url:http://127.0.0.1:8086 org:test-org bucket:test-bucket influxdb2DataConfig: measurement:stat tag: unit:temperature fieldKey: devicetest在示例文件中，用户可以通过 reportToCloud 字段定义 Mapper 是否将设备数据推送至云端；此外，pushmethod.mqtt 字段定义了 Mapper 向用户应用推送的配置信息，示例中表示 Mapper 会定时以 MQTT 协议的方式向 127.0.0.1:1883 地址的用户应用推送设备数据；pushmethod.dbMethod 字段定义了 Mapper 向用户数据库推送的配置信息，示例中表示 Mapper 会定时向 127.0.0.1:8086 地址的 InfluxDB 数据库推送设备数据。基于 DMI 数据面的能力，用户只需在 Device Instance 配置文件中定义相关字段，即可使用多种方式处理采集到的设备数据，有效降低了云边通道阻塞的风险。DMI 提供的功能接口最终是由设备管理插件 Mapper 来承载的。Mapper 北向需要实现 DMI 管理接口向 KubeEdge 完成自身的注册以及设备管理。对于用户来说，独立对接 DMI 接口实现自定义的 Mapper 使用门槛依然较高，因此我们在v1.15.0版本中推出 Mapper 开发框架 Mapper Framework，能够使用简单的命令自动生成一个 Mapper 工程供用户使用，有效降低用户上手的难度。在本系列的下一篇文章中，我们会对 Mapper Framework 的架构与使用方法进行详细介绍。【更多KubeEdge资讯推荐】玩转KubeEdge保姆级攻略——环境搭建篇玩转KubeEdge保姆级攻略——环境搭建篇《玩转KubeEdge保姆级攻略——环境搭建篇》课程主要介绍如何通过华为云服务快速搭建一套KubeEdge边缘计算开发平台及部署Sedna、EdgeMesh等KubeEdge生态组件。课程免费学习链接：cid:link_0KubeEdge社区介绍：KubeEdge是业界首个云原生边缘计算框架、云原生计算基金会（CNCF）唯一毕业级边缘计算开源项目，社区已完成业界最大规模云原生边云协同高速公路项目（统一管理10万边缘节点/50万边缘应用）、业界首个云原生星地协同卫星、业界首个云原生车云协同汽车、业界首个云原生油田项目，开源业界首个分布式协同AI框架Sedna及业界首个边云协同终身学习范式，并在持续开拓创新中。KubeEdge网站 :  https://kubeedge.ioGitHub地址 : cid:link_2Slack地址 : 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/

开放创新，释放云上数字生产力。12月7日，2024华为云开源开发者论坛将于上海举办。本届论坛面向生态合作伙伴、企业、个人和高校开发者，设置主论坛、云原生、开源共创、大前端四大论坛，帮助开发者使用开源链接鲲鹏、昇腾根生态和华为云生态，实现高效创新和价值裂变。2024华为云开源开发者论坛云原生专场汇聚 KubeEdge、Volcano、Karmada、Kmesh、openGemini、Sermant、OpenTiny、Kuasar 等技术大咖，邀您共探前沿技术，共领智能未来！完整议程已揭晓，欢迎报名参会 https://hdxu.cn/mitm

作者：王彬丞、杨志佳、刘家伟随着万物互联时代快速到来，5G网络普及导致边缘设备产生的数据量快速增长。普通的边缘设备计算能力不足，因此传统方法会将边缘侧数据集中汇聚到云端数据中心进行处理，容易对响应实时性、网络稳定性以及数据安全性产生挑战。为满足用户在大规模设备场景中更高的可用性需求，KubeEdge Device-IoT在1.12版本推出设备管理框架（Device Management Interface，DMI）。DMI整合设备管理接口，将管理面和业务面数据解耦，优化边缘计算场景下的设备管理能力，打造基于云原生技术的设备数字孪生管理平台。在 1.15 版本中，我们根据边缘设备管理的用户需求迭代更新 v1beta1 版本的设备管理  API，并以此为基础完善 DMI 数据面功能，承载于南向的 Mapper 开发框架 Mapper-Framework 中。Mapper-Framework 提供了全新的 Mapper 自动生成框架，框架中集成了 DMI 设备管理面与数据面能力，能够自动生成 Mapper 工程，用户只需实现其中的设备驱动的功能即可使用 Mapper 管理边缘设备，简化用户设计开发 Mapper 的复杂度，提升开发效率。针对新版本 Device-IoT 领域的更新，我们计划推出一系列的文章对这些特性进行详细的介绍，大致的文章大纲为：基于物模型的设备管理 API 设计与实现DMI 数据面能力设计与实现Mapper 开发框架 Mapper-Framework 设计与实现如何使用 Mapper 完成视频流数据处理如何使用 Mapper 实现设备数据写入如何从头开发一个 Mapper（以 modbus 为例） 本篇文章是系列文章的第一篇，主要介绍基于物模型的设备管理 API。    基于物模型的设备管理 API  为适应用户需求，在 v1.15.0 版本中，KubeEdge SIG Device-IoT 提出基于物模型的设备管理 API，将 Device Model 与 Device Instance从 v1alpha2 版本升级为 v1beta1 版本。新版本的设备管理 API 能够更全面的描述物理设备，新增了边缘设备数据处理的相关字段，能够适配 DMI 数据面能力增强功能。北向设备  API 结合南向的 DMI 接口，实现设备管理与设备数据处理，API 的主要更新包括：▍1. Device ModelDevice Model 用以描述一类边缘设备共同的设备属性。按照物模型的定义，Device Model 中新增了设备属性描述、设备属性类型、设备属性取值范围、设备属性单位等字段，如下图所示：// ModelProperty describes an individual device property / attribute like temperature / humidity etc. type ModelProperty struct { // Required: The device property name. // Note: If you need to use the built-in stream data processing function, you need to define Name as saveFrame or saveVideo Name string `json:"name,omitempty"` // The device property description. // +optional Description string `json:"description,omitempty"` // Required: Type of device property, ENUM: INT,FLOAT,DOUBLE,STRING,BOOLEAN,BYTES,STREAM Type PropertyType `json:"type,omitempty"` // Required: Access mode of property, ReadWrite or ReadOnly. AccessMode PropertyAccessMode `json:"accessMode,omitempty"` // +optional Minimum string `json:"minimum,omitempty"` // +optional Maximum string `json:"maximum,omitempty"` // The unit of the property // +optional Unit string `json:"unit,omitempty"` }上图展示了 Device Model 的核心 ModelProperty 字段，其中 Type 字段定义该属性的数据类型，AccessMode 定义该属性的访问方式，包括读写和只读两种。当访问方式设置为只读时，Mapper 会直接返回采集到的设备数据，反之当设置为读写后，Mapper 会对采集到的设备数据进行归一化等处理后再返回。Minimum 与 Maximum 则定义了设备属性的最大最小值，Unit 字段定义了设备属性的单位。下图展示了一个 Device Model 配置文件的示例：apiVersion: devices.kubeedge.io/v1beta1 kind: DeviceModel metadata: name: beta1-model spec: properties: - name: temp # define device property description: beta1-model type: INT # date type of device property accessMode: ReadWrite maximum: "100" # range of device property (optional) minimum: "1" unit: "Celsius" # unit of device property protocol: modbus # protocol for device, need to be same with device instance▍2. Device Instance一个 Device Instance 代表一个实际的设备对象。v1beta1 版本中，Device Instance 中内置的协议配置全部移除，包括 Modbus、OPC-UA、Bluetooth 等。用户可以通过可扩展的 Protocol 配置来设置设备协议，能够实现任何协议的设备接入。Modbus、OPC-UA、Bluetooth 等内置协议的 Mapper 仍会保留在 Mappers-go 仓库中，同时也会不断增加其他协议的内置 Mapper。type ProtocolConfig struct { // Unique protocol name // Required. ProtocolName string `json:"protocolName,omitempty"` // Any config data // +optional // +kubebuilder:validation:XPreserveUnknownFields ConfigData *CustomizedValue `json:"configData,omitempty"` } type CustomizedValue struct { Data map[string]interface{} `json:"-"` }此外，为增强 DMI 数据面功能，本次更新在 Device Instance 的设备属性中增加了设备数据处理的相关配置，例如设备上报频率、数据推送频率、属性是否上报云端、设备数据推送方式，如下图所示。type DeviceProperty struct { ... // Define how frequent mapper will report the value. // +optional ReportCycle int64 `json:"reportCycle,omitempty"` // Define how frequent mapper will collect from device. // +optional CollectCycle int64 `json:"collectCycle,omitempty"` // whether be reported to the cloud ReportToCloud bool `json:"reportToCloud,omitempty"` // PushMethod represents the protocol used to push data, // please ensure that the mapper can access the destination address. // +optional PushMethod *PushMethod `json:"pushMethod,omitempty"` }ReportCycle 字段定义了 Mapper 向用户数据库、用户应用推送数据的频率；CollectCycle 字段定义了 Mapper 向云端上报数据的频率；ReportToCloud 字段定义了 Mapper 采集到的设备数据是否需要上报云端；PushMethod 字段定义了 Mapper 推送设备数据的方式。目前提供 HTTP、MQTT 以及 OpenTelemetry 等方式向用户应用推送数据，并内置集成 InfluxDB、MySQL、Redis、TDengine 数据库。用户能够通过配置文件控制Mapper 向用户应用、用户数据库中定时推送设备数据，也能够通过 API 主动拉取设备数据，实现设备数据处理方式的多样化，相比于将所有数据推送至云端再行处理的传统方法，能够有效减少云边通信阻塞的风险。下图展示了一个 Device Instance 配置文件的示例：apiVersion: devices.kubeedge.io/v1beta1 kind: Device ... spec: properties: - name: temp collectCycle: 2000 # The frequency of reporting data to cloud, 2 seconds reportCycle: 2000 # The frequency of data push to user applications or databases, 2 seconds reportToCloud: true # Decide whether device data needs to be pushed to the cloud pushMethod: mqtt: # Define the MQTT config to push device data to user app address: tcp://127.0.0.1:1883 topic: temp qos: 0 retained: false visitors: # Define the configuration required by the mapper to access device properties (e.g. register address) protocolName: modbus configData: register: "HoldingRegister" offset: 2 limit: 1 protocol: # Device protocol. The relevant configuration of the modbus protocol is defined in the example. protocolName: modbus configData: serialPort: '/dev/ttyS0' baudRate: 9600基于 v1beta1版本的设备管理 API，我们以 Kubernetes CRD 的形式将 Device Model 与 Device Instance 引入 KubeEdge 集群。如需要更多详细的信息，可以参考设备管 API 的 proposal 文件[1] 以及相关 PR[2]。在本系列的下一篇文章中，我们会对 DMI 数据面能力的支持进行详细的介绍。▍相关链接[1]  docs/proposals/device-crd-v1beta1.md：cid:link_1[2]  相关PR：device crd v1beta1 and API definition：cid:link_2【更多KubeEdge资讯推荐】玩转KubeEdge保姆级攻略——环境搭建篇玩转KubeEdge保姆级攻略——环境搭建篇《玩转KubeEdge保姆级攻略——环境搭建篇》课程主要介绍如何通过华为云服务快速搭建一套KubeEdge边缘计算开发平台及部署Sedna、EdgeMesh等KubeEdge生态组件。课程免费学习链接：cid:link_0KubeEdge社区介绍：KubeEdge是业界首个云原生边缘计算框架、云原生计算基金会（CNCF）唯一毕业级边缘计算开源项目，社区已完成业界最大规模云原生边云协同高速公路项目（统一管理10万边缘节点/50万边缘应用）、业界首个云原生星地协同卫星、业界首个云原生车云协同汽车、业界首个云原生油田项目，开源业界首个分布式协同AI框架Sedna及业界首个边云协同终身学习范式，并在持续开拓创新中。KubeEdge网站 :  https://kubeedge.ioGitHub地址 : cid:link_3Slack地址 : 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 1.19.0版本现已正式发布。新版本在节点和设备方面引入了多个新特性，同时带来了全新版本的 Dashboard。 KubeEdge v1.19 新增特性：支持边缘节点上报 Event支持边缘节点 OTA 升级Mapper 支持设备数据写入Mapper 框架新增支持 OpenTelemetry全新版本 Dashboard  新特性概览  ▍支持边缘节点上报 EventKubernetes Event 作为集群中事件的报告，可以反馈节点、Pods 等集群资源的状态变化。在1.19版本中，EdgeCore 支持了边缘 Event 的上报，用户可以直接在云端通过kubectl get events 或者kubectl describe {resource_type} {resource_name} 获取边缘节点或者 pods 等状态。该特性在1.19版本中默认关闭，使用EdgeCore时执行--set modules.edged.reportEvent=true 或者如下修改 EdgeCore 配置参数并重启 EdgeCore。apiVersion: edgecore.config.kubeedge.io/v1alpha2 kind: EdgeCore featureGates:   requireAuthorization: true modules:   ...   edged:     reportEvent: true ...更多信息可参考：cid:link_3cid:link_4▍支持边缘节点 OTA 升级新版本在节点升级 NodeUpgradeJob 基础上新增了边端节点卡点确认和对镜像摘要的验证。卡点确认可以使节点升级下发到边缘节点后，在用户得到确认后才进行升级。镜像摘要验证可以确保在边缘节点待升级的 kubeedge/installation-pacakge 镜像是安全可靠的。在1.19版本中，我们可以通过 YAML 配置 NodeUpgradeJob 的 imageDigestGatter 来定义镜像摘要，value 用于直接定义摘要的值，registryAPI 用于通过 registry v2 接口获取镜像摘要，两者互斥，如果都没有配置则在升级时不进行镜像摘要的校验，样例：spec:   ...   imageDigestGatter:     value: ""     registryAPI:       host: ""       token: ""我们还可以通过 YAML 配置 NodeUpgradeJob 的 requireConfirmation 来定义是否要在边端进行确认操作，样例：spec:   ...   requireConfirmation: true当 requireConfirmation 设置为 true 时，在边端节点升级任务下发到边端后，任务状态会更新为 confirmation 状态等待边端发起确认命令后再继续进行升级。我们可以通过执行 keadm ctl 指令进行确认，以继续升级任务：keadm ctl confirm或者调用 Metaserver 接口进行确认，以继续升级任务：POST http(s)://localhost:<metaserver_port>/confirm更多信息可参考：cid:link_2cid:link_5cid:link_6▍Mapper 支持设备数据写入 Mapper 当前能够采集设备数据并上报，但在设备数据写入方面仍不完善。1.19版本在 Mapper-Framework 中增加了设备数据写入的能力，允许用户通过 Mapper 提供的 API 调用 device method，对 device property 完成数据写入。Device method API目前基于物模型的 v1beta1 版本的设备管理 API 包含 device property 的定义，在1.19版本中，新增 device method 的定义。Device method 指设备能够被外部调用的能力或方法，一个 device method 能够控制多个 device property 值。用户能在 device-instance 文件中定义 device method，通过 device method 完成 device property 的控制、写入。spec:   ...   methods:     - name: ""       description: ""       propertyNames:       - ""设备数据写入在1.19中改进 Mapper API 能力，新增 device method 调用接口。用户能够调用相关的接口获取某个设备包含的所有 device method，以及 device method 的调用命令，通过返回的调用命令发起设备写入请求。device method 的具体功能实现需要用户自行在 Mapper 的设备驱动层中完成。更多信息可参考：cid:link_7cid:link_8▍Mapper 框架新增支持 OpenTelemetry 当前 Mapper 向用户应用推送设备数据默认内置 HTTP 与 MQTT 两种方式，但仍存在部分应用无法直接以这两种方式进行推送。在1.19版本中我们在数据面引入 OpenTelemetry 观测框架，能够封装设备数据并向多类应用或数据库推送数据，例如 GreptimeDB、 Prometheus 等，增强 Mapper 数据面推送设备数据的能力。spec:   ...   properties:     - name: ""       pushMethod:          otel：           endpointURL: ""更多信息可参考：cid:link_9▍全新版本 Dashboard之前发布的 KubeEdge Dashboard，新版本使用主流的 Next.js 框架以及 MUI 样式库对其进行了重构。在新版本中我们重构并优化了近60个页面与组件，基于 KubeEdge 最新版本的后端 API，我们完善并增加了 Device 等相关功能页面，并在不影响原有功能的基础上将代码量减少至原先的四分之一。在这个过程中，我们整理完善了 Kubernetes 以及 KubeEdge 后端接口的 Typescript 类型定义，并将依赖的后端接口更新至最新版本，确保其与最新的 KubeEdge 兼容。更多信息可参考：cid:link_10 版本升级注意事项 下个版本（v1.20），EdgeCore的配置项edged.rootDirectory的默认值将会由/var/lib/edged切换至/var/lib/kubelet，如果您需要继续使用原有路径，可以在使用keadm 安装EdgeCore时设置 --set edged.rootDirectory=/var/lib/edged。从1.19版本开始，请在使用 keadm 安装 KubeEdge 时，使用--kubeedge-version 指定版本，--profile version 已废弃。▍致谢感谢 KubeEdge 社区技术指导委员会 (TSC)、各 SIG 成员对v1.19版本开发的支持与贡献，未来 KubeEdge 将持续在新场景探索与支持、稳定性、安全性、可扩展性等方面持续发展与演进！▍相关链接Release Notes：cid:link_1【更多KubeEdge资讯推荐】玩转KubeEdge保姆级攻略——环境搭建篇玩转KubeEdge保姆级攻略——环境搭建篇《玩转KubeEdge保姆级攻略——环境搭建篇》课程主要介绍如何通过华为云服务快速搭建一套KubeEdge边缘计算开发平台及部署Sedna、EdgeMesh等KubeEdge生态组件。课程免费学习链接：cid:link_0KubeEdge社区介绍：KubeEdge是业界首个云原生边缘计算框架、云原生计算基金会内部唯一孵化级边缘计算开源项目,社区已完成业界最大规模云原生边云协同高速公路项目（统一管理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/

展望未来科技前沿，探索云原生边缘计算与边缘AI的无限可能！本期直播我们将解读业界首个云原生边缘计算框架KubeEdge的架构设计，如何实现边云协同AI，将AI能力无缝下沉至边缘，让AI赋能边侧各行各业，构建智能、高效、自治的边缘计算新时代，共同探索智能边缘的新篇章！直播链接：cid:link_0Q：云边协同推理是在云和边各一个模型吗？是通过什么指标将任务卸载到云端呢？A:sedna案例中云边协同推理是将一个大模型部署在云端，并将一个小模型部署在边缘端，对于简单的推理任务可以直接在边端推理，针对较难的任务可以由云端大模型推理。我们可以设置一个置信度阈值指标判断推理任务是否是难例，将难例使用云端大模型推理。Q：k8s 调用 kubeEdge 服务兼容性不匹配，如何解决？A:可能是因为版本的原因，一个kubeedge的版本能够兼容3个k8s的版本，需要安装合适版本的k8s。Q：边缘节点的故障恢复，KubeEdge是如何处理的？A:KubeEdge利用边缘侧轻量级数据库实现了云边消息元数据的持久化，这是其故障恢复能力的重要基础。通过将Pod、ConfigMap等基础元数据持久化在边缘节点上，确保即使在边缘节点离线或重启后，这些元数据也能被保留下来。这样，当边缘节点重新上线时，它可以直接从本地获取这些元数据，快速恢复应用的状态。Q：现在安装KubeEdge最简单的方式有推荐吗？A:社区推荐大家使用官方安装组件keadm进行安装，使用keadm安装时在云端节点只需执行keadm init命令进行初始化，获取秘钥后在边缘节点上执行keadm join命令即可。详细的安装教程可以参考官方文档https://kubeedge.io/docs/setup/install-with-keadm。此外，对于想试用KubeEdge功能的初学者，还可以使用keink工具自动创建一个KubeEdge集群，可以参考https://github.com/kubeedge/keinkQ：KubeEdge在边缘AI场景下如何提升模型的推理效率？A:kubeedge一方面借助Kubernetes的容器编排能力，实现了边缘AI应用的自动化部署和管理。另一方面还提出边缘AI智能框架sedna，其边云协同的理念能借助云端充足的资源提升边缘模型的性能，也可以使用边云协同推理提升系统推理效率。Q：kubeedge是否在边缘异常断电文件系统损坏做了相关优化， 边缘侧电力稳定性有可能较差，会存在异常断电场景A:kubeedge主要是对云边消息传递的可靠性做了增强，使用一个轻量级数据库存储云边控制命令的元数据，对于边缘节点的文件系统没有做相关的功能增强。Q：介绍一下边缘节点和kubeEdge的部署A:我们目前有三种方式部署kubeedge，分别是采用keadm、二进制部署以及keink自动部署，相关文档可以参考https://kubeedge.io/docs/category/setupQ：边缘AI在哪些行业有应用前景？A:边缘AI在智慧城市、智能家居、智慧医疗、AR/VR技术等方面有着广阔的应用前景。Q：边缘计算环境中，KubeEdge如何保障数据的安全性和隐私性？A:KubeEdge在节点安全方面，采用了容器隔离、CNI网络安全、节点入侵检测和容器自愈等技术。在访问控制方面，利用Kubernetes的RBAC（基于角色的访问控制）权限管理功能，能够对集群资源进行细粒度的访问控制。Q：云边之间的数据传输是否支持视频格式的传输？A:这里我们主要考虑到视频一般的传输数据量是很大的，如果使用云边通道进行传递会导致严重的通信负荷，使用目前在kubeedge 1.17版本的特性中我们只实现将摄像头采集到的视频流转化成帧文件或者视频片段存在边缘节点上，暂时不支持向云端传输。Q：CDN部署过程中，怎么保证节点容器有序和可控的升级？ 是否支持版本的A/B 测试？ 怎么对升级过程进行校验？A:可以通过分批升级与组内升级并发控制、细粒度版本设置、升级校验等方式解决以上问题，可以参考https://kubeedge.io/zh/case-studies/ctyun/Q：对于数据孤岛问题。对于需要对设备调节参数的场景，同一租户在不同楼宇中的控制系统，甚至电力系统部互通。那么对于这种需要预测的参数怎么去调整？同样的情况下，基于安全原因，不支持打洞，那edgemesh是不是就不能用了？A:可以采用sedna中提供的联邦学习能力，在边缘侧直接进行模型训练，只把训练得到的模型参数上传云端。Edgemesh核心的特点就是使用中继和P2P打洞技术联通边缘节点。Q：云边协同推理是根据哪些指标将任务卸载到云端呢？A:在sedna有关云边协同推理的案例中，是通过设置一个阈值指标用于衡量推理任务是否是难例，可以将难例放置在云端进行推理。Q：Sedna的推算准确率高吗？达到了什么样的程度？A:sedna的定位主要是为了将用户已有的AI应用下沉至边缘侧，能够让用户部署更便捷，推算的准确度一般是和用户的训练得到的模型相关。Q：云端训练后的结果如何通过局域网推送到边缘端设备？A:可以通过云边通道、edgemesh来进行通信。Q：对比其他边缘计算框架，KubeEdge有哪些独到之处？A:KubeEdge的核心理念是基于Kubernetes提供的云原生能力，在边缘计算场景下进行了增强，所以一方面有云原生的基础能力支持，比如利用容器化技术屏蔽边缘复杂的底层硬件环境、利用云原生管理技术能够让故障的用户应用迅速回滚；另一方面做了组件轻量化、云边消息可靠性增强以及边缘设备管理能力增强，更加适合云原生边缘计算场景。Q：因docker的问题边端安装时基础环境镜像无法下载的问题怎么处理，官方是否有备用镜像库A:可以在能够下载镜像的节点上下载镜像，再打包至边缘节点。Q：分集群部署K8s的控制面和集群太多，怎么构建统一的CDN调度平台又不会过度占用机器资源？A:案例中CDN管理平台是在大区的区域中心、数据中心上部署k8s集群，通过kubeedge纳管边缘节点，具体的技术实现可以参考kubeedge官网的案例解读https://kubeedge.io/zh/case-studies/ctyun/Q：如何评估一个应用场景是否适合采用KubeEdge进行边缘AI部署？A:可以看具体的应用场景是否有云边协同的需求Q：Sendna的模型管理中，模型文件量化是如何处理的？模型work是独立运行在容器里面的还是需要和业务相结合的，例如视频的解码、推理、编码不放在一个容器里面的话延时是否会有问题？A:需要根据实际的使用场景判断，比如解码、推理、编码容器是部署在一个节点上、或者部署在多个节点上的时延是不同的。Q：脸检测模型最多同时检测到多少张脸啊？A:需要针对模型的性能、节点资源等角度具体分析。Q：karmada和KubeEdge有哪些区别？A:karmada是面向多云原生集群编排的，kubeedge主要面向云原生边缘计算场景。Q：如何解决边缘节点样本数量少的问题？A:kubeedge sedna支持多种训练和推理模式，其中终身学习主要用于解决小样本与边缘数据异构问题。Sedna会在云节点上部署一个知识库，能够辅助边缘端完成推理，并不断学习未知任务更新知识库。Q：KubeEdge最大支持管理多少规模边缘节点？A:目前有案例表明kubeedge接入的边缘节点规模突破10万，可以参考https://kubeedge.io/zh/blog/scalability-test-reportQ：KubeEdge如何处理多租户环境下的资源隔离？A:kubeedge依然保留了k8s的原生能力，因此可以通过创建命名空间、创建资源配额等的方式完成多租户环境下的资源隔离。Q：KubeEdge如何与云服务集成？A:KubeEdge核心理念是在原有Kubernetes云原生能力的基础上，面向边缘场景做了功能的增强，例如云边传递消息可靠性的增强、组件的轻量化，能够依托目前成为事实标准的Kubernetes api完成边缘与云上一致的使用体验，因此云服务依然可以参考传统Kubernetes中的部署方式进行部署。Q：云端可以批量升级边缘吗？A:在KubeEdge 1.16版本中，我们对边缘节点的批量升级这一特性做了功能增强，NodeUpgradeJob 的 Kubernetes API 进行边缘节点的一键化、批量升级。API 支持边缘节点的升级预检查、并发升级、失败阈值、超时处理等功能。对此，KubeEdge 支持了云边任务框架。社区开发者将无需关注任务控制、状态上报等逻辑实现，只需聚焦云边任务功能本身。 具体信息可参考https://kubeedge.io/blog/release-v1.16#support-cloud-and-edge-components-upgradeQ：EdgeMesh对边缘站点有哪些要求？A:运行EdgeMesh的边缘节点需要满足正常kubeedge对于边缘节点的要求，例如需要部署容器运行时、还需要满足硬件资源的一些限制。Q：KubeEdge如何处理边缘计算中的网络不稳定问题？A:KubeEdge针对边云连接不稳定、时常断连的情况，做了消息可靠性的增强，也是KubeEdge的核心特性之一。云上向边缘端下发控制命令时会检查边缘是否回传了ack应答，以此验证消息是否下发成功，并且云端会将消息进行编号，记录消息的下发。当边缘端长期断链后再次连接时，就不需要将消息全部重新发送，避免造成带宽冲击。另一方面，我们还实现了边缘自治的能力，在边缘节点上部署了一个轻量级的数据库，云上发送到边缘的元数据会保存在这个数据库中进行持久化，在边云连接长时断开或者边缘节点宕机重启后，能从边缘数据库中恢复用户应用。Q：EdgeMesh Agent之间打洞失败时怎么判断流量是否中转成功？A:当EdgeMesh打洞失败时可以使用EdgeMesh-server来中继流量，确保流量中转成功。Q：如果对安全要求很高的情况，那edgemesh的打洞不被允许，那这个特性是不是也用不了了。A:Edgemesh需要在边缘节点跨局域网时通过P2P打洞和中转技术才能完成边缘节点间的通信。Q：怎么降低两个边缘节点上的流量经过 EdgeMesh中转的网络时延？A:可以将EdgeMesh中继节点部署在地理位置适中的位置，以缩短数据传输的物理距离；也可以使用负载均衡技术将流量均匀分配到多个中继节点上，避免单个节点过载，从而提高整体的网络性能和降低时延。Q：1.12.7版本边端启动一段时间后云端可正常获取到边端的cpu，内存等状态信息，但运行一段时间后（一天或两天不固定）会出现边端状态信息上报失败连接超时，但除状态信息外其他都正常。边端重启后即恢复正常，这种情况可能有哪些原因造成的A:可以查看日志中是否有其他报错，例如channel已满，也可以使用go pprof等工具查看是否有内存泄露或者goroutine泄露的情况。Q：边缘设备开发有无官方开发板？A:目前我们已经内置了一些典型边缘设备协议的mapper插件，例如modbus、onvif等，用户可以直接使用我们提供的mapper对边缘设备进行管理，也可以仿照内置的mapper，自行通过mapper-framework开发框架实现其他协议mapper。内置的mapper地址为https://github.com/kubeedge/mappers-goQ：kubeEdge连入k8s如何防止抖动（经常断了又连接上）呢，毕竟数量太多的话会对集群造成影响A:kubeedge针对边云连接不稳定、时常断连的情况，做了消息可靠性的增强，也是kubeedge的核心特性之一。云上向边缘端下发控制命令时会检查边缘是否回传了ack应答，以此验证消息是否下发成功，并且云端会将消息进行编号，记录消息的下发。当边缘端长期断链后再次连接时，就不需要将消息全部重新发送，避免造成带宽冲击。另一方面，我们还实现了边缘自治的能力，在边缘节点上部署了一个轻量级的数据库，云上发送到边缘的元数据会保存在这个数据库中进行持久化，在边云连接长时断开或者边缘节点宕机重启后，能从边缘数据库中恢复用户应用。Q：KubeEdge对于跨地域的边缘计算部署有哪些支持？A:KubeEdge 1.11版本引入了“边缘节点分组管理”新特性，该特性允许将边缘节点按地区划分为节点组，使得应用所需资源可以打包成一个整体在节点组上进行部署。这种分组方式有效降低了边缘应用生命周期管理的复杂度，并减少了运维成本。Q：边缘设备的数量有限制吗？A:目前已经有案例表明kubeedge能够支持上万边缘设备的管理Q：KubeEdge支持哪些类型的工作负载？A:由于kubeedge的核心理念是基于k8s云原生能力，在边缘场景下做了一些功能的增强，因此传统k8s中工作负载的类型在kubeedge中都能够支持，例如deployment、job等。Q：云原生边缘计算与传统云计算相比有哪些优势？A:第一，云原生边缘计算拥有低延迟与高实时性，能够更快地响应用户请求，提供更高的实时性服务。第二，云原生边缘计算能够保障数据隐私与安全，能够在本地或靠近数据产生的地方处理数据，减少了数据传输的中间环节，从而提高了数据的安全性。第三，云原生边缘计算能带来带宽与成本优化。数据在边缘端处理能够减少数据传输的距离，降低了对带宽的需求，从而有助于降低网络成本。Q：KubeEdge对于边缘设备的异构性是如何处理的？A:kubeedge通过mapper插件对边缘设备进行管理，mapper中集成了设备驱动，可以按照对应的协议访问物理设备、获取边缘设备的数据或者状态。Mapper通过实现edgecore中DMI这个设备管理统一接口完成自身向集群的注册，最终完成设备的纳管。DMI采用grpc+uds的机制，定义了通用的接口，能够屏蔽设备之间的差异。Q：在KubeEdge的sedna中，实现边云协同AI的具体步骤是怎么样的A:由于sedna定位并不是tensorflow pytorch这类的深度学习框架，而是提供把用户已有的AI应用能力下沉至边缘端，减少用户构建部署的成本。因此第一，用户需要根据典型的框架实现自己的AI应用，并根据sedna中的要求对代码做一些修改，主要是导入sedna边云协同推理库，设置推理阈值等，修改完成后可以打包为一个镜像；第二，需要实现sedna中定义的部分crd文件，例如model crd定义的用户模型参数；第三，提交AI任务。用户可以定义sedna中JointInferenceService之类的任务crd，提交至集群，由sedna完成部署。Q：KubeEdge中边缘端和云端是如何高效同步状态和配置信息A:kubeedge中需要用到多个组件共同协作，完成云边同步状态和配置信息。在云端主要是依靠cloudhub和synccontroller，synccontroller中一方面会对云端下发的消息进行记录并编号，保证消息下发的连续性，另一方面也会定期同步云边状态，cloudhub则是实际执行消息传递的。在边缘端有edgehub，metamanager等组件来辅助云边通信，edghehub和cloudhub对应，接收cloudhub下发的消息并转发，metamanager一方面实现边缘自治，把核心元数据保存在边缘数据库中，一方面会把edgehub中的消息转发到边缘其他模块。Q：在边云协同过程中，如何处理数据的实时性与一致性？A:可以依赖kubeedge提供的云边消息同步机制。云端下发消息时会监测边端是否回传ACK应答，确保消息下发成功，另一方面云端使用synccontroller对云端下发的消息进行记录并编号，保证消息下发的连续性，也能定期同步云边状态。Q：KubeEdge在管理边缘设备必须通过mapper吗A:kubeedge是需要mapper来管理边缘设备的，mapper是kubeedge中的设备管理插件，其中集成了对应协议设备的驱动程序，能够实际连接到物理设备，并且获取设备状态与数据。Mapper实现了edgecore中DMI的相关接口，能将自身注册入kubeedge集群，并且将管理的设备状态数据通过DMI接口上报到edgecore，edgecore会对这些消息进行处理封装，通过云边通道上传到云端cloudcore，cloudcore中的devicecontroller就是edgecore中上报的设备信息与k8s apiserver通信的桥梁，完成对边缘设备的管理。Q：基于KubeEdge云原生边缘计算如何保障数据处理的实时性呢？A:kubeedge整合了云计算的优势和边缘计算的优势，能在靠近物或数据源头的网络边缘侧就近处理海量数据，具有毫秒级的实时响应。Q：KubeEdge安装部署有什么要求A:KubeEdge是依赖Kubernetes的，在部署前需要先拥有一个Kubernetes集群，同时KubeEdge也是以容器化的形式管理用户边缘应用的，所以也需要下载相应的容器运行时，比如containerd。Docker等，当然因为目前Kubernetes已经不在使用docker作为默认的容器运行时，所以使用高于1.14版本的KubeEdge时需要使用cri-dockerd，相关容器运行时的安装以及注意事项在我们的官网文档中也有介绍https://kubeedge.io/docs/setup/prerequisites/runtime/，大家可以参考。Q：KubeEdge如何将AI能力下沉至边缘？有哪些具体的技术实现和优化措施？A:kubeedge提出了边缘智能框架sedna，基于KubeEdge提供的边云协同能力，支持用户现有AI类应用无缝下沉到边缘，降低用户构建与部署成本、提升模型性能、保护数据隐私。Sedna能够提供基础的边云协同数据集管理、模型管理功能，具有协同推理、增量学习、联邦学习和终身学习的能力，能够更好的实现边云协同AI。Q：是否依赖边缘节点算力大小？A:kubeedge从部署的角度来说实现了组件的轻量化，目前已经能将内存占用降低至70M左右，减少了边缘节点的资源要求。除安装需求外，边缘节点算力的需求主要与用户部署的边缘应用相关，需要根据用户应用的大小评测具体的算力消耗。Q：KubeEdge的架构设计主要关注哪些关键组件？A:kubeedge云端和边端都运行了众多组件，其中云端组件包括EdgeController、deviceController、Synccontroller、cloudhub等，边端组件包括edgehub、MetaManager、edged、devicetwin、EventBus、ServiceBus等，每个组件都有重要的功能，具体的介绍可以访问我们的官方文档 https://kubeedge.io/docs/category/architectureQ：对于KubeEdge的边缘节点应该怎么配置？A:目前官方推荐大家使用keadm这个安装管理工具来部署kubeedge集群，可以在获得云端kubeedge集群的token后，使用keadm join命令加入kubeedge集群，并且自动部署edgecore组件。Q：KubeEdge与K8s有什么关系，与k8s的兼容性如何，是否支持最新版本的k8s？A:Kubeedge核心理念是基于k8s原生能力，在边缘计算场景下做了一些增强，因此与k8s的兼容性是kubeedge的核心特点之一。一般来说一个Kubeedge版本可以兼容3个版本的k8s，在每三个月kubeedge发布版本时，都会升级k8s的依赖，我们近期刚发布的1.18版本已经能够兼容1.29 1.28 1.27三个版本的k8s，欢迎大家使用。Q：边缘计算\边缘AI\云计算有什么区别？A:云是中心化、按需获取的大规模计算资源共享池，服务于广大的区域，能够提供几乎无限的算力；边缘计算是靠近数据产生源头的计算能力，服务于广小的区域，提供受限的算力。边缘AI是指在边缘计算环境中实现的人工智能。Q：KubeEdge在边云协同中如何处理数据安全与隐私保护？A:KubeEdge在数据传输过程中采用了全链路加密技术，确保数据在云端和边缘端之间的传输过程中不被窃取或篡改。这种加密方式涵盖了数据的整个传输路径，从源头到目的地都保持数据的安全性。Q：KubeEdge如何应对边缘设备的动态性和不确定性？A:kubeedge采用mapper设备管理插件来实际管理物理设备。在mapper中承载了DMI数据面能力，能够按照用户设置的周期定时采集设备状态与数据，并进行数据推送。Q：KubeEdge是否支持边缘设备的本地自治？网络中断时，边缘节点能否独立运行和做出决策？可以中断多久？A:kubeedge针对边云经常断连的情况，在边缘节点上部署了轻量级的数据库，可以存储云端命令的核心元数据，在边缘节点断开连接时能够依靠数据库维持边缘应用和设备稳定运行。在证书未过期的情况下理论上可以保持断连状态，随时重新连接。Q：KubeEdge是否对边缘侧异常断电场景有优化？边缘侧电力稳定性比较弱 经常断电A:kubeedge主要是对云边消息传递的可靠性做了增强，在边缘节点上部署一个轻量级数据库存储云边控制命令的元数据，在边缘节点断电重启时可以依据数据库的数据进行恢复想要了解更多云原生相关知识，欢迎观看DTSE Tech Talk 系列技术直播

当边缘计算遇到AI，会迸发出怎样的火花？KubeEdge带你玩转云原生边缘计算技术与应用，一起体验开源社区，赋能多领域、多场景边云协同AI智算！KubeEdge是华为云发起的CNCF首个云原生边缘计算项目，也是业界首个云原生边缘计算框架。作为活跃而成熟的开发者社区，KubeEdge面向开发者与企业提供开源开放的云原生边缘计算技术——面向边缘设备管理领域发布了云原生边缘设备管理接口DMI，支持边缘设备以云原生的方式接入集群，面向边缘AI的场景实现了业界首个分布式AI协同框架子项目Sedna；面向边缘容器网络通信领域实现Edgemesh……欢迎开发者前往KubeEdge社区免费体验最新版本！      如果你是云原生新手，我们也会大家准备了全套能量包课程——华为云云原生王者之路集训营课程，一起开启云原生与开源之旅吧！本期我们邀请了华为云云原生专家Elias老师坐阵，和大家一起探讨关于边缘AI基础设施的话题。【问题参考】（包括不限于）边缘计算\边缘AI\云计算有什么区别？云端可以批量升级边缘吗？KubeEdge支持哪些类型的工作负载？KubeEdge在边缘AI场景下如何提升模型的推理效率？在边云协同中如何处理数据安全与隐私保护？……对于云原生边缘计算的技术与应用，你有哪些疑问呢？【活动时间】2024年8月21日-9月5日【参与方式】直接在此活动帖下方回帖提问即可。【获奖规则】优质问题奖与积极互动奖不叠加参与云咖问答的提问我们会整理在问答专题中，你的提问将会帮助更多的开发者~欢迎大家踊跃提问，积极互动~【活动规则】1、开发者用户发布的提问，仅限于本期产品，其他产品求助帖不参与此次活动，将视为无效内容，否则取消该用户获奖资格。（其他产品求助可发帖到相应的版块进行提问）；2、本次活动不限用户的总提问数及连续提问数，但需保证提问质量，如华为云社区小编认定参与用户有恶意灌水嫌疑，则取消该用户获奖资格；3、本次活动将根据实际参与情况发放奖励，包括但不限于用户百分之百中奖或奖项轮空的情况；以上奖品均为实物奖品，具体发放视出库情况而定；4、每期活动预计于结束后七天内完成奖项公示，并于结束后15个工作日内完成邮寄。【温馨提示】1、请务必使用个人实名账号参与活动（IAM、企业账号等账号参与无效）。如一个实名认证对应多个账号，只有一个账号可领取奖励，若同一账号填写多个不同收件人或不同账号填写同一收件人，均不予发放奖励。2、所有获得奖品的获奖用户，请于获奖后3日内完成实名认证，否则视为放弃奖励。

中奖结果公示感谢各位小伙伴参与本次活动，欢迎关注华为云DTSE Tech Talk 技术直播更多活动~本次活动获奖名单如下（部分视频号抽奖用户无账号名）：账号名 奖项名称 奖品名称 linghz666 口令抽奖 华为云定制T恤hw_008618020934589_01 口令抽奖 华为云定制T恤xj120141121 优质提问  华为云定制双肩包视频号抽奖 华为云定制Polo衫视频号抽奖 华为云定制Polo衫视频号抽奖 华为云定制Polo衫

1. 引言随着物联网（IoT）和边缘计算技术的飞速发展，企业和开发者面临着如何管理大规模分布式设备的挑战。KubeEdge作为一个开源平台，可以帮助扩展Kubernetes的能力，将容器编排从云延伸到边缘节点。本文将在Ubuntu 22.04上详尽介绍如何使用KubeEdge，并通过实际案例演示其应用。2. 什么是kubeEdge2.1 KubeEdge简介KubeEdge是由CNCF（云原生计算基金会）孵化的开源平台，其设计目的是扩展Kubernetes的能力至边缘计算设备。它提供了统一的边云协同管理能力，使得边缘设备和云端能够无缝对接，构建一个灵活高效的边缘计算架构。2.2 架构介绍KubeEdge 由以下组件组成：Edged: 在边缘节点上运行并管理容器化应用程序的代理。EdgeHub: Web 套接字客户端，负责与 Cloud Service 进行交互以进行边缘计算（例如 KubeEdge 体系结构中的 Edge Controller）。这包括将云侧资源更新同步到边缘，并将边缘侧主机和设备状态变更报告给云。CloudHub: Web 套接字服务器，负责在云端缓存信息、监视变更，并向 EdgeHub 端发送消息。EdgeController: kubernetes 的扩展控制器，用于管理边缘节点和 pod 的元数据，以便可以将数据定位到对应的边缘节点。EventBus: 一个与 MQTT 服务器（mosquitto）进行交互的 MQTT 客户端，为其他组件提供发布和订阅功能。DeviceTwin: 负责存储设备状态并将设备状态同步到云端。它还为应用程序提供查询接口。MetaManager: Edged 端和 Edgehub 端之间的消息处理器。它还负责将元数据存储到轻量级数据库（SQLite）或从轻量级数据库（SQLite）检索元数据。3. 网络组网图3.1 网络拓扑在具体的安装步骤之前，我们先了解一下KubeEdge的组网拓扑。这有助于更好地理解后续的安装和配置过程。以下是KubeEdge的组网拓扑图：3.2 组网原理介绍：网络环境的要求：KubeEdge要求边端能够访问云端的cloudcore暴露的端口（10000-10004）注意：单方面要求边端能够访问云端。不要求云端可以访问边端。云端：在公有云上搭建k8s集群并部署KubeEdge的cloudcore。边缘节点：在自己的笔记本电脑上安装edgecore,连接到家庭交换机，最后通过宽带拨号连接到Internet，访问到云端。在企业私有云中创建vm充当边缘节点部署edgecore，通过虚拟交换机连接到数据中的交换设备（交换机，路由器），通过企业防火墙设备，访问到云端。通信：KubeEdge使用WebSocket协议来实现云和边缘之间的高效通信，特别是在其核心组件之间。以下是KubeEdge如何使用WebSocket的详细说明，WebSocket在KubeEdge中主要用于以下几个方面：心跳检测：为了确保连接的稳定性，EdgeCore和CloudCore之间会定期发送心跳消息，通过WebSocket连接检测对方的在线状态。如果在一定时间内没有收到心跳响应，则认为连接断开。自动重连：如果检测到WebSocket连接断开，EdgeCore会自动尝试重新连接CloudCore，确保云边之间的通信恢复。Kubernetes事件：KubeEdge需要将Kubernetes事件从云端传输到边缘节点。例如，当用户在云端通过Kubernetes API部署新的应用时，CloudCore会捕获这些事件，并通过WebSocket连接将事件发送到相应的EdgeCore，从而在边缘节点上进行相应的处理。设备管理事件：KubeEdge支持IoT设备管理，设备状态和事件信息也通过WebSocket连接在云和边缘之间传输。例如，设备的状态变化、数据采集等事件都会通过WebSocket进行实时同步。连接建立：EdgeCore启动时，会与CloudCore建立WebSocket连接。CloudCore充当WebSocket服务器，EdgeCore充当客户端。这种连接是持久化的，确保云和边缘之间的实时通信。数据传输：通过WebSocket连接，EdgeCore和CloudCore可以传输各种类型的数据，包括控制命令、应用部署信息、设备状态更新等。由于WebSocket支持全双工通信，数据可以在任意一端实时传输，而无需轮询。云边通信：事件传输：心跳检测和重连机制：4 环境安装在开始安装KubeEdge之前，需要先准备好基础环境。以下是需要安装的基本工具和依赖。4.1 安装依赖在云端方面，我们需要：Kubernetes 集群，集群安装请参考我的另外一篇文章：Kubernetes v1.27.1（kubeadm）部署在边缘，我们需要：容器运行时，现在我们支持：DockerContainerdCri-oVirtletMQTT 服务器（可选）4.2  安装cloudcore（云端）下面将详细介绍如何在Ubuntu 22.04上安装最新版本的KubeEdge。4.2.1  下载并安装KubeEdge软件包首先需要下载KubeEdge的二进制文件，并将其解压到指定目录。最新版本为v1.17.0：root@cloudcore:~# mkdir kubeEdge root@cloudcore:~# cd kubeEdge/ root@cloudcore:~/kubeEdge# curl -LO  https://github.com/kubeedge/kubeedge/releases/download/v1.17.0/keadm-v1.17.0-linux-amd64.tar.gz root@cloudcore:~/kubeEdge# tar -xvzf keadm-v1.17.0-linux-amd64.tar.gz root@cloudcore:~/kubeEdge# cd keadm-v1.17.0-linux-amd64 root@cloudcore:~/kubeEdge/keadm-v1.17.0-linux-amd64# sudo cp keadm/keadm /usr/local/bin/ root@cloudcore:~/kubeEdge/keadm-v1.17.0-linux-amd64# keadm -h     +----------------------------------------------------------+     | KEADM                                                    |     | Easily bootstrap a KubeEdge cluster                      |     |                                                          |     | Please give us feedback at:                              |     | https://github.com/kubeedge/kubeedge/issues              |     +----------------------------------------------------------+     Create a cluster with cloud node     (which controls the edge node cluster), and edge nodes     (where native containerized application, in the form of     pods and deployments run), connects to devices. Usage:   keadm [command] Examples:     +----------------------------------------------------------+     | On the cloud machine:                                    |     +----------------------------------------------------------+     | master node (on the cloud)# sudo keadm init              |     +----------------------------------------------------------+     +----------------------------------------------------------+     | On the edge machine:                                     |     +----------------------------------------------------------+     | worker node (at the edge)# sudo keadm join <flags>       |     +----------------------------------------------------------+     You can then repeat the second step on, as many other machines as you like. Available Commands:   completion  Generate the autocompletion script for the specified shell   config      Use this command to configure keadm   ctl         Commands operating on the data plane at edge   debug       debug function to help diagnose the cluster   deprecated  keadm deprecated command   gettoken    To get the token for edge nodes to join the cluster   help        Help about any command   init        Bootstraps cloud component. Checks and install (if required) the pre-requisites.   join        Bootstraps edge component. Checks and install (if required) the pre-requisites. Execute it on any edge node machine you wish to join   manifest    Checks and generate the manifests.   reset       Teardowns KubeEdge (cloud(helm installed) & edge) component   rollback    rollback edge component. Rollback the edge node to the desired version.   upgrade     Upgrade components of the cloud or the edge   version     Print the version of keadm Flags:   -h, --help   help for keadm Additional help topics:   keadm beta       keadm beta command Use "keadm [command] --help" for more information about a command.4.2.2 初始化CloudCore1、去除k8s controlplane节点的污点root@cloudcore:~# kubectl taint nodes cloudcore  node-role.kubernetes.io/control-plane:NoSchedule- node/cloudcore untainted root@cloudcore:~# root@cloudcore:~# kubectl describe node cloudcore | grep Taints Taints:             <none> root@cloudcore:~# 2、CloudCore负责云端与边缘节点的交互和管理。安装和初始化CloudCore如下：root@cloudcore:~# keadm init --advertise-address="182.92.163.65" --kubeedge-version=1.17.0 --kube-config=/root/.kube/config --set iptablesHanager.mode="external" Kubernetes version verification passed, KubeEdge installation will start... CLOUDCORE started =========CHART DETAILS======= Name: cloudcore LAST DEPLOYED: Sat Jun  1 21:18:03 2024 NAMESPACE: kubeedge STATUS: deployed REVISION: 1 注意：请指定kueedge的版本，默认安装的是v1.15.1root@cloudcore:~# kubectl get all -n kubeedge NAME                             READY   STATUS    RESTARTS   AGE pod/cloudcore-69d64c8b78-wrpq7   1/1     Running   0          11m NAME                TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)                                             AGE service/cloudcore   ClusterIP   10.105.194.25   <none>        10000/TCP,10001/TCP,10002/TCP,10003/TCP,10004/TCP   11m NAME                                    DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE daemonset.apps/edge-eclipse-mosquitto   0         0         0       0            0           <none>          11m NAME                        READY   UP-TO-DATE   AVAILABLE   AGE deployment.apps/cloudcore   1/1     1            1           11m NAME                                   DESIRED   CURRENT   READY   AGE replicaset.apps/cloudcore-69d64c8b78   1         1         1       11m 4.2.3 关闭云端防火墙root@cloudcore:~# systemctl status ufw.service ○ ufw.service - Uncomplicated firewall      Loaded: loaded (/usr/lib/systemd/system/ufw.service; enabled; preset: enabled)      Active: inactive (dead) since Thu 2024-05-30 10:29:18 CST; 4 days ago    Duration: 11h 56min 27.372s        Docs: man:ufw(8)    Main PID: 552 (code=exited, status=0/SUCCESS) May 29 22:32:51 cloudcore systemd[1]: Starting ufw.service - Uncomplicated firewall... May 29 22:32:51 cloudcore systemd[1]: Finished ufw.service - Uncomplicated firewall. May 30 10:29:18 cloudcore systemd[1]: Stopping ufw.service - Uncomplicated firewall... May 30 10:29:18 cloudcore ufw-init[180267]: Skip stopping firewall: ufw (not enabled) May 30 10:29:18 cloudcore systemd[1]: ufw.service: Deactivated successfully. May 30 10:29:18 cloudcore systemd[1]: Stopped ufw.service - Uncomplicated firewall. root@cloudcore:~# systemctl stop ufw.service root@cloudcore:~# systemctl disable ufw.service Synchronizing state of ufw.service with SysV service script with /usr/lib/systemd/systemd-sysv-install. Executing: /usr/lib/systemd/systemd-sysv-install disable ufw Removed "/etc/systemd/system/multi-user.target.wants/ufw.service". root@cloudcore:~# 4.2.4 打标签防止云端的一些damonset pod调度到边缘端root@cloudcore:~# kubectl get daemonset -n kube-system |grep -v NAME |awk '{print $1}' | xargs -n 1 kubectl patch daemonset -n kube-system --type='json' -p='[{"op": "replace","path": "/spec/template/spec/affinity","value":{"nodeAffinity":{"requiredDuringSchedulingIgnoredDuringExecution":{"nodeSelectorTerms":[{"matchExpressions":[{"key":"node-role.kubernetes.io/edge","operator":"DoesNotExist"}]}]}}}}]'注意：因为通常边缘计算的硬件条件都不好，这里我们需要打上标签，让一些云端damonset pod不扩展到edge节点上去。4.2.5 在云端设置安全组规则由于cloudcore 会暴露10000-10004端口。边缘端会通过此端口和云端交互.公有云的安全组一般不会开放这些端口，因此需要手动开启。root@cloudcore:~# kubectl get svc -n kubeedge NAME        TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)                                             AGE cloudcore   ClusterIP   10.110.56.18   <none>        10000/TCP,10001/TCP,10002/TCP,10003/TCP,10004/TCP   3d17h root@cloudcore:~# 4.3 安装EdgeCore（边缘侧）EdgeCore安装在边缘节点，用于运行实际的应用和处理数据。4.3.1 安装基础软件kevin@edgecore:~$ sudo apt-get update kevin@edgecore:~$ sudo apt-get install -y curl wget apt-transport-https4.3.2 安装与配置containerdStep 1: 更新包索引并安装必要的包kevin@edgecore:~$ sudo apt-get update kevin@edgecore:~$ sudo apt-get install -y apt-transport-https ca-certificates curl gnupg lsb-releaseStep 2: 添加阿里云的 Docker GPG 密钥kevin@edgecore:~$ curl -fsSL https://mirrors.aliyun.com/docker-ce/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg Step 3: 设置稳定版仓库kevin@edgecore:~$ echo \   "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://mirrors.aliyun.com/docker-ce/linux/ubuntu \   $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null Step 4: 更新包索引并安装 containerdkevin@edgecore:~$ sudo apt-get update kevin@edgecore:~$ sudo apt-get install -y containerd.ioStep 5: 配置 containerd创建或编辑 config.toml 配置文件：kevin@edgecore:~$ sudo containerd config default | sudo tee /etc/containerd/config.tomlStep 6: 要确保 cri 没有出现在 /etc/containerd/config.toml 文件中 disabled_plugins 列表内kevin@edgecore:~$ cat /etc/containerd/config.toml | grep -A 5 -B 5 "disabled_plugins" #cri 没有出现在 /etc/containerd/config.toml 文件中 disabled_plugins 列表内 disabled_plugins = [] imports = [] oom_score = 0 plugin_dir = "" required_plugins = [] root = "/var/lib/containerd"注意：如果你从软件包（例如RPM或者.deb）中安装 containerd，你可能会发现其中默认禁止了 CRI 集成插件。你需要启用 CRI 支持在KubeEdge场景下使用 containerd。要确保 cri 没有出现在 /etc/containerd/config.toml 文件中 disabled_plugins 列表内。如果你更改了这个文件，也请记得要重启 containerd。Step 7:  确保安装v1.6.0或更高版本的containerdkevin@edgecore:~$ sudo containerd --version containerd containerd.io 1.6.32 8b3b7ca2e5ce38e8f31a34f35b2b68ceb8470d89Step 8: 更新沙箱(pause)镜像，可以通过在containerd的配置文件中修改如下设置来实现：[plugins."io.containerd.grpc.v1.cri"]   sandbox_image = "kubeedge/pause:3.6"Step 9: 更新containerd的cgroup驱动[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]   ...   [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]     SystemdCgroup = trueStep 10: 启动并启用 containerd 服务kevin@edgecore:~$ sudo systemctl restart containerd kevin@edgecore:~$ sudo systemctl enable containerdStep 11:  查看containerd的状态kevin@edgecore:~$ sudo systemctl status containerd ● containerd.service - containerd container runtime      Loaded: loaded (/lib/systemd/system/containerd.service; enabled; vendor preset: enabled)      Active: active (running) since Mon 2024-06-03 01:37:00 UTC; 43s ago        Docs: https://containerd.io    Main PID: 62879 (containerd)       Tasks: 8      Memory: 13.0M         CPU: 374ms      CGroup: /system.slice/containerd.service              └─62879 /usr/bin/containerd4.3.3 配置 CNI 插件下载和安装 CNI 插件：kevin@edgecore:~$  sudo mkdir -p /opt/cni/bin kevin@edgecore:~$  curl -L https://github.com/containernetworking/plugins/releases/download/v1.5.0/cni-plugins-linux-amd64-v1.5.0.tgz | sudo tar -C /opt/cni/bin -xz kevin@edgecore:~$ ls -al /opt/cni/bin total 81544 drwxr-xr-x 2 1001  127     4096 May 20 07:23 . drwxr-xr-x 3 root root     4096 Jun  4 04:48 .. -rwxr-xr-x 1 1001  127  4272394 May 20 07:23 bandwidth -rwxr-xr-x 1 1001  127  4787319 May 20 07:23 bridge -rwxr-xr-x 1 1001  127 11430474 May 20 07:23 dhcp -rwxr-xr-x 1 1001  127  4422354 May 20 07:23 dummy -rwxr-xr-x 1 1001  127  4943785 May 20 07:23 firewall -rwxr-xr-x 1 1001  127  4344044 May 20 07:23 host-device -rwxr-xr-x 1 1001  127  3679567 May 20 07:23 host-local -rwxr-xr-x 1 1001  127  4440601 May 20 07:23 ipvlan -rw-r--r-- 1 1001  127    11357 May 20 07:23 LICENSE -rwxr-xr-x 1 1001  127  3750042 May 20 07:23 loopback -rwxr-xr-x 1 1001  127  4478854 May 20 07:23 macvlan -rwxr-xr-x 1 1001  127  4228716 May 20 07:23 portmap -rwxr-xr-x 1 1001  127  4600833 May 20 07:23 ptp -rw-r--r-- 1 1001  127     2343 May 20 07:23 README.md -rwxr-xr-x 1 1001  127  3956598 May 20 07:23 sbr -rwxr-xr-x 1 1001  127  3223795 May 20 07:23 static -rwxr-xr-x 1 1001  127  4503238 May 20 07:23 tap -rwxr-xr-x 1 1001  127  3837627 May 20 07:23 tuning -rwxr-xr-x 1 1001  127  4439832 May 20 07:23 vlan -rwxr-xr-x 1 1001  127  4102988 May 20 07:23 vrf配置 CNI 网络：创建 CNI 网络配置文件：kevin@edgecore:~$ sudo mkdir -p /etc/cni/net.d kevin@edgecore:~$ cat <<EOF | sudo tee /etc/cni/net.d/10-containerd-net.conflist {   "cniVersion": "0.4.0",   "name": "containerd-net",   "plugins": [     {       "type": "bridge",       "bridge": "cni0",       "isGateway": true,       "ipMasq": true,       "ipam": {         "type": "host-local",         "ranges": [           [{"subnet": "192.168.0.0/16"}]         ],         "routes": [           {"dst": "0.0.0.0/0"}         ]       }     },     {       "type": "portmap",       "capabilities": {"portMappings": true}     }   ] } EOFkevin@edgecore:~$ curl -LO https://github.com/containerd/nerdctl/releases/download/v1.7.6/nerdctl-1.7.6-linux-amd64.tar.gz kevin@edgecore:~$ sudo tar -C  /usr/local/bin -xzvf nerdctl-1.7.6-linux-amd64.tar.gz nerdctl containerd-rootless-setuptool.sh containerd-rootless.sh kevin@edgecore:~$ nerdctl --version nerdctl version 1.7.64.3.4  下载并安装KubeEdge软件包首先需要下载KubeEdge的二进制文件，并将其解压到指定目录。最新版本为v1.17.0：kevin@edgecore:~$ mkdir kubeEdge kevin@edgecore:~$ cd kubeEdge/ kevin@edgecore:~/kubeEdge$  curl -LO  https://github.com/kubeedge/kubeedge/releases/download/v1.17.0/keadm-v1.17.0-linux-amd64.tar.gz kevin@edgecore:~/kubeEdge$ tar -xvzf keadm-v1.17.0-linux-amd64.tar.gz kevin@edgecore:~/kubeEdge$ cd keadm-v1.17.0-linux-amd64 kevin@edgecore:~/kubeEdge/keadm-v1.17.0-linux-amd64# sudo cp keadm/keadm /usr/local/bin/4.3.5 测试网络的联通性1、从边端ping云端root@edgecore:/etc/kubeedge/config# ping 182.92.163.65 PING 47.109.202.113 (47.109.202.113) 56(84) bytes of data. 64 bytes from 47.109.202.113: icmp_seq=1 ttl=51 time=49.6 ms 64 bytes from 47.109.202.113: icmp_seq=2 ttl=51 time=49.1 ms ^C --- 47.109.202.113 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1002ms rtt min/avg/max/mdev = 49.135/49.345/49.556/0.210 ms 2、测试端口是否可以访问#cloudcore 监听的端口在10000-10004 root@edgecore:~# telnet 182.92.163.65 10000 Trying 47.109.202.113... Connected to 47.109.202.113. Escape character is '^]'. ^CConnection closed by foreign host. root@edgecore:~# telnet 182.92.163.65 10002 Trying 47.109.202.113... Connected to 47.109.202.113. Escape character is '^]'. ^CConnection closed by foreign host. root@edgecore:~# telnet 182.92.163.65 10003 Trying 47.109.202.113... Connected to 47.109.202.113. Escape character is '^]'. ^CConnection closed by foreign host. root@edgecore:~# telnet 182.92.163.653 10004 Trying 47.109.202.113... Connected to 47.109.202.113. Escape character is '^]'. ^CConnection closed by foreign host. root@edgecore:~# 4.3.6 获取云端tokenroot@cloudcore:~# keadm gettoken afc0ccb97b1f68c8607aa31584e8bd8f115cbca66d2bfbe21a782c866f589db9.eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE3MTc5NDU3NDB9.OJeQ1ewmQ_C3xFYrPmUJ7kOrqz1M5oTfKp4_fDCEMfM root@cloudcore:~#4.3.7 边缘节点加入云端1、运行keadm join命令加入云端root@edgecore:~/kubeEdge# sudo keadm join --cloudcore-ipport=182.92.163.65:10000 \ --token afc0ccb97b1f68c8607aa31584e8bd8f115cbca66d2bfbe21a782c866f589db9.eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE3MTc5NDU3NDB9.OJeQ1ewmQ_C3xFYrPmUJ7kOrqz1M5oTfKp4_fDCEMfM \ --edgenode-name=edgenode01 \ --kubeedge-version v1.17.0 \ --remote-runtime-endpoint=unix:///run/containerd/containerd.sock \ --cgroupdriver=systemd I0609 01:02:07.306277    3442 command.go:925] 1. Check KubeEdge edgecore process status I0609 01:02:07.308827    3442 command.go:925] 2. Check if the management directory is clean I0609 01:02:07.308940    3442 join.go:94] 3. Create the necessary directories I0609 01:02:07.327151    3442 join_others.go:183] 4. Pull Images Pulling kubeedge/installation-package:v1.17.0 ... Successfully pulled kubeedge/installation-package:v1.17.0 I0609 01:03:07.418751    3442 join_others.go:183] 5. Copy resources from the image to the management directory I0609 01:03:23.211034    3442 join.go:94] 6. Generate systemd service file I0609 01:03:23.211142    3442 join.go:94] 7. Generate EdgeCore default configuration I0609 01:03:23.211151    3442 join_others.go:111] The configuration does not exist or the parsing fails, and the default configuration is generated W0609 01:03:23.212571    3442 validation.go:71] NodeIP is empty , use default ip which can connect to cloud. I0609 01:03:23.214148    3442 join.go:94] 8. Run EdgeCore daemon I0609 01:03:23.816884    3442 join_others.go:264] I0609 01:03:23.816894    3442 join_others.go:265] KubeEdge edgecore is running, For logs visit: journalctl -u edgecore.service -xe I0609 01:03:33.825262    3442 join.go:94] 9. Install Complete!注意：Keadm安装EdgeCore时，你需要设置--remote-runtime-endpoint=unix:///run/containerd/containerd.sock2、云端查看边缘节点是否加入云端root@cloudcore:~# kubectl get nodes NAME         STATUS   ROLES           AGE   VERSION cloudcore    Ready    control-plane   39h   v1.28.2 edgenode01   Ready    agent,edge      96s   v1.28.6-kubeedge-v1.17.05. 部署nginx到edge端1、编写ngnix deployment yaml#nginx-deployment.yaml apiVersion: apps/v1 kind: Deployment metadata:  name: nginx-demo spec:  replicas: 1   selector:    matchLabels:      app: nginx  template:    metadata:      labels:        app: nginx    spec:      nodeName: edgenode01  # 边缘端的名字 kubectl get node里面的      hostNetwork: true          containers:        - name: nginx          image: nginx:latest          ports:            - containerPort: 80 --- apiVersion: v1 kind: Service metadata:  name: nginx-service spec:  selector:    app: nginx  ports:    - name: http       port: 80      targetPort: 80 注意：在云端执行2、在科学上网的机器下载nginx镜像，进行打包kevin@jumphost:~/kubeedge/images$ sudo docker pull nginx Using default tag: latest latest: Pulling from library/nginx 2cc3ae149d28: Pull complete a97f9034bc9b: Pull complete 9571e65a55a3: Pull complete 0b432cb2d95e: Pull complete 24436676f2de: Pull complete 928cc9acedf0: Pull complete ca6fb48c6db4: Pull complete Digest: sha256:56b388b0d79c738f4cf51bbaf184a14fab19337f4819ceb2cae7d94100262de8 Status: Downloaded newer image for nginx:latest docker.io/library/nginx:latest kevin@jumphost:~/kubeedge/images$ sudo docker save -o nginx.tar nginx kevin@jumphost:~/kubeedge/images$ pwd /home/kevin/kubeedge/images在科学上网的机器上执行。3、拷贝镜像到边缘节点kevin@edgecore:~$ scp 100.98.97.43:/home/kevin/kubeedge/images/nginx.tar ./在边缘节点上执行。4、在边缘节点上load镜像kevin@edgecore:~$ sudo nerdctl load -i nginx.tar --namespace k8s.io unpacking docker.io/library/nginx:latest (sha256:dfc74c87d8108a046662ee785732b1d7b5f54f362da12b171f222b9b0e3a76a2)... Loaded image: nginx:latest kevin@edgecore:~$在边缘节点上执行5、创建Nginx应用，查看是否在边缘节点创建成功。root@cloudcore:~/ke_install# kubectl apply -f ngnix.yaml deployment.apps/nginx-metallb created service/nginx-service created root@cloudcore:~/ke_install# root@cloudcore:~/ke_install# kubectl get pod NAME                                   READY   STATUS    RESTARTS   AGE nginx-demo-5488d4cccd-p2fkf            1/1     Running   0          9s6、边缘节点上测试能否访问ngnix的80端口kevin@edgecore:~$ sudo ss -ntlp | grep 80 LISTEN 0      511          0.0.0.0:80         0.0.0.0:*    users:(("nginx",pid=1733,fd=6),("nginx",pid=1697,fd=6)) LISTEN 0      511             [::]:80            [::]:*    users:(("nginx",pid=1733,fd=7),("nginx",pid=1697,fd=7)) kevin@edgecore:~$ curl http://172.17.48.6 <!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> <style> html { color-scheme: light dark; } body { width: 35em; margin: 0 auto; font-family: Tahoma, Verdana, Arial, sans-serif; } </style> </head> <body> <h1>Welcome to nginx!</h1> <p>If you see this page, the nginx web server is successfully installed and working. Further configuration is required.</p> <p>For online documentation and support please refer to <a href="http://nginx.org/">nginx.org</a>.<br/> Commercial support is available at <a href="http://nginx.com/">nginx.com</a>.</p> <p><em>Thank you for using nginx.</em></p> </body> </html> 6. 总结本文详细介绍了如何在Ubuntu 22.04系统上使用keadm安装和配置最新版本的KubeEdge（v1.17.0）。通过KubeEdge，可以将Kubernetes的强大功能扩展到边缘节点，提升边缘计算的能力和效率。希望这些内容能帮助读者快速上手并掌握KubeEdge的核心技术与应用。KubeEdge的边缘计算架构在未来将会有更广泛的应用前景，随着物联网，边缘计算技术和AI技术发展，KubeEdge将在更多的场景中发挥其独特优势，尤其是云+AI模式的云边协调场景。参考链接:[1]  https://release-1-17.docs.kubeedge.io/zh/docs/welcome/getting-started[2] https://kubeedge.io/zh/docs/setup/prerequisites/runtime/#containerd[3] 树莓派上部署KubeEdge_execute keadm command failed: edge node join faile-CSDN博客[4] https://blog.csdn.net/Leventcoco/article/details/128516720?utm_medium=distribute.pc_relevant.none-task-blog-2~default~baidujs_baidulandingword~default-1-128516720-blog-125448199.235^v43^pc_blog_bottom_relevance_base2&spm=1001.2101.3001.4242.2&utm_relevant_index=4[5] https://kubeedge-docs.readthedocs.io/en/latest/index.html[6] https://blog.csdn.net/xc979906570/article/details/139481230[7] https://github.com/kubeedge/examples/tree/master/kubeedge-counter-demo[8] https://mp.weixin.qq.com/s/QlI1RxOXGBY2IzNqHNaX6g[9] https://github.com/haicgu/training/blob/main/Cloud-Edge/KubeEdge/kubeedge-counter-demo.md[10] KubeEdge CounterDemo 源码分析