Kubernetes ships a minor release about every 4 months, and each one gets roughly 14 months of patches. Skip upgrades for a year and you're not one version behind, you're on an unsupported one.
A thread on upgrading clusters without drama.
Rolling replacement only works if workloads can move. A PodDisruptionBudget that allows zero disruptions blocks every drain, and single-replica apps go down. Fix both before the upgrade window, not during it.
With Cluster API, an upgrade is a version change in Git: bump spec.version on the KubeadmControlPlane, then on each MachineDeployment. CAPI replaces machines one by one instead of patching them in place. Nodes become disposable, which is the point.
Add-ons break more upgrades than Kubernetes does. CNI, CSI driver, ingress or Gateway controller, cert-manager, Argo CD: check which Kubernetes versions each supports and bump them in Git before the cluster, not after.
Control plane first, one minor version at a time. You can't jump from 1.32 to 1.35 in one step. Kubelets may lag the API server by up to three minors, so nodes can follow later, but never run them newer than the control plane.
First, check what the new version removes. A manifest in Git that still uses an old apiVersion fails to sync the day you upgrade. Tools like pluto or kubent find deprecated APIs in your repo and in the live cluster.
🚀 Just dropped a blog on leveraging ArgoCD, ClusterAPI, & our argocd-capi-controller for smarter Kubernetes management. A must-read for anyone in #DevOps and #CloudNative spaces.
Dive in ➡️ cloudnativesolutions.ro/blog…
Let's chat about it! #ArgoCD #ClusterAPI