Kaip valdyti konteinerio išteklius (CPU ir atmintį)?

Question

Accepted Answer

Pagal numatytuosius nustatymus, konteineriai gali naudoti **neribotus pagrindinės sistemos išteklius** — tai rizikuoja, kad vienas konteineris išnaudos kitų išteklius arba sugriaus pagrindinę sistemą. Docker leidžia nustatyti **išteklių ribas** (CPU, atmintį) suvaldyti jų naudojimą, o tai svarbu stabilumui ir teisingam išteklių dalijimui produkcijoje.

## Problema: neapriboti išteklių naudojimas

```text
BY DEFAULT a container can consume ALL available host CPU and memory:
  → a buggy/busy container (memory leak, runaway loop) can starve other containers
    or crash the entire host (out of memory)
→ In production (multiple containers per host), LIMIT resources to isolate them.
```

## Atminties ir CPU ribų nustatymas

```bash
# memory limits
docker run -m 512m myapp              # hard limit: 512 MB (container killed if exceeded — OOM)
docker run -m 512m --memory-reservation 256m myapp   # soft limit + hard limit

# CPU limits
docker run --cpus="1.5" myapp         # limit to 1.5 CPU cores
docker run --cpu-shares=512 myapp     # relative weight (priority under contention)
```

```yaml
# in docker-compose.yml (or for orchestrators)
services:
  app:
    deploy:
      resources:
        limits:    { cpus: '1.5', memory: 512M }   # maximum
        reservations: { cpus: '0.5', memory: 256M } # guaranteed minimum
```

Atminties ribos (`-m`) riboja naudojimą (konteineris yra **OOM-killed**, jei viršija ribą); CPU ribos (`--cpus`) riboja CPU naudojimą. **Rezervacijos** garantuoja minimumą.

## Stebėjimas ir derinimas

```text
✓ docker stats → live CPU/memory usage per container (to right-size limits)
✓ Set limits based on the app's actual needs (measure, then add headroom)
✓ OOMKilled (in docker inspect) → the container hit its memory limit → raise it or fix a leak
✓ Orchestrators (Kubernetes) use requests/limits similarly — essential for scheduling
```

## Kodėl tai svarbu

Supratimas apie konteinerio išteklių valdymą yra svarbus **patikimiems konteineriams paleisti produkcijoje**, todėl tai vertingas operacinis žinojimas.

Pagrindinė problema — pagal numatytuosius nustatymus, **konteineriai gali naudoti visus pagrindinės sistemos išteklius** — yra tikra rizika: vienas sugedęs arba per daug apkrautas konteineris (su atminties nuotėkiu arba nevaldomu procesu) gali **išnaudoti kitus konteinerius arba sugriati visą pagrindinę sistemą** (atmintis baigsis), todėl pagrindinė sistema tampa nestabili.

Nustatant **išteklių ribas** (atmintį ir CPU) tai išvengiama **izoliuojant konteinerių išteklius**, užtikrinant, kad vienas konteineris negali sugriati kitų arba pagrindinės sistemos — tai būtina stabilumui, kai pagrindinėje sistemoje veikia keletas konteinerių (tai norma produkcijoje).

Supratimas, kaip nustatyti **atminties ribas** (konteineris yra OOM-killed, jei viršija ribą) ir **CPU ribas**, taip pat **rezervacijas** (garantuojančias minimumą), yra praktinis mechanizmas ištekliams valdyti ir teisingai juos dalytis.

Žinojimas, kaip **stebėti ir derinti** — naudojant `docker stats` stebėti faktinį naudojimą ir tinkamai nustatyti ribas, atpažinti `OOMKilled` (konteineryje pasiekta atminties riba) problemoms diagnozuoti — svarbu nustatant tinkamas ribas pagal tikruosius poreikius.

Tai taip pat susijęs su orkestravimu: **Kubernetes naudoja panašius išteklių užklausas/ribas**, kurios yra būtinos planavimui ir stabilumui, todėl šio koncepto supratimas perkeliamas į orkestruotą aplinką.

Kadangi patikimas kelių konteinerių veikimas reikalauja išvengti išteklių konkurencijos ir kontrolės nepraradusių procesų, o kadangi išteklių ribos (atminties ir CPU apribojimai, rezervacijos, stebėjimas) yra mechanizmas konteineriams izoliuoti ir pagrindinės sistemos stabilumui apsaugoti, supratimas apie konteinerio išteklių valdymą yra vertingas, praktiškai svarbus žinojimas produkcijos konteinerio diegimuose — būtinas stabiliam daugelio konteinerių serveriui ir koncepcija, kuris tiesiogiai išplečiamas į orkestruotas aplinkas, tokias kaip Kubernetes, kur išteklių specifikacija yra esminė.