KubeEdge
KubeEdge extends Kubernetes so you can manage containerized workloads and connected devices at remote edge locations. It separates cloud-side control from edge-side execution, allowing edge nodes to keep running workloads when their cloud connection is unreliable.
itCloud native tools and technologies | OpenSkills.info
Intro
KubeEdge
KubeEdge extends Kubernetes from a central cluster to remote edge locations. You keep the Kubernetes control plane in the cloud or a central data center. KubeEdge adds cloud-side controllers and an edge-side agent so Kubernetes can manage workloads and devices across links that may be slow, private, or unreliable.
This architecture addresses a specific problem. Standard Kubernetes assumes that worker nodes can communicate with the control plane often enough to receive desired state and report current state. An edge site may lose that connection for minutes or hours. It may also have limited compute capacity and devices that speak protocols outside the Kubernetes resource model.
KubeEdge adapts Kubernetes to those conditions. It synchronizes the metadata each edge node needs, stores that metadata locally, and manages containers through the Container Runtime Interface. It also models devices with Kubernetes custom resources and connects those resources to protocol-specific mappers.
You still need an existing Kubernetes control plane. KubeEdge is not a separate container orchestrator and does not install Kubernetes for you. It extends a Kubernetes cluster with edge-aware communication, local state, workload management, and device management.
The cloud-and-edge split
KubeEdge has two major runtime parts:
- CloudCore runs on the cloud side. It connects Kubernetes controllers and the API server to edge nodes. CloudHub maintains cloud-edge connections. EdgeController synchronizes node and workload metadata. DeviceController synchronizes device metadata and status.
- EdgeCore runs as a service on each edge node. EdgeHub communicates with CloudHub. Edged manages pod lifecycles through a compatible container runtime. MetaManager stores and serves local metadata. DeviceTwin tracks device state. EventBus and ServiceBus connect local applications and services.
The central control plane remains the source of desired Kubernetes state. KubeEdge narrows and transports the relevant state to each edge node. This avoids requiring every edge node to run a full Kubernetes control plane.
Continue the course
This section is part of the paid course.
See pricing to subscribe, or log in if you already have access.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://kubeedge.io/
Supports
- KubeEdge is built on Kubernetes and extends containerized application orchestration to edge hosts
- Cloud-edge coordination supports bidirectional communication with edge nodes in private subnets
- Per-node metadata persistence supports autonomous edge operation during cloud disconnection
- KubeEdge supports x86, ARMv7, and ARMv8 environments
- https://kubeedge.io/docs/
Supports
- KubeEdge extends native containerized application orchestration and device management to edge hosts
- CloudCore includes CloudHub, EdgeController, and DeviceController responsibilities
- EdgeCore includes EdgeHub, Edged, EventBus, ServiceBus, DeviceTwin, and MetaManager responsibilities
- KubeEdge supports Kubernetes-native management and HTTP or MQTT applications
- https://kubeedge.io/docs/category/architecture/
Supports
- The architecture documentation provides component-level references for cloud, edge, and the shared Beehive framework
- CloudCore and EdgeCore separate central control integration from edge execution
- https://kubeedge.io/docs/setup/prerequisites/kubernetes
Supports
- An existing Kubernetes control plane is essential before deploying KubeEdge
- KubeEdge extends Kubernetes to network-unreliable and resource-constrained edge locations
- https://kubeedge.io/docs/setup/prerequisites/runtime/
Supports
- Each edge node needs a container runtime for EdgeCore installation and edge pod execution
- Runtime endpoint and cgroup settings depend on the selected CRI implementation
- Docker Engine requires cri-dockerd in current post-dockershim KubeEdge releases
- https://kubeedge.io/docs/setup/install-with-keadm/
Supports
- keadm installs cloud and edge components but does not install Kubernetes or its runtime environment
- keadm init deploys CloudCore on the cloud side
- keadm join installs EdgeCore and requires a CloudCore address
- CloudCore's advertised address must be reachable by edge nodes and is added to certificate subject alternative names
- CloudCore and EdgeCore should use the same KubeEdge version
- https://kubeedge.io/docs/architecture/edge/edged/
Supports
- Edged manages pod lifecycle on edge nodes
- Edged uses the Container Runtime Interface with OCI-compliant runtimes
- Edged manages probes, ConfigMaps, Secrets, volumes, images, and status
- Edged retrieves metadata through MetaManager and can use locally stored entries
- https://kubeedge.io/docs/architecture/edge/edgehub/
Supports
- EdgeHub communicates with CloudHub through WebSocket or QUIC
- EdgeHub routes messages between cloud and edge modules
- EdgeHub reports connection state to local module groups
- https://kubeedge.io/docs/architecture/edge/metamanager
Supports
- MetaManager processes messages between Edged and EdgeHub
- MetaManager stores and retrieves metadata from a local SQLite database
- MetaManager tracks cloud connection state and periodically synchronizes pod status
- https://kubeedge.io/docs/architecture/cloud/device_controller/
Supports
- DeviceController uses Kubernetes custom resources to describe device metadata and status
- Device models are reusable descriptions, while device instances represent actual devices
- DeviceController synchronizes desired state downstream and reported state upstream
- https://kubeedge.io/docs/concept/device/mapper/
Supports
- A mapper manages devices that use a particular protocol
- Mappers read, write, and report device data and status
- DeviceController, DeviceTwin, and mappers form the device-control path
- https://kubeedge.io/docs/developer/dmi/
Supports
- The Device Management Interface provides a unified connection between EdgeCore and mappers
- The architecture separates the device management plane from the device data plane
- Device data can flow directly to local consumers without always crossing the cloud-edge channel
- https://kubeedge.io/docs/advanced/inclusterconfig/
Supports
- Edge pods cannot normally reach the cloud Kubernetes API through standard in-cluster configuration across separated networks
- KubeEdge can provide edge-side Kubernetes API access by enabling MetaServer and required authorization features
- https://kubeedge.io/docs/faq/setup/
Supports
- CloudCore and EdgeCore logs are primary evidence for installation and runtime diagnosis
- CloudCore address reachability, firewall access, tokens, and certificate identity can prevent edge-node joins
- The CloudCore advertised address must align with the address EdgeCore uses and with certificate coverage
- CloudCore workload failures should be diagnosed through Kubernetes workload state and logs
- https://github.com/sindresorhus/awesome
Supports
- Discovery began from the maintained index of topic-specific awesome lists
- https://github.com/qijianpeng/awesome-edge-computing
Supports
- EdgeMesh, OpenYurt, K3s, and EdgeX Foundry are relevant projects in the edge-computing ecosystem
- EdgeMesh is associated with KubeEdge service communication
- OpenYurt and K3s provide alternative Kubernetes-oriented approaches for edge environments
- EdgeX Foundry provides device and application interoperability at the IoT edge
- https://edgemesh.kubeedge.io/
Supports
- EdgeMesh works with Kubernetes APIs and KubeEdge's edge API endpoint
- EdgeMesh deploys agents across nodes to support edge service communication
- The documentation covers proxying, security, gateways, and high availability
- https://openyurt.io/docs/
Supports
- OpenYurt manages distributed heterogeneous edge resources through a central control side
- YurtHub caches Kubernetes API state locally to support edge autonomy
- OpenYurt documents node pools, cross-node-pool networking, workload upgrades, and device-management integration
- https://docs.k3s.io/
Supports
- K3s is a lightweight, conformant Kubernetes distribution intended for edge, IoT, embedded, and air-gapped environments
- K3s packages control-plane and supporting components into a compact distribution
- https://docs.edgexfoundry.org/4.0.2/
Supports
- EdgeX Foundry is a vendor-neutral edge interoperability framework
- EdgeX device services connect sensors and devices, translate protocols and data, and support actuation
- The documentation provides guidance for building device services and connecting applications