Vad är skillnaden mellan CPU/minne-requests och -limits, och hur påverkar de scheduling, eviction och QoS?

Question

IT Interview Practice · Accepted Answer

**Requests** är vad en container *garanteras* (används för scheduling); **limits** är det *tak* den inte får överskrida (upprätthålls vid körning). Tillsammans styr de var Pods placeras, hur de stryps eller dödas under press, och vilken **Quality of Service (QoS)**-klass en Pod får.

## Requests kontra 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 av en kärna, garanterat
          memory: "256Mi"
        limits:
          cpu: "500m"        # får bursta till 0,5 kärna, sedan strypt
          memory: "512Mi"    # överskrid detta → OOMKilled
```

## Hur scheduling använder 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-klasser (avgör eviction-ordning under minnestryck)

```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                           # faktisk CPU/minnesanvändning
kubectl describe node <node>               # allokerade resurser kontra kapacitet
```

## Praktisk vägledning

```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
```

## Varför det är viktigt

Requests och limits är hur Kubernetes delar ändliga nodresurser rättvist och förutsägbart, så att förstå distinktionen och dess konsekvenser är väsentlig kunskap om prestanda och tillförlitlighet. Kärninsikten är att de tjänar olika syften: **requests** är en garanterad reservation som **schedulern** använder för att placera Pods (summerar requests för att avgöra om en nod har plats, och ignorerar limits), medan **limits** är ett körningstak som upprätthålls olika per resurs — att överskrida en **CPU**-limit ger dig **strypning** (nedsaktning), men att överskrida en **minnes**-limit gör att containern **OOM-dödas** och startas om. Att få requests fel har verkliga kostnader åt båda hållen: för lågt och noder blir överbokade så att Pods svälter varandra; för högt och kapacitet slösas medan Pods sitter i Pending eftersom inget får plats. De tre **QoS-klasserna** — Guaranteed (requests lika med limits), Burstable (requests under limits) och BestEffort (inget satt) — avgör eviction-ordningen under minnestryck, med BestEffort dödad först och Guaranteed sist, vilket är precis vad du behöver förstå för att skydda kritiska workloads. Att känna till den praktiska vägledningen (sätt minnes-requests lika med limits för kritiska appar, dimensionera rätt utifrån verklig användning via `kubectl top`, upprätthåll standardvärden med LimitRange/ResourceQuota) förvandlar detta från teori till sund kapacitetsplanering. Eftersom felkonfigurerade resurser är en av de vanligaste orsakerna till instabilitet, slösad kostnad och Pending-Pods i riktiga kluster är det grundläggande att behärska requests, limits och QoS för att köra effektiva, stabila Kubernetes-workloads.

Requests kontra limits

Hur scheduling använder requests

QoS-klasser (avgör eviction-ordning under minnestryck)

Praktisk vägledning

Varför det är viktigt

Relaterade frågor