Kubernetes 1.33 reaches end of life on June 28, 2026. That is 27 days from now. After that date, the upstream project stops issuing patches for it -- no CVE fixes, no security backports, nothing.
The version entered maintenance mode on April 28. Since then, only the most severe security issues have been patched. June 28 is the full stop.
What EOL actually means
You can still run 1.33 after June 28. Nobody is forcing a shutdown. But any vulnerability discovered after that date will go unpatched upstream. Your cluster will continue working until a CVE lands that you cannot fix without upgrading -- and at that point you will be doing an emergency upgrade instead of a planned one.
The current active releases are 1.34, 1.35, and 1.36. The latest patches as of today are 1.34.8, 1.35.5, and 1.36.1.
The sequential upgrade constraint
Kubernetes does not support skipping minor versions. You cannot upgrade directly from 1.33 to 1.35. The kube-apiserver must move one minor version at a time.
If you are running 1.32 or older, this matters more than it might look. Getting from 1.32 to 1.36 is four separate upgrade cycles, each with its own drain, cordon, node roll, and validation pass. That is not a weekend job if you have multiple clusters or complex workloads.
The practical rule: start one minor version below your target and work upward. If you are on 1.33 and targeting 1.36, you are doing 1.33 to 1.34, then 1.34 to 1.35, then 1.35 to 1.36 -- assuming you want the latest. Targeting 1.34 is a single hop and still gets you off the EOL version.
Managed services are not exempt
If you are on GKE, EKS, or AKS, you may have extended support available. All three providers offer it, and all three charge for it.
EKS charges $0.60/hour per cluster for clusters that fall into extended support. GKE and AKS have premium tiers at comparable rates. These extended support windows buy you time -- typically months -- but they are not free, and they are not a substitute for upgrading.
If you are using managed Kubernetes and assuming the provider will handle the EOL for you: check your contract. Extended support does not activate automatically on all plans.
What to do now
Pick your target version. 1.34 is the minimum to get off EOL. 1.36 is current. Unless you have a specific reason to stop at 1.34 or 1.35, going to 1.36 avoids another upgrade cycle in the near term.
Check your cluster count. If you are running more than two or three clusters, the upgrade sequencing becomes a scheduling problem. Map out which ones to do first based on risk and traffic.
Read the changelogs for each minor version you are crossing. API deprecations and removals happen on minor version boundaries. kubectl api-versions and kubectl deprecations (via Pluto or similar) will surface which resources in your manifests hit removed APIs.
Test in non-production first. The upgrade itself is well-understood, but deprecated API usage in Helm charts or custom controllers will surface during the dry-run or on first apply.
27 days is enough time to do this properly. It is not enough time to leave it until the last week.
Sources: Kubernetes Patch Releases -- kubernetes.io; Version Skew Policy -- kubernetes.io; Kubernetes endoflife.date; EKS Extended Support -- Amazon EKS docs