Kubernetes 1.34 End of Life: What It Costs to Stay On It

Upstream stops patching Kubernetes 1.34 on 27 October 2026, and on most clusters running it nothing visible happens that day. No alert fires. A kubeadm node pointed at the v1.34 package repository is never offered anything newer than a 1.34 patch, so apt keeps calling the Kubernetes packages current right up to the moment somebody reads a CVE against them.

Kubernetes 1.34 end of life means four different things depending on who runs the control plane. CloudSpinx builds and operates Kubernetes clusters for organizations in Kenya, on hardware in your rack or a Nairobi facility and on EKS, AKS and GKE, and the date that decides an upgrade plan is almost never the upstream one. On EKS it is 2 December, and it arrives with a bill six times the usual rate. On your own hardware it is 27 October, and nothing arrives at all.

When does Kubernetes 1.34 reach end of life on your platform?

Upstream end of life is 27 October 2026, on the Kubernetes patch release calendar. Each managed service then sets its own window, and what happens when that window closes differs more than the dates do.

The EKS row carries the trap. AWS turns extended support on for new and existing clusters alike. You can switch a cluster's upgrade policy to STANDARD, which tells AWS to upgrade it rather than bill it, but only while it is still in standard support: AWS will not let you disable extended support once a cluster has entered it. For 1.34 that makes 2 December the real decision date. After it, only an upgrade stops the meter.

GKE defaults the other way. Outside the Extended channel Google upgrades the cluster for you, and once a version is past end of support it upgrades nodes even with auto-upgrade switched off. Google calls its own dates best-effort predictions, which is why the table says "about".

Read the AKS row twice. Microsoft's supported versions page says a platform-initiated upgrade does not follow your maintenance window, does not stop for deprecated API usage, and can override a Pod Disruption Budget that blocks a node drain. June 2027 is Microsoft's planning month for 1.34, not a date on your calendar. OpenShift is a fifth answer again, with its own release calendar layered over upstream.

The first row is the quiet one, and with no hyperscaler region in Kenya it is where a cluster ends up when its data has to stay in the country. On kubeadm it carries a second clock: client certificates expire after a year, and a control-plane upgrade is what renews them, so the cluster nobody upgrades is also counting down to the day its own admin credentials stop working.

What extended support costs per cluster

USD 0.60 per cluster-hour against USD 0.10, on EKS and on GKE's Extended channel alike. Over AWS's 730-hour month that is USD 438 instead of USD 73, so each cluster costs USD 365 more every month it sits on an old version.

Ride 1.34's whole extended year on EKS, 2 December 2026 to 2 December 2027, and that is 8,760 hours at USD 0.50 extra: USD 4,380 per cluster. A production, a staging and a dev cluster make USD 13,140. After 2 December 2027 AWS upgrades all three anyway, with no notice and no set day, and the version it lands them on is 1.35, which by then is billing extended rates too.

We do not tell every client to avoid it. USD 365 a month for one cluster buys a year to rehearse the hops on a copy, which is cheaper than an upgrade forced through on a Friday because the date arrived. The mistake is paying it by default, on every environment, with nobody using the time. If you cannot say which of your clusters are already on the meter, send the list through the scoping form and we will mark which ones are, and which hop each one needs first.

Why 1.34 cannot jump straight to 1.37

The control plane has to take every minor in turn. Upstream policy says kube-apiserver may not skip a minor version even on a single instance, and EKS states it plainly: you can update only one minor version at a time. kubeadm enforces it. We wanted the real refusal rather than the docs' paraphrase, so we ran checksummed upstream binaries as an ordinary user: etcd 3.6.5 and a kube-apiserver at 1.34.12, with kubeadm pointed at it. We kept the raw output, and the two errors that matter are below.

kubeadm can upgrade only 1 minor version at a time

Ask kubeadm 1.35.9 to apply 1.36.5 against that 1.34.12 API server and it stops in preflight, even told to ignore preflight errors:

$ kubeadm upgrade apply v1.36.5 --yes --kubeconfig kc/admin.conf --ignore-preflight-errors=all
...
[upgrade/preflight] You have chosen to upgrade the cluster version to "v1.36.5"
[upgrade/versions] Cluster version: v1.34.12
[upgrade/versions] kubeadm version: v1.35.9
error: error execution phase preflight: the version argument is invalid due to these fatal errors:
	- Specified version to upgrade to "v1.36.5" is too high; kubeadm can upgrade only 1 minor version at a time
	- Specified version to upgrade to "v1.36.5" is at least one minor release higher than the kubeadm minor release (36 > 35). Such an upgrade is not supported
Please fix the misalignments highlighted above and try upgrading again

The catch sits one command earlier. kubeadm upgrade plan v1.36.5 from the same binary did not refuse. It printed a plan for the jump, with a note to update kubeadm to v1.36.5 first. Point kubeadm 1.36.5 at the same API server and it refuses a 1.34 cluster before it plans anything:

error: [upgrade/init config] FATAL: this version of kubeadm only supports deploying clusters with the control plane version >= 1.35.0. Current version: v1.34.12

The plan points at a binary that refuses the cluster. Three hops it is, each with its own kubeadm and, on the community packages, its own repository line, because apt will not offer 1.35 until the node's source points at the v1.35 repository.

The same lab answered the question that comes next, which is what those hops break. We started a default 1.34.12 API server and a default 1.37.1 one and diffed what each serves: 65 resource types against 71, six added, none removed. That matches the upstream deprecation guide, whose list of removed APIs stops at 1.32. Manifests written against the built-in APIs are not where this upgrade hurts. The add-ons are: the CNI, the ingress controller, the storage driver and any operator you installed, each on its own release train, and each to check against every hop. On your own hardware the nodes are on the list too: from 1.35 the kubelet will not start on a cgroup v1 host by default, and 1.35 is the last release that supports containerd 1.x, so a cgroup v1 host can fail the very first hop out of 1.34, and a node still on containerd 1.x fails the second. That check belongs in the pipeline that deploys them, so a hop that breaks an add-on fails in staging rather than in production. (Our diff covers default flags only. A beta API you switched on with --runtime-config is your own to check.)

Costing the calendar, not the upgrade

A minor ships about every four months and each one lives 14 months upstream. Keeping a cluster inside support across a three-year budget therefore takes at least six control-plane hops, and that is for a cluster which starts the three years current. One on 1.34 starts three behind.

Each hop is a change window, an add-on review and a test pass, per cluster, per environment. Budget it as a recurring line, the way you budget certificate renewals, or price the alternative honestly: build a new cluster alongside at the current version and move the workloads across, which turns three hops into one cutover and leaves the old cluster standing as the way back. On a cluster several minors behind it is often the safer route, and we price both before recommending either. If you are choosing who does it, the questions we would put to any Kubernetes consultant apply here unchanged.

If you run one EKS cluster and your last upgrade went cleanly, you do not need us for this. Set the upgrade policy before 2 December and take the three hops. Where we earn the fee is the estate with several clusters, a self-managed control plane, or a version nobody has touched since the day it was installed. Send us where each cluster runs, its version and what is installed on it, through the Kubernetes scoping form or on WhatsApp at +254 713 403 044. You get back the hop path for each cluster and one figure for the work, and if a rebuild beats the climb, we handle the move with you. Nothing is owed for that answer.