Cum gestionezi resursele containerului (CPU și memorie)?

Question

Accepted Answer

În mod implicit, containerele pot folosi **resurse nelimitate ale gazdei** — ceea ce riscă ca un container să lipsească pe alții de resurse sau să blocheze gazda. Docker te lasă să setezi **limite de resurse** (CPU, memorie) pentru a controla consumul, important pentru stabilitate și partajarea echitabilă a resurselor în producție.

## Problema: utilizare de resurse nemărginită

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

## Setarea limitelor de memorie ș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
```

Limitele de memorie (`-m`) limitează utilizarea (containerul este **ucis din cauza OOM** dacă depășește limita hard); limitele de CPU (`--cpus`) limitează utilizarea CPU. **Rezervările** garantează un minim.

## Monitorizare și ajustare

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

## De ce este important

Înțelegerea gestionării resurselor containerului este importantă pentru **rularea containerelor fiabil în producție**, deci este o cunoaștere operațională valoroasă.

Problema de bază — în mod implicit, **containerele pot consuma toate resursele disponibile ale gazdei** — este un risc real: un singur container defect sau ocupat (cu o scurgere de memorie sau un proces în buclă infinită) poate **lipsă alți containere de resurse sau bloca întreaga gazdă** (fără memorie), făcând gazda instabilă.

Setarea **limitelor de resurse** (memorie și CPU) previne acest lucru prin **izolarea consumului de resurse al containerelor**, asigurând că un container nu poate duce jos alții sau gazda — esențial pentru stabilitate atunci când rulezi mai multe containere pe gazdă (norma în producție).

Înțelegerea modului de setare a **limitelor de memorie** (cu containerul ucis din cauza OOM dacă depășește limita hard) și **limitelor de CPU**, plus **rezervări** (garantând minime), este mecanismul practic pentru controlul și partajarea echitabilă a resurselor.

Cunoașterea modului de **monitorizare și ajustare** — folosind `docker stats` pentru a observa utilizarea reală și a redimensiona limitele, recunoscând `OOMKilled` (un container atingând limita sa de memorie) pentru a diagnostica problemele — este importantă pentru stabilirea limitelor corespunzătoare pe baza necesităților reale.

Aceasta se conectează, de asemenea, la orchestrare: **Kubernetes folosește cereri/limite de resurse similare** care sunt esențiale pentru planificare și stabilitate, deci înțelegerea conceptului se transferă la mediile orchestrate.

Cum rularea mai multor containere fiabil necesită prevenirea contenției de resurse și consumului în buclă infinită, și cum limitele de resurse (limite de memorie și CPU, rezervări, monitorizare) sunt mecanismul pentru izolarea containerelor și protejarea stabilității gazdei, înțelegerea gestionării resurselor containerului este cunoaștere valoroasă și practic importantă pentru implementări de containere în producție — necesară pentru gazdele multi-container stabile și un concept care se extinde direct la mediile orchestrate cum ar fi Kubernetes, unde specificarea resurselor este fundamentală.