kOps just did the thing that actually matters this week: the 1.35 release line removes support for Kubernetes 1.29 and explicitly deprecates 1.30 for removal in kOps 1.36. Thats a more consequential signal to platform teams than the fact upstream didnt cut a new patch release this week.
Upstream Kubernetes remains in the 1.36 series; there were no new upstream minor releases this week. v1.37 is still moving through alpha/beta stages and follows the project's published release calendar — check the official release notes and calendar for exact patch and GA dates.
Why kOps' change matters
kOps governs the supported upgrade surface for clusters it manages. When the project removes support for a Kubernetes minor (1.29), its not only a statement about age: it changes which kubeconfigs, admission controllers, extensions and addon versions kOps will validate and safely apply in its provisioning and rolling upgrade paths. If you run production clusters with control planes or nodes on 1.29 and rely on kOps for lifecycle operations, youve just lost a supported upgrade path inside your tooling. Deprecating 1.30 for removal in 1.36 gives teams a concrete deadline: either align cluster versions with kOps supported matrix, or absorb bespoke automation to bridge the gap.
This is overdue and necessary. The real operational cost of supporting three-year-old minors isn't the code in kOps the cost is the testing matrix you carry forever. Tightening supported versions reduces blast radius: fewer combinations to validate means fewer surprise regressions during upgrades. Yes, this will bite organizations that delayed routine upgrades; thats the point.
What else is happening upstream and in managed offerings
-
Kubernetes: the 1.36 series is in active maintenance; follow the release calendar for upcoming patch releases. v1.37 is progressing through alpha/beta and carries the usual compatibility attention (container runtime and CRI compatibility are common risk areas to watch).
-
GKE: Google continues to publish incremental release notes with targeted fixes, feature rollouts, and deprecations. Managed offerings remain the lower-friction path for many teams, but you still need to watch provider-specific deprecation and node-image notices.
-
CNCF ecosystem: no major graduations or large OCI/container-runtime releases were announced this week. Most activity appears to be maintenance and security fixes rather than big API churn.
What to do now (short list)
If you run kOps-managed clusters: prioritize migrating off 1.29 as soon as possible and plan to remove 1.30 before kOps 1.36 lands. If you still run bespoke automation around older kube versions, accept that technical debt becomes more expensive the longer you carry it.
If you rely on managed providers: continue to track provider-specific release notes. GKEs incremental updates will surface changes you need to adapt to even if upstream looks quiet.
Final take
This weeks headline isnt a missing patch; its a tightening of supported versions by an important cluster manager. kOps pushing older minors out the door is the ecosystem doing the cleanup most platform teams should have been doing years ago. Expect other lifecycle tools and managed providers to accelerate similar prunings the safe window for clinging to ancient minors is closing. If you want a calmer 2027, schedule those upgrades now; procrastination here is a policy choice, not a technical inevitability.
Relevant reading: see our coverage of v1.37 compatibility and the enhancements freeze, and check recent kind and kOps release notes for changes to default versions and support matrices.