Kubernetes 1.37 moves the HorizontalPodAutoscaler (HPA) into beta for scaling a workload down to zero replicas, and the feature is turned on out of the box. Engineers who run queue consumers, batch jobs, or any pod that sits idle can now let the control plane retire the last pod, cutting resource spend, while the HPA will resurrect pods when the chosen metric signals demand.
How Zero‑Replica Autoscaling Works
The classic HPA model watches CPU or memory usage, which only exist while at least one pod is running. When the replica count hits zero there is no internal signal to trigger a scale‑up. By switching to an object metric or an external metric, the HPA can keep reading a value that lives independent of the pods—such as the length of a message queue. As long as that metric reports a non‑zero value, the HPA can calculate the desired replica count and create pods.
Configuring an External Metric
Assume a Prometheus series called queue_consumer_lag that tracks pending tasks. The cluster needs a metrics adapter that implements the External Metrics API; the Prometheus Adapter is a common choice. A minimal adapter rule looks like:
externalRules:
- seriesQuery: '{__name__="queue_consumer_lag",name!=""}'
metricsQuery: sum(<<.Series>>{<<.LabelMatchers>>}) by (name)
resources:
overrides:
namespace:
resource: namespace
After the adapter is deployed, verify that Kubernetes can read the metric:
kubectl get --raw '/apis/external.metrics.k8s.io/v1beta1/namespaces/default/queue_consumer_lag?labelSelector=name%3Dworker_tasks'
If the command returns a numeric value, the metric pipeline is functional and the HPA can be created.
Operational and Security Considerations
Scaling to zero introduces a cold‑start delay: the HPA must detect a metric change, schedule a pod, and wait for the container to become ready. Workloads that can tolerate this latency—typically those that pull work from a durable queue—are good candidates. For request‑driven HTTP services, Kubernetes Services do not queue traffic while no pods exist, so a separate buffering component (e.g., a proxy or ingress that holds requests) is required.
Because the HPA’s decision now hinges on an external source, the reliability and integrity of that source become operational concerns. A missing or malformed metric will prevent the HPA from scaling up, effectively causing a denial of service for the workload. Practitioners should monitor the health of the metrics adapter and consider access controls on the metric endpoint to avoid accidental or malicious disruption.
Related CloudNinjas coverage: Kubernetes.
What This Means For Practitioners
- Identify idle‑prone workloads and evaluate whether a durable queue or similar external signal exists.
- Deploy a compatible external‑metrics adapter (e.g., Prometheus Adapter) and confirm metric visibility with the raw API call.
- Design or adopt a buffering layer for request‑driven services that cannot afford a cold start.
- Add health checks for the adapter and metric source to your observability stack to catch outages before they block scaling.
- Review RBAC or network policies around the metrics endpoint to limit exposure to only the HPA controller.