How the suggestion is calculated
CPU request is p95 CPU usage plus your headroom, rounded up to the next 10 millicores. CPU is compressible, so a pod that goes over its request competes for spare capacity and slows down, and it isn't killed. That's why p95 is a reasonable base.
Memory request and limit are the peak working set plus your headroom, rounded up to the next 16 MiB. Memory is not compressible: a container over its limit is killed. That's why the calculator uses the peak and not a percentile. Setting the limit equal to the request means the pod's memory behaviour on a busy node is easier to predict.
No CPU limit appears in the block on purpose. CPU limits can throttle latency-sensitive services even when the node has idle capacity. This is debated, and some multi-tenant clusters need CPU limits for fairness or by policy. If yours does, add one and watch throttling metrics after the change.
Capacity change is the difference between the new and current requests, multiplied by replicas. It describes capacity the scheduler reserves, and it only becomes real savings if the cluster can then run fewer nodes.
A worked example
Here is an example using the default values: 6 replicas, each requesting 1,000 millicores and 2,048 MiB. Over a representative period, p95 CPU is 180 millicores and the peak working set is 700 MiB.
- CPU: 180 × 1.30 = 234, rounded up to 240m
- Memory: 700 × 1.20 = 840, rounded up to 848 MiB
- CPU reservation: (1,000 − 240) × 6 = 4,560 millicores, or 4.56 cores less
- Memory reservation: (2,048 − 848) × 6 = 7,200 MiB, or about 7.03 GiB less
Check these before applying the numbers
Measure over a full cycle. Include your busiest day, month-end jobs and deployments. A week of quiet traffic will give you numbers that fail on the first busy Monday.
Check the HPA first. A HorizontalPodAutoscaler that targets CPU utilisation calculates it as a percentage of the request. If you cut the request from 1,000m to 240m and keep a 70% target, the same load now looks four times busier, so the HPA will add replicas. Adjust the target, or your change could increase total usage.
Look at startup. Some Java and .NET services use far more CPU while starting than while serving traffic. A very low CPU request can slow startup enough to fail readiness probes. Include startup in your review, or add headroom for it.
Watch runtimes that size themselves from limits. The JVM and .NET both read container limits when choosing heap sizes and thread settings. Changing the memory limit may change the runtime's own behaviour, so the working set you measured might not stay the same.
Roll out gradually. Change one workload, or one canary, and watch restarts, OOM kills, CPU throttling and latency for at least a full business cycle before moving on. The right-sizing guide covers the whole process step by step.
Which headroom should I use?
There is no universal value. The defaults of 30% for CPU and 20% for memory are only starting points. Use more for services with sudden traffic changes, recent memory growth or a slow autoscaler, and less for stable batch workloads with well-known behaviour. If you run replicas across zones, also consider what remaining pods have to absorb when one zone fails.
Where to get the inputs
CPU p95 and peak working set should come from at least a week of per-pod history. The
container_memory_working_set_bytes metric is the one the kubelet uses for
eviction decisions, which makes it a better input than total memory usage including page
cache.
Wrentrix shows min, average, p95 and peak resource usage per workload with right-sizing hints, and lines up changes against latency and errors. It runs inside your own network, and you can explore the screens in the live demo.
Frequently asked questions
How do I calculate Kubernetes CPU and memory requests?
Measure real usage over a representative period. A common starting point is the CPU request at p95 usage plus some headroom, and the memory request at peak working set plus some headroom. Then roll out gradually and watch for throttling, OOM kills and latency changes.
Should requests equal limits in Kubernetes?
For memory, many teams set them equal, because it makes the pod's behaviour under node pressure easier to predict. For CPU, many teams set a request and no limit on latency-sensitive services to avoid throttling. If requests equal limits for both resources in all containers, the pod gets the Guaranteed QoS class.
What happens if a pod goes over its limits?
Going over the CPU limit causes throttling, so the container runs more slowly. Going over the memory limit gets the container killed with an OOM error and restarted according to its restart policy.
Will lowering requests save money?
Only if it allows you to run fewer or smaller nodes. Lower requests free up schedulable capacity, but node costs stay the same until the cluster actually shrinks, for example through an autoscaler or a capacity change.
Is my data sent anywhere?
No. The calculation runs in your browser with JavaScript, and the page does not send what you enter to any server.