Kubernetes Resource Calculator

Size a Kubernetes workload. Enter the per-pod CPU and memory requests and limits and the replica count, describe your node size and the overhead reserved for the system and kubelet, and the calculator returns the total reserved capacity, how many pods fit per node, and how many nodes the workload needs — flagging whether CPU or memory is the binding constraint. Runs entirely in your browser.

Node sizing uses requests, because the scheduler packs pods by requested resources, not limits. The reserved overhead approximates kube-reserved, system-reserved, and the eviction threshold — the slice of a node not available to your pods. Real allocatable capacity varies by provider; check kubectl describe node.

How to use the Kubernetes Resource Calculator

Enter the resource spec for a single pod — CPU in milli-cores (250 = 0.25 vCPU) and memory in mebibytes — for both requests and limits, then the number of replicas you run. Describe a node in your cluster by its vCPU and memory, and estimate the reserved overhead: the portion of each node consumed by the kubelet, the OS, and the eviction threshold, which is not available to your pods. Cloud nodes typically lose 10–25% this way.

The result shows the total CPU and memory your replicas request and the total they are allowed to use, how many of these pods fit on one node, and the number of nodes required. It also tells you whether CPU or memory is the limiting factor — the resource that fills up first as you add pods. If one is far tighter than the other, rebalancing the request ratio or choosing a differently-shaped node can pack more pods per node and cut your bill.

How Kubernetes packs pods onto nodes

When you create a pod, the Kubernetes scheduler must find a node with enough free capacity to hold it. Crucially, it decides using each container's requests, not its limits: a node can accept new pods as long as the sum of requested CPU and memory does not exceed what the node has allocatable. Limits matter at runtime — CPU is throttled and memory over-limit is OOM-killed — but they do not affect placement. That is why node sizing is a requests problem.

A node's allocatable capacity is always less than its raw size. The kubelet, container runtime, and operating system need CPU and memory of their own (system-reserved and kube-reserved), and a slice is held back as an eviction threshold so the node can react before it runs out of memory. On managed clusters this overhead commonly removes 10–25% of a node, and memory reservations grow with node size. The reserved-overhead field models this so the node count reflects real allocatable capacity, not the marketing spec.

The number of pods that fit per node is the smaller of two ratios: allocatable CPU divided by the CPU request, and allocatable memory divided by the memory request. Whichever runs out first is the binding constraint. A common waste pattern is requesting lots of memory but little CPU (or vice versa) on a balanced node, so half the node's other resource sits idle while pods can no longer be scheduled. Spotting the binding constraint tells you whether to adjust requests or pick a compute-optimised or memory-optimised node shape to improve density and reduce cost.

Common use cases

  • Cluster sizing. Estimate how many nodes a deployment of N replicas requires.
  • Right-sizing requests. See whether CPU or memory binds and rebalance to pack more pods per node.
  • Capacity planning. Project node count and cost before scaling a service up.
  • Node shape selection. Compare how a compute- vs memory-optimised node changes density.

Frequently asked questions

Why does node sizing use requests and not limits?
The scheduler places pods by requested resources — a node accepts pods until the sum of requests reaches its allocatable capacity. Limits only cap runtime usage (CPU throttling, memory OOM-kills) and do not reserve scheduling space. So the number of nodes you need is driven by total requests.

What is the reserved overhead?
It is the portion of a node not available to your pods: system-reserved (the OS), kube-reserved (the kubelet and runtime), and the eviction threshold. Managed Kubernetes typically reserves 10–25% of a node, with memory reservations rising on larger nodes. Check kubectl describe node to see exact allocatable values for your provider.

What does the binding constraint mean?
It is the resource — CPU or memory — that fills up first as you add pods to a node. If memory binds, you run out of schedulable memory while CPU sits idle, and vice versa. Identifying it tells you whether to adjust your request ratio or choose a differently-shaped node to improve packing.

What does 250m CPU mean?
CPU in Kubernetes is measured in milli-cores: 1000m equals one vCPU, so 250m is a quarter of a core. Memory uses binary units — Mi is mebibytes (1024 KiB) and Gi is gibibytes — which is why this tool takes memory in Mi.

Should requests and limits be equal?
Setting them equal places the pod in the Guaranteed QoS class, which gives the most predictable performance and the lowest eviction priority, but reserves the full amount even when idle. Lower requests with higher limits (Burstable) pack more densely but risk contention and eviction under pressure. The right balance depends on how spiky and how latency-sensitive the workload is.