TL;DR
- Kubernetes is an open-source system that runs containerised workloads across a cluster of machines, and its releases follow a numbered minor version that receives patches for a fixed period.
- The releases page lists 27 October 2026 as the end-of-life date for version 1.34 and 1.34.12, released on 15 September 2026, as its latest patch.
- The fourteen months a minor release receives split into twelve months of standard patching and two months of maintenance mode, during which only CVE-tracked vulnerabilities, dependency and base-image issues, and critical core component problems can prompt a release.
- The project maintains three branches at a time: 1.35 closes on 28 February 2027, 1.36 on 28 June 2027 and 1.37 on 28 October 2027.
- The project has released patches after an end-of-life date before, for 1.26, 1.25 and 1.24 when a CVE or a Go update forced it, so the date marks the end of a commitment and the start of an exception process.
- A plan for a small platform team starts with a register of clusters taken from the API, continues with one target version tested against its manifests, and ends with a change window booked inside the monthly patch calendar.
What changes on 27 October 2026
Several things stop on that date, and they are easy to conflate. Cherry picks into the release-1.34 branch close soon after end of life, which means no further patch release for the branch. The project stops treating a defect in 1.34 as something it owes anyone a fix for. The gap between the last maintenance release and the next one widens into permanence.
Netics editorial metric grid of the support model: fourteen months per minor release, twelve months of standard support, two months of maintenance mode, and 27 October 2026 as the end of life for 1.34.
The final two-month maintenance period was already a narrower regime. The project's patch release page describes it as a two-month window in which release managers may cut additional releases for a defined list: vulnerabilities with an assigned CVE ID, under the advisement of the Security Response Committee; dependency issues, base image updates included; and critical core component issues. A bug outside those categories waits for a version upgrade.
The fourteen months a minor release receives
The Kubernetes patch-releases page at https://kubernetes.io/releases/patch-releases/ sets the support period at roughly fourteen months under the project's yearly support KEP: twelve months treated as the standard period, then two months of maintenance mode, then end of life. The 28th of the month was chosen for both dates because every month has one, which is why the calendar reads as a pattern.
That clock starts at release, so the end date is visible from the day a version ships. An operator who tracks a cluster against its upstream version has fourteen months of notice and no dependency on an announcement. The end-of-life date is a published planning target. The project cautions that release timelines may vary with the severity of bug fixes.
The Kubernetes releases page (kubernetes.io/releases/, retrieved 2026-10-23), which lists 1.34 with its latest release 1.34.12 of 2026-09-15 and its end-of-life date of 2026-10-27, beside the three branches that remain active.
Which branches still receive patches
Three branches are active as of 23 October 2026, and the releases page lists each with its latest patch and its end-of-life date. Version 1.37 sits at 1.37.1, released on 15 September 2026, and closes on 28 October 2027. Version 1.36 sits at 1.36.5 of the same date and closes on 28 June 2027. Version 1.35 sits at 1.35.9, also 15 September 2026, and closes on 28 February 2027.
Version 1.34 leaves that list on 27 October, with 1.34.12 as its latest patch, and the branch behind it, 1.33, closed on 28 June 2026 at 1.33.13. Version 1.32 closed on 28 February 2026 at 1.32.13. The releases page states the consequence plainly: end-of-life releases no longer receive security updates or bug fixes.
The exceptions the project has made to its own dates
The end-of-life date is a commitment with a documented exception history, recorded on the Kubernetes patch-releases page at https://kubernetes.io/releases/patch-releases/. Version 1.26.15 was released in March 2024, after the 1.26 end-of-life date, to pick up a new version of Go that addressed several Go CVEs. Version 1.25.16 followed in November 2023, after its end-of-life date, to fix CVE-2023-5528. Version 1.24.17 arrived in August 2023, after that branch closed, to fix CVE-2023-3676 and CVE-2023-3955.
Read those notes as the shape of the exception: a serious vulnerability in the language toolchain or the cluster itself can still pull a patch out of a closed branch. Nobody should schedule against that. An exception release arrives only when the project decides the risk justifies it.
The Kubernetes patch releases page (kubernetes.io/releases/patch-releases/, retrieved 2026-10-23), where the fourteen-month support period, the two-month maintenance mode and the categories of fix that can prompt a maintenance release are described.
The dependency trail that a closed branch leaves behind
Maintenance mode's second category is the one that spreads beyond the cluster: dependency issues, including base image updates. A branch that still receives maintenance releases can pick up a rebuilt base image with a patched system library underneath, and a branch that has closed stops receiving those rebuilds from the project.
That consequence reaches the scanning pipeline. An image that the project rebuilt in September still carries a September-era base, and a scanner that reads image metadata will keep reporting whatever the base contains for as long as the image stays in the registry. The fix moves into the operator's own rebuild process, with its own owner and its own schedule.
The upgrade path off a closed branch
A cluster on 1.34 has a fixed end date and a documented path forward. The project's monthly patch calendar stays the reference point: it targets monthly release points, warns that timelines may vary with bug-fix severity, and allows for unplanned critical releases between them. Booking the upgrade beside a planned monthly release keeps the target version and its patches in the same change window.
The intermediate versions carry their own deprecations, so the upgrade plan follows the release notes in sequence. A team moving from 1.34 to 1.37 reads three sets of notes, removes what a later version dropped, and tests the manifests against a staging cluster at the final version before touching production.
Netics editorial fact banner recording that 1.34.12, published on 15 September 2026, is the latest patch of the 1.34 branch, and that cherry picks to release-1.34 close after 27 October 2026.
A plan for a small platform team
Start with a list of every cluster and its version, taken from the API. Compare each entry against 1.37.1, 1.36.5 and 1.35.9, and mark anything on 1.34 or older as unfinished.
Then pick one target version and test the manifests against it. The Kubernetes v1.37 volume changes are worth a specific test if the cluster mounts persistent volumes, because storage behaviour is where an upgrade turns into an incident.
Then schedule the change inside a patch window, upgrade one cluster at a time, and record the version each cluster actually reports afterwards. That register is the artefact that makes the next end-of-life date a calendar entry: 1.35 closes on 28 February 2027, and a team that records its versions today will see it coming.
For teams that run clusters on their own hardware, the sovereign infrastructure and cloud exit page lists related infrastructure topics. The dates are published years ahead. The work is a list, a test and a change window, repeated for each minor release.
Originally published on the Netics blog.
Top comments (0)