kubernetesautoscalingPractitioner

Mastering Kubernetes HPA: Scaling Workloads to Zero

5 min read Kubernetes BlogSep 2, 2026Reviewed for accuracy

Practitioner — Hands-on experience recommended

In a world where resource efficiency is paramount, Kubernetes v1.37's ability to scale workloads down to zero replicas is a significant leap forward. It addresses the common challenge of managing idle resources in cloud-native environments. By leveraging the HorizontalPodAutoscaler (HPA), you can now ensure that your applications only consume resources when they are truly needed, reducing costs and optimizing performance.

The HPA operates by observing metrics and adjusting the number of replicas accordingly. With the introduction of external metrics, you can scale workloads based on conditions like queue length, which is crucial for applications that can afford to wait for tasks in a durable queue. For instance, you can set minReplicas to 0 and maxReplicas to 10, allowing the HPA to manage your workload dynamically. The configuration also includes a scaleDown stabilization window of five minutes, preventing abrupt changes that could destabilize your application. This means your system can effectively respond to varying loads without unnecessary resource consumption.

However, there are some critical considerations to keep in mind. If the metrics adapter fails to return the configured metric, the HPA will report ScalingActive=False, and you’ll need to manually intervene to restore capacity. Additionally, during control plane upgrades, ensure that both components support this feature before creating HPAs with minReplicas: 0. Lastly, remember that setting minReplicas: 0 requires at least one external metric; otherwise, the API server will reject your HPA configuration. Understanding these nuances will help you leverage this powerful feature effectively in production.

Key takeaways

→Configure `minReplicas` to 0 for efficient resource management.
→Use external metrics like queue length to scale workloads dynamically.
→Monitor the HPA status to catch metric retrieval failures early.
→Ensure compatibility during control plane upgrades to avoid disruptions.
→Remember that `minReplicas: 0` requires at least one external metric.

Why it matters

This feature can drastically reduce cloud costs by eliminating idle resources, making it easier to scale applications based on real-time demand. It empowers teams to optimize resource allocation without sacrificing performance.

Code examples

YAML

1apiVersion: autoscaling/v2
2kind: HorizontalPodAutoscaler
3metadata:
4  name: queue-worker
5  annotations:
6    kubernetes.io/description: "Scales queue-worker based on the number of queued tasks"
7spec:
8  scaleTargetRef:
9    apiVersion: apps/v1
10    kind: Deployment
11    name: queue-worker
12  minReplicas: 0
13  maxReplicas: 10
14  metrics:
15  - type: External
16    external:
17      metric:
18        name: queue_consumer_lag
19      selector:
20        matchLabels:
21          name: worker_tasks
22      target:
23        type: Value
24        value: "30"

shell

kubectl get --raw \
'/apis/external.metrics.k8s.io/v1beta1/namespaces/default/queue_consumer_lag?labelSelector=name%3Dworker_tasks'

shell

kubectl describe hpa queue-worker

When NOT to use this

The official docs don't call out specific anti-patterns here. Use your judgment based on your scale and requirements.

Want the complete reference?

Read official docs

Test what you just learned

Quiz questions written from this article

Take the quiz →

Linux Foundation🔥 OCTOBER PROMOSponsor

35% off the CKA and other certifications with code OCT26NONCYBER, or 40% off Kubernetes security certs (CKS, KCSA) with OCT26CYBER.

Claim the discount →

Mastering Kubernetes HPA: Scaling Workloads to Zero

Key takeaways

Why it matters

Code examples

When NOT to use this

More on this topic

Deploying n8n on EKS: Mastering Queue Mode for Production

Unlocking Workloads with SIG Apps: The Heart of Kubernetes

Mastering Resource Resizing for Kubernetes Containers