How OpenYurt Enables Edge Autonomy on Unstable Networks

Background

OpenYurt’s mission is to extend Kubernetes’s powerful cloud‑side control to the edge, unifying heterogeneous edge resources into a single platform. Edge environments often lack the stable, high‑bandwidth network assumed by vanilla Kubernetes, leading to high public‑network costs, cross‑domain communication challenges, and especially unstable connectivity.

Problems with Native Kubernetes in Unstable Networks

When a node loses network connectivity, Kubernetes performs a series of actions:

kubelet detects the network issue within 10 seconds and updates the NodeStatus, but cannot report it to the control plane.

The control‑plane NodeLifeCycle controller receives no heartbeat for 40 seconds, marks the node NotReady , and stops scheduling new pods to it.

If the heartbeat remains absent for 5 minutes, the controller evicts all pods on the node.

This behavior is appropriate for always‑online data‑center machines but problematic for edge nodes that may intentionally disconnect for maintenance or simply suffer intermittent network loss. Moreover, some edge workloads require pods to stay bound to a specific node (e.g., camera‑based image processing or smart‑traffic applications), which conflicts with Kubernetes’s default isolation model.

Another issue is that, during a network outage, the node’s in‑memory data is lost on restart, preventing pod recovery because the kubelet cannot fetch required resources from the cloud.

OpenYurt Edge Autonomy Capabilities

OpenYurt introduces a set of non‑intrusive solutions to address these challenges.

YurtHub – Edge‑Side Cache and Proxy

When the cloud‑edge network is healthy, YurtHub acts as a transparent gateway that forwards requests to the cloud while caching responses locally.

If the network disconnects, YurtHub switches traffic to the local cache, allowing kubelet and other components to continue operating without cloud access. After reconnection, YurtHub resumes forwarding and updates the cache.

Centralized Heartbeat Proxy (Pool‑Coordinator + YurtHub)

In OpenYurt 1.2, a heartbeat proxy mechanism ensures that node heartbeats reach the cloud even during network outages:

With a healthy network, kubelet reports heartbeats to both the cloud and the Pool‑Coordinator via YurtHub.

When the network is down, the cloud heartbeat fails, but the heartbeat sent to the Pool‑Coordinator carries a special label.

The leader YurtHub watches the Pool‑Coordinator’s heartbeat data; if a labeled heartbeat is found, it forwards it to the cloud and adds a taint to the node to prevent new pod scheduling.

This mechanism prevents unwanted pod eviction (Problem 2) while still allowing the node to be marked with a taint that limits scheduling of new workloads.

Node Binding for Edge Workloads

OpenYurt supports two ways to bind pods to a specific edge node:

Node‑level binding: label the node with node.beta.openyurt.io/autonomy=true so that all pods on that node are considered bound.

Pod‑level binding: add the label apps.openyurt.io/binding to a pod, indicating it requires node‑binding semantics.

Both approaches ultimately add appropriate tolerations to the pod, ensuring the workload remains on the designated node even if the node experiences a failure.

Summary

Edge scenarios demand autonomy when cloud‑edge connectivity is weak or absent. OpenYurt builds on native Kubernetes to provide a non‑intrusive solution that tackles three core pain points: loss of in‑memory data on node restart, pod eviction during prolonged network outages, and the need for node‑specific workload binding. The combination of YurtHub caching, a centralized heartbeat proxy, and flexible binding labels enables continuous operation of edge applications, laying the groundwork for a reliable, cloud‑native edge computing platform.

Future directions include expanding edge autonomy to cover node‑pool management and other advanced operational capabilities.