HPA scale-to-zero depends on an independent demand signal
Kubernetes 1.37 can reactivate workloads it has scaled to zero through object or external metrics. Reliable adoption needs a working metrics path and a deliberate distinction between idling and manual pause.
The Kubernetes project has published operational guidance for HPA scale-to-zero. The feature is beta and enabled by default in Kubernetes 1.37. It lets an HPA using an appropriate object or external metric remove the last idle pod and restore capacity when demand returns. CPU and memory metrics cannot provide that reactivation signal because they depend on running pods.
I would evaluate this first for work that can wait in a durable queue. The guidance identifies queue consumers and batch processors as suitable examples. It also warns that Kubernetes Services do not buffer requests while no pods are ready. A request-driven application therefore needs a separate buffering arrangement before a zero-replica state becomes a useful operating mode.
After eight years with Kubernetes, I value a controller that can recover its intended behavior across reconciliation loops. The detail that interests me here is the explicit status used to preserve intent. A zero replica count alone cannot explain whether autoscaling should wake the workload. That ambiguity has to be resolved before the controller can handle idling safely.
Zero and paused have different meanings
The Kubernetes 1.37 release announcement describes the ScaledToZero condition. When HPA reduces an active workload to zero, it records ScaledToZero=True. Later reconciliations use that condition to recognize a zero state that the controller should continue managing. After bringing the workload back, it sets the condition false with the reason NotScaledToZero.
Manual deactivation retains its established meaning. The September guidance says to start the Deployment with at least one replica. A workload manually set to zero without the condition remains paused. Setting minReplicas: 0 does not turn every zero-replica Deployment into an automatically reactivating workload.
I would include that distinction in the operating procedure. An engineer responding to an idle queue worker needs to inspect why it is at zero before changing configuration. The guidance provides a straightforward inspection command, shown here with an illustrative context:
kubectl --context staging describe hpa queue-worker
The HPA name follows the source example. I would inspect its conditions alongside the target workload and the configured metric. A healthy metrics request and a zero-state condition answer different questions. Both are relevant when the expected response to new work is not happening.
The demand signal must survive the workers
An external queue-length metric exists independently of the consumers. The guidance uses that property to explain scaling from zero. Kubernetes still needs an adapter that exposes the measurement through the External Metrics API. The article demonstrates a Prometheus Adapter configuration, while noting that installation and discovery rules depend on the monitoring setup.
I would test the metrics endpoint before creating the HPA. The source explicitly recommends this ordering. If the adapter cannot return the selected metric, the controller cannot use it to restore capacity. An application with no running workers makes the availability of that independent observation path especially consequential.
A metrics failure is also different from an empty queue. The guidance identifies ScalingActive=False and reasons such as FailedGetExternalMetric as diagnostic signals. Recovery can require restoring the metric or manually scaling the workload to recover capacity. I would document the manual recovery step with the service's ownership information before enabling scale-to-zero.
I would include a controlled adapter failure in the adoption exercise. The check should establish which condition appears and how the owner restores processing. It should also confirm that a later valid metric reactivates a workload the HPA previously idled.
Idling adds latency to returning work
The guidance describes the cold-start sequence as observing demand, scheduling a pod, and starting the application. I would measure that sequence against the workload's acceptable waiting time. The existence of a durable queue prevents immediate loss of queued work, but does not establish that the resulting processing delay meets the application's requirement.
Downscale behavior remains subject to ordinary HPA controls. The article states that the default downscale stabilization window is five minutes and identifies spec.behavior.scaleDown as the configuration point. I would first observe behavior under the existing window. Changing it should follow evidence about how often demand disappears and how costly repeated restarts are for the particular workload.
The rollout also has a control-plane requirement. Both kube-apiserver and kube-controller-manager must support the feature and have it enabled. The guidance warns that a controller manager without the condition-based behavior may interpret zero as a manual pause. I would wait until the control-plane transition is complete before introducing HPAs that rely on reactivation.
Rollback needs an explicit preparation step. Before disabling the feature or downgrading to an implementation without the condition-based behavior, the project says to raise affected HPAs to a minimum of at least one and restore any zero-replica workloads to at least one. I would verify both changes in the rollback procedure. The resulting configuration must continue to supply capacity after the controller loses the behavior that previously restored it.