kubectl top shows a Deployment's Pods consistently using far less CPU and memory than their requests. What is the application-developer response to improve packing?
Select an answer to reveal the explanation.
Short Explanation
Requests are reserved seats—if nobody sits there, other apps can't use those seats. After kubectl top shows steady under-use, trim requests closer to real usage with a little peak cushion. That helps the scheduler pack the node more honestly.
Full Explanation
When kubectl top shows a Deployment's Pods consistently using far less CPU and memory than their requests, the application-developer response to improve packing is to lower the containers' resource requests toward observed usage while keeping enough headroom for peaks. Right-sizing frees allocatable capacity for other municipal workloads without immediately buying more nodes.
Deleting the Metrics Server so under-utilized Pods stop reporting and appear fully utilized fails observability and does not improve packing. Raising requests further so the scheduler spreads Pods onto more nodes by force worsens packing efficiency and wastes capacity. Converting every request into an equal limit and removing the Deployment's replicas field confuses QoS tuning with replica management and ignores the over-request problem.
Exam caveat: leave headroom for startup spikes and rare peaks; over-lowering causes CPU throttling or memory OOM under real load. Operational check: review kubectl top over a representative window, patch requests downward with deliberate headroom, roll out, and confirm denser packing without latency or error regressions. In CKAD scenarios involving q205, prefer verifying the live object with kubectl get and describe before changing cluster-wide settings.