County analytics must keep HPA from scaling a batch API below a floor or above a cost ceiling. Which HPA fields constrain that range?
Select an answer to reveal the explanation.
Short Explanation
min and max replicas are the guardrails on the on-ramp—HPA can speed up or slow down only between those posts so cost and capacity stay sane.
Full Explanation
County analytics that must keep HPA from scaling a batch API below a floor or above a cost ceiling should set minReplicas and maxReplicas on the HPA. Those fields bound the allowed replica range: the autoscaler will not go below the floor that keeps a minimum civic capacity and will not exceed the ceiling that protects cluster cost and neighbor workloads. That range is the primary administrative constraint for HPA sizing on a municipal batch API and is what capacity planners quote when finance asks for a hard upper bound.
Only hostPort on containers publishes ports on the node; it does not bound HPA replica counts. Only fsGroup in a securityContext sets volume group ownership; it is not an autoscaling range control. Only topologySpreadConstraints balance Pods across topology domains; they do not replace minReplicas and maxReplicas on the HPA object.
Exam caveat: maxReplicas is required; minReplicas defaults to 1 if omitted in many versions—know that an explicit floor matters for analytics SLOs. Operational check: kubectl get hpa -o yaml and confirm minReplicas and maxReplicas, then watch the HPA under load and idle to ensure the county batch API stays inside the configured band. This distinction matters on the CKA because distractors often mix adjacent objects that sound related but solve a different control-plane problem.