HPA raised court-docket replicas, but new Pods stay Pending because managed-node CPU is saturated. What capacity action addresses the shortage?
Select an answer to reveal the explanation.
Short Explanation
HPA is demand ("need more Pods"); node-pool size is supply ("need more workers"). When managed-node CPU is full, extra replicas pend until you add capacity. Virtual-node pools skip that worker lever—Pods scale with HPA on the serverless data plane.
Full Explanation
When HPA has already raised court-docket replicas but new Pods stay Pending because managed-node CPU is saturated, the shortage is worker supply, not replica desire. Increasing managed node-pool size—or enabling cluster autoscaler on managed nodes—adds Compute capacity so the scheduler can place the extra Pods HPA requested. Demand (HPA) and supply (node pool) must both be addressed. Lowering the HPA minimum replicas may reduce how many Pods are desired, but it does not add workers and can under-serve the docket workload. Pending Pods 'disappear' only because you stopped asking for capacity—not because the saturation problem was solved. Deleting the Service removes traffic routing; it does not free node CPU in a useful way or create scheduling room for Pending Pods. Callers lose access while capacity remains exhausted. Switching only the image tag does not free saturated CPU. Retagging may roll Pods but the same requests still need the same scarce node resources unless the new image dramatically lowers usage—which the stem does not claim. Exam caveat: virtual-node pools do not use the same managed worker-pool lever—Pending causes differ there—but this stem specifies managed-node CPU saturation, so node-pool scale or cluster autoscaler is the matching fix. Operational check: inspect Pending events for insufficient CPU, scale the managed node pool (or confirm cluster autoscaler adds nodes), and verify formerly Pending docket Pods schedule and pass readiness.