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.

Technologycloud

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.

Nodes required

2 nodes for 40 pods, costing ₹46,720 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.

Nodes on CPU

Nodes on memory

Monthly cost

₹46,720

CPU utilisation

88.24%

Memory utilisation

44.12%

Cost per pod

₹1,168

Binding constraint

CPU

On resource balance

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

Method and background

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

Worked examples

Each of these is asserted on every build. If a change to the engine ever moved one of these answers, the build would fail before the page could print it.

40 pods on 8 vCPU nodes

Pods: 40
CPU request per pod: 250 m
Memory request per pod: 512 MB
vCPUs per node: 8
Memory per node: 32 GB
Reserved for the system: 15%
Scheduling headroom: 20%
Cost per node a month: ₹23,360

Nodes required2

12,000 millicores over 6,800 allocatable

Open this example

memory-heavy pods bind on memory

Pods: 40
CPU request per pod: 100 m
Memory request per pod: 4,096 MB
vCPUs per node: 8
Memory per node: 32 GB
Reserved for the system: 15%
Scheduling headroom: 20%
Cost per node a month: ₹23,360

Nodes required8

boundary: the constraint switches

Open this example

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 · India · 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.