How to calculate CPU and memory requests and limits in Kubernetes?▼
To calculate CPU and memory requests, establish steady-state P95 consumption using Prometheus or Datadog over a 7-day period. Set requests equal to P95 plus a 20-30% buffer (Request = P95 * 1.25) to absorb diurnal traffic spikes without scheduler evictions. For memory limits, establish a ceiling 20-30% higher than the request to accommodate transient heap expansions and memory-mapped file buffers before hitting the Linux cgroup memory.max threshold. For CPU limits, industry best practice for latency-critical microservices mandates setting limits to 2x-3x requests or omitting them entirely to prevent Linux Completely Fair Scheduler (CFS) quota throttling, while pairing unconstrained limits with cluster autoscaling and Guaranteed memory ceilings.
What is the difference between Guaranteed and Burstable QoS in Kubernetes?▼
Guaranteed QoS requires CPU and memory requests to exactly equal their respective limits (cpu.limits == cpu.requests AND memory.limits == memory.requests) across all containers in the pod, assigning an oom_score_adj of -997 to -998 for near-total immunity from node memory starvation. Burstable QoS occurs when requests are strictly lower than limits or limits are omitted for CPU, yielding an oom_score_adj calculated dynamically between 2 and 999. Under node memory pressure, the kubelet and Linux OOM killer terminate BestEffort pods first (oom_score_adj: 1000), Burstable pods exceeding memory requests second, and Guaranteed pods last.
Should CPU limits always be set on production Kubernetes pods?▼
No, setting CPU limits is often counter-productive for multi-threaded microservices. Enforcing 'resources.limits.cpu' instructs the Linux kernel Completely Fair Scheduler to apply hard millisecond quotas (cpu.cfs_quota_us) over 100ms windows. When multi-threaded runtimes (Go, Java, Node.js worker pools) burst across multiple host cores, they exhaust the quota in 10-20ms, forcing the kernel to throttle execution for the remaining 80-90ms. This causes artificial P99 latency spikes and connection timeouts while the host node sits 60% idle. Production architectures typically enforce generous CPU requests, omit CPU limits, and maintain strict memory limits to prevent out-of-memory cascades.
Why do Kubernetes pods fail with Exit Code 137 OOMKilled?▼
Exit code 137 signifies process termination by Linux signal SIGKILL (128 + 9 = 137) triggered by the Out-Of-Memory Killer. This occurs in two distinct scenarios: 1) Container-level cgroup limit breach, where container_memory_working_set_bytes exceeds 'resources.limits.memory' and the kernel cgroup controller terminates the offending container immediately; or 2) Host node memory exhaustion, where physical RAM dips below the kubelet's hard eviction threshold (100MiB default) and the system OOM killer selects and kills pods with the highest oom_score_adj (typically BestEffort or Burstable pods exceeding requests).
How much CPU and memory does Kubernetes reserve for node operating systems?▼
Cloud providers reserve system capacity using kube-reserved and system-reserved piecewise curves. In AWS EKS and GCP GKE, memory reservations follow an official stepped curve: 25% of the first 4 GiB, 20% of the next 4 GiB (4 to 8 GiB), 10% of the next 8 GiB (8 to 16 GiB), 6% of the next 112 GiB (16 to 128 GiB), and 2% of memory above 128 GiB, plus a mandatory 100 MiB eviction hard threshold. For CPU, reservations deduct approximately 6% of the first core, 1% of the second core, 0.5% of cores 3 and 4, and 0.25% of cores above 4 to protect the Linux kernel, systemd, and kubelet daemons.
How to calculate the number of worker nodes needed for a Kubernetes cluster?▼
Calculate total required cluster nodes using multi-dimensional vector bin-packing: Nodes_Needed = max(ceil(Total_Pod_CPU_Req / Allocatable_Node_CPU), ceil(Total_Pod_Mem_Req / Allocatable_Node_Mem), ceil(Total_Replicas / Effective_Max_Pods)). First, deduct piecewise cloud reservations and DaemonSet footprints from raw node hardware to establish true Allocatable capacity. Next, aggregate all pod replica requests. Finally, evaluate whether the cluster is CPU-bound, Memory-bound, or constrained by CNI IP pod density limits (e.g., AWS VPC CNI ENI limits), and round up to the next integer to ensure N+1 high availability.
