-
Notifications
You must be signed in to change notification settings - Fork 38.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Exclude nodes from rolling update depending on tolerations #119317
Exclude nodes from rolling update depending on tolerations #119317
Conversation
Hi @mochizuki875. Thanks for your PR. I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/sig apps |
/ok-to-test |
a1591b7
to
f5647d7
Compare
f113af4
to
decc495
Compare
/retest |
/retest |
1 similar comment
/retest |
/test pull-kubernetes-e2e-gce |
/retest |
1 similar comment
/retest |
@mochizuki875 would you mind cherry-picking this into 1.28, 1.27, 1.26 ,1.25? We have promoted the maxSurge feature to GA in 1.25 so it would be great to get the backports into all of these versions (#111194). |
@atiratree |
thanks! |
@atiratree |
thanks, let's wait for the tests and then we can tag them |
…-#119317-upstream-release-1.26 Automated cherry pick of #119317: change rolling update logic to exclude sunsetting nodes
…-#119317-upstream-release-1.28 Automated cherry pick of #119317: change rolling update logic to exclude sunsetting nodes
…-#119317-upstream-release-1.27 Automated cherry pick of #119317: change rolling update logic to exclude sunsetting nodes
…-#119317-upstream-release-1.25 Automated cherry pick of #119317: change rolling update logic to exclude sunsetting nodes
Changelog suggestion Revised the logic for DaemonSet rolling update to exclude nodes if scheduling constraints are not met.
This eliminates the problem of rolling updates to a DaemonSet getting stuck around tolerations. Further polish is welcome; I don't think I really understand the effect of the change from the current changelog entry. |
@sftim I'm picking your suggestion for the |
@sftim |
What type of PR is this?
/kind bug
What this PR does / why we need it:
In this PR, exclude
Nodes
from daemon pod updating if thetolerations
of it dose not match thetaints
ofNodes
.It will cause update stuck if we try to rolling update
DaemonSet
which has non zeromaxSurge
and dose not havetolerations
matchingNodes
taints
.It's because all
Nodes
runningPods
belonging to the previousDaemonSet
are included in the update, regardless of thetolerations
of the newDaemonSet
.Which issue(s) this PR fixes:
Fixes #118823
Special notes for your reviewer:
Does this PR introduce a user-facing change?
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: