kubectl Version Skew and Component Upgrade Order for kube-apiserver

### kubectl `kubectl` is supported within one minor version (older or newer) of `kube-apiserver`. Example: * `kube-apiserver` is at **{{< skew currentVersion >}}** * `kubectl` is supported at **{{< skew currentVersionAddMinor 1 >}}**, **{{< skew currentVersion >}}**, and **{{< skew currentVersionAddMinor -1 >}}** {{< note >}} If version skew exists between `kube-apiserver` instances in an HA cluster, this narrows the supported `kubectl` versions. {{< /note >}} Example: * `kube-apiserver` instances are at **{{< skew currentVersion >}}** and **{{< skew currentVersionAddMinor -1 >}}** * `kubectl` is supported at **{{< skew currentVersion >}}** and **{{< skew currentVersionAddMinor -1 >}}** (other versions would be more than one minor version skewed from one of the `kube-apiserver` components) ## Supported component upgrade order The supported version skew between components has implications on the order in which components must be upgraded. This section describes the order in which components must be upgraded to transition an existing cluster from version **{{< skew currentVersionAddMinor -1 >}}** to version **{{< skew currentVersion >}}**. Optionally, when preparing to upgrade, the Kubernetes project recommends that you do the following to benefit from as many regression and bug fixes as possible during your upgrade: * Ensure that components are on the most recent patch version of your current minor version. * Upgrade components to the most recent patch version of the target minor version. For example, if you're running version {{<skew currentVersionAddMinor -1>}}, ensure that you're on the most recent patch version. Then, upgrade to the most recent patch version of {{<skew currentVersion>}}. ### kube-apiserver Pre-requisites: * In a single-instance cluster, the existing `kube-apiserver` instance is **{{< skew currentVersionAddMinor -1 >}}** * In an HA cluster, all `kube-apiserver` instances are at **{{< skew currentVersionAddMinor -1 >}}** or **{{< skew currentVersion >}}** (this ensures maximum skew of 1 minor version between the oldest and newest `kube-apiserver` instance) * The `kube-controller-manager`, `kube-scheduler`, and `cloud-controller-manager` instances that communicate with this server are at version **{{< skew currentVersionAddMinor -1 >}}** (this ensures they are not newer than the existing API server version, and are within 1 minor version of the new API server version) * `kubelet` instances on all nodes are at version **{{< skew currentVersionAddMinor -1 >}}** or **{{< skew currentVersionAddMinor -2 >}}** (this ensures they are not newer than the existing API server version, and are within 2 minor versions of the new API server version) * Registered admission webhooks are able to handle the data the new `kube-apiserver` instance will send them: * `ValidatingWebhookConfiguration` and `MutatingWebhookConfiguration` objects are updated to include any new versions of REST resources added in **{{< skew currentVersion >}}**

This section outlines the supported version skew for kubectl in relation to kube-apiserver, allowing for one minor version difference (older or newer). It also details the recommended component upgrade order when transitioning a cluster from version {{< skew currentVersionAddMinor -1 >}} to {{< skew currentVersion >}}, focusing on pre-requisites for upgrading kube-apiserver, including ensuring compatible versions of kube-controller-manager, kube-scheduler, cloud-controller-manager, and kubelet instances, as well as preparing registered admission webhooks for new REST resources.