OpenYurt - Extending your native Kubernetes to edge(project under CNCF)
APACHE-2.0 License
Bot releases are visible (Hide)
Support Kubernetes up to V1.28
“k8s.io/xxx” and all its related dependencies are upgraded to version “v0.28.9”, for ensuring OpenYurt is compatible with Kubernetes v1.28 version. This compatibility has been confirmed by an end-to-end (E2E) test where we started a Kubernetes v1.28 cluster using KinD and deployed the latest components of OpenYurt. At the same time, all the key components of OpenYurt, such as yurt-manager and yurthub, are deployed on the Kubernetes cluster via Helm to ensure that the Helm charts provided by the OpenYurt community can run stably in the production environment.
#2047
#2074
Reduce cloud-edge traffic spike during rapid node additions
NodePool
resource is essential for managing groups of nodes within OpenYurt clusters, as it records details of all nodes in the collective through the NodePool.status.nodes
field. YurtHub relies on this information to identify endpoints within the same NodePool, thereby enabling pool-level service topology functionality. However, when a large NodePool—potentially comprising thousands of nodes—experiences swift expansion, such as the integration of hundreds of edge nodes within a mere minute, the surge in cloud-to-edge network traffic can be significant. In this release, a new type of resource called NodeBucket
has been introduced. It provides a scalable and streamlined method for managing extensive NodePool
, significantly reducing the impact on cloud-edge traffic during periods of rapid node growth, and ensuring the stability of the clusters is maintained.
#1864
#1874
#1930
Upgrade YurtAppSet
to v1beta1 version
YurtAppSet v1beta1 is introduced to facilitate the management of multi-region workloads. Users can use YurtAppSet to distribute the same WorkloadTemplate
(Deployment/Statefulset) to different nodepools by a label selector NodePoolSelector
or nodepool name slice (Pools
). Users can also customize the configuration of workloads in different node pools through WorkloadTweaks
.
In this release, we have combined the functionality from the three old crds (YurtAppSet v1alpha1, YurtAppDaemon and YurtAppOverrider) in yurtappset v1beta1. We recommend to use this in favor of the old ones.
#1890
#1931
#1939
#1974
#1997
Improve transparent management mechanism for control traffic from edge to cloud
The current transparent management mechanism for cloud-edge control traffic has certain limitations and cannot effectively support direct requests to the default/kubernetes service. In this release, a new transparent management mechanism for cloud-edge control traffic, aimed at enabling pods using InClusterConfig or the default/kubernetes service name to access the kube-apiserver via YurtHub without needing to be aware of the details of the public network connection between the cloud and edge.
#1975
#1996
Separate clients for yurt-manager component
Yurt-manager is an important component in cloud environment for OpenYurt which holds multiple controllers and webhooks. Those controllers and webhooks shared one client and one set of RBAC (yurt-manager-role/yurt-manager-role-binding/yurt-manager-sa) which grew bigger as we add more function into yurt-manager. This mechanism makes a controller has access it shouldn't has. and it's difficult to find out the request is from which controller from the audit logs. In the latest release, we restrict each controller/webhook to only the permissions it may use and separate RBAC and UA for different controllers and webhooks.
#2051
#2069
Enhancement to Yurthub's Autonomy capabilities
New autonomy condition have been added to node conditions so that yurthub can report autonomy status of node in real time at each nodeStatusUpdateFrequency. This condition allows for accurate determination of each node's autonomy status. In addition, an error key mechanism has been introduced to log cache failure keys along with their corresponding fault reasons. The error keys are persisted using the AOF (Append-Only File) method, ensuring that the autonomy state is recovered even after a reboot and preventing the system from entering a pseudo-autonomous state. These enhancements also facilitate easier troubleshooting when autonomy issues arise.
#2015
#2033
#2096
Thank you to everyone who contributed to this release! ❤
And thank you very much to everyone else not listed here who contributed in other ways like filing issues,
giving feedback, helping users in community group, etc.
Published by rambohe-ch 6 months ago
Full Changelog: https://github.com/openyurtio/openyurt/compare/v1.4.3...v1.4.4
Published by rambohe-ch 6 months ago
Full Changelog: https://github.com/openyurtio/openyurt/compare/v1.4.2...v1.4.3
Published by rambohe-ch 7 months ago
Full Changelog: https://github.com/openyurtio/openyurt/compare/v1.4.1...v1.4.2
Published by rambohe-ch 8 months ago
Full Changelog: https://github.com/openyurtio/openyurt/compare/v1.4.0...v1.4.1
Published by rambohe-ch 12 months ago
Support for HostNetwork Mode NodePool
When the resources of edge nodes are limited and only simple applications need to be run (for instance, situations where container network is not needed and there is no need for communication between applications),
using a HostNetwork mode nodepool is a reasonable choice. When creating a nodepool, users only need to set spec.HostNetwork=true to create a HostNetwork mode nodepool.
In this mode, only some essential components such as kubelet, yurthub and raven-agent will be installed on all nodes in the pool. In addition, Pods scheduled on these nodes will automatically adopt host network mode.
This method effectively reduces resource consumption while maintaining application performance efficiency.
Support for customized configuration at the nodepool level for multi-region workloads
YurtAppOverrider is a new CRD used to customize the configuration of the workloads managed by YurtAppSet/YurtAppDaemon. It provides a simple and straightforward way to configure every field of the workload under each nodepool.
It is fundamental component of multi-region workloads configuration rendering engine.
Support for building edgex iot systems by using PlatformAdmin
PlatformAdmin is a CRD that manages the IoT systems in the OpenYurt nodepool. It has evolved from the previous yurt-edgex-manager. Starting from this version, the functionality of yurt-edgex-controller has been merged into yurt-manager. This means that users no longer need to deploy any additional components; they only need to install yurt-manager to have all the capabilities for managing edge devices.
PlatformAdmin allows users with a user-friendly way to deploy a complete edgex system on nodepool. It comes with an optional component library and configuration templates. Advanced users can also customize the configuration of this system according to their needs.
Currently, PlatformAdmin supports all versions of EdgeX from Hanoi to Minnesota. In the future, it will continue to rapidly support upcoming releases using the auto-collector feature. This ensures that PlatformAdmin remains compatible with the latest versions of EdgeX as they are released.
Supports yurt-iot-dock deployment as an iot system component
yurt-iot-dock is a component responsible for managing edge devices in IoT system. It has evolved from the previous yurt-device-controller. As a component that connects the cloud and edge device management platforms, yurt-iot-dock abstracts three CRDs: DeviceProfile, DeviceService, and Device. These CRDs are used to represent and manage corresponding resources on the device management platform, thereby impacting real-world devices.
By declaratively modifying the fields of these CRs, users can achieve the operational and management goals of complex edge devices in a cloud-native manner. yurt-iot-dock is deployed by PlatformAdmin as an optional IoT component. It is responsible for device synchronization during startup and severs the synchronization relationship when being terminated or destroyed.
In this version, the deployment and destruction of the yurt-iot-dock are all controlled by PlatformAdmin, which improves the ease of use of the yurt-iot-dock.
Some Repos are archived
With the upgrading of OpenYurt architecture, the functions of quite a few components are merged into Yurt-Manager (e.g. yurt-app-manager, raven-controller-manager, etc.),
or there are repos migrated to openyurt for better management (e.g. yurtiotdock). The following repos have been archived:
yurthub/yurthub
by @luc99hen in https://github.com/openyurtio/openyurt/pull/1693
Thank you to everyone who contributed to this release! ❤
And thank you very much to everyone else not listed here who contributed in other ways like filing issues,
giving feedback, helping users in community group, etc.
Published by rambohe-ch over 1 year ago
Full Changelog: https://github.com/openyurtio/openyurt/compare/v1.2.1...v1.2.2
Published by rambohe-ch over 1 year ago
Full Changelog: https://github.com/openyurtio/openyurt/compare/v1.1.0...v1.1.1
Published by rambohe-ch over 1 year ago
Full Changelog: https://github.com/openyurtio/openyurt/compare/v1.0.1...v1.0.2
Published by rambohe-ch over 1 year ago
Full Changelog: https://github.com/openyurtio/openyurt/compare/v1.3.3...v1.3.4
Published by rambohe-ch over 1 year ago
Full Changelog: https://github.com/openyurtio/openyurt/compare/v1.3.2...v1.3.3
Published by rambohe-ch over 1 year ago
Full Changelog: https://github.com/openyurtio/openyurt/compare/v1.3.1...v1.3.2
Published by rambohe-ch over 1 year ago
Full Changelog: https://github.com/openyurtio/openyurt/compare/v1.3.0...v1.3.1
Published by rambohe-ch over 1 year ago
Refactor OpenYurt control plane components
In order to improve the management of all repos in OpenYurt community, and reduce the complexity of installing OpenYurt,
After detailed discussions in the community, a new component named yurt-manager was agreed to manage controllers and webhooks
scattered across multiple components (like yurt-controller-manager, yurt-app-manager, raven-controller-manager, etc.).
After the refactoring, based on the controller-runtime framework, new controllers and webhooks can be easily added to the
yurt-manager component in the future. Also note that the yurt-manager component is recommended to be installed on the same node as the K8s control-plane component (like kube-controller-manager). #1067
Support OTA or AdvancedRollingUpdate upgrade models for static pods
As you know, static pods are managed directly by the kubelet daemon on the node and there is no APIServer watching them.
In general, if a user wants to upgrade a static pod(like YurtHub), the user should manually modify or replace the manifest
of the static pod. this can be a very tedious and painful task when the number of static pods becomes very large.
Users can define Pod templates and upgrade models through YurtStaticSet CRD. The upgrade models support both OTA and AdvancedRollingUpdate kinds,
thus easily meeting the upgrade needs of large-scale Static Pods. Also the Pod template in yurthub YurtStaticSet CRD is used to
install YurtHub component on the node when the node is joined. #1261, #1168, #1172
NodePort Service supports nodepool isolation
In edge scenarios, users using the NodePort service expect to listen to nodePort ports only in a specified nodepools
in order to prevent port conflicts and save edge resources.
Users can specify the nodepools to listen to by adding annotation nodeport.openyurt.io/listen
to the NodePort or
LoadBalancer service, thus getting the nodepool isolation capability of the NodePort or LoadBalancer service. #1183, #1209
Thank you to everyone who contributed to this release! ❤
And thank you very much to everyone else not listed here who contributed in other ways like filing issues,
giving feedback, helping users in community group, etc.
Full Changelog: https://github.com/openyurtio/openyurt/compare/v1.2.0...v1.3.0
Published by rambohe-ch over 1 year ago
The release candidate for OpenYurt v1.3.0
Published by rambohe-ch over 1 year ago
Full Changelog: https://github.com/openyurtio/openyurt/compare/v1.2.0...v1.2.1
Published by rambohe-ch over 1 year ago
Improve edge autonomy capability when cloud-edge network off
The original edge autonomy feature can make the pods on nodes un-evicted even if node crashed by adding annotation to node,
and this feature is recommended to use for scenarios that pods should bind to node without recreation.
After improving edge autonomy capability, when the reason of node NotReady is cloud-edge network off, pods will not be evicted
because leader yurthub will help these offline nodes to proxy their heartbeats to the cloud via pool-coordinator component,
and pods will be evicted and recreated on other ready node if node crashed.
By the way, The original edge autonomy capability by annotating node (with node.beta.openyurt.io/autonomy) will be kept as it is,
which will influence all pods on autonomy nodes. And a new annotation (named apps.openyurt.io/binding) can be added to workload to
enable the original edge autonomy capability for specified pod.
Reduce the control-plane traffic between cloud and edge
Based on the Pool-Coordinator in the nodePool, A leader Yurthub will be elected in the nodePool. Leader Yurthub will
list/watch pool-scope data(like endpoints/endpointslices) from cloud and write into pool-coordinator. then all components(like kube-proxy/coredns)
in the nodePool will get pool-scope data from pool-coordinator instead of cloud kube-apiserver, so large volume control-plane traffic
will be reduced.
Use raven component to replace yurt-tunnel component
Raven has released version v0.3, and provide cross-regional network communication ability based on PodIP or NodeIP, but yurt-tunnel
can only provide cloud-edge requests forwarding for kubectl logs/exec commands. because raven provides much more than the capabilities
provided by yurt-tunnel, and raven has been proven by a lot of work. so raven component is officially recommended to replace yurt-tunnel.
Thank you to everyone who contributed to this release! ❤
And thank you very much to everyone else not listed here who contributed in other ways like filing issues,
giving feedback, helping users in community group, etc.
Published by rambohe-ch almost 2 years ago
Support OTA/Auto upgrade model for DaemonSet workload
Extend native DaemonSet OnDelete
upgrade model by providing OTA and Auto two upgrade models.
Support autonomy feature validation in e2e tests
In order to test autonomy feature, network interface of control-plane is disconnected for simulating cloud-edge network disconnected, and then stop components(like kube-proxy, flannel, coredns, etc.) and check the recovery of these components.
Improve the Yurthub configuration for enabling the data filter function
Compares to the previous three configuration items, which include the component name, resource, and request verb. after improvement, only component name is need to configure for enabling data filter function. the original configuration format is also supported in order to keep consistency.
Thank you to everyone who contributed to this release! ❤
And thank you very much to everyone else not listed here who contributed in other ways like filing issues, giving feedback, helping users in community group, etc. ️
Full Changelog: https://github.com/openyurtio/openyurt/compare/v1.0.0...v1.1.0
Published by rambohe-ch about 2 years ago
Full Changelog: https://github.com/openyurtio/openyurt/compare/v1.0.0...v1.0.1
Published by rambohe-ch about 2 years ago
We're excited to announce the release of OpenYurt 1.0.0!🎉🎉🎉
Thanks to all the new and existing contributors who helped make this release happen!
If you're new to OpenYurt, feel free to browse OpenYurt website, then start with OpenYurt Installation and learn about its core concepts.
Nearly 20 people have contributed to this release and 8 of them are new contributors, Thanks to everyone!
@huiwq1990 @Congrool @zhangzhenyuyu @rambohe-ch @gnunu @LinFCai @guoguodan @ankyit @luckymrwang @zzguang @hxcGit @Sodawyx @luc99hen @River-sh @slm940208 @windydayc @lorrielau @fujitatomoya @donychen1134
The version of NodePool
API has been upgraded to v1beta1
, more details in the https://github.com/openyurtio/yurt-app-manager/pull/104
Meanwhile, all APIs management in OpenYurt will be migrated to openyurtio/api repo, and we recommend you to import this package to use APIs of OpenYurt.
We track unit test coverage with CodeCov
Code coverage for some repos as following:
and more details of unit tests coverage can be found in https://codecov.io/gh/openyurtio
In addition to unit tests, other levels of testing are also added.
OpenYurt makes Kubernetes work in cloud-edge collaborative environment with a non-intrusive design. so performance of
some OpenYurt components have been considered carefully. several test reports have been submitted so that end users can clearly
see the working status of OpenYurt components.
early installation way(convert K8s to OpenYurt) is removed. OpenYurt Cluster installation is divided into two parts:
and all Control Plane Components of OpenYurt are managed by helm charts in repo: https://github.com/openyurtio/openyurt-helm
Full Changelog: https://github.com/openyurtio/openyurt/compare/v0.7.0...v1.0.0-rc1
Thanks again to all the contributors!