Kubernetes 1.34 Reaches End of Life October 27: How to Plan the Upgrade
You cannot skip minor versions, and 1.35 expires in four months. Here is how to sequence the climb without a weekend of surprises.
On this page 7 sections
Kubernetes 1.34 reaches end of life on October 27, 2026, so it stops getting security patches in two days. You cannot jump straight to a newer release, because the project requires upgrading one minor version at a time. Plan the climb now, and aim past 1.35, which expires on February 28, 2027.
This how-to explains the support dates, the upgrade rules from the Kubernetes docs, and a rollout sequence that limits risk. It is written for platform engineers and SRE teams who run their own clusters, or who manage node pools on a hosted service. Backtrace covers the unglamorous parts of infrastructure, and a missed end-of-life date is one of them.
What Is the Kubernetes Support Window Right Now?
Kubernetes supports each minor release for about 14 months: 12 months of standard support, then 2 months of maintenance mode, then end of life on the 28th of the month. Version 1.34 entered maintenance mode on August 27, 2026, and it expires October 27. Only fixes for CVEs and critical issues land during maintenance.
The Kubernetes project's patch release schedule lists the current picture. The table below summarizes it.
| Minor | Latest listed patch | Maintenance mode | End of life |
|---|---|---|---|
| 1.37 | 1.37.1 | Aug 28, 2027 | Oct 28, 2027 |
| 1.36 | 1.36.5 | Apr 28, 2027 | Jun 28, 2027 |
| 1.35 | 1.35.9 | Dec 28, 2026 | Feb 28, 2027 |
| 1.34 | 1.34.12 | Entered Aug 27, 2026 | Oct 27, 2026 |
The next monthly patch releases are targeted for November 10 and December 15, 2026. Timelines can shift with bug severity, and unplanned critical releases may appear between those dates. After October 27, a vulnerability found in 1.34 will not get an upstream fix.
That is the real risk. Nothing breaks on the 27th. The danger is that the next serious CVE arrives and your cluster has no patch path except a rushed upgrade under pressure.
Can You Skip a Minor Version When Upgrading Kubernetes?
No. The Kubernetes version skew policy requires the kube-apiserver to move one minor version at a time, even in a single-instance cluster. Going from 1.34 to 1.37 means passing through 1.35 and 1.36. Each hop is a separate upgrade with its own checks, so plan the time for three.
The version skew policy also sets the limits for every other component. The kubelet may be up to three minor versions older than the API server, but never newer. The kubectl client must stay within one minor version either side.
Here is how the skew rules apply while you climb:
- kube-apiserver: upgrade one minor at a time, and in HA setups keep instances within one minor of each other.
- kube-controller-manager and kube-scheduler: match the API server, or sit one minor older.
- kubelet and kube-proxy: no newer than the API server, up to three minors older.
- kubectl: within one minor of the API server.
The three-minor allowance for kubelets is useful. You can upgrade the control plane through 1.35, 1.36, and 1.37 in sequence while nodes wait on 1.34. There is a catch, though. Nodes that stay three minors behind must be upgraded before the control plane can move again.
What Order Should You Upgrade Components In?
Upgrade the control plane first, then the nodes. The sequence is kube-apiserver, then the controller manager, scheduler, and cloud controller manager, then each kubelet after draining its node, then kube-proxy. Moving the API server first guarantees that older components never talk to a newer API than they understand.
For clusters built with kubeadm, the docs describe a three-phase flow: upgrade the primary control plane node, then any additional control plane nodes, then the workers. Read the release notes before each hop. The kubeadm guide also asks you to back up important state and disable swap.
One detail catches teams out. All containers restart after a kubeadm upgrade, because the container spec hash changes. Schedule the work for a quiet window, and make sure your workloads have enough replicas and sensible disruption budgets so a node drain does not take a service offline.
Admission webhooks deserve their own check. The skew policy notes that webhooks must handle resources and fields from the new version, so update their configuration or set matchPolicy: Equivalent. A webhook that rejects unknown fields can block deploys the moment the API server upgrades.
Backtrace's editors suggest treating the etcd step with extra care. If a kubeadm upgrade also upgrades etcd, in-flight API requests may stall while the static pod restarts. The kubeadm docs recommend stopping the API server gracefully first, then waiting about 20 seconds before running the upgrade.
How Do You Roll Out the Upgrade Safely?
Move in small, reversible steps and rehearse first. Update to the latest patch of your current minor, upgrade a staging cluster through the full path, then roll production one hop at a time. Pause for a soak period after each hop. The Kubernetes docs recommend the latest patch before any minor upgrade.
A workable sequence looks like this:
- Inventory every cluster, its minor version, and who owns it.
- Move each cluster to the latest patch of its current minor, which for 1.34 is the final 1.34 release.
- Rehearse the full path on a staging cluster that mirrors production add-ons.
- Upgrade the production control plane to 1.35, then watch metrics for a day or two.
- Continue to 1.36, and decide whether to stop there or continue to 1.37.
- Drain and replace nodes in batches, starting with the least critical pools.
Where should you stop? Version 1.35 buys you only four months, since it expires February 28, 2027. Version 1.36 lasts until June 28, 2027, and 1.37 until October 28, 2027. Stopping at 1.36 or 1.37 saves you from repeating this exercise in the winter.
Infrastructure-as-code needs the same care. If you manage clusters or add-ons with Terraform, check provider compatibility at every hop. Backtrace's walkthrough on upgrading the Terraform Kubernetes provider to 3.4 covers the pitfalls on that side, and the two upgrades should be sequenced so they do not collide.
Deployment strategy matters while nodes churn. The trade-offs in Backtrace's guide to blue-green versus canary deployments apply directly: canary-style rollouts of your own workloads make it easier to spot a problem introduced by a node upgrade rather than an application change.
What About Hosted Clusters and Node Pools?
Hosted Kubernetes services set their own version calendars, which usually trail upstream. Check your provider's support page for the exact dates that apply to you, because a managed cluster may run a little past upstream end of life, or force an upgrade earlier. Never assume the upstream date is your deadline.
Managed control planes remove much of the manual work, but they do not remove the node side. You still need to move node pools, test add-ons, and confirm that your workloads tolerate the churn. The skew limits apply either way, so a node pool left three minors behind can block the next control plane upgrade.
Many teams find that upgrading node pools by replacement is simpler than upgrading in place. A new pool at the target version lets you cordon the old nodes, drain them in batches, and delete the pool once workloads settle. The kubeadm docs also note that in-place minor kubelet upgrades are not supported, which makes replacement the natural pattern.
Cost is a side effect worth planning for. Running two pools side by side during the swap raises your bill for a few days. Backtrace's guide to Kubernetes cost optimization for small platform teams is a useful companion for sizing the overlap, and for trimming idle capacity afterward.
What Should You Check Before Each Hop?
Before each minor upgrade, read the release notes, scan for removed APIs, confirm webhook and CRD compatibility, and verify add-on versions such as your CNI and ingress controller. Then confirm backups and rollback steps. Most failed upgrades trace back to one of these items being skipped.
The list below is a compact pre-hop checklist you can paste into a runbook.
- Release notes read, with deprecations and removals noted.
- Manifests and Helm charts scanned for removed API versions.
- CNI, CSI, ingress, and monitoring add-ons confirmed compatible.
- Admission webhooks tested against the new version.
- etcd snapshot taken and restore steps verified.
- Pod disruption budgets reviewed for critical services.
Spend time on the rollback story, too. A control plane minor upgrade is hard to undo, so the real rollback is a restore from backup. That makes the etcd snapshot, and a tested restore procedure, worth more than any other single item on the list.
Write the plan into your incident process. Backtrace's incident response runbook checklist is a good template for the communication side: who is on call, who approves a pause, and who decides to stop.
Conclusion
Kubernetes 1.34 loses upstream support on October 27, 2026, and the one-minor-at-a-time rule means the fix takes weeks, not hours. Inventory your clusters this week, patch to the final 1.34 release, rehearse in staging, and climb past 1.35 so you are not back here by spring. Backtrace will keep covering upgrade deadlines as they approach.
