-
Notifications
You must be signed in to change notification settings - Fork 14.5k
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
kubeadm: add docs for UpgradeAddonsBeforeControlPlane feature gate #41606
kubeadm: add docs for UpgradeAddonsBeforeControlPlane feature gate #41606
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.
/sig cluster-lifecycle
some minor nits but, lgtm
thanks
should be for the dev-1.28 branch instead |
54a51ec
to
9c3c6bf
Compare
✅ Pull request preview available for checkingBuilt without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify site settings. |
content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md
Outdated
Show resolved
Hide resolved
Before v1.27 (including v1.27), kubeadm will upgrade the addons (including CoreDNS and kube-proxy) immediately during | ||
`kubeadm upgrade apply`, regardless of whether there are other control plane instances that have not been upgraded, which | ||
may cause compatibility problems. Since v1.28, kubeadm will always checks whether all the control plane instances have | ||
been upgraded before starting to upgrade the addons. You **MUST** perform control plane nodes upgrade sequentially, and |
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: don't remember if i asked this. some users are known to not follow this rule today and they try to do parallel cp upgrades. will the logic we added in 1.28 support them or there are no guarantees - i.e. undefined behavior?
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.
@neolit123 Because the check is only performed during kubeadm upgrade apply/node
, when the control plane nodes are upgrading in parallel, there may be a race that all the kubeadm upgrade processes assume that there are unupgraded control plane instances, this will cause the addons to miss performing the upgrade. Complete serial execution is not required, but in order to ensure that the addons can be successfully upgraded during the last cp node upgrade, users should ensure that all the other cp nodes have been upgraded before doing the last cp node upgrade. In the future, we can add a new separate phase and call it after all the cp nodes have been upgraded, such as kubeadm upgrade addons
. Then gradually deprecate upgrading addons during the upgrade apply/node
phase. But this will change the upgrade workflow and may take a long time.
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.
If parallel cp upgrade is necessary, the user needs to make additional checks to see if the addons have been successfully upgraded or always to call kubeadm upgrade node
or kubeadm upgrade addons
(in the future) on the last cp node again to ensure that the addons can be upgraded successfully. This should be safe because the upgrade operation is idempotent.
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.
thanks for the clarification.
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.
Hi. Here's how I'd change this - what do you think @SataQiu ?
content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md
Outdated
Show resolved
Hide resolved
content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md
Outdated
Show resolved
Hide resolved
content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md
Outdated
Show resolved
Hide resolved
9c3c6bf
to
c43c101
Compare
thanks @sftim @neolit123 PTAL again! |
c43c101
to
fe98320
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
LGTM label has been added. Git tree hash: 2829a9f7314fa1cd5e424518e595d7a4fd6c46a6
|
hi @tengqm |
@@ -160,6 +160,7 @@ Feature | Default | Alpha | Beta | GA | |||
`PublicKeysECDSA` | `false` | 1.19 | - | - | |||
`RootlessControlPlane` | `false` | 1.22 | - | - | |||
`UnversionedKubeletConfigMap` | `true` | 1.22 | 1.23 | 1.25 | |||
`UpgradeAddonsBeforeControlPlane` | `false` | - | - | - |
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.
Is this alpha, or beta?
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.
Thanks @tengqm
Sorry for the late reply.
It isn't a new feature, it's more like a bugfix. So this feature gate has been marked deprecated since it was created.
So it's not in Alpha stage, and will never be Beta or GA.
For more context: kubernetes/kubernetes#116570 (comment)
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.
In that case, we should document this in the second table (gates for GA'ed or deprecated feature).
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.
Updated
instances upgrade sequentially or at least ensure that the last control plane instance is upgraded after all the other control | ||
plane instances have been upgraded, and the addons upgrade will be performed after the last control plane instance is upgraded. |
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.
Ensure "that the last control plane instance is upgraded after all the other control
plane instances have been upgraded" ...
This is so verbose. Does this mean that we need to ensure all control plane instances are properly upgraded?
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.
This is because the control plane node upgrade needs to ensure the sequence. In a HA cluster, the upgrade of the last control plane node cannot be performed until all the other control plane nodes have been upgraded successfully.
has been upgraded by checking whether the image of the kube-apiserver Pod has been upgraded. You **MUST** perform control plane | ||
instances upgrade sequentially or at least ensure that the last control plane instance is upgraded after all the other control | ||
plane instances have been upgraded, and the addons upgrade will be performed after the last control plane instance is upgraded. | ||
The deprecated `UpgradeAddonsBeforeControlPlane` feature gate gives you a chance to keep the old upgrade behavior. You should not |
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.
Is the gate defaulted to true or false?
It is introduced as a deprecated feature, right?
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, the deprecated feature gate is defaulted to false.
instances upgrade sequentially or at least ensure that the last control plane instance is upgraded after all the other control | ||
plane instances have been upgraded, and the addons upgrade will be performed after the last control plane instance is upgraded. | ||
The deprecated `UpgradeAddonsBeforeControlPlane` feature gate gives you a chance to keep the old upgrade behavior. You should not | ||
need this old behavior; if you do, you should change your cluster or upgrade processes but please do not rely on it, as this |
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.
"please do not rely on it" ...
What does this "it" refer to?
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.
"it" means the UpgradeAddonsBeforeControlPlane
feature gate.
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.
"please do not rely on it" has been removed now
fe98320
to
d5a2a69
Compare
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: tengqm 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 |
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
LGTM label has been added. Git tree hash: 1c39610de7f763532d027aefd8c517204bb076d6
|
kubeadm: add docs for UpgradeAddonsBeforeControlPlane feature gate
Ref kubernetes/kubeadm#2346