Configure a Kubernetes Horizontal Pod Autoscaler

WHAT THIS TESTS This checks operational Kubernetes knowledge: how HPA computes scaling decisions, what it depends on, and how it differs from other autoscalers.

A GOOD ANSWER COVERS The HPA is a controller that targets a workload like a Deployment and scales its replica count horizontally. You define a target, for example average CPU utilization of 60 percent, plus minReplicas and maxReplicas. Periodically the controller fetches current pod CPU metrics, computes the desired replicas as roughly current replicas times current metric divided by target metric, and updates the Deployment, which the scheduler then reconciles. Two prerequisites are essential. First, the metrics-server must be installed so the HPA can read resource metrics through the metrics API. Second, the pods must declare CPU resource requests, because utilization is measured as a percentage of the request, and without a request the HPA cannot compute a percentage. A strong answer adds that HPA needs spare cluster capacity, and that the Cluster Autoscaler handles adding nodes when pods cannot be scheduled.

COMMON WRONG ANSWERS Confusing HPA with the Vertical Pod Autoscaler, which resizes pods, or the Cluster Autoscaler, which adds nodes. Forgetting the metrics-server dependency. Omitting CPU requests, so utilization is undefined. Assuming HPA can place pods even when the cluster is full.

LIKELY FOLLOW-UPS How does HPA differ from VPA and Cluster Autoscaler? What if there is no spare node capacity? Can you scale on custom or external metrics? How do stabilization windows prevent flapping?

ONE CONCRETE EXAMPLE You set CPU requests of 250m on each pod and create an HPA targeting 60 percent average CPU with min 2 and max 10 replicas. Under load the average climbs to 90 percent; the controller computes it needs more replicas and scales toward the max. As traffic falls it scales back down to 2, and the metrics-server feeds it the readings throughout.