Your Kubernetes cluster is probably two or three versions behind — and that is quietly costing you more than you think. Kubernetes releases three times a year, each version supported for roughly 14 months. Miss the window and you are running a cluster with known vulnerabilities, no vendor support, and APIs that will stop working the day you finally upgrade.
For SMBs the pattern is almost universal: the cluster was set up once, by one person, and nobody has touched the version since. Upgrades feel risky, so they get postponed. Postponed upgrades become urgent, forced migrations — usually triggered by a managed provider dropping support or a CVE in the news. That is the worst possible way to do the most important maintenance task in your infrastructure.
The good news: Kubernetes upgrades can be boring. This guide gives you a practical audit, a repeatable runbook, and automation to keep version drift from ever sneaking up on you again.
The Real Cost of Running an Outdated Cluster
Outdated clusters fail in three predictable ways:
- Security. End-of-life versions receive no patches. When a critical vulnerability drops — and it will, in the container runtime, the ingress controller, or kubelet — you are exposed with no fix available.
- Broken manifests. Kubernetes removes deprecated APIs after a few releases. The Ingress and PodSecurityPolicy APIs you wrote years ago will not parse on a current cluster, and every manifest, Helm chart, and CI step that depends on them breaks at upgrade time — all at once.
- Provider deadlines. Managed Kubernetes providers support only the most recent versions: typically the latest four for EKS, three for GKE, and a rolling window for AKS. Their deadline becomes your deadline, whether you are ready or not.
There is also a quieter cost: an outdated cluster tends to run outdated tooling — old metrics servers, old CSI drivers, old CNI plugins — which is exactly the kind of accumulated debt that makes Kubernetes bills creep upward and makes day-to-day operations harder than they need to be. If you are still deciding whether Kubernetes is right for you at all, our Kubernetes vs. serverless decision framework will help — but if you already run a cluster, the upgrade problem applies to you today.
Step 1: The Pre-Upgrade Audit — Know What You Are Running
Before touching anything, answer three questions: what version am I on, what APIs do I use, and what will break?
# Current version of client and server
kubectl version --short
# All nodes and their kubelet versions
kubectl get nodes -o wide
# Kubelet version per node
kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.nodeInfo.kubeletVersion}{"\n"}{end}'Next, detect deprecated APIs before they bite. Pluto is the standard tool: point it at your live cluster or at your Git repository of manifests, and it tells you which resources will disappear in each future version.
# Scan the live cluster
pluto detect-cluster --ignore-deprecations
# Scan manifests in Git
pluto detect-files -d ./k8s-manifests/Run this against the version you are targeting, not just the next one. If you are on 1.28 and plan to reach 1.31, check every removal between 1.28 and 1.31 in one pass. Fix manifests in Git first — this is where a GitOps workflow pays off, because the fix is a reviewed pull request instead of a live edit.
Step 2: A Safe, Repeatable Upgrade Runbook
The golden rule: never skip minor versions, and never upgrade production first. One minor version at a time, staging before production, and a rollback story for every step.
Managed clusters (EKS, AKS, GKE) — the control plane upgrades for you; you manage node groups:
# EKS: upgrade control plane, then node group
eksctl upgrade cluster --name=prod --version=1.30
eksctl upgrade nodegroup --cluster=prod --name=workers --version=1.30
# AKS
az aks upgrade --resource-group rg-prod --name aks-prod --kubernetes-version 1.30
# GKE (surge upgrade limits disruption)
gcloud container clusters upgrade prod --cluster-version=1.30 \
--node-pool=default-pool --surge-max=1 --max-unavailable=0Self-managed clusters — drain each node before upgrading it, so pods move cleanly to upgraded nodes:
# On the control-plane node
kubeadm upgrade plan
kubeadm upgrade apply v1.30.0
# For each worker node
kubectl cordon node-1
kubectl drain node-1 --ignore-daemonsets --delete-emptydir-data
ssh node-1 "kubeadm upgrade node && systemctl restart kubelet"
kubectl uncordon node-1Two rules keep this safe:
- Back up etcd before the control-plane upgrade. A Velero backup of namespaces plus an etcd snapshot is your rollback path, because Kubernetes does not support downgrades.
- Verify after every step.
kubectl get nodesshows all nodes Ready; run a smoke test of your critical paths (login, checkout, webhook) before moving to the next minor version.
Step 3: Automate Drift Detection So You Never Fall Behind Again
Manual upgrades fail because humans forget. Automation does not. Three cheap pieces of automation keep you current:
1. Renovate for your infrastructure-as-code. Renovate watches your Terraform, Helm, and GitHub Actions files and opens a pull request when a new Kubernetes version is released. Approving a well-tested PR is far easier than planning a migration:
# renovate.json
{
"kubernetes": {
"fileMatch": ["\\.yaml$", "\\.yml$", "values\\.yaml$"]
},
"packageRules": [
{
"matchDatasources": ["docker"],
"matchPackageNames": ["eksctl", "kubectl", "helm"],
"automerge": false
}
]
}2. A scheduled drift check in CI. A weekly GitHub Actions job compares your cluster version against the oldest supported version and opens an issue when you drift:
# .github/workflows/k8s-drift.yml
name: kubernetes-drift-check
on:
schedule:
- cron: "0 6 * * 1"
jobs:
check:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: |
kubectl version --client
pluto detect-files -d ./k8s-manifests/ || exit 13. Continuous vulnerability scanning. Trivy against your cluster and your container registry turns “is there a CVE?” from a manual panic into a daily report — the same CI discipline you already use for your production pipeline.
Make Upgrades Boring: The Cadence That Works for SMBs
The teams that never fear upgrades share one habit: they upgrade on a schedule, not on a deadline. Concretely:
- Stay within two minor versions of the latest release.
- Block a quarterly upgrade window: staging in week one, production in week two, buffer for surprises.
- Keep a staging cluster that mirrors production — even a small one. It turns every upgrade into a rehearsal.
- Document the runbook in your repo so the upgrade is not dependent on one person’s memory.
For a typical SMB cluster, a single minor-version upgrade is a two-hour task with the runbook above. Two hours a quarter is a small price for never again facing a forced, panic-stricken, all-hands upgrade.
Your cluster is the foundation of everything you ship. Treating version drift as a routine, automated chore — instead of an emergency — is one of the highest-leverage reliability investments an SMB can make.
Want a second pair of eyes on your upgrade plan — or help building the automation so you never drift again? Book a free strategy session with our team: Schedule your free consultation.
English 
Español