Kubernetes Resource Limits Calculator

CPU request is the amount of CPU the scheduler guarantees your container will always have — it is used to decide which node the pod lands on. CPU limit is the maximum CPU a container can consume before Kubernetes throttles it. If a container tries to use more CPU than its limit, the kernel throttles it (reduces its time slice) but does not kill it. Unlike memory, exceeding a CPU limit never causes a pod restart.

OOMKilled (Out Of Memory Killed) happens when a container exceeds its memory limit. The Linux kernel's OOM killer terminates the process, and Kubernetes immediately restarts the container. To prevent it: (1) profile your app's real memory usage with kubectl top or Prometheus, (2) set memory limits at least 1.5×–2× the request, (3) never set memory limits lower than requests. Watch CrashLoopBackOff with exit code 137 — that is always OOMKill.

A ResourceQuota sets an aggregate cap on all resource consumption within a Kubernetes namespace. Without a ResourceQuota, a single misbehaving workload can exhaust all cluster resources and starve other namespaces. Apply ResourceQuotas to every non-system namespace in production. This calculator adds 20% headroom above your calculated totals so the quota does not immediately block new deployments during scaling events.

The 4× ratio is a widely used rule of thumb. A very high limit-to-request ratio means pods are scheduled based on low requests but allowed to consume much more, causing noisy-neighbor problems on the node. For CPU, this triggers excessive throttling spikes. For memory, it risks OOMKill during load spikes. Best practice: CPU limit at 2×–3× request, memory limit at 1.5×–2× request. For latency-sensitive apps, set CPU request = limit (Guaranteed QoS).

Kubernetes assigns a QoS class to every pod based on its resource configuration. Guaranteed (request = limit for all containers) — never evicted under memory pressure. Burstable (at least one request < limit) — evicted when node is under pressure after BestEffort pods. BestEffort (no requests or limits at all) — first to be evicted. For critical production workloads, use Guaranteed QoS by setting memory request equal to memory limit.