What is happening

Kubernetes 1.34 reaches end of life on 27 October. Its last patch release is 1.34.12. From then on the project does not publish fixes for it, including security fixes, so a cluster that stays on 1.34 is exposed to every flaw found later.

Check your clusters

Find out which version each cluster runs, and which version its nodes run: they can differ.

kubectl version
kubectl get nodes -o wide

Include every cluster: production, staging, test and the ones created for one project and never removed. If a provider runs the control plane for you, check its own support timeline for your version, because managed services often have their own dates and may keep a version supported longer or shorter.

Plan the upgrade

  • One minor version at a time. Kubernetes supports upgrading from one minor version to the next, so a jump of several versions means several upgrades.
  • Control plane first, then nodes. Keep the nodes within the allowed version difference from the control plane.
  • Read the release notes for every version you pass, looking for removed APIs. Manifests and tools that use a removed API stop working after the upgrade.
  • Try it on a non-production cluster before production, and keep a way to roll back.

If you cannot upgrade in time

Schedule the upgrade, write down who accepted the risk until then, and reduce exposure in the meantime: keep the API server off the public internet, keep workloads isolated, and watch the project's security announcements for flaws that affect your version.

A note on LineXa Studio

Applications deployed with LineXa Studio run on managed Cloud Run services, not on a Kubernetes cluster you operate, so there is no cluster of ours for you to upgrade.

In short

Find every cluster, check its version, and book the upgrade before 27 October. If you would like help planning it, book a Kubernetes Upgrade Planning and Cloud Architecture Review and we will plan it with you.