Kubernetes 1.34 entered maintenance mode on August 27, 2026 and reaches end of life on October 27, 2026, exactly one year and two months after its August 27, 2025 release. Those are the upstream dates published on the project’s own release page, and after the second one there are no more patches — including for security issues.
The uncomfortable arithmetic: getting from 1.34 to a release that will still be supported after October means two minor-version hops, and the version skew policy does not permit skipping. This runbook is the sequence, the gates between steps, and the specific things that break at each one.
First, Check Whose Deadline You Are Actually On
If you run managed Kubernetes, the upstream EOL date is not necessarily your date. EKS, GKE, and AKS each publish their own end-of-support schedules, and all three offer some form of extended support that keeps a version patched past the upstream cutoff — usually at a higher per-cluster price and always with its own end date.
Look up your provider’s published date for 1.34 before you plan anything. There are two failure modes here and they are opposite: teams that panic against the upstream date when their provider has given them longer, and teams that assume extended support is indefinite when it has a date of its own and a cost attached. Neither is a reason to skip the upgrade; both change how much room you have to sequence it.
For self-managed clusters, the upstream date is the date. October 27, 2026.
The Skew Policy Sets the Path
You cannot go from 1.34 to 1.37 in one step. The control plane upgrades one minor version at a time, so the path is 1.34 → 1.35 → 1.36, with 1.37 available after its August 26, 2026 release if you want to land further forward.
Nodes have more slack than the control plane. The kubelet may run up to three minor versions behind the API server, which means you can upgrade the control plane and let node pools follow rather than lockstepping every hop. Use that slack deliberately — it is what lets you do two control-plane hops without two full fleet-wide node rollouts — but do not let it become an excuse to leave node pools drifting indefinitely, because the skew window closes as the control plane moves forward.
Pre-Flight: Do This Before the First Hop
Inventory deprecated and removed APIs. This is the single highest-yield pre-flight step and it is fully automatable. Tools in the kubent / pluto family scan live cluster objects and Helm releases for API versions that have been removed or are scheduled for removal, and kubectl convert will rewrite manifests to current versions. Run the scan against the cluster and against your source-of-truth manifests in Git, because the cluster only tells you what is deployed now, not what your CI will apply next week.
Audit static pod manifests. Anything in staticPodPath referencing a Secret or ConfigMap is a problem on the way to 1.37, where that reference is no longer permitted and the feature gate that allowed it has been removed. It costs nothing to fix this during the 1.35 or 1.36 hop rather than discovering it on the last one.
Confirm cgroup v2 on every node pool. This is the item that turns the 1.34 → 1.35 hop from routine into an outage. Since 1.35, failCgroupV1 defaults to true, and a kubelet on a cgroup v1 node will refuse to initialize unless explicitly overridden in KubeletConfiguration. If any node image in your fleet is old enough to still be on cgroup v1, the fix is a new node image, not a kubelet flag — the override exists to buy time, not to be a configuration you keep.
Snapshot etcd and verify you can restore it. A backup you have never restored is a hypothesis. If your runbook has never been exercised, this is the upgrade to exercise it on, in a non-production cluster, before the first hop.
Check your add-ons against each target version. CNI plugin, CSI drivers, ingress controller, service mesh, admission webhooks, operators. Add-on incompatibility causes more failed Kubernetes upgrades than the core components do, and the compatibility matrix that matters is the one published by each add-on vendor, not the Kubernetes release notes.
Hop One: 1.34 → 1.35
The cgroup v1 change is the headline risk, and the pre-flight above should have removed it. Beyond that, treat this as a standard control-plane upgrade: upgrade the control plane, verify API server health and controller-manager and scheduler leader election, then roll one node pool.
The gate before you proceed: one canary node pool running the 1.35 kubelet, carrying a representative workload class, held long enough to produce real metrics across a normal traffic cycle — not a smoke test. Watch pod start latency, OOM kills, and eviction events specifically, because cgroup-related behavior changes show up there first.
Hop Two: 1.35 → 1.36
1.36 is the security-defaults release. User Namespaces, Mutating Admission Policies, and Fine-Grained Kubelet API Authorization all reached GA, and the practical effect is that assumptions from the 1.2x era stop holding.
The workloads most likely to break are the ones that assumed root-in-container was free: images that write to host-protected paths, init scripts that chown system directories, and Helm charts hardcoding runAsUser: 0 without a capabilities review. Scan for privileged pods before you flip any cluster-wide policy, and turn User Namespaces on per-workload rather than fleet-wide on the first pass.
Mutating Admission Policies are worth a separate look if you are carrying mutating webhooks. Some webhook glue can now be replaced with in-tree policy, which removes a network hop and a failure mode from the admission path — but that is a migration to do deliberately after the upgrade is stable, not during it.
After: Where to Stop
1.36 puts you on a supported release with room ahead of it, and that is a legitimate place to stop. 1.37, released August 26, 2026, is the further-forward option, and its own set of changes — the static-pod restriction becoming unconditional, ipvs mode entering formal deprecation — are things you will have to absorb eventually anyway.
The decision rule that holds up: if the fleet is stable on 1.36 and your add-ons are all certified for it, stop there and schedule 1.37 as its own project with its own canary window. Chaining a third hop onto the end of a deadline-driven migration is how teams turn a successful upgrade into an incident.
Whichever you choose, get off 1.34 before October 27. After that date an unpatched CVE in the control plane has no upstream fix, and “we were mid-migration” is not a mitigation anyone accepts after the fact.
