-
Notifications
You must be signed in to change notification settings - Fork 527
[GEP-31] Adapt OperatingSystemConfig
reconciler and extension to populate fields related to in-place update
#11393
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
[GEP-31] Adapt OperatingSystemConfig
reconciler and extension to populate fields related to in-place update
#11393
Conversation
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.
Along the way, we felt that it'd be better to populate the OSC with the relevant fields of kubelet config instead of just a hash.
This is required to execute some special steps in case of some kubelet config changes, eg: https://kubernetes.io/docs/tasks/administer-cluster/cpu-management-policies/#changing-the-cpu-manager-policy
Please elaborate. Which kind of special steps do you talk about/would be relevant to the OSC controllers/node-agent?
pkg/component/extensions/operatingsystemconfig/original/components/kubelet_test.go
Outdated
Show resolved
Hide resolved
pkg/component/extensions/operatingsystemconfig/original/components/kubelet_test.go
Outdated
Show resolved
Hide resolved
In case of CPU Manager policy change, just draining and restarting the kubelet isn't enough, we need to remove the |
Can't we parse the kubelet config file from the OSC instead of duplicating some values in the OSC spec? |
We did consider this, but there are some challenges with this, the config file in the node is applied after some defaulting here, gardener/pkg/component/extensions/operatingsystemconfig/original/components/kubelet/config.go Lines 171 to 267 in ea892e5
So in case if the Shoot spec is some but the default is changed here for some reason (ideally, we wouldn't), node-agent would detect it as an in-place update and wait for the Node to be ready. I agree this would also happen today, if some defaults are changed here, that would not roll the nodes since the hash doesn't change. Should we add a comment here about this and go on with reading the config file approach? |
I see. Given that this also happens with rolling update strategy as of today, perhaps it's better to address this concern (if it is one) separately out of the scope of GEP-31? |
Today, with rolling, even if the defaulting changes, the config file is applied, and kubelet is restarted (It can have other side affects since there is no drain), but the action is not blocking as such. |
Opened #11416 |
/retest |
a33445a
to
0a1eb18
Compare
/retest |
Co-Authored-By: Ashish Ranjan Yadav <ashish.ranjan.yadav@sap.com> Co-Authored-By: Sonu Kumar Singh <sonu.kumar.singh02@sap.com>
Co-Authored-By: Ashish Ranjan Yadav <ashish.ranjan.yadav@sap.com> Co-Authored-By: Sonu Kumar Singh <sonu.kumar.singh02@sap.com>
Co-Authored-By: Ashish Ranjan Yadav <ashish.ranjan.yadav@sap.com> Co-Authored-By: Sonu Kumar Singh <sonu.kumar.singh02@sap.com>
Co-Authored-By: Ashish Ranjan Yadav <ashish.ranjan.yadav@sap.com> Co-Authored-By: Sonu Kumar Singh <sonu.kumar.singh02@sap.com>
Co-Authored-By: Ashish Ranjan Yadav <ashish.ranjan.yadav@sap.com> Co-Authored-By: Sonu Kumar Singh <sonu.kumar.singh02@sap.com>
NB: Hide whitespaces for this commit Co-Authored-By: Ashish Ranjan Yadav <ashish.ranjan.yadav@sap.com> Co-Authored-By: Sonu Kumar Singh <sonu.kumar.singh02@sap.com>
0a1eb18
to
52d7e1d
Compare
8247d42
to
4f3e783
Compare
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
/approve
LGTM label has been added. Git tree hash: 28da5b9f0c802eae78fc3835621231837fa177de
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: rfranzke The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/cherry-pick release-v1.113 |
@plkokanov: once the present PR merges, I will cherry-pick it on top of release-v1.113 in a new PR and assign it to you. 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-sigs/prow repository. |
/test pull-gardener-e2e-kind-ha-multi-zone |
@plkokanov: new pull request created: #11488 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-sigs/prow repository. |
Co-Authored-By: Ashish Ranjan Yadav ashish.ranjan.yadav@sap.com
Co-Authored-By: Sonu Kumar Singh sonu.kumar.singh02@sap.com
How to categorize this PR?
/kind enhancement
What this PR does / why we need it:
This PR prepares the OSC extension deployment and the OSC reconciler to populate fields necessary for in-place update in the OSC spec and status. Once released, we can vendor the OS extensions with this version.
These fields are only populated if the update strategy is in-place.
Along the way, we felt that it'd be better to populate the OSC with the relevant fields of kubelet config instead of just a hash.
This is required to execute some special steps in case of some kubelet config changes, eg: https://kubernetes.io/docs/tasks/administer-cluster/cpu-management-policies/#changing-the-cpu-manager-policy
And since the
InPlaceUpdates
is not present for Rolling update, let's make it a separate struct in the OSC with in-place related config.Which issue(s) this PR fixes:
Part of #10219
Special notes for your reviewer:
/cc @acumino @ary1992
Release note: