KubeEdge: Kubernetes for Edge Computing

Kubernetes at the edge: the problem KubeEdge solves

Edge computing pushes application processing closer to data sources, reducing latency and protecting privacy by keeping sensitive data local. But most edge environments lack the infrastructure that cloud data centers have. KubeEdge extends Kubernetes to these environments, letting you manage edge nodes and containers using the same Kubernetes API you use for cloud workloads.

Without KubeEdge, edge deployments require separate tooling, separate APIs, and manual synchronization between cloud and edge state. KubeEdge unifies the two: you define a pod in your cloud Kubernetes cluster, and EdgeCore (the edge agent) pulls it down, runs it on the edge node, and reports status back to the cloud. The edge node stays connected to your control plane through a websocket tunnel managed by CloudHub and EdgeHub.

The architecture: cloud hub and edge core

KubeEdge splits into two parts. The cloud part runs in your existing Kubernetes cluster as three controllers: CloudHub (a websocket server that watches changes at the cloud side, caches and sends messages to edges), EdgeController (an extended Kubernetes controller that manages edge nodes and pods metadata, targeting data to specific nodes), and DeviceController (an extended Kubernetes controller that manages devices so their metadata and status sync between edge and cloud).

The edge part runs on each edge node. EdgeCore is the main agent that schedules and runs containers, similar to kubelet. EventBus is an MQTT client that interacts with MQTT servers like mosquitto, offering publish and subscribe capabilities to other components. ServiceBus is an HTTP client that interacts with HTTP servers over REST, offering HTTP client capabilities for cloud components to reach HTTP servers running at the edge. DeviceTwin is responsible for storing device status and syncing it to the cloud, while also providing query interfaces for applications. MetaManager acts as the message processor between EdgeCore and EdgeHub, and is responsible for storing and retrieving metadata from a lightweight SQLite database.

Messages between cloud and edge travel over a websocket connection. This matters because edge networks are often unstable. KubeEdge handles this by caching messages at CloudHub and EdgeHub, then delivering them when the connection stabilizes. If an edge node goes offline, it continues running its scheduled pods autonomously. When it reconnects, it syncs state with the cloud. This architecture ensures reliable message delivery without loss over unstable cloud-edge networks.

Deploying CloudCore and EdgeCore with keadm

Installation uses keadm, a command-line tool that deploys CloudCore to your Kubernetes cluster and EdgeCore to edge nodes. CloudCore runs as extended Kubernetes controllers in your cloud cluster, watching changes and managing edge state. EdgeCore runs as a lightweight agent on each edge machine, managing containerized applications on that node. The README links to separate guides for cloud core and edge core deployment, documenting the full setup process. Once deployed, edge nodes appear in `kubectl get nodes` alongside your cloud nodes and are labeled with the edge role.

You deploy applications to edge nodes using standard Kubernetes manifests. The EdgeController automatically routes pods to edge nodes based on node selectors and node affinity rules. Once scheduled, pods pull down to the edge and run there, with status updates flowing back to the cloud. The system provides core infrastructure support for networking, application deployment, and metadata synchronization between cloud and edge. The README and examples repository provide sample deployments and configuration, including examples for machine learning, image recognition, and event processing workloads.

Edge devices and MQTT messaging

KubeEdge can manage connected devices (sensors, cameras, etc.) on your edge network. You define a Device object in Kubernetes using Custom Resource Definitions, and KubeEdge syncs that state to the edge node. The node's EventBus MQTT client interacts with MQTT servers like mosquitto, letting your applications subscribe to device data and offering publish and subscribe capabilities to other edge components. KubeEdge implements device management through DeviceTwin, which stores the device status and syncs changes to the cloud, also providing query interfaces for applications running on the edge.

Applications running on edge nodes can also use ServiceBus to call HTTP endpoints in the cloud, enabling cloud services to push instructions back to the edge. This creates a two-way communication channel without the application having to manage networking. This support for MQTT and HTTP back-channels enables complex edge scenarios like real-time sensor data collection and cloud-driven device control.

Autonomy when offline and network instability

The fundamental constraint of edge computing is that networks fail. KubeEdge addresses this with edge autonomy: if the cloud connection drops, edge nodes continue running their assigned pods without interruption. The pod manifest is cached on the edge node, so as long as container images are already present, workloads keep running.

When the cloud-edge link reconnects, EdgeCore queries the cloud for any manifest updates, then syncs local state. This design works well for stateless applications and for workloads that tolerate eventual consistency. However, applications that need real-time state from the cloud during disconnection will fail. Also, if an edge node crashes and loses its cache before reconnecting, pods may not restart if the cloud was unreachable during the outage.

Kubernetes compatibility and lightweight requirements

KubeEdge supports Kubernetes 1.27 through 1.32. The newest release, KubeEdge 1.23, fully supports Kubernetes 1.30, 1.31, and 1.32, with partial support for earlier versions. Check the compatibility matrix in the README.

EdgeCore is designed for resource-constrained devices. It uses SQLite instead of etcd for local metadata storage, which reduces memory overhead. The binary itself is comparatively small. However, you still need enough disk space for container images and enough RAM to run your applications. The README does not specify minimums, so benchmark EdgeCore on your target hardware.

CNCF graduation and active development

KubeEdge graduated from the Cloud Native Computing Foundation in 2024. The last push to the repository was on 2026-09-23, six days ago. Recent releases include v1.23.1 (2026-07-15), v1.22.2 (2026-07-15), and v1.21.2 (2026-07-15). The project holds a Core Infrastructure Initiative best practices badge. License is Apache 2.0.

Editorial conclusion

KubeEdge is for organizations running Kubernetes that want to extend control to edge devices while keeping application logic tied to Kubernetes. Avoid it if your edge nodes do not have Kubernetes compatibility or if you need strict real-time guarantees that cloud-edge communication cannot provide. Verify first that your edge devices have enough resources to run EdgeCore and that your network topology allows reliable cloud-edge websocket connections even under degradation.

Frequently asked questions

Official sources

1. kubeedge/kubeedge on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases