Kubernetes just pushed v1.37.0-rc.0 into the wild — and at the same time the project signals two imminent patch trains: 1.36.3 and 1.35.7. That combination matters because it’s explicitly the one-two punch platform teams will be juggling over the next month: testing the RC for upgrade impacts while preparing to roll small-but-urgent patches across supported clusters.
The concrete status from upstream: v1.37.0-rc.0 is published and the release calendar targets the final v1.37.0 in late August 2026. The patch-release tracker shows the next expected patch releases as 1.36.3 and 1.35.7 and the kubernetes-announce channel has corresponding notes. The practical takeaway is the same: validate the RC in staging while preparing maintenance windows for the patch lines you run.
Why this matters operationally: most organizations treat an RC as the signal to start upgrade rehearsals and patch trains as the signal to schedule maintenance windows. Having both active at once is operationally noisy. You’ll be validating the RC in staging clusters while your stable clusters need small fixes applied immediately. If your automation treats upgrades and patching the same way, you’ll create unnecessary risk or delay.
Here’s what matters practically:
-
If you run 1.36: 1.36.3 is the next patch you should expect. That’s typically a mix of security and stability fixes; don’t conflate its low number with low urgency. Prepare your kubeadm/managed-provider playbooks and CI smoke tests to run against 1.36.3 images.
-
If you run 1.35: same story with 1.35.7. Older supported lines still get fixes; this is the last-mile maintenance rhythm people on EOL timelines ignore at their peril.
-
If you’re evaluating 1.37: the RC lets you vet API changes and controller behavior now. The calendar visibility for a late-August release gives you a window to tie your app-testing and admission/controller compatibility checks to.
One operational truth nobody likes: the more patch trains upstream runs, the more disciplined your automation must be. Manual click-through upgrades or ad-hoc remediation are where incidents start. If you’re not running automated canary upgrades and immediate rollbacks in CI, this cadence will bite you.
Also note a gap to watch: runtime and tooling compatibility (container runtimes, CRI implementations, local developer tooling and some ecosystem tools) don’t always move in lockstep with the Kubernetes release cadence. Don’t assume runtime or tooling compatibility will magically align with your Kubernetes patch schedule; verify containerd/CRI-O/runc/other components and your tooling channels as part of the 1.36.3 / 1.35.7 rollout.
If you want a quick operational checklist: run your kube-proxy, CNI, and admission-controller smoke matrix against the RC in a canary cluster; schedule patch windows for 1.36.3/1.35.7 with your vendors, and make sure rollback is exercised. If you manage clusters with kubeadm, test kubeadm upgrade plans against the RC images; if you’re on a managed service, expect providers to stagger rollouts and communicate their timelines.
For background on how patch maintenance fits into the next release, see my previous piece on the 1.36 patch maintenance and 1.37 release prep: Kubernetes 1.36 patch maintenance and 1.37 release prep.
Final take: this RC + active patch trains is the upstream way of saying "ship forward, fix backward." It’s the right approach, but only if your platform automation is more mature than your change freeze process. If you still treat minor patching as an afterthought, the next two weeks will cost you late-night rollbacks and postmortems. Lock in automated canaries now, because August isn’t far away and compatibility surprises are the most likely hazard.