Kubernetes 1.37 “Garhwal”: What Changes in Your Cluster

Overview

Let idle workers sleep, recover the API server without flooding etcd, and manage individual GPUs: what Kubernetes 1.37 changes and where to adopt it.

By the Maborak engineering team · 2026-11-02 · 15 min read

An empty queue does not need a worker waiting beside it. A faulty GPU should not force you to treat an entire machine as unavailable. Kubernetes 1.37 addresses both situations: native autoscaling can reach zero replicas, while stable device-allocation features give operators more control over individual accelerators. The release also changes how API servers rebuild their caches after a restart. 4 (opens in a new tab)

These changes affect different parts of the platform. Application teams can reconsider how they run intermittent workers. Infrastructure teams get new tools for allocating hardware and recovering the control plane. Understanding the boundary between those responsibilities is where the release becomes useful.

The latest stable patch is 1.37.2, checked on 2 November 2026. This guide explains the 1.37 capabilities, the latest patch repairs, and the provider support and compatibility checks that shape adoption. 1 (opens in a new tab) 7 (opens in a new tab)

Checked 2 November 2026.

Stop keeping a worker alive for an empty queue

Consider a report-generation service that receives requests during business hours and waits overnight. Its workers take tasks from a queue. Keeping one worker running preserves a way to notice new work, but leaves that Pod’s requested capacity occupied when there are no reports to generate.

The HorizontalPodAutoscaler, or HPA, adjusts a workload’s replica count from metrics. A CPU-only HPA cannot wake a Deployment from zero: no worker means no CPU measurement. A queue-length signal exists independently of the workers, so Kubernetes can continue observing demand after the last Pod stops. In 1.37, HPA scale-to-zero reaches beta and is enabled by default; workloads opt in using minReplicas: 0 and an External or Object metric. 2 (opens in a new tab)

For an external signal, a metrics adapter must expose the queue measurement through external.metrics.k8s.io. Installing metrics-server for CPU and memory does not provide that adapter. Both the metric producer and adapter must keep running when the workers stop, returning a real zero for an empty queue rather than disappearing. 2 (opens in a new tab) 6 (opens in a new tab)

Diagram: a queue producer sends reports to a queue; the queue feeds a metrics adapter, which feeds the HPA; the HPA sets replicas on a Deployment that starts zero to N workers; the workers consume from the queue. A note explains that the queue and adapter stay available at zero replicas, while a CPU metric cannot wake a workload because no Pods are running.

Figure 1. The wake-up signal lives outside the workers. At zero replicas the queue and adapter keep running, so the HPA can still read the metric and restore the Deployment. 2 (opens in a new tab)

This minimal illustrative example targets an existing default/queue-worker Deployment. The metric name and selector stand for a signal configured in your adapter; they are not built-in Kubernetes metrics. The YAML has not been cluster-tested. 2 (opens in a new tab)

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: queue-worker
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: queue-worker
  minReplicas: 0
  maxReplicas: 10
  metrics:
    - type: External
      external:
        metric:
          name: queue_consumer_lag
          selector:
            matchLabels:
              name: worker_tasks
        target:
          type: Value
          value: "30"

Here, scaleTargetRef identifies the Deployment. The replica bounds allow HPA to stop every worker while limiting scale-up to ten. Its metric selector chooses the worker_tasks queue signal, and 30 is the target value used in the scaling calculation. This Value target does not mean a fixed one-worker-per-30-tasks rule; per-Pod AverageValue targets have different semantics. 2 (opens in a new tab)

Start the Deployment with at least one replica and let HPA perform the downscale. Its ScaledToZero condition records that HPA owns the zero-replica state and should watch for demand again. Manually setting the target to zero without that condition leaves it paused instead. Finish upgrading both the API server and controller-manager before relying on this behavior. 2 (opens in a new tab)

Choose workloads that can wait for startup

A queued report can wait while a worker starts. An HTTP request needs somewhere to wait too: HPA does not provide a request buffer in front of an empty service. Choose workloads whose queue and latency requirements can absorb startup, including image pulls and application initialization. Downscaling also takes time: the default stabilization window is five minutes. 2 (opens in a new tab)

Stopping Pods releases their requested capacity; removing unused nodes remains a separate node-autoscaler decision. Keep KEDA (opens in a new tab) if you need its event-source integrations or ScaledJob behavior rather than only the zero-replica transition. 3 (opens in a new tab)

For a first trial, let the report queue empty and confirm that HPA reaches zero. Submit another report, observe the worker returning, and measure the delay before processing starts. That delay determines whether this design suits the service. Inspect the HPA’s metrics and conditions if recovery stalls; a missing metric is an error, not evidence of an empty queue. 2 (opens in a new tab)

Pick the autoscaler that owns the signal

The three common choices differ less in their scaling arithmetic than in who supplies the metric and what else you have to operate. 2 (opens in a new tab) 3 (opens in a new tab) 16 (opens in a new tab)

Option	Signal	Reaches zero?	You also operate	Fits
Resource HPA	CPU or memory from running Pods through `metrics.k8s.io`	No	metrics-server	Services whose load tracks CPU or memory, with at least one worker always available
HPA with object or external metric	A queue or object measurement through `custom.metrics.k8s.io` or `external.metrics.k8s.io`	Yes, with `minReplicas: 0`	An adapter and a metric producer that survive at zero	Queue consumers that can absorb cold starts and do not need a separate autoscaling platform
KEDA	Event-source scalers, with queries and credentials managed by KEDA	Yes	The KEDA operator and its scaler configuration	Many event sources, authentication-heavy triggers, or job-per-event workloads that already use KEDA

Table 1. Native HPA scale-to-zero replaces the zero-replica transition, not every reason to run KEDA. 2 (opens in a new tab) 3 (opens in a new tab) 16 (opens in a new tab)

Recover the API server without flooding etcd

The workers depend on a control plane that can recover too. Kubernetes stores cluster objects in etcd, its backing store. API servers maintain watch caches so ordinary reads and watches do not all become storage requests. After a restart, an API server has to repopulate those caches while clients are already asking for objects. Sending that demand straight to etcd can make recovery harder just when the control plane needs to rebuild. 4 (opens in a new tab)

In 1.37, WatchCacheInitializationPostStartHook becomes stable and locked on. This stabilizes a remaining hook in an existing resilient-initialization design, rather than introducing the entire recovery architecture. While a cache warms, GET requests and constrained, unfiltered, paginated LIST requests can still reach etcd. Other LISTs and WATCHes can receive HTTP 429 instead of piling up. Custom clients must respect retry delays and use backoff; repeatedly retrying immediately defeats that protection. 4 (opens in a new tab)

Two related changes address the rebuilding work itself. Beta EtcdRangeStream, enabled by default, consumes large etcd responses in chunks rather than retaining a complete response before processing it. Its streaming RPC needs etcd 3.7+; older servers trigger a fallback to the non-streaming path. Concurrent watch decoding also becomes default-on, processing events with a bounded worker pool while preserving order. Slow custom-resource conversions need not serialize all that work, but conversion webhooks must handle the additional simultaneous requests. 4 (opens in a new tab)

For operators of large clusters, the practical review is therefore on both sides of recovery: etcd and API-server initialization, plus the clients and conversion webhooks participating in it. Do not treat a temporary 429 during cache warm-up as a reason to remove backoff. 4 (opens in a new tab)

Put individual GPUs under allocation control

An accelerator workload often asks for hardware using a resource name such as example.com/gpu. Dynamic Resource Allocation (DRA) adds a device-allocation model: a driver publishes available devices, a DeviceClass describes which devices qualify, and a ResourceClaim records an allocation request and its result. That gives infrastructure teams device-level control, but asking every application author to write claim objects creates migration work. 5 (opens in a new tab)

Stable extended-resource support in 1.37 connects those two approaches. An operator maps the familiar resource name through DeviceClass.spec.extendedResourceName. Existing workloads keep their resource requests while Kubernetes uses generated claims for DRA allocation. The workload author avoids hand-written ResourceClaim YAML; claims still exist behind the scenes. 5 (opens in a new tab)

Diagram: a Pod requests one example.com/gpu device; a DeviceClass maps that resource name to the class; Kubernetes creates a generated ResourceClaim; the DRA driver receives the allocation request and configures one device on a node. The node holds three GPUs: two are available and one is tainted.

Figure 2. The Pod keeps its familiar extended-resource request. The DeviceClass mapping lets Kubernetes generate a claim and ask the DRA driver for one device; a device taint can remove one GPU without cordoning the node. 5 (opens in a new tab)

The platform team still needs a suitable DRA driver, device inventory and class mapping. Upgrading Kubernetes does not convert a vendor device plugin into that driver. This is a way to change the allocation backend without simultaneously rewriting every consuming workload. 5 (opens in a new tab)

Device taints and DeviceTaintRule also become stable. If one GPU is faulty, operators can prevent new allocations of that device rather than marking the whole host unavailable. An untolerated NoExecute device taint can also evict its users. The 1.37.2 repair below matters here: that eviction path must find generated claims as well as explicit ones. Include both allocation and eviction in a DRA trial. 5 (opens in a new tab) 9 (opens in a new tab)

CPU and memory metrics get a stable API

The resource metrics API graduates to metrics.k8s.io/v1, retaining the resource types and fields from v1beta1. This is a stable API contract for CPU and memory measurements, not a new monitoring backend or the queue-metric adapter used above. 6 (opens in a new tab)

An aggregated implementation, commonly metrics-server, must actually serve v1 and register its APIService. Upgrading the core alone does not create that endpoint. kubectl top prefers v1 and falls back to v1beta1, while the 1.37 HPA controller still uses v1beta1. Keep the beta endpoint during migration; Kubernetes 1.37 has not removed it. 6 (opens in a new tab)

Use the patch fixes, not just the minor number

The minor release supplies the capabilities above; 1.37.2 repairs failures in particular operating paths. Three fixes are worth matching against your workloads. The merged backports include regression tests, inspected rather than run locally. 7 (opens in a new tab) 8 (opens in a new tab) 9 (opens in a new tab) 10 (opens in a new tab)

Recreated Jobs can resume reconciliation. Deleting a Job while Pod creation was in flight, then recreating the same name with a new UID, could leave the replacement waiting on the old Job’s bookkeeping. Issue #142142 (opens in a new tab) led to backport #142390, which clears those expectations on deletion. Its integration test recreates the Job while the old Pod request is blocked. 8 (opens in a new tab)
Device taints reach generated claims. The eviction controller missed DRA claims stored in extended-resource Pod status. An untolerated NoExecute taint could therefore leave those Pods running. Issue #141290 (opens in a new tab) and backport #142492 add the missing claim traversal, with eviction and ownership tests. That backport targets 1.37, not older minors. 9 (opens in a new tab)
kube-proxy avoids an unnecessary privileged write. A 1.36 regression made it try to lower an already sufficient nf_conntrack_max; restricted deployments could fail without sysctl-write permission. Issue #141943 (opens in a new tab) and backport #142198 fix that decision, with tests for higher, equal and lower existing values. 10 (opens in a new tab)

Security fixes in 1.37.1 also carry forward. September advisories cover crafted StatefulSet revisions crossing a namespace boundary through controller-manager (CVE-2026-2270) and Windows kubelet following network-share paths and exposing NTLM authentication material (CVE-2026-76654 (opens in a new tab)). Both affect 1.37.0 and were fixed in 1.37.1, not newly in October. Patch the affected controller-manager and Windows kubelets; updating only the API server or kubectl is insufficient. 11 (opens in a new tab)

EKS, GKE and AKS offer different routes to 1.37

The following is a public-documentation snapshot checked on 2 November 2026, not an authenticated regional inventory. A selectable version can differ from the creation default, and an announced rollout can still be reaching deployment locations. These records do not establish inclusion of every upstream 1.37.2 repair in provider builds. 12 (opens in a new tab) 13 (opens in a new tab) 14 (opens in a new tab)

Service	Advertised 1.37 availability	Patch and default boundary
Amazon EKS	Creation/upgrades across EKS Regions; announced 2 October	Platform table lists 1.37.0 / eks.4. The reviewed static pages do not establish the current default minor. 12 (opens in a new tab)
Google GKE	Rapid, Regular, Extended and no channel; not Stable	Rapid offers 1.37.1-gke.3020000, default 1.37.1-gke.1697000. Regular/Extended offer 1.37.1-gke.1552000, default 1.36.4-gke.2046003. Stable defaults to 1.35.8-gke.1439001. Verify zonal availability. 13 (opens in a new tab)
Azure AKS	GA/LTS designation announced 27 October	1.37.1 announced; 1.36 remains the new-cluster default. Regional rollout can take 10 business days. LTS requires enrollment, not merely selecting 1.37. 14 (opens in a new tab)

The differences have documented operational reasons. AWS qualifies releases (opens in a new tab) and rolls platform updates out incrementally. Google promotes minors after usage and stability validation in earlier channels (opens in a new tab), and its build suffix can include Google Cloud compatibility fixes; Rapid versions are excluded from the GKE SLA. Microsoft stages regional deployment as a safe-deployment practice (opens in a new tab). These policies explain why versions are qualified and promoted, without identifying a specific bug as the cause of the entire 1.37 adoption interval. 12 (opens in a new tab) 13 (opens in a new tab) 14 (opens in a new tab)

Before scheduling an upgrade, check the versions and eligible targets exposed for your region, channel and existing cluster. Treat the provider build and node image as part of that target, not just the 1.37 label. 12 (opens in a new tab) 13 (opens in a new tab) 14 (opens in a new tab)

Check the changes that can stop an upgrade

Shared SELinux volumes: 1.37 enables SELinuxMount by default. Supporting Container Storage Interface (CSI) drivers use mount labels instead of recursive file relabeling. Conflicting labels or mixed policies on shared volumes can prevent Pods starting. Check volume_manager_selinux_volume_context_mismatch_warnings_total beforehand; affected workloads can consistently use seLinuxChangePolicy: Recursive. 7 (opens in a new tab) 15 (opens in a new tab)
Removed configuration and APIs: migrate kubeadm v1beta3 configuration to v1beta4 using the documented 1.35 kubeadm migration path. Remove scheduling.k8s.io/v1alpha2 objects before upgrading. Static Pods can no longer reference API Secrets or ConfigMaps; ordinary API-created Pods are not subject to that ban. 4 (opens in a new tab) 7 (opens in a new tab)
Node startup and integrations: obsolete embedded-cAdvisor flags now prevent kubelet startup. Verify runtime, Container Network Interface (CNI), CSI and node-image support for the target build. Kubernetes 1.37 does not universally require containerd 2.0; use the distribution’s compatibility requirements. Keep the metrics beta endpoint while upgrading its implementation, as described above. 6 (opens in a new tab) 7 (opens in a new tab)
Upgrade order: do not skip upstream API-server minors. The upstream skew policy (opens in a new tab) forbids kubelets newer than the API server and allows three minors behind; GKE allows only two. Check provider node-image and add-on requirements separately from the control plane. 13 (opens in a new tab)

Windows AKS deployments need an extra check: September notes exclude Windows Server 2022 from 1.37+, but the supported-version table still lists it. Get provider confirmation before choosing that image rather than treating the component table as overriding the explicit retirement note. 14 (opens in a new tab)

Queue consumers that can tolerate startup delay have a direct reason to try native zero-replica scaling. Latency-sensitive HTTP services without buffering still need available workers. Accelerator clusters can adopt a DRA backend while preserving familiar resource requests, provided the driver and device-maintenance path are ready. 2 (opens in a new tab) 5 (opens in a new tab)

Choose one representative workload on the offered patched build: a report worker that sleeps and wakes, or a GPU consumer whose device can be tainted and replaced. Complete the compatibility checks first, then use that trial to decide whether the new behavior meets the workload’s requirements. 2 (opens in a new tab) 5 (opens in a new tab) 9 (opens in a new tab)

Resources for a first trial

HPA behavior and rollback: KEP-2021 (opens in a new tab) records the ScaledToZero design, the 1.37 beta graduation, the API-server/controller-manager skew and the rollback step. The HPA documentation (opens in a new tab) states the current field rules. 16 (opens in a new tab)
Queue metric plumbing: the Prometheus Adapter external-metrics rules (opens in a new tab) show how an external series becomes external.metrics.k8s.io/v1beta1 and how namespace handling changes the query. 17 (opens in a new tab)
DRA allocation: Allocate Devices to Workloads with DRA (opens in a new tab) is the workload-operator walkthrough; KEP-4381 (opens in a new tab) explains structured parameters and scheduler ownership. 18 (opens in a new tab)
Device maintenance: Device Taints and Tolerations (opens in a new tab) covers driver and administrator taints, effects and eviction. 18 (opens in a new tab)
Stable metrics contract: the metrics.k8s.io/v1 reference (opens in a new tab) lists the node, Pod and container metric types an implementation must serve. 19 (opens in a new tab)

Sources

Upstream and provider availability were checked on 2 November 2026. Earlier research found stale patch dates on the upstream website; the latest-stable conclusion uses the agreeing release metadata and artifact pointer. The v1.37.2-tagged changelog omits its own patch section, so current notes were cross-checked with merged backports. 1 (opens in a new tab) 7 (opens in a new tab)

Release metadata — Kubernetes SIG Release; 1.37 minor released 26 August 2026, v1.37.2 GitHub publication 28 October. Release API (opens in a new tab), artifact pointer (opens in a new tab), release listing (opens in a new tab), website index (opens in a new tab), 1.37 page (opens in a new tab). Supports latest stable, prerelease distinction and stale website metadata.
HPA scale-to-zero — Kubernetes; 2 September 2026, feature beta in 1.37. Feature explanation and example (opens in a new tab), v1.37.2 controller (opens in a new tab), replica calculator (opens in a new tab). Supports prerequisites, ownership condition, timing and metric-target semantics.
Node scaling and KEDA scope — Kubernetes and KEDA; current Kubernetes documentation checked 2 November 2026; KEDA version 2.18. Node autoscaling (opens in a new tab), KEDA concepts (opens in a new tab). Supports the distinction between replica scaling, node savings and event-source integrations.
Kubernetes v1.37 release and cache recovery design — Kubernetes; 26 August 2026, KEP-4568. Release announcement (opens in a new tab), KEP-4568 (opens in a new tab). Supports recovery stages, HTTP 429 behavior, RangeStream, decoding concurrency and static-Pod restrictions.
DRA updates — Kubernetes; 3 September 2026, stable 1.37 capabilities. Feature article (opens in a new tab), v1.37.2 resource API (opens in a new tab). Supports extended-resource mapping, generated claims, driver requirements and device taints.
Metrics API graduation — Kubernetes; 27 August 2026, metrics.k8s.io/v1 in 1.37. Implementation and client guidance (opens in a new tab). Supports unchanged resource scope, APIService registration and continued v1beta1 use.
CHANGELOG-1.37 — Kubernetes; release notes for 1.37.0–1.37.2, checked 2 November 2026. Current notes (opens in a new tab), v1.37.2 snapshot (opens in a new tab). Supports patch inclusion, API/configuration removals and node/runtime warnings; records the snapshot discrepancy.
Job expectation repair — Kubernetes; backport #142390 merged 16 October 2026, fixed 1.37.2. Original PR #142247 (opens in a new tab), merged source and tests (opens in a new tab). Supports same-name recreation trigger and expectation cleanup.
Generated-claim eviction repair — Kubernetes; backport #142492 merged 16 October 2026, fixed 1.37.2. Original PR #142289 (opens in a new tab), backport scope (opens in a new tab), source and tests (opens in a new tab). Supports missed status claims, eviction tests and 1.37-only backport.
Conntrack repair — Kubernetes; backport #142198 merged 16 October 2026, fixed 1.37.2. Original PR #142035 (opens in a new tab), merged source and tests (opens in a new tab). Supports the restricted kube-proxy failure and conditional sysctl write.
September security repairs — Kubernetes Security Response Committee; advisories 14 September 2026, fixed 1.37.1. StatefulSet advisory (opens in a new tab), repair #142159 (opens in a new tab), Windows advisory (opens in a new tab), repair #142168 (opens in a new tab). Supports affected components and prior-patch timing.
EKS 1.37 availability — AWS; announcement 2 October 2026, platform row dated 1 October; checked 2 November. Announcement (opens in a new tab), platform table (opens in a new tab), version policy (opens in a new tab). Supports regional availability, 1.37.0/eks.4 and qualification process.
GKE versions and channels — Google Cloud; release notes 26–27 October 2026, versioning updated 30 October; checked 2 November. Release notes (opens in a new tab), channels (opens in a new tab), versioning (opens in a new tab). Supports offered builds, defaults, zonal rollout, Rapid SLA exclusion and node skew.
AKS availability and node requirements — Microsoft; release 2026-10-25 published 27 October, September prerequisite notes; checked 2 November. GA release (opens in a new tab), version policy (opens in a new tab), LTS enrollment (opens in a new tab), 25 September notes (opens in a new tab). Supports 1.37.1/default 1.36, deployment timing and conflicting Windows2022 guidance.
SELinux migration and upgrade skew — Kubernetes; SELinux warning 22 April 2026 for 1.36→1.37; current skew policy checked 2 November. Warning (opens in a new tab), KEP-1710 (opens in a new tab), skew policy (opens in a new tab). Supports shared-volume checks, Recursive policy and upgrade sequencing.
HPA scale-to-zero design and field rules — Kubernetes; KEP-2021 beta in 1.37, documentation checked 2 November 2026. KEP-2021 (opens in a new tab), HPA documentation (opens in a new tab). Supports ScaledToZero, component skew, rollback, scale-up timing and feature state.
External metric adapter rules — Kubernetes SIG Instrumentation; prometheus-adapter current documentation checked 2 November 2026. External metrics rules (opens in a new tab). Supports external rule mapping, namespace handling and external.metrics.k8s.io/v1beta1.
DRA implementation references — Kubernetes; KEP-4381, allocation task and device-taint documentation checked 2 November 2026. KEP-4381 (opens in a new tab), allocation task (opens in a new tab), device taints (opens in a new tab). Supports structured allocation, generated claims, driver responsibilities and per-device taints.
Metrics v1 API reference — Kubernetes; v1.37 reference checked 2 November 2026. metrics.k8s.io/v1 (opens in a new tab). Supports node, Pod and container metric fields.

Topics: kubernetes, infrastructure, migration

Back to all articles