Hoe beheer je containerresources (CPU en geheugen)?

Question

Accepted Answer

Standaard kunnen containers **onbeperkt hostresources** gebruiken — wat risico's met zich meebrengt dat één container anderen uithongert of de host crasht. Docker laat je **resourcelimieten** (CPU, geheugen) instellen om consumptie te controleren, wat belangrijk is voor stabiliteit en eerlijke resourcedeling in productie.

## Het probleem: onbegrensde resourcegebruik

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

## Geheugen- en CPU-limieten instellen

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

Geheugenlimieten (`-m`) limiteren het gebruik (de container wordt **OOM-killed** als het de harde limiet overschrijdt); CPU-limieten (`--cpus`) limiteren CPU-gebruik. **Reserveringen** garanderen een minimum.

## Monitoring en afstemming

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

## Waarom het belangrijk is

Inzicht in containerresourcebeheer is belangrijk voor **het betrouwbaar uitvoeren van containers in productie**, dus het is waardevolle operationele kennis.

Het kernprobleem — standaard kunnen **containers al beschikbare hostresources verbruiken** — is een reëel risico: één defecte of druk bezette container (met geheugenlek of wild proces) kan **andere containers uithongeren of de hele host crashen** (onvoldoende geheugen), waardoor de host instabiel wordt.

Door **resourcelimieten** (geheugen en CPU) in te stellen, voorkom je dit door **containerresourcegebruik te isoleren**, zodat één container niet anderen of de host down kan halen — essentieel voor stabiliteit bij het uitvoeren van meerdere containers per host (de norm in productie).

Inzicht in hoe je **geheugenlimieten** instelt (met de container die OOM-killed wordt als het de harde limiet overschrijdt) en **CPU-limieten**, plus **reserveringen** (die minimums garanderen), is het praktische mechanisme voor het controleren en eerlijk delen van resources.

Weten hoe je **monitort en afstemt** — door `docker stats` te gebruiken om werkelijk gebruik waar te nemen en limieten te dimensioneren, `OOMKilled` herkennen (een container die zijn geheugenlimieten raakt) om problemen te diagnosticeren — is belangrijk voor het instellen van passende limieten op basis van werkelijke behoeften.

Dit verbindt ook met orkestratie: **Kubernetes gebruikt vergelijkbare resourceaanvragen/limieten** die essentieel zijn voor planning en stabiliteit, dus inzicht in het concept draagt over naar georkestreerde omgevingen.

Omdat het betrouwbaar uitvoeren van meerdere containers vereist dat je resourceconflicten en wild verbruik voorkomt, en omdat resourcelimieten (geheugen- en CPU-cappen, reserveringen, monitoring) het mechanisme zijn voor het isoleren van containers en het beschermen van hoststabiliteit, is inzicht in containerresourcebeheer waardevolle, praktisch belangrijke kennis voor containerimplementaties in productie — noodzakelijk voor stabiele multi-containerhosten en een concept dat rechtstreeks doorloopt naar georkestreerde omgevingen zoals Kubernetes, waar resourcespecificatie fundamenteel is.