Kubernetes 1.34 Hit End of Life Oct 27: What EKS, GKE and AKS Do Next

Kubernetes 1.34 reached upstream end of life on October 27, 2026, so 1.34.12 is the last patch it will ever get. Your managed provider decides what happens next: EKS starts charging six times the control plane rate on December 2, AKS drops 1.34 at the end of November, and GKE keeps it on standard support until January 25, 2027.

End of life upstream means the community stops cutting 1.34 releases. The last one, 1.34.12 on September 15, closed CVE-2026-19444, the Windows-only kubectl cp path traversal that let a malicious tar in a container write anywhere on the user's machine. The next bug like that gets a fix in 1.35.x and newer only. Providers can backport to their own builds for a while, and that is exactly what you pay for, or lose, from here.

The deadlines, side by side

AKS publishes months, not days, and treats a month as its last day, so "Nov 2026" means November 30. Dates are as of October 31, 2026.

Find every 1.34 cluster you own

Run these per account, project or subscription. The EKS loop also prints the upgrade policy, which tells you whether December 2 means a bill or a forced upgrade.

# EKS: version and support type per cluster in the current region
$ for c in $(aws eks list-clusters --query 'clusters[]' --output text); do
    echo "$c $(aws eks describe-cluster --name "$c" \
      --query 'cluster.[version,upgradePolicy.supportType]' --output text)"
  done
$ aws eks describe-cluster-versions          # end-of-support dates EKS reports

# GKE: control plane version and release channel
$ gcloud container clusters list \
    --format="table(name,location,currentMasterVersion,releaseChannel.channel)"

# AKS: version, tier and support plan (KubernetesOfficial vs AKSLongTermSupport)
$ az aks list --query "[].{name:name, rg:resourceGroup, version:currentKubernetesVersion, tier:sku.tier, plan:supportPlan}" -o table

Node pools can lag the control plane, so also run kubectl get nodes and read the VERSION column. A 1.35 control plane with 1.34 kubelets is legal under the skew policy, but it is still a 1.34 fleet for patching purposes.

The extended support math

EKS charges $0.10 per cluster-hour on standard support and $0.60 on extended, as of October 2026. The difference is $0.50 an hour, about $365 a month or $4,380 a year per cluster at 730 hours a month. Ten forgotten dev clusters is roughly $43,800 a year for the privilege of not upgrading. Billing starts at 00:00 UTC on the end of standard support date, and extended support is the default for new and existing clusters. If you would rather be forced than billed, switch the policy:

$ aws eks update-cluster-config --name dev-cluster --upgrade-policy supportType=STANDARD

Be sure that is what you want: with STANDARD, EKS upgrades the control plane for you at the end of standard support, on its schedule, and managed node groups stay behind until you move them. GKE's Extended channel also adds a cluster management fee once a version enters its extended period; check the GKE pricing page for the current rate. AKS LTS requires opting in and is never automatic.

The upgrade, in the order that does not hurt

1. Scan for removed APIs against 1.35. The upstream deprecation guide lists no removals for 1.35 (the most recent removal was in 1.32), but Helm releases and old manifests hide surprises, so run the scanners anyway:

$ kubent --target-version 1.35.0
$ pluto detect-all-in-cluster --target-versions k8s=v1.35.0
$ aws eks list-insights --cluster-name prod --filter categories=UPGRADE_READINESS

2. Check your nodes for cgroup v1. Since 1.35 the kubelet refuses to start on cgroup v1 by default, the most common way this particular upgrade breaks. Our cgroup v1 kubelet fix has the one-line check.
3. Upgrade the control plane one minor at a time. No skipping: 1.34 to 1.35, then 1.35 to 1.36 if you are going further. EKS states it outright, and AKS refuses non-LTS skips.

$ aws eks update-cluster-version --name prod --kubernetes-version 1.35
$ gcloud container clusters upgrade prod --master --cluster-version=1.35 --location=europe-west1
$ az aks upgrade -g rg-prod -n prod --kubernetes-version 1.35 --control-plane-only

4. Upgrade node pools, with surge and PodDisruptionBudgets that allow at least one eviction. Our PDB and node drain guide covers why rollouts stall.
5. Upgrade add-ons (VPC CNI, CoreDNS, kube-proxy on EKS; cluster-autoscaler to the matching minor) and finally your kubectl clients, which must stay within one minor of the control plane.

AWS documents the order as control plane, nodes, then add-ons. Some teams bump add-ons right after the control plane; either works as long as each add-on version supports both minors during the window.

Where this breaks

AKS platform-initiated upgrades do not follow your maintenance window, do not stop for deprecated API usage, and can override a PodDisruptionBudget that blocks a drain, per Microsoft's docs. You also cannot create new 1.34 clusters during AKS platform support, which breaks any pipeline that spins up ephemeral 1.34 test clusters. On EKS, a cluster auto-upgraded at the end of extended support cannot be rolled back, while a manual upgrade can be within 7 days. And extended support patches the control plane and AWS-published components, not your Helm charts or operators pinned to 1.34 behavior.

Questions people ask

What happens to my EKS cluster when Kubernetes 1.34 standard support ends?

On December 2, 2026, a 1.34 EKS cluster with the default EXTENDED upgrade policy moves to extended support and is billed $0.60 per cluster-hour instead of $0.10. It keeps getting control plane security patches until December 2, 2027, then EKS auto-upgrades the control plane. With the policy set to STANDARD, EKS auto-upgrades the control plane at the end of standard support instead.

Can I skip from Kubernetes 1.34 straight to 1.36?

Not on the control plane. EKS upgrades one minor version at a time, and AKS requires one-minor steps for non-LTS clusters, so 1.34 to 1.36 means two upgrades with a health check between them. Node pools are more flexible: kubelets may run up to three minors behind the API server, so you can move nodes once at the end.

When does AKS stop supporting Kubernetes 1.34?

AKS lists 1.34 end of life as November 2026, which means November 30. After that the version gets platform support only until 1.38 is GA, then a 60-day grace period before AKS upgrades the cluster itself, with that rollout planned for June 2027. Clusters explicitly enrolled in LTS keep support until November 2027.

The call we'd make

Upgrade every 1.34 cluster to 1.35 in November, before AKS end of life and well before the EKS billing switch on December 2. Treat extended support as a deliberate, budgeted exception for one or two clusters with a real blocker, never the default, because at $4,380 per cluster per year it is the most expensive way to postpone a routine upgrade. The caveat is GKE: you have until January 25, but the 1.35 cgroup v2 requirement is the same, so do the node audit now. If you are choosing where to run next, our managed Kubernetes comparison covers how each provider handles upgrades.

Sources

• Kubernetes releases (end of life dates)
• Amazon EKS: Kubernetes version lifecycle and release calendar
• Azure AKS: Supported Kubernetes versions
• GKE release schedule