Jak zarządzasz zasobami kontenera (CPU i pamięć)?

Question

Accepted Answer

Domyślnie kontenery mogą używać **nieograniczonych zasobów hosta** — co stwarza ryzyko, że jeden kontener będzie starving inne lub zawiesi hosta. Docker pozwala ustawić **limity zasobów** (CPU, pamięć) w celu kontrolowania zużycia, co jest ważne dla stabilności i uczciwego dzielenia zasobów w środowisku produkcyjnym.

## Problem: nieograniczone użycie zasobów

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

## Ustawianie limitów pamięci i 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 pamięci (`-m`) ograniczają użycie (kontener jest **zabijany przez OOM**, jeśli przekroczy limit twardy); limity CPU (`--cpus`) ograniczają użycie CPU. **Rezerwacje** gwarantują minimum.

## Monitorowanie i tuning

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

## Dlaczego to ważne

Zrozumienie zarządzania zasobami kontenera jest ważne dla **niezawodnego uruchamiania kontenerów w produkcji**, dlatego jest wartościową wiedzą operacyjną.

Problem podstawowy — domyślnie **kontenery mogą zużywać wszystkie dostępne zasoby hosta** — to rzeczywiste ryzyko: pojedynczy wadliwy lub obciążony kontener (z wyciekiem pamięci lub procesem wymykającym się spod kontroli) może **starve inne kontenery lub zawalić cały host** (brak pamięci), czyniąc hosta niestabilnym.

Ustawianie **limitów zasobów** (pamięć i CPU) zapobiega temu przez **izolowanie zużycia zasobów kontenerów**, zapewniając, że jeden kontener nie może zniszczyć innych ani hosta — jest to niezbędne dla stabilności podczas uruchamiania wielu kontenerów na jednym hoście (norma w produkcji).

Zrozumienie jak ustawić **limity pamięci** (z zabijaniem przez OOM, jeśli kontener przekroczy limit twardy) i **limity CPU**, oraz **rezerwacje** (gwarantujące minima), to praktyczny mechanizm kontrolowania i uczciwego dzielenia zasobów.

Wiedzenie jak **monitorować i tunować** — używając `docker stats` do obserwowania rzeczywistego użycia i prawidłowego zmianę rozmiarów limitów, rozpoznawanie `OOMKilled` (kontener osiągający limit pamięci) do diagnozowania problemów — jest ważne dla ustawienia odpowiednich limitów opartych na rzeczywistych potrzebach.

To również łączy się z orkiestrацją: **Kubernetes używa podobnych żądań zasobów/limitów**, które są niezbędne do planowania i stabilności, więc zrozumienie koncepcji przenosi się do środowisk zorkiestrowanych.

Ponieważ niezawodne uruchamianie wielu kontenerów wymaga zapobiegania rywalizacji o zasoby i ucieczce zużycia, a limity zasobów (ograniczenia pamięci i CPU, rezerwacje, monitorowanie) są mechanizmem izolowania kontenerów i ochrony stabilności hosta, zrozumienie zarządzania zasobami kontenera jest wartościową, praktycznie ważną wiedzą dla wdrożeń kontenerów w produkcji — niezbędną dla stabilnych hostów wielokontenerowych i koncepcją, która rozciąga się bezpośrednio na zorkiestrowane środowiska takie jak Kubernetes, gdzie specyfikacja zasobów jest fundamentalna.