Abstract: The design and implementation of the KubeEdge device management architecture can effectively help users deal with the scenarios encountered in the process of device digital twinning.
This article is shared from Huawei Cloud Community " KubeEdge: Design and Implementation of the Next Generation Cloud Native Edge Device Management Standard DMI ".
With the mature development of technologies such as 5G, AI, and distributed cloud, concepts such as the Internet of Everything, digital twins, and ubiquitous computing power have continued to advance, bringing about innovations in many industries and businesses, and more and more devices and applications are running on the terminal. side and generate a lot of data. How to better decouple business application development and device data access, provide complete lifecycle data management for devices, and release the value of device data? How to efficiently manage and transmit device data while ensuring cluster availability, and obtain a more convenient and flexible data access method? The choice of cloud-native edge computing solutions can help users better deal with such problems.
1. KubeEdge device management framework
The design and implementation of the KubeEdge device management architecture can effectively help users deal with the scenarios encountered in the process of device digital twinning. Users can abstract physical devices into digital twins through KubeEdge, and manage devices and data in a cloud-native manner.
Figure 1 KubeEdge device management architecture design
The KubeEdge device management architecture design is shown in Figure 1, and the specific process is as follows:
- The user calls the Kubernetes API interface to create a Device CRD instance to KubeEdge
- CloudCore, the component on the KubeEdge cloud, watches the Creation message of the Device CRD instance in Kubernetes
- At this time, CloudCore will do two things. On the one hand, CloudCore sends Device Twin information to EdgeCore through the cloud-side websocket channel. On the other hand, CloudCore will generate a Configmap containing Device Profile information. Loaded into the Pod corresponding to Mapper
- Mapper updates the locally maintained Device list by reading the Device Profile information in the mounted Configmap
- EdgeCore sends the received Device Twin information to the specified mqtt topic
- All Mappers on the node will receive the Device Twin message, and match the Device in the list they maintain according to the Device name.
- Mapper establishes a connection with the device through the corresponding protocol according to the Device Profile information
- Mapper reports device status and collected data Device Twin to EdgeCore through mqtt topic
- EdgeCore reports Device Twin data to CloudCore through the cloud-edge websocket channel
- CloudCore updates Device Twin data to Kubernetes
2. DMI frame design
On this basis, the KubeEdge team also continuously updates and iterates on the framework. In order to help users cope with larger-scale device scenarios, higher availability requirements, more flexible function support, and better user experience in the future, KubeEdge has designed a more optimized device management framework - DMI .
DMI integrates device management interfaces, optimizes device management capabilities in edge computing scenarios, and builds a cloud-native technology-based device digital twin management platform that covers device management and device data; at the same time, it defines a unified connection entry between EdgeCore and Mapper, and The server and client for upstream and downstream data streams are implemented by EdgeCore and Mapper respectively, and carry the specific functions of DMI.
The DMI framework design decouples the data of the device management plane and the device business plane, so that the Device CRD only carries the life cycle management of the device itself, while the device business plane data is directly provided to the data consumer application through microservices. Under such an architecture, the device is no longer a simple data source, but a cloud-native device micro-service. Developers of device data consumption applications can no longer care about how to obtain device data, but instead use a more cloud-native device. way to focus on the business logic development of the application itself. The DMI framework also provides a variety of data push methods, so that data consumers can obtain device data more flexibly, and the user experience is better.
Due to the separation of device management plane and business plane data of DMI, business plane data can be processed more flexibly in the cloud or on the edge through the business plane channel, while only a small amount of management plane information is transmitted in the cloud side channel of the management plane, which greatly increases the It reduces the possibility of cloud side channel congestion and improves the availability of the KubeEdge system. In addition, DMI provides a unified interface related to device management. Both device application developers and device application users can carry out device-related work in a more unified, flexible, and standardized way, regardless of specific forms. As long as the DMI interface can be implemented, you can enjoy the cloud-native device management experience brought by the KubeEdge edge computing platform.
▍2.1 DMI frame positioning
Figure 2 The positioning of DMI in the KubeEdge architecture
The positioning of DMI in the KubeEdge architecture is shown in Figure 2. Similar to Kubernetes' CNI, CSI, CRI and other interfaces, DMI defines a set of internal API interfaces between EdgeCore and Mapper and a unified API interface for external applications to access Mapper. The bottom layer of the internal interface is implemented by gRPC combined with UDS, and the external API interface supports two access methods: mqtt and REST. Regardless of the bearer and implementation method of Mapper, as long as the uplink and downlink data interfaces defined in DMI are implemented, it can be connected to the KubeEdge cloud-native edge computing platform, and the device can be managed in a cloud-native manner.
▍2.2 DMI device management and data management
The DMI framework design is shown in Figure 3, where the yellow line is the data flow management of the device management plane, and the blue part is the data flow management of the service plane.
In the architecture design of DMI, the management plane data of the device is separated from the service plane data. The management plane data mainly includes device metadata, device attributes, configuration, status, life cycle, etc. It is characterized by relatively stable, less updated information after creation, except for status reporting, which is closer to the data generated by Pod-type resources , while ensuring that users can maintain the life cycle of the Device like accessing the Pod through the cloud Kubernetes API, while minimizing the additional data transmission overhead caused by device management.
Figure 3 DMI device management and data management architecture
Under the design of the DMI framework, devices are no longer a pure data source, but are abstracted into microservices to provide data services for device data consumers in a cloud-native manner. Device data access under the DMI framework supports multiple scenarios and is more flexible. Several main data access methods are listed in Figure 3, including push data and pull data, etc. The details are as follows:
- Edge-side applications access device data through REST Service
- Cloud-side applications access device data through REST Service
- Mapper pushes data to edge applications by configuring the REST destination address
- Mapper pushes data to cloud-side applications by configuring the REST destination address
- Mapper pushes data to the edge database by configuring the destination address
- Mapper pushes data to mqtt broker by configuring the destination address
- Edge-side applications subscribe to device data through mqtt broker topic
- Cloud-side applications subscribe device data through mqtt broker topic
- The edge-side application processes the data and uploads the processing results to the cloud
▍2.3 DMI workflow
Figure 4 Example of DMI Device Management Workflow
Under the DMI framework, there are certain changes in the process of device management. As shown in Figure 4, when KubeEdge is installed, CloudCore will register the DeviceController component to monitor the CRD resources of Device and DeviceModel. There are two modules in DeviceController, Downstream Controller and Upstream Controller. Downstream Controller is used to monitor Device and DeviceModel events in the cloud and send them to the edge through Cloudhub. Upstream Controller is used to receive the Device status and report from EdgeHub forwarded from Cloudhub. message, and update the Device state in Kubernetes. On the edge side, when the Mapper is initialized, it needs to call the Mapper registration interface in the DMI, register the relevant information of the Mapper to the Device Manager, and receive the device information that has been delivered to the node and matches the protocol returned by the interface. When EdgeHub receives a device message from the cloud, it will forward it to the DeviceManager component. DeviceManager will select the corresponding Mapper driver according to the device's protocol, send a request to create a device, and the local database will also store the device's information. , the subsequent Mapper will convert the device twin message into the device protocol format and communicate with the actual physical device.
Three, DMI interface definition
▍3.1 DMI interface classification
The DMI interface realizes the communication between EdgeCore and Mapper, supports the communication mode of REST and mqtt, and presents it in a standardized form, which reduces the difficulty of Mapper development and adaptation. In terms of data access, DMI enables both edge and cloud applications to access device data through REST Service.
Figure 5 DMI interface definition
As shown in Figure 5, DMI has six types of interfaces. Mapper management is for various device protocol drivers on the edge side. Device management and Device data management split the data on the management plane and service plane. Device upgrade management and Device command management Provide relevant interfaces for devices with upgrade and command execution functions, and Device Event Management can monitor the running status of Mapper and its managed devices.
▍3.2 DMI interface definition example
Figure 6 DMI device management part interface definition example
As shown in Figure 6, it defines some interfaces for DMI device management. The v1 version is defined in the form of gRPC proto. You can use the make dmi command to create the corresponding gRPC-go code.
▍3.3 Definition of CRD related to DMI device
As shown in Figure 7, it is the definition of CRD related to DMI device, which is mainly divided into Device and DeviceModel. Among them, DeviceModel and device model are in a one-to-one correspondence, representing the common properties of the same type of device model, mainly including device-generated data properties and device-supported command properties Commands. Device is a device instance, which has a one-to-one relationship with a real physical device. Each DeviceModel can correspond to multiple Device instances of the same model. Device type resources mainly include device model correspondence information, device protocol configuration information, device deployment node information, device status information, and device data Property collection configuration information.
Figure 7 Definition of CRD related to DMI device
4. Release plan
The DMI release plan is divided into three versions. The Alpha version provides the implementation of device management related functions, and provides a Mapper Demo that supports the DMI interface. The Beta version supports device command management, device upgrade management, and device data management capabilities. In addition, it will connect to third-party platforms and provide related docking demos. The GA version will support multi-platform and multi-protocol docking, and will complete the functions of device security and event management.
Figure 8 DMI release plan
Currently KubeEdge Device IoT SIG is focusing on the first phase of device management and the development of Mapper Demo. You are welcome to contact us through the contact information below, and participate in the work of program design and feature development together.
Author of this article: Huawei Cloud Zhao Ran; DaoCloud Taoist Wang Zilong
Attachment: KubeEdge community contribution and technical exchange address
Website: https://kubeedge.ioGithub
Address: https://github.com/kubeedge/kubeedgeSlack
Address: https://kubeedge.slack.com
Mailing list: https://groups.google.com/forum/#!forum/kubeedge
Weekly community meeting: https://zoom.us/j/4167237304
Twitter: https://twitter.com/KubeEdge
Documentation address: https://docs.kubeedge.io/en/latest/
Click Follow to learn about HUAWEI CLOUD's new technologies for the first time~