Kubernetes Upgrade Path Planner

Kubernetes releases 3 minor versions per year and supports the 3 most recent minor versions. Staying within the supported window means upgrading at minimum once per year.

Why One Minor Version at a Time

Each Kubernetes minor version may remove deprecated APIs that were available in the previous version. The API deprecation policy gives 2 releases of notice, but skipping versions risks hitting a removed API that breaks your workloads on the new apiserver.

Pre-Upgrade Checklist

1. 1.Check deprecated APIs: pluto detect-helm -A
2. 2.Back up etcd: etcdctl snapshot save backup.db
3. 3.Read the release notes for each version in your path
4. 4.Verify addon compatibility (CNI, CSI, ingress controller)
5. 5.Test upgrade on a staging cluster first

kubeadm Upgrade Commands

# On first control plane
apt-get install kubeadm=1.30.0-1.1
kubeadm upgrade apply v1.30.0

# On remaining control planes kubeadm upgrade node

# On each worker (after draining) apt-get install kubeadm=1.30.0-1.1 kubelet=1.30.0-1.1 kubectl=1.30.0-1.1 kubeadm upgrade node systemctl restart kubelet ```

Version Skew Policy

• ›kubectl can be ±1 minor version from apiserver
• ›kubelet must be ≤ apiserver version (never newer)
• ›kube-proxy must match kubelet version
• ›etcd: any version compatible with the K8s minor version (check release notes)

Cluster Add-on Compatibility

Check your CNI (Calico, Cilium, Flannel), CSI driver, ingress controller, and cert-manager compatibility matrix for the target K8s version before upgrading.