$ k8s-calc
requests and limits from actual usage. Get the numbers from kubectl top, Prometheus or Lens.
input
resources: # result appears here
How the numbers are derived
CPU requests — average usage plus headroom. Requests drive scheduling and the guaranteed CPU share under contention, so they are based on the average, not the peak — otherwise the cluster idles on reservations.
CPU limits — for latency-sensitive services the calculator suggests no limit at all: CPU throttling hurts tail latency, and unlike memory, excess CPU can be reclaimed without killing the process. For batch workloads the limit is set from the peak so a background job doesn't starve the node.
Memory requests and limits — from the peak with headroom, set equal to each other. Memory is incompressible: exceeding the limit means an OOMKill, so skimping on headroom here is riskier than on CPU.
Where to get the input numbers
Quick way: kubectl top pod <pod> at different times of day. Proper way: Prometheus — container_cpu_usage_seconds_total (5m rate, weekly quantiles) and container_memory_working_set_bytes (weekly max). Pick a window that includes peak load.
Common mistakes
Eyeballed requests at 10× actual usage — the pod reserves node capacity, the autoscaler inflates the cluster, the bill grows. Memory limit right at the peak — any spike and the pod lands in CrashLoopBackOff via OOMKilled.