search

openyurtio / raven

provide layer 3 and layer 7 network connectivity among pods in different physical regions
Apache License 2.0
57 stars 37 forks source link

Build(deps): bump github.com/openyurtio/openyurt from 1.2.1-0.20230320014349-7cc573e1d097 to 1.3.0 #112

Closed dependabot[bot] closed 1 year ago

dependabot[bot] commented 1 year ago

Bumps github.com/openyurtio/openyurt from 1.2.1-0.20230320014349-7cc573e1d097 to 1.3.0.

Release notes

Sourced from github.com/openyurtio/openyurt's releases.

v1.3.0

What's New

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

Other Notable changes

... (truncated)

Changelog

Sourced from github.com/openyurtio/openyurt's changelog.

v1.3.0

What's New

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 must 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 YurtAppSet 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

Other Notable changes

... (truncated)

Commits


Dependabot compatibility score

You can trigger a rebase of this PR by commenting @dependabot rebase.

Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
dependabot[bot] commented 1 year ago

The following labels could not be found: kind/enhancement, release-note/misc.

codecov[bot] commented 1 year ago

Codecov Report

Merging #112 (102b86e) into main (e1e8075) will not change coverage. The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #112   +/-   ##
=======================================
  Coverage   43.25%   43.25%           
=======================================
  Files           7        7           
  Lines        1031     1031           
=======================================
  Hits          446      446           
  Misses        501      501           
  Partials       84       84
Flag Coverage Δ
unittests 43.25% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.