Version skew: which components may differ
A cluster rarely runs one version everywhere. The official skew policy says how far each component may be from kube-apiserver. Pick your API server version:
The rules
| Component | Allowed versions, relative to kube-apiserver |
|---|---|
| kube-apiserver (HA) | Newest and oldest instances within one minor of each other. |
| kubelet | Never newer. Up to three minors older; a kubelet older than 1.25 only up to two. |
| kube-proxy | Never newer than kube-apiserver; up to three minors older (two for kube-proxy older than 1.25); and within three minors of the kubelet beside it, either way. |
| kube-controller-manager, kube-scheduler, cloud-controller-manager | Never newer; the same minor or one older. |
| kubectl | One minor older, the same, or one newer. |
Rules restated from the official Version Skew Policy; checked against the current text on every build (all 7 key sentences still match). With HA API servers on two minors, every limit is measured from the older one.
Table for current versions
| kube-apiserver | kubelet / kube-proxy | controller-manager, scheduler | kubectl |
|---|---|---|---|
| 1.37 | 1.34 – 1.37 | 1.36 – 1.37 | 1.36 – 1.38 |
| 1.36 | 1.33 – 1.36 | 1.35 – 1.36 | 1.35 – 1.37 |
| 1.35 | 1.32 – 1.35 | 1.34 – 1.35 | 1.34 – 1.36 |
| 1.34 | 1.31 – 1.34 | 1.33 – 1.34 | 1.33 – 1.35 |
| 1.33 | 1.30 – 1.33 | 1.32 – 1.33 | 1.32 – 1.34 |
| 1.32 | 1.29 – 1.32 | 1.31 – 1.32 | 1.31 – 1.33 |
Why it matters
- Node upgrades can wait. With three minors of kubelet skew, you can upgrade the control plane across a year of releases and roll nodes once.
- But not forever. Before an API server upgrade, every kubelet must already be inside the new window. On a 1.37 control plane that means 1.34 or newer.
- Never run nodes ahead. A kubelet newer than its API server is unsupported, even by one minor. Upgrade the control plane first.