KubeEdge：下一代云原生边缘设备管理标准 DMI 的设计与实现

本文分享自华为云社区《KubeEdge：下一代云原生边缘设备管理标准DMI的设计与实现》，作者：云容器大未来 。

随着 5G、AI、分布式云等技术的成熟发展，万物互联、数字孪生、算力泛在等理念不断推进，带来了很多行业业务的创新，越来越多的设备、应用运行在端侧，并产生大量的数据。如何更好地解耦业务应用开发和设备数据访问，为设备提供完整的生命周期数据管理，释放设备数据的价值？如何在保证集群可用性的同时，高效管理和传输设备数据，获得更为方便、灵活的数据访问方式？云原生边缘计算的方案选择可以帮助用户更好地应对这类问题。

一、KubeEdge 设备管理框架

KubeEdge 设备管理架构的设计实现，有效帮助用户处理设备数字孪生进程中遇到的场景。用户可以通过 KubeEdge，将物理设备抽象成数字孪生，用云原生的方式对设备和数据进行管理。

图 1 KubeEdge 设备管理架构设计

KubeEdge 设备管理架构设计如图 1 所示，具体流程如下：

1. 用户调用 Kubernetes API 接口，创建 Device CRD 实例到 KubeEdge

2. KubeEdge 云上组件 CloudCore watch 到 Kubernetes 中 Device CRD 实例创建消息

3. 此时 CloudCore 会做两件事情，一方面 CloudCore 通过云边 websocket 通道下发 Device Twin 信息到 EdgeCore，另一方面 CloudCore 会生成一份包含 Device Profile 信息的 Configmap，该 Configmap 是以 Node 名称为索引，挂载到对应 Mapper 的 Pod 中的

4. Mapper 通过读取挂载的 Configmap 中的 Device Profile 信息，更新本地维护的 Device list 列表

5. EdgeCore 把接收到的 Device Twin 信息发送到指定的 mqtt topic

6. 该节点上的所有 Mapper 都会收到该 Device Twin 消息，并根据 Device 名称来匹配是否是自己维护的 list 中的 Device

7. Mapper 根据 Device Profile 信息，通过对应的协议与设备建立连接

8. Mapper 通过 mqtt topic 上报设备状态和采集的数据 Device Twin 到 EdgeCore

9. EdgeCore 通过云边 websocket 通道上报 Device Twin 数据到 CloudCore

10. 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 中列出了几种主要的数据访问方式，包括推数据和拉数据等，具体情况如下：

1. 边缘侧应用通过 REST Service 访问设备数据

2. 云侧应用通过 REST Service 访问设备数据

3. Mapper 通过配置 REST 目的地址，将数据推送到边缘侧应用

4. Mapper 通过配置 REST 目的地址，将数据推送到云侧应用

5. Mapper 通过配置目的地址，将数据推送到边缘侧数据库

6. Mapper 通过配置目的地址，将数据推送到 mqtt broker

7. 边缘侧应用通过 mqtt broker topic 订阅设备数据

8. 云侧应用通过 mqtt broker topic 订阅设备数据

9. 边缘侧应用处理数据后将处理结果传上云

▍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 的开发工作。欢迎大家通过下方联系方式联系我们，一起参与到方案设计和特性开发的工作当中。

本文作者：KubeEdge 社区 Maintainers：赵然 王梓龙

附：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/

点击关注，第一时间了解华为云新鲜技术~