Kubernetes v1.37: Kubelet Flag Removals, Containerd 2.0 Deadline, and Your Upgrade Checklist
The upcoming release finishes the cleanup v1.36 deferred. If your kubelet configs still reference legacy flags or you haven't moved to containerd 2.0, the upgrade path just got narrower.
Kubernetes v1.37 is expected to land in the coming weeks, and while every release brings a mix of new features and housekeeping, this one leans harder than usual on the housekeeping side. The project is completing a set of removals that were explicitly postponed from v1.36, giving operators who procrastinated through the last cycle no more runway. If you manage clusters with custom kubelet systemd unit files, bootstrap scripts, or CI pipelines that inject kubelet flags directly, this is the release where deferred maintenance becomes a hard blocker.
Here's what's changing, why the project sequenced it this way, and what you need to do before upgrading.
The Containerd 2.0 Deadline Arrives
The headline removal in v1.37 is the completion of deprecated kubelet configuration flag cleanup. VersionLog's v1.37 breakdown explains that the Kubernetes project intentionally deferred these removals from v1.36 to align with the end of containerd 1.7 support. The logic was straightforward: many operators were still running containerd 1.7, and yanking kubelet flags that interacted with legacy runtime behavior before those operators had a migration path would have caused unnecessary breakage.
That grace period is over. Any cluster still passing removed flags to the kubelet will fail to start after upgrading to v1.37. Not warn. Not degrade gracefully. Fail.
This is the kind of change that doesn't surface in integration tests until it's too late — the flags in question live at the infrastructure layer, injected via systemd unit files, cloud-init scripts, Ansible playbooks, Terraform provisioners, and Packer templates. The kubelet binary itself is the one that rejects them, and it does so at startup.
Before you attempt the upgrade, VersionLog recommends a simple audit:
# Check for deprecated kubelet flags in use on a node
journalctl -u kubelet | grep -i "deprecated"
# Or inspect the kubelet config directly
cat /var/lib/kubelet/config.yaml
If you're running v1.36 today, your kubelet logs have been warning you. If you haven't been reading them, now is the time.
What v1.36 Set Up, v1.37 Finishes
To understand why v1.37's removal list looks the way it does, you need the context of v1.36's ambition. As the Kubernetes project's own v1.36 sneak peek outlined earlier this year, that release packed 70 enhancements: 18 graduated to stable, 25 moved to beta, and 25 entered alpha. It also started several deprecation clocks, including the removal of Service ExternalIPs and significant work on declarative validation, admission policies, and pod-level resource management.
The v1.36 cycle was a building release. v1.37 is the release that clears the scaffolding.
Per VersionLog's v1.37 alpha cycle coverage, the focus has been on two things: hardening the alpha features introduced in v1.36, and completing the removals that v1.36 chose to defer. This is a pattern the Kubernetes project has leaned into more deliberately in recent releases, alternating between feature-heavy and cleanup-heavy cycles to manage the complexity of a codebase this large.
For platform teams, the practical implication is that v1.37 is less about adopting new capabilities and more about ensuring your existing infrastructure doesn't break on contact with the new binary.
WebSocket Routing Stabilization
One area where v1.37 builds constructively on v1.36 is WebSocket-based exec, attach, and port-forward routing. The ExtendWebSocketsToKubelet feature gate moved to beta (on by default) in v1.36, routing WebSocket streaming requests directly to the kubelet instead of proxying them through the API server (Transition from SPDY to Websockets, Kubernetes Contributors). As VersionLog notes, v1.37 is expected to further stabilize this path.
This matters for anyone running interactive debugging sessions, log tailing, or port-forwarding at scale. The old proxy path through the API server added latency and created a bottleneck under load (Transition from SPDY to Websockets, Kubernetes Contributors). Direct kubelet routing reduces both.
Two alpha metrics introduced in v1.36 give you visibility into the transition:
# Check WebSocket routing metrics on the API server
kubectl get --raw /metrics | grep apiserver_websocket_streaming_requests_total
# Check kubelet-side metrics
kubectl get --raw /metrics | grep kubelet_streaming_websocket_requests_total
If you're running v1.36 clusters today, check these metrics before upgrading. They'll tell you whether your tooling is already using the WebSocket path or still hitting the legacy proxy. Any tools that explicitly expect the old routing behavior may need updates.
The Upgrade Checklist
Here's a concrete list of what to audit before moving to v1.37:
1. Kubelet flags. Grep your node bootstrap scripts, systemd unit files, and configuration management templates for any kubelet flags marked deprecated in v1.36. The kubelet binary in v1.37 will reject them at startup. This is the single most likely source of upgrade failures.
2. Containerd version. If you're still running containerd 1.7, you need to migrate to 2.0 or later before upgrading. The kubelet flag removals in v1.37 were specifically sequenced around the end of containerd 1.7 support, as VersionLog documents.
3. WebSocket routing. Verify that your exec, attach, and port-forward tooling works with direct kubelet WebSocket routing. The feature gate is on by default since v1.36, so most clusters are already using it, but custom tooling or network policies that assume API server proxying may break.
4. CI/CD pipelines. Any pipeline that provisions or configures nodes needs to be tested against the v1.37 kubelet binary. This includes managed Kubernetes providers where you control the node image or kubelet arguments.
5. Monitoring. Ensure your observability stack captures kubelet startup failures. A node that fails to start its kubelet looks different from a node that starts and then fails health checks. Your alerting should distinguish between the two.
Kubernetes' Deprecation Discipline: Why This Pattern Is Becoming the Norm
Kubernetes has been getting more disciplined about its deprecation-to-removal pipeline. The project's documented deprecation policy, as described in the v1.36 sneak peek, requires that stable APIs only be deprecated when a newer stable version exists, and that deprecated APIs remain functional for at least one year. This policy has been in place for a while, but the project's execution of it has tightened.
The v1.36-to-v1.37 sequence is a good example: defer removals when the ecosystem isn't ready, then follow through once the prerequisite migrations (like containerd 2.0) are available. It's a more humane approach than dropping breaking changes without warning, but it also means operators who ignore deprecation warnings for a full release cycle will hit a wall.
The deprecation story has a lighter coda, though. Sam Rose at ngrok recently demonstrated a partial port of Kubernetes to TypeScript that runs clusters entirely in the browser, complete with pod lifecycles, cluster DNS, and deployment tracking. It's not production infrastructure, but it's a striking illustration of how deeply Kubernetes' abstractions have permeated developer tooling. When someone can reimplement your orchestrator in a browser tab, your API surface has become a de facto standard — which makes deprecation discipline even more consequential.
What Comes Next
The v1.37 release is a maintenance checkpoint, not a revolution. The features to watch are the ones graduating from alpha to beta and beta to stable in subsequent releases: pod-level resource management, in-place vertical scaling, and the continued maturation of Dynamic Resource Allocation for AI/ML workloads.
For now, the action item is straightforward. Audit your kubelet flags. Upgrade containerd. Test your node bootstrap. The v1.37 kubelet won't wait for you to catch up.
