Bạn quản lý tài nguyên container (CPU và bộ nhớ) như thế nào?

Question

Accepted Answer

Mặc định, các container có thể dùng **tài nguyên host không giới hạn** — điều này có nguy cơ một container làm các container khác đói tài nguyên hoặc làm crash host. Docker cho phép bạn đặt **giới hạn tài nguyên** (CPU, bộ nhớ) để kiểm soát mức tiêu thụ, quan trọng cho sự ổn định và chia sẻ tài nguyên công bằng trong production.

## Vấn đề: sử dụng tài nguyên không giới hạn

```text
MẶC ĐỊNH một container có thể tiêu thụ TẤT CẢ CPU và bộ nhớ host có sẵn:
  → một container lỗi/bận (rò rỉ bộ nhớ, vòng lặp chạy mất kiểm soát) có thể làm các container khác đói
    hoặc làm crash toàn bộ host (hết bộ nhớ)
→ Trong production (nhiều container mỗi host), GIỚI HẠN tài nguyên để cô lập chúng.
```

## Đặt giới hạn bộ nhớ và CPU

```bash
# giới hạn bộ nhớ
docker run -m 512m myapp              # giới hạn cứng: 512 MB (container bị kill nếu vượt — OOM)
docker run -m 512m --memory-reservation 256m myapp   # giới hạn mềm + giới hạn cứng

# giới hạn CPU
docker run --cpus="1.5" myapp         # giới hạn ở 1.5 nhân CPU
docker run --cpu-shares=512 myapp     # trọng số tương đối (ưu tiên khi tranh chấp)
```

```yaml
# trong docker-compose.yml (hoặc cho các orchestrator)
services:
  app:
    deploy:
      resources:
        limits:    { cpus: '1.5', memory: 512M }   # tối đa
        reservations: { cpus: '0.5', memory: 256M } # tối thiểu được đảm bảo
```

Giới hạn bộ nhớ (`-m`) giới hạn mức sử dụng (container bị **OOM-kill** nếu nó vượt giới hạn cứng); giới hạn CPU (`--cpus`) giới hạn mức sử dụng CPU. **Reservation** đảm bảo một mức tối thiểu.

## Giám sát và điều chỉnh

```text
✓ docker stats → mức sử dụng CPU/bộ nhớ trực tiếp mỗi container (để định cỡ giới hạn đúng)
✓ Đặt giới hạn dựa trên nhu cầu thực tế của ứng dụng (đo lường, rồi thêm dư địa)
✓ OOMKilled (trong docker inspect) → container chạm giới hạn bộ nhớ → tăng nó hoặc sửa rò rỉ
✓ Các orchestrator (Kubernetes) dùng request/limit tương tự — thiết yếu cho scheduling
```

## Tại sao điều này quan trọng

Hiểu việc quản lý tài nguyên container là quan trọng để **chạy các container một cách đáng tin cậy trong production**, vì vậy đó là kiến thức vận hành có giá trị.

Vấn đề cốt lõi — mặc định, **các container có thể tiêu thụ tất cả tài nguyên host có sẵn** — là một rủi ro thực sự: một container lỗi hoặc bận đơn lẻ (với một rò rỉ bộ nhớ hoặc process chạy mất kiểm soát) có thể làm **các container khác đói tài nguyên hoặc làm crash toàn bộ host** (hết bộ nhớ), làm cho host không ổn định.

Đặt **giới hạn tài nguyên** (bộ nhớ và CPU) ngăn ngừa điều này bằng cách **cô lập mức tiêu thụ tài nguyên của các container**, đảm bảo một container không thể làm hỏng các container khác hoặc host — thiết yếu cho sự ổn định khi chạy nhiều container mỗi host (chuẩn mực trong production).

Hiểu cách đặt **giới hạn bộ nhớ** (với container bị OOM-kill nếu nó vượt giới hạn cứng) và **giới hạn CPU**, cùng với **reservation** (đảm bảo các mức tối thiểu), là cơ chế thực tế để kiểm soát và chia sẻ tài nguyên công bằng.

Biết cách **giám sát và điều chỉnh** — dùng `docker stats` để quan sát mức sử dụng thực tế và định cỡ giới hạn đúng, nhận ra `OOMKilled` (một container chạm giới hạn bộ nhớ của nó) để chẩn đoán các vấn đề — là quan trọng để đặt các giới hạn phù hợp dựa trên các nhu cầu thực tế.

Điều này cũng kết nối với orchestration: **Kubernetes dùng các resource request/limit tương tự** vốn thiết yếu cho scheduling và sự ổn định, nên hiểu khái niệm này chuyển sang các môi trường được orchestrate.

Vì chạy nhiều container một cách đáng tin cậy đòi hỏi ngăn ngừa tranh chấp tài nguyên và tiêu thụ mất kiểm soát, và vì các giới hạn tài nguyên (giới hạn bộ nhớ và CPU, reservation, giám sát) là cơ chế để cô lập các container và bảo vệ sự ổn định của host, hiểu việc quản lý tài nguyên container là kiến thức có giá trị, quan trọng thực tế cho các triển khai container production — cần thiết cho các host đa container ổn định và một khái niệm mở rộng trực tiếp sang các môi trường được orchestrate như Kubernetes, nơi việc đặc tả tài nguyên là nền tảng.