A building-permits platform sees Pod counts thrash up and down under bursty traffic while HPA is enabled. What scale-down awareness should admins apply?
Select an answer to reveal the explanation.
Short Explanation
Bursty traffic can make the replica count yo-yo. Stabilization windows are the shock absorbers—HPA can wait before scale-down so you do not thrash Pods on every blip.
Full Explanation
A building-permits platform that sees Pod counts thrash up and down under bursty traffic while HPA is enabled should understand that HPA scale-down can be delayed or stabilized to reduce flapping risk. Controllers apply stabilization windows and related anti-flapping behavior so brief dips do not immediately destroy capacity that was just added. For bursty permit-submission traffic, admins should tune scale-down behavior and replica bounds rather than assuming instantaneous downsizing is always desirable for citizen experience.
Assuming HPA never scales down under any metric configuration is false—scale-down is a core behavior when utilization stays low. Disabling kube-proxy on all nodes so thrashing Pods cannot receive traffic breaks Service dataplane cluster-wide and is not an HPA remediation. Setting maxUnavailable on the Service object is invalid for this purpose—Services do not use maxUnavailable; that field belongs to Deployment rollingUpdate strategy, not HPA.
Exam caveat: know that flapping often comes from noisy metrics, missing requests, or too-narrow stabilization; fix metrics and bounds before blaming the cluster network. Operational check: describe the HPA, review events and current versus desired replicas over time, adjust targets, min/max, or stabilization-related settings, and retest under synthetic bursty load for the permits API.