Kubernetes Resource Calculator

Every container in Kubernetes can declare how much CPU and memory it needs and how much it may use. Those two numbers decide where pods are scheduled, which pods are evicted first under pressure and how many fit on a node, yet they are often copied from an example without much thought. This calculator adds them up for a whole pod, shows the QoS class Kubernetes will assign and estimates node capacity.

The units

CPU is measured in cores. 1 is one full core or vCPU, and 250m is 250 millicores, a quarter of a core; 0.5 and 500m mean the same thing. Memory is measured in bytes with suffixes, and the suffixes come in two families: Mi and Gi are powers of 1024, while M and G are powers of 1000. 512Mi is 536,870,912 bytes and 512M is 512,000,000, about 5% less, so mixing them up quietly changes your limits.

Requests and limits

A request is a reservation: the scheduler only places a pod on a node that has that much unreserved capacity, and the container is guaranteed at least that share. A limit is a ceiling. A container that tries to use more CPU than its limit is throttled, which slows it down; one that uses more memory than its limit is killed and restarted. If a container sets a limit without a request, Kubernetes copies the limit into the request, and the calculator does the same.

QoS classes

Kubernetes sorts pods into three quality-of-service classes from their containers’ settings. A pod with no requests or limits at all is BestEffort and is evicted first when a node runs short. A pod where every container has CPU and memory limits equal to its requests is Guaranteed and is evicted last. Everything in between is Burstable. The class appears in kubectl describe pod and matters most on busy nodes.

Node fit

Enter the node’s vCPUs and memory, and a percentage reserved for the operating system and the kubelet. The calculator divides the remaining CPU and memory by the pod’s requests and takes the smaller result as the number of pods per node, then works out how many nodes the chosen replica count needs. It also shows how much the replicas could use in total if every container went up to its limits.

A worked example

The Sample pod has an app container requesting 250m CPU and 256Mi memory with limits of 1 core and 512Mi, plus a log-shipper sidecar requesting 50m and 64Mi with limits of 200m and 128Mi. The pod requests 300m (0.3 cores) and 320Mi in total, and its QoS class is Burstable because requests and limits differ. On a 4-vCPU, 16 GiB node with 10% reserved, CPU is the tighter resource: 12 pods fit, so three replicas need one node.

Warnings

The calculator warns about containers without a memory limit, since one leak can starve the whole node; containers without any CPU request, which the scheduler treats as needing nothing; requests larger than limits, which the API server rejects; and quantities it cannot parse.

What the estimate leaves out

Real nodes also run DaemonSets such as log collectors and network agents, and the kubelet keeps eviction thresholds free, so actual capacity is lower than the estimate. Compare with the Allocatable section of kubectl describe node for exact numbers.

Related tools

• Kubernetes YAML Generator writes the Deployment these values go into.
• Connection Pool Calculator sizes the database side of the same app.
• docker run to Compose sets similar limits for Compose.
• Unit Converter converts between other units of data size.