kubeadm: update docs for removed UpgradeAddonsBeforeControlPlane feat…

…ure gate

Co-authored-by: Lubomir I. Ivanov <[email protected]>

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

@@ -192,37 +192,14 @@ on a control plane node to become ready. The wait process starts right after the
 is started by kubeadm. You are advised to enable this feature gate in case you wish to observe a ready
 state from all control plane components during the `kubeadm init` or `kubeadm join` command execution.
 
-List of deprecated feature gates:
-
-{{< table caption="kubeadm deprecated feature gates" >}}
-Feature | Default
-:-------|:--------
-`UpgradeAddonsBeforeControlPlane` | `false`
-{{< /table >}}
-
-Feature gate descriptions:
-
-`UpgradeAddonsBeforeControlPlane`
-: This is as a **disabled** feature gate that was introduced for Kubernetes v1.28, in order to allow reactivating a legacy
-and deprecated behavior during cluster upgrade. For kubeadm versions prior to v1.28, kubeadm upgrades cluster 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. This may cause compatibility problems. Since v1.28, kubeadm defaults to a mode that
-always checks whether all the control plane instances have been upgraded before starting to upgrade the addons. This behavior
-is applied to both `kubeadm upgrade apply` and `kubeadm upgrade node`. kubeadm determines whether a control plane instance
-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 upgrade is not started until all the
-other control plane instances have been upgraded completely, 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 consider changing your cluster or upgrade processes, as this
-feature gate will be removed in a future release.
-
 List of removed feature gates:
 
 {{< table caption="kubeadm removed feature gates" >}}
 Feature | Alpha | Beta | GA | Removed
 :-------|:------|:-----|:---|:-------
 `IPv6DualStack` | 1.16 | 1.21 | 1.23 | 1.24
 `UnversionedKubeletConfigMap` | 1.22 | 1.23 | 1.25 | 1.26
+`UpgradeAddonsBeforeControlPlane` | 1.28 | - | - | 1.31
 {{< /table >}}
 
 Feature gate descriptions:
@@ -241,6 +218,20 @@ or `kubeadm upgrade apply`), kubeadm respects the value of `UnversionedKubeletCo
 (during `kubeadm join`, `kubeadm reset`, `kubeadm upgrade ...`), kubeadm attempts to use unversioned ConfigMap name first;
 if that does not succeed, kubeadm falls back to using the legacy (versioned) name for that ConfigMap.
 
+`UpgradeAddonsBeforeControlPlane`
+: This is as a **disabled** feature gate that was introduced for Kubernetes v1.28, in order to allow reactivating a legacy
+and deprecated behavior during cluster upgrade. For kubeadm versions prior to v1.28, kubeadm upgrades cluster 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. This may cause compatibility problems. Since v1.28, kubeadm defaults to a mode that
+always checks whether all the control plane instances have been upgraded before starting to upgrade the addons. This behavior
+is applied to both `kubeadm upgrade apply` and `kubeadm upgrade node`. kubeadm determines whether a control plane instance
+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 upgrade is not started until all the
+other control plane instances have been upgraded completely, 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 consider changing your cluster or upgrade processes. 
+This feature gate has been removed since v1.31.
+
 ### Adding kube-proxy parameters {#kube-proxy}
 
 For information about kube-proxy parameters in the kubeadm configuration see:

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

@@ -189,11 +189,7 @@ Pick a control plane node that you wish to upgrade first. It must have the `/etc
    the control plane instances have been upgraded before starting to upgrade the addons. You must perform control plane
    instances upgrade sequentially or at least ensure that the last control plane instance upgrade is not started until all
    the other control plane instances have been upgraded completely, and the addons upgrade will be performed after the last
-   control plane instance is upgraded. If you want to keep the old upgrade behavior, please enable the `UpgradeAddonsBeforeControlPlane`
-   feature gate by `kubeadm upgrade apply --feature-gates=UpgradeAddonsBeforeControlPlane=true`. The Kubernetes project does
-   not in general recommend enabling this feature gate, you should instead change your upgrade process or cluster addons so
-   that you do not need to enable the legacy behavior. The `UpgradeAddonsBeforeControlPlane` feature gate will be removed in
-   a future release.
+   control plane instance is upgraded.
    {{</ note >}}
 
 1. Manually upgrade your CNI provider plugin.