Hvordan administrerer du containerressourcer (CPU og hukommelse)?

Question

Accepted Answer

Som standard kan containere bruge **ubegrænset værtsressourcer** — hvilket risikerer, at en container sulter andre eller får værten til at gå ned. Docker lader dig angive **ressourcebegrænsninger** (CPU, hukommelse) for at kontrollere forbruget, hvilket er vigtigt for stabilitet og fair ressourcedeling i produktion.

## Problemet: ubegrænset ressourceforbrug

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

## Indstilling af hukommelse- og CPU-grænser

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

Hukommelsesgrænser (`-m`) begrænser forbruget (containeren bliver **OOM-dræbt** hvis den overstiger hardgrænsen); CPU-grænser (`--cpus`) begrænser CPU-forbrug. **Reservationer** garanterer et minimum.

## Overvågning og 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
```

## Hvorfor det betyder noget

At forstå containerressourcestyring er vigtig for **at køre containere pålideligt i produktion**, så det er værdifuld operationel viden.

Kerneproblemationen — som standard kan **containere forbruge alle tilgængelige værtsressourcer** — er en reel risiko: en enkelt fejlbehæftet eller travl container (med et hukommelsesleak eller løbsk proces) kan **sulte andre containere eller få hele værten til at gå ned** (tom for hukommelse), hvilket gør værten ustabil.

Indstilling af **ressourcebegrænsninger** (hukommelse og CPU) forhindrer dette ved at **isolere containerenes ressourceforbrug**, hvilket sikrer, at en container ikke kan få andre ned eller værten — vigtig for stabilitet når man kører flere containere pr. vært (normen i produktion).

At forstå hvordan man indstiller **hukommelsesgrænser** (med containeren blive OOM-dræbt hvis den overstiger hardgrænsen) og **CPU-grænser**, plus **reservationer** (garanterer minimums), er den praktiske mekanisme for at kontrollere og fair dele ressourcer.

At vide hvordan man **overvåger og tuner** — brug `docker stats` til at observere faktisk forbrug og rette størrelsen på grænser, genkendelse af `OOMKilled` (en container der rammer sin hukommelsesgrænse) for at diagnosticere problemer — er vigtig for at indstille passende grænser baseret på reelle behov.

Dette forbinder sig også til orkestrering: **Kubernetes bruger lignende ressourceanmodninger/grænser** som er vigtige for planlægning og stabilitet, så forståelsen af konceptet overføres til orkesterede miljøer.

Da kørsel af flere containere pålideligt kræver at forhindre ressourcekonflikter og løbsk forbrug, og da ressourcebegrænsninger (hukommelse og CPU-lofter, reservationer, overvågning) er mekanismen for at isolere containere og beskytte værtsstabilitet, er forståelsen af containerressourcestyring værdifuld, praktisk vigtig viden for produktionscontainerinstallationer — nødvendig for stabile multi-container-værter og et koncept der udvides direkte til orkestrede miljøer som Kubernetes, hvor ressourcespecifikation er fundamental.