There is no Kubernetes LTS —
and the thing that buys you time is a cloud invoice.

People search for “Kubernetes LTS” expecting a version number. There isn’t one. Upstream Kubernetes has never shipped a long-term-support release: every minor version gets the same window — roughly fourteen months, twelve of standard support and two of maintenance mode — and a new minor arrives about every four months. Every cycle in the project’s history carries the same lifecycle; none is marked LTS, because none is.

That does not mean long-term Kubernetes support doesn’t exist. It does — but it is a product the managed clouds sell, not a thing the project publishes. This guide answers both versions of the question: what the upstream clock really is, and what EKS, AKS and GKE actually offer when you need to hold a version longer than fourteen months.

The upstream clock: 12 + 2, every four months

The Kubernetes project’s own release policy states it plainly: the community “will support active patch release series for a period of roughly fourteen (14) months” — the first twelve as the standard period, after which the series enters a two-month maintenance mode where release managers may cut additional maintenance releases for critical and security fixes. Then it ends. There is no tier above that, no extended designation, no version chosen for a longer life.

Combine that with the roughly four-month release cadence and the arithmetic is unforgiving: at any moment, exactly three minors are in standard support, and one drops off every four months. If your organisation upgrades Kubernetes less often than three times a year, you will spend part of every year on an unsupported version — not through negligence, but by construction.

What that means for the versions people are still running

Two consequences fall out of the fourteen-month clock, and both are visible in what people search for.

Kubernetes 1.32 has been unpatched since February 28, 2026. It is one of the most-searched versions on this site, and much of that traffic is people asking whether it is still supported. Upstream, it is not — nearly six months dead. It scores 60 on our risk scale, and that number only rises. The version people think is the safe long-lived one is exactly the one the clock has already retired.

Kubernetes 1.34 leaves standard support on August 27, 2026. After that it is in its two-month maintenance tail; end of life follows on October 27. Teams that upgraded to 1.34 last autumn and considered themselves current have a decision this month, not this quarter.

Where LTS actually lives: EKS, AKS and GKE

The managed clouds noticed the same arithmetic their customers did, and each now sells the thing upstream doesn’t: a longer window on one minor version. The three offerings are structurally similar — roughly a year of the upstream window, then roughly a year of the provider’s own security backports — and all three charge for the extension. Details, from each provider’s own documentation:

Amazon EKS is the most explicit and the most automatic. Every version gets 14 months of standard support, then enters 12 months of extended support — and extended support is enabled by default: unless you set the upgrade policy otherwise, your cluster crosses into it silently and the bill changes with it. AWS’s own words: “each version will be supported for 26 months in Amazon EKS.” At the end of extended support the control plane is auto-upgraded, with no notification of timing. Our EKS lifecycle guide covers the mechanics and the pricing step in detail. Concretely: Kubernetes 1.32 upstream died February 28, 2026, but on EKS its extended support runs to March 23, 2027 — that is Kubernetes LTS, in practice, on an invoice.

Azure AKS names it directly: “AKS provides one year of community support, followed by one additional year of long-term support” — approximately 24 months from GA. It requires the Premium tier and an explicit LTS support plan, but every supported version is LTS-eligible, and enabling it is a configuration change with no node reimaging. During the LTS year Microsoft backports security fixes from upstream.

Google GKE offers the Extended release channel: “you can stay on a minor version for up to 24 months” — 14 months of standard support and roughly 10 more of security patches, with pay-per-use costs applying once the version enters the extended period. GKE also begins upgrading extended clusters to the next minor about two months before the window closes.

The honest summary of the market: Kubernetes LTS exists, it costs money, it tops out at about two years, and on EKS you are enrolled in it whether you decided to be or not. None of the three lets a version live indefinitely, and all three end in a forced or strongly-encouraged upgrade. It is a bridge, priced as one.

What to do

If you were searching for the LTS version to standardise on: there isn’t one, so pick the newest instead. 1.36 has the longest runway available (end of life June 28, 2027), and every version behind it dies sooner. Standardising on “the newest minor, upgraded every eight months” is the closest thing to an LTS policy upstream Kubernetes allows.

If you are on 1.32 or 1.33: you are upstream-unsupported now. On a managed cloud, check which tier you are actually in — on EKS you are almost certainly paying extended-support rates already — and treat the upgrade as overdue, not upcoming.

If you genuinely need two years on one version: that is a managed-cloud decision, and it is worth costing properly — the extension is priced per cluster-hour, so a large fleet held on an old version for a year is a real line item. Our EKS guide works the numbers for the AWS case.

If you run Kubernetes yourself: there is no extension to buy. The fourteen-month clock is the whole clock, which is why self-managed clusters have the strongest case for a fixed, calendar-driven upgrade cadence.

Every Kubernetes release, its dates and its EOL Risk Score are on the Kubernetes lifecycle page; the version-by-version guide is Kubernetes End of Life 2026.

Frequently Asked Questions