Kubernetes requests and limits calculator

What this calculates

Kubernetes schedules pods using their requests, not their limits. A request is what the scheduler reserves on a node. A limit is the most a container may use before it is throttled (CPU) or killed (memory). Getting the totals right tells you whether a Deployment fits on the nodes you have, how much capacity a namespace really uses, and which QoS class the pod will get when the node is under pressure.

This calculator reads the containers in a manifest, normalises every quantity to millicores or bytes, and works out the per-pod and per-replica numbers using the same rules as the Kubernetes scheduler.

Reading the units

CPU is measured in cores. 1 is one core and 250m is 250 millicores, a quarter of a core. Memory uses bytes with a suffix. The binary suffixes Ki, Mi and Gi are powers of 1024. The decimal suffixes k, M and G are powers of 1000. The calculator accepts all of them, plus the exponent form such as 129e6, and reports the result in millicores and Mi or Gi.

The pod request formula

App containers run at the same time, so their requests add up. Init containers run one at a time before the app starts, so only the largest one counts. The pod-level request for each resource is:

pod request = max( sum(app containers), max(init containers) )

Sidecars are the exception. They are init containers with restartPolicy: Always, so they keep running alongside the app. Their requests add to the app sum. A regular init container that starts after a sidecar runs next to it, so it counts as its own request plus the sidecars started before it. Pod overhead is not included.

Worked example

The sample in the calculator is a Deployment with three replicas. It has one init container that requests 50m, an app container that requests 250m, and a metrics container that requests 50m. The app has a memory limit but no CPU limit.

CPU request per pod  = max(250m + 50m, 50m) = 300m
CPU request total    = 300m × 3 = 900m
Memory request/pod   = 256Mi + 64Mi = 320Mi (init 32Mi is smaller)
Memory request total = 320Mi × 3 = 960Mi
CPU limit            = not set on the app, so unbounded
QoS                  = Burstable (some requests, not all equal to limits)

The init container does not add to the 300m, and the missing CPU limit is why the calculator reports "no limit" rather than a number. Only with a limit on every container, and requests equal to those limits, does the pod become Guaranteed.

QoS classes in plain terms

• Guaranteed: every container, init containers included, sets CPU and memory limits, and each request equals its limit. These pods are the last to be evicted under node pressure.
• BestEffort: no container sets any request or limit. These pods are evicted first.
• Burstable: everything in between. A limit without a request is treated as a request equal to the limit, so a limits-only container can still be Guaranteed.

Fit against a node

The node fit divides the node's allocatable CPU and memory by the per-pod request and takes the scarcer result. It is a lower bound on nodes because it ignores how the scheduler packs unequal pods and any DaemonSets. Allocatable is smaller than the instance size because the kubelet and the operating system reserve some of it. Read the real value with kubectl describe node and look at the Allocatable section.

Common mistakes

• Summing init containers. They run in sequence, so adding them over-reserves capacity.
• Confusing G with Gi. 1Gi is about 7 percent more than 1G. Keep one unit in the manifest.
• Forgetting replicas. A per-pod request of 250m is 750m for three replicas, and the namespace quota counts the total.
• Setting a limit and expecting it to be the request. If you set only a limit, the request becomes that limit, which can make a pod much larger for the scheduler than you intended.
• Leaving out limits and wondering why QoS is Burstable. Guaranteed needs both CPU and memory limits on every container.