How pod capacity is calculated
The scheduler fits pods into each node's allocatable resources, using their requests. The calculator follows the same steps:
- Start from the node's CPU and memory.
- Subtract what the kubelet reserves for the OS, the container runtime and itself (kube-reserved, system-reserved and the eviction threshold). The result is allocatable.
- Subtract the requests of DaemonSet pods, which run on every node.
- Divide what is left by the pod's CPU request and by its memory request. The smaller number, capped by max pods per node, is how many pods fit.
Whichever resource runs out first is the limiting factor. If CPU limits you while half the memory sits idle, a node type with a different CPU-to-memory ratio will usually cost less for the same workload.
Worked example
The default inputs describe a 4 vCPU, 16 GiB node running pods that request 500m CPU and 1Gi memory. The GKE formula reserves 80m CPU and about 2.7Gi memory, leaving 3.92 cores and 13.3Gi allocatable. DaemonSets take another 200m and 400Mi, so 3.72 cores and about 12.9Gi remain for the workload.
By CPU, 3.72 / 0.5 = 7.44, so 7 pods fit. By memory, 12.9Gi / 1Gi allows 12. CPU runs out first, so each node holds 7 pods, 20 replicas need 3 nodes, and about 44% of each node's allocatable memory goes unused.
Pitfall: limits without requests
If a container sets a limit but no request, Kubernetes copies the limit and uses it as the request, unless a LimitRange in the namespace applies a default first. A pod with a 4Gi memory limit and no request is scheduled as if it needs 4Gi, and far fewer pods fit than you expect. The opposite case hurts too: a pod with no requests and no limits counts as requesting nothing, so it can land on a node that is already full. Set requests explicitly, close to what the container really uses, and enter those numbers here.
Leave headroom
Packing nodes to 100% leaves no space for rolling updates, which briefly run extra pods, or for a node failing and its pods moving elsewhere. Plan for one more node than the minimum, or use a PodDisruptionBudget and the cluster autoscaler to absorb the spikes.
FAQ
Does Kubernetes schedule pods based on requests or limits?
Requests. The scheduler only places a pod on a node if the sum of CPU and memory requests of all pods on that node, plus the new one, fits within the node's allocatable resources. Limits are enforced at runtime but play no role in scheduling, which is why this calculator only asks for requests.
What is allocatable versus capacity?
Capacity is the raw CPU and memory of the machine. Allocatable is what is left for pods after the kubelet subtracts kube-reserved, system-reserved and the eviction threshold. Run kubectl describe node and look for the Capacity and Allocatable sections to see the real numbers on your cluster.
How accurate is the automatic reserved estimate?
It uses the tiered formula GKE publishes: 6% of the first CPU core down to 0.25% above four cores, and 25% of the first 4 GiB of memory down to 2% above 128 GiB, plus a 100 MiB eviction threshold. AKS and EKS use similar formulas, so the estimate is usually within a few percent. Switch to manual and enter the values from kubectl describe node for exact results.
Why is there a max pods per node limit?
The kubelet caps pods per node, 110 by default. On EKS with the VPC CNI the limit depends on how many IP addresses the instance type can attach, which can be much lower on small instances (for example 29 on an m5.large without prefix delegation). On GKE and AKS it is configurable per node pool.
Why do my DaemonSets matter?
DaemonSets such as log shippers, monitoring agents, CNI and CSI drivers run one pod on every node, and their requests come out of the same allocatable pool. Three agents at 100m CPU and 200Mi each take 300m CPU and 600Mi from every node before your workload gets anything.
What do the CPU and memory units mean?
CPU is measured in cores, and 1000m (millicores) equals one core, so 250m is a quarter of a core. Memory uses bytes with binary suffixes (Ki, Mi, Gi = powers of 1024) or decimal ones (k, M, G = powers of 1000). 1Gi is about 7% larger than 1G.