Kako upravljate s sredstvi vsebnikov (CPU in pomnilnik)?

Question

Accepted Answer

Privzeto lahko vsebniki uporabijo **neomejene vire gostitelja** — kar tvega, da en vsebnik druge gladuje ali zruši gostitelja. Docker vam omogoča nastavitev **omejitev virov** (CPU, pomnilnik) za nadzor porabe, kar je pomembno za stabilnost in pravično deljenje virov v produkciji.

## Problem: neomejeno uporabo virov

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

## Nastavitev omejitev pomnilnika in CPU

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

Omejitve pomnilnika (`-m`) omeјijo porabo (vsebnik je **OOM-ubljen**, če preseže trdo omejitev); omejitve CPU (`--cpus`) omejijo porabo CPU. **Rezervacije** zagotavljajo minimalno vrednost.

## Spremljanje in optimizacija

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

## Zakaj je to pomembno

Razumevanje upravljanja virov vsebnikov je pomembno za **zanesljivo izvajanje vsebnikov v produkciji**, zato je dragoceno operativno znanje.

Osrednji problem — privzeto, **vsebniki lahko porabijo vse razpoložljive vire gostitelja** — je prava nevarnost: en okvarjen ali obremenjen vsebnik (s puščanjem pomnilnika ali nadziranim processom) lahko **gladuje druge vsenike ali zruši celoten gostitelja** (pomanjkanje pomnilnika), kar gostitelja naredi nestabilen.

Nastavitev **omejitev virov** (pomnilnik in CPU) to prepreči z **izolacijo porabe virov vsebnikov**, kar zagotavlja, da en vsebnik ne more onesposobiti drugih ali gostitelja — bistveno za stabilnost pri izvajanju več vsebnikov na gostitelju (norma v produkciji).

Razumevanje kako nastaviti **omejitve pomnilnika** (pri čemer je vsebnik OOM-ubljen, če preseže trdo omejitev) in **omejitve CPU**, plus **rezervacije** (ki zagotavljajo minimalne vrednosti), je praktični mehanizem za nadzor in pravično deljenje virov.

Znanje kako **spremljati in optimizirati** — z uporabo `docker stats` za opazovanje dejanske porabe in prilagajanje omejitev, prepoznavanje `OOMKilled` (vsebnik, ki doseže svojo omejitev pomnilnika) za diagnozo težav — je pomembno za nastavitev ustreznih omejitev glede na dejansko potrebo.

To se tudi povezuje z orkestriranjem: **Kubernetes uporablja podobne zahtevke/omejitve virov**, ki so bistveni za razporeditev in stabilnost, zato se razumevanje koncepta prenese v orkestrirane okolje.

Ker zanesljivo izvajanje več vsebnikov zahteva preprečevanje konkurence virov in nadziranega potrošovanja, in ker so omejitve virov (omejitve pomnilnika in CPU, rezervacije, spremljanje) mehanizem za izolacijo vsebnikov in zaščito stabilnosti gostitelja, je razumevanje upravljanja virov vsebnikov dragoceno, praktično-pomembno znanje za produkcijske uvedbe vsebnikov — potrebno za stabilne večvsebniške gostiteljie in koncept, ki se neposredno razširja na orkestroriana okolja, kot je Kubernetes, kjer je specifikacija virov temeljna.