Skip to content
ENExplore Calculators

OpenShift Node Capacity Calculator

Turn raw node CPU and memory into allocatable capacity after system-reserved, kube-reserved and the eviction threshold.

About OpenShift Node Capacity Calculator

Capacity is what the hardware has; allocatable is what the scheduler may hand out. OpenShift subtracts system-reserved, kube-reserved and the hard eviction threshold in that order, and the scheduler then packs pods against their resource requests — not their limits or their actual usage. The 250-pod per-node ceiling applies on top of the arithmetic. Reservations typically remove 8-12% of a node before a single pod schedules, so sizing a cluster from raw vCPU and RAM totals overstates real capacity and produces a cluster that cannot schedule the last deployment.

Formula

OpenShift Node Capacity

allocatable CPU = node vCPU × 1000 − system-reserved − kube-reserved; allocatable memory = node RAM − system-reserved − kube-reserved − eviction threshold; pods per node = min(allocatable ÷ request, 250).

system-reserved
Resources fenced off for OS daemons outside Kubernetes
kube-reserved
Resources fenced off for kubelet and the container runtime
eviction threshold
Buffer the kubelet keeps free before it starts evicting pods

Worked example

With the default values below, OpenShift Node Capacity Calculator returns Pods per Node of 58. Change any input above and every figure here is recalculated in your browser.

Inputs used

Worker nodesaccepts 1–2,000 nodes
6 nodes
vCPUs per nodeaccepts 1–512 vCPU
16 vCPU
Memory per nodeaccepts 2–24,576 GiB
64 GiB
system-reserved CPUaccepts 0–16,000 millicores
500 millicores
kube-reserved CPUaccepts 0–16,000 millicores
1,000 millicores
system-reserved memoryaccepts 0–256 GiB
3 GiB
kube-reserved memoryaccepts 0–256 GiB
1 GiB
Hard eviction thresholdaccepts 0–8,192 MiB
100 MiB
CPU request per podaccepts 1–64,000 millicores
250 millicores
Memory request per podaccepts 1–262,144 MiB
512 MiB

Results

Pods per Node
58 pods
Allocatable CPU
14,500 millicores
Allocatable Memory
59.90 GiB
Pods across the Cluster
348 pods
Capacity Lost to Reservations
7.0%
Limiting Resource
CPU requests are the limit — lower requests or add cores

Step by step

  1. 1Values used
  2. 2OpenShift Node Capacity
  3. 3Pods per Node= 58 pods
  4. 4Allocatable CPU= 14,500 millicores
  5. 5Allocatable Memory= 59.90 GiB
  6. 6Pods across the Cluster= 348 pods
  7. 7Capacity Lost to Reservations= 7.0
  8. 8Limiting Resource= CPU requests are the limit — lower requests or add cores

Assumptions and limits

  • The result is derived only from the 10 inputs listed above. Anything not among them is not part of the calculation.
  • In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
  • Figures are rounded for display to 2 decimal places, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.

How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.

Frequently Asked Questions

How is OpenShift Node Capacity calculated?

allocatable CPU = node vCPU × 1000 − system-reserved − kube-reserved; allocatable memory = node RAM − system-reserved − kube-reserved − eviction threshold; pods per node = min(allocatable ÷ request, 250). Capacity is what the hardware has; allocatable is what the scheduler may hand out. OpenShift subtracts system-reserved, kube-reserved and the hard eviction threshold in that order, and the scheduler then packs pods against their resource requests — not their limits or their actual usage. The 250-pod per-node ceiling applies on top of the arithmetic.

Why does OpenShift Node Capacity matter?

Reservations typically remove 8-12% of a node before a single pod schedules, so sizing a cluster from raw vCPU and RAM totals overstates real capacity and produces a cluster that cannot schedule the last deployment.

What values do I need to enter?

This calculator takes 10 inputs: Worker nodes, vCPUs per node, Memory per node, system-reserved CPU, kube-reserved CPU, system-reserved memory, kube-reserved memory, Hard eviction threshold, CPU request per pod, Memory request per pod. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.

Why does the scheduler use requests rather than limits?

Requests are a guaranteed reservation and are what the scheduler subtracts from allocatable; limits are only enforced at runtime by the cgroup. A pod with a 250m request and a 2-core limit occupies 250m of scheduling capacity, which is exactly how a node ends up oversubscribed at runtime while appearing to have room.

Related Calculators

OpenShift Node Capacity Calculator | Calcrivo