Kubernetes Resource Planner

Kubernetes capacity planning turns on the distinction between requests and limits. A request is a scheduling claim: the scheduler places a pod only on a node whose unreserved allocatable capacity covers the sum of its container requests, and that reservation is held whether or not the process ever uses it. A limit is an enforcement ceiling applied through Linux cgroups. CPU is compressible, so exceeding a CPU limit produces throttling by the Completely Fair Scheduler quota mechanism rather than termination, while memory is not, so exceeding a memory limit triggers an out-of-memory kill of the container. CPU is expressed in millicores, where 1000m equals one core-second per second, and memory in binary units where 1 Gi equals 1024 Mi. Requests and limits together also assign the pod a quality of service class: Guaranteed when they match for every container, Burstable when requests are lower, and BestEffort when neither is set, which determines eviction order under node pressure. Node capacity is always smaller than the instance size suggests. The kubelet reserves resources for itself, the container runtime and the operating system through kube-reserved and system-reserved, plus an eviction threshold, so a nominal 4 vCPU and 16 GiB node typically exposes closer to 3.6 vCPU and 14 to 15 GiB as allocatable. A third constraint is the pod count ceiling, 110 per node by default in kubeadm clusters and lower on some managed platforms where the limit is tied to available IP addresses. Pods per node is the minimum of the CPU-derived, memory-derived and count-derived figures. Buffer allowances of 15 to 25 percent are conventional in production because rolling updates run surge replicas temporarily and a node failure must be absorbable. The cost output uses flat assumed unit prices and ignores instance families, committed-use discounts, spot pricing, storage and egress.

Kubernetes descends directly from Borg, the internal cluster manager Google had been running since roughly 2003 to schedule containerised jobs across its fleet. Borg was described publicly for the first time in the 2015 EuroSys paper on large-scale cluster management at Google, by Abhishek Verma and colleagues, following the 2013 Omega paper on a successor scheduler built around shared state. Borg introduced the resource-request model that Kubernetes inherited, including the finding that users systematically overestimate what their jobs need, which Borg countered by reclaiming the gap between requested and actually used capacity. Kubernetes itself was announced in June 2014 by Joe Beda, Brendan Burns and Craig McLuckie at Google, reached version 1.0 in July 2015, and was donated at that point to the newly formed Cloud Native Computing Foundation. The resource model has been extended steadily since: quality of service classes and the eviction manager arrived across the early 1.x releases, the Horizontal Pod Autoscaler gained support for custom and external metrics, and the Vertical Pod Autoscaler was built as an add-on that recommends requests from observed usage rather than guesswork. Cost attribution tools such as Kubecost and rightsizing tools such as Goldilocks appeared from the late 2010s onward, largely because the gap between requested and used resources that Borg had documented internally resurfaced as a cloud billing problem.