Kuo skiriasi CPU/atminties requests ir limits ir kaip jie veikia scheduling, eviction bei QoS?

Question

IT Interview Practice · Accepted Answer

**Requests** yra tai, kas konteineriui *garantuojama* (naudojama scheduling'ui); **limits** yra *lubos*, kurių jis negali viršyti (užtikrinama vykdymo metu). Kartu jie lemia, kur Pod'ai talpinami, kaip jie stabdomi ar žudomi esant spaudimui ir kurią **Quality of Service (QoS)** klasę Pod'as gauna.

## Requests vs. limits

```text
REQUEST → kiekis, REZERVUOTAS konteineriui. SCHEDULER naudoja request'ų sumą,
          kad nuspręstų, ar node turi vietos. Tai jūsų garantuotos grindys.
LIMIT   → MAKSIMUMAS, kurį konteineris gali naudoti. Užtikrinamas vykdymo metu:
          CPU virš limito    → STABDOMAS (lėtinamas, ne žudomas)
          atmintis virš limito → OOM-KILLED (konteineris nutraukiamas, tada perkraunamas)
```

```yaml
spec:
  containers:
    - name: app
      image: myapp:1.0
      resources:
        requests:
          cpu: "250m"        # 0,25 branduolio, garantuota
          memory: "256Mi"
        limits:
          cpu: "500m"        # gali šoktelėti iki 0,5 branduolio, tada stabdoma
          memory: "512Mi"    # tai viršijus → OOMKilled
```

## Kaip scheduling naudoja requests

```text
Node turi 4 CPU / 8Gi paskirstomų.
Scheduler sumuoja jau patalpintų Pod'ų REQUESTS; naujas Pod'as telpa tik jei jo
requests dar telpa į likutį. (Limits NENAUDOJAMI talpinimui.)
→ Requests per mažas → node perkrautas, Pod'ai grumiasi dėl resursų.
→ Requests per didelis → švaistomas pajėgumas, Pod'ai stringa Pending (niekas netelpa).
```

## QoS klasės (lemia eviction eiliškumą esant atminties spaudimui)

```text
Guaranteed  → requests == limits ir cpu, ir atminčiai (kiekvienam konteineriui)
              → paskutinis evictinamas (aukščiausias prioritetas)
Burstable   → turi requests, bet jie < limits (arba iš dalies nustatyti)
              → evictinamas po BestEffort
BestEffort  → visai nėra requests ar limits
              → PIRMAS evictinamas, kai node pritrūksta atminties
```

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

## Praktiniai patarimai

```text
✓ Kritinėms app visada nustatykite atminties requests = limits, kad elgesys būtų nuspėjamas ir OOM-saugus
✓ CPU requests nustatykite pagal pastovų poreikį; CPU limits dažnai paliekami, kad leistų šoktelėti
✓ Dydį parinkite iš realaus naudojimo (kubectl top / metrics), o ne iš spėjimų
✓ Naudokite LimitRange / ResourceQuota, kad įtvirtintumėte protingus numatytuosius kiekvienam namespace
```

## Kodėl tai svarbu

Requests ir limits yra tai, kaip Kubernetes teisingai ir nuspėjamai dalija baigtinius node resursus, tad suprasti skirtumą ir jo pasekmes yra esminė našumo ir patikimumo žinia. Pagrindinė įžvalga — kad jie tarnauja skirtingiems tikslams: **requests** yra garantuota rezervacija, kurią **scheduler** naudoja Pod'ams talpinti (sumuodamas requests, kad nuspręstų, ar node turi vietos, ignoruodamas limits), o **limits** yra vykdymo laiko lubos, užtikrinamos skirtingai kiekvienam resursui — viršijus **CPU** limitą būnate **stabdomas** (lėtinamas), bet viršijus **atminties** limitą konteineris būna **OOM-killed** ir perkraunamas. Neteisingi requests kainuoja abiem pusėm: per maži — ir node'ai perkraunami, tad Pod'ai vienas kitą alkina; per dideli — ir pajėgumas švaistomas, o Pod'ai sėdi Pending, nes niekas netelpa. Trys **QoS klasės** — Guaranteed (requests lygu limits), Burstable (requests žemiau limits) ir BestEffort (nieko nenustatyta) — lemia eviction eiliškumą esant atminties spaudimui: BestEffort žudomas pirmas, Guaranteed — paskutinis, o tai būtent ir reikia suprasti, norint apsaugoti kritinius workload'us. Praktinių patarimų žinojimas (kritinėms app nustatyti atminties requests lygius limits, dydį parinkti iš realaus naudojimo per `kubectl top`, įtvirtinti numatytuosius su LimitRange/ResourceQuota) paverčia tai iš teorijos į patikimą pajėgumo planavimą. Kadangi netinkamas resursų konfigūravimas yra viena dažniausių nestabilumo, švaistomų išlaidų ir Pending Pod'ų priežasčių realiuose klasteriuose, requests, limits ir QoS įvaldymas yra pamatinis efektyviems, stabiliems Kubernetes workload'ams paleisti.

Requests vs. limits

Kaip scheduling naudoja requests

QoS klasės (lemia eviction eiliškumą esant atminties spaudimui)

Praktiniai patarimai

Kodėl tai svarbu

Susiję klausimai