Mi a különbség a CPU/memória request és limit között, és hogyan hatnak az ütemezésre, az eviction-re és a QoS-re?

Question

IT Interview Practice · Accepted Answer

A **requestek** azok, amiket egy konténer *garantáltan* megkap (az ütemezéshez használva); a **limitek** a *felső korlát*, amelyet nem léphet túl (futásidőben kikényszerítve). Együtt határozzák meg, hova kerülnek a Podok, hogyan throttle-olódnak vagy ölődnek meg terhelés alatt, és melyik **Quality of Service (QoS)** osztályt kapja egy Pod.

## Request vs limit

```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 mag, garantálva
          memory: "256Mi"
        limits:
          cpu: "500m"        # 0.5 magig burstölhet, aztán throttle
          memory: "512Mi"    # ezt túllépve → OOMKilled
```

## Hogyan használja az ütemezés a requesteket

```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 osztályok (a memórianyomás alatti eviction-sorrendet döntik el)

```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                           # tényleges CPU/memória használat
kubectl describe node <node>               # lefoglalt erőforrások vs kapacitás
```

## Gyakorlati útmutatás

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

## Miért fontos

A requestek és limitek azok, amivel a Kubernetes igazságosan és kiszámíthatóan osztja el a véges node-erőforrásokat, ezért a megkülönböztetés és annak következményeinek megértése alapvető teljesítmény- és megbízhatósági tudás. A lényegi felismerés, hogy más célt szolgálnak: a **requestek** garantált foglalás, amelyet a **scheduler** használ a Podok elhelyezéséhez (a requesteket összegezve dönti el, van-e hely egy node-on, a limiteket figyelmen kívül hagyva), míg a **limitek** futásidejű felső korlát, amelyet erőforrásonként másképp kényszerít ki — a **CPU** limit túllépéséért **throttle**-t (lassítást) kapsz, de a **memória** limit túllépéséért a konténert **OOM-killelik** és újraindítják. A requestek elrontásának valós ára van mindkét oldalon: túl alacsonyan a node-ok túlfoglalttá válnak, így a Podok kiéheztetik egymást; túl magasan a kapacitás pazarlódik, miközben a Podok Pending állapotban ülnek, mert semmi nem fér el. A három **QoS osztály** — Guaranteed (a requestek egyenlők a limitekkel), Burstable (a requestek a limitek alatt) és BestEffort (semmi sincs beállítva) — a memórianyomás alatti eviction-sorrendet dönti el, a BestEffort-ot ölik meg elsőként, a Guaranteed-et utolsóként — pontosan ezt kell megérteni a kritikus workloadok védelméhez. A gyakorlati útmutatás ismerete (a kritikus alkalmazásoknál a memória-request legyen egyenlő a limittel, méretezz a valós használatból a `kubectl top` révén, kényszeríts ki alapértékeket LimitRange/ResourceQuota-val) elméletből józan kapacitástervezéssé alakítja ezt. Mivel az erőforrás-hibás konfiguráció a valódi clusterekben az instabilitás, a pazarolt költség és a Pending Podok egyik leggyakoribb oka, a requestek, limitek és a QoS elsajátítása alapvető a hatékony, stabil Kubernetes-workloadok futtatásához.

Request vs limit

Hogyan használja az ütemezés a requesteket

QoS osztályok (a memórianyomás alatti eviction-sorrendet döntik el)

Gyakorlati útmutatás

Miért fontos

Kapcsolódó kérdések