Falling Behind on Kubernetes Versions Now Has a List Price

There is a Kubernetes cluster in your organisation right now that is three minor versions behind, and everyone who knows about it has a reason. The upgrade touches everything. The last one broke ingress for an afternoon. There is a migration that has to land first. The reasons are all true, and they are all beside the point, because while the cluster waits, three clocks are ticking: one run by the Kubernetes project, one run by your cloud provider’s billing department, and one run by every CVE scanner that will eventually notice. Falling behind used to be a vague risk. In 2026 it is a scheduled, priced event, and the pricing is not subtle.

This post is the case for making upgrades boring: what the clocks actually say, why the upgrade itself is rarely the hard part, and the routine that turns a dreaded quarterly project into maintenance you barely discuss.

The clock you are on, whether you like it or not

Since 2021, Kubernetes has shipped three minor releases a year, and each one receives patches for roughly fourteen months. That sentence contains the whole treadmill. Fourteen months of support against a four-month release cadence means the project patches the three most recent minors, and a cluster that skips two upgrade windows is running on borrowed time. Skip three and you are unpatched, full stop, on the software running underneath every workload you have.

Two version-skew rules shape what you can do about it. The control plane upgrades one minor at a time, no skipping, so a cluster that is four versions behind is not one upgrade away from current, it is four sequential upgrades away, each with its own change window and its own regressions. The good news hides on the node side: since Kubernetes 1.28, the kubelet may trail the API server by up to three minor versions, which means control plane and node pools can move on separate schedules, and the terrifying all-at-once cluster upgrade is a self-imposed constraint, not a platform requirement.

The bill when you stop pedalling

The cloud providers noticed that customers were treating “we will upgrade later” as a free option, and they repriced it. The clearest example is EKS: a cluster inside its fourteen-month standard window pays the base fee of $0.10 per hour, and the moment its version ages out, the cluster is automatically enrolled in extended support at $0.60 per hour. Same cluster, same workloads, six times the control plane fee, roughly an extra $4,400 a year, purely for being old. Extended support runs about a year, and at the end of it the provider force-upgrades the cluster on its own schedule, which is the worst possible version of the upgrade you were deferring: same work, arbitrary timing, someone else’s hand on the button. GKE and AKS run their own long-term support channels with different mechanics and their own price tags, but the shape is identical everywhere: staying current is included, staying old is a product you pay for, and staying too old is taken out of your hands.

Once falling behind has a list price, the framing inside your organisation changes. An upgrade cadence stops being an engineering preference and becomes the cheaper of two subscriptions.

The upgrade is not the hard part. The archaeology is.

Ask teams what actually went wrong during their worst upgrade and it is almost never the control plane, which the providers have made genuinely reliable. It is the things the cluster was quietly depending on. An API version that had been deprecated for two years finally got removed, and a Helm chart nobody had touched since 2023 was still writing it. PodSecurityPolicy vanished in 1.25 and took somebody’s admission setup with it. The in-tree cloud provider code was fully gone by 1.31, and clusters that had ignored the migration warnings stopped provisioning load balancers. Each removal was announced releases in advance; each one still ruined a change window somewhere, because the warning and the dependency were in different teams’ heads.

The honest reframe is that “upgrading Kubernetes” is a misnomer. You are upgrading a system of thirty-odd components, of which Kubernetes is the best-documented one. The CNI, the ingress controller, cert-manager, the observability agents, every operator: each has its own supported-version matrix against the Kubernetes minor you are moving to, and the real upgrade plan is a topological sort of that graph. This is the same lesson the ingress-nginx retirement taught about inventory: you cannot sequence what you cannot list, and most teams cannot list it.

The archaeology, at least, has good tools now. The API server counts every request to a deprecated API in the apiserver_requested_deprecated_apis metric, so the question “will the next upgrade break anything” is answerable from Prometheus before you touch a thing:

sum by (group, version, resource) (apiserver_requested_deprecated_apis)

Anything that query returns is an object someone is still writing in a form that is scheduled to disappear. For the complementary view, open-source scanners like kubent and Pluto walk your live objects and Helm releases and print the manifests that will not survive the next removal:

kubent --target-version <the-minor-you-are-moving-to>

Ten minutes with either one converts the scary unknown into a work list, and the work list is usually shorter than the fear was.

The routine that makes it boring

Teams that have escaped the dread all converge on the same shape, whatever they call it.

They pin the cadence to the calendar, not to courage: one minor version per quarter, scheduled like patch Tuesday, aiming to sit one release behind latest. The counterintuitive part is that upgrading more often is less work in total, because each hop carries at most four months of ecosystem drift, and because the muscle memory persists between windows instead of being relearned annually. One rehearsed minor-version hop is a Tuesday; three compounding hops under extended-support pricing is a project with a steering committee.

They rehearse on a disposable copy. The teams we wrote about in the environment-cloning post get this almost for free: stand up a clone of production, its addons and workloads included, run the upgrade there, and let the deprecated-API scanners and smoke tests fail where failing is cheap. The dry run converts release-note reading from literature review into a diff against your actual cluster.

They move the control plane first and let node pools follow through surge or blue-green rotation, leaning on that three-minor kubelet skew allowance rather than fighting it. PodDisruptionBudgets stop the rotation from strangling quorum-based workloads, which is exactly the scenario we flagged for databases on Kubernetes. None of this is exotic; all of it fails if improvised at 5 p.m. inside a change window.

And they read release notes as a diff, not a novel: the deprecations section, the removals section, and the changes to defaults. Everything else is somebody else’s excitement.

The part where the fleet outgrows the spreadsheet

All of the above works beautifully for a cluster. It stops scaling somewhere around cluster number six, when “what version is everything on, and what is about to age out” becomes a spreadsheet that is wrong by the time it is finished. This is the point where the problem changes from engineering to bookkeeping, and bookkeeping is what platforms are for.

This is the job Ankra treats as table stakes. Every cluster’s version and every addon’s version is inventory the platform holds, not folklore, because each one is a pinned node in a stack. The AI’s proactive insights flag versions approaching end-of-life before the billing clock or the CVE scanner does, upgrades roll out with dependency ordering and a Git record instead of a runbook in a wiki, and for managed clusters the version hop itself is a scheduled platform operation. The treadmill does not stop, but it stops being cardio.

Because that is the real conclusion: the treadmill is the deal now. Three releases a year, fourteen months of grace, and a price list for lapsing are not temporary conditions to wait out; they are the steady state of running Kubernetes, chosen by the ecosystem on purpose to keep the fleet moving. You can pay for that in one of three currencies: a quarterly routine so rehearsed it is boring, an extended-support line item that buys you nothing but delay, or a forced march on a date you do not control. The first one is the only currency that gets cheaper the longer you use it.

Get started: Create a free account on Ankra.

Join our community: Slack

Follow us on: LinkedIn | GitHub

Contact us: [email protected]