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 amount depends on the platform: pick yours under Reserved resources, or enter the numbers yourself. 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.
To compare what GKE, AKS and EKS leave on the same node size, use the Kubernetes allocatable calculator. Not sure what a value such as 250m or 1Gi comes to? The Kubernetes CPU units converter turns it into cores, and the Kubernetes memory units converter into exact bytes.
Worked example
The default inputs describe a 4 vCPU, 16 GiB node running pods that request 500m CPU and 1Gi memory. GKE's formula for node pools created on 1.36 or earlier 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.
The platform changes the memory side. With EKS and a max pods value of 58, the same node reserves 993Mi instead of about 2.7Gi, so memory alone would allow 14 pods. CPU still limits it to 7, which is why the platform matters most for memory-heavy pods.
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 much do GKE, AKS and EKS reserve on each node?
Each platform uses its own formula, and the calculator offers all of them. GKE node pools created on 1.36 or earlier reserve 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. GKE node pools created on 1.37 or later reserve the lower of that memory figure and 15 MiB per max pod plus a 500 MiB base on Container-Optimized OS, and at most 1 CPU core. AKS 1.29 and later reserves about 20 MB per max pod plus 50 MB of memory, capped at 25% of the node, and 60m to 740m of CPU on 1 to 64 cores. EKS Amazon Linux AMIs reserve 11 MiB per pod the instance type supports, plus 255 MiB of memory, and use the same CPU tiers as GKE. Every platform adds a 100 MiB eviction threshold. These formulas cover Linux nodes only. For Windows nodes, or to match a node exactly, choose Enter manually and use Capacity minus Allocatable from kubectl describe node.
Why is there a max pods per node limit?
Every node runs a limited number of pods, and each platform sets its own default. GKE Standard defaults to 110 and allows up to 512, set per node pool. AKS defaults to 250 with Azure CNI Overlay and allows at most 250, also set per node pool. On EKS with the VPC CNI the limit depends on how many IP addresses the instance type can attach, for example 29 on an m5.large without prefix delegation, and managed node groups cap it at 110 below 30 vCPUs and 250 above. On GKE 1.37 or later and on AKS, max pods also sets how much memory is reserved, so enter the real value. EKS reserves memory from the max pods the instance type supports, even when a managed node group or the kubelet config sets a different limit, so the calculator has a separate field for it.
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.