Upgrade kube-apiserver first, then kube-controller-manager, kube-scheduler and cloud-controller-manager, and then the kubelet and kube-proxy on nodes. Kubelet and kube-proxy may lag the API server by up to three minor versions, and none may be newer. Do not skip minor versions on the API server.
Why this belongs in a supply chain post
Cluster add-ons and node components ship on their own schedules. If you do not know the rules, you either freeze everything and collect known vulnerabilities, or you upgrade in the wrong order and break nodes. The Kubernetes version skew policy gives the actual limits.
The skew rules at a glance
| Component | Rule relative to kube-apiserver |
|---|---|
| kubelet | Not newer, up to three minor versions older (two if below 1.25) |
| kube-proxy | Not newer, up to three minor versions older (two if below 1.25) |
| kube-controller-manager, kube-scheduler, cloud-controller-manager | Not newer, expected to match, up to one minor older |
| kubectl | Within one minor version, older or newer |
With a highly available control plane, the newest and oldest API server instances must be within one minor version of each other. Skew between API servers narrows what is allowed for the other components.
Upgrade order
- kube-apiserver. Before you start, controller manager, scheduler and cloud controller manager must be at the current version, kubelets within range, and admission webhooks ready to handle new resources and fields, or set to match equivalent versions.
- kube-controller-manager, kube-scheduler and cloud-controller-manager, in any order, once the API servers they talk to are upgraded.
- kubelet, which is optional per release. Drain the node first. The docs say in-place minor version kubelet upgrades are not supported.
- kube-proxy, also optional, with the same rule about the API servers.
The page warns that running kubelets or kube-proxies persistently three minor versions behind means they must be upgraded before the control plane can move.
The security angle
Falling three minors behind is allowed, but it removes your room to move. Plan so that each node pool stays within one or two versions, and keep a calendar for the end of support of each release. See how long Kubernetes versions are supported.
Do not forget what runs on top
Add-ons such as ingress controllers, CNI plugins and DNS also have their own compatibility notes. Check each project's documentation for the Kubernetes versions it supports before an upgrade, because this post covers only the core components.
Try it yourself
Try it yourself
Click through it at your own pace, or open it full screen. Watch how new findings appear after a release, and note how an upgrade calendar fits that rhythm.
Quick check
Can I skip a Kubernetes minor version on the API server?
The docs say project policies require that the kube-apiserver does not skip minor versions when upgrading, even in single instance clusters.
Does kubectl have to match the cluster exactly?
No. It is supported within one minor version, older or newer.
Safeguard continuous monitoring and asset discovery help you keep track of what versions you run.
Sources
Last reviewed: 19 October 2026.
