Kubernetes Resource Estimator

Requests are what Kubernetes uses for scheduling — it guarantees that much CPU will be available. Limits are the maximum a container can use before being throttled (CPU) or killed (memory). Setting requests = limits gives you Guaranteed QoS. A common pattern is requests at 25–50% of limits for burstable workloads.

CPU is measured in millicores (m). 1000m = 1 vCPU core. A typical Node.js app might request 100–250m. Memory is in MiB (mebibytes). 1 GiB = 1024 MiB. Set memory limits based on your app's actual heap usage plus a safety buffer.

Use kubectl top pods --all-namespaces to see live CPU and memory usage. For historical data, check Prometheus + Grafana or your cloud provider's container insights. Always base your requests on measured p95 usage, not guesses.

A ResourceQuota limits total resource consumption within a namespace. It prevents runaway pods from consuming all cluster resources and enforces fair usage between teams. It's strongly recommended for multi-tenant clusters or any production namespace. The quota this tool generates includes a 20% buffer above your workload totals.

Kubernetes assigns each pod a Quality of Service class: Guaranteed (requests = limits), Burstable (requests < limits), or BestEffort (no requests/limits). Guaranteed pods are the last to be evicted under memory pressure. Use Guaranteed for critical services like databases.

Reserve 10–20% for system components (kube-system, monitoring DaemonSets). Add another buffer for peak traffic bursts. A common rule: size nodes so that workloads use 60–70% of total node capacity at steady state, leaving room for rolling updates and traffic spikes.