← Back to Kubernetes Requests Rightsizer
Nodes are bought for what pods request, not for what they use. Requests are usually guessed once, copied between services and never revisited, so most clusters carry a lot of reserved-but-idle CPU and memory. Shrinking them is the cheapest cost cut in Kubernetes, and also the easiest to get wrong.
The scheduler packs pods onto nodes by their requests. A request above real usage is capacity you pay for and nothing else can use. A limit is a different thing: a container above its CPU limit is throttled, and above its memory limit it is OOMKilled. So lowering a request saves money, and lowering a memory limit below real peak usage breaks things.
kubectl top pod -A --containers kubectl get pods -A -o json
The first gives live CPU and memory per container; the second gives each container's requests and limits. kubectl top is one sample. A request has to cover your busiest hour of the busiest week, so a quiet-afternoon snapshot will under-state it. Take p95 (or p99 for critical services) over several days from your metrics system and feed that in as CSV.
A simple rule: request = p95 usage x (1 + headroom). About 20% headroom for CPU is common; memory needs more, about 25%, because exceeding it is a kill rather than a slowdown. The analyzer shows the result for every container with the headroom you choose, and the monthly difference at node prices you enter.
node cli.mjs analyze top.txt pods.json --patch
Apply the patch to the owning Deployment or StatefulSet in staging, watch restarts and throttling for a few days, then roll it out gradually. Vertical Pod Autoscaler in recommendation mode is a good cross-check on the same numbers.
A pasted snapshot is not your traffic. List prices ignore your discounts, node bin-packing and per-node overhead, so the dollar figure is an estimate of requested capacity, not a bill.
The scheduler places a pod using its requests and a node guarantees that much. A limit is a ceiling: crossing the CPU limit throttles the container, crossing the memory limit gets it OOMKilled. Requests decide what you pay for; limits decide what breaks.
A common starting point is observed p95 usage plus headroom, about 20% for CPU and 25% for memory, taken over a period that includes your busiest hour. Memory deserves more care than CPU because running out is a kill, not a slowdown.
No. It is a single moment. Use it to find the obvious outliers, then confirm with p95 usage from your metrics system over days before lowering anything.