Hogyan kezelsz container erőforrásokat (CPU és memória)?

Question

Accepted Answer

Alapértelmezésben a containerek **korlátlan host erőforrásokat** használhatnak — amely veszélyezteti, hogy egy container megfosztsa másokat vagy összeomlik a host. A Docker lehetővé teszi **erőforrás-limitek** (CPU, memória) beállítását a felhasználás szabályozásához, ami fontos a stabilitás és a fair erőforrás-megosztás szempontjából az üzemi környezetben.

## A probléma: korlátlan erőforrás-használat

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

## Memória és CPU limitek beállítása

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

A memória limitek (`-m`) korlátozódnak (a container **OOM-killt** ha meghaladja a kemény limitet); CPU limitek (`--cpus`) korlátozzák a CPU-használatot. **Foglalások** garantálnak egy minimumot.

## Monitorozás és hangolás

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

## Miért fontos

A container erőforrás-kezelés megértése fontos az **containerek megbízható üzemeltetéséhez az üzemi környezetben**, ezért értékes operációs tudás.

Az alapvető probléma — alapértelmezésben az **containerek az összes elérhető host erőforrást felhasználhatják** — valódi kockázat: egyetlen hibás vagy elfoglalt container (memória szivárgás vagy szaladó folyamat miatt) **megfoszthat más containereket vagy összeomoltathatja az egész hostot** (memória kifogyása), ami instabillá teheti a hostot.

Az **erőforrás limitek** (memória és CPU) beállítása megelőzi ezt az **containerek erőforrás-felhasználásának elkülönítésével**, biztosítva, hogy egy container ne omolthassa össze másokat vagy a hostot — elengedhetetlen a stabilitáshoz több container futtatása esetén per host (ez a norma az üzemi környezetben).

A **memória limitek** beállításának megértése (a containerrel OOM-killolt, ha meghaladja a kemény limitet) és **CPU limitek**, valamint **foglalások** (minimumok garantálása) a praktikus mechanizmus az erőforrások szabályozásához és fair megosztásához.

Annak ismerete, hogyan kell **monitorozni és hangolni** — a `docker stats` használata a tényleges használat megfigyelésére és limitek megfelelő méretezésére, az `OOMKilled` felismerése (container elérte memória limitét) a problémák diagnosztizálásához — fontos a limitek megfelelő beállításához a valódi igények alapján.

Ez összekapcsolódik az orchestrációval: **a Kubernetes hasonló resource kéréseket/limiteket használ**, amelyek elengedhetetlenek a scheduling és stabilitás szempontjából, ezért a koncepció megértése átkerül az orchestrált környezetekre.

Szinceén több container megbízható üzemeltetéséhez szükséges az erőforrás-konfliktus és szaladó felhasználás megelőzése, és mivel az erőforrás limitek (memória és CPU sapkák, foglalások, monitorozás) az containerek elkülönítésének és a host stabilitásának védelme mechanizmusa, a container erőforrás-kezelés megértése értékes, gyakorlatilag fontos tudás az üzemi container üzemeltetésekhez — szükséges a stabil multi-container hostokhoz és egy koncepció, amely közvetlenül kiterjed az orchestrált környezetekre, mint a Kubernetes, ahol az erőforrás specifikáció alapvető.