Kubernetes node sizing: why 16 vCPU needs more than 4 nodes

Por Rohit Athaide · Publicado em 5 de nov. de 2026

Short answer: the number of nodes comes from the CPU and memory your pods request, after each node sets aside part of itself for the system. Take the larger of the CPU-based count and the memory-based count, then apply your minimum for resilience. Small nodes lose a larger share to overhead, so the same pods can need more total capacity on small nodes.

Key points

• Nodes are filled by pod requests, not actual use.
• Each node keeps part of its CPU and memory for the system (allocatable is what is left).
• Node count is the larger of the CPU count and the memory count, never below your minimum.
• Overhead is a larger share of small nodes.
• Spare space on a node is paid for.

How do I work out the node count?

1. Add up the CPU requests and memory requests of every pod.
2. Find the allocatable CPU and memory of one node.
3. CPU nodes = pod CPU / allocatable CPU, rounded up.
4. Memory nodes = pod memory / allocatable memory, rounded up.
5. Nodes = the larger of the two, but not fewer than your minimum.

How much of a node is usable?

Clouds publish their own reservation rules and they are similar. Google’s published GKE formula reserves 6 percent of the first core, 1 percent of the second, 0.5 percent of the next two and 0.25 percent above four. For memory it reserves 25 percent of the first 4 GB, 20 percent of the next 4 GB, 10 percent of the next 8 GB, 6 percent of the next 112 GB and 2 percent above that. Our estimator applies that one formula to every cloud so the comparison stays fair, and says so in its assumptions.

What does a worked example look like?

The usable amounts come from the formula above. The prices are made-up round numbers to show the method, not real prices. Pods request 16 vCPU and 64 GB.

The pods are the same, and the small nodes cost more because overhead takes a bigger share and the memory need rounds up to 11 nodes. Note that 16 vCPU does not fit in 4 nodes of 4 vCPU: the system keeps part of each node, so you need 5. The right size is the one that fits your pods with the least waste, and that depends on your biggest pods too, since a pod must fit on one node.

What wastes node capacity?

• Requests set too high. Capacity is reserved and idle.
• Pods that don’t pack. A 3-vCPU pod on a 4-vCPU node leaves 0.9 vCPU unusable.
• Memory-heavy pods on CPU-heavy nodes. Memory runs out first and the CPU idles.
• Too many tiny nodes. Overhead repeats on each.
• Minimum node floors. Three nodes serve a workload that needs one.

Ways to spend less

1. Right-size requests using real usage. See cloud cost optimization checklist.
2. Pick a node size where your largest pod fits comfortably.
3. Use autoscaling with a sensible minimum and maximum.
4. Use spot nodes for interruptible work.
5. Consider pod-billed mode for uneven loads.

Decision checklist

• Are requests based on measured use?
• Does the largest pod fit on one node with room to spare?
• Is the node count driven by CPU or by memory?
• Is the minimum set by resilience and not habit?

Next steps

Try your numbers in the Kubernetes estimator; it shows the CPU count, the memory count and the minimum behind the node total. Read what is a vCPU for why vCPU counts differ between clouds, and choosing a VM size for the machine itself.