Free Tool
Kubernetes Resource Request & Limit Calculator
Enter what a pod actually uses and get a starting-point set of resource requests and limits, in the shape you'd paste straight into a manifest. Everything runs in your browser — nothing is sent anywhere.
Observed usage per pod
Recommended manifest values
resources:
requests:
cpu: "220m"
memory: "296Mi"
limits:
cpu: "300m"
memory: "520Mi"- QoS class
- Burstable
- Requested / 3 replicas
- 660m · 888Mi
- Max burst / 3 replicas
- 900m · 1.52Gi
The recommended CPU limit is below your reported peak usage — the workload will be throttled during peaks. Consider the bursty profile or raise the limit.
These numbers are a reasoned starting point for a first rollout, not a substitute for observing real usage. CPU is compressible (a limit throttles, it doesn't kill), so its recommended headroom is smaller; memory is not (a limit that's too tight gets the container OOMKilled), so its headroom is larger. Re-check both against real metrics — ideally from the Vertical Pod Autoscaler in recommendation mode — after the workload has run for a week or two.
Why requests and limits differ
Kubernetes uses the CPU and memory request for scheduling — it's the reserved floor the scheduler guarantees your pod on some node. The limit is the ceiling: cross it on CPU and the kernel throttles you; cross it on memory and the kernel kills the container. That asymmetry is why memory limits need more headroom above observed peak usage than CPU limits do, and why a bursty or batch workload can often run with no CPU limit at all — let it use whatever spare capacity the node has, rather than throttling it back to a number picked in advance.
These numbers are a starting point for a first rollout. For the real tuning loop, run the Vertical Pod Autoscaler in recommendation mode against production traffic, and read up on what cgroup v2 limits actually constrain if a pod is being throttled or killed in ways that don't match what you set.