Kubernetes Node Allocatable Resource Management

Kubernetes Node Allocatable Resource Management is the practice of understanding and configuring how much of a node's total physical capacity is actually made available for scheduling ordinary Pods, as distinct from the node's raw Capacity, which includes reservations carved out for the operating system, the kubelet and container runtime themselves, and eviction safety margins. The Allocatable value — not Capacity — is what the scheduler actually compares Pod resource requests against, and the gap between the two represents deliberately reserved headroom protecting the node's own basic functioning from being crowded out by application workloads.

Correctly reasoning about allocatable capacity, rather than raw physical capacity, is essential for accurate cluster capacity planning, since assuming every node's full physical resources are available for scheduling systematically overestimates true cluster capacity.

Capacity vs. Allocatable

The Full Breakdown

Capacity reflects the node's total physical resources as reported by the kubelet; Allocatable subtracts reservations for Kubernetes system components, the underlying OS, and a hard eviction safety margin, leaving the amount genuinely available for ordinary Pod scheduling.

kubectl describe node node-worker-05 | grep -A 5 "Capacity:"
kubectl describe node node-worker-05 | grep -A 5 "Allocatable:"

kube-reserved and system-reserved

Reserving for Kubernetes Components

--kube-reserved configures resources set aside for Kubernetes system daemons themselves — the kubelet, container runtime, and node problem detector — ensuring these components always have guaranteed capacity to function correctly even under heavy application Pod load.

--kube-reserved=cpu=200m,memory=250Mi,ephemeral-storage=1Gi

Reserving for the Underlying OS

--system-reserved configures resources set aside for non-Kubernetes OS-level processes (systemd, sshd, and other host-level services), protecting the node's basic operating system functions from application workload contention.

--system-reserved=cpu=100m,memory=100Mi

Combined Effect on Allocatable

Both reservations are subtracted from raw capacity before the result is reported as Allocatable, meaning increasing either reservation directly reduces the capacity available to application Pods on that node — this tradeoff between node stability headroom and usable application capacity is a deliberate cluster-operator decision, typically informed by observed system daemon resource consumption under realistic load.

Eviction Thresholds

Hard Eviction Threshold Subtracted from Allocatable

The kubelet's hard eviction threshold for memory (--eviction-hard=memory.available<100Mi, for example) also factors into the effective allocatable calculation, ensuring the scheduler never places Pods in a way that would leave no safety margin before the node crosses into active eviction territory.

Balancing Safety Against Usable Capacity

A larger eviction threshold provides a bigger safety cushion against sudden resource exhaustion but further reduces the node's usable allocatable capacity — this is tuned based on how much headroom a cluster's specific workload profile actually needs to avoid triggering eviction under normal operational variance.

Practical Implications for Capacity Planning

Effective Cluster Capacity Is Less Than Raw Capacity

A cluster's true schedulable capacity for application workloads is the sum of every node's Allocatable value, not the sum of raw Capacity — capacity planning exercises that overlook this distinction systematically overestimate how much workload the cluster can actually support.

kubectl get nodes -o jsonpath='{range .items[*]}{.status.allocatable.cpu}{"\n"}{end}' | \
  awk '{sum += $1} END {print sum}'

DaemonSet Overhead Further Reduces Effective Application Capacity

Beyond the system-level reservations baked into Allocatable, DaemonSet Pods running on every node (log collectors, CNI agents) further reduce the practical capacity remaining for application workloads — true "capacity available for application Pods" is Allocatable minus the aggregate DaemonSet footprint, a distinction worth making explicit in any capacity model.

Observing Allocatable in Practice

kubectl describe node node-worker-05

Capacity:
  cpu:     4
  memory:  16Gi
Allocatable:
  cpu:     3800m
  memory:  15Gi

The difference here (200m CPU, 1Gi memory) represents the combined kube-reserved, system-reserved, and eviction threshold headroom deliberately withheld from application scheduling on this node.

Example: Reasoning About Fit

kubectl describe node node-worker-05 | grep -A 10 "Allocated resources"

Comparing already-allocated requests against Allocatable (not Capacity) gives the accurate remaining headroom for new Pod scheduling on a specific node, which is the figure that actually determines whether a new Pod will fit there.