Kubernetes 1.34 stopped receiving patches on 27 October: your real deadline belongs to your provider
On 27 October 2026, Kubernetes 1.34 reached end of life and will receive no further upstream patches. The date that actually matters depends on your platform: 2 December on EKS, 25 January on GKE, 30 November on AKS.
27 October 2026. Kubernetes 1.34 hit end of life: the project will ship no more patches for the branch. The final one, 1.34.12, landed on 15 September 2026 and fixes, among other things, CVE-2026-2270 — a flaw that lets a user who can write StatefulSets and ControllerRevisions in one namespace get kube-controller-manager to create a Pod in another. The point that matters: that upstream date changes almost nothing by itself. What changes everything is your provider’s clock — EKS, GKE, or AKS — and what it charges you to wait.
A fixed death date, but not the same one for everyone
Upstream end of life is the only deadline everyone shares. Kubernetes maintains three minor branches at once: today 1.37, 1.36, and 1.35. 1.34 entered maintenance mode on 27 August 2026, then end of life on 27 October 2026. After that date, a CVE found in the orchestrator core has no 1.34 fix — unless your distribution decides to backport it itself.
So the question is not “am I behind,” but “who is still going to protect me.” The answer varies sharply depending on where the cluster runs:
- EKS: standard support ends 2 December 2026, then extended support kicks in automatically through 2 December 2027. Cluster pricing jumps from $0.10 to $0.60 per hour. If you disabled extended support, AWS upgrades the control plane at the end of standard support.
- GKE: standard support runs to 25 January 2027. On the Extended channel it stretches to 25 November 2027, at $0.60 per cluster-hour.
- AKS: end of life falls on 30 November 2026. The cluster keeps serving traffic and scaling, but Microsoft stops applying security patches — unless you’re on the LTS channel, which requires the Premium tier and runs to November 2027.
Keep the asymmetry in mind: AKS is the quietest on the day itself (nothing moves, but nothing gets patched), while EKS is the bluntest (a control plane upgrade “at any time, without notice” once extended support runs out).
What “no more patches” actually means
CVE-2026-2270 shows the real risk. It was fixed in 1.34.12, the very last patch of the branch. Anyone still applying 1.34 patches should at minimum be on 1.34.12 before planning the move. But an equivalent flaw published on 1 November 2026 will have no 1.34 fix at all.
On a self-managed cluster (kubeadm, k3s, RKE2), that responsibility lands on you. On a managed cluster, it lands on the provider — but not the same way: EKS says explicitly that it backports security patches to every version it still supports, including extended support, while AKS says explicitly that its “platform support” does not apply security patches. Two opposite readings of the same word “support.”
The practical reading is simple. If you are still on 1.34, the last patch already exists and you should apply 1.34.12 now, then schedule the hop. After 27 October, the only fixes you can still get are the ones your provider or distribution chooses to backport — and every one of them is a discretionary choice by someone else, not a guarantee. On AKS, that guarantee is explicitly absent: platform support means the cluster keeps running, not that it stays safe. Self-managed distributions complicate this further, because k3s and RKE2 backport fixes on their own cadence, and their support matrix can disagree with the upstream table by months.
The migration path: one minor at a time
You cannot skip from 1.34 to 1.37. The control plane upgrades one minor at a time: 1.34 → 1.35 → 1.36 → 1.37. That rule is spelled out in Microsoft’s AKS documentation and shared by EKS and GKE. In practice, to land somewhere durably supported, you chain up to 1.36 (end of life 28 June 2027) or 1.37 (end of life 28 October 2027).
Three traps deserve a check before each hop:
- GKE can pause automatic upgrades when it detects use of an API the next minor removes, until it sees 30 consecutive days without that usage. The result: it is precisely the clusters with known blockers that stay behind.
- EKS upgrades only the control plane during a forced move. Self-managed nodes and managed node groups stay on the old version, leaving you in a never-tested skew: a 1.32 control plane with 1.31 nodes.
- AKS removes Azure Linux 2.0 node images on 31 October 2026; the affected node pools can no longer scale.
The operational rule fits in one sentence: plan each hop, don’t endure the provider’s forced upgrade.
# Version and support policy for every EKS cluster in the region
for c in $(aws eks list-clusters --query 'clusters[]' --output text); do
aws eks describe-cluster --name "$c" \
--query 'cluster.[name, version, upgradePolicy.supportType]' --output text
done
# Dates EKS will enforce for those versions
aws eks describe-cluster-versions --cluster-versions 1.34 1.35 1.36 1.37 \
--query 'clusterVersions[].[clusterVersion, status, endOfStandardSupportDate, endOfExtendedSupportDate]' \
--output table
# GKE inventory: master version, node version, channel
gcloud container clusters list \
--format="table(name, location, currentMasterVersion, currentNodeVersion, releaseChannel.channel)"What comes next
End of life for 1.34 is not the year’s last appointment. The Kubernetes 1.38 release is proposed for 16 December 2026, and 1.35 enters maintenance mode on 28 December 2026 — starting the same countdown for clusters still on 1.35. In the adjacent ecosystem, Helm 3 shipped its final feature release (v3.22.0) on 9 September 2026: security fixes continue until 10 February 2027, after which you must have moved.
Keep the version skew policy in mind too: the control plane can only lead the kubelets by a limited number of minors. That is why an EKS forced upgrade that moves only the control plane leaves the nodes behind, and why every hop must cover both: the control plane and the node agents.
Verdict
If you’re still on 1.34, act before your provider’s date, not the project’s: on AKS you have one month before 30 November and the end of patches; on EKS, every day after 2 December costs you $0.50 more per cluster-hour. If your fleet is small or self-managed, take the straight path: upgrade 1.34 → 1.35 → 1.36 before the end of the year, and settle on 1.36 if you want to avoid a second cycle in early 2027. And if you run multi-cloud, never reason in terms of a “supported” version: map every cluster against its provider’s date, because a “1.34” on GKE still has three months of runway where a “1.34” on AKS has one. Upstream end of life is just a line in a table; the real deadline is the one that triggers a bill or a forced upgrade.