KubeEdge: Kubernetes Application and Device Management at the Edge

KubeEdge is a Kubernetes-native edge computing framework. It lets a central Kubernetes cluster manage applications and devices on edge nodes in factories, vehicles, retail sites and remote locations, where the network is slow, intermittent or behind a firewall that allows only outbound connections. A stock kubelet expects a stable, low-latency connection to the API server, which edge sites rarely provide. KubeEdge replaces that connection with a cloud component, CloudCore, and a lightweight edge agent, EdgeCore, that keep a reliable message channel, cache the desired state locally and keep pods and devices running when the link drops. KubeEdge was open sourced by Huawei Cloud in November 2018, accepted into the CNCF Sandbox on 18 March 2019, moved to Incubating on 16 September 2020 and graduated on 11 September 2024, with the graduation announced on 15 October 2024.

CNCF daily · Sprint 3, post 16 of 21 · Automation & Configuration

At a glance

Category	Provisioning › Automation & Configuration
CNCF status	Graduated. Accepted March 18, 2019; incubating September 16, 2020; graduated September 11, 2024
Written in	Go
License	Apache 2.0
Cloud side	CloudCore: CloudHub (WebSocket or QUIC server), EdgeController, DeviceController
Edge side	EdgeCore: EdgeHub, Edged (runs pods), MetaManager (local cache), EventBus (MQTT), DeviceTwin
Key properties	Edge autonomy, reliable cloud-edge messaging, a small agent, edge-initiated connections
Related components	EdgeMesh (edge networking and service discovery), device mappers, Sedna (edge AI)
Installer	keadm (container or binary mode); it does not install Kubernetes or the container runtime

Architecture

Slate is Kubernetes, purple KubeEdge, grey the edge workloads and blue the devices. The two purple arrows are one connection that the edge opens to the cloud. Open the zoomable diagram, or download it as SVG or PNG.

Component	Responsibility
Kubernetes API	The usual control plane: users create pods, and edge nodes appear as nodes in the same cluster.
CloudCore	Watches the API through its controllers and sends the desired state for each edge node through CloudHub.
EdgeCore	The edge agent. EdgeHub keeps the connection to CloudCore, Edged runs pods, and MetaManager stores metadata in a local database.
Edge pods	The workloads on the edge node. They keep running and restart from the local cache if the link is down.
Devices	Sensors and machines that connect to EdgeCore over MQTT, or through mapper programs, and are represented as device twins.

Design principle. Assume the link will fail. The edge keeps its own copy of the desired state and runs from it, and the cloud treats the edge connection as eventually consistent, so a lost link delays updates but does not stop the site.

Request flow

1. Watch the API. A user creates a pod that targets an edge node. CloudCore’s controllers see it through their watch on the Kubernetes API.
2. Send desired state. CloudCore sends the pod specification to EdgeCore through CloudHub, over the WebSocket or QUIC connection the edge opened.
3. Run the pod. EdgeCore stores the specification in its local database and Edged starts the pod. If EdgeCore restarts or the link drops, it runs from this copy.
4. Collect device data. Devices publish telemetry over MQTT to EdgeCore, which processes it locally and updates the device twin.
5. Report back. When the link is up, EdgeCore sends pod status, node status and device twin updates to CloudCore, which writes them to the Kubernetes API.

Open the zoomable flow diagram, or download it as SVG or PNG.

Production reference design

This Sprint 3 design runs CloudCore in the cloud cluster on Google Compute Engine (self-managed Kubernetes with Calico, not GKE) and EdgeCore on bare-metal edge machines.

1. Expose CloudCore. (GCP) Give CloudCore a stable address, for example a Cloud Load Balancing address or a static external IP, and open firewall rules for TCP 10000 (CloudHub) and 10002 (certificate and token service) from the edge sites. Edge nodes only make outbound connections.
2. Install CloudCore on the cluster with keadm, choosing a version that your Kubernetes release supports:

   keadm init --advertise-address="<CLOUDCORE-ADDRESS>" --kubeedge-version=v1.23.1 --kube-config=/root/.kube/config
   keadm gettoken

3. Prepare each edge machine with a container runtime, such as containerd, and the keadm binary of the same version.
4. Join the edge node with the token:

   keadm join --cloudcore-ipport="<CLOUDCORE-ADDRESS>":10000 --token=<TOKEN> --kubeedge-version=v1.23.1

   Confirm with kubectl get nodes in the cloud and systemctl status edgecore on the edge.
5. Deploy an application to the edge by setting a node selector or toleration for the edge node’s label, and test it by blocking the edge’s link to the cloud: the pod should keep running.
6. Add devices with MQTT through EdgeCore’s EventBus, or with a mapper for the device protocol, and add EdgeMesh if edge pods need service discovery between sites.

Typical uses include factory and retail sites, transport and energy systems, vehicles, and any place where applications must keep running through network loss.

Operational considerations

• Version alignment. Cloud and edge components must be the same KubeEdge version, and the release must match the Kubernetes version. Plan upgrades site by site.
• Network exposure. CloudCore ports must be reachable from every site. Use a stable address, firewall rules that allow only known sites, and token rotation.
• Edge resources. EdgeCore is lighter than a kubelet with its dependencies, but the container runtime, pods and cache still need CPU, memory and storage.
• Not all Kubernetes features work. Some features that need direct node access, such as certain logs and exec paths, require extra setup, so test the operations you depend on.
• Data and ordering. Messages are delivered reliably but not instantly. Design applications for delayed updates, and decide what each site does when it is offline for a long time.

Adoption

• NIO built a vehicle-to-cloud platform on KubeEdge and uses it in mass-produced vehicles, according to the CNCF’s graduation announcement.
• SF Technology uses KubeEdge in logistics sorting and transportation, in the same announcement.
• HarmonyCloud, DaoCloud and BoCloud report customer deployments in telecommunications, manufacturing, retail, finance, transportation and energy.
• The announcement also lists intelligent transportation, smart energy, smart retail, aerospace and CDN among the project’s industries, and the project keeps an ADOPTERS file in its repository.

Alternatives

Solution	Model	Best suited to
K3s (Rancher)	Lightweight full Kubernetes at each site	Sites with a reliable link that can run their own small cluster; see the K3s brief
OpenYurt (CNCF Incubating)	Edge extension for Kubernetes	Teams that want to keep standard kubelets and add edge autonomy
Akri (CNCF Sandbox)	Device discovery for Kubernetes	Exposing leaf devices to a cluster, rather than managing the edge node
Karmada (CNCF Graduated)	Multi-cluster management	Fewer, larger edge clusters; see the Karmada brief
Cloud IoT services	Managed device and edge platforms	Teams that prefer a vendor service for device fleets

Strengths and limitations

Strengths	Limitations
Built for unreliable and one-way connections	CloudCore must be reachable from every edge site
Edge autonomy through the local cache	Cloud and edge versions must match
Small agent for constrained hardware	Not every Kubernetes feature works unchanged at the edge
Device management with MQTT and twins	Smaller ecosystem outside China and edge-focused teams
CNCF Graduated, Apache 2.0, wide industry use	Operating many edge nodes needs strong automation

Recommendation

Adopt for organisations that manage many edge sites over unreliable links and want Kubernetes APIs for applications and devices. Start with one cloud cluster and two edge nodes, run the offline test (cut the link and confirm pods keep running), then script the join and upgrade process before adding sites. For a few sites with solid connectivity, a small cluster per site with K3s and a multi-cluster tool is simpler.

References: CNCF project page · KubeEdge graduation announcement · Installing KubeEdge with Keadm · CloudCore and EdgeCore configuration · KubeEdge repository · CNCF Landscape