Mitä eroa on CPU:n/muistin requesteilla ja limiteillä, ja miten ne vaikuttavat aikataulutukseen, häätöön (eviction) ja QoS:ään?

Question

IT Interview Practice · Accepted Answer

**Requestit** ovat se, mitä kontille *taataan* (käytetään aikataulutukseen); **limitit** ovat *katto*, jota se ei saa ylittää (pakotetaan ajonaikana). Yhdessä ne ohjaavat, mihin Podit sijoitetaan, miten niitä kuristetaan tai tapetaan paineen alla, ja minkä **Quality of Service (QoS)** -luokan Pod saa.

## Requestit vs limitit

```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 ydintä, taattu
          memory: "256Mi"
        limits:
          cpu: "500m"        # voi purskahtaa 0,5 ytimeen, sitten kuristetaan
          memory: "512Mi"    # tämän ylitys → OOMKilled
```

## Miten aikataulutus käyttää requesteja

```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-luokat (määräävät häätöjärjestyksen muistipaineen alla)

```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                           # todellinen CPU:n/muistin käyttö
kubectl describe node <node>               # Allokoidut resurssit vs kapasiteetti
```

## Käytännön ohjeistus

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

## Miksi se on tärkeää

Requestit ja limitit ovat se tapa, jolla Kubernetes jakaa rajallisia node-resursseja reilusti ja ennustettavasti, joten erottelun ja sen seurausten ymmärtäminen on olennaista suorituskyky- ja luotettavuustietoa. Ydinoivallus on, että ne palvelevat eri tarkoituksia: **requestit** ovat taattu varaus, jota **scheduler** käyttää Podien sijoittamiseen (summaten requestit päättääkseen onko nodella tilaa, sivuuttaen limitit), kun taas **limitit** ovat ajonaikainen katto, joka pakotetaan eri tavoin resurssia kohti — **CPU**-limitin ylittäminen johtaa **kuristukseen** (hidastus), mutta **muisti**-limitin ylittäminen johtaa kontin **OOM-tappoon** ja uudelleenkäynnistykseen. Requestien väärin asettamisella on todellisia kustannuksia molemmilla puolilla: liian matalat ja nodet ylivarautuvat niin että Podit näännyttävät toisiaan; liian korkeat ja kapasiteettia haaskataan kun Podit jäävät Pending-tilaan koska mikään ei mahdu. Kolme **QoS-luokkaa** — Guaranteed (requestit yhtä kuin limitit), Burstable (requestit alle limittien) ja BestEffort (mitään ei asetettu) — määräävät häätöjärjestyksen muistipaineen alla, BestEffort tapettuna ensin ja Guaranteed viimeisenä, mikä on juuri se mitä sinun tulee ymmärtää suojataksesi kriittisiä työkuormia. Käytännön ohjeistuksen tunteminen (aseta muistin requestit yhtä suuriksi kuin limitit kriittisille sovelluksille, oikeamitoita todellisesta käytöstä `kubectl topin` kautta, pakota oletukset LimitRangella/ResourceQuotalla) muuttaa tämän teoriasta järkeväksi kapasiteettisuunnitteluksi. Koska resurssien väärä konfigurointi on yksi yleisimmistä epävakauden, hukatun rahan ja Pending-Podien syistä todellisissa klustereissa, requestien, limittien ja QoS:n hallinta on perustavaa tehokkaiden, vakaiden Kubernetes-työkuormien ajamiselle.

Requestit vs limitit

Miten aikataulutus käyttää requesteja

QoS-luokat (määräävät häätöjärjestyksen muistipaineen alla)

Käytännön ohjeistus

Miksi se on tärkeää

Aiheeseen liittyvät kysymykset