Version Skew Policy (original) (raw)

The maximum version skew supported between various Kubernetes components.

This document describes the maximum version skew supported between various Kubernetes components. Specific cluster deployment tools may place additional restrictions on version skew.

Supported versions

Kubernetes versions are expressed as x.y.z, where x is the major version,y is the minor version, and z is the patch version, followingSemantic Versioning terminology. For more information, seeKubernetes Release Versioning.

The Kubernetes project maintains release branches for the most recent three minor releases (1.33, 1.32, 1.31). Kubernetes 1.19 and newer receive approximately 1 year of patch support. Kubernetes 1.18 and older received approximately 9 months of patch support.

Applicable fixes, including security fixes, may be backported to those three release branches, depending on severity and feasibility. Patch releases are cut from those branches at aregular cadence, plus additional urgent releases, when required.

The Release Managers group owns this decision.

For more information, see the Kubernetes patch releases page.

Supported version skew

kube-apiserver

In highly-available (HA) clusters, the newest and oldest kube-apiserver instances must be within one minor version.

Example:

kubelet

Example:

Example:

kube-proxy

Example:

Example:

kube-controller-manager, kube-scheduler, and cloud-controller-manager

kube-controller-manager, kube-scheduler, and cloud-controller-manager must not be newer than thekube-apiserver instances they communicate with. They are expected to match the kube-apiserver minor version, but may be up to one minor version older (to allow live upgrades).

Example:

Example:

kubectl

kubectl is supported within one minor version (older or newer) of kube-apiserver.

Example:

Example:

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 version1.32 to version 1.33.

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:

For example, if you're running version 1.32, ensure that you're on the most recent patch version. Then, upgrade to the most recent patch version of 1.33.

kube-apiserver

Pre-requisites:

Upgrade kube-apiserver to 1.33

kube-controller-manager, kube-scheduler, and cloud-controller-manager

Pre-requisites:

Upgrade kube-controller-manager, kube-scheduler, andcloud-controller-manager to 1.33. There is no required upgrade order between kube-controller-manager, kube-scheduler, andcloud-controller-manager. You can upgrade these components in any order, or even simultaneously.

kubelet

Pre-requisites:

Optionally upgrade kubelet instances to 1.33 (or they can be left at1.32, 1.31, or 1.30)

kube-proxy

Pre-requisites:

Optionally upgrade kube-proxy instances to 1.33(or they can be left at 1.32, 1.31, or 1.30)