The Kubernetes version skew policy supports kubectl within one minor version, older or newer, of kube-apiserver. If the cluster is at 1.37, kubectl 1.36, 1.37 and 1.38 are supported. Outside that window it may still work, but it is not supported, so update the client when you upgrade the cluster.
The documented rules
From the Kubernetes version skew policy:
| Component | Supported skew relative to kube-apiserver |
|---|---|
| kubectl | Within one minor version, older or newer |
| kubelet | Not newer; up to three minor versions older |
| kube-proxy | Not newer; up to three minor versions older |
For kubelet and kube-proxy, versions below 1.25 may be only two minor versions older. kube-proxy may also be up to three minor versions older or newer than the kubelet it runs next to.
When there are several API servers at different versions, such as during an upgrade, the kubectl rule is applied across them. With API servers at 1.37 and 1.36, kubectl 1.37 and 1.36 are supported.
Why developer machines are the weak spot
Cluster upgrades are planned events. Laptops and CI images are not. A kubectl installed two years ago and baked into a pipeline image is easy to forget, and then the cluster moves two minors ahead.
The result is odd behavior: missing fields, deprecated API versions in manifests, or commands that quietly do less than expected. The failure is rarely dramatic, which is why it lingers.
How long does a cluster version get patches
The same page says the project maintains release branches for the most recent three minor releases, currently 1.37, 1.36 and 1.35. For Kubernetes 1.19 and newer, the page says each gets approximately one year of patch support. A cluster two or three minors behind is close to the end of that road.
A routine that keeps clients aligned
- Make a list of every place kubectl lives: laptops, CI images, build agents, jump hosts.
- Run kubectl version in CI and fail the job if client and server differ by more than one minor.
- Upgrade the cluster, then upgrade the client images the same week.
- Keep manifests free of deprecated API versions by checking before each cluster upgrade.
- Pin the kubectl version in pipeline images and bump it with the cluster.
The upgrade order for control plane components matters too. The skew page lists kube-apiserver first, then the controllers and scheduler, then kubelet and kube-proxy.
Safeguard can scan container images used in your pipelines, including tooling images, for known issues. Try a free scan at gold.safeguard.sh/scan.
Common mistakes
The common ones are baking kubectl into an image once and never rebuilding it, upgrading the cluster without telling the teams who own pipelines, and assuming a command that still runs is a command that still works as intended.
Try it yourself
Click through it at your own pace, or open it full screen.
Open the scan results and look at how an image's installed tool versions are listed, which is where an old kubectl would show up.
Quick check
Can kubectl be newer than the cluster?
Yes, by one minor version. The policy supports kubectl one minor older or newer than kube-apiserver.
Can kubelet be newer than the API server?
No. The policy says kubelet must not be newer than kube-apiserver.
Sources
Last reviewed: 19 October 2026.
