Kubernetes 1.34 is end of life – make your next upgrade boring
Kubernetes 1.34 reaches end of life on 27 October 2026. From that day, the upstream project no longer ships patches for it – not even for critical security issues. If some of your clusters still run 1.34, they are now running on borrowed time.
This is not a crisis. It is the normal rhythm of Kubernetes. But how an organisation handles a date like this says a lot about how healthy its platform really is.
The rhythm is predictable – use it
Kubernetes ships roughly three minor releases a year. Each release gets about twelve months of regular patch support, followed by a two-month maintenance period where only critical security fixes are accepted. For 1.34, maintenance mode started on 27 August 2026; the last patch release was 1.34.12 in September. The supported branches are now 1.35, 1.36 and 1.37, and 1.38 is targeted for mid-December.
In practice that means every cluster needs a minor upgrade every four to six months just to stay supported. Anyone who treats upgrades as a yearly project will always be one or two versions behind – and will always be doing them under pressure.
Managed services do not remove the problem
Many managed Kubernetes services follow their own calendars, and several offer extended support for older versions – often at an additional cost or tied to a specific tier. That can buy time, but it does not change the underlying need: the cluster, its add-ons and the workloads on it still have to move forward eventually.
The same applies, perhaps even more, if you run on European or Swedish infrastructure providers for sovereignty reasons. Check which Kubernetes versions your provider currently offers, how quickly new releases become available, and what happens when a version reaches its end of support. Sovereignty and resilience are weakened if your platform cannot keep up with security patches.
Where upgrades actually break
The control plane upgrade itself is rarely the hard part. The trouble usually sits around it:
- Removed or deprecated APIs in manifests, Helm charts and operators that nobody has looked at for a year
- Add-ons and controllers – ingress, CNI, CSI drivers, cert-manager, policy engines – with their own compatibility matrices
- Node images and container runtimes that need to be rolled in step with the control plane
- Workloads without disruption budgets or proper health checks, which turn a routine node drain into an outage
- Snowflake clusters that were configured by hand and can no longer be recreated with confidence
None of these are Kubernetes problems as such. They are platform hygiene problems that an upgrade happens to expose.
Make upgrades boring
The goal is not heroic upgrade weekends. The goal is upgrades so routine that nobody notices them. A few practices make the biggest difference:
- Everything as code. Clusters, node pools and add-ons defined in infrastructure as code, and workloads deployed via GitOps. An upgrade then becomes a reviewed pull request, not a sequence of console clicks.
- Continuous API checks. Scan manifests and charts for deprecated APIs in the pipeline, so problems are found months before the upgrade, not during it.
- An upgrade ladder. Upgrade development and test clusters first, with a fixed soak period, before production follows. Keep the steps small – one minor version at a time.
- Rebuild, don't just upgrade. Regularly create a fresh cluster from code on the target version and deploy workloads to it. If that works, you have also tested your disaster recovery and your exit plan.
- A calendar, not a reminder. Put the end-of-life dates for every version you run into the team's planning. The Kubernetes release pages publish them well in advance.
A quick check for this week
If you are unsure where you stand, three questions are enough to start:
- Which clusters run 1.34 or older today – including test, edge and "temporary" clusters?
- Which of them could you upgrade this sprint, and what is blocking the rest?
- Could you rebuild your most important cluster from code on 1.37 without anyone logging in by hand?
If the answers come quickly, your platform is in good shape. If they don't, the end of life for 1.34 is a useful reason to fix the process rather than just the version number.