Conceptual illustration of the support timelines the article compares. The picture labels Azure's later date Extended Support, the article's table calls it LTS.
Kubernetes 1.34 reaches the end of its upstream support lifecycle on October 27, 2026. After that date, the Kubernetes project will no longer routinely provide security updates or bug fixes for the 1.34 release branch.
For organizations operating their own Kubernetes control planes, that deadline matters directly. A cluster running 1.34 can continue serving workloads, but newly discovered issues may no longer receive upstream fixes for that version.
The situation is different for teams running managed Kubernetes.
Amazon EKS, Azure Kubernetes Service (AKS) and Google Kubernetes Engine (GKE) maintain their own release schedules and, in some cases, extended-support options. A cluster running Kubernetes 1.34 on one provider may therefore remain supported longer than the same minor version on another.
The immediate operational question is not simply whether a cluster is running 1.34. It is who maintains that distribution, what support period applies, and whether the cluster can complete a supported upgrade without disrupting its workloads.
One Kubernetes version, four support timelines
The Kubernetes project currently maintains the three most recent minor branches: 1.35, 1.36 and 1.37. Version 1.34 entered maintenance mode on August 27, 2026, and its latest listed patch at the time of this review is 1.34.12.
Managed providers extend or otherwise manage support through their own tested releases, maintenance policies and lifecycle arrangements.
| Platform | Kubernetes 1.34 support deadline | What it means |
|---|---|---|
| Upstream / self-managed | October 27, 2026 | Upstream patch releases end (since August 27 only critical security fixes have been accepted) |
| Amazon EKS | Standard: December 2, 2026. Extended: December 2, 2027 | Extended support is on by default (upgrade policy EXTENDED) at an additional cost per cluster hour. At the end of extended support the cluster is upgraded automatically |
| Azure AKS | Standard end of life: November 2026. LTS: November 2027 | Extended lifecycle depends on enrollment and eligibility. The published months are not exact dates |
| Google GKE | Standard: January 25, 2027. Extended: November 25, 2027 | Extended support applies only to clusters enrolled in the Extended release channel |
Sources: Kubernetes release schedule, Amazon EKS lifecycle, AKS supported versions, and GKE release schedule. Dates are current as of October 26, 2026, and provider schedules can change.
The differences are operationally important.
An EKS team with a cluster approaching the December standard-support deadline may have time to schedule a controlled upgrade, although extended-support charges and eventual provider-managed upgrades affect that decision.
For AKS, the exact cluster support position depends on its lifecycle enrollment and supported version. Long-term support is never enabled automatically. A cluster must be explicitly enrolled.
GKE’s Extended channel keeps a minor version supported until its end of extended support, while clusters on the other release channels (Rapid, Regular and Stable) follow the standard support and automatic upgrade schedule.
A self-managed cluster does not receive any of those arrangements merely because its upstream components remain operational. Continued support would require an appropriate distribution vendor, support provider or internally maintained patch strategy.
What platform teams should check first
Before changing a cluster, establish its actual control-plane version and the versions running on its nodes.
For a cluster accessible through kubectl, two useful commands are:
kubectl version
kubectl get nodes -o wideThe first reports client and server version information. The second shows node details, including kubelet versions.
These commands establish a starting point, but they do not tell an operator whether the managed service’s support policy covers that version.
For EKS, AKS or GKE, check the cluster’s configured Kubernetes version, release channel or support policy in the provider’s management interface or CLI. Include node pools and separately managed components in the inventory.
The control plane and nodes do not necessarily move to a new minor version at the same time.
A managed provider may upgrade the control plane automatically while requiring separate action for some node groups. Self-managed clusters usually require operators to coordinate both parts of the process.
An inventory should therefore capture the Kubernetes distribution, control-plane version, node and node-pool versions, support deadline, upgrade policy and any documented maintenance restrictions.
That information determines whether the next step is an urgent unsupported-version upgrade, a planned maintenance change or verification that an extended-support arrangement is already active.
Plan the upgrade around compatibility, not only the date
For self-managed Kubernetes clusters using kubeadm, upgrading from 1.34 to 1.35 is the supported next minor-version step. Skipping directly from 1.34 to 1.36 or 1.37 is not supported by the kubeadm upgrade process.
Managed services may automate portions of the upgrade, but their supported paths and prerequisites must be followed separately.
Kubernetes also maintains a version-skew policy governing the versions of control-plane components, kubelets and other cluster services.
A kubelet must not be newer than the API server it communicates with. Under the current policy, it can generally be up to three minor versions older, subject to additional restrictions in clusters with mixed API-server versions.
This allows control-plane and node upgrades to occur in stages, but it does not mean every version combination is supported.
The Kubernetes project recommends updating to the latest patch in the current minor release and then targeting the latest available patch in the next minor release.
Before upgrading production clusters, the more consequential compatibility checks involve components that interact closely with the Kubernetes API.
Admission webhooks may depend on API versions or fields that change between releases. Network and storage components must support the target version. Operators, custom resource definitions and cluster add-ons may also require upgrades.
Workloads need attention as well. PodDisruptionBudgets, replica availability, scheduling constraints and storage behavior determine whether nodes can be drained without unacceptable interruption.
A minor-version upgrade that succeeds at the API-server level is not necessarily a successful application upgrade if essential workloads fail to reschedule or an incompatible add-on stops functioning.
A practical upgrade-readiness check
For teams still running 1.34, the following assessment is a reasonable starting point.
- Support: Confirm the actual distribution support deadline and whether extended support is enabled, available or subject to additional charges.
- Compatibility: Review deprecated API usage, admission webhooks, CRDs, controllers, CNI and CSI drivers, and required cluster add-ons against the target version.
- Availability: Verify workload replicas, PodDisruptionBudgets, node capacity, draining behavior and maintenance windows.
- Recovery: Confirm the relevant backup and restore procedures, including etcd recovery for self-managed control planes, and understand the provider’s limitations on downgrading or rolling back.
- Validation: Test the upgrade on a representative non-production cluster or node pool, then monitor workload health, networking, storage and application error rates during production rollout.
These checks should be proportionate to the environment. A small development cluster and a multi-region production platform do not need identical change procedures, but both need a known upgrade path.
Teams should also avoid assuming that extended support is the same as postponing every upgrade obligation. It offers additional time under the provider’s stated conditions, not permanent maintenance of a particular Kubernetes version.
What changes after October 27?
For self-managed Kubernetes 1.34 environments relying on upstream maintenance, October 27 marks the end of routine fixes for that branch. Organizations that remain on it must accept or independently manage the resulting maintenance risk.
For EKS, AKS and GKE, the deadline is a reminder to verify the provider-specific lifecycle rather than a signal that all managed 1.34 clusters become unsupported overnight.
The right decision depends on the operating model. An organization with a tested upgrade path may reasonably advance to a supported minor version now. Another may use a formally supported extension to complete compatibility work and schedule a lower-risk change.
What should not happen is allowing a cluster to remain on an aging version because the workloads appear healthy and nobody has confirmed who is responsible for maintaining it.
Kubernetes 1.34’s upstream lifecycle ends on October 27, 2026. The operational responsibility is to establish the deadline that actually applies to each cluster and complete a supported, tested upgrade before that coverage expires.
Go deeper
- Kubernetes: Version 1.34 Release Schedule. Official release lifecycle, maintenance-mode date and upstream end-of-life deadline.
- Kubernetes: Version Skew Policy. Supported version relationships among API servers, kubelets, controllers and other cluster components.
- Kubernetes: Upgrading kubeadm Clusters. Official self-managed upgrade process and minor-version sequencing requirements.
- Amazon EKS: Kubernetes Version Lifecycle. EKS standard and extended-support dates, version policies and related billing considerations.
- Microsoft Learn: Supported Kubernetes Versions in AKS. AKS standard lifecycle, long-term support and platform-initiated upgrade schedules.
- Google Cloud: GKE Release Schedule. GKE standard and extended-support dates, release-channel availability and upgrade scheduling.
Related reading on this site
- Ingress-NGINX Is Retired: What Kubernetes Teams Should Do Next, on another Kubernetes component that has reached the end of security fixes and how to plan the move.
- Kubernetes 1.37: Three Changes Platform Teams Should Understand Before Upgrading, on the newest minor release this article lists among the supported branches.
Research reviewed October 26, 2026. Support dates are time-sensitive and should be rechecked against provider documentation before publication or operational changes. This article describes lifecycle and upgrade planning. It does not replace platform-specific upgrade instructions.