Foreword¶

Kubernetes 1.37 is scheduled to officially launch on August 26, 2026. On July 31, the official Kubernetes blog published the v1.37 Sneak Peek, where the Release Team listed the deprecations and key enhancements that operations teams need to be aware of in advance. Based on the Kubernetes Enhancement Tracker and community mid-cycle statistics, this version tracks a total of 86 enhancements, of which approximately 16 are planned to graduate to Stable (GA).

For platform teams, 1.37 is not a “feature-heap” release, but a convergence point of several long-term evolution lines: HPA native scale-to-zero enters Beta and is enabled by default, DRA device taint tolerations officially reach GA, kube-proxy IPVS mode starts its deprecation timeline, and metrics.k8s.io graduates to stable after nearly nine years in Beta. If you are planning upgrade windows for the third and fourth quarters, the following items are worth prioritizing for evaluation.

Release Schedule and Version Overview¶

The official launch date of Kubernetes 1.37 has been added to the Release Calendar: August 26, 2026 (Wednesday). It is important to emphasize that the Sneak Peek article clearly states at the beginning: the content reflects the current release status, and adjustments may still be made before the official launch.

From the perspective of enhancement distribution (data source: Cloudsmith’s sorting of the official Tracker):
- 86 valid enhancements (excluding Deferred / Removed from Milestone)
- 28 items are in the Graduating stage, of which 16 items target Stable
- 34 items are Net New Alpha

In addition to the key points covered in this article, 1.37 also includes changes such as Pod-level resource requests (KEP-2837) reaching GA, KYAML output stabilizing, Kubelet Rootless Mode entering Beta, and Volume Health Monitor re-entering Alpha. The complete list can be referenced in Cloudsmith’s 1.37 Feature Sorting and the official CHANGELOG (synchronized on launch day).

HPA Scale-to-Zero: Beta Enabled by Default¶

Background and Significance¶

For scenarios such as queue-based workers, scheduled batch processing, and event-driven microservices, Pods occupy nodes for long periods when idle but barely perform any work. In the past, to achieve “scale down to 0 during idle periods”, the common practice was to introduce KEDA or Knative, adding an additional event source adaptation layer on top of HPA.

KEP-2021 has tracked the capability of “scaling down to zero based on object/external metrics and then scaling back up” since its Alpha launch in Kubernetes 1.16; after completing the Alpha reimplementation in 1.36, 1.37 plans to promote the HPAScaleToZero feature gate to Beta and enable it by default (see kubernetes/kubernetes#139648).

This means: for workloads with suitable metric sources, native HPA can already cover the “idle zero replicas” scenario, and there is no need to introduce third-party controllers for this basic capability.

Usage Constraints (Must Read)¶

Scale-to-zero does not support CPU/memory utilization metrics. The reason is simple: when the replica count is 0, no Pods are running, so the Resource Metrics API cannot retrieve utilization data, and HPA cannot calculate the target replica count.

This capability only applies to Object or External metrics—for example, message queue depth, custom Prometheus metrics, cloud vendor observability metrics, etc., where the signal is independent of the current number of Pods.

The 1.37 Beta also introduces the ScaledToZero condition in HPA Status, which is used to distinguish between “controller automatically scaled to 0” and states such as “manually paused Deployment”, preventing false positives in scaling logic.

Configuration Example¶

Below is an example of an HPA based on external metrics, with minReplicas: 0, which will scale down to zero when the number of visible queue messages drops to 0:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: queue-worker
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: queue-worker
  minReplicas: 0
  maxReplicas: 10
  metrics:
  - type: External
    external:
      metric:
        name: queue_messages_visible
      target:
        type: Value
        value: "0"

Practice recommendations:
1. When enabling it for the first time, it is recommended to start the Deployment with at least 1 replica, allowing HPA to record the initial state before scaling down to 0 (the KEP explains the scale-from-zero trigger conditions).
2. The default 5-minute scale-down stabilization window will suppress jitter; you can adjust it as needed in spec.behavior for burst traffic scenarios.
3. KEDA still has advantages in the ecosystem of event source connectors; but if your requirement is only “do not occupy machines when the queue is empty”, the native HPA in 1.37 is worth validating in a pre-production environment.

DRA Device Taint Tolerations GA: The Key Puzzle for GPU Cluster Operations¶

What are DRA and Device Taints?¶

Dynamic Resource Allocation (DRA) is Kubernetes’ next-generation resource allocation model for dedicated hardware such as GPUs, FPGAs, and SR-IOV. Drivers report device inventories via ResourceSlice, users apply for devices via ResourceClaim, and the scheduler completes device selection during the allocation phase.

In GPU clusters, a long-standing pain point is: when a GPU card has ECC errors, driver timeouts, or needs to be taken offline for maintenance, how to prevent new Pods from being scheduled onto it and safely evict running workloads? The traditional Device Plugin model lacks device-level isolation methods equivalent to Node Taints.

KEP-5055 introduces Device Taints and Tolerations, with a mechanism similar to node taints:

DRA drivers can directly mark devices in ResourceSlice; cluster administrators can also create DeviceTaintRule to batch apply taints using selectors such as driver, pool, and device name, without modifying driver configurations.

GA Significance of 1.37¶

The milestone for KEP-5055 is: Alpha 1.33 → Beta 1.36 → Stable 1.37. The corresponding PR #138676 has been merged, and Device TaintRule is officially available via the resource.k8s.io/v1 API.

For GPU cluster scheduling, this means:
- Faulty GPUs can be marked with NoSchedule, preventing new training Jobs from being scheduled onto them
- Maintenance windows can apply NoExecute to specific pools, rolling out evictions in conjunction with Pod toleration policies
- Combined with DRA enhancements promoted in 1.37 (such as KEP-5304 Device Attributes Downward API, KEP-6072 standard numaNode attribute Alpha), distributed training will be able to obtain topology information more smoothly for NUMA/PCIe affinity scheduling

If you have piloted the DRA GPU Driver in a 1.35+ cluster, 1.37 is the appropriate version to incorporate taint tolerations into production SOPs.

kube-proxy IPVS Phase-Out, nftables Takes Over¶

Why Deprecate IPVS?¶

The IPVS mode of kube-proxy was introduced in 1.8, originally to alleviate performance issues caused by the expansion of iptables rules. However, the Kubernetes community clearly stated in KEP-3866 that the kernel IPVS API alone cannot fully implement Service semantics, and the IPVS mode still relies on iptables as a fallback at the underlying layer, resulting in high maintenance costs and inconsistent behavior.

Starting from 1.37, clusters running in IPVS mode will receive a deprecation warning when kube-proxy starts. The official timeline given in the Sneak Peek (KEP-5495) is as follows:

How to Confirm the Current Mode¶

kubectl -n kube-system get configmap kube-proxy -o jsonpath='{.data.config\.conf}' | grep 'mode:'

If the output shows mode: ipvs, you should start planning the migration. The community’s generally recommended target backend is nftables—Kubernetes’ nftables mode entered Beta in 1.31, and the official blog post in February 2025 has a dedicated introduction.

1.37 also adds KEP-5343 (Alpha): to prepare clusters that have not yet switched their default backend—nodes still using the iptables default will receive log warnings, reminding them to complete explicit configuration or migration before the default switch to nftables in 1.40. The same version’s KEP-6032 also completes the user-mode proxy capability for localhost NodePort for nftables (Alpha).

Before migrating, please confirm that the node kernel ≥ 5.13 (required for nftables kube-proxy), and validate key paths such as Services, NodePort, and externalTrafficPolicy: Local in a pre-production environment.

metrics.k8s.io Officially Reaches GA¶

Behind HPA, kubectl top, and various monitoring integrations lies the Metrics API (metrics.k8s.io). This API has been in Beta for a long time since early versions, and 1.37 plans to graduate it to Stable (GA) (KEP-5207).

The official note states: there are no expected functional changes, and both v1 and v1beta1 can be used during the transition period. This is more like a “stability certification”, allowing platform teams relying on Metrics Server to eliminate the psychological burden of “Beta APIs may change at any time”.

Pre-Upgrade Checklist¶

Before the official launch on August 26, it is recommended to conduct an assessment in the following order (some items come from the official Sneak Peek, some from the community upgrade guide; please refer to the official Release Notes for the final upgrade):

1. Check kube-proxy mode
See the grep command above. Users of IPVS should schedule migration to iptables or nftables.

2. Confirm containerd version
Kubernetes deprecated containerd 1.6/1.7 starting from 1.34, and 1.35 is the last version to support containerd 1.x; 1.37 continues to remove legacy kubelet configuration items, with KubeletCgroupDriverFromCRI (GA in 1.36) becoming the only path for cgroup driver detection. If nodes are still running containerd 1.x, migrate to containerd 2.0+ before upgrading to 1.37:

containerd --version
kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.nodeInfo.containerRuntimeVersion}{"\n"}{end}'

Before migration, you can run ctr deprecations list on 1.7.21+ to check for incompatibilities; monitoring/operations tools that directly access the containerd socket need to confirm they use CRI v1 (containerd 2.0 has removed CRI v1alpha2).

3. Confirm cgroup version
Since 1.35, failCgroupV1 defaults to true, and 1.37 still allows temporary override via failCgroupV1: false, but cgroup v1 support will be removed in subsequent versions (KEP-5573). Capabilities such as In-Place Pod Resize and tiered memory protection depend on cgroup v2:

stat -fc %T /sys/fs/cgroup/

4. Validate HPAScaleToZero in pre-production
For queue/event-driven Deployments, configure minReplicas: 0 using External or Object metrics, and observe whether scaling down, scaling up, and the ScaledToZero condition behave as expected.

5. Evaluate DRA taint rules for GPU clusters
If you have enabled DRA, create a DeviceTaintRule in the staging environment and verify whether NoSchedule/NoExecute and ResourceClaim toleration policies work as expected.

Summary¶

Kubernetes 1.37 pushes several long-discussed evolution lines to actionable stages at the same time: HPA scale-to-zero makes idle cost controllable, DRA device taint tolerations brings native semantics to GPU cluster fault isolation, and IPVS phase-out forces kube-proxy to unify to nftables. There may not be a single “killer feature” among the 86 enhancements, but for those responsible for cluster lifecycle management, this is exactly the right time to formulate a Q3-Q4 upgrade roadmap.

There are about three weeks left before the official launch. It is recommended to use the commands above to check the kube-proxy mode, containerd version, and cgroup status now; after the CHANGELOG is released on August 26, make the final Go/No-Go decision by comparing the diff.