Project guest post by KubeEdge Maintainers
KubeEdge enables cloud-edge synergy, computing at edge, and easy access of a massive number of devices based on Kubernetes container orchestration and scheduling capabilities. This article will introduce KubeEdge architecture, code directory, and cluster deployment.
KubeEdge Architecture
1. Kubernetes Architecture
This diagram shows a classic Kubernetes architecture. It consists of a control plane and a data plane. Kubernetes has a robust ecosystem and a full set of standards for application and container management. Some of its advantages are as follows:
- etcd can be accessed only through the API server.
- Components obtain cluster status through the API server.
- Kubernetes uses declarative APIs.
- API objects complement each other and can be combined.
- Event listening is used preferentially instead of polling.
2. Advantages and challenges of Building Edge Computing Based on Kubernetes
The advantages are as follows:
Container-based application encapsulation provides great flexibility. You only need to encapsulate your applications once, then they are available to run everywhere. This is exactly what IoT needs. Traditionally, the software of IoT embedded devices has to adapt to different types of hardware as they are closely related. If we pack the software into containers and have devices support container runtime, the software can be easily provisioned to all types of IoT devices.
Kubernetes has been widely recognized in the industry. A set of standards has been established for Kubernetes APIs, including Developments and pods. Using Kubernetes as the foundation of the edge computing platform makes the platform easier to work with.
Kubernetes’ loosely coupled architecture ensures extensibility. For example, custom resources can be used to define APIs of IoT devices. These APIs allow the devices to be easily managed using Kubernetes. In addition, diverse types of runtimes can be integrated using CRIs. Considering the resources of edge nodes are restricted, lightweight runtimes are preferred when it comes to IoT devices.
The challenges are as follows:
- Resource constraints
A gateway device requires 128 MB of memory.
A Kubernetes cluster requires at least 1 GB of memory, whereas the resources of edge nodes are limited.
- Poor network connection
Edge nodes are on private networks with no public IP addresses.
The cloud accesses the edge over public networks, which are in limited bandwidth and brings high latency.
The list-watch of Kubernetes requires data center network.
- Hard to achieve edge node autonomy
The network is unstable and may be offline at any time.
Edge services are required to work properly even when they are disconnected.
The edge should be able to recover from faults when it is offline.
- Poor support for device access and management
Lack of edge device abstraction
Poor support for edge device access protocols
3. KubeEdge Architecture and Core Concepts
The KubeEdge architecture consists of cloud, edge, and device layers. The control plane is on the cloud. Edge nodes are at the edge. At the cloud layer, the green box on the left represents a Kubernetes master. It is a native Kubernetes control plane without any changes. The light yellow box on the right represents CloudCore. It contains EdgeController and DeviceController, which process data from the control plane, and Cloud Hub, which sends the data to EdgeHub at the edge.
The edge enables application and device management. In the light yellow box, on the left is Edged for application management. On the right are DeviceTwin and EventBus for device management. The green box on the left represents DataStore. It enables local autonomy. Specifically, when the data of an application or device is distributed from the cloud through EdgeHub, the data is stored in a database before it is sent to Edged or the device. In this way, Edged can retrieve metadata from the database and the service recovers even when the edge is disconnected from the cloud or when the edge node restarts.
Core Concepts
- Reliable cloud-edge synergy
Bi-directional, multiplex network communication between cloud and edge nodes allows the edge nodes to be located in private networks.
WebSocket and message encapsulation greatly eases communication pressure and ensures normal running even when high latency occurs.
Cloud-edge message verification ensures that no data is lost when the network is unstable.
- Edge node autonomy
Node metadata persistence provides node autonomy when the nodes are disconnected.
Node fault recovery does not require list-watch. It reduces the network pressure and recovery time.
- Lightweight edge
The Kubelet functional modules are reorganized to achieve ultimate lightweight (only requiring about 70 MB of memory).
Containerd and CRI-O can be integrated using CRI to reduce runtime resource consumption.
- Edge device management
The cloud uses Kubernetes APIs to manage edge devices.
4. The KubeEdge Community and Ecosystem
KubeEdge is committed to extending Kubernetes capabilities to the edge.
It is the first edge container platform project in the industry.
KubeEdge supports Apache License 2.0.
It was donated to CNCF in March 2019.
In September 2020, the project was promoted to an incubation-level hosted project.
Kubernetes IoT Edge WG reference architecture
This platform is built based on Kubernetes and fully compatible with Kubernetes APIs.
Eleven feature releases. The latest is v1.6.1.
4,000+ stars, 1,100+ forks, 680 + contributors
Currently, three SIGs are established: SIG Device IoT, SIG MEC, and SIG AI.
The following enterprises have contributed to the community: China Unicom, ARM, China Mobile, Harmony Cloud, China Telecom, Tenxcloud, JD.com, the Software Engineering Lab of Zhejiang University, EMQ, Infoblox, Inovex, and Midokura.
KubeEdge Code Directory Overview
The following screenshots show the KubeEdge code directory. If your project adopts KubeEdge and you want to participate in or give suggestions on KubeEdge, submit a PR to have us include you in ADOPTERS. The screenshots below show the details of the cloud, edge, and mappers directories. Mappers are for device access. OWNERS lists the KubeEdge maintainers. If you are a major contributor to the community and would like to lend a hand in reviewing and merging code, ask us to add your name into OWNERS.
KubeEdge Cluster Deployment
- Tool: keadm
keadm borrows the concept from Kubeadm to provide you fast paths for creating KubeEdge clusters. It deploys the KubeEdge system on top of Kubernetes. Before deploying KubeEdge clusters, install a Kubernetes master that is compliant with any of the Kubernetes standards.
Subcommand parameters
init: Deploy cloud components.
join: Deploy edge components.
gettoken: Obtain the startup credential of the edge device from the cloud.
reset: Resets the cloud and edge of the KubeEdge cluster.
- KubeEdge deployment at the cloud
Run the init command to install the cloud end of KubeEdge on the master.
Key parameters:
–kube-config: credential for connecting to the Kubernetes master
–advertise-address: IP address issued to the edge certificate
3. KubeEdge deployment at the edge
Run the join command to install the edge end of KubeEdge.
Key parameters:
–token: credential for accessing the cloud when the edge is started
–cloudcore-ipport: the cloud IP address accessed by the edge
For more details about KubeEdge, visit
Github: https://github.com/kubeedge/kubeedge
Website: https://kubeedge.io/en/