Kubernetes Resource Request Calculator

Requests are the guaranteed minimum resources Kubernetes schedules your pod with — the scheduler uses requests to find a node with enough capacity. Limits are the maximum a container can use; if it exceeds the CPU limit, it's throttled; if it exceeds memory, it's OOMKilled. Always set requests; limits are optional but recommended for multi-tenant clusters.

HPA (Horizontal Pod Autoscaler) scales the number of replicas based on CPU/memory/custom metrics. VPA (Vertical Pod Autoscaler) adjusts the resource requests/limits of existing pods. HPA is best for stateless web workloads with variable traffic. VPA is useful when you don't know the right resource sizing and want Kubernetes to learn it.

Run your workload under production-like load and check actual memory usage with kubectl top pods. Set requests to ~80% of P99 observed usage. Set limits to 1.5–2× the request. For Java apps, account for JVM overhead: add 512 MB–1 GB on top of your heap size for GC, metaspace, and native memory.

1000 millicores = 1 vCPU. So 250m = 0.25 cores, 500m = 0.5 cores. Kubernetes uses millicores for CPU requests to allow fractional CPU allocation. For a web server that's CPU-light but needs consistent latency, 100–250m is typical. CPU limits above 1000m (1 full core) should be considered carefully as they increase throttling risk.

Node size affects scheduling efficiency. Smaller nodes (2–4 vCPU) waste less capacity when pods can't be co-located but add overhead per node. Larger nodes (8–16 vCPU) allow more efficient packing but increase blast radius if a node fails. A common pattern: use nodes with 4–8× your typical pod's resource requirements to allow efficient bin-packing.