Choosing the Right Edge Computing Platform: KubeEdge vs SuperEdge vs OpenYurt vs K3s

Background

Edge computing platforms aim to bring compute units close to data sources into the central cloud for unified management and rapid response to terminal requests. Thousands of edge nodes are scattered across locations such as bank branches, vehicle nodes, and gas stations, making centralized management difficult.

Edge Computing Challenges

When integrating edge computing into a Kubernetes system, the following problems must be addressed:

Memory data loss and inability to recover business containers after network disconnection or node restart.

Long‑term network disconnection leads to cloud‑side controller evicting business containers.

Ensuring data consistency between edge and cloud after network recovery.

Unstable networks cause heavy API Server load due to repeated ListWatch re‑listing for each reconnection, especially in large‑scale, unreliable cross‑internet scenarios.

Solution Options

KubeEdge

SuperEdge

OpenYurt

k3s

3.1 KubeEdge

3.1.1 Architecture Overview

KubeEdge is the first CNCF open‑source project that extends Kubernetes to provide cloud‑edge collaboration. Its key goals are cloud‑edge coordination, heterogeneous resource support, large‑scale deployment, lightweight operation, and unified device management.

KubeEdge architecture:

The architecture consists of three layers: cloud, edge, and device.

Cloud

The cloud side includes two components:

cloudhub – receives information synchronized from edgehub.

edgecontroller – synchronizes the state of Kubernetes API Server, edge nodes, applications, and configurations.

Kubernetes master runs in the cloud, allowing users to manage edge nodes, devices, and applications with standard kubectl commands.

Edge

The edge side includes five components:

edged – a lightweight Kubelet that manages Pod, Volume, Node lifecycles.

metamanager – persists local metadata, enabling edge autonomy.

edgehub – a multiplexed messaging channel for reliable cloud‑edge synchronization.

devicetwin – abstracts physical devices and creates a device‑state mapping in the cloud.

eventbus – subscribes to device data from an MQTT broker.

Network

KubeEdge edge‑cloud network relies on EdgeMesh:

The cloud side runs a standard Kubernetes cluster with any CNI plugin (e.g., Flannel, Calico) and native components. CloudCore runs on the cloud, while EdgeCore runs on edge nodes to register them with the cloud cluster.

EdgeMesh consists of EdgeMesh‑Server (cloud) and EdgeMesh‑Agent (each node). The server listens for agent connections, assists UDP hole‑punching for P2P links, and relays traffic when direct P2P fails.

3.1.2 Practice

Deployment was performed according to the official “Deploying using Keadm | KubeEdge” guide.

Cluster information:

Cloud – 47.108.201.47, Ubuntu 18.04.5 LTS, amd64, k8s‑v1.19.8 + kubeedge‑v1.8.1, ports 10000‑10005 open.

Edge – 172.31.0.153, Ubuntu 18.04.5 LTS, arm64, kubeedge‑v1.8.1.

Practice conclusion: Edge nodes joined the cluster successfully, services could be deployed to edge nodes, and edge could access cloud services via svc, but cloud could not access edge services, and edge‑to‑edge svc communication failed.

3.2 SuperEdge

3.2.1 Architecture Overview

SuperEdge is Tencent’s Kubernetes‑native edge management framework. Compared with OpenYurt and KubeEdge, SuperEdge adds zero‑intrusion Kubernetes integration, distributed health checks, and edge service access control.

Cloud Components

tunnel‑cloud : maintains network tunnels with edge nodes (supports TCP/HTTP/HTTPS).

application‑grid controller : manages DeploymentGrids and ServiceGrids CRDs, generating corresponding deployments and services, and implements service topology awareness.

edge‑admission : uses distributed health‑check reports to decide node health and applies taints via cloud‑kube‑controller.

Edge Components

lite‑apiserver : a proxy for cloud‑kube‑apiserver, caching requests and serving them locally when the cloud network is unstable.

edge‑health : distributed health‑check service with voting to determine node health.

tunnel‑edge : establishes authenticated gRPC tunnels with tunnel‑cloud and forwards API requests to kubelet.

application‑grid wrapper : works with the controller to achieve closed‑loop service access.

3.2.2 Practice

Deployment followed the official “superedge/README_CN.md” guide.

Cloud – same as KubeEdge test environment.

Edge – same as KubeEdge test environment.

Practice conclusion: Edge nodes joined the cluster, but services could not be deployed to edge nodes; an issue was raised without response, and further testing was halted.

3.3 OpenYurt

3.3.1 Architecture Overview

OpenYurt enhances Kubernetes without intrusion. Cloud side adds Yurt Controller Manager, Yurt App Manager, and Tunnel Server. Edge side adds YurtHub and Tunnel Agent.

YurtHub proxies component communication, persists metadata locally, and enables edge autonomy during network instability.

Tunnel Server/Agent establish authenticated gRPC tunnels for bidirectional communication.

Yurt App Manager introduces NodePool and UnitedDeployment CRDs for batch node management and edge‑centric workload models.

3.3.2 Practice

No deployment was performed; only architectural study.

3.4 K3s

3.4.1 Architecture Overview

K3s is a CNCF‑certified lightweight Kubernetes distribution designed for resource‑constrained environments (x86, ARM64, ARMv7). It combines server and agent components, uses SQLite instead of etcd, replaces Docker with containerd, and bundles many processes into a single binary.

3.4.2 Practice

Installation scripts:

<code>curl -fsSL http://mirrors.aliyun.com/docker-ce/linux/ubuntu/gpg | sudo apt-key add -
# add Docker repo
sudo add-apt-repository "deb [arch=amd64] http://mirrors.aliyun.com/docker-ce/linux/ubuntu $(lsb_release -cs) stable"
sudo apt-get -y update
# install Docker-CE
sudo apt-get -y install docker-ce</code>

<code>curl -sfL http://rancher-mirror.cnrancher.com/k3s/k3s-install.sh | INSTALL_K3S_MIRROR=cn INSTALL_K3S_EXEC="--docker" sh -s - server</code>

<code>curl -sfL http://rancher-mirror.cnrancher.com/k3s/k3s-install.sh | INSTALL_K3S_MIRROR=cn INSTALL_K3S_EXEC="--docker" K3S_URL=https://192.168.15.252:6443 K3S_TOKEN=... sh -</code>

After installation, verification confirmed successful K3s cluster deployment.

Comparison

The four open‑source solutions share a decentralized deployment model where the control plane resides in the cloud and edge nodes run lightweight agents.

KubeEdge : CNCF incubating project (since 2018), invasive modifications, partial native monitoring, supports edge autonomy but adds EdgeMesh complexity.

OpenYurt : CNCF sandbox (since 2020), non‑invasive, full cloud‑native compatibility, lacks edge health checks.

SuperEdge : Not a CNCF project, later release (2020), similar to OpenYurt but less mature.

K3s : CNCF certified (since 2019), runs a full Kubernetes cluster on each edge node, higher resource usage, no built‑in cloud‑edge coordination.

Overall Conclusion

KubeEdge offers strong cloud‑edge coordination via EdgeMesh, but the added network layer increases complexity and edge‑to‑edge svc access fails in tests.

K3s provides a complete Kubernetes cluster on the edge, simplifying operations and avoiding extra components, though it consumes more resources.

Considering the specific scenario of a gas‑station business with sufficient edge server resources, K3s’s simplicity and lower operational overhead make it the preferred choice.