By Linbo He and Lu Chen
As an open-source project in the edge cloud-native field, OpenYurt adopts a cloud-edge architecture that integrates cloud and edge computing. It aims to address the challenges of deploying cloud-native solutions in edge computing scenarios. For cloud-edge collaboration scenarios, key features provided by OpenYurt include edge autonomy, universal cross-region Pod communication, multi-region workload and traffic management, and device management. At the same time, all features are non-intrusive to native Kubernetes and are installed and deployed in the form of Addons.
The OpenYurt architecture is as follows:
The v1.5 highlights improvements in multi-region workload management, edge autonomy, optimized cloud access pathways, and enhanced security. Major features include customizable configurations and canary release support for node pools in multi-region workloads, an edge autonomy mechanism for cloud-edge collaboration, controller permission splitting, optimized cloud access pathways, and reduced control traffic during large-scale node connection.
After extensive discussions within the community, the YurtAppSet API was upgraded from v1alpha1 to v1beta1 in v1.5. This upgrade includes dynamic detection of node pool changes to distribute workloads and support for customized configuration of workloads at the node pool level. Details include:
• workloadTemplate: Unified Template Definition
YurtAppSet enables you to manage workloads across multiple regions using a single unified workloadTemplate definition. This approach reduces redundant deployment configurations and makes batch operations like creation, updates, and deletions more efficient and consistent.
• nodepoolSelector: Automated Deployment
YurtAppSet uses the nodepoolSelector mechanism to flexibly select target node pools, synchronizing with their dynamic changes. When new node pools are created or existing ones are removed, the nodepoolSelector automatically identifies and matches the latest suitable node pools for workload distribution and deployment, helping you reduce the O&M burden.
• workloadTweaks: Regionally Differentiated Configurations
When application requirements vary between regions, YurtAppSet provides the workloadTweaks feature, allowing for customized adjustments to workloads in specific regions. This meets the unique needs of each region without requiring independent management or updates for each workload.
With the upgrade of YurtAppSet to v1beta1, its capabilities now cover the two APIs of YurtAppDaemon and YurtAppOverider. In this version, these two APIs have been marked as Deprecated, and users are recommended to use YurtAppSet v1beta1 instead.
The edge autonomy capabilities provided by OpenYurt in earlier versions ensure the stable operation of edge services, primarily including the following two aspects:
• Self-healing of business on edge nodes under cloud-edge disconnection:
o The Yurthub component on the node caches Metadata locally on the disk, ensuring that Kubelet can reliably recover edge services through local caching when there is a cloud-edge disconnection.
• Enhanced eviction policy for Pods in the cloud:
o For a Node with the apps.openyurt.io/binding=trueAnnotation, even if the node is NotReady, the controller will not evict Pods on that node.
In this version, Yurthub uses Node Condition to report the status of local edge caches in real time. Therefore, the cloud controller not only uses Node Annotation but also uses the real-time information of edge caches to determine whether edge autonomy can be enabled for nodes, solving the problem of edge autonomy misjudgment that may be caused by edge cache failures.
The Yurt-Manager component contains all Controllers and Webhooks in OpenYurt, which share the same ClusterRole and ServiceAccount. This results in Controllers having permissions that they should not have and makes it impossible to determine which Controller modified resources through audit logs.
In this release, each Controller and Webhook in Yurt-Manager uses a separate ServiceAccount and User-Agent to build its clientset. Additionally, individual ClusterRole/ClusterRoleBinding configurations are set up for each ServiceAccount. This provides better security and log auditing capabilities for Controllers and Webhooks.
In OpenYurt clusters, the NodePool.status.nodes field records the list of all nodes within a node pool. Yurthub relies on this information to identify endpoints within the same NodePool, enabling service topology functionality based on node pools. However, when a large-scale NodePool (potentially containing thousands of nodes) experiences rapid expansion, such as adding hundreds of edge nodes within a minute, the connection of each node triggers an update to the NodePool. Consequently, hundreds of updates need to be pushed to each edge node, causing a surge in cloud-edge communication traffic.
In this release, we introduce a new resource type called NodeBucket. A NodeBucket contains limited node information (up to 100 nodes by default) and exists in a ratio of N:1 compared to the size of the NodePool. In large-scale scenarios, this means that the size of the NodeBucket is approximately one-tenth that of the NodePool. Yurthub is adjusted to rely on NodeBucket for providing service topology functionality, significantly reducing cloud-edge communication traffic during rapid node connection and lowering traffic peaks.
The pod on the edge node and the cloud kube-apiserver are located on different physical network planes, and the default/Kubernetes service is usually resolved to an internal Pod IP address. Therefore, the Pod on the edge node cannot directly use the default/Kubernetes service to access the cloud kube-apiserver. In this release, OpenYurt introduces a transparent data rewriting mechanism that allows Pods using InClusterConfig or the default/Kubernetes service to directly access the cloud kube-apiserver over the public Internet without any modification or adaptation to the Pods.
You can visit the GitHub release[1] page to view additional changes as well as their authors and commit records.
Development for the v1.6 version of the community is underway, focusing primarily on high-availability access to multi-region services and traffic reuse at the node level for cloud-edge scenarios. We welcome your participation in the OpenYurt open-source community through Github[2]. Feel free to share your thoughts at our community weekly meetings[3] or join the community Slack channel[4] for discussions.
[1] Github release: https://github.com/openyurtio/openyurt/releases
[2] Github: https://github.com/openyurtio/openyurt/issues
[3] The Community Weekly Meeting https://us02web.zoom.us/j/82828315928?pwd=SVVxek01T2Z0SVYraktCcDV4RmZlUT09#success
[4] Slack channel: https://openyurt.slack.com/unsupported-geo
The Pressure Test of Prometheus on Alibaba Cloud ECS Service Discovery Feature
Kubernetes Multi-Cluster Management: Empower Your Kubernetes Clusters
175 posts | 31 followers
FollowAlibaba Container Service - November 7, 2024
Alibaba Developer - January 11, 2021
Alibaba Developer - March 3, 2022
Alibaba Developer - January 11, 2021
Alibaba Cloud Native Community - October 13, 2020
Alibaba Clouder - September 17, 2020
175 posts | 31 followers
Follow
Link IoT Edge
Link IoT Edge allows for the management of millions of edge nodes by extending the capabilities of the cloud, thus providing users with services at the nearest location.
Learn More
Function Compute
Alibaba Cloud Function Compute is a fully-managed event-driven compute service. It allows you to focus on writing and uploading code without the need to manage infrastructure such as servers.
Learn More
Elastic High Performance Computing Solution
High Performance Computing (HPC) and AI technology helps scientific research institutions to perform viral gene sequencing, conduct new drug research and development, and shorten the research and development cycle.
Learn More
Quick Starts
Deploy custom Alibaba Cloud solutions for business-critical scenarios with Quick Start templates.
Learn MoreMore Posts by Alibaba Container Service
