Skip to content

Commit d5a2a69

Browse files
committed
kubeadm: add docs for UpgradeAddonsBeforeControlPlane feature gate
1 parent 884bf0b commit d5a2a69

File tree

2 files changed

+38
-0
lines changed

2 files changed

+38
-0
lines changed

content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md

+24
Original file line numberDiff line numberDiff line change
@@ -189,6 +189,30 @@ or `kubeadm upgrade apply`), kubeadm respects the value of `UnversionedKubeletCo
189189
(during `kubeadm join`, `kubeadm reset`, `kubeadm upgrade ...`), kubeadm attempts to use unversioned ConfigMap name first;
190190
if that does not succeed, kubeadm falls back to using the legacy (versioned) name for that ConfigMap.
191191

192+
List of deprecated feature gates:
193+
194+
{{< table caption="kubeadm deprecated feature gates" >}}
195+
Feature | Default
196+
:-------|:--------
197+
`UpgradeAddonsBeforeControlPlane` | `false`
198+
{{< /table >}}
199+
200+
Feature gate descriptions:
201+
202+
`UpgradeAddonsBeforeControlPlane`
203+
: This is as a **disabled** feature gate that was introduced for Kubernetes v1.28, in order to allow reactivating a legacy
204+
and deprecated behavior during cluster upgrade. For kubeadm versions prior to v1.28, kubeadm upgrades cluster addons (including
205+
CoreDNS and kube-proxy) immediately during `kubeadm upgrade apply`, regardless of whether there are other control plane
206+
instances that have not been upgraded. This may cause compatibility problems. Since v1.28, kubeadm defaults to a mode that
207+
always checks whether all the control plane instances have been upgraded before starting to upgrade the addons. This behavior
208+
is applied to both `kubeadm upgrade apply` and `kubeadm upgrade node`. kubeadm determines whether a control plane instance
209+
has been upgraded by checking whether the image of the kube-apiserver Pod has been upgraded. You must perform control plane
210+
instances upgrade sequentially or at least ensure that the last control plane instance upgrade is not started until all the
211+
other control plane instances have been upgraded completely, and the addons upgrade will be performed after the last control plane
212+
instance is upgraded. The deprecated `UpgradeAddonsBeforeControlPlane` feature gate gives you a chance to keep the old upgrade
213+
behavior. You should not need this old behavior; if you do, you should consider changing your cluster or upgrade processes, as this
214+
feature gate will be removed in a future release.
215+
192216
### Adding kube-proxy parameters {#kube-proxy}
193217

194218
For information about kube-proxy parameters in the kubeadm configuration see:

content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md

+14
Original file line numberDiff line numberDiff line change
@@ -152,6 +152,20 @@ Pick a control plane node that you wish to upgrade first. It must have the `/etc
152152
[upgrade/kubelet] Now that your control plane is upgraded, please proceed with upgrading your kubelets if you haven't already done so.
153153
```
154154

155+
{{< note >}}
156+
For versions earlier than v1.28, kubeadm defaulted to a mode that upgrades the addons (including CoreDNS and kube-proxy)
157+
immediately during `kubeadm upgrade apply`, regardless of whether there are other control plane instances that have not
158+
been upgraded. This may cause compatibility problems. Since v1.28, kubeadm defaults to a mode that checks whether all
159+
the control plane instances have been upgraded before starting to upgrade the addons. You must perform control plane
160+
instances upgrade sequentially or at least ensure that the last control plane instance upgrade is not started until all
161+
the other control plane instances have been upgraded completely, and the addons upgrade will be performed after the last
162+
control plane instance is upgraded. If you want to keep the old upgrade behavior, please enable the `UpgradeAddonsBeforeControlPlane`
163+
feature gate by `kubeadm upgrade apply --feature-gates=UpgradeAddonsBeforeControlPlane=true`. The Kubernetes project does
164+
not in general recommend enabling this feature gate, you should instead change your upgrade process or cluster addons so
165+
that you do not need to enable the legacy behavior. The `UpgradeAddonsBeforeControlPlane` feature gate will be removed in
166+
a future release.
167+
{{</ note >}}
168+
155169
1. Manually upgrade your CNI provider plugin.
156170

157171
Your Container Network Interface (CNI) provider may have its own upgrade instructions to follow.

0 commit comments

Comments
 (0)