Transit sets an HPA CPU utilization target on a schedules API, but utilization percentages are meaningless without a baseline. What must Pods define for those targets to work?
Select an answer to reveal the explanation.
Short Explanation
CPU utilization is 'how full is the tank versus the tank size you declared.' Without a CPU request, HPA has no denominator for that percentage—set requests so the math works.
Full Explanation
Transit setting an HPA CPU utilization target on a schedules API finds that utilization percentages are meaningless without a baseline: Pods must define CPU resource requests on the containers so utilization can be computed. Resource-based HPA utilization is generally current usage divided by requests as a percentage target. Without requests, the autoscaler lacks the denominator needed for a sensible CPU target on the schedules Deployment, so scale decisions will not behave as operators expect during rush hour.
Only stdin and tty flags on the container affect interactive attachment behavior; they do not establish CPU request baselines for HPA. Only a preStop lifecycle hook with no resource requests handles shutdown signaling, not utilization math. Only an emptyDir volume named cpu-request does not set CPU requests—the name is cosmetic and unrelated to resources.requests.cpu.
Exam caveat: set requests (and usually limits as appropriate for QoS) on the container resources block; HPA targets refer to those requests for resource metrics. Operational check: ensure the schedules API PodSpec has resources.requests.cpu, confirm metrics exist, and validate HPA calculates non-zero utilization before expecting scale actions.