Kubernetes minor versions from 1.19 onward receive approximately one year of patch support, according to the project's release page. After end of life, no new patches are published for that line. Running an unsupported version means security fixes will not reach you without an upgrade.
Current versions (checked 19 October 2026)
| Minor version | Latest patch listed | End of life |
|---|---|---|
| 1.37 | 1.37.1 | 2027-10-28 |
| 1.36 | 1.36.5 | 2027-06-28 |
| 1.35 | 1.35.9 | 2027-02-28 |
| 1.34 | 1.34.12 | 2026-10-27 |
Dates and patch numbers change. Check the official releases page before you plan. The page treats the three newest minors as maintained and lists 1.34 until its end-of-life date, days after this review.
Why it matters
A cluster has several moving parts: the control plane, the nodes, the container runtime, and add-ons. A vulnerability in any of them is fixed in a patch release of a supported line. An unsupported cluster cannot take the fix without a minor upgrade, which is a larger change. Teams that wait often face skipping several versions at once, which means more API removals and more testing.
If you use a managed service, the provider sets its own support window, which can differ from the upstream dates. Check your provider's calendar and treat the earlier date as your deadline.
A calm upgrade routine
- Track the end-of-life date of your current minor and set a reminder at 90 days.
- Read the release notes and the deprecation guide for the target version.
- Scan manifests and charts for removed APIs.
- Upgrade a non-production cluster first and run your tests.
- Upgrade the control plane, then nodes, one minor at a time.
- Re-check admission policies, add-ons and image pull behavior after each step.
What counts as an emergency
Most patch releases are routine. Treat a patch as urgent when it fixes a flaw that is reachable in your setup, for example an issue in the API server you expose, or in a component your nodes run. Read the release notes for each patch of your minor, not only the headline minor release. Subscribe to the project's security announcements so you hear about it from the source and not from a rumor.
Also keep a record of the version of every cluster, including test and forgotten ones. Old clusters in side accounts are where unsupported versions tend to live. If you cannot list your clusters and their versions, that is the first job.
Do not forget the layers around the cluster
Patch the node operating system and the container runtime on their own schedule. The cluster version is only one part. Rebuilding application images also matters, which is covered in rebuilding images regularly.
Quick check
Can I stay on an old minor if nothing breaks?
You can, but you will not receive security patches. Treat end of life as a deadline.
Is the provider's version the same as upstream?
Not necessarily. Managed services publish their own support calendars. Use the earlier date.
Safeguard can inventory the components you run and apply policies to them; start with the free scan.
Sources
Last reviewed: 19 October 2026.
