Kubernetes Resource Calculator
Calculate CPU and memory requests and limits, total cluster footprint across replicas, and the resulting Pod QoS class — right-size pods and avoid OOMKills.
CPU units (millicores) and memory units explained
Kubernetes expresses CPU in millicores: 1000m equals one vCPU, so 250m is a quarter of a core. Memory is expressed in bytes, usually with binary suffixes such as Mi (mebibyte, 1024² bytes) and Gi (gibibyte). This calculator accepts both the millicore form (500m) and the whole-core form (0.5), and both binary (Mi/Gi) and decimal (M/G) memory suffixes.
Requests vs limits
A request is what the scheduler reserves for a container and uses to decide which node the pod fits on. A limit is the hard ceiling: exceed the CPU limit and the container is throttled; exceed the memory limit and it is OOMKilled. Multiply per-pod values by replica count and you get the real footprint the calculator shows above, which is what you must fit inside your node pool.
Right-sizing pods to avoid OOMKills and throttling
Set memory requests close to steady-state usage and give limits enough headroom for spikes, or the kubelet will kill the container the moment it crosses the line. For CPU, remember that limits cause throttling rather than eviction, so many teams set a CPU request but leave the limit generous. For a deeper treatment of scaling replicas dynamically, see our guide on Kubernetes pod autoscaling with HPA, VPA and KEDA.
QoS classes
The QoS class shown above is derived exactly as Kubernetes does it: Guaranteed when requests equal limits for both CPU and memory, BestEffort when nothing is set, and Burstable otherwise. Guaranteed pods are the last to be evicted under node pressure, which matters for right-sizing cost vs reliability. For the cost side of that trade-off, see our Kubernetes cost optimization guide.
FAQ
What is a millicore (m) in Kubernetes?
A millicore is 1/1000th of a CPU core. 1000m equals one full vCPU. Kubernetes schedules CPU in millicores, so 250m means a quarter of a core.
What is the difference between requests and limits?
A request is the amount of CPU/memory reserved for the pod and used by the scheduler to place it. A limit is the hard ceiling the container may use before being throttled (CPU) or OOMKilled (memory).
How do I avoid OOMKilled pods?
Set a memory request close to real usage and a limit with headroom for spikes. If a container exceeds its memory limit it is OOMKilled, so measure actual usage and avoid limits that are too tight.
What QoS class should I aim for?
Guaranteed (requests equal limits for both CPU and memory) gives the strongest eviction protection. Burstable is the common default. BestEffort pods are evicted first under node pressure.