Kubernetes 1.34 End of Life: What Actually Happens on EKS, GKE, and AKS

Kubernetes 1.34 reaches end of life upstream on October 27, 2026. If you run it on EKS, GKE, or AKS, that date by itself changes very little. Each provider keeps its own support clock, and each one does something different when that clock runs out. EKS upgrades your control plane without notice. GKE upgrades it on its own schedule, later if the cluster is on the Extended channel. AKS upgrades nothing on the day and stops shipping security patches.

For 1.34 itself, the provider dates are:

• EKS: standard support ends December 2, 2026; extended support ends December 2, 2027.
• GKE: standard support ends January 25, 2027; the Extended channel runs to November 25, 2027.
• AKS: end of life November 30, 2026; LTS runs to November 2027.

Between now and the end of the year, these are the dates that change what a cluster does:

Kubernetes support deadlines, October to December 2026

Where only a month is given, that's all the provider publishes. AKS end-of-life months end on the last day of the month. Every row links to its source in the section below.

What "end of support" does on each platform

"End of support" means something different on each platform:

I spent years at Google working with GKE customers, and forced upgrades look different from the provider's side. An unpatched control plane is a liability for the provider as much as for you, which is why every provider eventually moves it for you. They differ in what they move, when, and what they charge you to wait. AKS waits longest: on November 30, an AKS 1.34 cluster keeps serving traffic, keeps scaling, and stops getting security patches.

Kubernetes 1.34 end of life upstream: no more patches after October 27

Kubernetes 1.34 entered maintenance mode on August 27, 2026, and reaches end of life on October 27, 2026. After that, the Kubernetes project ships no more 1.34 patch releases. The next monthly patch release is targeted for October 13, before the cutoff.

The last round landed on September 23: 1.34.12, 1.35.9, 1.36.5, and 1.37.1 fix CVE-2026-2270, where a user who can write StatefulSets and ControllerRevisions in one namespace can get kube-controller-manager to create a Pod in another namespace. If you apply one more 1.34 patch before upgrading, apply that one.

Who a missing patch affects depends on who runs your control plane. On self-managed clusters (kubeadm, k3s, RKE2), a CVE found after October 27 has no 1.34 fix unless your distribution backports it. EKS says it backports security patches to every version it still supports, including extended support. AKS platform support explicitly does not apply security patches.

EKS 1.34 and 1.31: the forced upgrade moves only the control plane

EKS gives every version 14 months of standard support and 12 months of extended support. When extended support ends, EKS upgrades the control plane to the oldest version still supported. The docs are direct about the timing: automatic updates "can happen at any time after the end of extended support date," and "You won't receive any notification before the update."

For 1.31, that date is November 26, 2026. After that date the control plane can be upgraded at any time. The forced upgrade only moves the control plane. Self-managed nodes and managed node groups stay on 1.31 (EKS Auto Mode nodes may update on their own), add-ons stay on whatever versions you pinned for 1.31, and an automatically upgraded cluster can't be rolled back. Whenever it happens, you end up with a 1.32 control plane and 1.31 nodes. That's within the version skew policy, so it runs, but it's a state you never tested.

It also lands you on 1.32, which is itself in extended support until March 23, 2027. However late the forced upgrade comes, the next deadline doesn't move.

For 1.34, the date is December 2, 2026, and what changes is the bill. Extended support is enabled by default, so a 1.34 cluster keeps running and moves from $0.10 to $0.60 per cluster-hour. If you disabled extended support, the cluster is upgraded at the end of standard support instead.

As of September 29, EKS doesn't offer 1.37 yet.

To see where each cluster stands:

# Version and support policy for every EKS cluster in the current 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
 
# The dates EKS will enforce for those versions
aws eks describe-cluster-versions --cluster-versions 1.31 1.32 1.34 \
  --query 'clusterVersions[].[clusterVersion, status, endOfStandardSupportDate, endOfExtendedSupportDate]' \
  --output table

EKS also scans for upgrade problems on its own. Upgrade insights refresh every 24 hours and check for deprecated APIs, kubelet and kube-proxy version skew, cluster health, and add-on compatibility (aws eks list-insights --cluster-name "$c"). They're built around APIs, version skew, and add-ons; the 1.35 changes below live in node configuration, so check those separately.

GKE 1.34: standard support runs to January, the 1.36 rollout starts in October

GKE 1.34 stays in standard support until January 25, 2027, when GKE upgrades clusters outside the Extended channel to the next minor. Most channel-enrolled clusters won't wait that long. Per the release schedule, 1.35 became the auto-upgrade target from 1.34 in late April 2026 on Regular and mid-September on Stable. Rollouts are gradual and follow maintenance windows, so a cluster still on 1.34 may just not have been reached yet, but it may also be held back by a maintenance exclusion, a deprecation pause, or the Extended channel.

For most GKE clusters, what changes this quarter is 1.36. Google's best-effort schedule has the Regular channel targeting 1.36 in October and Stable in December. That's the 1.35 to 1.36 upgrade in the table below: gitRepo volumes, strict IP validation, renamed metrics. Meanwhile Google's schedule has 1.37 reaching Regular on September 30.

GKE's deprecation pause can keep exactly the wrong clusters behind. When GKE detects use of an API that the next minor removes, it pauses automatic minor upgrades until it sees 30 consecutive days without that usage, and it says it "cannot guarantee" the pause. It's a sensible safety valve. It also means the clusters with known upgrade blockers are the ones that stay behind, until end of support upgrades them with the blocker still in place. An emergency "No upgrades" maintenance exclusion can hold that off for up to 90 days past end of support, unsupported the whole time, and no longer.

Two GKE-specific changes on the way to 1.35: GKE now enforces timeoutSeconds on exec probes, so a probe command that takes 3 seconds against the default 1-second timeout, which used to pass, starts failing. Windows Server nodes also move to containerd 2.0.

gcloud container clusters list \
  --format="table(name, location, currentMasterVersion, currentNodeVersion, releaseChannel.channel)"

The Extended channel has its own deadline this quarter: GKE 1.31 reaches the end of extended support on October 22, 2026.

If you need more time, the Extended channel keeps 1.34 until November 25, 2027, at a total of $0.60 per cluster-hour once the version is in its extended period.

AKS 1.34 end of life: nothing happens on November 30, and that's the risk

AKS 1.34 reaches end of life at the end of November 2026. After that it moves to platform support until 1.38 reaches GA. In platform support, node pool scaling, upgrades to a supported version, and the infrastructure SLA all still work. "Applying security patches" and "Kubernetes components (including add-ons)" are listed as not supported, and you can't create new 1.34 clusters.

AKS doesn't upgrade the cluster on November 30. The forced upgrade comes later: when a non-LTS cluster is about to fall out of platform support, which for 1.34 means when 1.38 reaches GA on AKS, AKS upgrades it to the oldest fully supported minor. Clusters on an auto-upgrade channel move sooner. AKS Automatic is always on stable, which targets the second-newest minor, and Standard clusters on stable or rapid follow their channel. The default for Standard clusters is none. If you need patches without upgrading, AKS sells a second year as LTS, which requires the Premium tier and explicit LTS enrollment.

One AKS date this quarter isn't about a Kubernetes version at all. AKS stopped patching Azure Linux 2.0 on November 30, 2025 and froze its node image at 202512.06.0. On October 31, 2026, those images are removed and node pools on them can't scale. Nothing visible happens that day. It breaks the next time the cluster autoscaler, or anyone else, tries to add a node. Azure Linux 3.0 is the default from Kubernetes 1.32, so the pools at risk are AzureLinux pools on 1.31 or earlier: LTS clusters, and clusters already out of support. az aks nodepool update --os-sku AzureLinux3 migrates a pool in place on Kubernetes 1.28 and later.

AKS also stops patching the ingress-nginx-based application routing add-on in November 2026. Microsoft's documented migration target is the Gateway API. Upstream ingress-nginx has been archived since March 2026.

az aks list \
  --query "[].{name:name, resourceGroup:resourceGroup, version:currentKubernetesVersion, channel:autoUpgradeProfile.upgradeChannel, plan:supportPlan, tier:sku.tier}" -o table
 
az aks nodepool list -g "$RG" --cluster-name "$CLUSTER" \
  --query "[].{pool:name, osSku:osSku, version:currentOrchestratorVersion, image:nodeImageVersion}" -o table

When paying for extended support is the right call

EKS and GKE charge the same for extended support: $0.50 per cluster-hour on top of the $0.10 base, which comes to about $365 per cluster per month. For a single cluster with a known blocker and an upgrade scheduled for January, that's cheaper than the engineering time of rushing the upgrade through in December. Across a fleet, it adds up. Forty clusters left in extended support by default cost an extra $175,000 a year.

My rule of thumb: pay for extended support when you can name the blocker and the date you'll fix it. If you can't name the blocker, extended support mostly delays the day you find out what it is.

What breaks between Kubernetes 1.34 and 1.37

EKS, GKE, and AKS (outside LTS) upgrade the control plane one minor version at a time, so a 1.34 cluster reaches 1.37 through three separate upgrades, each with its own removals:

The 1.35 and 1.36 details are in the v1.35 and v1.36 release announcements. The cgroup v1 change is the one that stops nodes: on 1.35, a kubelet on a cgroup v1 host refuses to start unless you set failCgroupV1: false. To check a node, run stat -fc %T /sys/fs/cgroup/ on it. cgroup2fs means v2; tmpfs means v1.

containerd 1.7 has a similar caveat. The 1.35 release told users to move to containerd 2.x before the next Kubernetes version, but the kubelet change that would break 1.7 has since been deferred to 1.38. containerd 1.7 itself reaches end of life this month, and 2.2 follows on November 6.

To see every cluster's control plane, kubelet, and runtime versions from one kubeconfig:

for ctx in $(kubectl config get-contexts -o name); do
  echo "== $ctx: $(kubectl --context "$ctx" version -o json 2>/dev/null \
    | jq -r '.serverVersion.gitVersion // "unreachable"')"
  kubectl --context "$ctx" get nodes --no-headers \
    -o custom-columns=KUBELET:.status.nodeInfo.kubeletVersion,RUNTIME:.status.nodeInfo.containerRuntimeVersion \
    2>/dev/null | sort | uniq -c
done

Checking each upgrade with Radar

We build Radar, an open-source Kubernetes UI, so take this section with that in mind. Its Upgrade impact view (Checks, then the Upgrade impact tab) runs against one cluster at a time and targets the next minor by default. Each check belongs to the release that makes it relevant, so it only runs when your upgrade crosses that release. A 1.34 cluster targeting 1.35 gets node cgroup compatibility and, on GKE, exec probe timeout exposure. A 1.35 cluster targeting 1.36 gets container runtime support, gitRepo volumes, Service externalIPs, strict IP/CIDR validation, and renamed metrics. Every upgrade also gets the standing checks: removed API usage, kubelet and kube-proxy version skew, admission and CRD conversion webhooks, and node drain feasibility.

Here it is on our own GKE nonprod cluster, which runs 1.35 on the Regular channel and is due for 1.36 in October. The 1.36 checks all pass there, but the scan still finds three blockers in webhooks and node drains:

Inspect

If you pick a target more than one minor ahead, the verdict is Blocked and the report lists the upgrade sequence, the same one-minor-at-a-time path EKS, GKE, and non-LTS AKS require. When Radar can't read something, such as kubelet configuration without nodes/proxy access, the check is marked Incomplete rather than passed. Radar doesn't know your provider's dates or release channels; that's what the table at the top is for.

The same scan runs headless over HTTP and over MCP (get_cluster_upgrade_readiness), so you can script it per cluster or hand it to an agent. The 1.37 post has the commands.

Also on the calendar

• Helm 3: bug fixes ended with the final feature release, v3.22.0, on September 9, 2026. Security fixes continue until February 10, 2027.
• Kubernetes 1.38: proposed release on December 16, 2026, which starts the same cycle for 1.35.

Check each cluster before your provider's date arrives. After an automatic upgrade you'll be debugging on whatever version you were moved to.

Radar is open source (Apache-2.0). brew install skyhook-io/tap/radar, point it at a cluster, and open Checks. Or star it on GitHub.