Resource Requests and Limits

Requests and limits should be set for every production workload. Without requests, the scheduler has no information to place pods well, so you end up with wasted capacity or overcommitted nodes. Without limits, a single container can use far more than expected and affect its neighbours.

How it works

A request is the amount of a resource a container is guaranteed. The kube-scheduler uses requests, not limits, to decide which node a pod fits on, and a pod’s request is the sum of its containers’ requests. A limit is the maximum a container may use, enforced by the kubelet and container runtime, with the Linux kernel doing the work through cgroups. A container can use more than its request when the node has spare capacity.

The two resources behave differently at the limit. CPU limits are enforced by throttling, so the container is slowed but keeps running. Memory limits are enforced by out-of-memory kills: a container that exceeds its limit can be terminated when the kernel detects memory pressure. If you set a limit but no request, and nothing else applies a default, Kubernetes uses the limit as the request.

A practical example

resources:
  requests:
    cpu: "500m"
    memory: "128Mi"
  limits:
    cpu: "1"
    memory: "256Mi"

Here 500m means half a CPU core and 1 means one core. The scheduler looks for a node with at least that much unreserved CPU and memory, and the container is throttled above one core and exposed to an OOM kill above 256Mi.

Common mistakes

• Guessing values instead of measuring. Base requests on observed usage, and use the Vertical Pod Autoscaler in recommendation mode to inform them.
• Setting memory limits below real peak usage, which causes repeated OOM kills and restarts.
• Setting requests far above real usage, which wastes money because nodes are sized for reservations rather than consumption.
• Setting very tight CPU limits on latency-sensitive services, which can cause throttling even when the node has idle CPU.
• Combining the Horizontal Pod Autoscaler with CPU utilisation targets while leaving CPU requests unset or unrealistic, since utilisation is measured against the request.
• Leaving namespaces without defaults or quotas, so some pods run with no requests at all.

When to use it and when not to

Always set memory and CPU requests for production workloads. Whether to set CPU limits is a judgement call: they guard against runaway processes but can throttle healthy ones, so decide per workload and measure. Memory limits are generally worth setting because memory cannot be reclaimed by throttling. Right-sized requests also help node autoscalers such as Karpenter choose appropriate capacity, and our Kubernetes consulting service covers sizing reviews.

See also

• Vertical Pod Autoscaler
• Horizontal Pod Autoscaler
• Karpenter
• Namespace