Miten hallinnoit kontin resursseja (CPU ja muisti)?

Question

Accepted Answer

Oletusarvoisesti kontit voivat käyttää **rajattomat isäntäkoneen resurssit** — mikä riskeissä yhden kontin nälkiintymisen muita tai isäntäkoneen kaatumisen. Docker antaa sinun asettaa **resurssirajat** (CPU, muisti) kulutuksen hallintaan, mikä on tärkeää vakauden ja oikeudenmukaisen resurssijaon kannalta tuotannossa.

## Ongelma: rajoittamaton resurssin käyttö

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

## Muistin ja CPU-rajoitusten asettaminen

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

Muistirajat (`-m`) rajoittavat käyttöä (kontti **OOM-dödätään**, jos se ylittää kovan rajan); CPU-rajat (`--cpus`) rajoittavat CPU-käyttöä. **Varatut resurssit** takaavat vähimmäismäärän.

## Seuranta ja säätäminen

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

## Miksi tämä on tärkeää

Kontin resurssihallinnan ymmärtäminen on tärkeää **konttien luotettavalle käyttämiselle tuotannossa**, joten se on arvokas operatiivinen tieto.

Ydinongelmaa — oletusarvoisesti **kontit voivat kuluttaa kaikki saatavilla olevat isäntäkoneen resurssit** — on todellinen riski: yksittäinen viallinen tai kuormitettu kontti (muistin vuotolla tai juoksevalla prosessilla) voi **nälkiintää muita kontteja tai kaataa koko isäntäkoneen** (muisti loppui), mikä tekee isäntäkoneen epävakaaksi.

**Resurssirajat** asettaminen (muisti ja CPU) estää tämän **eristämällä konttien resurssin kulutuksen**, varmistaen, että yksi kontti ei voi kaataa muita tai isäntäkonetta — olennaista vakaudelle, kun useita kontteja ajetaan per isäntä (normaali tuotannossa).

Ymmärtäminen kuinka asettaa **muistirajat** (kontti OOM-dödätään, jos se ylittää kovan rajan) ja **CPU-rajat**, plus **varatut resurssit** (vähimmäisen takaaminen), on käytännöllinen mekanismi resursseista hallitsemiselle ja oikeudenmukaiselle jakamiselle.

Ymmärtäminen kuinka **seurata ja säätää** — käyttäen `docker stats` todellisen käytön havaitsemiseen ja rajoitusten oikeaan mitoitukseen, tunnistamalla `OOMKilled` (kontti, joka osuu muistirajaalleen) ongelmien diagnosointiin — on tärkeä sopivien rajoitusten asettamisessa todellisten tarpeiden perusteella.

Tämä yhdistyy myös orkestointiin: **Kubernetes käyttää samanlaisia resurssi-pyyntöjä/rajoja**, jotka ovat olennaisia ajoittamiselle ja vakaudelle, joten konseptin ymmärtäminen siirtyy orkestroiduille ympäristöille.

Koska useiden konttien luotettava ajaminen vaatii resurssikilpailun ja juoksevan kulutuksen estämisen, ja koska resurssirajat (muistin ja CPU-rajat, varatut resurssit, seuranta) ovat mekanismi konttien eristämiselle ja isäntäkoneen vakauden suojaamiselle, kontin resurssihallinnan ymmärtäminen on arvokas, käytännöllisesti tärkeä tieto tuotannon kontti-käyttöönotoille — välttämätöntä vakaille monikon-kontin isäntäkoneille ja konsepti, joka ulottuu suoraan orkestroituihin ympäristöihin kuten Kubernetes, jossa resurssin määrittäminen on perustavaa.