Jaký je rozdíl mezi CPU/memory requests a limits a jak ovlivňují scheduling, eviction a QoS?

Question

IT Interview Practice · Accepted Answer

**Requests** jsou to, co má kontejner *zaručeno* (používá se pro scheduling); **limits** jsou *strop*, který nesmí překročit (vynucováno za běhu). Společně určují, kam se Pody umístí, jak jsou pod tlakem přiškrceny nebo zabity a jakou třídu **Quality of Service (QoS)** Pod dostane.

## Requests vs limits

```text
REQUEST → množství REZERVOVANÉ pro kontejner. SCHEDULER používá součet
          requestů k rozhodnutí, zda má node místo. To je vaše zaručené minimum.
LIMIT   → MAXIMUM, které kontejner smí využít. Vynucováno za běhu:
          CPU nad limit    → PŘIŠKRCENO (zpomaleno, nezabito)
          paměť nad limit  → OOM-KILLED (kontejner ukončen, pak restartován)
```

```yaml
spec:
  containers:
    - name: app
      image: myapp:1.0
      resources:
        requests:
          cpu: "250m"        # 0,25 jádra, zaručeno
          memory: "256Mi"
        limits:
          cpu: "500m"        # může vyskočit na 0,5 jádra, pak přiškrceno
          memory: "512Mi"    # překročení → OOMKilled
```

## Jak scheduling používá requests

```text
Node má alokovatelných 4 CPU / 8Gi.
Scheduler sečte REQUESTY již umístěných Podů; nový Pod se vejde jen tehdy, když se
jeho requesty ještě vejdou do zbytku. (Limits se pro umístění NEpoužívají.)
→ Requesty příliš nízké → node přetížen (overcommit), Pody se perou o zdroje.
→ Requesty příliš vysoké → plýtvání kapacitou, Pody uvíznou v Pending (nic se nevejde).
```

## Třídy QoS (určují pořadí eviction při tlaku na paměť)

```text
Guaranteed  → requests == limits pro OBOJE cpu i paměť (každý kontejner)
              → evikován jako poslední (nejvyšší priorita)
Burstable   → má requesty, ale jsou < limits (nebo částečně nastavené)
              → evikován po BestEffort
BestEffort  → žádné requesty ani limity
              → evikován jako PRVNÍ, když nodu dochází paměť
```

```bash
kubectl describe pod app | grep -i qos    # QoS Class: Guaranteed/Burstable/BestEffort
kubectl top pods                           # skutečné využití CPU/paměti
kubectl describe node <node>               # alokované zdroje vs kapacita
```

## Praktická doporučení

```text
✓ U kritických aplikací vždy nastavte memory requests = limits pro předvídatelné, OOM-bezpečné chování
✓ CPU requests nastavte na ustálenou potřebu; CPU limits se často vynechávají, aby bylo možné bursting
✓ Velikost odvozujte ze skutečného využití (kubectl top / metriky) — ne z odhadů
✓ Používejte LimitRange / ResourceQuota k vynucení rozumných výchozích hodnot na namespace
```

## Proč je to důležité

Requests a limits jsou způsob, jakým Kubernetes férově a předvídatelně sdílí konečné zdroje nodů, takže pochopení tohoto rozdílu a jeho důsledků je nezbytná znalost pro výkon a spolehlivost. Klíčové je, že slouží k různým účelům: **requests** jsou zaručená rezervace, kterou **scheduler** používá k umístění Podů (sečte requesty a rozhodne, zda má node místo, limits ignoruje), zatímco **limits** jsou strop za běhu vynucovaný různě podle zdroje — překročení limitu **CPU** vás **přiškrtí** (zpomalí), ale překročení limitu **paměti** vede k **OOM-kill** kontejneru a jeho restartu. Špatně nastavené requesty mají skutečné náklady na obou stranách: příliš nízké a nody jsou přetížené (overcommit), takže se Pody navzájem vyhladovují; příliš vysoké a kapacita se plýtvá, zatímco Pody uvíznou v Pending, protože se nic nevejde. Tři **třídy QoS** — Guaranteed (requests se rovnají limits), Burstable (requests pod limits) a BestEffort (nic nenastaveno) — určují pořadí eviction při tlaku na paměť, přičemž BestEffort je zabit první a Guaranteed poslední, což je přesně to, co musíte pochopit, abyste ochránili kritické workloady. Znalost praktických doporučení (u kritických aplikací nastavit memory requests rovné limits, dimenzovat podle skutečného využití přes `kubectl top`, vynucovat výchozí hodnoty přes LimitRange/ResourceQuota) mění tohle z teorie ve zdravé plánování kapacity. Protože chybná konfigurace zdrojů je jednou z nejčastějších příčin nestability, plýtvání a Podů v Pending v reálných clusterech, zvládnutí requests, limits a QoS je základem pro provoz efektivních, stabilních workloadů na Kubernetes.

Requests vs limits

Jak scheduling používá requests

Třídy QoS (určují pořadí eviction při tlaku na paměť)

Praktická doporučení

Proč je to důležité

Související otázky