Kubernetes v1.37 Native Scale-to-Zero HPA Eliminates Idle Cluster Spend

The Kubernetes project has advanced native scale-to-zero support in the HorizontalPodAutoscaler (HPA) to Beta status in version 1.37, activating the capability by default across clusters. Under this enhancement, setting `minReplicas: 0` in an HPA definition allows the `kube-controller-manager` to safely scale target Deployments down to zero pods when driven by object or external metrics, such as message queue depth or worker job counts. Crucially, the controller introduces a dedicated `ScaledToZero` status condition to distinguish automated zero-replica scaling from manual administrative pauses, allowing the controller to dynamically scale the workload back up when inbound demand re-emerges. For platform engineers and FinOps practitioners, this graduation delivers a long-requested efficiency milestone directly in the upstream control plane. In typical multi-tenant or asynchronous processing environments, maintaining a single idle pod per service—especially for large fleets of internal microservices, batch consumers, or expensive GPU-backed workers—results in significant compute wastage. By removing the mandatory minimum replica constraint for metrics that exist independently of pod execution, teams can reclaim node capacity and reduce cloud spend without relying on bespoke operational workarounds. This release reflects a broader architectural convergence between traditional container orchestration and serverless execution models. Historically, Kubernetes users seeking scale-to-zero behavior had to adopt external extensions such as KEDA (Kubernetes Event-driven Autoscaling) or Knative Serving. While these tools remain valuable for rich event-trigger ecosystems and complex HTTP request buffering, embedding core scale-to-zero semantics directly into the upstream HPA streamlines platform architecture. It positions native Kubernetes as a more viable runtime for sporadic, asynchronous, and AI/ML inference workloads where idle instances represent unsustainable cost centers. In practice, platform operators must account for architectural trade-offs before broadly applying `minReplicas: 0`. Native HPA scale-to-zero only functions with object or external metrics; standard CPU and memory metrics cannot be used because their data streams terminate when all pods stop running. Furthermore, scaling from zero introduces cold-start latency, making this mechanism ideal for asynchronous message queues where jobs can wait in a durable buffer rather than synchronous, latency-critical HTTP APIs that lack ingress request holding. During cluster upgrades, teams must also ensure both `kube-apiserver` and `kube-controller-manager` support the feature gate before configuring zero-replica targets to prevent workloads from stalling.