Jak spravujete zdroje kontejnerů (CPU a paměť)?

Question

Accepted Answer

Ve výchozím nastavení mohou kontejnery používat **neomezené prostředky hostitele** — což rizikuje, že jeden kontejner bude hlasitě vytlačovat ostatní nebo způsobí selhání hostitele. Docker umožňuje nastavit **limity zdrojů** (CPU, paměť) pro kontrolu spotřeby, což je důležité pro stabilitu a spravedlivé sdílení zdrojů v produkci.

## Problém: neomezené používání zdrojů

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

## Nastavení limitů paměti a 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
```

Limity paměti (`-m`) omezují používání (kontejner je **OOM-killnut**, pokud překročí tvrdý limit); limity CPU (`--cpus`) omezují využití CPU. **Rezervace** garantují minimum.

## Monitorování a ladění

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

## Proč je to důležité

Porozumění správě zdrojů kontejnerů je důležité pro **spolehlivý provoz kontejnerů v produkci**, takže jde o cenné operační znalosti.

Jádro problému — ve výchozím nastavení mohou **kontejnery spotřebovat všechny dostupné zdroje hostitele** — je skutečné riziko: jeden vadný nebo vytížený kontejner (s únikem paměti nebo procesem mimo kontrolu) může **hlasitě vytlačovat ostatní kontejnery nebo způsobit selhání celého hostitele** (nedostatek paměti), což způsobí nestabilitu hostitele.

Nastavením **limitů zdrojů** (paměť a CPU) se tomu zabráníte **izolací spotřeby zdrojů kontejnerů**, což zajišťuje, že jeden kontejner nemůže způsobit selhání ostatních ani hostitele — nezbytné pro stabilitu při provozu více kontejnerů na jednom hostiteli (norma v produkci).

Porozumění tomu, jak nastavit **limity paměti** (s kontejnerem, který je OOM-killnut, pokud překročí tvrdý limit) a **limity CPU**, plus **rezervace** (garantující minima), je praktickým mechanismem pro kontrolu a spravedlivé sdílení zdrojů.

Vnímání toho, jak **monitorovat a ladit** — pomocí `docker stats` k pozorování skutečného používání a správné velikosti limitů, rozpoznání `OOMKilled` (kontejner, který dosáhl svého limitu paměti) k diagnostice problémů — je důležité pro nastavení vhodných limitů na základě skutečných potřeb.

To se také váže na orchestraci: **Kubernetes používá podobné žádosti/limity zdrojů**, které jsou nezbytné pro plánování a stabilitu, takže porozumění konceptu se přenáší do orchestrovaných prostředí.

Protože spolehlivý provoz více kontejnerů vyžaduje prevenci contention zdrojů a neřízeného používání, a protože limity zdrojů (limity paměti a CPU, rezervace, monitorování) jsou mechanismem pro izolaci kontejnerů a ochranu stability hostitele, je porozumění správě zdrojů kontejnerů cenné a prakticky důležité znalosti pro produkční nasazení kontejnerů — nezbytné pro stabilní hosty s více kontejnery a koncept, který se přímo rozšiřuje na orchestrovaná prostředí jako Kubernetes, kde je specifikace zdrojů fundamentální.