作者：王彬丞、杨志佳、刘家伟随着万物互联时代快速到来，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进入技术群

  背景介绍  当今社会正处在一个技术飞速发展、机器人与人工智能深入应用于工业领域的时代。在物流、制造和零售等领域，自动导引车（AGV）已经成为高效生产的关键工具，正在全球范围内迅速发展并得到广泛应用。2022年，我国 AGV 销量为93000台，同比增长29.2%；销售规模为185亿元，同比增长46.8%；海外销售规模为36亿，同比增长44%。AGV 系统中的无人驾驶技术，不仅可以提高生产效率，减少人工操作失误的概率，还可以在复杂和危险的环境下保障操作人员的安全。图 1 定制化接口与统一接口下，工厂调度系统架构图尽管 AGV 技术被广泛应用，却缺乏调度系统与 AGV 之间的统一接入协议。图1(a)展示了单个工厂部署不用厂家 AGV 的软件架构图，其中 MES/WMS/ERP 代表上层业务系统，RCS 代表 AGV 调度系统或云端控制平台。由于 AGV 与 RCS 之间的接口是定制化且封闭的，因此 AGV 与 RCS 的厂家属于强耦合关系，即厂家1的 RCS 无法调度厂家2的 AGV。因此对于工厂用户来讲，为了保证不同厂家的机器人安全工作，必须划定交管区域。在同一个交管区内，同一时刻只允许同一厂家的机器人进入，显著降低了任务的执行效率和 AGV 的利用效率。因此，制定一套全面、深入、适用各种环境和物流领域的调度系统与 AGV 的协议，对于统一调度系统与设备之间对接，提升 AGV 的效率、稳定性和安全性至关重要。统一的协议标准不仅明确 AGV 供应方的责任，同时也为 AGV 需求方提供保障。图 1(b)展示了统一接口下的软件架构图，可以看到，RCS 与 AGV 之间不再存在耦合关系。总结来讲，统一接口相比于定制化的接口存在以下优势：安全性高：所有厂商的 AGV 被 RCS 当作白盒集中处理，从源头杜绝碰撞，保障安全；调度效率高：同一场地无需划定交管区，AGV 也无需在“红绿灯”前长时间等待；业务连续性强：终端用户的采购方案更加灵活，无需被单个 AGV 供应商绑定；部署运维成本低：单 RCS 部署的模式，显著降低计算资源和运维人员的成本；扩展性强：支持不同厂家的新旧设备共存，用户可以按需引入新的 AGV；为此，华为联合中外运、顺丰、龙岩烟草、海康、海柔、蓝芯、斯坦德、镭神、边缘计算产业联盟、中国物流与采购联合会等30+伙伴共同起草了《云端控制平台与物流自动导引车通用接口指南》，旨在将相关的经验贡献给行业，促进我国机器人行业的蓬勃发展。  协议内容  ▍内容简介该文件规定了 AGV 与云端控制平台的接口模型、客户端通信安全认证、通信协议结构，以及控制、传输流程接口的技术要求和检验规则。适用于物流、仓储、制造业等领域的物流自动导引车实现云端控制的系统接口设计、开发、检验等。图 2 云端控制平台与AGV报文交互示意图图 2 展示了云端控制平台与 AGV 的交互流程图，整体分成以下几步：AGV 在初始化完成后，向云端控制平台发起接入申请，可选普通模式接入和安全模式接入。在普通模式中，后续报文将直接发送至对端。在安全模式中， AGV 与云端控制平台将协商会话密钥，且后续报文以密文的形式发送。AGV 向云端控制平台发起注册请求。注册成功后，将会周期性的上报自身状态；云端控制平台配置 AGV 的全局信息，如状态上报周期、告警参数等；AGV 周期性地向云端控制平台上报自身状态，并与云端控制平台保持心跳；云端控制平台根据上层业务系统输入，下发每个 AGV 的控制报文，驱动 AGV 运动；AGV 可以根据需求向云端控制平台申请安全空间，以完成自主运动，如动态绕障。▍协议亮点图 3 协议亮点信息安全：在普通接入模式的基础上，新增了安全加密模式。AGV 与云端控制平台通过 SM2 密钥交换协议协商会话密钥，然后使用该密钥对传输的报文进行 SM4 分组密码算法进行加密后，利用 SM2 数字签名算法生成签名，再对密文和签名进行传输，从而保证整个通信过程的安全；多地图管理：为满足 AGV 跨楼层和跨楼栋搬运的需求，协议规定了 RCS 和 AGV 的地图切换流程。同时指明了 AGV 在同一场地下，在 SLAM 和二维码导航之间的切换流程；双向路径规划：协议不仅规定了 RCS 规划的路径下发给 AGV 的流程，同时支持车体在极端环境下自主规划且平台授权的轨迹形式方法，如临时性避障；通信数据：采用二进制报文，显著降低通讯的数据量，减轻了对网络的依赖。同时保留多个预留字段，便于扩展和定制化实现。▍行业推广 协议的蓬勃发展离不开行业的应用和推广。KubeEdge 是边缘计算领域的开源平台，构建在 Kubernetes 之上，为网络、应用部署和云端与边缘之间的数据同步提供基础设施的支持，其目标和应用范围与当前协议的宗旨十分契合。因此 KubeEdge 将作为协议推广的重要阵地，其功能包括但不限于文档展示、协议内容详细解读、协议代码参考实现和端到端调度系统实现等，为了广大厂商和终端用户提供了良好的交流平台。▍相关链接仓库地址：cid:link_0更多云原生技术动向关注容器魔方添加小助手k8s2222进入技术群

作者：达益鑫 |南开大学，刘家伟、吴锟 |DaoCloud，王杰章 |华为云▍特性研发背景以及原理KubeEdge EdgeMesh 边缘 CNI 特性针对于边缘容器网络复杂异构环境提供与云上一致的容器网络体验，包括：1. 云边统一的容器网络资源管理分配2.基于分布式中继及穿透能力的 PodIP 级别跨子网流量转发服务特性开发背景EdgeMesh 致力于研究和解决边缘计算场景下网络连通、服务协同、流量治理等相关的一系列问题，其中在异构复杂的边缘网络环境内，不同物理区域的容器在面对动态变迁的网络环境以及短生命周期且跳跃变迁的服务位置，一部分服务可能需要使用 PodIP 进行跨网段通信，而主流的 CNI 方案主要针对于云上稳定且集成式的网络环境，并不支持跨子网流量的转发，致使这些 CNI 方案并不能够很好地适应边缘复杂异构的环境，最终导致容器即便在同一个集群内却没有享用一个平面的网络通信服务。针对这个需求，EdgeMesh 进行逐步的优化。首先实现的是网络底层的中继以及穿透服务功能开发，即 EdgeMesh 高可用特性。在分布式网络场景当中，该特性能够为节点提供基于 Service 的中继流量以及网络穿透服务，但还没有完全支持对 PodIP 层次流量的转发和穿透能力。换句话说在云边混合的场景当中 ，EdgeMesh 能够为跨网段的 Service 流量提供穿透服务，但并没有涉足到容器网络的资源管理和 IP 层的连通性功能，仍旧依赖于集群原本的 CNI 方案。这个局限性导致 EdgeMesh 无法为更加底层的网络 IP 流量提供服务，意味着 EdgeMesh 并不能够完全覆盖混合云边的场景需求，对于那些需要穿透和中继服务的 PodIP 流量，老版本的 EdgeMesh 爱莫能助。那么为什么主流的 CNI 方案无法兼容边缘环境，EdgeMesh 又是如何理解这个需求的呢？关键问题在于主流的 CNI 方案大多建立于至少三层可通的环境要求之下，具体来说 CNI 自身管理创建网络资源的时候，并不能够感知底层网络的状态，其管理能力高度依赖于 Kubernetes 系统提供的 Node IP 地址，而这个地址的连通性是由底层的网络设备来维持的，如果宿主机不能通过该 Node IP 访问到目标，那么容器网络的虚拟 IP 就更没有办法联通了，原理也将在下文详述。这也意味着 Kubernetes 系统所给的 Node IP 在边缘这样底层网络并不稳定的环境下无法保障稳定的底层通信服务。EdgeMesh 基于上述理解，对这个需求进行细化的分析：边缘网络拓扑结构变动性强，且物理隔离场景较多，致使容器网络环境难以呈现出云上那样稳定的底层设施特征，比如边缘环境中自动驾驶场景或者是快递运输场景等。在这样的环境中，物理节点本身并不是绑定固定地址，甚至涉及到 5G 信号核心网注册切换等通信上的流程问题，使得 IP 地址和网络拓扑并不具备完全意义上的寻址能力，通俗说某个节点可能在上一时刻在 A 区域但是过了一会他就行驶到 B 区域了，这样动态变化切换的场景是以往 CNI 架构不曾考虑的。CNI 的连通性是基于 Kubernetes 的 Node IP 维持的，更加深入理解这个结论：主流的 CNI 相信 Kubernetes 系统设置的 IP 地址是可以联通的，所以这些主流的 CNI 方案管理虚拟网络往往都使用这样的方法：宿主机操作系统中的一个切换装置，通过让自己作为虚拟网络资源和实际物理网络环境的中继；正如下图所示， CNI 只是通过 k8s 系统，在各个节点上创建了虚假的地址，通过信息协同的方式让拥有这些虚假地址的数据包可以正常在单机节点上传送给目标，但根本还是依赖于 Node IP 可以访问联通，毕竟如果数据包不能够正常到达目标节点，CNI 利用操作系统所作的虚假行为也就没有了意义。反过来说也无法超过于单机操作系统能够管理的网络连通性，多机分布式场景下完全只能够依靠 Kubernetes 系统。当然，也并非所有的主流 CNI 都只在本机的操作系统内做文章，更加深入解决连通性的 Calico 组件有提供基于 BGP 协议的跨机连接方案，但也围绕着云上数据中心架构展开的。与此相对应的边缘环境中， 节点的 IP 地址是存在着局域性、变动性、不确定性的，可以风趣地说 Kubernetes 系统被节点欺骗了。容器生命周期短暂且不确定，这个特性更像是此类问题的催化剂，使得边缘割裂场景下的网络连接更加难以使用固定的拓扑结构来进行规划管理。系统设计思路在本特性初阶段我们确定了此次项目实现的目标：是结合 EdgeMesh 已有的 P2P 功能来提供 CNI 特性， CNI 特性在目前阶段并不意味着开发出完全替代Flannel、Calico、Cilium 等已有架构的完全独立 CNI，而是作为多阶段逐步迭代实现的特性。一方面从用户角度来说，如果直接替代云上已有的 CNI 架构，会带来额外的部署成本，也无法向用户保证新的架构有足够的价值可以完全覆盖老体系的场景和功能，以项目迭代开发的方式，优先实现一些能力，再慢慢优化、敏捷开发更能符合用户的利益。因而对于云上环境，我们倾向于直接兼容已有的 CNI 架构，使用它们提供的服务，但是补足他们不能够提供的 P2P 功能。与此同时，现有的 CNI 方案并不能够为边缘复杂异构的环境提供统一的容器网络服务，所以相较于 Docker 或者是其他 CRI 提供的简单网络功能，我们更倾向于直接开发出自己的 CNI 来实现对边缘容器网络资源的管理。而在上述的 CNI 需求之外，最重要的是如何与 EdgeMesh 的 P2P 服务结合起来；目前的开源社区中实现隧道的技术有：如 VPN，包含 IPSec、Wireguard等；如 P2P，包含 LibP2P 等，结合 EdgeMesh 应对的复杂异构多变边缘环境，我们选用了 LibP2P 技术进行开发。在此之上需要判断哪些PodIP流量需要 P2P ,哪些流量仍旧使用原本的 CNI 网络服务；再来是将这两部分的功能解耦，以便后期的功能逐步迭代优化，主要的系统架构如下图所示：上述系统设计将集群内的流量分为两类：同一网段流量： 指的是底层网络 NodeIP 可通信，Pod 容器流量通过 CNI 转换即可进行通讯。跨网段流量: 指的是底层网络不可直接访问， Pod 容器流量通过 CNI 转换封装也无法到达目标节点。针对于不同的流量我们提供不同的流量传输方式：对于同一网段的流量：依旧使用主流 CNI 的方案，通过 CNI 转换地址的形式切换虚拟网络和真实网络，连通性依赖 Kubernetes 系统获取的 NodeIP。对于跨网段的流量： 将这部分流量拦截到 EdgeMesh 当中，通过中继或者是穿透的形式转发到目标的节点，此时 EdgeMesh 充当具有 P2P 功能的 CNI 插件，来完成虚拟网络的切换。这样的设计需要解决亮点重要的问题：云边集群容器网络资源统一控制管理边缘节点以及云上节点 CNI 共同管理容器网络资源，使得容器可以分配到集群唯一的 IP地址，且不论云边都可以通过这个 IP 地址进行通信。云边以及边边跨网段容器网络通信能力兼容原本 CNI 的通信方式让需要 P2P 的流量跨网段传输。系统设计的关键抉择在于，是否需要将 P2P 的功能放置到 CNI 执行的关键路径当中，或者是将 P2P 的功能与 CNI 架构解耦。针对于第一个问题，核心关键是 IPAM 插件的设计和兼容，这方面我们倾向于集成开源社区成熟的方案 Siderpool ：📌 ：https://github.com/spidernet-io/spiderpool Spiderpool 是一个kubernetes 的 underlay 和 RDMA 网络解决方案， 同时也是一款 CNCF Sanbox级别项目这一方案也更加契合容器网络插件化设计的理念，用户可以依据业务的需求来更改系统组件的组合，在现阶段完全满足多 CNI 统一管理集群资源的设计。针对第二个问题，核心在于为 CNI 创建的容器网络资源添加跨子网的连通性。方案设计上，如果将中继和穿透的功能放置到 CNI 执行的关键路径中，那就意味着需要在内核中实现中继和穿透的流程，否则将带来巨大的性能消耗。实际上目前 Calico 、 Flannel 、Cilium 等架构在云上使用隧道技术时候就是采用这个方法：在容器资源创建修改的时候，同步修改内核中的网络设备参数，然后对数据包进行封装或者是修改，比如 Vxlan 服务中将目标是其他节点容器的流量拦截，然后添加对协议参数。这个方式在云上运用较为普遍，但是明显无法适应边缘的环境，原因在于：CNI 执行是无状态且一次性的，只有当容器网络资源创建、修改、删除的时候， CNI 调用链会被触发并执行对应的功能；这个方式的实质是通过静态配置的方式来提供通信服务，对于云上较为稳定的网络环境以及通信条件来说，确实是合适的选择，但对于边缘环境来说，网络资源并非一成不变；如果将隧道信息配置为静态形式，再通过 CNI 调用链触发管理，就无法应对部分容器动态变化之后隧道信息变迁的情况。在上述考量的基础上，本特性将 分开 CNI 和 P2P 的功能，解耦彼此在系统运作上的依赖关系，这样也更加方便用户可以选择是否开启其中的一项功能。边缘 CNI 功能这部分设计为实现基础的 CNI 调用链功能，在边缘节点管理容器网络资源，同时通过 IPAM 组件 spiderpool 兼容云上其他的 CNI 架构，统一分配集群的容器网络资源，包括基础的 CNI 功能，其次是通过 SpiderPool 实现全局的容器 IP 地址唯一。基于以上各组件设计,当集群内每一个容器都拥有了唯一的 IP 地址，我们接下来需要做的是为需要中继穿透的流量提供服务，设计方式为： 用户配置全局容器网段文件，分为云上 CIDR 和 边缘 CIDR ，每一段 CIDR 对应一个区域网络即 三层不可通的网络， EdgeMesh 通过配置文件插入路由表规则，将目标地址于本节点 CIDR 不相同的流量都拦截到本机的Tun 设备，再传输到 EdgeMesh 的 libP2P host 通过中继或者穿透的方式传输到目标地址。▍特性启用以及功能启用 EdgeMesh 边缘 CNI 特性您可以通过以下配置的方式，在启动 EdgeMesh 时候启用 CNI 边缘 P2P 特性，配置过程中您可以依据对云边网段资源的划分需求来配置云边容器网络所处的区域：# 启用 CNI 边缘特性 helm install edgemesh --namespace kubeedge \ --set agent.relayNodes[0].nodeName=k8s-master,agent.relayNodes[0].advertiseAddress="{1.1.1.1}" \ --set agent.cloudCIDR="{10.244.1.0/24,10.244.1.0/24}",agent.edgeCIDR="{10.244.5.0/24,10.244.6.0/24}" https://raw.githubusercontent.com/kubeedge/edgemesh/main/build/helm/edgemesh.tgz上述配置的参数中 cloudCIDR 是云上容器集群分配的地址， edgeCIDR 是边缘容器集群分配的地址；EdgeMesh 会对比部署节点分配到的容器网段 CIDR 与配置文件中是否属于不同网段，属于不同网段的地址会添加对应的 ip route 规则拦截到 Tun 设备。cloudCIDR 参数是云上分配的容器网段，类型为 []string ，形式为容器 IP 地址以及其子网掩码，表示一段虚拟网络区域，在区域内的容器应当网络二层可通，如果容器不能够通过二层设备访问，请划分为不同的容器网段。edgeCIDR 参数是边缘分配的容器网段，类型为 []string ，形式为容器IP地址以及其子网掩码，表示一段虚拟网络区域，在区域内的容器应当网络二层可通，如果容器不能够通过二层设备访问，请划分为不同的容器网段。名称参数类型使用实例agent.meshCIDRConfig.cloudCIDR[]string--setagent.meshCIDRConfig.cloudCIDR="{10.244.1.0/24,10.244.1.0/24}"agent.meshCIDRConfig.edgeCIDR[]string--setagent.meshCIDRConfig.edgeCIDR="{10.244.1.0/24,10.244.1.0/24}"需要注意的是设置的地址必须为 CIDR 形式 ，同时需要您依据云边网络情况划分出对应的网段；另一方面本特性需要同时启动高可用特性，为跨网段的流量提供中继和穿透服务。更多的安装配置信息请详见：helm安装 : https://edgemesh.netlify.app/zh/guide/#helm手动安装：https://edgemesh.netlify.app/zh/guide/项目功能特性介绍依据系统的设计，边缘 CNI 特性提供以下具体的功能：云边集群容器网络资源控制管理📌 ：现版本推荐集群云上节点使用 calico/flannel/cilium 等 CNI 插件，同时边缘集群节点使用 EdgeMesh CNI 插件，整个集群配置 SpiderPool 作为统一的地址管理插件来提供服务。针对于边缘网络复杂异构的情况，EdgeMesh 提供了边缘 CNI 插件来创建和管理边缘节点容器的地址资源，同时通过配合 IPAM 插件 spiderpool 协调云上节点的其他 CNI 插件来实现 整个集群的容器地址唯一，云边节点都可以通过唯一的地址进行通讯。如下图所示，该项功能的主要特性在于屏蔽了云边复杂的网络集群拓扑，实现了云边集群统一的容器资源管理，使得云边的容器可以体验如同在一个局域网内的通信服务，而不必考虑边缘集群节点容器地址重复或者是云边集群底层地址不通的问题。云边以及边边容器网络通信能力针对于边缘环境中云边和边缘通信问题，EdgeMesh CNI 特性集成了 P2P 的功能，为跨网络集群的容器流量提供中继和穿透服务。该 P2P 特性现版本主要通过 TUN 设备在 IP 层拦截需要中继和穿透服务的流量实现，能够为应用网络通信提供底层连接的服务，而不受到 IP 层以上网络协议的影响。系统功能运行如下图所示，在每个节点上的 EdgeMesh 会通过修改 IP Route 的形式拦截流量到 TUN 设备，再传输到 EdgeMesh 的 libP2P host 通过中继或者穿透的方式传输到目标地址。这个过程中 EdgeMesh 并不会拦截所有的流量而是通过用户在启动时候设置的网络区域参数来区别哪些流量是跨网段，哪些流量是同局域网访问的，并不会干扰到正常同网段流量的通信。后续计划以及未来设想在项目开发的初期阶段，系统设计基础实现了最初的需求，但是在边缘容器网络环境当中，由于网路部署和设备架构的使用情况多样复杂，对于容器网络提出了三方面重点的需求：可观测具体指的是对于云边以及边边流量的去向，包含在节点内操作系统处理的过程以及节点外多节点之间转发传输的流程可观测性。这类需求对于运维人员以及应用开发人员有着非常重要的价值和意义，可以快速定位网络流量问题出现的位置和导致的原因，并快速得出性能优化的方案和解决问题的办法。高性能与纯云部署的容器集群相似，云边混杂集群同样也面临着性能堪忧的问题，在网络层面主要指的是节点内对网络数据包在操作系统处理路径上的优化，减少其处理的逻辑和相关资源的消耗。强稳定相较于纯云上集群的部署，云边混杂集群的状态往往难以稳定，需要服务能够应对环境变化同时在出现问题时候较快地将流量卸载到正常的服务当中。针对于这些需求， 容器网络 CNI 功能是重点开发和创新的系统组件， EdgeMesh 将在接下来的系统开发中结合 eBPF 等内核优化技术，同时以实现一款泛用的边缘 CNI 插件为目标，推出应对这三点需求的特性和功能，期待能够为用户带来更加丰富和稳定的网络服务体验。附：KubeEdge社区贡献和技术交流地址[1] 网站: https://kubeedge.io[2] Github地址: cid:link_0[3] Slack地址: https://kubeedge.slack.com[4] 每周社区例会: https://zoom.us/j/4167237304[5] Twitter: https://twitter.com/KubeEdge[6] 文档地址: https://docs.kubeedge.io/en/latest/更多云原生技术动向关注容器魔方添加小助手k8s2222进入技术群

作者：华为云云原生团队▎边缘计算安全防护的实践与洞察随着开源软件安全漏洞持续引起世界各地政府和企业的关注，越来越多的组织、开发人员、研究人员和安全专家投入到开源安全工作中，在各方力量的推动下，开源安全目前已初步形成体系化的生态大网，覆盖了国际化的软件工程行业标准、安全评估体系、安全工具链与整体解决方案等，并逐步撬动整个业界开源软件安全行业的生态产业链。在2020年Linux基金会与多家硬件和软件厂商合作创立了开源软件安全基金会OpenSSF（Open Source Security Foundation），这是一个跨行业的合作组织，汇集了行业领军企业与机构，涵盖世界上最重要的软件供应链安全计划、开源开放的工具链、安全指南、培训等，旨在提高开源软件（OSS）的安全性。作为业界首个云原生边缘计算项目，KubeEdge社区致力于提升KubeEdge在云原生边缘计算场景下的安全性，将安全视为社区发展的重要指导原则。社区充分结合了业界的开源安全经验，于2022年7月完成了对KubeEdge项目的安全威胁模型分析。尽管云原生边缘计算的安全问题备受用户关注，但业界目前缺乏相关的安全威胁模型分析，这使得用户难以有效地加固其边缘系统。因此，KubeEdge社区发布了安全威胁模型及分析白皮书，为用户和厂商提供了重要的安全实践指导。下文将着重介绍Kubeedge在安全防护方面的实践，并介绍OpenSSF在开源软件安全方面的计划与目标。▎KubeEdge安全防护安全防护背景KubeEdge在边端云协同领域正在加速布局，已在智慧交通、智慧城市、智慧园区、智慧能源、智慧工厂、智慧银行、智慧工地、CDN等行业提供一体化的边端云协同解决方案。随着越来越多的用户将KubeEdge项目用于生产环境中， KubeEdge社区把安全问题放在优先地位，并成立Sig- Security 和安全团队 ，负责KubeEdge的系统安全设计，并快速响应和处理安全漏洞。为了对KubeEdge项目进行更加全面的安全评估，KubeEdge社区联合ADA LOGICS公司、OSTIF及云原生计算基金会（CNCF）对KubeEdge项目进行安全评估并输出安全评估报告，分析和总结KubeEdge项目的安全威胁模型及相关安全问题。该评估对KubeEdge项目的安全防护有重要的指导意义，感谢ADA LOGICS公司的专家Adam Korczynski和David Korczynski在该项工作中的巨大贡献，同时，感谢OSTIF的Amir Montazery和Derek Zimmer以及CNCF基金会，他们对这次评估提供了很大帮助。对于安全报告中发现的安全问题，KubeEdge社区已根据社区的漏洞处理策略第一时间完成修复，并针对v1.11、v1.10、v1.9三个版本发布了安全补丁，版本号分别为v1.11.1、v1.10.2和v1.9.4，漏洞公告已发布在cid:link_4。接下来将通过解读KubeEdge威胁模型，为边缘计算领域提供更多的安全防护经验，并在开源软件供应链安全加固工作上为更多的开源社区提供参考。威胁模型分析KubeEdge的安全审计报告指出，该系统可能受到外部攻击、内部操作人员的不当操作和供应链攻击等三种潜在攻击类型的影响。本章节使用STRIDE威胁建模方法，结合安全审计报告对KubeEdge进行了系统的安全分析，包括上述三个方面。目的是帮助开发者和用户了解系统中的潜在安全威胁、明确风险并列举出目前KubeEdge社区已有的消减机制和安全加固建议。以下人群使用KubeEdge过程中，了解KubeEdge的威胁模型分析和可能的缓解措施将对他们的工作有所帮助：• KubeEdge的贡献者：一个通用的威胁模型对KubeEdge贡献者很有用，他们可以从整体角度考虑并加固他们的系统。• 部署KubeEdge的组织：对于在集群中使用KubeEdge的组织来说，了解常见的攻击和可能的弱点是很有用的，这样他们就可以检查和评估自己的配置。• 安全评估员：负责评估KubeEdge及所属Kubernetes集群的安全性。通过了解该威胁模型，让安全评估员可以对系统的安全风险进行更加全面的评估。• KubeEdge的用户及其开发人员：需要了解KubeEdge的更新和攻击，以主动避免未来可能发生的安全风险。外部攻击分析根据STRIDE威胁建模方法对KubeEdge潜在的外部攻击进行分析，对应的数据流图如下。如数据流图所示，当数据流穿越不同的信任级别（区域）时，就存在信任边界，已在图中用红框标出。下面将详细分析KubeEdge系统架构中的信任边界（引用自KubeEdge第三方安全报告）、社区已有的消减措施并给出安全加固建议。威胁一：云端CloudCore组件与EdgeCore组件之间的连接描述：该威胁涉及边缘EdgeCore与云端CloudCore之间的连接。在这个数据流中，较低信任级别组件EdgeCore向较高信任级别组件CloudCore发起访问。由于EdgeCore在系统中拥有独立的权限级别，攻击者控制EdgeCore后，不应该能够对其他边缘节点造成负面影响，例如通过攻击和操控CloudCore来攻击其他节点（该漏洞描述引用自安全评估报告）。影响：攻击者恶意修改CloudCore与EdgeCore组件之间的请求和应答报文，导致通信过程存在仿冒和篡改的威胁风险。消减措施：• CloudCore与EdgeCore之间的通信通过数字签名证书加密和服务端/客户端双向认证的方式保障信息交互的机密性和完整性，安全加密协议使用TLS 1.2，且指定加密算法套件白名单，防止客户端使用不在白名单中的不安全算法进行通信造成安全风险；• 证书默认有效期为一年，过期后失效，防止证书被攻击者利用。用户基于KubeEdge项目已有的证书轮转机制，可以实现证书过期自动更换，保障业务连续性。针对该威胁，我们建议采取以下安全加固措施（见“安全加固建议列表”中的Recommendation ID 1和2）。威胁二：边缘组件ServiceBus在本机范围内提供HTTP服务描述：边缘组件ServiceBus监听本地local host端口并在本机范围内提供HTTP服务。该数据流中，较低信任级别的用户应用进程向较高信任级别组件ServiceBus发起访问。如果发起攻击，不应该使攻击者能够将影响范围扩大到云端控制面（该漏洞描述引用自安全评估报告）。影响：ServiceBus组件收到的数据往往是不受管理面控制的，攻击者能够对ServiceBus组件发起恶意报文攻击，导致通信过程存在仿冒和篡改的威胁风险。ServiceBus组件异常仅影响单个边缘节点服务故障，不会导致整个KubeEdge系统崩溃。消减措施：• ServiceBus组件仅监听本地local host端口，已限制服务范围，只允许本机进程访问，通过对本机用户访问权限的限制保障本组件安全；• 服务端接收客户端连接时记录连接访问的日志，可作为审计日志，可以让管理员及时发现攻击的发生，并及时停止ServiceBus服务，阻止攻击继续进行；• ServiceBus服务默认关闭，遵守默认安全的原则。在用户使用文档中已明确提示用户如果开启该服务，则存在上述风险。针对该威胁，我们建议采取以下安全加固措施（见“安全加固建议列表”中的Recommendation ID 3、4和5）。威胁三：边缘端Device通过MQTT Broker连接到EdgeCore描述：边缘device设备通过MQTT Broker（集成在EventBus组件中）连接到EdgeCore。该数据流中，较低信任级别的用户device设备向较高信任级别组件EdgeCore发起访问（该漏洞描述引用自安全评估报告）。影响：EdgeCore组件收到的数据往往是不受管理面控制的，攻击者能够对MQTT Broker发起恶意报文攻击，存在仿冒和篡改的威胁风险。如果发起攻击导致EventBus组件异常，异常仅影响单个边缘节点服务故障，不会导致整个KubeEdge系统崩溃。消减措施：• MQTT Broker仅监听在本机端口，已限制服务范围，只允许本机进程访问，通过对本机用户访问权限的限制保障本组件安全；同时，EventBus组件可作为客户端，对接外置第三方MQTT Broker，如果用户使用第三方MQTT Broker，详细的消减措施请参考对应第三方MQTT Broker服务提供厂商的安全文档。• EventBus仅对MQTT Broker中的特定Topic进行处理，用户无法通过该通道对EdgeCore任意访问。针对该威胁，我们建议采取以下安全加固措施（见“安全加固建议列表”中的Recommendation ID 3、4、5和6）。威胁四：Edged管理和监控Pods及其他K8s资源描述：Edged管理和监控Pods及其他K8s资源。该数据流中，较低信任级别的应用容器与较高信任级别组件EdgeCore之间进行数据交互。如果主动发起连接时，被恶意服务器攻击，不应该使攻击者能够将影响范围扩大到云端控制面（该漏洞描述引用自安全评估报告）。影响：如果Edged访问的CRI插件被攻击者恶意伪造，则存在CRI插件仿冒和篡改的威胁风险，导致本地业务异常。消减措施：• Edged与CRI插件通信时，只在本地访问受信任路径，由管理员控制访问路径，最小化Unix domain sockets文件描述符的权限，避免被仿冒者恶意替换。针对该威胁，我们建议采取以下安全加固措施（见“安全加固建议列表”中的Recommendation ID 3和7）。威胁五：MetaServer在边缘节点提供HTTP服务描述：MetaServer作为边缘“api-server”，对边缘插件提供HTTP服务。该数据流中，较低信任级别的用户应用插件向较高信任级别组件MetaServer发起访问（该漏洞描述引用自安全评估报告）。影响：MetaServer组件收到的数据往往是不受管理面控制的，攻击者能够对MetaServer组件发起恶意报文攻击，导致通信过程存在仿冒和篡改的威胁风险。MetaServer组件异常仅影响单个边缘节点服务故障，不会导致整个KubeEdge系统崩溃。消减措施：• MetaServer组件仅监听本地local host端口，已限制服务范围，只允许本机进程访问，通过对本机用户访问权限的限制保障本组件安全；• MetaServer服务默认关闭，遵守默认安全的原则。在用户使用文档中已明确提示用户如果开启该服务，则存在上述风险。针对该威胁，我们建议采取以下安全加固措施（见“安全加固建议列表”中的Recommendation ID 3、4和5）。内部攻击分析对于内部管理员或操作人员，可能的风险主要包括管理员或操作人员错误操作将恶意软件部署至集群中、在高风险场景中执行高风险配置等。消减措施：• KubeEdge用户手册中已提供各个组件的详细功能描述及配置使用指导文档 ，指导系统管理员或操作人员正确操作，减少人为误操作或误配置导致的安全风险。由于KubeEdge的持续迭代，该文档也将持续更新并完善。针对该威胁，我们建议采取以下安全加固措施（见“安全加固建议列表”中的Recommendation ID 3、4、8和9）。供应链攻击分析攻击可能发生在典型软件供应链的每一个环节，而且在当今环境中，这些类型的攻击越来越公开，破坏性和代价高昂。攻击方向包括源代码完整性、构建完整性和构建产物的可用性。消减措施：• 社区联合安全公司对KubeEdge软件供应链流程已进行SLSA等级评估，并引入SLSA软件供应链安全评估框架，包括对源代码、构建流程、依赖库等进行安全评估，防止针对软件供应链的攻击，从源头上保障软件供应链的安全。值得一提的是，在2023年1月18日发布的v1.13.0版本中，KubeEdge项目已达到SLSA L3等级（包括二进制和容器镜像构件），成为CNCF社区首个达到SLSA L3等级的项目，并加入Sigstore生态系统，实现更高等级的安全标准。• KubeEdge仓库CI/CD流水线中已开启dependence bot第三方依赖库检查功能，及时发现第三方依赖库的安全漏洞并在KubeEdge版本中同步更新，降低被攻击的风险；• KubeEdge security team已具备完整漏洞处理机制，包括漏洞发现、漏洞上报、漏洞分析处理、漏洞披露和发布整个流程，可以及时处理和修复安全漏洞。详细漏洞处理及披露策略请见https://github.com/kubeedge/community/blob/master/security-team/SECURITY.md。针对该威胁，我们建议采取以下安全加固措施（见“安全加固建议列表”中的Recommendation ID 10和11）。安全加固建议列表Recommendation ID描述1使用安全长度的私钥加密，并加密保存私钥。建议用户生成至少为2048位私钥，且在本地加密存储私钥，存储私钥的文件设置最小化的访问权限，仅属主可读。2使用可信来源的CA证书。从可信的CA获取数字证书，不使用自签名证书。3严格限制边缘节点的本机权限，限制外部用户的用户登录权限，减少非必要的授权。4严格限制边缘节点应用部署的权限，只有系统服务和管理员才能拥有部署特权容器的权限。5在边缘节点部署应用时，严格校验应用镜像的合法性，防止部署恶意应用。6对于接入边缘节点的Device设备进行严格审核，避免非必要设备接入。7严格审查CRI插件的配置，使用CRI对应插件的官方推荐配置。8严格划分系统中各个角色权限，通过RBAC、OPA等方式实现系统角色权限的细粒度控制。9社区发现漏洞后将在最近的3个minor release版本中合入解决，用户可以关注社区security advisory 获取漏洞披露信息，及时跟进并更新KubeEdge版本。10用户使用社区发布的二进制文件前，应该根据社区发布的校验文件进行严格校验，防止二进制被仿冒和篡改。社区release软件包发布地址cid:link_6。11用户或vendors在使用源代码构建过程中，应该参考SLSA软件供应链安全评估框架，对源代码、构建流程、依赖库等进行安全加固。开源安全洞察本章节通过对OpenSSF社区的战略规划、OpenSSF工作组内容及开放源代码软件安全动员10个TOP计划进行介绍，为相关从业人员、开源生态产业提供参考。1) OpenSSF介绍社区工作组为了更好的提升开源软件安全，OpenSSF目前已成立了8个工作组，主要负责开源软件开发最佳实践、软件代码安全、用户、安全工具链、开源项目安全威胁识别、软件供应链完整性、保护关键开源项目、漏洞披露。相关项目1. OpenSSF最佳实践徽章（OpenSSF Best Practices Badge Program）开源软件开发的最佳实践目的是提供开源开发者安全相关行业标准、框架、安全指导、课程、开源安全评估体系、包括工具支持开发人员日常开发过程的软件安全检测。开源项目可以通过OpenSSF最佳实践徽章项目进行最佳实践评估，该项目是自由/开源软件（FLOSS）项目展示其遵循最佳实践的一种方式。可以通过使用这个网站来解释他们如何遵循每个最佳实践，从而自愿地进行自我认证，认证分为通过、银、金三个级别，不需要任何费用。该项目是基于核心基础设施倡议（CII）项目发展而来。2. 积分卡（Scorecards）通过Scorecards积分卡项目可以实现自动化地对开源项目相关安全指标进行评估，以加强项目的安全状况，根据项目的评估结果给出0-10分数，帮助项目maintainer改进项目安全。3. 安全知识框架（Security Knowledge Framework）SKF是一个完全开源的Python-Flask / Angular网络应用程序，它使用许多其他的开源项目来训练你和你的团队通过设计来构建安全的应用程序。其涵盖了整个软件开发生命周期如构建、测试、需求、设计、代码开发、度量、培训等环节。4. 安全开发指南提供安全开发、安全评估的详细指导步骤，以开发者使用视角将上面的项目全部串接起来，已完整覆盖了OpenChain Security Assurance Specification、SLSA、工具如 GitHub's dependabot、GitLab dependency scanning、Scorecards check等。5. 教育与培训课程提供开发人员免费的安全开发课程，完成学习后可以发放证书有效期2年。6. 软件构建供应链级别（SLSA）软件构建的供应链级别SLSA由Google贡献给OpenSSF，是软件供应链完整性的安全标准准则，以帮助企业和开源生态确保软件开发生命周期的安全，ScoreCards是SLSA度量的工具组成部分。7. 令牌分发项目Great Multi-Factor Authentication (MFA) 分发项目。致力于将硬件 MFA 令牌分发给关键的 100+开源软件项目，目标是防止开源软件开发凭据薄弱或受损的供应链攻击。8. 包管理最佳实践提供业界主流的构建框架、包管理器的最佳实践如 maven、gradle、npm、pip、RubyGems，重点介绍其依赖管理、可重复构建、发布、基于包管理的漏洞披露等。当前文档还不完善，只重点介绍了npm，其它的包管理器待建设中。9. C/C++编译选项制定 C/C++场景的编译选项规则，避免潜在的安全风险和被攻击的风险。当前在孵化阶段。10. 开源社区安全教育SIG当前在孵化阶段，主要致力于提供行业标准的安全软件开发相关的培训材料，提供网络和应用程序安全方面的最佳实践辅导开发人员安全地创建、编写、部署和维护软件。OpenSSF安全工具链安全领域涉及面广，规则规范多，开发人员甚至从事资深安全工作的专家人工识别冗余遗漏。安全工具链用于快速识别安全风险，使开发人员专注于功能特性开发。覆盖范围：涵盖整个DevSecOps的各环节工具链，并支撑开源软件开发的最佳实践章节，如：linters(cleanCode), SAST, SCA, DAST, Fuzzers, Hard Coded Secrets Detectors, and SBOM generators。提供方：部分来自公司捐赠，部分来自OpenSSF基金会自主规划，部分在规划阶段待建设。2) 开源软件安全动员计划及目标2022 年 1 月，美国政府专家、 OSS 基金会、相关企业在白宫举行会议讨论，制定如下三个动员计划的总体目标：• 保护 OSS 生产：首先是专注于防止安全缺陷、代码和开源包漏洞• 改进漏洞识别和修复：改进缺陷识别过程、漏洞修复• 缩短补丁响应时间：缩短漏洞披露和修复时间在2022年5月第二届开源软件安全峰会上，Linux基金会、OpenSSF及各行业安全专家，就提高开源软件安全性计划达成共识，将集中在以下10个方向进行投资和安全改善，项目投资1.5亿美元，分为两年规划。备注：动员计划和OpenSSF工作组是相辅相成的，其动员计划的能力会融入到工作组中。投资方向描述安全培训向所有人提供基础安全软件开发培训和认证。风险评估为前 10,000 个（或更多）OSS 组件建立一个公开的、供应商中立的、客观的、基于指标的风险评估仪表板。数字签名加快在软件版本上采用数字签名。内存安全通过替换非内存安全语言来消除大多数漏洞的根本原因。事件响应建立一个由安全专家组成的 OpenSSF 事件响应团队，以协助开源项目加快对新发现漏洞的响应速度。安全扫描通过高级安全工具和专家指导，加快维护人员和专家发现新漏洞的速度。代码审计每年对200+个最关键的OSS组件进行一次第三方代码审查（以及任何必要的补救工作）。数据共享协调全行业的数据共享，以改善研究，帮助确定最关键的开放源码软件组件。SBOMs改进SBOM工具和培训，以推动采用。提升软件供应链安全用更好的供应链安全工具和最佳实践来增强10个关键的开放源码软件构建系统、软件包管理器和分发系统。▎总结本文通过从外部攻击面、内部攻击面及软件供应链三个维度对KubeEdge项目进行安全威胁建模，实现对KubeEdge项目的系统性安全评估，帮助社区maintainer及时发现和修复安全风险。同时，对业界OpenSSF社区开源安全策略及相关项目进行洞察，通过洞察分析可以看出，越来越多的组织、开发人员、研究人员和安全专家将加大投入资源来加强开源安全，并已逐步形成业界开源安全行业的生态产业链，在开源安全上占据标准高地可以为后续的商业扩展提供有力地位。KubeEdge社区结合业界安全理念，将能够推动社区持续巩固和演进项目的安全。▎附录相关链接• 社区漏洞处理机制: cid:link_5• 安全审计报告: cid:link_1• 社区security advisory链接: cid:link_4• KubeEdge威胁模型及安全防护分析（本文档）: cid:link_0• 社区用户文档链接: https://kubeedge.io/en/docs• SLSA软件供应链安全框架: https://slsa.dev/spec/v0.1/#supply-chain-threats• KubeEdge实现SLSA L3分析: https://kubeedge.io/en/blog/reach-slsa-l3/• Release版本发布链接: cid:link_6• 开源软件安全动员计划：https://cta-redirect.hubspot.com/cta/redirect/8112310/3b79d59d-e8d3-4c69-a67b-6b87b325313c• OpenSSF最佳时间徽章：https ://bestpractices.coreinfrastructure.org/en• 最佳实践项目：https://github.com/ossf/wg-best-practices-os-developers添加小助手微信k8s2222，进入云原生交流群

华为云海外首发CCI Serverless容器服务，释放数字生产力在MWC23 巴展期间，华为新产品解决方案发布会在2月27日下午成功举行。在发布会上，华为云全球Marketing与销售服务总裁石冀琳表示：我们希望通过“一切皆服务”的战略，为客户、伙伴和开发者提供稳定、可靠、安全、可持续的云服务。在本次发布会上，华为云海外首发CCI Serverless容器服务正式上线。基于serverless容器架构CCI，客户无需创建和管理服务器节点，即可直接运行容器应用，按需获取、智能运维，让客户只需专注应用开发，无需关注底层资源。具备业务领先的弹性能力，助力客户轻松应对超10倍的突发流量浪涌。CCI Serverless容器具备优势如下：• 聚焦应用免运维1. Serverless无服务器容器使用全新体验2. 客户无需管理服务器或集群• 极致计算性能1. 瑶光统一资源池，提供多种X86、AXD、鲲鹏等类型算力资源2. 全面升级资源拓扑管理能力，保障容器极致算力性能• 智能统筹弹性1. 30秒发放1000容器，满足极速弹性要求2. 支持跨云、跨集群、跨IDC对接的灵活弹性，全场景助力客户业务应对峰值流量    Serverless容器构筑极致性能、高效运维、丰富算力等差异化竞争力，打造大规模高性能云原生Serverless容器资源底座。Source : 华为官网新闻报道KubeEdge 社区 v1.13.0 版本发布，稳定性、安全性大幅提升KubeEdge社区v.1.13.0版本发布。作为2023年最新版本，v.1.13.0性能在稳定性、安全性等方面进大幅提升，其中重大更新如下：• 运行性能提升：对CloudCore 内存使用减少 40%，优化List-watch dynamicController处理，增加云端和边缘之间的list-watch同步机制，增加dynamicController watch gc机制。• 安全性能提升：成为CNCF首个达到软件供应链SLSA L3等级的项目；同时删除边缘节点配置文件 edgecore.yaml 中的 token 字段，消除边缘信息泄露的风险• 对Kuberbetes支持升级至v.1.23.15: 将vendered kubernetes版本升级到v1.23.15，用户现在可以在云端和边缘使用新版本的特性。• 基于 DMI 的 Modbus 映射器：提供基于DMI的Modbus Device Mapper，用于接入Modbus协议设备。• EdgeMes​​h：向边缘隧道模块添加了可配置字段 TunnelLimitConfigedge-tunnel模块的隧道流用于管理隧道的数据流状态。用户可以获得稳定、可配置的隧道流，保证用户应用流量转发的可靠性。KubeEdge云原生边缘计算社区于2022年完成多项关键突破，相继发布《KubeEdge单集群10万边缘节点报告》，《云原生边缘计算威胁模型及安全防护技术白皮书》，并于KubeEdge Summit 2022正式开源分布式协同AI基准测试平台Ianvs。目前项目已完成EdgeMesh高可用架构，KubeEdge on openEuler支持，KubeEdge on openHarmony支持，下一代云原生边缘设备管理框架DMI也将带来更全面的的性能支持与更优的用户体验。欢迎大家测试体验。cid:link_1CNCF持续重视软件供应链安全， KubeEdge成为首个达到SLSA L3等级的项目软件供应链安全持续受到高度关注，CNCF 和OSTIF （Open Source Technology Improvement Fund，开放源码技术改进基金）在过去几年中一直合作，为CNCF 的毕业和孵化项目进行安全审计，保障开源生态系统具有更好的安全性。最新的 OSTIF 报告公布了 2022 年下半年至 2023 年初开展的独立安全审计结果。获得审计通过的项目包含KubeEdge、Argo、Istio、Envoy、CloudEvents等12个项目：审计工作通过创建良好的指导性政策和项目成熟度模型，以及可重复的审计执行流程，以确定风险、威胁媒介并实施工具来改善项目的安全状况。提升项包含：在本次公布的社区中，KubeEdge社区早在2022年7月份，通过完成整个KubeEdge项目的第三方安全审计[2] ，发布《云原生边缘计算安全威胁分析和防护白皮书》，并根据安全威胁模型和安全审计的建议，对KubeEdge软件供应链进行持续安全加固，为本次SLSA L3等级的达成做了充分的准备。在2023年1月18日，社区发布v1.13.0版本，该版本达到SLSA[1] L3等级标准（包括二进制和容器镜像构件），KubeEdge 成为CNCF社区首个达到SLSA L3等级的项目。以下表格展示了KubeEdge在Source、Build、Provenance、Common中的达标情况（Y表示KubeEdge已达标，空格表示SLSA在该等级下未要求）：RequirementL1L2L3L4SourceVersion controlledYYYVerified historyYYRetained indefinitelyYYTwo-person reviewedYBuildScripted buildYYYYBuild serviceYYYBuild as codeYYEphemeral environmentYYIsolatedYYParameterlessYHermeticYProvenanceAvailableYYYTo-doAuthenticatedYYTo-doService generatedYYTo-doNon-falsifiableYTo-doDependencies completeTo-doCommonSecurityYAccessYSuperusersY为什么达到SLSA L3等级对开源项目至关重要软件供应链完整性攻击（对软件包的未经授权的修改）在过去三年中呈上升趋势。SLSA在KubeEdge项目软件供应链安全中发挥着重要作用，基于sigstore社区提供的能力，从源码到发布产物，对软件供应链端到端的整个流程进行签名和校验，确保KubeEdge软件供应链安全。自v1.13.0版本开始， KubeEdge 可以端到端的从源码构建到发布流程进行安全加固，保障用户获取到的二进制或容器镜像产物不被恶意篡改。基于SLSA安全框架，可以潜在地加强软件构件的完整性。SLSA提供端到端的指导原则，可以作为软件的一组防御措施，并防止对组成软件产品的软件包的篡改或任何类型的未经授权的修改。采用SLSA框架可以保护项目软件免受常见的供应链攻击。参考资料[1]  SLSA官网：https://slsa.dev/[2]   KubeEdge项目第三方安全审计：cid:link_0Karmada v1.5 新增多调度组助力成本优化Karmada 是开放的多云多集群容器编排引擎，旨在帮助用户在多云环境下部署和运维业务应用。在最新发布的1.5版本中，Karmada 提供了多调度组的能力，利用该能力，用户可以实现将业务优先调度到成本更低的集群，或者在主集群故障时，优先迁移业务到指定的备份集群。本版本其他新增特性：• 提供了多调度器支持能力，默认调度器可以与第三方自定义调度器协同工作，提供更强的定制能力。• 集群差异化配置策略（OverridePolicy/ClusterOverridePolicy）将按照隐式的优先级进行应用。• 内置资源解释器支持聚合StatefulSet/CronJob 状态。Karmada v1.5版本API兼容v1.4版本API，v1.4版本的用户仍然可以平滑升级到v1.5版本Volcano 社区 v1.7.0 版本正式发布，提升云原生调度能力，强化AI、大数据场景适用度北京时间2023年1月9日，Volcano社区v1.7.0版本正式发布。Volcano是业界首个云原生批量计算项目，项目于2019年6月在上海的KubeCon大会上正式宣布开源，并于2020年4月成为CNCF官方项目。2022年4月，Volcano正式晋级为CNCF孵化项目。Volcano社区开源以来，受到众多开发者、合作伙伴和用户的认可和支持。截止目前，累计有490+全球开发者向项目贡献了代码。Volcano v1.7.0版本在主流计算框架支持、通用服务调度能力、队列资源可观测性等方面进行了增强，新增特性列表如下：• Pytorch Job插件功能强化• Ray on Volcano• 增强Volcano对Kubernetes通用服务的调度能力• 支持Volcano的多架构镜像• 优化队列状态信息等本次版本发布后，Volcano可以更好的适用AI、大数据场景，为使用者提供更简洁易用的Ray、Pytorch等工作负载的云原生调度能力。Volcano云原生批量计算项目主要用于 AI、大数据、基因、渲染等诸多高性能计算场景，对主流通用计算框架均有很好的支持。社区已吸引2.6万+全球开发者，并获得2.8k Star和670+ Fork，参与贡献企业包括华为、AWS、百度、腾讯、京东、小红书等。目前，Volcano在人工智能、大数据、基因测序等海量数据计算和分析场景已得到快速应用，已完成对Spark、Flink、Tensorflow、PyTorch、Argo、MindSpore、Paddlepaddle 、Kubeflow、MPI、Horovod、mxnet、KubeGene、Ray等众多主流计算框架的支持，并构建起完善的上下游生态。ING国际银行基于Volcano开展大数据分析作业，获得Kubernetes更高调度性能在 KubeCon North America 2022， ING荷兰国际集团（International Netherlands Groups）发表了《Efficient Scheduling Of High Performance Batch Computing For Analytics Workloads With Volcano - Krzysztof Adamski & Tinco Boekestijn, ING》主题演讲，重点介绍了云原生批量计算项目Volcano如何在数据管理平台中为大数据分析作业提供高性能调度工作。ING荷兰国际集团（International Netherlands Groups）是一个国际金融服务私营企业，成立于1991年，由荷兰最大的保险公司Nationale-Nederlanden，与荷兰的第三大银行NMB PostBank Group合并而成。ING集团的服务遍及全球40多个国家，核心业务是银行、保险及资产管理等。ING集团的全球职员大约56,000人，顾客5320万人，包括自然人、家庭，企业、政府及其他等，例如基金组织。在银行行业有许多法规和限制，ING布局符合自身产业的DAP平台（Data Analytics Platform），为全球50%的ING员工提供安全的、自助的端到端分析能力，帮助员工在数据平台之上构建并解决业务问题。在本次以Volcano为案例的演讲中，ING 重点指出Volcano对批处理任务调度做了很好的抽象，使其在Kubernetes平台能够获得更高的调度性能，后面ING也会将开发的功能逐步回合社区，比如：DRF Dashboard、在每个节点添加空闲空间、自动队列管理、更多的Prometheus监控指标、Grafana仪表盘更新、kube-state-metrics更新和集群角色限制等。Volcano 2019年由华为云捐献给云原生计算基金会（CNCF），也是 CNCF 首个和唯一的容器批量计算项目，帮助用户将 AI、大数据、HPC等计算密集型的业务从传统的系统快速迁移到云原生平台，加速整个云原生落地的进程。Kurator v0.2.0 发布！助力企业分布式云原生应用升级Kurator是华为云开源的分布式云原生平台，帮助用户构建属于自己的分布式云原生基础设施，助力企业数字化转型。Kurator v0.1 版本通过一键集成 Karmada，Volcano，Istio，Prometheus 等主流开源项目，提供了分布式云原生的统一多集群管理，统一的调度，统一的流量治理以及统一的应用监控能力。在最新发布的 v0.2.0 中，Kurator 新增两大类关键特性，增强了可观测性并新增了集群生命周期管理，具体包括以下重大更新。• 基于Thanos的多集群监控及指标持久化存储• 基于Pixie实时的K8s应用监控• 支持本地数据中心集群生命周期管理• 支持AWS云上自建集群生命周期管理Kurator由此开始提供分布式云原生基础设施的管理。这意味着，从此Kurator可以依托基础设施、Kubernetes集群，更好的管理各种云原生中间件，为用户提供开箱即用的分布式云原生能力。Kurator，一键构建分布式云原Kurator于2022年6月在华为伙伴暨开发者大会上开源，是业界首个开源分布式云原生平台。通过集成业界主流开源技术栈以及良好云原生舰队管理性能，Kurator为用户提供一站式、开箱即用的分布式云原生能力，打造分布式云原生技术底座,助力企业业务跨云跨边、分布式化升级。Istio宣布2023年指导委员会席位，华为占两席2月6日，Istio社区宣布2023年指导委员会（Steering Committee）席位。Istio 指导委员会[1]，由 9 个贡献席位（根据企业对项目的贡献按比例分配）和 4 个选举产生的社区席位组成。每年 2 月，社区都会根据年度商定的指标[4]，查看哪些公司对 Istio 的贡献最大并进行公布。华为云已连续三年获得Istio委员会席位(Steering Committee成员2名,全球仅8家公司13人）；Maintainer 2名，Member 10+名。过去几年，华为云Pull Request 位于全球TOP 3，Contributions TOP 3(1.9w+）。由华为云技术团队撰写并出版的《云原生服务网络Istio：原理、实践、架构与源码解析》一书，是业内最有影响力的服务网络书籍之一。目前，华为云应用服务网格（ASM）也已服务于互联网、汽车、制造、物流、政府等多个行业的近千家客户，满足不同行业客户的业务诉求。华为云将在此过程中积累的丰富经验，转化为代码贡献给Istio社区，极大地推动了Istio技术的成熟和社区的快速发展。同时，华为云还大力投入服务网格的技术布道，通过社区论坛、技术会议、视频直播、专业书籍等各种方式，推动服务网格技术传播和普及。添加小助手微信k8s2222，进入云原生交流群