KubeEdge
An edge computing framework that extends a Kubernetes control plane out to edge nodes and IoT devices over an unreliable network.
- Category: Orchestration & Scheduling
- CNCF maturity: Graduated
- Language: Go
- License: Apache License 2.0
- Repository: kubeedge/kubeedge
- Documented at commit:
864f45eb1(89 commits after v1.23.0, 2026-06-22)
What it is
KubeEdge splits a cluster into two planes. The cloud plane runs cloudcore, a control-plane process that sits next to a normal Kubernetes API server. The edge plane runs edgecore, a lightweight agent on each edge node that manages Pods and talks to local IoT devices. The two planes connect over a single WebSocket or QUIC channel and exchange messages across it.
Both processes are built from modules registered on Beehive, an in-tree messaging framework. A module declares a name, a group, and a restart policy, then communicates with other modules only through a message bus. This keeps the cloud controllers and the edge agent loosely coupled and lets either side run a different subset of modules.
The edge agent stores desired state in a local SQLite database, so an edge node keeps running its workloads when the link to the cloud drops. KubeEdge adds device management on top of plain workload orchestration: it models physical devices as Kubernetes custom resources and bridges them through an MQTT broker.
When to use it
- You run Kubernetes workloads on nodes that lose connectivity to the control plane and must keep operating offline (edge autonomy).
- You manage IoT or field devices and want them as Kubernetes objects with a desired/reported state twin.
- Your edge hardware is too constrained for a full kubelet but can run a trimmed agent.
- It is a poor fit when every node has a stable, low-latency link to the API server; a standard cluster or a thin distribution is simpler then.
- It is also a poor fit when you only need a smaller Kubernetes and have no device or offline requirement.
In this deep-dive
- History: origin, milestones, and why it exists.
- Architecture: components and how requests flow.
- Adoption & Ecosystem: who runs it and what surrounds it.
- Internals: the code paths that matter, read from source.
- Getting Started: install and a first working setup.