TL;DR: The gap between requested and used resources can reveal reclaimable capacity, and closing it is a measurement and defaults problem before it is an autoscaler problem. Cut toward p95 usage in staged steps, watch throttle and OOM signals, and accept that some headroom is insurance teams bought on purpose.
How to approach it
Separate requests from limits. Requests influence scheduling and contention behavior. CPU limits impose quota throttling; memory limits can trigger a cgroup OOM kill. Reducing a request alone does not lower those limits. Measure the bottleneck before changing either.
Measure each resource separately and test changes against throughput, latency, contention and recovery requirements. Keep explicit limits visible in the review so a request change cannot silently change a different control.
A strong answer
Measure requested, used and allocatable resources in this cluster. A requested-to-used ratio is a screening signal, not a savings estimate. Node deletion depends on placement constraints and resilience headroom, while billing savings also depend on commitments. Kubernetes resource management.
The gap forms for boring reasons. Engineers size once, usually right after an incident, then never revisit. Requests get copied between services, wrapped in stacked safety factors, and set equal to limits because that is the template everyone inherited. Nobody who picked the number ever sees its cost, so nothing pushes back.
Run it as a loop, not a cleanup:
| Signal | Example review trigger | What it hides |
|---|---|---|
| Requested to p95-used ratio | Investigate sustained large gaps | Punishes teams holding deliberate headroom |
| Node fill rate | Compare with tested failover capacity | A high average can conceal placement fragmentation |
| Throttle and OOM kill rate | Flat through every cut | Trails the cut by days |
Cut toward p95 plus modest headroom, never the mean, since means hide spikes and deploy surges. Stage cuts 20 to 30 percent at a time as automated pull requests generated from real recommendations; VPA in recommendation mode feeding chart-default bumps is the boring, effective version. Remember that a rollout briefly schedules old and new replicas together, and that this is the constraint that turns a successful right-sizing into a stuck deploy. A service of 100 pods right-sized to 600m requests 60 cores in steady state. A rolling update with a 25 percent surge puts 125 pods on the cluster at peak, 125 × 0.6 = 75 cores, so a cluster trimmed to exactly 60 has nowhere to place the extra 25 and the rollout stalls with pods Pending.
The headroom you keep therefore has to cover the largest surge you actually run, not the steady state the recommendation was computed from: 75 − 60 = 15 cores, 25 percent, reserved for a condition that exists for a few minutes per deploy. Per-pod requests do not include the other replica's allocation, which is why the arithmetic has to be done at the cluster level and why the first sign of over-trimming is usually a deploy that will not finish rather than a workload that is slow. Per-pod requests do not include the other replica's allocation. Consolidation then compounds the win: deliberate topology spread settings, descheduling, and node-level bin-packing turn per-pod savings into deleted nodes, and deleted nodes are the only saving finance can actually see.
Hold a defensible position on exceptions. A payments path carrying 40 percent memory headroom after an OOM incident made a correct purchase; a batch job idling at 1.2x is leaving money on the table. Publish the ratio per team, judge the exceptions openly, and resist any policy that forces one number on every namespace.
What interviewers probe next
"Half your cuts triggered throttling alerts. Diagnose." Check whether CPU limits changed with requests, including a chart that ties them together. Quota throttling follows the CPU limit. Lower requests can instead increase contention after consolidation; compare CPU pressure, latency and placement. Revert unsafe changes and test the cause.
"Why not run VPA in automatic mode everywhere?" Check the installed VPA version and update policy, including whether in-place resizing is supported for these workloads or replacement is required. Coordinate VPA and HPA signals to avoid conflicting control loops. Recommendation-only mode is a conservative starting policy, not the only valid mode.
"Waste crept back within two quarters. Fix that." A CI check flagging requests drifting past a threshold from trailing p95, with the ratio on the team dashboard beside latency, converts a project into a habit.
Common mistakes
Quoting fleet-average utilization as the savings figure; averages hide the peaks you must still provision for, and finance discovers the shortfall when the bill barely moves.
One blanket ratio policy for all namespaces, which breaks latency-critical services that bought headroom knowingly.
Chasing node fill above 90 percent, then discovering during the next zone failure that there was nowhere to reschedule.
Running it as a one-off sprint; without changed defaults and visible ratios, requests inflate straight back.