# Kubernetes 1.34 Hit End of Life Oct 27: What EKS, GKE and AKS Do Next URL: https://www.devopsness.com/blog/kubernetes-1-34-end-of-life-eks-gke-aks-upgrade Author: Kiril Urbonas Published: 2026-10-31 Updated: 2026-10-31 Categories: Cloud Tags: Kubernetes, EKS, Upgrades, Cloud, FinOps Summary: Upstream stopped patching 1.34 on October 27. EKS starts billing 6x on December 2, AKS drops it at the end of November, and GKE gives you until January. The dates, the commands to find your 1.34 clusters, and the upgrade order. --- # 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. > [!VERIFIED] > Kubernetes 1.34.12 and 1.35.9, against the kubernetes.io releases page, the Amazon EKS version lifecycle and pricing pages, the AKS supported versions calendar and the GKE release schedule. Checked October 2026. 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 | Provider | 1.34 end of standard support | What happens next | Extra cost | Hard stop | |---|---|---|---|---| | Upstream | October 27, 2026 | No more releases | n/a | Already passed | | Amazon EKS | December 2, 2026 | Extended support starts automatically (default policy) | $0.60/hr instead of $0.10/hr per cluster | December 2, 2027, then control plane auto-upgrade | | Amazon EKS, extended disabled | December 2, 2026 | Control plane auto-upgraded at end of standard support | None | December 2, 2026 | | Azure AKS, community | November 30, 2026 | Platform support only, then a 60-day grace period, then platform-initiated upgrade | None | Upgrade rollout planned for June 2027 | | Azure AKS, LTS | November 2027 | LTS keeps patches; upgrade to the next LTS afterwards | LTS pricing | Platform-initiated upgrade planned for February 2028 | | Google GKE | January 25, 2027 | Auto-upgrade, unless on the Extended channel | Extended channel fee during extended period | November 25, 2027 on Extended | 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. ```bash # 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: ```bash $ 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: ```bash $ 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](/blog/kubelet-cgroup-v1-kubernetes-1-35) 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. ```bash $ 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](/blog/kubernetes-pod-disruption-budgets-node-drains) 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](/blog/best-managed-kubernetes) covers how each provider handles upgrades. ## Sources - [Kubernetes releases (end of life dates)](https://kubernetes.io/releases/) - [Amazon EKS: Kubernetes version lifecycle and release calendar](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html) - [Azure AKS: Supported Kubernetes versions](https://learn.microsoft.com/en-us/azure/aks/supported-kubernetes-versions) - [GKE release schedule](https://docs.cloud.google.com/kubernetes-engine/docs/release-schedule)