Kubernetes Resource Limits and Requests Explained

Requests and limits are the two knobs Kubernetes uses to schedule and constrain containers. Get them wrong and pods crash or sit idle on an overloaded node.

Requests vs limits

Requests tell the scheduler how much resource a container needs. Nodes are chosen based on available requested capacity.

Limits cap how much a container can actually consume at runtime.

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

What happens when limits are hit

• CPU: throttled. Container slows down but keeps running.
• Memory: killed. OOMKilled status. Pod restarts.

Memory limits are hard. CPU limits cause throttling.

Setting good values

Start with no limits. Run under realistic load. Observe with:

kubectl top pods -n your-namespace

Set requests to the observed average. Set limits to the observed peak plus headroom.

The danger of CPU limits

CPU throttling is invisible in most dashboards. A container hitting its CPU limit looks slow, not broken. Many teams remove CPU limits entirely and rely on requests for scheduling fairness.

Quality of Service classes

Kubernetes assigns a QoS class based on your settings:

• Guaranteed: requests equal limits for all containers.
• Burstable: requests set, limits higher.
• BestEffort: no requests or limits.

Guaranteed pods are last to be evicted under memory pressure. BestEffort are first.

Namespace resource quotas

Enforce defaults across a team with a LimitRange:

apiVersion: v1
kind: LimitRange
metadata:
  name: default-limits
spec:
  limits:
    - default:
        memory: 256Mi
        cpu: 500m
      defaultRequest:
        memory: 128Mi
        cpu: 250m
      type: Container

Without this, containers with no requests get BestEffort, which means they are evicted first under memory pressure.