Kubernetes Node Resource Accounting

Kubernetes Node Resource Accounting is the ongoing process by which a node tracks how much of its compute capacity — CPU, memory, ephemeral storage, and extended resources such as devices — is available, allocated, and actually in use, providing the numerical foundation that scheduling, admission, eviction, and Quality of Service decisions all depend on. Without accurate node resource accounting, the scheduler would have no reliable basis for deciding whether a Pod fits on a node, and the kubelet would have no basis for enforcing the limits that keep Pods from starving each other of shared resources.

Capacity and Allocatable

Capacity as Total Node Resources

Each Node object reports a status.capacity field describing the total resources physically present on the machine, such as total CPU cores and total memory, as detected by the kubelet at startup, representing an upper bound that does not change unless the underlying hardware or VM sizing changes.

Allocatable as the Schedulable Portion

status.allocatable is derived from capacity by subtracting resources reserved for the operating system (system-reserved), for Kubernetes system components including the kubelet and container runtime (kube-reserved), and for eviction thresholds (eviction-hard), producing the actual quantity of each resource that the scheduler considers available for placing Pods; this distinction exists specifically so that node-level system processes are protected from being starved by Pod workloads.

Tracking Requests Versus Actual Usage

Scheduling-Time Accounting: Requests

The scheduler and the kubelet's own admission checks reason primarily in terms of resource requests declared in Pod specs, summing the requests of all Pods already bound to a node and comparing that sum against allocatable capacity; this is a purely arithmetic reservation-based accounting that does not depend on what a container is actually consuming at any given moment.

Runtime Accounting: Actual Usage

Separately, the kubelet continuously measures actual resource usage through cgroup statistics — CPU time consumed, resident memory, and I/O — surfaced through the Summary API and consumed by components such as the Metrics Server, Horizontal Pod Autoscaler, and the kubelet's own eviction manager, giving a live picture that can diverge substantially from the static request-based accounting.

The Gap Between Requested and Used

Because requests represent reservations rather than guarantees of consumption, a node can be considered fully allocated from a scheduling perspective while its actual measured usage remains well below capacity, or conversely, containers without well-tuned limits can consume more than their requests suggest, which is a central tension node resource accounting is designed to make visible rather than to eliminate.

Limits, cgroups, and Enforcement

Translating Limits into cgroup Constraints

Resource limits declared on a container are translated by the kubelet and runtime into concrete cgroup constraints at container creation time — CPU limits become CFS quota and period settings (or equivalent CPU controller settings under cgroup v2), and memory limits become a hard cgroup memory ceiling enforced by the kernel, which triggers an OOM kill of the offending process if exceeded.

Quality of Service Classes

Node resource accounting is also what determines a Pod's Quality of Service class — Guaranteed, when every container's limits equal its requests for both CPU and memory; Burstable, when at least one request is set but limits and requests are not equal; and BestEffort, when no requests or limits are specified at all — and this classification directly governs eviction ordering under resource pressure.

Node-Level Pressure and Eviction Accounting

Eviction Thresholds

The kubelet's eviction manager continuously compares live resource usage signals — available memory, available node filesystem space, and available inode count — against configured hard and soft eviction thresholds, and crossing a hard threshold triggers Pod eviction to reclaim the resource before the node becomes unusable or the kernel's own OOM killer intervenes less predictably.

Eviction Ordering by Accounting Class

When eviction is necessary, the kubelet ranks candidate Pods first by whether their usage of the pressured resource exceeds their requests, and then by Quality of Service class, evicting BestEffort and over-requesting Burstable Pods before Guaranteed Pods, which makes accurate per-Pod accounting essential to fair and predictable eviction behavior.

Extended Resource Accounting

Device Plugin Resources

Resources exposed through the Device Plugin framework, such as GPUs or specialized network interfaces, are accounted for as discrete, non-fractional units advertised by the plugin and tracked by the kubelet separately from CPU and memory, with allocation recorded so that two Pods can never be assigned the same physical device.

Node Reporting Cadence

The kubelet periodically republishes updated capacity and allocatable figures to the API server as part of its node status update cycle, ensuring that changes such as device plugin registration or updated reservation configuration are reflected in the cluster's scheduling-relevant view of the node within a bounded delay.