Kubernetes 1.34 reaches end of life on October 27: an upgrade plan for EKS teams

The Kubernetes project lists October 27, 2026 as the end of life date for version 1.34. The 1.34 patch series entered maintenance mode on August 27, 2026, a two-month period in which fixes are limited to vulnerabilities with an assigned CVE ID, dependency issues, and critical core component issues. The project now maintains release branches for 1.37, 1.36, and 1.35. Kubernetes 1.37 was released on August 26, 2026, and Amazon EKS made it available on October 1, 2026.

For clusters you run yourself, the upstream date is the one that matters. On Amazon EKS the calendar is different, and it is easy to misread.

What the dates mean on Amazon EKS

EKS gives each Kubernetes version 14 months of standard support, followed by 12 months of extended support. For 1.34, the EKS release calendar shows standard support ending on December 2, 2026 and extended support ending on December 2, 2027. Three points are worth knowing:

Extended support is enabled by default and costs more. AWS describes it as letting you stay on a version longer "at an additional cost per cluster hour."
If you disable extended support, the cluster is upgraded automatically at the end of standard support.
At the end of extended support, EKS upgrades the cluster to the next version automatically. That upgrade covers only the control plane. Instances in managed node groups are not upgraded for you.

Older versions are further along the same path. Kubernetes 1.33 left EKS standard support on July 29, 2026, and extended support for 1.31 ends on November 26, 2026.

Plan one minor version at a time

EKS updates a cluster only one minor version at a time, and upstream policy also requires that the API server not skip minor versions. Moving from 1.34 to 1.37 is therefore three upgrades: 1.35, 1.36, then 1.37. Before each control plane update, AWS says managed nodes and Fargate nodes must be on the same minor version as the control plane.

There is now a safety net. On July 1, 2026 AWS announced version rollbacks for EKS, which let you return a cluster to the previous minor version within seven days of an upgrade. After seven days the documented option is to create a new cluster on the earlier version and migrate workloads.

What to check before each step

The EKS release notes flag changes that need action. The ones most likely to affect an existing platform are:

1.35: the kubelet, the agent that runs on every node, refuses to start by default on nodes that use cgroup v1. Amazon Linux 2023 uses cgroup v2 by default. Version 1.35 is also the last release that supports containerd 1.x, so move to containerd 2.0 or later before going further. Custom images must drop the removed --pod-infra-container-image kubelet flag.
1.36: the gitRepo volume type is permanently disabled, and the kubelet refuses to run Pods that use it. AWS points to init containers or a git-sync sidecar as replacements. Strict IP and CIDR validation is on by default, so new creates and updates with leading zeros or non-canonical CIDR values are rejected. Review manifests, Helm charts, and automation.
1.37: the SELinuxMount feature is enabled by default. On nodes with SELinux enabled, a Pod can stay in ContainerCreating if another Pod on the same node already uses the same volume with a different SELinux label. Nodes without SELinux enabled are not affected. The kubelet also drops the container_cpu_load_average_10s, container_cpu_load_d_average_10s, and container_tasks_state metrics, so update dashboards and alerts that use them.

A short checklist

List the control plane and node versions of every cluster, and flag anything on 1.34 or older.
Review EKS cluster insights, which scan for issues that affect upgrades, such as deprecated Kubernetes API usage.
Confirm that the cluster subnets have free addresses. EKS requires up to five available IP addresses to update a cluster.
Choose the upgrade policy on purpose. Staying on the default means paying for extended support once standard support ends. Changing it means accepting an automatic upgrade when standard support ends.
Upgrade a non-production cluster first, update nodes after each control plane step, and use the seven-day rollback window to watch for regressions before taking the next step.