Hvordan administrerer du containerressurser (CPU og minne)?

Question

Accepted Answer

Som standard kan containere bruke **ubegrenset vertressurser** — noe som risikerer at én container sulter andre eller krasjer verten. Docker lar deg sette **ressursbegrensninger** (CPU, minne) for å kontrollere forbruket, noe som er viktig for stabilitet og rettferdig ressursdeling i produksjon.

## Problemet: ubegrenset ressursbruk

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

## Sette minne- og CPU-grenser

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

Minneegrenser (`-m`) begrenser bruk (containeren blir **OOM-drept** hvis den overstiger den harde grensen); CPU-grenser (`--cpus`) begrenser CPU-bruk. **Reservasjoner** garanterer et minimum.

## Overvåking og justering

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

Å forstå containerressursstyring er viktig for **å kjøre containere pålitelig i produksjon**, så det er verdifull operasjonell kunnskap.

Kjerneproblematet — som standard kan **containere bruke alle tilgjengelige vertressurser** — er en reell risiko: en enkelt buggy eller opptatt container (med minnelekk eller løpsk prosess) kan **sulte andre containere eller krasje hele verten** (ut av minne), noe som gjør verten ustabil.

Å sette **ressursbegrensninger** (minne og CPU) forhindrer dette ved å **isolere containeres ressursforbruk**, og sikrer at én container ikke kan ta ned andre eller verten — essensielt for stabilitet når du kjører flere containere per vert (normen i produksjon).

Å forstå hvordan man setter **minnegrenser** (med containeren blir OOM-drept hvis den overstiger den harde grensen) og **CPU-grenser**, pluss **reservasjoner** (som garanterer minimum), er den praktiske mekanismen for å kontrollere og rettferdig dele ressurser.

Å vite hvordan man **overvåker og justerer** — ved å bruke `docker stats` for å observere faktisk bruk og riktig dimensjonere grenser, gjenkjenne `OOMKilled` (en container som treffer minnegrensen) for å diagnostisere problemer — er viktig for å sette passende grenser basert på faktiske behov.

Dette kobler seg også til orkestrering: **Kubernetes bruker lignende ressursforespørsler/grenser** som er essensielle for planlegging og stabilitet, så å forstå konseptet overføres til orkestrerte miljøer.

Siden kjøring av flere containere pålitelig krever å forhindre ressurskonflikt og løpsk forbruk, og siden ressursbegrensninger (minne- og CPU-grenser, reservasjoner, overvåking) er mekanismen for å isolere containere og beskytte vertestabilitet, er forståelse av containerressursstyring verdifull, praktisk-viktig kunnskap for produksjonsbeholdningsutplasseringer — nødvendig for stabile multi-containerverte og et konsept som utvides direkte til orkestrerte miljøer som Kubernetes, hvor ressursoppsetting er grunnleggende.