Bagaimanakah anda mengurus sumber kontena (CPU dan memori)?

Question

Accepted Answer

Secara lalai, kontena boleh menggunakan **sumber hos tanpa had** — yang berisiko menyebabkan satu kontena melaparkan kontena lain atau menyebabkan hos crash. Docker membolehkan anda menetapkan **had sumber** (CPU, memori) untuk mengawal penggunaan, penting untuk kestabilan dan perkongsian sumber yang adil dalam produksi.

## Masalahnya: penggunaan sumber tanpa had

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

## Menetapkan had memori dan 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
```

Had memori (`-m`) mengehadkan penggunaan (kontena akan **dibunuh oleh OOM** jika ia melebihi had keras); had CPU (`--cpus`) mengehadkan penggunaan CPU. **Reservation** menjamin minimum.

## Pemantauan dan penalaan

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

## Mengapa ia penting

Memahami pengurusan sumber kontena adalah penting untuk **menjalankan kontena dengan boleh dipercayai dalam produksi**, jadi ia merupakan pengetahuan operasi yang bernilai.

Isu teras — secara lalai, **kontena boleh menggunakan semua sumber hos yang tersedia** — adalah risiko sebenar: satu kontena yang buggy atau sibuk (dengan memory leak atau proses tidak terkawal) boleh **melaparkan kontena lain atau menyebabkan keseluruhan hos crash** (kehabisan memori), menjadikan hos tidak stabil.

Menetapkan **had sumber** (memori dan CPU) mencegah perkara ini dengan **mengasingkan penggunaan sumber kontena**, memastikan satu kontena tidak boleh menjatuhkan kontena lain atau hos — penting untuk kestabilan apabila menjalankan pelbagai kontena bagi setiap hos (norma dalam produksi).

Memahami cara menetapkan **had memori** (dengan kontena dibunuh oleh OOM jika ia melebihi had keras) dan **had CPU**, ditambah **reservation** (menjamin minimum), adalah mekanisme praktikal untuk mengawal dan berkongsi sumber secara adil.

Mengetahui cara **memantau dan menala** — menggunakan `docker stats` untuk memerhati penggunaan sebenar dan menetapkan had yang tepat, mengenali `OOMKilled` (kontena yang mencapai had memorinya) untuk mendiagnosis isu — adalah penting untuk menetapkan had yang sesuai berdasarkan keperluan sebenar.

Ini juga berkaitan dengan orkestrasi: **Kubernetes menggunakan requests/limits sumber yang serupa** yang penting untuk scheduling dan kestabilan, jadi memahami konsep ini terpindah ke persekitaran berorkestrasi.

Memandangkan menjalankan pelbagai kontena dengan boleh dipercayai memerlukan pencegahan persaingan sumber dan penggunaan tidak terkawal, dan memandangkan had sumber (had memori dan CPU, reservation, pemantauan) adalah mekanisme untuk mengasingkan kontena dan melindungi kestabilan hos, memahami pengurusan sumber kontena adalah pengetahuan bernilai dan penting secara praktikal untuk penempatan kontena produksi — perlu untuk hos berbilang kontena yang stabil dan satu konsep yang terpanjang terus ke persekitaran berorkestrasi seperti Kubernetes, di mana spesifikasi sumber adalah asas.