Kubernetes Resource Requests and Limits: A Practical Guide

Requests and limits tell Kubernetes how to manage capacity

Kubernetes resource requests and limits define how much CPU and memory a container expects and how much it is allowed to use. Requests affect scheduling because Kubernetes uses them to decide which node can run a pod. Limits cap usage, which can protect nodes but also create performance problems when set carelessly.

These settings are not decorative YAML. They shape reliability, cost, scheduling, autoscaling, and incident behavior. A pod with no requests can be scheduled in ways that overload nodes. A pod with unrealistic requests can waste capacity. A pod with a harsh CPU limit can be throttled even when the node has spare CPU.

CPU and memory behave differently

CPU is compressible. If a container hits its CPU limit, it can be throttled and run slower. Memory is not forgiving in the same way. If a container uses too much memory, it may be killed. This difference matters when choosing limits. A CPU limit can hurt latency, while a memory limit can create restarts.

For many latency-sensitive services, CPU requests are important, but CPU limits need careful testing. Some teams avoid CPU limits for certain services and rely on requests, quotas, and node isolation instead. Memory limits are more common because runaway memory usage can damage node stability.

• Set requests based on measured usage, not guesses.
• Understand CPU throttling before adding strict CPU limits.
• Use memory limits to prevent one pod from exhausting a node.
• Review resource settings after load tests and production incidents.

Quality of Service affects eviction priority

Kubernetes assigns pods a Quality of Service class based on requests and limits. Guaranteed pods have equal requests and limits for CPU and memory. Burstable pods have some requests but are not fully guaranteed. BestEffort pods have no requests or limits. During resource pressure, BestEffort pods are most likely to be evicted.

This is important for critical services. A production API, queue worker, or database sidecar should not accidentally run as BestEffort. If the cluster is under pressure, the least protected workloads are the first to suffer.

Resource settings connect to cost

Requests reserve cluster capacity. If every team over-requests by a large margin, the cluster appears full while real usage is low. This leads to unnecessary nodes and higher cloud bills. If every team under-requests, scheduling becomes optimistic and incidents become more likely. Cost control and reliability both depend on realistic values.

Use metrics, VPA recommendations, load tests, and historical usage to tune. Review p95 and p99 usage, not only averages. Spiky workloads may need headroom, while steady jobs can often be sized tightly.

Make resource review part of release work

New features can change memory, CPU, and startup behavior. Resource requests that were safe six months ago may become wrong after a library upgrade or traffic change. Treat resource settings as living production configuration. They should be reviewed, tested, and owned by the teams that operate the service.