-
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
🌱 handle kubeadm 1.24 kubelet ConfigMap name change #6176
🌱 handle kubeadm 1.24 kubelet ConfigMap name change #6176
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.
LGTM, added only a couple of comments
if desiredKubeletConfigMapName == previousMinorVersionKubeletConfigMapName { | ||
return nil | ||
} | ||
|
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.
Q: I know this was like this before but the old ConfigMap is intentionally never deleted, correct?
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.
Yes, in theory the user can create workers with the previous version
Just for my understanding about how KCP works:
Are there some values in the KCP KubeadmConfig that can change and then would be / should be reflected in the kubelet ConfigMap? |
/cherry-pick release-1.1 |
@sbueringer: once the present PR merges, I will cherry-pick it on top of release-1.1 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/test-infra repository. |
2ea191f
to
e594009
Compare
Yes. that's correct
No, given that we allow only to change kubelet flags (via extra args) and they precedence on the content of kubeletConfiguration |
Definitely orthogonal to this PR
I looked at the KubeletConfiguration and I found
I assume this only happens on Just trying to figure out if:
I would expect that there are only a few fields ( Just to confirm another assumption: KubeletConfiguration is uploaded on kubeadm init and then used as config for subsequently joining nodes? And by downloading it and not by Dynamic Kubelet Configuration. |
There is code in kubeadm which takes it from ClusterConfiguration and
sets it in the KubeletConfiguration (code
<https://github.com/kubernetes/kubernetes/blob/c2a8cd359f1f70d364808d800dd995c23a7773ab/cmd/kubeadm/app/componentconfigs/kubelet.go#L147>
)
This kubeadm feature is old. Probably someone requested it as propagation
from the cluster config to the kubelet config, so that they don't have to
explicitly pass a kublet config. kubletconfig on init is also the base
config / global one so this seems a bit redundant to me.
I assume this only happens on kubeadm init and later changes are not
reflected in the KubeletConfiguration ConfigMap (?).
kubeadm upgrade can mutate the kubelet config stored in the cluster if e.g.
secure defaults change (rare). But subsequent joins after init would not
change it.
I assume in this case that's not really relevant as changing the
clusterDomain probably (?) breaks the whole cluster.
Probably breaks it, but who knows what happens? The component maintainers
likely don't know and don't have tests for that. This renders the change
unsupported. If users change it from my understanding they need to restart
all pods on a node, where a kublet is configured with that kubeletconfig.
The kubelet config has a design flaw where it holds both global and
instance specific options. As per the field description the cluster domain
sounds like a global and immutable field and changing it is untested and
unsupported in node local and cluster scenarios.
|
What about moving the orthogonal discussion to an issue? this could quickly cross the line of redesigning the bootstrap API and providing a better abstraction layer on top of kubeadm/bootstrap providers. |
You're right. Just wanted to confirm my impression of the current state is correct. Thx @neolit123 for the additional context. Should this be a part of: #4464? |
e594009
to
9705e43
Compare
/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.
/approve
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: vincepri 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 |
@sbueringer: new pull request created: #6206 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:
This PR makes KCP handle the kubelet ConfigMap as expected by kubeadm >= 1.24
Which issue(s) this PR fixes:
Fixes #5921