Kubernetes expires every fourteen months, and you cannot skip versions

On 27 October 2026, the Kubernetes 1.34 branch stops receiving patches. That is not news, and it is not a last-minute scare: the date has been published since the version shipped. And still, come October, somebody will find out by reading a security advisory.

The policy fits in a single sentence of the project documentation: the community supports each patch release series for "roughly fourteen (14) months". Twelve normal months plus two final ones in maintenance mode. The project maintains "release branches for the most recent three minor releases" — today 1.35, 1.36 and 1.37 — and because those last two months overlap, 1.34 still gets patches until 27 October.

The published expiry dates are these, and they are worth reading together because together they say something each one alone does not: 1.35 enters maintenance mode on 28 December 2026 and dies on 28 February 2027; 1.36, on 28 April and 28 June 2027; 1.37, on 28 August and 28 October 2027. Subtract the three death dates: February, June, October. A version expires every four months, for as long as the project keeps that cadence. That is what you sign up for the day you adopt Kubernetes, and you sign up for every year, not just year one.

What "maintenance mode" actually means

The last two months of each branch are not the same as the twelve before, and the difference is written down. In maintenance mode, release managers only cut new releases for three things: vulnerabilities with an assigned CVE ID, dependency issues — including base image updates — and critical core component issues. Nothing else.

Translated into a working morning: that odd bug you hit, the one that is neither critical nor has a CVE, the one you were going to report with a proper reproduction case, no longer gets fixed on your branch. It gets fixed on another one, the one you have not moved to yet. It is a reasonable decision by a project that moves at its own pace, but it is a decision you end up making by omission when you fall behind.

The rule that turns the calendar into a project

Here is the part people find out late. The project version policy requires "kube-apiserver to not skip minor versions when upgrading, even in single-instance clusters". You do not skip minor versions on the control plane. Not even on a single-instance cluster, where you might assume nobody would notice.

Counting the hops

So the debt is not paid off in one go. If you run 1.33 today and want to reach 1.37, that is four chained upgrades: 1.34, 1.35, 1.36 and 1.37. Four sets of release notes to read, four batches of removed APIs to check against your manifests, four windows. One version behind is an afternoon. Four versions behind is a project with a name, a budget and a meeting to decide when it happens.

The nodes, by contrast, have slack: kubelet may run up to three minor versions behind kube-apiserver — two if it predates 1.25 — and kubectl is supported within one minor version either way. That slack is useful and exists so upgrades can be staged. It is also, in our experience, the reason a cluster looks healthy while it drifts: the nodes keep working, nobody sees anything broken, and the margin gets spent in silence.

The calendar that is not on that calendar

The dates above belong to the Kubernetes project. Your cluster is not only Kubernetes. On top of it sit an ingress controller, a network plugin, one or more storage drivers, a certificate issuer, the metrics stack and, nearly always, some operator running a database nobody wants to touch. Each of those pieces has a cycle of its own, a compatibility matrix of its own and a maintainer who does not know you exist, and none of those dates appear on the Kubernetes releases page.

We already covered here what happened with the ingress controller that half the Kubernetes world ran and two people maintained. That warning did not arrive in the release notes of a Kubernetes minor, because it was not Kubernetes. It arrived on its own, with its own deadline. Upgrading a cluster for real means resolving the intersection of several compatibility matrices moving at different speeds; the command is the last step and the shortest. That intersection decides which day you can upgrade and which day you cannot.

This is not a flaw in Kubernetes

Worth saying plainly, because this could read as a complaint and it is not. Shipping three minor versions a year is exactly what lets the project move at the speed it moves, and publishing expiry dates more than a year ahead is the opposite of a vendor pulling a product by surprise. We would take a hard, public calendar over a soft promise any day.

What does change is the question to ask before adopting it. Before adopting it you have to answer a question that is not about technology but about headcount: who runs three maintenance windows a year in this shop, for the next five years. At everyWAN we run both Kubernetes and Docker Swarm, we offer managed Kubernetes just as we run Swarm, and we choose on the merits of each case, not on commission, because we are not resellers of any platform. Which is why we will say it bluntly: a well-designed cluster ages badly the moment the calendar loses its owner.

There is also a method detail pointing the same way that we wrote about elsewhere: "latest" is not a version. If your deployments do not pin versions, this calendar is useless to you, because you do not know what you are running and therefore you do not know what day it expires.

Five questions you should be able to answer today

• Which minor do you run, and what day does it expire? One kubectl version and the project patch releases table. If the answer takes more than five minutes, you already have your first finding.
• How many hops separate you from the oldest live branch? Each hop is a window, because the control plane does not skip versions. That number is your debt.
• What minimum Kubernetes version does each add-on you run require? And, the one that stings, which of them does not support the version you want to reach yet? This question takes an afternoon rather than five minutes, and it owns your date.
• Who runs the window, and with what rollback plan? With a person's name and a written procedure, not "whoever is around". With no documented way back, the window is a bet.
• Who looks at the alert at three in the morning the day after? The 48 hours after the window are the ones that hurt. We have written about which alert deserves to wake someone and which is noise; that distinction gets decided beforehand, not that night.

What we are not saying

We are not saying do not use Kubernetes. We run it, we offer it managed, and we think it is the right tool in plenty of cases. Nor are we saying these dates are set in stone: they are the ones the project publishes today, 24 September 2026, and the project reserves the right to vary patch timelines with the severity of bug fixes. And we did not check for this post what each managed Kubernetes cloud provider offers once a version expires, or at what price; what does come from the official calendar is the project's own date, and that one applies to everybody equally.

The only thing we are arguing here is one piece of arithmetic and one consequence. The arithmetic: fourteen months per branch, three live branches, one expiry every four months, no skipping on the control plane. The consequence: the cost of Kubernetes is not standing it up, it is holding it up, and that cost is paid in maintenance windows. If that work has an owner, the calendar is a schedule. If it does not, the calendar is an expiry date that arrives on its own, on a Tuesday, with a security advisory underneath it. That is exactly what our 24x7 IT support covers, and the first thing we look at when somebody asks us for consulting on a platform that is already running.

Sources (consulted on 24 Sep 2026): the phrase "roughly fourteen (14) months", the split into twelve months plus two in maintenance mode, the list of reasons a release is cut during that period (vulnerabilities with assigned CVE IDs, dependency issues including base image updates, and critical core component issues), and the maintenance-mode and end-of-life dates for 1.34 (27-08-2026 and 27-10-2026), 1.35 (28-12-2026 and 28-02-2027), 1.36 (28-04-2027 and 28-06-2027) and 1.37 (28-08-2027 and 28-10-2027) are on Patch Releases. That the project maintains "release branches for the most recent three minor releases" (1.35, 1.36, 1.37), and that 1.19 and newer receive approximately one year of patch support, is on Releases. The version skew rules — "kube-apiserver to not skip minor versions when upgrading, even in single-instance clusters", kubelet up to three minor versions behind (two before 1.25), kubectl within one minor version, and the apiservers of an HA cluster within one minor version — are on Version Skew Policy. What this post does NOT claim: the "one expiry every four months" figure is ours, obtained by subtracting the three published end-of-life dates, and it holds only while the cadence does; the project reserves the right to vary patch timelines with the severity of bug fixes. We did not verify what extended support each managed Kubernetes provider offers after upstream end of life, or what it costs, which is why we give no numbers on that. We do not claim any other container platform is better or worse for having a different lifecycle: they are different trade-offs. And the advice to count your hops and put a name on the window is our own judgement, not a recommendation from the project.