KubeEdge：下一代云原生边缘设备管理标准DMI的设计与实现
优质资源分享
| 学习路线指引（点击解锁） | 知识定位 | 人群定位 |
|---|---|---|
| Python实战微信订餐小程序 | 进阶级 | 本课程是python flask+微信小程序的完美结合，从项目搭建到腾讯云部署上线，打造一个全栈订餐系统。 |
| Python量化交易实战 | 入门级 | 手把手带你打造一个易扩展、更安全、效率更高的量化交易系统 |
**摘要：**KubeEdge设备管理架构的设计实现，有效帮助用户处理设备数字孪生进程中遇到的场景。
本文分享自华为云社区《KubeEdge：下一代云原生边缘设备管理标准DMI的设计与实现》。
随着5G、AI、分布式云等技术的成熟发展，万物互联、数字孪生、算力泛在等理念不断推进，带来了很多行业业务的创新，越来越多的设备、应用运行在端侧，并产生大量的数据。如何更好地解耦业务应用开发和设备数据访问，为设备提供完整的生命周期数据管理，释放设备数据的价值？如何在保证集群可用性的同时，高效管理和传输设备数据，获得更为方便、灵活的数据访问方式？云原生边缘计算的方案选择可以帮助用户更好地应对这类问题。
一、KubeEdge设备管理框架
KubeEdge设备管理架构的设计实现，有效帮助用户处理设备数字孪生进程中遇到的场景。用户可以通过KubeEdge，将物理设备抽象成数字孪生，用云原生的方式对设备和数据进行管理。
图 1 KubeEdge设备管理架构设计
KubeEdge设备管理架构设计如图1所示，具体流程如下：
- 用户调用Kubernetes API接口，创建Device CRD实例到KubeEdge
- KubeEdge云上组件CloudCore watch到Kubernetes中Device CRD实例创建消息
- 此时CloudCore会做两件事情，一方面CloudCore通过云边websocket通道下发Device Twin信息到EdgeCore，另一方面CloudCore会生成一份包含Device Profile信息的Configmap，该Configmap是以Node名称为索引，挂载到对应Mapper的Pod中的
- Mapper通过读取挂载的Configmap中的Device Profile信息，更新本地维护的Device list列表
- EdgeCore把接收到的Device Twin信息发送到指定的mqtt topic
- 该节点上的所有Mapper都会收到该Device Twin消息，并根据Device名称来匹配是否是自己维护的list中的Device
- Mapper根据Device Profile信息，通过对应的协议与设备建立连接
- Mapper通过mqtt topic上报设备状态和采集的数据Device Twin到EdgeCore
- EdgeCore通过云边websocket通道上报Device Twin数据到CloudCore
- CloudCore更新设备Device Twin数据到Kubernetes
二、DMI框架设计
**在此基础上，KubeEdge团队也对框架不断更新迭代。**为帮助用户应对未来更大规模设备场景、更高的可用性需求、更灵活的功能支持以及更优的用户体验，KubeEdge 设计了更优化的设备管理框架——DMI。
DMI整合设备管理接口，优化边缘计算场景下的设备管理能力，打造基于云原生技术的，覆盖设备管理、设备数据的设备数字孪生管理平台；同时定义了EdgeCore与Mapper之间统一的连接入口，并分别由EdgeCore和Mapper实现上行数据流和下行数据流的服务端和客户端，承载DMI具体功能。
DMI框架设计中解耦了设备管理面与设备业务面数据，让Device CRD只承载设备本身的生命周期管理，而设备业务面数据则直接通过微服务的方式为数据消费者应用提供出来。在这样的架构下，设备就不再是单纯的数据源，而是一种云原生的设备微服务，设备数据消费应用的开发者就可以不再关心如何获取设备数据，而是以更云原生的方式来聚焦应用本身的业务逻辑开发。DMI框架还提供多种数据推送方式，让数据消费者可以更灵活地获取设备数据，用户体验更优。
由于DMI的设备管理面与业务面数据分离的特点，业务面数据可以通过业务面通道更灵活地在云端或边端被处理，而管理面的云边通道中只会传输少量管理面信息，大大降低了云边通道拥塞的可能，提高了KubeEdge系统的可用性。另外，DMI提供了统一的设备管理相关接口，无论是设备应用开发者还是设备应用的使用者，都可以以更统一、更灵活、更标准化的方式来开展设备相关工作，不拘泥于具体形式，只要能够实现DMI接口，就能够享受KubeEdge边缘计算平台带来的云原生设备管理体验。
▍2.1 DMI框架定位
图 2 DMI 在 KubeEdge 架构中的定位
DMI在KubeEdge架构中的定位如图2所示。DMI类似Kubernetes的CNI、CSI、CRI等接口，定义了一组EdgeCore与Mapper之间的内部API接口以及外部应用访问Mapper的统一的API接口。其中内部接口底层由gRPC结合UDS的方式来实现，外部API接口支持mqtt和REST两种接入方式。Mapper不论是何种承载、实现方式，只要实现了DMI中所定义的上行、下行数据接口，即可接入KubeEdge云原生边缘计算平台，使用云原生的方式对设备进行管理。
▍2.2 DMI设备管理与数据管理
DMI框架架构设计如图3所示，其中黄色线条为设备管理面数据流管理，蓝色部分为业务面数据流管理。
在DMI的架构设计中，将设备的管理面数据与业务面数据进行分离。其中管理面数据主要包括设备的元数据、设备属性、配置、状态、生命周期等，其特点是相对比较稳定，创建后除状态上报外的信息更新较少，更贴近Pod类型资源所产生的数据，在保证用户可以通过云端Kubernetes API像访问Pod一样维护Device的生命周期的同时，尽量减少设备管理产生的额外数据传输开销。
图 3 DMI设备管理与数据管理架构
在DMI框架设计下，设备不再是单纯的数据源，而是被抽象为微服务，以云原生的方式为设备数据消费者提供数据服务。DMI框架下的设备数据访问支持多种场景，更加灵活。图3中列出了几种主要的数据访问方式，包括推数据和拉数据等，具体情况如下：
- 边缘侧应用通过REST Service访问设备数据
- 云侧应用通过REST Service访问设备数据
- Mapper通过配置REST目的地址，将数据推送到边缘侧应用
- Mapper通过配置REST目的地址，将数据推送到云侧应用
- Mapper通过配置目的地址，将数据推送到边缘侧数据库
- Mapper通过配置目的地址，将数据推送到mqtt broker
- 边缘侧应用通过mqtt broker topic订阅设备数据
- 云侧应用通过mqtt broker topic 订阅设备数据
- 边缘侧应用处理数据后将处理结果传上云
▍2.3 DMI工作流程
图 4 DMI设备管理工作流程示例
在DMI框架下，设备管理工作的流程有一定的变化。如图4所示，在安装KubeEdge的时候，云端CloudCore会注册DeviceController组件用于监听Device和DeviceModel的CRD资源。DeviceController中存在两个模块，Downstream Controller和Upstream Controller，其中Downstream Controller用于监听云端的Device、DeviceModel事件，并通过Cloudhub下发至边缘，Upstream Controller用于接收从Cloudhub转发来的EdgeHub上报的Device状态和消息，并更新Kubernetes中的Device状态。在边缘侧，Mapper初始化的时候，需要调用DMI中的Mapper注册接口，将Mapper的相关信息注册至Device Manager，并接收接口返回的已下发至该节点的且协议匹配的设备信息。EdgeHub在接收到云端下发的设备消息时，会将其转发到DeviceManager组件，DeviceManager会根据该设备的协议选择对应的Mapper驱动程序，发送创建设备的请求，并且本地数据库也会存储该设备的信息，后续Mapper会将设备孪生消息转化为设备协议格式，跟实际的物理设备进行通信。
三、DMI接口定义
▍3.1 DMI 接口分类
DMI接口实现了EdgeCore与Mapper之间的通信，支持REST和mqtt的通信方式，并以标准化的形式呈现，降低了Mapper开发、适配难度。在数据访问方面，DMI可以实现边缘侧和云侧的应用都可以通过REST Service的方式访问设备数据。
图 5 DMI接口定义
如图5所示，DMI有六类接口，Mapper管理是针对边缘侧各类设备协议驱动程序，Device管理和Device数据管理对管理面和业务面进行了数据拆分，Device升级管理和Device命令管理为具有升级和命令执行功能的设备提供相关的接口，Device事件管理可以监控Mapper及其纳管的各个设备的运行状态。
▍3.2 DMI 接口定义示例
图 6 DMI设备管理部分接口定义示例
如图6所示，为DMI设备管理部分接口定义，v1版本以gRPC proto的方式定义，可使用make dmi命令创建对应的gRPC-go代码。
▍3.3 DMI 设备相关 CRD 定义
如图7所示，是DMI设备相关CRD定义，主要分为Device和DeviceModel。其中DeviceModel与设备型号是一一对应的关系，代表同一类设备型号的共有属性，主要包含设备产生数据属性Properties和设备支持命令属性Commands。Device为设备实例，与真实的物理设备为一对一的关系，每个DeviceModel可以对应统一型号的多个Device实例。Device类型资源主要包含设备型号对应关系信息、设备协议配置信息、设备部署节点信息、设备状态信息以及设备数据Property采集配置信息。
图 7 DMI 设备相关 CRD 定义
四、发布计划
DMI发布计划分为三个版本，Alpha版本提供设备管理相关功能实现，以及提供一个支持DMI接口的Mapper Demo。Beta版本支持设备命令管理、设备升级管理以及设备数据管理的能力，此外还会对接第三方平台，并提供相关对接Demo。GA版本会对多平台、多协议进行对接支持，另外会把设备安全以及事件管理的功能补全。
图 8 DMI发布计划
目前 KubeEdge Device IoT SIG 专注于第一阶段的设备管理和 Mapper Demo 的开发工作。欢迎大家通过下方联系方式联系我们，一起参与到方案设计和特性开发的工作当中。
本文作者：华为云 赵然 ；DaoCloud 道客 王梓龙
附：KubeEdge社区贡献和技术交流地址
网站: https://kubeedge.ioGithub
地址: https://github.com/kubeedge/kubeedgeSlack
地址: https://kubeedge.slack.com
邮件列表: https://groups.google.com/forum/#!forum/kubeedge
每周社区例会: https://zoom.us/j/4167237304
Twitter: https://twitter.com/KubeEdge
文档地址: https://docs.kubeedge.io/en/latest/
点击关注，第一时间了解华为云新鲜技术~