How long is a Kubernetes version supported?
The Kubernetes project supports each minor version with patches for about 14 months: a 12-month standard period followed by a two-month maintenance period for security and critical fixes. A new minor version ships roughly every four months, so only the three most recent minor versions are maintained at any time. Managed services follow a similar window and sell paid extended support that keeps a version patched for up to 24 or 26 months in total.
The upstream release cycle
The Kubernetes community releases about three minor versions a year. According to the patch release policy, defined in KEP-1498, each minor version gets:
- 12 months of standard support, with regular patch releases for bugs and vulnerabilities.
- 2 months of maintenance mode, with patches only for CVEs, dependency issues and critical core bugs.
- End of life after that. The release branch closes and no further patches ship.
The releases page lists the current versions and their end-of-life dates.
Version skew between the control plane and nodes
Upgrades are easier because components do not have to move in lockstep. The version skew policy sets the limits:
| Component | Allowed skew against kube-apiserver |
|---|---|
| kubelet and kube-proxy | Up to three minor versions older, never newer (two before Kubernetes 1.28) |
| kube-controller-manager, kube-scheduler | Same version or one minor version older |
| kubectl | One minor version older or newer |
| Other API server instances in an HA control plane | Within one minor version |
The three-version node skew came with KEP-3935 in Kubernetes 1.28 and lets you upgrade the control plane several times before you replace nodes. Providers can be stricter: GKE allows nodes to run at most two minor versions behind its control plane. Nodes that sit at the maximum skew block the next control plane upgrade until you upgrade them.
Extended support on EKS, GKE and AKS
The large managed services all offer a standard window of about 12 to 14 months and a paid option to stay longer. Prices are as of November 2026.
| Amazon EKS | Google GKE | Azure AKS | |
|---|---|---|---|
| Standard support | 14 months | About 14 months | About 12 months (community support) |
| Extended option | Extended support, 12 more months | Extended channel, up to 24 months in total | Long-term support (LTS), 12 more months |
| Control plane price | $0.10 per cluster hour, $0.60 in extended support | $0.10 per cluster hour, plus $0.50 in the extended period | $0.10 per cluster hour on the Standard tier, $0.60 with LTS on the Premium tier |
| Enrollment | Automatic: the default upgrade policy is EXTENDED |
Opt-in: the cluster must be on the Extended channel | Opt-in: Premium tier and the LTS support plan |
| After support ends | Control plane is upgraded automatically | Control plane and nodes are upgraded automatically | Cluster is upgraded after a 60-day grace period |
Sources: the EKS version lifecycle and EKS pricing, the GKE versioning and GKE pricing pages, and the AKS supported versions, AKS LTS and AKS pricing pages.
The surcharge is the same $0.50 per cluster hour on all three, which is about $365 per cluster per month at 730 hours. It applies per cluster, so a company with 20 clusters one version behind pays it 20 times. The EKS default deserves attention: a cluster that nobody upgrades moves into extended support and starts billing at six times the standard rate without any action from you.
Forced upgrades are the other half of the policy. EKS upgrades the control plane at the end of extended support and leaves node groups and add-ons for you to fix. GKE upgrades control planes and nodes. AKS announced that, starting June 1, 2027, it will upgrade clusters left on an unsupported version once the 60-day grace period ends, and that these upgrades ignore maintenance windows and deprecated API checks.
What end of support means in practice
A version past its end of life keeps running. Nothing switches off on the date. What changes:
- No security patches. Vulnerabilities found later are not fixed in that version, and the community discourages CVE reports for unsupported versions, so some are never published.
- Add-ons move on. CNI plugins, CSI drivers, ingress controllers and operators drop old Kubernetes versions from their test matrix, so their own security fixes stop reaching you.
- Provider limits. Managed services stop letting you create clusters on the version, limit support cases, and eventually upgrade the cluster for you, often at a time you did not choose.
The longer a cluster waits, the bigger the jump. Removed APIs pile up across versions, and an upgrade from a version two years old means stepping through several minor versions in a row.
A planning rule
Stay within one minor version of the newest release your provider offers, and schedule an upgrade every four months instead of once a year. Treat extended support as a buffer for a blocked migration, not as a lifecycle plan. Upgrading a cluster safely covers the checks that make a regular cadence realistic, and managed Kubernetes pricing shows where version fees sit in the total bill. Distributions set their own windows too, as described in what a Kubernetes distribution is.
Kubernetes versions on Cloudfleet
Cloudfleet Kubernetes Engine (CFKE) supports the Kubernetes versions that upstream supports and upgrades the control plane with a rolling update. Pro and Enterprise clusters choose a stable or extended release channel, and Enterprise clusters include extended support for older versions. See Kubernetes versions and upgrades for the policy.