KubeEdge is an open source system that extends native containerized orchestration and device management to hosts on the Edge. It is built on Kubernetes and provides core infrastructure support for networking, application deployment, and metadata synchronization between cloud and edge. It also supports MQTT and allows developers to write custom logic and enable resource-constrained device communication on Edge. KubeEdge consists of a cloud part and an edge part, and the edge and cloud parts are now open source.
1. Introduction to the basic principles of KubeEdge
1.1 Overview of KubeEdge architecture
The KubeEdge architecture is mainly divided into three parts: cloud, edge, and end. The cloud is mainly the control plane of KubeEdge, the edge is the edge node of KubeEdge, and the end is the end-side device connected to the edge node, such as cameras and sensors. The K8s control plane is connected to the cloud. CloudCore, the cloud component of KubeEdge, mainly obtains some cloud data on the K8s control plane.
Then do some processing through DeviceController, and then communicate with the side end through the PubHub below. EdgeCore at the edge will receive the data from PubHub, and take down the control instructions and user data on the cloud. In addition, EdgeCore mainly manages edge applications and devices. The application management capability is connected to the container engine based on the CNI standard. For example, container d and docker are used to manage the life cycle of containers. The device management capability mainly implements multi-device access management through the mapper component.
KubeEdge also introduces the EdgeMesh plug-in to provide mutual access to services between edge nodes.
1.2 CloudCore component introduction
EdgeController and List/watch in CloudCore components, K8s metadata manage edge nodes and edge collaboration of application status metadata. Device Controller defines the device abstraction API, such as the CRD of Device. Responsible for accessing and managing edge devices. The Sync Controller is mainly responsible for the reliability of the edge collaboration at the application layer, and keeps the cloud-side data consistent. CSI Driver is used to support the seamless integration of third-party CSI plug-ins. Admission Webhook is mainly used to implement best practices for edge applications and to extend API input validation. CloudHub is used for edge-cloud data channels and is responsible for distributing and receiving messages.
1.3 Introduction to edgecore components
The CloudHub module in the CloudCore component establishes a data channel with the edge node. In fact, it establishes a two-way connection with the EdgeHub module. It will be responsible for providing reliable two-way connection synchronization. The data channel between CloudHub and EdgeHub is a Websocket layer connection, which ensures An intranet penetration of the cloud edge, the connection between the cloud edge can also choose kata as the protocol of the data channel. In a weak network environment, there will be better QOS. MetaManager is the localization module of EdgeCore metadata, which is used to save the data on the cloud locally for use by other modules. For example, KubeEdge's offline autonomy capability can use MetaManager's ability. MetaServer is a submodule of MetaManager. It is a new function introduced by KubeEdge in version 1.7. It can provide native API access introduced by K8s at the edge. Yes, K8s Operator can run on edge nodes without distinction. The Edged module mainly refers to the Kubelet-Lite of the upstream K8s, and has made lightweight customizations. Users can also customize different scenarios according to their own needs. The main responsibility of Edged is to interface with the container engine based on the CNI standard. EventBus is essentially an MQTT client, which defines a series of device messages for non-aware communication with edge devices.
1.4 EdgeMesh Plugin Introduction
EdgeMesh is a solution for KubeEdge's multilateral intercommunication at the edge of the network in edge scenarios. EdgeMesh is part of the KubeEdge architecture. EdgeMesh is divided into two components: EdqeMesh-Server and EdgeMesh-Agent. EdqeMesh-Server is a coordinator and also assumes the role of a data repeater. EdgeMesh-Agent is deployed in
K8s nodes and edge nodes are responsible for data transmission on proxy applications. The Tunnel-Server module of EdgeMesh is mainly responsible for establishing a connection with Tunnel-Agent, assisting P2P hole punching and providing relay capabilities for EdgeMesh-Agent. EdgeMesh-Agent contains the Proxier module, which is responsible for configuring the iptables rules of the kernel and intercepting requests into the EdgeMesh-Agent process. The DNS module is a built-in DNS resolver, which is responsible for resolving the domain name request in the node into a service cluster IP. The Traffic module is a traffic forwarding module based on the Go-Chassis framework, responsible for forwarding traffic between applications. The Controller module obtains metadata such as Services, Endpoints, and Pods through the capabilities of KubeEdge's edge-side MetaServer. The Tunnel-Agent module uses relay and hole-punching technologies to provide cross-subnet communication capabilities.
After the EdgeMesh plug-in is deployed to the KubeEdge cluster, a Peer connection will be established between Agents, and metadata changes will be monitored through the Edge List/watch. The proxier module will be responsible for configuring the host's iptables interception rules to intercept application traffic. When the application of the node accesses the application using Cluster IP or service domain name, the DNS module of EdgeMesh-Agent will be responsible for resolving the domain name to Cluster IP, and EdgeMesh-Agent will then load balance the back-end instances according to the rules. This is the general working principle of EdgeMesh-Agent.
2. KubeEdge environment construction and application
The chapter of KubeEdge environment construction and application mainly introduces the creation of K8s cluster by using Huawei Cloud CCE service, the construction of KubeEdge environment by using OSC, and the development of edge applications based on KubeEdge.
2.1 Create a K8s cluster using HUAWEI CLOUD CCE service
Log in to the HUAWEI CLOUD account and enter the HUAWEI CLOUD CCE service console
HUAWEI CLOUD CCE service console link: https://www.huaweicloud.com/s/JWNjZSU
Click to use now
Click to create a CCE cluster
Select the appropriate location according to the location of the business, enter the cluster name, and select the cluster project and version. Can be selected according to the actual situation
Click to create a node
After selecting as needed, click Next to install the plug-in
Then click to confirm the configuration and submit the payment
Wait about 8 minutes for the CCE cluster to be created
The next step is to create a node pool. In order to ensure the availability of the application, the number of nodes should be greater than or equal to 2. Of course, in actual business, the node specifications and operating system should be selected according to specific needs.
Network configuration is configured according to requirements
Submit after confirming that the information is correct, and wait for 3-5 minutes for the node to be created.
After the creation is complete, we configure the node as shown in the figure below. If there is no elastic public IP, it needs to be purchased separately.
At the same time, the security group needs to release 20004-20008.
2.1 Build KubeEdge environment
In this section, we mainly explain how to use Huawei Cloud to build a KubeEdge environment.
Open the browser and enter the OSC console: https://console.huaweicloud.com/osc
First subscribe to CloudCore, click Create CloudCore service, the region is the same as the previous selection, and the service name can be selected by default.
Fill in the public network IP we bound before in the instance parameter column, and fill in the node name we filled in before in nodeName. Click Submit when you're done. After the task is submitted, the instance will be installed, which takes 3-5 minutes.
On the workload interface, you can see that CloudCore has been created. Click Cloudshell to enter the terminal interface.
We can operate the cluster with the following commands.
kubege get nodes
After CloudCore is installed, you can use keadm to manage edge nodes.
Open github and enter kubeedge to select the corresponding version of the edge node installation package to download.
Put the downloaded and decompressed compressed package into the system root directory.
Use the keadm join command to add
We go back to the CCE interface, open Cloudshell, enter kubecli nodes, and we can see that our edge nodes have been included in the edge nodes.
On the CloudShell interface, we need to modify the clusterDNS and clusterDomain parameters so that we can intercept DNS requests later. Save after the configuration is complete.
Enter systemmctl restart edgecore to restart the system.
Finally, we need to create an EdgeMesh service instance, click Subscribe and create an instance, and the rest of the steps are the same as CloudCore configuration.
2.3 Develop edge applications based on KubeEdge
There are many practical scenarios for edge applications, and we rely on the KubeEdge example as an illustration.
KubeEdge example link: www.github.kubeedge/example
We mainly use KubeEdge Counter Demo. Its main application architecture is as shown in the figure below. It is mainly divided into two parts. There is a web Controller on the cloud to control and issue instructions to the edge, and a Counter on the edge to receive instructions on the cloud and change the state to Expectations on the cloud.
We first clone the example repository locally, log in to the development machine (linux system is recommended), and clone the example system.
Enter the CRD directory, modify the yaml of the app, and change the image to the mirror address of hw.
Go back to the top directory to package the crd and upload it to Cloudshell.
After the creation, you need to decompress, and then create the Controller application and edge application
Next, we choose to create a node access type service to access the counter demo with its public network IP and port.
The web display is shown in the figure. The edge counter will start counting after clicking.
3. Summary
This article mainly explains the basic principles of KubeEdge and how to build KubeEdge applications through Huawei Cloud deployment. With the commercialization of 5G communication and the rapid arrival of the Internet of Everything era, the number of devices at the edge of the network and the explosive growth of data generated, centralized data centers (including public cloud services) will face challenges in real-time performance, bandwidth, energy consumption, and data privacy , More and more scenarios need to apply edge computing. On K8s, edge computing can be realized through the three architectures of K3s, Microk8s, and KubeEdge. KubeEdge obtains more applications due to edge-cloud collaboration, edge-side lightweight, and edge autonomy capabilities.