The Kubernetes project maintains release branches for the most recent three minor releases.

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 a regular cadence, or as needed.
This decision is owned by the patch release manager.
The patch release manager is a member of the release team for each release.

Minor releases occur approximately every 3 months, so each minor release branch is maintained for approximately 9 months.

kubelet

kubelet must not be newer than kube-apiserver, and may be up to two minor versions older.

Example:

kube-apiserver is at 1.13

kubelet is supported at 1.13, 1.12, and 1.11

Note: If version skew exists between kube-apiserver instances in an HA cluster, this narrows the allowed kubelet versions.

Example:

kube-apiserver instances are at 1.13 and 1.12

kubelet is supported at 1.12, and 1.11 (1.13 is not supported because that would be newer than the kube-apiserver instance at version 1.12)

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

kube-controller-manager, kube-scheduler, and cloud-controller-manager must not be newer than the kube-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:

kube-apiserver is at 1.13

kube-controller-manager, kube-scheduler, and cloud-controller-manager are supported at 1.13 and 1.12

Note: If version skew exists between kube-apiserver instances in an HA cluster, and these components can communicate with any kube-apiserver instance in the cluster (for example, via a load balancer), this narrows the allowed versions of these components.

Example:

kube-apiserver instances are at 1.13 and 1.12

kube-controller-manager, kube-scheduler, and cloud-controller-manager communicate with a load balancer that can route to any kube-apiserver instance

kube-controller-manager, kube-scheduler, and cloud-controller-manager are supported at 1.12 (1.13 is not supported because that would be newer than the kube-apiserver instance at version 1.12)

kubectl

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

Example:

kube-apiserver is at 1.13

kubectl is supported at 1.14, 1.13, and 1.12

Note: If version skew exists between kube-apiserver instances in an HA cluster, this narrows the supported kubectl versions.

Example:

kube-apiserver instances are at 1.13 and 1.12

kubectl is supported at 1.13 and 1.12 (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 1.n to version 1.(n+1).

kube-apiserver

Pre-requisites:

In a single-instance cluster, the existing kube-apiserver instance is 1.n

In an HA cluster, all kube-apiserver instances are at 1.n or 1.(n+1) (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 1.n (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 1.n or 1.(n-1) (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 1.(n+1)

The webhooks are able to handle any new versions of REST resources that will be sent to them, and any new fields added to existing versions in 1.(n+1)

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

Pre-requisites:

The kube-apiserver instances these components communicate with are at 1.(n+1) (in HA clusters in which these control plane components can communicate with any kube-apiserver instance in the cluster, all kube-apiserver instances must be upgraded before upgrading these components)