Scaling on queue length with the HPA
external-metric autoscaling.
expose queue length through an external metrics adapter behind the metrics API, point the HPA at that external metric with a target per pod; KEDA packages this.
What's really being asked
Whether you know the HPA cannot read arbitrary sources directly and understand the adapter-based metrics pipeline that feeds it.
The full answer
The HorizontalPodAutoscaler does not connect to your message broker. It reads metrics only through the Kubernetes aggregated metrics APIs: metrics.k8s.io for resource metrics served by metrics-server, and custom.metrics.k8s.io or external.metrics.k8s.io served by an adapter you deploy. For queue length, which is not tied to a pod, you use an external metric. The pipeline is: the queue's depth is collected, often scraped into Prometheus or read from the broker, then an adapter such as the Prometheus Adapter or a KEDA scaler exposes that value through the external metrics API. You then write an HPA with a metric of type External naming the queue-length metric and a target value, typically a target per pod like messages per replica. Each cycle the HPA fetches the current value and computes desired replicas roughly as current divided by per-pod target, scaling out as the backlog grows and in as it drains. KEDA is the common production choice because it ships ready-made scalers for Kafka, SQS, RabbitMQ and more, and can scale to zero.
The mistakes people make
Saying the HPA queries the queue directly; it only consumes the metrics API. Believing the HPA supports just CPU and memory. Using a custom (per-object) metric where an external metric is appropriate for a queue not associated with a pod. Forgetting to deploy and register the adapter, so the metric is unavailable.
What usually comes next
What is the difference between custom and external metrics? How does the HPA's scaling formula and stabilization window prevent flapping? How does KEDA differ from a raw HPA and how does scale-to-zero work? How do you avoid thrashing when the queue is bursty?
A concrete example
Workers consume an SQS queue. You deploy KEDA with an SQS scaler targeting thirty messages per pod. KEDA exposes the queue depth via the external metrics API and manages an HPA. When the queue holds 300 messages, the HPA targets about ten replicas; as workers drain it to 30, it scales back toward one, and KEDA can scale to zero when the queue is empty.
Interview question
You want the HPA to scale workers by message-queue depth. Why can it not simply read the queue, and what makes it work?
- a.It can read the queue directly once you grant it broker credentials
- b.It reads only through the metrics APIs, so an adapter must expose queue depth as an external metricCorrect
- c.The HPA supports only CPU and memory, so queue-based scaling is impossible
- d.You must replace the HPA with a CronJob that polls the queue
Why? this is the answer
The HPA consumes metrics solely via the aggregated metrics APIs, so you deploy an adapter (or KEDA) that surfaces queue depth as an external metric. The HPA does support custom and external metrics, and need not be replaced.
Just read this? Test yourself on what you have been reading.
Read the original → github.com
- #kubernetes
- #hpa
- #autoscaling
- #keda
- #metrics
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on kubernetes — each one lists the topics its interview covers.
See open roles