Kubernetes Pod Resource Calculator

Kubernetes separates two numbers that are often confused. A request is a scheduling claim: the scheduler sums requests already placed on each node and refuses to bind a pod where the remainder is insufficient, so requests should track average steady-state usage. A limit is an enforcement ceiling applied by the kernel at runtime. CPU is measured in millicores, where 1000m equals one core-second per second, and exceeding a CPU limit causes throttling by the Completely Fair Scheduler, which grants a quota per 100 ms period and stalls the container once it is spent. Memory has no equivalent soft failure; crossing a memory limit triggers the kernel out-of-memory killer and the container is terminated with an OOMKilled status. That asymmetry is why the calculator applies a smaller buffer to CPU, commonly 10 to 25 percent, and a larger one to memory, commonly 25 to 50 percent. Node capacity is not the same as allocatable capacity. The kubelet subtracts kube-reserved, system-reserved and hard eviction thresholds before scheduling, which typically removes 10 to 15 percent of a node, and DaemonSet pods consume more from every node before your workload gets any. The 0.9 factor used here approximates that reservation. Quality of Service class follows mechanically from the values: equal requests and limits on every container yields Guaranteed, unequal yields Burstable, and omitting both yields BestEffort, which is evicted first under node pressure. Two limits are worth stating. Runtime-managed heaps break naive sizing, since a JVM needs its container limit set to roughly 1.5 to 2 times the maximum heap to leave room for metaspace, thread stacks and native allocations. And the model assumes measured averages and peaks; without at least seven days of observed data from metrics-server or Prometheus the inputs are guesses.

Kubernetes was announced by Google in June 2014, created by Joe Beda, Brendan Burns and Craig McLuckie, and reached version 1.0 in July 2015, when it was donated to the newly formed Cloud Native Computing Foundation. Its resource model was inherited almost directly from Borg, the internal cluster manager Google had been running since around 2003. The 2015 EuroSys paper Large-scale cluster management at Google with Borg, by Abhishek Verma and colleagues, documented the request-and-limit distinction, the separation of latency-sensitive from batch work, and the practice of reclaiming the gap between requested and actually used resources, all of which reappear in Kubernetes. The enforcement machinery came from the Linux kernel. The Completely Fair Scheduler, written by Ingo Molnar, was merged in kernel 2.6.23 in 2007, and CFS bandwidth control, which supplies the quota-and-period mechanism behind CPU limits, was merged in kernel 3.2 in 2011. Kubernetes layered its own abstractions on top over subsequent releases: the three Quality of Service classes were introduced in the 1.1 and 1.2 releases in 2015 and 2016 to define eviction order under node pressure, and the Horizontal Pod Autoscaler shipped in version 1.1 in 2015 scaling on CPU utilization relative to requests. The Vertical Pod Autoscaler followed as an add-on project, using historical usage to recommend requests and limits, and remains the standard way to close the loop between observed consumption and configured values.