Kubernetes Resource Calculator

CPU requests are what Kubernetes uses to schedule a pod onto a node — the scheduler ensures the node has at least that many free millicores. CPU limits cap how much CPU the container can consume after it's running. Exceeding the limit causes CPU throttling (not a crash), which degrades performance. Best practice: set the limit to ~2–5× the request to allow bursting.

When a container exceeds its memory limit, the Linux kernel OOM (Out Of Memory) killer terminates the container with exit code 137. Kubernetes then restarts it according to the pod's restartPolicy. Unlike CPU throttling, memory over-limit is a hard kill. Always set memory limits to prevent one container from starving others on the same node.

Millicores represent 1/1000 of a CPU core. 1000m = 1 vCPU = 1 AWS vCPU or GCP vCPU. Common values: 100m (0.1 vCPU, for lightweight services), 500m (0.5 vCPU, for medium workloads), 1000m (1 vCPU, for CPU-intensive apps). If your node has 4 cores, it has 4000m total allocatable CPU.

HPA calculates CPU utilization as a percentage of the pod's CPU request, not the limit. If your request is 100m and your target is 70%, HPA scales up when actual CPU usage exceeds 70m. This is why setting accurate requests is critical — too low causes premature scaling, too high causes underutilization.

A ResourceQuota limits the total resources consumed by all pods in a namespace. It prevents a single team or deployment from consuming the entire cluster's capacity. Quotas can cap total CPU requests/limits, memory requests/limits, and number of pods. They are enforced at admission time — pods that exceed the quota are rejected.

For most web APIs: start with 100m CPU request / 500m CPU limit and 128Mi memory request / 512Mi memory limit. Run load tests, check actual usage with `kubectl top pods`, then adjust. As a rule of thumb: set request to ~50–70% of your measured P95 usage, and limit to ~150–200% of request to allow for traffic spikes without OOM kills.