Upgrading Kubernetes Clusters Safely#
Kubernetes releases a new minor version roughly every four months. Staying current is not optional – clusters more than three versions behind lose security patches, and skipping versions during upgrade is not supported. Every upgrade must step through each minor version sequentially.
Version Skew Policy#
The version skew policy defines which component version combinations are supported:
- kube-apiserver instances within an HA cluster can differ by at most 1 minor version.
- kubelet can be up to 3 minor versions older than kube-apiserver (changed from 2 in Kubernetes 1.28+), but never newer.
- kube-controller-manager, kube-scheduler, and kube-proxy must not be newer than kube-apiserver and can be up to 1 minor version older.
- kubectl is supported within 1 minor version (older or newer) of kube-apiserver.
The practical consequence: always upgrade the control plane first, then node pools. Never upgrade nodes past the control plane version.