Kubernetes 1.34 reaches end of life on October 27

Kubernetes 1.34 reaches end of life on October 27, 2026, according to the Kubernetes patch release schedule. That is 28 days away. After that date the Kubernetes project ships no more 1.34 patches.

Your managed cluster will not stop on that day, because Amazon EKS, Azure AKS and Google GKE each keep their own calendar. The catch is what happens next: on EKS and GKE, staying on 1.34 becomes a paid option.

When does Kubernetes 1.34 reach end of life?

Kubernetes 1.34 is the upstream release of August 27, 2025. It entered maintenance mode on August 27, 2026 and reaches end of life on October 27, 2026, per the Kubernetes patch release table.

The latest 1.34 patch is 1.34.12, released September 15, 2026. The next monthly patch is targeted for October 13, with a cherry-pick deadline of October 9.

The supported upstream versions are 1.35, 1.36 and 1.37. Their end-of-life dates are February 28, 2027, June 28, 2027 and October 28, 2027.

What are the EKS, AKS and GKE deadlines for Kubernetes 1.34?

Each cloud sets its own end of standard support for 1.34, and all three sit after the upstream date. The table pulls each date from the provider's own documentation.

Platform	Standard support ends	Extended or long-term support ends	Days from September 29
Upstream Kubernetes	October 27, 2026	None	28
Amazon EKS	December 2, 2026	December 2, 2027	64
Azure AKS	November 30, 2026	November 2027 (LTS, opt-in)	62
Google GKE	January 25, 2027	November 25, 2027 (Extended channel)	118

The sources are the EKS version calendar, the AKS supported versions page and the GKE release schedule. Microsoft writes AKS end of life as "Nov 2026" and says a month-only date means the last day of that month, so the table shows November 30.

What does extended support cost per cluster?

Amazon EKS extended support is a paid stage that starts the day standard support ends and lasts 12 months. AWS lists the price on its EKS pricing page as $0.10 per cluster per hour in standard support and $0.60 in extended support.

GKE Extended channel support is also paid. Google's GKE pricing page prices the extended period at $0.50 per cluster per hour, added to the flat $0.10 cluster fee that applies to every GKE cluster.

Number of clusters	Extra cost per month	Extra cost per year
1	$365	$4,380
5	$1,825	$21,900
10	$3,650	$43,800
40	$14,600	$175,200

Methodology: we analyzed the published per-hour surcharge of $0.50 and multiplied by 730 hours a month and 8,760 hours a year. The all-in EKS rate of $0.60 is $438 per cluster per month. Fact-check: every rate matches the two pricing pages.

Azure works differently. Microsoft's AKS page says you must enable long-term support to get extended coverage, and does not list a price there. Check the Azure pricing page for your tier before you budget.

What happens if I do nothing on each platform?

On EKS, doing nothing costs money, because extended support is on by default. The EKS lifecycle page says the default upgrade policy is EXTENDED, and billing starts at the beginning of the day standard support ends, in UTC. A 1.34 cluster left alone begins billing at $0.60 an hour on December 2, 2026.

If you turn extended support off, AWS auto-upgrades the cluster at the end of standard support. After the extended year ends, EKS upgrades the control plane without notice, and nodes stay on the older version.

On AKS, a 1.34 cluster moves into platform support after November 30. Microsoft's support table says Kubernetes components, bug fixes and security patches are not supported in that stage. You also cannot create new clusters on that version.

On GKE, Google's schedule pairs each release channel with an auto-upgrade date. Only clusters that opted into the Extended channel stay on 1.34 through November 25, 2027.

Which Kubernetes version should I upgrade to from 1.34?

Upgrade to 1.36. Kubernetes 1.34 to 1.36 takes two hops, and 1.36 stays supported upstream until June 28, 2027. Version 1.35 ends February 28, 2027, which puts you back in an upgrade project five months after finishing this one.

Skipping is not an option. Microsoft's AKS FAQ states that a supported non-LTS cluster cannot jump from 1.33 to 1.35 and must upgrade one minor version at a time. Upstream Kubernetes control planes also move one minor version at a time.

Version 1.37 is a three-hop path. It shipped upstream on August 26, 2026, but the EKS calendar only lists versions up to 1.36 in standard support. On EKS, 1.36 is currently the newest version you can reach.

One 1.35 change deserves a warning before the first hop. Kubernetes 1.35 will not start your cgroup v1 nodes, so check node images before you move the control plane.

How do I plan the upgrade before the deadline?

Work through the hops with a test cluster first. For example, a staging cluster that mirrors production catches removed APIs early. Each step takes a control plane upgrade, then nodes, then add-ons.

1. List every cluster and its version with kubectl version or your cloud console.
2. Note which clusters are on 1.34 or older, and how many are on EKS or GKE, where extended support bills by the hour.
3. Read the release notes for 1.35 and 1.36 for removed APIs, and scan manifests with a deprecation checker such as kubent or pluto.
4. Upgrade a staging cluster to 1.35, run your test suite, then continue to 1.36.
5. Upgrade production one hop at a time, and update node pools, since the control plane does not upgrade them for you.
6. Schedule the work so production reaches 1.36 before December 2 on EKS and November 30 on AKS.

Nodes can trail the control plane by up to three minor versions, according to the AWS lifecycle page. Running that far behind is not recommended.

Should I pay for extended support or upgrade now?

Pay for extended support only when you can name the blocker and the date you will remove it. Otherwise the fee just delays the discovery of the problem. A single cluster costs $4,380 more a year. Forty clusters cost $175,200 more, which is often enough to fund the migration itself.