-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
✨ Taint nodes with PreferNoSchedule during rollouts #7631
Conversation
Welcome @hiromu-a5a! |
Hi @hiromu-a5a. Thanks for your PR. I'm waiting for a kubernetes-sigs 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. |
/cc @enxebre |
/ok-to-test |
dcfcd40
to
a14517c
Compare
internal/controllers/machinedeployment/machinedeployment_sync.go
Outdated
Show resolved
Hide resolved
This approach is effectively implementing in place propagation of an annotation->taint. If we continue that direction this should be blocked until https://github.com/kubernetes-sigs/cluster-api/blob/main/docs/proposals/20221003-In-place-propagation-of-Kubernetes-objects-only-changes.md is implemented so we can have a clearer path. Alternatively I can see this being built-in business logic as suggested in https://github.com/kubernetes-sigs/cluster-api/pull/7631/files#r1039744048 cc @sbueringer @fabriziopandini thoughts? |
I kind of agree that we should wait for label propagation from machine set to machines to be implemented in the context of the work above. instead, annotation to -> taint is something specific of this PR and it won't be addressed by the work above |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@hiromu-a5a thanks for taking up this issue, this will be super valuable for users!
MD/MS code base is not ideal for first-time contributors, but it seems you are navigating it well; however we should sync with the label propagation effort in order to avoid duplicating/conflicting work
cc @ykakarap who is starting to look into this
This is a really good issue to solve. The node labels proposal is also looking at using taints to solve the problem of workloads getting scheduled to nodes that it should not. I will take a closer look at it in a day or two and see if there are any conflicts and how we can get proceed further. |
|
55aee21
to
d6efe70
Compare
d6efe70
to
b0aca44
Compare
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/retitle ✨ Taint nodes with PreferNoSchedule during rollouts |
@enxebre Yes. I did. |
Changes LGTM /assign @sbueringer |
I'll try to get to this soon |
Tangential discussion, but If we supported API input for taint propagation then MD could use computeDesiredMachineSet to just apply the opinionated taints to old machinesets while reusing already required api calls to perform a rollout. Code changes lgtm. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
/assign @sbueringer
This seems all very reasonable to get in
LGTM label has been added. Git tree hash: 2b1ef82b6213fdd832b79c253676dbe451a90b62
|
Sorry for the delay. Taking a look now |
I will try to get a look as well, it seems a nice change to have |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Skipped reviewing unit tests for now.
Thank you very much for your continued work on this. Mostly smaller findings from my side.
I'll try to review this PR quicker from now on, so we can get it merged soon :)
@hiromu-a5a Do you have time to follow-up on the review comments? |
@hiromu-a5a Do you have time to follow-up? Otherwise we could take over the remaining work. (we would like to get this feature into the next CAPI minor release) |
/close Superseeded by: Kudos to @hiromu-a5a for the awesome work! |
@chrischdi: Closed this PR. In response to this:
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. |
What this PR does / why we need it:
If the MachineSet or MachineDeployment has many replicas, and each node has many pods, changes to an existing MachineDeployment or MachineSet infrastructure template can result in unnecessary pod churn. As the first node is drained, pods previously running on that node may be scheduled onto nodes who have yet to be replaced, but will be torn down soon. This can happen over and over again.
To avoid the above problem, this PR changes the machine controller to add
PreferNoSchedule
taint to nodes in old MachineDeployment. As mentioned in #7043 (comment), tainting should be triggered by MachineDeployment controller. In the MachineDeployment controller, the old MachineSets are given an annotation, then the annotation is propagated from MachineSet to Machines, and finally Machine with the annotation sets taint to Node.This behavior may be related to #493
Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when PR gets merged):Fixes #7043