Kubernetes supports an active patch release series for roughly fourteen months. The first twelve are the standard period. The last two are maintenance mode, where release managers may cut extra releases for CVE-assigned vulnerabilities, dependency issues including base images, and critical core component issues. After that the series is end of life.
The support clock
The Kubernetes patch releases page describes the support period in line with a yearly support proposal. Roughly fourteen months in total, split as follows.
| Period | Length | What happens |
|---|---|---|
| Standard | First 12 months | Regular monthly patch releases |
| Maintenance mode | Next 2 months | Extra releases only for specific problems |
| End of life | After month 14 | Cherry picks to the branch are closed soon afterwards |
During maintenance mode, the page says release managers may cut additional releases to resolve vulnerabilities with an assigned CVE ID (under the advisement of the Security Response Committee), dependency issues including base image updates, and critical core component issues. At the end of the two month period the series is considered end of life.
The cadence
The typical patch release cadence is monthly, and it is often a bit faster, one to two weeks, for the earliest patch releases after a new minor release. Critical bug fixes can cause an immediate release outside the schedule. The page lists target dates; for example it showed 13 October 2026 as the October target, and 10 November 2026 for November. Cherry pick deadlines come a few days before each date.
What it means for cluster owners
Fourteen months is shorter than many organisations plan upgrades. If you upgrade a cluster once a year, you will often sit in maintenance mode or past it. Managed services follow their own windows, which may differ from upstream, so check your provider's policy separately. I did not verify any provider policy for this article.
The maintenance mode detail matters for scanning. In that period a fix may land for a CVE, but not for an ordinary bug, so a team watching only for bug fixes may think the branch is quiet.
Steps
- Record the minor version of every cluster, including test and edge clusters.
- Look up each version's end of life date on the official release pages.
- Treat the start of maintenance mode as the signal to begin the upgrade, not the end.
- Rehearse the upgrade in a non-production cluster and keep notes on API removals.
- Subscribe to the project's security announcements.
- Make the patch level a tracked item too: staying on the newest patch of your minor is cheap.
A lesson for maintainers
The page is clear about the cherry pick process and its deadlines. A fixed rhythm with a public deadline makes it easy for contributors to know when a fix can land in older branches.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how a change in a component's status shows up over time, and consider what a version nearing end of life should trigger.
Quick check
Does maintenance mode mean no fixes?
No. The page says extra releases may be cut for CVE-assigned vulnerabilities, dependency issues and critical core component issues.
How often are patch releases made?
Typically monthly, with critical fixes possible in between.
Is my managed cluster on the same clock?
Not necessarily. Check your provider's own support policy.
How Safeguard helps
Safeguard's asset discovery and continuous monitoring can show which services run which versions, and its SBOM and dependency scanning check those versions against known advisories. Reachability analysis helps you rank what to fix first. Autonomous remediation with fix pull requests is off by default, with every category on Manual. The free scan is a low-effort place to start.
Sources
- Kubernetes, Patch Releases: cadence, cherry picks, support period and maintenance mode. Fetched 19 October 2026.
Last reviewed: 19 October 2026.
