On September 29, 2022, Beijing time, KubeEdge released version 1.12 . The new version adds a number of enhancements, which have greatly improved scalability, stability, and security . In this major upgrade of the entire KubeEdge architecture, the DMI device management function proposed by "DaoCloud Daoke" last year and has been deeply involved in research and development has received very high expectations and evaluations from the community.
01
KubeEdge v1.12
Release Notes
New Edge Device Management Interface DMI (Alpha)
The DMI interface enables KubeEdge's IoT device management in a cloud-native manner, and its functions cover device lifecycle management, device operation, and device data management.
Device Lifecycle Management: Simplify operations and make IoT device lifecycle management as easy as managing a Pod.
Device operation: Provides the ability to operate devices through the Kubernetes API.
Device data management: Separated from device management, data can be used by local applications or synchronized to the cloud through a special tunnel.
Through the DMI interface, developers only need to implement the Mapper of the corresponding protocol according to the DMI interface standard, and execute the corresponding API operations on the cloud to connect the device to KubeEdge and enjoy the cloud-native devices brought by the KubeEdge edge computing platform Manage experience.
The next generation of Edge is officially released: suitable for more scenarios
The Edged module is a lightweight container application engine on the edge side, which is used to realize the lifecycle management of edge Pod applications, as well as the ability to collect and report Node status. In order to ensure the light weight of the edge, the new version of Edged has been optimized and tailored in the native Kubelet, and has kept the commit history. The new Edged will still communicate with the cloud through a reliable transmission tunnel.
Introducing High Availability Mode for EdgeMesh
Compared with the previous centralized relay mode, EdgeMesh HA mode can set multiple relay nodes. When some relay nodes fail, other relay nodes can continue to provide relay services, avoiding a single point of failure and greatly improving the stability of the system.
In addition, if the relay node is too far away, it will cause high latency. The HA relay node capability can provide intermediate nodes and shorten the delay. mDNS enables nodes within a local area network to communicate with each other without connecting to an external network.
Support for upgrading edge nodes from the cloud (Alpha)
The NodeUpgradeJob v1alpha1 API has been added in version 1.12 to upgrade edge nodes from the cloud. Using the NodeUpgradeJob API and Controller, users can:
-
Upgrade selected edge nodes from the cloud using the NodeUpgradeJob API ;
-
If the upgrade fails, roll back to the original version.
Support side-end Kube-API authorization (Alpha)
On the edge side, the EdgeCore component provides edge-native interface capabilities externally through the MetaServer module. In order to consolidate and strengthen the security of the edge side, when users use the edge native interface to access the native K8s API, user requests need to be authenticated and authenticated.
The new version of MetaServer can start and provide services through HTTPS. User requests need to be authenticated by Token. Unauthenticated or authenticated requests will not be accessible. For security reasons, the Token authentication method in the current version requires edge nodes to remain online, and authentication requests in offline scenarios will be rejected by default.
New GigE Mapper
Provides a GigE device mapper with Golang implementation for accessing GigE Vision protocol cameras.
02
Edge device management
Device Management Interface
The design of KubeEdge for device management is very lightweight. The related control components include the Device Controller component in the "Cloud Core" and the Device Twin component in the "Edge Core". Edge device management effectively solves problems such as data collection, data cleaning, data migration to the cloud, and data security. However, in actual usage scenarios, it still has some content to be optimized and improved:
1. Coupling of device management plane data and business plane
-
There are performance problems in large-scale scenarios
-
Occupy the ws cloud edge channel
-
Etcd read and write performance bottleneck
2. Insufficient ability to manage device configuration information
-
Device information is sent to mapper through configmap
-
Configmap and CRD have information redundancy
-
There is information redundancy in Mapper's processing of mqtt messages
3. The device interface is not perfect
-
The access method of Mapper is only mqtt
-
Device interfaces are not uniform, and access adaptation is difficult
-
Data handling is inflexible
In order to solve and avoid the above-mentioned problems, at last year's Cloud Native Edge Computing Forum, "DaoCloud Daoke" put forward a proposal to integrate & reconstruct the device management interface , and at the same time gave a reference architecture, and implemented it in the next function In-depth participation in discussions and research and development. In the end, "DaoCloud Daoke" and the community proposed a new device management mode, Device Management Interface (DMI for short) , which is used to integrate device management interfaces, optimize device management capabilities in edge computing scenarios, and create cloud-native technology-based, covering Device management, device data device digital twin management platform; at the same time, a unified connection entry between EdgeCore and Mapper is defined, and EdgeCore and Mapper respectively realize the server and client of the upstream data flow and downstream data flow, and carry the specific functions of DMI .
It mainly includes the following features:
Cloud-native: As a K8s resource, device generates a virtualized digital twin, which can be simulated based on K8s.
Device management: manage the life cycle of devices like managing pods, and simplify operations for users.
Equipment operation: There are two entrances for equipment operation. K8s (man-machine, machine-machine) and equipment interaction control capabilities are also provided for deployment.
Device data: The deployment on the edge side can obtain the corresponding data, and the device data is uploaded to the cloud in some cases.
Architecture diagram:
The positioning of DMI in the KubeEdge architecture is shown in the figure. DMI is similar to Kubernetes' CNI, CSI, CRI and other interfaces, and 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 combining gRPC with UDS, and the external API interface supports two access methods: mqtt and REST.
No matter what kind of bearer and implementation method Mapper uses, as long as it implements the uplink and downlink data interfaces defined in DMI, it can be connected to the KubeEdge cloud-native edge computing platform and manage devices in a cloud-native way.
Contribution and participation of "DaoCloud Taoke"
In this release, "DaoCloud Taoke" has contributed the Mapper management and Device management modules of the DMI Alpha version and the corresponding Mapper Demo . The specific functions are as follows:
-
Implemented the DeviceManager interface in DMI to complete the addition, deletion and modification of devices;
-
Taking the Modbus device protocol as an example, a complete Mappers Demo is implemented;
-
Replace the original mqtt component and use gRPC to communicate with Kubeedge;
-
The Go version of Mappers is upgraded to 1.17 and compatible with Kubeedge v1.12;
-
Adjust the Mappers project structure and continue to optimize it, which provides good support for the subsequent development of Mappers.
The Alpha version mainly includes the following contents:
1. The management plane data is separated from the business plane data.
-
The management plane data is stored in KubeEdge's ETCD with few changes.
2. Management data include:
-
metadata
-
Attributes
-
configuration
-
state
-
life cycle
3. Device information management:
-
Cache in KubeEdge sqlite;
-
Specify Mapper through node+protocol;
-
Initialize through the return value of the Mapper registration interface;
-
Send it to Mapper by adding or deleting device interfaces.
4. Mapper implements the REST access method through grpc+UDS.
Next, we will continue to participate in the development of the Beta version, and cooperate with the community in the in-depth development of the Device data management module.
Join the KubeEdge community
KubeEdge is the industry's first cloud-native edge computing framework and the only incubation-level edge computing open source project within the Cloud Native Computing Foundation. applications), the industry's first cloud-native satellite-ground collaborative satellite, the industry's first cloud-native vehicle-cloud collaborative vehicle, the industry's first cloud-native oilfield project, the industry's first open-source distributed collaborative AI framework Sedna, and the industry's first edge-cloud collaborative lifelong learning Paradigm, and in the continuous development and innovation.
KubeEdge website:
https://kubeedge.io
GitHub address:
https://github.com/kubeedge/kubeedge
Slack address:
https://kubeedge.slack.com
Mailing Lists :
https://groups.google.com/forum/#!forum/kubeedge
Weekly community meeting:
https://zoom.us/j/4167237304
Twitter :
https://twitter.com/KubeEdge
Document address:
https://docs.kubeedge.io/en/latest/
author of this article
Liu Chenlin
Current "DaoCloud Daoke" DEC backend R&D engineer
KubeEdge Member
References: