Kubernetes 1.37 Garhwal: What Matters in 5 Minutes

Listen to this article
AI-narrated article - 8 min 06 sec. Prose is preserved; code and diagram cues refer to the examples below.

Read the narration transcript - Open audio

Kubernetes 1.37 improves autoscaling, memory management and workload identity. Here are the changes worth understanding and the EKS checks to make before upgrading.

TL;DR

Kubernetes 1.37 Garhwal introduces practical improvements for production clusters. HPA scale-to-zero can remove idle workers, but requires metrics that survive absent Pods. Memory QoS is beta and enabled, while protection and throttling still need explicit kubelet settings. Stable Pod certificates require a configured signer and application reload support. Control-plane streaming reduces temporary read-buffer pressure, and Metrics API adoption must preserve HPA compatibility. Amazon EKS now documents 1.37 availability. Before upgrading, review SELinux volume sharing, Auto Mode consolidation and custom node configuration, then validate one change against a measurable application requirement.

5-minute read · Updated October 8, 2026

Kubernetes 1.37 “Garhwal,” released on August 26, brings useful changes to idle capacity, memory management, workload identity and control-plane recovery. The practical question is which changes your applications can use—and which dependencies you must supply. Release announcement.

Official artwork from the Kubernetes release team, shown as a static image.

Scale idle workers to zero

HPA scale-to-zero is beta and enabled by default. An HPA can set minReplicas: 0 when it uses a suitable External or Object metric. Queue backlog is a useful signal because it exists even when every worker has stopped. CPU and memory usage cannot wake absent Pods.

You still need a metrics adapter. Keep the exporter and adapter independent of the Deployment that scales to zero; otherwise, stopping the workers could remove their wake-up signal. Start the Deployment with at least one replica: manually setting it to zero pauses autoscaling, while an HPA-owned zero is tracked through ScaledToZero. HPA scale-to-zero.

This example assumes an existing queue-worker Deployment and an adapter exposing total queue_depth. The target represents 25 queued messages per worker:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: queue-worker
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: queue-worker
  minReplicas: 0
  maxReplicas: 20
  metrics:
    - type: External
      external:
        metric:
          name: queue_depth
        target:
          type: AverageValue
          averageValue: "25"

At a nonzero replica count, 250 queued messages suggest an idealized ten workers. Actual decisions also depend on stabilization, tolerance and scaling policies. HPA algorithm.

Operational takeaway: measure the time from new work arriving to workers becoming ready. Node provisioning and image pulls can dominate that delay. A durable queue can absorb it; a Kubernetes Service does not buffer HTTP requests while no backend is ready. Preserve the distinction between an empty queue and a failed metric.

Memory QoS needs explicit configuration

MemoryQoS becomes beta, with its gate enabled by default on 1.37 kubelets. That does not automatically activate memory protection or throttling: memoryReservationPolicy defaults to None, and memoryThrottlingFactor defaults to null.

For a Linux cgroup v2 canary node, these fields opt into both behaviors. Merge them into supported kubelet configuration; this is not a manifest for kubectl apply:

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
memoryReservationPolicy: TieredReservation
memoryThrottlingFactor: 0.9

Reservation is node-wide, so test a dedicated node group before broader adoption. Memory QoS defaults and configuration.

The kernel controls address different problems: memory.min and memory.low protect memory from reclaim, memory.high introduces reclaim pressure and throttling, and memory.max enforces the hard limit. Throttling does not guarantee protection against OOM. Linux memory controller.

Operational takeaway: compare tail latency and memory-pressure counters, not just restart counts. A service that avoids OOM but stalls under reclaim pressure can still miss its SLO.

Certificates and recovery get stronger foundations

Pod certificates and ClusterTrustBundles are stable. The kubelet manages projected key and certificate material, while a configured signer authorizes issuance. You still need the signer, the right trust anchors and application support for refreshing TLS credentials. A fresh certificate file does not prove new connections use it. Pod certificate architecture.

etcd RangeStream is beta and on by default, requiring etcd 3.7 or newer. It streams collection reads in chunks, reducing temporary buffering pressure during cache initialization and direct reads. Older etcd uses the fallback path. This does not eliminate the memory needed for the final watch cache. RangeStream implementation.

The Metrics API reaches v1, but compatibility still matters: the 1.37 HPA uses v1beta1. Keep beta serving available while adopting the stable API, and verify your metrics provider supports it. Metrics API compatibility.

What EKS operators should check

AWS now documents Kubernetes 1.37 as available on EKS. Before upgrading, focus on these provider-specific changes:

• SELinux volume sharing: CSI mount labeling can leave Pods in ContainerCreating when shared volumes use incompatible labels or policies. Audit drivers and affected workloads.
• Auto Mode consolidation: new NodePools without an explicit policy default to Balanced; built-in pools also use it. Review your intended disruption behavior.
• Custom node images: remove deprecated cAdvisor flags and review dashboards that depend on removed kubelet metrics.
• Missing integrations: EKS does not install the external metrics adapter or DRA driver for you; DRA support also depends on the compute path.

Verify the target Region, node images and add-on compatibility. EKS 1.37 release notes.

Choose one change to validate first

Start with a concrete production problem: idle queue workers, memory contention or credential rotation. Establish a baseline, enable one change in staging and test its failure path. For scale-to-zero, verify idle-to-zero and wake-up with new work. For Memory QoS, measure latency under contention. For certificates, test rotation and signer outage. Promote only when the observed behavior meets your application's requirements.

FAQ

Can CPU metrics wake a Deployment from zero? No. Use a suitable External or Object metric that remains available without worker Pods.

Does Memory QoS automatically start throttling? No. The gate is enabled, but reservation and throttling require explicit kubelet settings.

Does upstream feature maturity guarantee EKS activation? No. Check AWS release notes, required integrations and the configuration supported by your compute environment.