Kubernetes 1.34 EOL October 27: EKS, GKE, AKS Upgrade Clocks Explained

On October 27, 2026, the upstream Kubernetes project stops maintaining version 1.34 for good. The release entered maintenance mode two months earlier, on August 27, meaning only critical security fixes were being accepted, and the hard stop this month ends even that minimal stream6. The final scheduled patch, 1.34.13, is targeted for October 13 — after that, a CVE disclosed against 1.34 gets no official fix from the community, period14.

But the October 27 date is only the beginning of the story for the majority of production clusters, because most people don't run upstream Kubernetes at all. They run it through Amazon EKS, Google GKE, or Azure AKS, and each of the three hyperscalers keeps its own support clock that diverges — sometimes by months — from the community calendar. Understanding those divergences, and what each provider does when its clock runs out, is the difference between a planned upgrade and a surprise one.

Three clocks, three very different behaviors

The dates line up like this. Upstream: end of life October 27, 2026. EKS: standard support for 1.34 ends December 2, 2026, with extended support running to December 2, 202713. AKS: end of life November 30, 2026, with an opt-in Long-Term Support tier extending to November 202723. GKE: standard support ends January 25, 2027, with the Extended channel carrying clusters to November 25, 202713. IBM Cloud, for those tracking the second tier of managed providers, runs a roughly 14-month window that ends January 20, 20273.

Those gaps exist because each provider anchors its calendar to its own GA date rather than the upstream tag. EKS made 1.34 available on October 2, 2025 — about five weeks after upstream — and grants 14 months of standard support from that date, plus 12 months of paid extended support, for a total lifespan of 26 months3. AKS took 1.34 to GA in November 2025 and runs a tighter 12-month standard window, which is why it hits end of life first among the big three3. GKE, which made 1.34 available in early September 2025, ends up with the longest runway of the three3.

What "end of support" actually means, though, differs sharply by provider — and this is where teams get burned.

EKS: doing nothing costs money, then costs the control plane

On EKS, inaction first shows up on the bill. Extended support is enabled by default, so a 1.34 cluster that passes December 2 doesn't stop running — it starts being charged at $0.60 per cluster-hour instead of the standard $0.10, a 500% increase that works out to roughly an extra $4,380 per cluster per year24. Extended support isn't a dead end, either: AWS says it backports security patches to every version it still supports, including those in extended support, so the security posture degrades more slowly than upstream1.

The sharper edge comes 12 months later. When extended support ends, EKS upgrades the control plane to the oldest version still supported — and the documentation is explicit that this automatic update "can happen at any time" and that "you won't receive any notification before the update"1. For 1.34, that forced upgrade lands December 2, 2027. Notably, the forced upgrade moves only the control plane; managed node groups, self-managed nodes, and add-ons stay on the old version until you move them, which creates its own skew problems1.

GKE: channel enrollment decides your fate

GKE handles versions through release channels, and most clusters enrolled in a channel won't sit anywhere near the January 25 deadline — Google auto-upgrades them on the channel's own schedule, with the Regular channel expected to move clusters to 1.36 sometime in November (an estimate Google already pushed back from October)1. Clusters that leave the channels entirely don't get indefinite pinning either: once standard support ends, the control plane is upgraded to the next minor version1.

The fallback is the Extended channel, which keeps 1.34 clusters running — at the same $0.60 per cluster-hour price point AWS charges — until November 25, 2027, with one final safety valve in the form of a 90-day emergency exclusion that comes with no support at all1. GKE adds one quirk that teams should not rely on: clusters using APIs deprecated in the next minor version may get their auto-upgrades paused, but Google frames that pause as conditional, not guaranteed4.

AKS: the quiet one is the dangerous one

AKS is the outlier in temperament. When 1.34 reaches end of life on November 30, nothing dramatic happens — the cluster keeps serving traffic, node pools keep scaling, and the infrastructure SLA holds1. What stops is everything that matters long-term: Microsoft's platform-support documentation is explicit that security patches and Kubernetes component support, including add-ons, are not supported in that stage, and new 1.34 clusters can't be created12.

The forced upgrade arrives later, when the cluster is about to fall out of platform support entirely — for 1.34, that means when 1.38 reaches GA on AKS — at which point the control plane is bumped to the oldest fully supported minor version1. Azure also reserves the right to force an upgrade if a cluster falls three or more minor versions behind3. The practical reading: AKS buys you the most time before anything visible happens and the least protection while you wait.

What breaks on the road from 1.34 to 1.37

Because all three providers upgrade one minor version at a time outside their LTS tiers, a 1.34 cluster reaching 1.37 passes through three separate upgrades, each with its own removals. The 1.34-to-1.35 hop defaults the failCgroupV1 gate to true, which means kubelets won't start on cgroup v1 nodes, and removes the --pod-infra-container-image kubelet flag outright — clusters still setting it fail to start1. The 1.35-to-1.36 hop permanently disables gitRepo volumes, workloads mounting them stop working, and renames a set of metrics that silently break alerting rules written against the old names1. The 1.36-to-1.37 hop removes 25 feature gates and 18 kubelet flags1. GKE additionally begins enforcing exec probe timeouts, so probe commands slower than their configured timeoutSeconds start failing1.

The CI/CD angle: make upgrades a pipeline concern, not a crisis

This is where CI/CD tooling earns its keep. The old model — a scheduled maintenance window, a manual aws eks update-cluster-version run, a nervous Slack thread — doesn't scale against a calendar where three providers can move your control plane on three different dates, one of them without notice. The upgrade has to become something pipelines and policy tooling do continuously.

Concretely, that means several things. First, drive upgrades through infrastructure-as-code and GitOps rather than consoles: AWS's own migration guidance centers on eksctl and the CLI precisely because those are automatable from a pipeline, and Terraform-based flows let a version bump go through the same PR review, CI checks, and staged rollout as any other change10. Second, add version drift as a first-class CI check — a policy gate that fails a build when the cluster's minor version is more than N versions behind, or when a deadline is inside 30 days, turns the EOL calendar into a routine pipeline failure instead of a production incident10.

Third, test against the breaking changes above deliberately. The cgroup v2 default, the kubelet flag removals, and the metric renamings are all things a CI environment can catch before production does — running pre-upgrade conformance jobs in a canary cluster on each target minor version is the single highest-value investment here. Fourth, remember that managed add-ons and node groups lag the control plane on every platform: a pipeline that upgrades the control plane but never re-runs node-image rollouts leaves a fleet of kubelets on the old version, quietly accumulating the exact compatibility failures the changelog warns about1.

Finally, the ecosystem lag is real and often underestimated. Supporting tooling — service meshes, monitoring stacks, security add-ons, and CI/CD systems themselves — needs time to catch up with new Kubernetes APIs and behaviors, which is a long-standing argument for trailing the bleeding edge by a minor version or two11. The flip side of that advice is that "trailing" has a hard limit now defined by provider calendars, not by your own comfort.

The takeaway

October 27 is a real deadline, but it is upstream's deadline. The deadlines that will actually change your operations are December 2 on EKS (price), November 30 on AKS (security patches), and either January 25 or an automatic channel-driven date on GKE (control plane version)12. Teams that treat Kubernetes version management as a CI/CD concern — IaC-driven upgrades, drift detection in the pipeline, conformance tests per minor version — will barely notice the transition. Teams that treat it as a quarterly ops task are on track to discover their control plane was moved for them, on a date they never saw coming.