What’s New in OpenYurt v1.5? Multi‑Region Workloads, Edge Autonomy, and Traffic Optimizations

OpenYurt v1.5 Overview

OpenYurt v1.5 extends native Kubernetes with edge‑native capabilities, focusing on multi‑region workload management, edge autonomy, controller permission isolation, traffic‑reduction for large‑scale node onboarding, and transparent cloud API access.

Multi‑Region Workload Enhancements (YurtAppSet v1beta1)

The YurtAppSet API is promoted from v1alpha1 to v1beta1. Key fields:

workloadTemplate : a single template that defines workloads across all regions, enabling batch create, update and delete operations.

nodepoolSelector : selects target NodePool objects dynamically; when node pools are added or removed, workloads are automatically redistributed.

workloadTweaks : region‑specific customizations applied without managing each workload individually.

The new API supersedes the deprecated YurtAppDaemon and YurtAppOverider resources.

Edge Autonomy Improvements

Yurthub caches pod and node metadata on local disk, allowing the Kubelet to recover workloads when the cloud‑edge link is lost.

Pod eviction protection: nodes annotated with apps.openyurt.io/binding=true are exempt from eviction even when they become NotReady.

Yurthub now reports a custom NodeCondition that reflects the health of its local cache, enabling the cloud controller to make more accurate autonomy decisions.

Controller Permission Isolation

Previously all OpenYurt controllers and webhooks shared a single ClusterRole and ServiceAccount. In v1.5 each controller/webhook receives its own ServiceAccount and dedicated ClusterRole / ClusterRoleBinding, reducing privilege over‑granting and improving auditability.

NodeBucket – Reducing Traffic Peaks During Rapid Node Onboarding

When thousands of edge nodes join a cluster quickly, each node update triggers a NodePool status change, causing a traffic surge. The new NodeBucket resource groups a limited number of nodes (default ≤ 100) with an N:1 ratio to a NodePool. Yurthub uses NodeBucket for service‑topology, dramatically lowering the number of status updates sent to the cloud.

Transparent Access to Cloud kube‑apiserver

Edge pods cannot reach the cloud kube‑apiserver via the default kubernetes service because they reside on different physical networks. OpenYurt adds a data‑rewriting mechanism that intercepts requests from pods using InClusterConfig or the default service, rewrites the endpoint to the cloud API, and forwards the traffic over the public network without requiring code changes.

Other Updates

All new capabilities are packaged as non‑intrusive Addons, preserving native Kubernetes compatibility.

Security hardening and permission splitting for Yurt‑Manager components.

References

GitHub release page: https://github.com/openyurtio/openyurt/releases

OpenYurt issue tracker: https://github.com/openyurtio/openyurt/issues