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 followed on June 28, 2026. 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.
Key Dates at a Glance
- Kubernetes 1.32: end of life 2026-02-28
- Kubernetes 1.33: end of life 2026-06-28
- Kubernetes 1.34: maintenance mode begins 2026-08-27; end of life 2026-10-27
- Kubernetes 1.35: end of life 2027-02-28
- Kubernetes 1.36: released 2026-04-22; end of life 2027-06-28
- Amazon EKS 1.34: standard support ends 2026-12-02; extended support ends 2027-12-02
- Google GKE 1.34: end of support 2026-10-01
- Azure AKS 1.34: community support ends 2026-11-30; long-term support ends 2027-11-30
- Complete Kubernetes EOL schedule — all versions
- Kubernetes 1.33 — EOL June 28, 2026
- Kubernetes 1.32 — EOL February 28, 2026
- Kubernetes 1.31 — EOL November 11, 2025
- 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 8, 2022 | Feb 28, 2024 | EOL | 70 |
| Kubernetes 1.27 | Apr 11, 2023 | Jun 28, 2024 | EOL | 70 |
| Kubernetes 1.28 | Aug 15, 2023 | Oct 28, 2024 | EOL | 65 |
| Kubernetes 1.29 | Dec 13, 2023 | Feb 28, 2025 | EOL | 65 |
| Kubernetes 1.30 | Apr 17, 2024 | Jul 15, 2025 | EOL | 65 |
| Kubernetes 1.31 | Aug 13, 2024 | Nov 11, 2025 | EOL | 60 |
| Kubernetes 1.32 | Dec 11, 2024 | Feb 28, 2026 | EOL | 60 |
| Kubernetes 1.33 | Apr 23, 2025 | Jun 28, 2026 | EOL | 55 |
| Kubernetes 1.34 | Aug 27, 2025 | Oct 27, 2026 | Warning | 45 |
| Kubernetes 1.35 | Dec 2025 | Feb 28, 2027 | Supported | 30 |
| Kubernetes 1.36 | Apr 2026 | Jun 28, 2027 | Latest | 30 |
Kubernetes 1.33 — EOL June 28, 2026
Kubernetes 1.33 entered maintenance mode on April 28, 2026 and reached full end of life on June 28, 2026. Since that date, nothing is backported at all — no security patches, no bug fixes, no hardening.
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 is already past EOL.
Kubernetes 1.31 — EOL November 11, 2025
Kubernetes 1.31 has been end of life since November 11, 2025 — about nine months. If you're still running 1.31, you're three minor versions behind the oldest supported release. Kubernetes moves fast. Nine 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's standard support window closes on August 27, 2026 — after that it is in its two-month maintenance tail, receiving only critical and security fixes, until end of life on October 27, 2026. If you're on 1.34, the comfortable window is over: plan the move to 1.35 or 1.36 now rather than in October.
Kubernetes 1.35 — Supported Until February 28, 2027
Kubernetes 1.35 is one of the three currently supported versions (1.34, 1.35, 1.36) and a solid upgrade target for most teams. Support runs through February 28, 2027. 1.36 is also available if you want the latest.
Kubernetes 1.36 — Supported Until June 28, 2027
Kubernetes 1.36 is the newest release and the longest runway available: standard support to April 28, 2027 and end of life on June 28, 2027. If you are upgrading off 1.32 or 1.33 anyway, 1.36 is the target that buys the most time before the next forced move — and it is the only version whose window outlasts every managed-cloud standard-support tier for the versions you are leaving.
EKS, GKE, and AKS Support Windows
Managed Kubernetes services extend support beyond upstream EOL dates — but at a cost, and with important caveats. (Upstream Kubernetes has no LTS at all; the managed clouds are where long-term support actually exists — see our guide to what Kubernetes LTS really means.) 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.33 entered its final maintenance window. 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.
Kubernetes currently carries an EOL Risk Score™ of 55/100 — Grade C, elevated risk, recalculated at every site build from EOL recency, attack surface, CISA KEV exposure, and extended-support availability. Per-version scores and dates are on the Kubernetes lifecycle page.
The right response comes down to one question: how many more years does this system need to run? Under a year, extended support (where it exists) is usually cheaper than an emergency migration. One to three years, migrate — support fees paid repeatedly cost more than doing the project once. Indefinitely, migrate now and plan the next one before it surprises you. Extended support is often the more expensive choice over a multi-year horizon — a bridge, not a destination. And if this deadline feels like vendor caprice, it isn’t — why end of life is inevitable for every version, with the receipts.
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.
Frequently Asked Questions
Which Kubernetes versions are supported right now?
Kubernetes 1.36 (released April 22, 2026, supported until June 28, 2027), 1.35 (until February 28, 2027) and 1.34 (maintenance mode from August 27, 2026, end of life October 27, 2026). Kubernetes 1.33 reached end of life June 28, 2026 and 1.32 on February 28, 2026. Upstream supports the three most recent minors, roughly 14 months each.
How long is each Kubernetes version supported?
About 14 months: 12 months of active patch support after release, then a two-month maintenance-mode window in which only critical fixes ship, ending on the 28th of the month. Three minor releases ship a year, so three minors are supported at any time.
Do EKS, GKE and AKS follow the upstream Kubernetes dates?
No — each managed service has its own clock, usually longer. For Kubernetes 1.34: Amazon EKS standard support ends December 2, 2026 (then paid extended support to December 2, 2027); Google GKE ends October 1, 2026; Azure AKS community support ends November 30, 2026 (long-term support to November 30, 2027). Plan against your provider's date, and note that EKS and AKS charge for the extended window and auto-upgrade clusters that fall off it.
What happens when my Kubernetes version reaches end of life?
The cluster keeps running, but no further security fixes ship for that minor, and control-plane CVEs — API server, kubelet, ingress and admission paths — stay open. Managed providers eventually force-upgrade or bill for extended support; upstream users have to move. Because Kubernetes supports skipping only one minor at a time on the control plane, being two or more minors behind means sequential upgrades under time pressure.
How do I check my Kubernetes version?
kubectl version reports the client and server versions; kubectl get nodes shows each node's kubelet version (nodes may lag the control plane by up to three minors, but should not). For managed clusters, the console or aws eks describe-cluster, gcloud container clusters describe and az aks show report the control-plane version and available upgrades.
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