Allocatable vs capacity
Capacity is the CPU and memory a node reports. Allocatable is what the scheduler can hand out to pods: capacity minus kube-reserved, system-reserved and, for memory, the eviction threshold.
Kubernetes defines those settings, and each provider picks the values, so the same node size leaves a different amount for pods on each one. This calculator applies the published formulas for GKE and AKS, and for EKS on Amazon Linux (AMI source), to the same node size. GKE has two rows because it changed its formula: node pools keep the one for the version they were created on.
Worked example: 4 vCPU, 16 GiB
At each provider's default max pods, the memory left for pods on this node size is:
- 11.9Gi on AKS with Azure CNI Overlay (250 max pods), where the reservation reaches its cap of 25% of the node.
- 13.3Gi on GKE node pools created on 1.36 or earlier (110 max pods), which reserve 2.7Gi.
- 13.8Gi on GKE node pools created on 1.37 or later (110 max pods), which reserve 2.2Gi.
- 15.03Gi on an EKS m5.xlarge (58 max pods), which reserves 993Mi.
That is a gap of 3.13Gi from the same inputs. CPU differs far less: 80m reserved on GKE and EKS and 140m on AKS, so 3.92 or 3.86 cores are left.
Max pods drives much of that gap. AKS with 110 max pods leaves 13.71Gi. Microsoft writes the per-pod figure in MB, and this page applies it as MiB, the unit kubelet reservations normally use. Read as MB, it would leave 13.81Gi. To turn these figures into pods per node, use the Kubernetes pod capacity calculator.
Pitfall: machine size is not capacity
A machine sold as 8 GB can report less. AWS gives 7,748 MiB as the capacity of an 8 GB instance and starts its allocatable formula from that. Enter the machine size and these results can run high, by 444 MiB in that example. For closer figures, enter Capacity from kubectl describe node.
The formulas also assume a standard Linux node. Windows nodes, shared-core machines, Ubuntu or image streaming on GKE, extra features on AKS, other node images and custom kubelet settings can reserve different amounts. When kubectl describe node disagrees with this page, trust kubectl: its Allocatable is the number the scheduler uses.
FAQ
What is the difference between capacity and allocatable in Kubernetes?
Capacity is the total CPU and memory a node has. Allocatable is what is left for pods after kube-reserved, system-reserved and the eviction threshold are subtracted. The scheduler places pods against allocatable, not capacity.
Which gives the most allocatable memory: GKE, EKS or AKS?
It depends on the node size and max pods, and each provider has its own default. At those defaults, a 4 vCPU, 16 GiB node leaves 15.03Gi on an EKS m5.xlarge (58 max pods), 13.8Gi on GKE node pools created on 1.37 or later and 13.3Gi on those created on 1.36 or earlier (110 max pods), and 11.9Gi on AKS with Azure CNI Overlay (250 max pods). AKS with 110 max pods leaves 13.71Gi. These figures start from the machine size, so real values can be lower.
How does max pods change allocatable memory?
On GKE node pools created on 1.37 or later and on AKS, part of the memory reservation is counted per max pod, 15 MiB and 20 MB, up to a cap. So raising max pods can lower what is left for pods, even with no extra pods running. EKS counts 11 MiB per pod, but it uses the max pods the instance type supports, so a maxPods value in the kubelet config does not change the reservation. GKE node pools created on 1.36 or earlier do not use max pods in the formula.
How do I see the real allocatable values of my node?
Run kubectl describe node with the node name and read the Capacity and Allocatable sections. The scheduler uses Allocatable. Trust that value if it differs from this calculator, for example after custom kubelet settings.
Does this apply to EKS Fargate or GKE Autopilot?
Not directly, because this calculator starts from a node size you choose. EKS Fargate runs one pod per node and sizes it from the pod's requests, and on GKE Autopilot Google manages the nodes and can adjust your requests.