Kubernetes End-of-Life Dates —
Official EOL Schedule for Every Version
Kubernetes releases a new minor version approximately every four months — and each version is supported for roughly 14 months after release. That means if you're not actively upgrading, you're falling behind faster than with almost any other infrastructure component in your stack.
Kubernetes 1.32 reached end of life on February 28, 2026. Kubernetes 1.33 reaches end of life on June 28, 2026 — six weeks from now. If you're running either of these in production, you have an active EOL exposure with no upstream security patches.
This page is the single authoritative reference for Kubernetes end-of-life dates across every version — with EOL Risk Scores™, managed service support windows for EKS, GKE, and AKS, and plain-English migration guidance.
- Complete Kubernetes EOL schedule — all versions
- Kubernetes 1.33 — EOL June 28, 2026
- Kubernetes 1.32 — EOL February 28, 2026
- Kubernetes 1.31 — EOL January 13, 2026
- Kubernetes 1.34 — current supported
- Kubernetes 1.35 — current supported
- EKS, GKE, and AKS support windows
- Understanding the release cadence
- How to upgrade safely
Complete Kubernetes EOL Schedule
Kubernetes supports the three most recent minor versions at any given time. Each minor version receives patch releases for approximately 14 months — covering bug fixes and security patches. Once a version reaches end of life, no further patches are issued by the upstream Kubernetes project.
| Version | Release Date | End of Life | Status | EOL Risk Score™ |
|---|---|---|---|---|
| Kubernetes 1.26 | Dec 9, 2022 | Feb 28, 2024 | EOL | 92 |
| Kubernetes 1.27 | Apr 11, 2023 | Jun 28, 2024 | EOL | 90 |
| Kubernetes 1.28 | Aug 15, 2023 | Oct 28, 2024 | EOL | 88 |
| Kubernetes 1.29 | Dec 13, 2023 | Feb 28, 2025 | EOL | 85 |
| Kubernetes 1.30 | Apr 17, 2024 | Jun 28, 2025 | EOL | 82 |
| Kubernetes 1.31 | Aug 13, 2024 | Jan 13, 2026 | EOL | 78 |
| Kubernetes 1.32 | Dec 11, 2024 | Feb 28, 2026 | EOL | 72 |
| Kubernetes 1.33 | Apr 23, 2025 | Jun 28, 2026 | Maintenance | 55 |
| Kubernetes 1.34 | Aug 27, 2025 | Oct 27, 2026 | Supported | 30 |
| Kubernetes 1.35 | Dec 2025 | Feb 28, 2027 | Supported | 18 |
| Kubernetes 1.36 | Apr 2026 | Jun 28, 2027 | Latest | 12 |
Kubernetes 1.33 — EOL June 28, 2026
Kubernetes 1.33 entered maintenance mode on April 28, 2026 and reaches full end of life on June 28, 2026. In maintenance mode, only critical security patches are backported — no new features, no bug fixes, no general security hardening. After June 28, nothing is backported at all.
If you're running 1.33 in managed services: GKE, EKS, and AKS all have their own extended support windows that may push past the upstream EOL date, but at additional cost. Check your managed service provider's documentation for specific dates.
Target version: Upgrade to Kubernetes 1.35 or 1.36. Both are actively supported through at least February 2027.
Kubernetes 1.32 — EOL February 28, 2026
Kubernetes 1.32 reached end of life on February 28, 2026. It is no longer receiving any patches from the upstream Kubernetes project. Any CVEs discovered in 1.32 after that date will not be fixed at the community level.
Running 1.32 today means you are accumulating unpatched vulnerabilities with no remediation path except upgrading. The longer you stay on 1.32, the wider that gap grows.
Target version: Upgrade to 1.35 or 1.36. Skip 1.33 — it reaches EOL in six weeks.
Kubernetes 1.31 — EOL January 13, 2026
Kubernetes 1.31 has been end of life since January 13, 2026 — over four months. If you're still running 1.31, you're two full minor versions behind the current supported releases. Kubernetes moves fast. Four months of unpatched CVEs in a cluster orchestration platform is a meaningful security gap.
Target version: Upgrade directly to 1.35 or 1.36. At two versions behind, plan for potential API deprecation issues and test thoroughly in a staging environment first.
Kubernetes 1.34 — Supported Until October 27, 2026
Kubernetes 1.34 is actively supported and receives full security patches through October 27, 2026. If you're on 1.34, you're in a stable position — but start planning your upgrade to 1.35 or 1.36 now so you're not caught by the October deadline.
Kubernetes 1.35 — Supported Until February 28, 2027
Kubernetes 1.35 is one of the two currently supported versions and the recommended upgrade target for most teams. Support runs through February 28, 2027, giving you nine months of runway from today. 1.36 is also available if you want the latest.
EKS, GKE, and AKS Support Windows
Managed Kubernetes services extend support beyond upstream EOL dates — but at a cost, and with important caveats. The upstream Kubernetes project stopping patches doesn't mean your cloud provider stops patching immediately, but it does mean the security burden shifts to them, and eventually to you through extended support pricing.
Understanding the Kubernetes Release Cadence
Kubernetes follows a predictable schedule that makes planning straightforward — if you're paying attention.
Three releases per year. Kubernetes releases a new minor version approximately every four months — roughly in April, August, and December. Each release introduces new features, API changes, and deprecations.
Three versions supported at once. At any point, only the three most recent minor versions receive upstream patches. When 1.36 shipped, 1.32 dropped off support. This is the version skew window — and it moves every four months.
14-month support window. Each version is supported for approximately 14 months from its release date. The final two months are "maintenance mode" — only critical security fixes are backported, not general bug fixes.
The math: if you skip one upgrade cycle, you're in trouble. Miss two consecutive releases (roughly 8 months of inaction) and your version falls off supported status. In practice, most teams that fall behind do so because infrastructure upgrades are deprioritized — until an audit, incident, or compliance review forces the issue.
How to Upgrade Safely
-
01Check your current version Run
kubectl versionto confirm your control plane and node versions. Note the version skew — your nodes and control plane must stay within one minor version of each other. -
02Review API deprecations Every Kubernetes minor release deprecates and removes APIs. Run
kubectl deprecationsor use Kubent (kube-no-trouble) to scan your cluster for deprecated API usage before upgrading. Skipping this step is the most common cause of broken upgrades. -
03Upgrade one minor version at a time Kubernetes does not support skipping minor versions. If you're on 1.31, you must go to 1.32, then 1.33, then 1.34, then 1.35. Plan your upgrade path as a sequence, not a single jump.
-
04Upgrade control plane before nodes Always upgrade the control plane first, then worker nodes. The control plane can run one minor version ahead of nodes, but nodes cannot run ahead of the control plane.
-
05Test in staging first Run your workloads against the target version in a non-production environment. Pay particular attention to admission webhooks, custom resource definitions, and any operators you're running — these are most likely to have compatibility issues across minor versions.
-
06Set a recurring calendar reminder Kubernetes releases on a four-month cadence. Put a recurring reminder in your calendar for every release — February, June, October — to review your current version against the support window. Staying current is significantly easier than catching up.
Check your full stack for EOL exposure
Kubernetes is one component. Check your container runtime, OS base images, and application dependencies too — free, no signup required.
Scan your stack Check a version Risk Score methodology