Skip to content
Calcrivo

OpenShift Node Capacity Calculator

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

Inputs

nodes
vCPU
GiB
millicores

Held back for sshd, the container runtime and the kernel.

millicores

Held back for kubelet, CRI-O and the node agents.

GiB
GiB
MiB

OpenShift defaults to memory.available under 100 MiB.

millicores
MiB

Pods per Node

58pods

Allocatable CPU

14,500millicores

Allocatable Memory

59.90GiB

Pods across the Cluster

348pods

Capacity Lost to Reservations

7.0%

Limiting Resource

CPU requests are the limit — lower requests or add cores

Step by step

  1. Values used

    Worker nodes = 6 nodes; vCPUs per node = 16 vCPU; Memory per node = 64 GiB; system-reserved CPU = 500 millicores; kube-reserved CPU = 1,000 millicores; system-reserved memory = 3 GiB; kube-reserved memory = 1 GiB; Hard eviction threshold = 100 MiB; CPU request per pod = 250 millicores; Memory request per pod = 512 MiB

  2. 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).

  3. Pods per Node

    = 58 pods

  4. Allocatable CPU

    = 14,500 millicores

  5. Allocatable Memory

    = 59.90 GiB

  6. Pods across the Cluster

    = 348 pods

  7. Capacity Lost to Reservations

    = 7.0

  8. Limiting Resource

    = CPU requests are the limit — lower requests or add cores

How it works

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

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.

You might also need