คุณจัดการทรัพยากรของ container (CPU และ memory) อย่างไร?

Question

Accepted Answer

โดยค่าเริ่มต้น container สามารถใช้ **ทรัพยากรของ host ได้ไม่จำกัด** — ซึ่งเสี่ยงที่ container หนึ่งจะแย่งทรัพยากรจากตัวอื่นหรือทำให้ host crash Docker ให้คุณตั้ง **resource limits** (CPU, memory) เพื่อควบคุมการใช้งาน ซึ่งสำคัญต่อความเสถียรและการแบ่งปันทรัพยากรอย่างเป็นธรรมใน production

## ปัญหา: การใช้ทรัพยากรแบบไม่จำกัด

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

## การตั้งค่า limit ของ memory และ 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
```

Limit ของ memory (`-m`) จำกัดการใช้งาน (container จะถูก **OOM-kill** หากเกิน hard limit) ส่วน limit ของ CPU (`--cpus`) จำกัดการใช้ CPU ส่วน **reservations** รับประกันค่าต่ำสุด

## การ monitor และปรับจูน

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

## ทำไมจึงสำคัญ

การเข้าใจการจัดการทรัพยากรของ container เป็นเรื่องสำคัญสำหรับ **การรัน container อย่างน่าเชื่อถือใน production** ดังนั้นจึงเป็นความรู้เชิงปฏิบัติงานที่มีคุณค่า

ประเด็นหลัก — โดยค่าเริ่มต้น **container สามารถใช้ทรัพยากรของ host ทั้งหมดที่มี** — เป็นความเสี่ยงจริง: container ที่มีบั๊กหรือทำงานหนักเพียงตัวเดียว (ที่มี memory leak หรือ process ที่วนไม่หยุด) สามารถ **แย่งทรัพยากรจาก container อื่นหรือทำให้ host ทั้งเครื่อง crash** (out of memory) ทำให้ host ไม่เสถียร

การตั้ง **resource limits** (memory และ CPU) ป้องกันเรื่องนี้โดยการ **แยกการใช้ทรัพยากรของแต่ละ container ออกจากกัน** เพื่อให้มั่นใจว่า container หนึ่งจะไม่ทำให้ตัวอื่นหรือ host ล่ม — เป็นเรื่องจำเป็นต่อความเสถียรเมื่อรัน container หลายตัวต่อ host (ซึ่งเป็นเรื่องปกติใน production)

การเข้าใจวิธีตั้ง **limit ของ memory** (โดย container จะถูก OOM-kill หากเกิน hard limit) และ **limit ของ CPU** รวมถึง **reservations** (รับประกันค่าต่ำสุด) คือกลไกเชิงปฏิบัติในการควบคุมและแบ่งปันทรัพยากรอย่างเป็นธรรม

การรู้วิธี **monitor และปรับจูน** — ใช้ `docker stats` เพื่อสังเกตการใช้งานจริงและปรับ limit ให้พอดี รวมถึงการจดจำ `OOMKilled` (container ที่ชน memory limit) เพื่อวินิจฉัยปัญหา — เป็นเรื่องสำคัญต่อการตั้ง limit ที่เหมาะสมตามความต้องการจริง

เรื่องนี้ยังเชื่อมโยงกับ orchestration ด้วย: **Kubernetes ใช้ resource requests/limits ที่คล้ายกัน** ซึ่งจำเป็นต่อ scheduling และความเสถียร ดังนั้นการเข้าใจแนวคิดนี้จึงถ่ายโอนไปยังสภาพแวดล้อมแบบ orchestrated ได้

เนื่องจากการรัน container หลายตัวอย่างน่าเชื่อถือต้องป้องกันการแย่งทรัพยากรและการใช้ทรัพยากรแบบไม่จำกัด และเนื่องจาก resource limits (การจำกัด memory และ CPU, reservations, การ monitor) คือกลไกในการแยก container และปกป้องความเสถียรของ host การเข้าใจการจัดการทรัพยากรของ container จึงเป็นความรู้ที่มีคุณค่าและสำคัญในทางปฏิบัติสำหรับการ deploy container ใน production — จำเป็นต่อ host ที่รันหลาย container อย่างเสถียร และเป็นแนวคิดที่ขยายต่อไปยังสภาพแวดล้อมแบบ orchestrated อย่าง Kubernetes ได้โดยตรง ซึ่งการกำหนดทรัพยากรเป็นเรื่องพื้นฐาน