Skip to content
Calcrivo

Node Capacity Calculator

Calculate how many pods and how much workload a Kubernetes node can host.

Inputs

cores

Total vCPU cores available on the node.

GiB

Total memory available on the node.

millicores

CPU request per pod.

MiB

Memory request per pod.

%

Percent of node capacity reserved for the kubelet, OS and system daemons.

Max Pods per Node

28pods

Binding Constraint

CPU

Max Pods (CPU-bound)

28pods

Max Pods (Memory-bound)

115pods

CPU Utilization at Max

97.2%

Memory Utilization at Max

24.3%

Step by step

  1. Allocatable CPU: node CPU × (1 − reserved%)

    8000m × (1 − 10/100)

    = 7200m

  2. Allocatable memory: node memory × (1 − reserved%)

    32768MiB × (1 − 10/100)

    = 29491MiB

  3. Max pods by CPU

    7200m ÷ 250m

    = 28

  4. Max pods by memory

    29491MiB ÷ 256MiB

    = 115

  5. Max pods (binding constraint)

    min(28, 115)

    = 28 pods (bound by CPU)

How it works

A node's pod capacity is bound by whichever resource — CPU or memory — runs out first, after subtracting the portion reserved for the kubelet, container runtime and OS. Formula: max_pods = min(allocatable_cpu / pod_cpu_request, allocatable_memory / pod_memory_request). Note that Kubernetes also enforces a hard cap (default 110 pods per node) independent of resource math, which this calculator does not include.

Formula

maxPods = min(floor(allocatableCPU / podCPU), floor(allocatableMemory / podMemory))

C_a
Allocatable CPU (node CPU × (1 - system reserved%))
C_p
Pod CPU request in millicores
M_a
Allocatable memory (node memory × (1 - system reserved%))
M_p
Pod memory request in MiB
P
Maximum pods per node

Frequently Asked Questions

Why is my actual max-pods lower than this calculation?

Kubernetes enforces a kubelet --max-pods setting (default 110) as a hard ceiling regardless of available resources, and some capacity may also be consumed by DaemonSets running on every node.

What's a typical system-reserved percentage?

Cloud providers commonly reserve 5-10% for small nodes and slightly more for the kubelet/OS on very large nodes; check your provider's specific allocatable formula (e.g. GKE, EKS use tiered reservations).

Should I size pods to fully saturate a node's CPU or memory equally?

Ideally your pod's CPU-to-memory request ratio matches the node's CPU-to-memory ratio, so neither resource is left stranded — otherwise you'll have unused capacity in whichever resource isn't the binding constraint.

Does this account for DaemonSet pods?

No — DaemonSet pods (e.g. log shippers, CNI agents) consume part of the allocatable capacity on every node and should be subtracted from allocatable CPU/memory before running this calculation for your application pods.

You might also need