Kubernetes Resource Calculator
Cluster node count from pod resource requests. Nodes are sized on whichever of CPU and memory runs out first, so a workload with a request ratio that does not match the instance type wastes the other resource entirely.
Also called: k8s node sizing, cluster capacity calculator.
2 nodes for 40 pods, costing $46,720.00 a month. CPU needs 2 nodes and memory needs 1, so CPU is the binding constraint. Utilisation is 88.24% CPU and 44.12% memory. The two requirements differ, so the slack on the non-binding resource is paid for and unused. A different instance ratio would cost less.
How this is calculated
Total requests divided by allocatable capacity per node, taking the larger of the CPU and memory requirements. The gap between the two is pure waste: if memory needs six nodes and CPU needs three, you pay for six nodes worth of CPU and use half. Matching the instance type's CPU to memory ratio to the workload's is the single most effective cluster cost reduction, and it is usually easier than tuning the requests themselves. Allocatable capacity is below nameplate because the kubelet and system daemons reserve a share.
the cluster is sized on whichever resource runs out first, and the other is wasted- c
- CPU request
- m
- Memory request
Method and limits
What it assumes
- Requests rather than limits drive scheduling, which is how Kubernetes works.
What it deliberately does not model
- DaemonSets consume capacity on every node and are not counted here.
- Pod affinity, taints and topology constraints can force more nodes than resources require.
- Vertical and horizontal autoscaling change the steady-state count.
Formula version 1.0.0 · definition 1.0.0 · United States · Report a problem with this calculator
Frequently asked questions
- Why is my cluster half empty?
- Usually a mismatch between the workload CPU to memory ratio and the instance type. The cluster sizes on whichever runs out first and the other sits idle.
- Do limits or requests decide node count?
- Requests. The scheduler places pods on requests, so a pod with a small request and a large limit can be scheduled onto a node that cannot actually satisfy it under load.