What is the difference between CPU/memory requests and limits, and how do they affect scheduling, eviction, and QoS?

Question

IT Interview Practice · Accepted Answer

**Requests** are what a container is *guaranteed* (used for scheduling); **limits** are the *ceiling* it may not exceed (enforced at runtime). Together they drive where Pods are placed, how they're throttled or killed under pressure, and which **Quality of Service (QoS)** class a Pod gets.

## Requests vs limits

```text
REQUEST → the amount RESERVED for the container. The SCHEDULER uses the sum of
          requests to decide if a node has room. This is your guaranteed floor.
LIMIT   → the MAX the container may use. Enforced at runtime:
          CPU over limit    → THROTTLED (slowed down, not killed)
          memory over limit → OOM-KILLED (container terminated, then restarted)
```

```yaml
spec:
  containers:
    - name: app
      image: myapp:1.0
      resources:
        requests:
          cpu: "250m"        # 0.25 of a core, guaranteed
          memory: "256Mi"
        limits:
          cpu: "500m"        # may burst to 0.5 core, then throttled
          memory: "512Mi"    # exceed this → OOMKilled
```

## How scheduling uses requests

```text
Node has 4 CPU / 8Gi allocatable.
Scheduler sums the REQUESTS of Pods already placed; a new Pod fits only if its
requests still fit in what remains. (Limits are NOT used for placement.)
→ Set requests too low → node overcommitted, Pods fight for resources.
→ Set requests too high → wasted capacity, Pods stuck Pending (nothing fits).
```

## QoS classes (decides eviction order under memory pressure)

```text
Guaranteed  → requests == limits for BOTH cpu & memory (every container)
              → last to be evicted (highest priority)
Burstable   → has requests but they are < limits (or partially set)
              → evicted after BestEffort
BestEffort  → no requests or limits at all
              → FIRST to be evicted when the node runs low on memory
```

```bash
kubectl describe pod app | grep -i qos    # QoS Class: Guaranteed/Burstable/BestEffort
kubectl top pods                           # actual CPU/memory usage
kubectl describe node <node>               # Allocated resources vs capacity
```

## Practical guidance

```text
✓ Always set memory requests = limits for predictable, OOM-safe behavior on critical apps
✓ Set CPU requests to the steady-state need; CPU limits are often left off to allow bursting
✓ Right-size from real usage (kubectl top / metrics) — not guesses
✓ Use LimitRange / ResourceQuota to enforce sane defaults per namespace
```

## Why it matters

Requests and limits are how Kubernetes shares finite node resources fairly and predictably, so understanding the distinction and its consequences is essential performance and reliability knowledge. The core insight is that they serve different purposes: **requests** are a guaranteed reservation that the **scheduler** uses to place Pods (summing requests to decide if a node has room, ignoring limits), while **limits** are a runtime ceiling enforced differently per resource — exceeding a **CPU** limit gets you **throttled** (slowed), but exceeding a **memory** limit gets the container **OOM-killed** and restarted. Getting requests wrong has real costs on both sides: too low and nodes become overcommitted so Pods starve each other; too high and capacity is wasted while Pods sit Pending because nothing fits. The three **QoS classes** — Guaranteed (requests equal limits), Burstable (requests below limits), and BestEffort (nothing set) — determine eviction order under memory pressure, with BestEffort killed first and Guaranteed last, which is exactly what you need to understand to protect critical workloads. Knowing the practical guidance (set memory requests equal to limits for critical apps, right-size from real usage via `kubectl top`, enforce defaults with LimitRange/ResourceQuota) turns this from theory into sound capacity planning. Because resource misconfiguration is one of the most common causes of instability, wasted spend, and Pending Pods in real clusters, mastering requests, limits, and QoS is fundamental to running efficient, stable Kubernetes workloads.

Requests vs limits

How scheduling uses requests

QoS classes (decides eviction order under memory pressure)

Practical guidance

Why it matters

Related questions