Jaka jest różnica między requestami a limitami CPU/pamięci i jak wpływają one na scheduling, eksmisję i QoS?

Question

IT Interview Practice · Accepted Answer

**Requesty** to to, co kontener ma *zagwarantowane* (używane do schedulingu); **limity** to *pułap*, którego nie może przekroczyć (egzekwowany w czasie działania). Razem decydują, gdzie Pody są rozmieszczane, jak są throttlowane lub zabijane pod presją oraz jaką klasę **Quality of Service (QoS)** dostaje Pod.

## Requesty vs limity

```text
REQUEST → ilość ZAREZERWOWANA dla kontenera. SCHEDULER używa sumy requestów,
          aby zdecydować, czy node ma miejsce. To twój gwarantowany dół.
LIMIT   → MAKSIMUM, którego kontener może użyć. Egzekwowany w czasie działania:
          CPU ponad limit    → THROTTLOWANY (spowalniany, nie zabijany)
          pamięć ponad limit → OOM-KILLED (kontener zakończony, potem restartowany)
```

```yaml
spec:
  containers:
    - name: app
      image: myapp:1.0
      resources:
        requests:
          cpu: "250m"        # 0,25 rdzenia, gwarantowane
          memory: "256Mi"
        limits:
          cpu: "500m"        # może wzrosnąć do 0,5 rdzenia, potem throttlowany
          memory: "512Mi"    # przekroczysz to → OOMKilled
```

## Jak scheduling używa requestów

```text
Node ma 4 CPU / 8Gi alokowalne.
Scheduler sumuje REQUESTY już rozmieszczonych Podów; nowy Pod mieści się tylko, jeśli jego
requesty wciąż mieszczą się w tym, co pozostało. (Limity NIE są używane przy rozmieszczaniu.)
→ Ustaw requesty za nisko → node przeciążony, Pody walczą o zasoby.
→ Ustaw requesty za wysoko → zmarnowana pojemność, Pody utknięte w Pending (nic nie pasuje).
```

## Klasy QoS (decydują o kolejności eksmisji pod presją pamięci)

```text
Guaranteed  → requesty == limity dla OBU cpu i pamięci (każdy kontener)
              → eksmitowany ostatni (najwyższy priorytet)
Burstable   → ma requesty, ale są < limity (lub częściowo ustawione)
              → eksmitowany po BestEffort
BestEffort  → brak requestów i limitów w ogóle
              → PIERWSZY do eksmisji, gdy nodowi zaczyna brakować pamięci
```

```bash
kubectl describe pod app | grep -i qos    # QoS Class: Guaranteed/Burstable/BestEffort
kubectl top pods                           # faktyczne użycie CPU/pamięci
kubectl describe node <node>               # zaalokowane zasoby vs pojemność
```

## Praktyczne wskazówki

```text
✓ Zawsze ustawiaj memory requests = limits dla przewidywalnego, OOM-bezpiecznego zachowania krytycznych aplikacji
✓ Ustaw CPU requests na potrzebę w stanie ustalonym; CPU limits często się pomija, by umożliwić bursting
✓ Dobieraj rozmiar na podstawie realnego użycia (kubectl top / metryki) — nie zgadywania
✓ Użyj LimitRange / ResourceQuota, aby wymusić rozsądne domyślne wartości per przestrzeń nazw
```

## Dlaczego to ważne

Requesty i limity to sposób, w jaki Kubernetes sprawiedliwie i przewidywalnie dzieli skończone zasoby noda, więc zrozumienie rozróżnienia i jego konsekwencji to niezbędna wiedza o wydajności i niezawodności. Kluczowe spostrzeżenie jest takie, że służą one różnym celom: **requesty** to gwarantowana rezerwacja, której **scheduler** używa do rozmieszczania Podów (sumując requesty, by zdecydować, czy node ma miejsce, ignorując limity), podczas gdy **limity** to pułap czasu działania egzekwowany inaczej dla każdego zasobu — przekroczenie limitu **CPU** powoduje **throttling** (spowolnienie), ale przekroczenie limitu **pamięci** powoduje **OOM-kill** kontenera i restart. Błędne requesty mają realne koszty po obu stronach: za niskie i nody stają się przeciążone, więc Pody głodzą się nawzajem; za wysokie i pojemność jest marnowana, a Pody stoją w Pending, bo nic nie pasuje. Trzy **klasy QoS** — Guaranteed (requesty równe limitom), Burstable (requesty poniżej limitów) i BestEffort (nic nieustawione) — decydują o kolejności eksmisji pod presją pamięci, z BestEffort zabijanym pierwszym i Guaranteed ostatnim, co jest dokładnie tym, co musisz zrozumieć, aby chronić krytyczne workloady. Znajomość praktycznych wskazówek (ustaw memory requests równe limitom dla krytycznych aplikacji, dobieraj rozmiar z realnego użycia przez `kubectl top`, wymuszaj domyślne wartości przez LimitRange/ResourceQuota) zmienia to z teorii w solidne planowanie pojemności. Ponieważ błędna konfiguracja zasobów to jedna z najczęstszych przyczyn niestabilności, marnowanych wydatków i Podów w stanie Pending w prawdziwych klastrach, opanowanie requestów, limitów i QoS jest fundamentalne dla uruchamiania wydajnych, stabilnych workloadów Kubernetes.

Requesty vs limity

Jak scheduling używa requestów

Klasy QoS (decydują o kolejności eksmisji pod presją pamięci)

Praktyczne wskazówki

Dlaczego to ważne

Powiązane pytania