Kubernetes 1.37: What's New, Release History & Support Lifecycle

What Is New in Kubernetes 1.37

What deprecated kubelet flags are finally being removed in Kubernetes 1.37?

Kubernetes 1.37 follows through on a cleanup that was explicitly deferred from v1.36: the removal of deprecated kubelet configuration flags and their legacy fallback behavior. This deferral was intentional -- the Kubernetes project aligned the removal timeline with the end of containerd v1.7 support, giving operators the full v1.36 cycle to finish migrating their nodes to containerd 2.0 or later.

In practice, this means any cluster still passing now-removed flags to the kubelet will fail to start after an upgrade to v1.37. The two most operationally relevant areas are:

• Legacy cgroup driver configuration flags -- the kubelet now relies entirely on KubeletCgroupDriverFromCRI (GA since v1.36) to detect the cgroup driver from the container runtime, with no manual flag fallback.
• Any node using containerd 1.x will not be able to run v1.37 kubelets. You must be on containerd 2.0+ before upgrading.

Watch out for this if you manage clusters with custom kubelet systemd unit files or bootstrap scripts that inject flags directly. Run kubelet --help against your current binary and audit for any flags marked as deprecated in your v1.36 cluster logs before attempting the upgrade.

# 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

How does the v1.37 development cycle build on Kubernetes 1.36 improvements?

Kubernetes 1.37 (in alpha) continues directly from v1.36's foundation of 70 enhancements -- 18 graduated to stable, 25 to beta, and 25 to alpha. The 1.37 alpha cycle is focused on hardening those new alpha features while completing the removals that v1.36 chose to defer.

One area seeing continued work is the ExtendWebSocketsToKubelet feature gate, which moved to beta (default true) in v1.36. This change routes WebSocket exec, attach, and portforward requests directly to the kubelet rather than proxying through the API server. In a v1.37 cluster you should expect this path to be further stabilized. The two alpha metrics introduced in v1.36 -- apiserver_websocket_streaming_requests_total and kubelet_streaming_websocket_requests_total -- give you visibility into the routing behavior.

# Check WebSocket routing metrics on the API server
kubectl get --raw /metrics | grep apiserver_websocket_streaming_requests_total

Most teams tracking the 1.37 development branch should treat this cycle as primarily a cleanup and graduation cycle for features introduced in 1.35 and 1.36, not a wave of net-new functionality.

What are the SELinux volume label implications teams should prepare for in Kubernetes 1.37?

The Kubernetes project has explicitly flagged SELinux volume label behavior changes as something to prepare for ahead of v1.37. SELinux volume labeling went GA in v1.36, with the default behavior switching to mount -o context instead of recursive file relabeling. This is faster but carries a breaking implication: sharing a volume between privileged and unprivileged Pods on the same node may produce unexpected SELinux denials.

This matters if you run mixed-privilege workloads (common in AI/ML pipelines, shared storage scenarios, or multi-tenant namespaces sharing PVCs). The v1.36 release notes recommended auditing before upgrading -- if you skipped that step and are now targeting v1.37, do it now.

• Audit your Pods for the seLinuxChangePolicy field and ensure SELinux volume labels are explicitly set.
• Any Pod that was relying on implicit recursive relabeling may see permission errors starting with v1.36 behavior, which v1.37 will inherit and potentially tighten further.
• Check the dedicated blog post linked from the v1.36 release notes: "SELinux Volume Label Changes goes GA (and likely implications in v1.37)".

What is the Kubernetes 1.37 release schedule and what should platform teams track now?

The v1.37.0 GA release is scheduled for Wednesday, August 26, 2026. The development cycle milestones are:

• Code Freeze and Test Freeze: July 22--23, 2026
• KubeCon Japan: July 28--30, 2026
• Docs Freeze: August 5--6, 2026
• GA Release: August 26, 2026

For platform teams, the most actionable items right now are not in the 1.37 alpha itself but in the prerequisites it enforces. If your cluster is running containerd 1.x, you must upgrade to 2.0+ before v1.37 is viable. If you are on cgroup v1 nodes without failCgroupV1: false set, your kubelet will refuse to start on v1.37. The alpha cycle is the right time to validate your upgrade runbook against these hard requirements rather than discovering them at GA.

What happened to Dynamic Resource Allocation (DRA) in the Kubernetes 1.37 cycle?

Dynamic Resource Allocation went GA in Kubernetes v1.34 and has seen continued expansion in each subsequent release. In v1.37, DRA-related work continues primarily around partitionable devices (KEP-4815), which entered alpha in v1.36. This feature allows a single physical device -- such as a GPU -- to be partitioned into smaller logical slices and allocated independently to multiple Pods, a critical capability for AI/ML workloads.

The DynamicResourceAllocation feature gate has been locked to enabled-by-default since v1.35 and cannot be disabled. In practice, every v1.37 cluster runs with DRA core enabled. The 1.37 alpha cycle is expected to advance DRA partitioning and the associated ResourceClaim API toward beta maturity, though the official graduation status will be confirmed at code freeze.

# Verify DRA is available in your cluster
kubectl api-resources | grep resource.k8s.io

# List ResourceClaims in a namespace
kubectl get resourceclaims -n <namespace>