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 源码分析

近年来快速发展的视觉大模型(例如 SAM )在促进高精度的智能感知方面具有很大的潜力。然而，边缘环境中的资源限制往往会限制这种视觉大模型在本地部署，从而产生相当大的推理延迟，导致难以支持自动驾驶和机器人等实时物联网智能感知应用。KubeEdge SIG AI 复旦大学吕智慧团队胡时京在 KubeEdge-Ianvs 上发布了基于大小模型协同推理的云边协同物联网感知方法，通过难例样本挖掘算法将少量难例样本上传云端由视觉大模型处理，大部分简单样本在边缘端由小模型处理，在保证推理时延的情况下提高了应对难例样本的处理效果。代码请见：cid:link_1一、背景智慧城市、物联网( IoT )技术的发展已经在国内外社会中根深蒂固，它们改变了人们日常生活和工作的方式，如自动驾驶、机器人、数字孪生、可穿戴设备和增强现实等。其中大量数据从物理世界生成和收集并由各种人工智能（AI）应用程序处理成用户需要的信息越来越成为了一种发展趋势。据 Gartner 统计，到2025年，物联网等终端设备产生的数据量将达到 79.4 zettabytes（ZB），到2030年，物联网设备数量将达到1250 亿。不断激增的终端设备（如移动设备，物联网设备）产生了海量的数据，由于物联网数据的特点（即容量大、多样性、产生速度快），传统的基于云的物联网模型已经无法满足物联网中智能应用的要求，数据源的高度分散性和广泛分布的人工智能应用要求物联网中的边缘设备具有智能感知的能力，即基于海量物联网数据训练边缘模型并进行高效推理。图1：物联网感知失败案例然而真实世界中的物联网边缘设备往往处在一个动态变化的环境中，例如自动驾驶汽车、机器人等移动边缘设备采集的数据会受其位置变化影响，监控摄像头采集的数据会受时间变化影响。物联网边缘设备采集的数据的分布和特征并非一成不变，在真实物联网边缘环境中普遍存在数据漂移和数据异构的现象。数据漂移和数据异构现象会对物联网边缘设备的智能感知能力造成极大影响，严重者甚至会导致出现人员伤亡以及业务受损。如图1所示，2017年，波士顿动力公司的人形机器人 Atlas 因为演示台所处环境与其训练所处环境相差较大未能正确识别演示台边缘，抱箱摔下演示台，该事件导致其股价大跌。2020年12月，福州中防万宝城导购机器人无法识别扶梯，跌落并撞翻两位客人，造成两人轻伤。2021年3月，特斯拉视觉识别应用误把白色卡车识别为天空，导致撞车造成至少两人丧生，特斯拉市值蒸发约440亿美金。2021年10月，美团无人配送车在送货过程中与一辆私家车相撞，美团被判全责。以上案例充分说明了数据漂移问题和数据异构问题是目前物联网智能感知技术的两大挑战。针对数据漂移问题，现有的解决思路致力于发生数据漂移后对模型在新的数据集上进行重训练使其能适应新的环境变化。然而重训练模型也会导致模型忘记之前学习到的信息，出现灾难性遗忘现象。这导致当物联网边缘设备又回到之前的环境时还需要再重新训练模型，造成了对算力的极大浪费。因此在训练过程中需要让模型具备终身学习的能力，使模型一方面可以不断学习新的数据集中的内容以适应新的环境，另一方面模型也不会大幅度遗忘在旧的数据集上学习到的信息，从而减少再重训练的开销。针对数据异构问题，目前快速发展的视觉大模型，如 Meta 公司发布的 Segment Anything Model（SAM），具有较强的泛化能力，在处理分布外的异构数据时相比传统计算机视觉模型效果较好。因此在物联网感知推理过程中引入视觉大模型是应对数据异构问题的关键解决方案之一。但是以 SAM 为首的大模型由于其参数量较大，难以部署在资源受限的边缘端，只能部署在云端使用。而很多边缘物联网设备，例如机器人、自动驾驶汽车，对推理的实时性要求较高，如果将所有推理样本都上传云端处理，会造成较大的通讯开销，并极大增加推理时延。因此只单独使用在云端部署的 SAM 大模型无法满足实时物联网感知的需求，需要通过云端大模型和边缘小模型的云边协同来解决实时物联网感知的挑战。二、基于大模型的边云协同物联网感知系统实现针对上述物联网边缘环境普遍存在的数据漂移和数据异构问题，我们采用终身学习训练方法动态更新边缘小模型从而使模型适应新的环境，我们在云端部署视觉大模型 SAM 用于处理分布外异构数据从而应对边缘小模型难以处理的难例推理样本。同时考虑到云端部署的 SAM 视觉大模型推理时延较大，难以满足物联网实时感知任务的需求，我们采用基于难例样本挖掘的云边协同策略，将大部分简单推理样本在边缘端由边缘小模型处理，少部分难例推理样本上传云端由云端 SAM 大模型处理，从而在保证推理时延的情况下提高推理准确率。▍2.1 总体架构设计基于大模型的边云协同物联网感知系统总体架构设计如图2所示，边云协同物联网感知系统包括云边协同推理和终身学习训练两部分。云边协同推理模块用于解决物联网感知的数据异构和实时性问题。以 SAM 为首的大模型具有较强的泛化能力，因此在处理分布外异构数据时准确率更高。我们通过基于难例样本挖掘的云边协同策略，将大部分简单样本在边缘处理，只有少部分难例样本才需要上传云端由 SAM 大模型处理，从而提高推理实时性。在云边协同推理部分，我们在边缘节点部署 RFNet 模型和难例样本挖掘算法用于实现在边缘端对简单样本的推理和判断推理样本是否需要上传云端。难例样本挖掘算法根据 RFNet 模型推理的结果将样本分为难例样本和简单样本，简单样本直接输出 RFNet 推理结果，难例样本上传云端处理，从而降低推理时延，提高推理实时性。我们在云端部署 SAM 模型用于对难例样本的推理结果进行优化，从而应对数据异构的问题。优化后的云端推理结果会下载到边缘节点作为难例样本的推理结果输出。SAM 模型可以通过 prompt 的方式以交互的形式对图像进行分割，在本项目中我们参考复旦大学提出的 SSA（Semantic Segment Anything）[1] 方法，用 SAM 模型将图像中所有物体都分割出来从而直接应用 SAM 模型于语义分割任务中。图2：基于大模型的边云协同物联网感知系统架构终身学习训练模块用于解决数据漂移问题。当环境变化导致数据分布发生变化时，原来训练的 RFNet 模型在面对数据分布变化后的样本时推理准确率会出现大幅度下降。终身学习算法通过在新分布的数据上持续训练 RFNet 模型从而提高 RFNet 模型的推理准确率，使之适应数据漂移现象。在终身学习训练部分，我们将上传到云端的难例样本及其云端推理结果存储在 replay buffer 中。当 replay buffer 中样本超过一定数量时，我们基于 replay buffer 中的难例样本对 RFNet 模型进行再训练，从而提高边缘模型应对数据漂移问题的能力。训练后的 RFNet 模型会被下载到边缘节点更新边缘端的 RFNet 模型。基于大模型的边云协同物联网感知系统总体架构设计如图2所示，边云协同物联网感知系统包括云边协同推理和终身学习训练两部分。上述系统架构的优势在于：通过难例样本挖掘，大部分简单样本在边缘节点由 RFNet 模型直接得到推理结果，保证系统可以满足实时性要求。少部分 corner case、难例样本上传云端由大模型 SAM 推理得到更完善的推理结果，提高系统推理平均准确率。通过终身学习训练，边缘端 RFNet 模型可以在大模型 SAM 的监督下从难例样本中学习到一定经验，从而适应边缘端复杂多变的环境。KubeEdge 是目前主流的开源边缘计算平台，其子项目 KubeEdge-Ianvs，作为业界首个分布式协同 AI 基准测试平台，基于 KubeEdge-Sedna 为算法及服务开发者提供全场景可扩展的分布式协同 AI 基准测试，以研发、衡量和优化分布式协同 AI 系统。我们基于 Kubeedge-Ianvs 实现了该系统架构，具体在 Ianvs 中实现的模块如图3所示。图3：在KubeEdge-Ianvs中实现模块我们将难例样本挖掘算法填补在 Ianvs 的未知样本识别模块，其将样本分为难例样本（未知样本）和简单样本（已知样本）。在云端节点基于大模型 SAM 对难例样本的推理在未知样本推理模块中实现，在边缘端基于 RFNet 对简单样本的推理在已知样本推理模块中实现。对于终身学习训练的部分，我们在已知和未知任务处理模块实现，这部分我们延用了 Ianvs 默认的终身学习训练配置。▍2.2 案例分析我们采用在华为深圳工业园区由智能机械狗采集的语义分割机器人数据集 Cloud-Robotics 作为本项目的测试 benchmark。Cloud-Robotics 是首个在真实世界场景中由机械狗实地收集的数据集，因此数据集中的图片都是以机械狗的视角拍摄的，拍摄角度相比 Cityscapes 等自动驾驶语义分割数据集更低，也更贴近实际机器人应用（递送、巡检）。数据集官网链接：cid:link_6。图4展示了在 Cloud-Robotics 数据集中RFNet模型和SAM模型部分的推理结果，不难看出 RFNet 在处理部分 corner case 比如反光（第三排图片）时效果较差，将建筑物识别为天空。然而通过大模型 SAM 推理得到分割完善的 mask 后基于像素级的投票成果将错误识别为天空的部分正确识别为了建筑物。图4：部分实验结果展示我们在[Cloud-Robotics][2] 数据集上进行了实验，为了进一步对比 SAM+RFNet 效果，我们额外选取了 Huggingface 发布的在cityscapes数据集上预训练的[Segformer][3] 模型作为基模型进行测试，测试结果如下表：上表展示了不同算法在 Cloud-Robotics 数据集上对不同类别物体的识别准确率（IoU）。我们将识别物体根据其在数据集中出现的频率分为常见类别和稀有类别两种。从结果中可以看出对于常见类别的 Road、Sidewalk 和 builiding 类物体的识别上，SAM+RFNet 云边协同和 RFNet 效果提升仅有1%左右，这是因为对于识别常见类别的简单任务来说，RFNet 模型的准确率已经很高了，再额外加入 SAM 大模型也没有太多提升空间。而对于园区中出现较少稀有类别的 Car、Terrain 类物体， SAM+RFNet 相比 RFNet 提升平均超过20%以上，这是因为对于识别稀有类别的难例任务来说，RFNet 模型处理效果不好，而 SAM 模型更擅长处理。总体来说， SAM+RFNet 云边协同相比只用RFNet准确率提升了8%以上，证明了我们提出的基于大模型的边云协同物联网感知系统的有效性。同时可以看出使用 Segformer 作为基模型的结果则相差很多，这主要是因为 Segformer 是在 cityscapes 数据集上预训练的，而 Cloud-Robotics 数据集中存在 cityscapes 数据集中没有的标签，同时数据集的分布差别较大（Cloud-Robotics 面向半封闭工业园区，cityscapes 面向开放世界）导致了 Segformer 推理结果较差。在Cityscapes 数据集上预训练的 Segformer 模型在 Car 类物体识别上准确率较高，这主要是因为 Cityscapes 数据集是面向开放世界的语义分割数据集，其中 car 类物体出现频率更高。下图展示了 RFNet 和 Segformer 的部分推理结果对比。图5：不同模型效果展示如图5所示，可以看出因为 Segformer 在分类时就将整个天空都识别为了建筑，因此即便 SAM 推理的结果中将天空正确切割出来了，最后 SAM+Segformer 的推理结果中天空仍然是分类错误的。这告诉我们 SAM 大模型不能解决一切问题，最终推理结果还是依赖于使用的小模型推理标签准确。因此即便在使用大模型进行云边协同推理时，对边缘端小模型进行终身学习更新仍然是必要的。三、基于KubeEdge-lanvs的使用教程在这章中我们通过运行 Ianvs 终身学习的 cloud-robotics 样例向大家讲解基于 KubeEdge-Ianvs 实现大模型边云协同物联网感知的基本流程。Ianvs 安装流程以及终身学习更详细的介绍可以参考：Ianvs-lifelong-learning-tutorial[4]。首先我们需要配置好 Cloud-Robotics 的数据集，先创建数据集的文件夹，注意如果你把数据集放到别的位置，本教程中的部分路径配置也要一并修改。mkdir /data cd /data mkdir datasets cd datasets download datasets in cid:link_6download.html配置好数据集后，我们可以准备运行示例代码了。Cloud-Robotics 示例运行的代码放在/ianvs/project/ianvs/examples/robot/lifelong_learning_bench/semantic-segmentation下，我们首先要配置 python 路径（这里如果 Ianvs 安装位置不一样的话需要更改路径）：export PYTHONPATH=$PYTHONPATH:/ianvs/project/ianvs/examples/robot/lifelong_learning_bench/semantic-segmentation/testalgorithms/rfnet/RFNet然后我们需要去安装 SAM 大模型：cd /ianvs/project git clone https://github.com/facebookresearch/segment-anything.git cd segment-anything python -m pip install -e .下载模型参数：wget https://dl.fbaipublicfiles.com/segment_anything/sam_vit_h_4b8939.pth为了保存模型推理结果，我们需要按照以下指令安装 mmcv 和 mmdetection:python -m pip install https://download.openmmlab.com/mmcv/dist/cu118/torch2.0.0/mmcv-2.0.0-cp39-cp39-manylinux1_x86_64.whl cd /ianvs/project git clone https://github.com/hsj576/mmdetection.git cd mmdetection python -m pip install -v -e .在机器配置性能不足以运行 SAM 模型的情况下，我们为 Cloud-Robotics 数据集中的所有 SAM 推理结果准备了一个缓存。你可以从这个链接 [5]下载缓存，并把缓存文件放在“/ianvs/project/”中:cp cache.pickle /ianvs/project通过使用缓存，可以在不安装 SAM 模型的情况下模拟基于大模型的边云协同推理。除此之外，我们还在这个链接  [6]中提供了一个预训练的 RFNet 模型，如果你不想从零开始训练 RFNet 模型，可以使用我们预训练的 RFNet 模型：cd /ianvs/project mkdir pretrain cp pretrain_model.pth /ianvs/project/pretrain in /ianvs/project/ianvs/examples/robot/lifelong_learning_bench/semantic-segmentation/testalgorithms/rfnet/RFNet/utils/args.py set self.resume = '/ianvs/project/pretrain/pretrain_model.pth'上述所有配置完成后，执行下面指令即可进行基于 SAM 大模型的边云协同推理：cd /ianvs/project/ianvs ianvs -f examples/robot/lifelong_learning_bench/semantic-segmentation/benchmarkingjob-sam.yaml相关资料：[1] SSA（Semantic Segment Anything）: cid:link_0[2] Cloud-Robotics: cid:link_6[3] Segformer: cid:link_2[4] Ianvs-lifelong-learning-tutorial: cid:link_5[5] cid:link_3[6] cid:link_4更多云原生技术动向关注容器魔方

KubeEdge社区v1.17.0 版本正式发布。新版本为边缘节点和设备带来了更多的新能力，同时持续在易用性上做了提升。KubeEdge v1.17.0 新增特性：支持边缘 Pods 使用 InClusterConfig 访问 Kube-APIServerMapper 支持流数据上报支持边缘子模块自启动引入 keadm ctl 命令，支持在边缘查询和重启 pod易用性提升：基于 Keadm 的部署能力增强Mapper 框架添加 MySQL 数据库升级 K8s 依赖到 v1.28  新特性概览   ▍支持边缘 Pods 使用 InClusterConfig 访问 Kube-APIServerKubernetes 支持 Pods 使用 InClusterConfig 机制直接访问 Kube-APIServer，然而在边缘场景，边缘 Pods 和 Kube-APIServer 通常不在一个网络环境下，无法直接访问。在1.17.0 新版本中，通过开启 MetaServer 和 DynamicController 模块，边缘 Pods 同样可以使用 InClusterConfig 机制直接访问 Kube-APIServer。该特性在本版本中作为 Alpha 特性发布，如果你需要使用，您需要开启边缘 List-Watch 开关并配置 requireAuthorization的featureGates。在使 keadm init 启动 CloudCore 时，指定 cloudCore.featureGates.requireAuthorization=true 以及 cloudCore.modules.dynamicController.enable=true。启动 EdgeCore 后，按如下修改 edgecore.yaml 后重启 EdgeCore。apiVersion: edgecore.config.kubeedge.io/v1alpha2 kind: EdgeCore featureGates: requireAuthorization: true modules: ... metaManager: metaServer: enable: true更多信息可参考：cid:link_3cid:link_4▍Mapper 支持流数据上报 1.17 版本中，针对当前 Mapper 只能处理离散型的设备数据，无法处理流数据的问题，为 Mapper-Framework 提供视频流数据处理的能力。在新版本中，能够支持 KubeEdge 管理边缘摄像头设备，获取摄像头采集的视频流，并将视频流保存为帧文件或者视频文件，增强 KubeEdge 边缘设备管理能力。边缘摄像头设备管理1.17 版本提供基于 Onvif 协议的内置 Mapper，实现 Onvif 设备驱动功能，能够根据用户配置文件中的定义连接摄像头设备，获取设备的鉴权文件与 RTSP 视频流，将 Onvif 摄像头设备纳管进 KubeEdge 集群。Onvif 设备的一个示例 device-instance 配置文件如下：apiVersion: devices.kubeedge.io/v1beta1 kind: Device metadata: name: onvif-device-01 namespace: default spec: deviceModelRef: name: onvif-model # need to be the same as the model name defined in onvif-model.yaml protocol: protocolName: onvif configData: url: 192.168.168.64:80 # Replace it with the address of your own onvif camera userName: admin # Replace it with the username of your own onvif camera password: /etc/secret/password # Fill in the fields according to your secret.yaml nodeName: edge-node # Replace it with your edge node name properties: - name: getURI visitors: protocolName: onvif configData: url: 192.168.168.64:80 userName: admin password: /etc/secret/password dataType: string视频流数据处理新版本增强 Mapper-Framework 数据面能力，内置流数据处理功能。用户能够在 device-instance 文件中进行配置，将边缘摄像头设备上报的视频流截取保存为视频片段文件以及视频帧文件，流数据处理的 device-instance 文件示例如下：apiVersion: devices.kubeedge.io/v1beta1 kind: Device metadata: name: onvif-device-01 ... properties: - name: saveFrame # Convert video stream into frame visitors: protocolName: onvif configData: format: jpg # Frame file format outputDir: /tmp/case/ # Directory for output frame files frameCount: 30 # Number of output frames frameInterval: 1000000 # Time interval between frames (The unit is nanoseconds) dataType: stream - name: saveVideo # Convert video streams into video clips visitors: protocolName: onvif configData: frameCount: 1000 # The number of frames the video clip contains format: mp4 # Video clip format outputDir: /tmp/case/ # Directory for output video clip videoNum: 2 # Number of video clips dataType: stream更多信息可参考：cid:link_5cid:link_6cid:link_2▍支持边缘子模块自启动由于配置或者可恢复的环境问题，例如进程启动顺序等，导致 EdgeCore 启动失败。例如，当 containerd.socket 没有就绪时，Edged 启动 Kubelet 失败会导致 EdgeCore 直接退出。在新版本中，我们改进了 Beehive 框架，支持边缘子模块重启。用户可以通过启动 moduleRestart featureGates，将 EdgeCore 的子模块设置为自动重启，而不是整个 EdgeCore 退出。该特性在本版本中作为 Alpha 特性发布，如果你需要使用，您需要配置 moduleRestart 的 featureGates。apiVersion: edgecore.config.kubeedge.io/v1alpha2 kind: EdgeCore featureGates: moduleRestart: true 更多信息可参考：cid:link_7cid:link_6▍引入 keadm ctl 命令，支持在边缘查询和重启 pod当边缘节点离线时，我们无法通过 kubectl 查看边缘节点上的 pod，在 1.17 中可以在边缘节点上通过 keadm ctl get/restart pod [flag] 对 pod 进行查询或重启。如果需要使用该特性，您需要开启 metaserver 开关。keadm ctl get pod 的可选参数如下：[root@centos-2 bin]# keadm ctl get pod -h Get pods in edge node Usage: keadm ctl get pod [flags] Flags: -A, --all-namespaces If present, list the requested object(s) across all namespaces. Namespace in current context is ignored even if specified with --namespace -h, --help help for pod -n, --namespace string Specify a namespace (default "default") -o, --output string Output format. One of: (json, yaml, name, go-template, go-template-file, template, templatefile, jsonpath, jsonpath-as-json, jsonpath-file, custom-columns, custom-columns-file, wide) -l, --selector string Selector (label query) to filter on, supports '=', '==', and '!='.(e.g. -l key1=value1,key2=value2)keadm ctl restart pod 的可选参数如下：[root@centos-2 bin]# keadm ctl restart pod -h Restart pods in edge node Usage: keadm ctl restart pod [flags] Flags: -h, --help help for pod -n, --namespace string Specify a namespace (default "default")Demo 演示：[root@centos-2 bin]# alias kectl='keadm ctl' [root@centos-2 bin]# kectl get pod -owide -A NAMESPACE NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES default nginx-deployment-58b54fbd94-f5q7p 1/1 Running 1 (20m ago) 22m 10.88.0.2 centos-2 kubeedge edge-eclipse-mosquitto-scvrk 1/1 Running 1 (16m ago) 28m 192.168.94.106 centos-2 [root@centos-2 bin]# kectl restart pod -n kubeedge edge-eclipse-mosquitto-scvrk 393cbcac4b484a4a28eee7dd2d63b33137a10a84d5f6eed6402b9a23efc6aef0 af4059137ced56b365da7e1c43d3ea218e3090ab7644a105651ca4661ddf26f0 [root@centos-2 bin]# kectl get pod -owide -A NAMESPACE NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES default nginx-deployment-58b54fbd94-f5q7p 1/1 Running 1 (21m ago) 23m 10.88.0.2 centos-2 kubeedge edge-eclipse-mosquitto-scvrk 1/1 Running 2 (10s ago) 29m 192.168.94.106 centos-2 更多信息可参考：cid:link_8cid:link_9▍易用性提升：基于 Keadm 的部署能力增强将命令 keadm generate 更改为 keadm manifest；[root@centos-2 bin]# keadm --help|grep manifest manifest Checks and generate the manifests. example: [root@centos-1 keepalived]# keadm manifest --advertise-address= --profile version=v1.17.0在 keadm join 添加一个镜像仓库参数: image-repository，以支持自定义镜像仓库；[root@centos-2 bin]# keadm join -h|grep image-repository --image-repository string Use this key to decide which image repository to pull images from example: [root@centos-2 bin]# keadm join --cloudcore-ipport :10000 --kubeedge-version=1.17.0 --remote-runtime-endpoint=unix:///run/cri-dockerd.sock --image-repository my.harbor.cn/kubeedge --token xxxx 将 keadm reset 命令进行三级拆分，拆分成 keadm reset cloud 和 keadm reset edge, keadm reset 仍然被保留，使用时 cloudcore 和 edgecore 都会被卸载，新增的三级命令 keadm reset cloud 和 keadm reset edge 分别只卸载 cloudcore 和 edgecore。[root@centos-2 bin]# keadm reset --help ... Available Commands: cloud Teardowns CloudCore component edge Teardowns EdgeCore component Flags: --force Reset the node without prompting for confirmation -h, --help help for reset --kube-config string Use this key to set kube-config path, eg: $HOME/.kube/config (default "/root/.kube/config") [root@centos-2 bin]# keadm reset cloud --help ... Flags: --force Reset the node without prompting for confirmation -h, --help help for cloud --kube-config string Use this key to set kube-config path, eg: $HOME/.kube/config (default "/root/.kube/config") [root@centos-2 bin]# keadm reset edge --help ... Flags: --force Reset the node without prompting for confirmation -h, --help help for edge更多信息可参考：cid:link_1cid:link_10cid:link_11cid:link_12▍Mapper 框架添加 MySQL 数据库在 1.17 的 Mapper-Framework 中，数据推送模块新增了 MySQL 数据库,如果用户想使用 MySQL 作为某个 property 的 PushMethod，可以在 device instance 的对应 property 下， 通过如下配置即可：apiVersion: devices.kubeedge.io/v1beta1 kind: Device ... spec: properties: - name: xxx ... pushMethod: dbMethod: mysql: mysqlClientConfig: addr: 127.0.0.1:3306 #the url to connect to the mysql database. database: kubeedge #database name userName: root #user name更多信息可参考：cid:link_13▍升级 K8s 依赖到 v1.28新版本将依赖的 Kubernetes 版本升级到 v1.28.6，您可以在云和边缘使用新版本的特性。更多信息可参考：cid:link_14  版本升级注意事项  自 v1.17.0 起，我们推荐在使用 keadm 安装 KubeEdge 时使用 --kubeedge-version= 来指定具体版本，--profile version= 会逐渐废弃。▍致谢感谢 KubeEdge 社区技术指导委员会 (TSC)、各 SIG 成员对 v1.17 版本开发的支持与贡献，未来 KubeEdge 将持续在新场景探索与支持、稳定性、安全性、可扩展性等方面持续发展与演进！▍相关链接Release Notes：cid:link_0 添加社区小助手k8s2222回复KubeEdge进入社区交流群

3月21日，在巴黎举办的云原生顶级峰会KubeCon+CloudNativeCon Europe 2024上 ，华为云首席架构师顾炯炯在 “Cloud Native x AI：以持续开源创新开启智能时代” 的主题演讲中指出，云原生和AI技术的融合，是推动产业深刻变革的关键所在。华为云将持续进行开源创新，与开发者共启智能时代。  ▲华为云首席架构师顾炯炯发表演讲AI对于云原生范式提出关键挑战在过去的几年里，云原生彻底改变了传统的IT系统，催化了互联网和政府服务等领域的数字飞跃。云原生范式带来的新的可能性，例如闪电般的快速销售和基于微服务治理的敏捷应用DevOps，已经深入人心。同时，人工智能的快速发展和广泛采用，包括大规模模型，已经成为行业智能的跳动心脏。根据Epoch 2023年的调研数据，基础模型所需的计算能力每18个月就会增长10倍，是摩尔定理揭示的通用计算能力增长率的5倍。AI带来的新摩尔定律和大规模AI模型的主导地位对云原生范式提出了挑战，顾炯炯总结了其中关键的4点：首先，低GPU/NPU平均利用率导致AI训练和推理的高成本；其次，大模型训练集群频繁的失败率限制了训练效率；第三，大规模模型的复杂配置导致AI开发门槛高；第四，大规模的AI推理部署面临着不可预测的最终用户访问延迟和数据隐私问题的风险。华为云AI创新为开发者迎接挑战提供思路随着AI模型变得越来越大，对计算能力的需求也呈指数级增长。这种需求不仅给云原生技术带来了挑战，也为业界提供了创新机遇。顾炯炯分享了一些华为云在AI创新方面的故事，为开发者解决这些挑战提供了参考。在云原生边缘计算平台KubeEdge的基础上，华为云实现了一个云原生多机器人调度管理平台。用户可以通过自然语言命令在云端输入任务指令，由系统协调边缘的多个机器人共同协作完成复杂任务。为了克服自然语言命令理解、大量机器人高效调度管理以及跨类型机器人访问管理的三个挑战，该系统采用了云端、边缘节点和机器人三个部分的架构，通过大模型执行自然语言命令，并进行流量预测、任务分配和路由规划。这一架构显著提高了机器人平台的灵活性，管理效率提升25%，系统部署周期缩短30%，新机器人的部署时间从月级缩短到天级。中国某顶级内容分享社区，每月活跃用户超过1亿。它的核心服务之一是主页上的推荐功能。推荐模型有近1000亿个参数。训练集群有数千个计算节点。一个训练作业需要数百个参数服务器和worker。因此，该社区对最优拓扑调度、高性能、高吞吐量有着强烈的需求。开源项目Volcano可以更好地支持在Kubernetes上运行的AI/ML工作负载，并提供了一系列作业管理和高级调度策略。Volcano项目引入了拓扑感知调度、装箱、SLA感知调度等算法，帮助社区将整体训练性能提升了20%，运维复杂度也大大降低。Serverless AI引领云原生发展趋势如何高效、稳定地运行AI应用，同时降低运营成本，成为摆在众多企业和开发者面前的一大挑战。为此，华为云总结了云原生AI平台的关键要求，提出了一种全新的云原生AI平台理念——Serverless AI。顾炯炯提到，从开发者的视角来看，Serverless AI致力于智能地推荐并行策略，让复杂的训练和推理任务变得轻而易举。它提供自适应的GPU/NPU自动扩展功能，能够根据工作负载的实时变化动态调整资源分配，确保任务的高效执行。同时，Serverless AI还维护着一个无故障的GPU/NPU集群，让开发者无需担心硬件故障带来的中断风险。更值得一提的是，该平台保持与主流AI框架的兼容性，让开发者能够无缝集成现有的AI工具和模型。对于云服务提供商而言，Serverless AI同样具有深远的意义。它不仅能够提高GPU/NPU的利用率，使训练、推理和开发混合工作负载得以高效运行，还能通过优化能效实现绿色计算，降低能耗成本。此外，Serverless AI平台还能实现跨多个租户的空间和时间GPU/NPU共享，提高资源的复用率。最重要的是，它为训练和推理任务提供了有保证的QoS和SLA，确保了服务质量和稳定性。Serverless AI平台采用了构建在操作系统和虚拟化之上的灵活的资源调度层，将应用程序框架的关键功能封装于应用资源中介层中。顾炯炯现场展示了Serverless AI平台的参考架构。他认为，这种架构设计，使得Serverless AI平台具有了大规模AI资源自动驱动引擎的特点，包括精确了解应用资源利用模式的资源分析，实现异构硬件资源池化的资源共享，基于GPU/NPU虚拟化和负载热迁移的AI训练任务容错能力，以及提高资源利用率的多维度调度和自适应弹性伸缩等优点。分论坛上，华为云技术专家提到，Kubernetes上运行AI/ML工作负载的使用量不断增加，许多公司在分布于数据中心和各种GPU类型的多个 Kubernetes 集群上构建云原生AI平台。使用Karmada和Volcano，可轻松实现多集群的GPU工作负载智能调度、集群故障转移支持，在保障集群内和跨集群的两级调度一致性和效率，并平衡系统整体资源的利用率和不同优先级工作负载的QoS，以应对大规模、异构的GPU环境管理中面临的挑战。Karmada为多云和混合云场景中的多集群应用管理提供即时可用的自动化管理，越来越多的用户在生产环境中使用Karmada构建灵活高效的解决方案。Karmada已于2023年正式升级为CNCF孵化项目，期待与更多伙伴与开发者们共建繁荣社区。Volcano与主流AI/大数据框架实现了无缝集成，有效解决了AI/大数据任务的作业管理，资源分配，资源调度等问题与挑战，为业界提供了分布式作业训练的最佳实践。在大模型日新月异的今天，Volcano将持续发力，解决多集群AI任务调度等难题，助推大模型训练与推理快速发展。“云原生技术的敏捷性和异构AI计算平台的创新性，将是提升AI生产力的关键。” 顾炯炯谈到，未来，华为云将持续致力于开源创新，与业界同仁、伙伴共同开启智能时代的新篇章。更多云原生技术动向关注容器魔方添加小助手k8s2222进入技术群

更多云原生技术动向关注容器魔方添加小助手k8s2222进入技术群

北京时间2024年1月23日，KubeEdge 发布 1.16.0 版本。新版本新增多个增强功能，在集群升级、集群易用性、边缘设备管理等方面均有大幅提升。KubeEdge v1.16.0 新增特性：集群升级：支持云边组件自动化升级支持边缘节点的镜像预下载支持使用 Keadm 安装 Windows 边缘节点增加多种容器运行时的兼容性测试EdgeApplication 中支持更多 Deployment 对象字段的 Override支持基于 Mapper-Framework 的 Mapper 升级DMI 数据面内置集成 Redis 与 TDEngine 数据库基于 Mapper-Framework 的 USB-Camera Mapper 实现易用性提升：基于 Keadm 的部署能力增强升级 K8s 依赖到 v1.27  新特性概览 ▍集群升级：支持云边组件自动化升级随着 KubeEdge 社区的持续发展，社区版本不断迭代；用户环境版本升级的诉求亟需解决。针对升级步骤难度大，边缘节点重复工作多的问题，v1.16.0 版本的 KubeEdge 支持了云边组件的自动化升级。用户可以通过 Keadm 工具一键化升级云端，并且可以通过创建相应的 Kubernetes API，批量升级边缘节点。云端升级云端升级指令使用了三级命令与边端升级进行了区分，指令提供了让用户使用更便捷的方式来对云端的 KubeEdge 组件进行升级。当前版本升级完成后会打印 ConfigMap 历史配置，如果用户手动修改过 ConfigMap，用户可以选择通过历史配置信息来还原配置文件。我们可以通过 help 参数查看指令的指导信息：keadm upgrade cloud --help Upgrade the cloud components to the desired version, it uses helm to upgrade the installed release of cloudcore chart, which includes all the cloud components Usage: keadm upgrade cloud [flags] Flags: --advertise-address string Please set the same value as when you installed it, this value is only used to generate the configuration and does not regenerate the certificate. eg: 10.10.102.78,10.10.102.79 -d, --dry-run Print the generated k8s resources on the stdout, not actual execute. Always use in debug mode --external-helm-root string Add external helm root path to keadm --force Forced upgrading the cloud components without waiting -h, --help help for cloud --kube-config string Use this key to update kube-config path, eg: $HOME/.kube/config (default "/root/.kube/config") --kubeedge-version string Use this key to set the upgrade image tag --print-final-values Print the final values configuration for debuging --profile string Sets profile on the command line. If '--values' is specified, this is ignored --reuse-values reuse the last release's values and merge in any overrides from the command line via --set and -f. --set stringArray Sets values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2) --values stringArray specify values in a YAML file (can specify multiple)升级指令样例：keadm upgrade cloud --advertise-address= --kubeedge-version=v1.16.0边端升级v1.16.0版本的KubeEdge支持通过 NodeUpgradeJob 的 Kubernetes API 进行边缘节点的一键化、批量升级。API 支持边缘节点的升级预检查、并发升级、失败阈值、超时处理等功能。对此，KubeEdge 支持了云边任务框架。社区开发者将无需关注任务控制、状态上报等逻辑实现，只需聚焦云边任务功能本身。升级 API 样例：apiVersion: operations.kubeedge.io/v1alpha1 kind: NodeUpgradeJob metadata: name: upgrade-example labels: description: upgrade-label spec: version: "v1.16.0" checkItems: - "cpu" - "mem" - "disk" failureTolerate: "0.3" concurrency: 2 timeoutSeconds: 180 labelSelector: matchLabels: "node-role.kubernetes.io/edge": "" node-role.kubernetes.io/agent: ""兼容测试KubeEdge 社区提供了完备的版本兼容性测试，用户在升级时仅需要保证云边版本差异不超过 2 个版本，就可以避免升级期间云边版本不一致带来的问题。更多信息可参考：https://github.com/kubeedge/kubeedge/pull/5330https://github.com/kubeedge/kubeedge/pull/5229https://github.com/kubeedge/kubeedge/pull/5289▍支持边缘节点的镜像预下载新版本引入了镜像预下载新特性，用户可以通过 ImagePrePullJob的 Kubernetes API 提前在边缘节点上加载镜像，该特性支持在批量边缘节点或节点组中预下载多个镜像，帮助减少加载镜像在应用部署或更新过程，尤其是大规模场景中，带来的失败率高、效率低下等问题。镜像预下载API示例：apiVersion: operations.kubeedge.io/v1alpha1 kind: ImagePrePullJob metadata: name: imageprepull-example labels: description:ImagePrePullLabel spec: imagePrePullTemplate： images: - image1 - image2 nodes： - edgenode1 - edgenode2 checkItems: - "disk" failureTolerate: "0.3" concurrency: 2 timeoutSeconds: 180 retryTimes: 1 更多信息可参考：https://github.com/kubeedge/kubeedge/pull/5310https://github.com/kubeedge/kubeedge/pull/5331▍支持使用 Keadm 安装 Windows 边缘节点KubeEdge 1.15.0 版本实现了在 Windows 上运行边缘节点，在新版本中，我们支持使用安装工具 Keadm 直接安装 Windows 边缘节点，操作命令与 Linux 边缘节点相同，简化了边缘节点的安装步骤。更多信息可参考：https://github.com/kubeedge/kubeedge/pull/4968▍增加多种容器运行时的兼容性测试新版本中新增了多种容器运行时的兼容性测试，目前已集成了containerd，docker，isulad 和 cri-o 4种主流容器运行时，保障 KubeEdge 版本发布质量，用户在安装容器运行时过程中也可以参考该PR中的适配安装脚本。更多信息可参考：https://github.com/kubeedge/kubeedge/pull/5321▍EdgeApplication 中支持更多 Deployment 对象字段的 Override在新版本中，我们扩展了 EdgeApplication 中的差异化配置项（overriders），主要的扩展有环境变量、命令参数和资源。当您不同区域的节点组环境需要链接不同的中间件时，就可以使用环境变量（env）或者命令参数（command, args）去重写中间件的链接信息。或者当您不同区域的节点资源不一致时，也可以使用资源配置（resources）去重写cpu和内存的配置。更多信息可参考：https://github.com/kubeedge/kubeedge/pull/5262https://github.com/kubeedge/kubeedge/pull/5370▍支持基于Mapper-Framework的 Mapper 升级1.16.0 版本中，基于 Mapper 开发框架 Mapper-Framework 构建了 Mapper 组件的升级能力。新框架生成的 Mapper 工程以依赖引用的方式导入原有 Mapper-Framework 的部分功能，在需要升级时，用户能够以升级依赖版本的方式完成，简化 Mapper 升级流程。Mapper-Framework 代码解耦:1.16.0 版本中将 Mapper-Framework 中的代码解耦为用户层和业务层。用户层功能包括设备驱动及与之强相关的部分管理面数据面能力，仍会随 Mapper-Framework 生成在用户 Mapper 工程中，用户可根据实际情况修改。业务层功能包括 Mapper向云端注册、云端下发Device列表等能力，会存放在kubeedge/mapper-framework 子库中。Mapper 升级框架:1.16.0 版本 Mapper-Framework 生成的用户 Mapper 工程通过依赖引用的方式使用 kubeedge/mapper-framework 子库中业务层功能，实现完整的设备管理功能。后续用户能够通过升级依赖版本的方式达到升级 Mapper 的目的，不再需要手动修改大范围代码。更多信息可参考：https://github.com/kubeedge/kubeedge/pull/5308https://github.com/kubeedge/kubeedge/pull/5326▍DMI 数据面内置集成 Redis 与TDEngine数据库1.16.0 版本中进一步增强 DMI 数据面中向用户数据库推送数据的能力，增加 Redis 与 TDengine 数据库作为内置数据库。用户能够直接在 device-instance 配置文件中定义相关字段，实现 Mapper 自动向 Redis 与 TDengine 数据库推送设备数据的功能，相关数据库字段定义为：type DBMethodRedis struct { // RedisClientConfig of redis database // +optional RedisClientConfig *RedisClientConfig `json:"redisClientConfig,omitempty"` } type RedisClientConfig struct { // Addr of Redis database // +optional Addr string `json:"addr,omitempty"` // Db of Redis database // +optional DB int `json:"db,omitempty"` // Poolsize of Redis database // +optional Poolsize int `json:"poo lsize,omitempty"` // MinIdleConns of Redis database // +optional MinIdleConns int `json:"minIdleConns,omitempty"` }type DBMethodTDEngine struct { // tdengineClientConfig of tdengine database // +optional TDEngineClientConfig *TDEngineClientConfig `json:"TDEngineClientConfig,omitempty"` } type TDEngineClientConfig struct { // addr of tdEngine database // +optional Addr string `json:"addr,omitempty"` // dbname of tdEngine database // +optional DBName string `json:"dbName,omitempty"` }更多信息可参考：https://github.com/kubeedge/kubeedge/pull/5064▍基于Mapper-Framework的USB-Camera Mapper实现基于KubeEdge 的 Mapper-Framework，新版本提供了 USB-Camera 的 Mapper 样例，该 Mapper 根据 USB 协议的 Camera 开发，用户可根据该样例和 Mapper-Framework 更轻松地开发具体业务相关的 Mapper。在样例中提供了 helm chart 包，用户可以通过修改 usbmapper-chart/values.yaml 部署 UBS-Camera Mapper，主要添加 USB-Camera 的设备文件, nodeName, USB-Camera 的副本数，其余配置修改可根据具体情况而定，通过样例目录中的 Dockerfile 制作 Mapper 镜像。global: replicaCounts: ...... cameraUsbMapper: replicaCount: 2 #USB-Camera的副本数 namespace: default ...... nodeSelectorAndDevPath: mapper: - edgeNode: "edgenode02" #USB-Camera连接的缘节点nodeName devPath: "/dev/video0" #USB-Camera的设备文件 - edgeNode: "edgenode1" devPath: "/dev/video17" ...... USB-Camera Mapper 的部署命令如下：helm install usbmapper-chart ./usbmapper-chart更多信息可参考：https://github.com/kubeedge/mappers-go/pull/122▍易用性提升：基于 Keadm 的部署能力增强添加云边通信协议配置参数在 KubeEdge v1.16.0 中，使用keadm join边缘节点时，支持使用--hub-protocol 配置云边通信协议。目前 KubeEdge 支持 websocket 和 quic 两种通信协议，默认为 websocket 协议。命令示例：keadm join --cloudcore-ipport <云节点ip>:10001 --hub-protocol=quic --kubeedge-version=v1.16.0 --token=xxxxxxxx说明：当--hub-protocol设置为 quic 时，需要将--cloudcore-ipport的端口设置为10001，并需在CloudCore的ConfigMap中打开quic开关，即设置modules.quic.enable为true。操作示例：使用 kubectl edit cm -n kubeedge cloudcore，将 quic 的 enable 属性设置成 true，保存修改后重启 CloudCore的pod。modules： ...... quic: address: 0.0.0.0 enable: true #quic协议开关 maxIncomingStreams: 10000 port: 10001 ......更多信息可参考：https://github.com/kubeedge/kubeedge/pull/5156keadm join 与 CNI 插件解耦在新版本中，keadm join边缘节点时，不需要再提前安装 CNI 插件，已将边缘节点的部署与 CNI 插件解耦。同时该功能已同步到 v1.12 及更高版本，欢迎用户使用新版本或升级老版本。说明：如果部署在边缘节点上的应用程序需要使用容器网络，则在部署完 EdgeCore 后仍然需要安装 CNI 插件。更多信息可参考：https://github.com/kubeedge/kubeedge/pull/5196▍升级 K8s 依赖到 v1.27新版本将依赖的 Kubernetes 版本升级到 v1.27.7，您可以在云和边缘使用新版本的特性。更多信息可参考：https://github.com/kubeedge/kubeedge/pull/5121  版本升级注意事项  新版本我们使用 DaemonSet 来管理边端的 MQTT 服务 Eclipse Mosquitto 了，我们能够通过云端 Helm Values 配置来设置是否要开启 MQTT 服务。使用 DaemonSet 管理 MQTT 后，我们可以方便的对边端 MQTT 进行统一管理，比如我们可以通过修改 DaemonSet 的配置将边端 MQTT 替换成 EMQX。但是如果您是从老版本升级到最新版本，则需要考虑版本兼容问题，同时使用原本由静态 Pod 管理的 MQTT 和使用新的 DaemonSet 管理的 MQTT 会产生端口冲突。兼容操作步骤参考：1、您可以在云端执行命令，将旧的边缘节点都打上自定义标签kubectl label nodes --selector=node-role.kubernetes.io/edge without-mqtt-daemonset=""2、您可以修改 MQTT DaemonSet 的节点亲和性nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - ... - key: without-mqtt-daemonset operator: Exists3、将节点 MQTT 改为由 DaemonSet 管理# ------ 边端 ------ # 修改/lib/systemd/system/edgecore.service，将环境变量DEPLOY_MQTT_CONTAINER设置成false # 这步可以放在更新EdgeCore前修改，这样就不用重启EdgeCore了 sed -i '/DEPLOY_MQTT_CONTAINER=/s/true/false/' /etc/systemd/system/edgecore.service # 停止EdgeCore systemctl daemon-reload && systemctl stop edgecore # 删除MQTT容器，Containerd可以使用nerdctl替换docker docker ps -a | grep mqtt-kubeedge | awk '{print $1}' | xargs docker rm -f # 启动EdgeCore systemctl start edgecore # ------ 云端 ------ # 删除节点标签 kubectl label nodes without-mqtt-daemonset新版本的 keadm join 命令会隐藏 with-mqtt 参数，并且将默认值设置成 false，如果您还想使用静态 Pod 管理 MQTT，您仍然可以设置参数--with-mqtt来使其生效。with-mqtt 参数在 v1.18 版本中将会被移除。  致谢  感谢 KubeEdge 社区技术指导委员会(TSC)、各 SIG 成员对 v1.16.0 版本开发的支持与贡献，未来 KubeEdge 将持续在新场景探索与支持、稳定性、安全性、可扩展性等方面持续发展与演进！▍相关链接Release Notes：cid:link_0更多云原生技术动向关注容器魔方添加小助手k8s2222进入技术群