CPU/memory requests กับ limits ต่างกันอย่างไร และมันส่งผลต่อ scheduling, eviction และ QoS อย่างไร?

Question

IT Interview Practice · Accepted Answer

**Requests** คือสิ่งที่ container ได้รับ *การรับประกัน* (ใช้สำหรับ scheduling); **limits** คือ *เพดาน* ที่มันห้ามเกิน (บังคับใช้ตอน runtime) รวมกันแล้วมันขับเคลื่อนว่า Pod ถูกวางที่ไหน, ถูก throttle หรือถูก kill อย่างไรเมื่อมีแรงกดดัน และ Pod ได้คลาส **Quality of Service (QoS)** ไหน

## Requests เทียบกับ limits

```text
REQUEST → จำนวนที่ถูกจองไว้ (RESERVED) ให้ container SCHEDULER ใช้ผลรวมของ
          request เพื่อตัดสินว่า node มีที่ว่างไหม นี่คือพื้น (floor) ที่รับประกันของคุณ
LIMIT   → ค่าสูงสุด (MAX) ที่ container ใช้ได้ บังคับใช้ตอน runtime:
          CPU เกิน limit    → THROTTLED (ช้าลง ไม่ถูก kill)
          memory เกิน limit → OOM-KILLED (container ถูกยุติ แล้ว restart)
```

```yaml
spec:
  containers:
    - name: app
      image: myapp:1.0
      resources:
        requests:
          cpu: "250m"        # 0.25 ของ core, รับประกัน
          memory: "256Mi"
        limits:
          cpu: "500m"        # อาจ burst ถึง 0.5 core แล้วถูก throttle
          memory: "512Mi"    # เกินค่านี้ → OOMKilled
```

## scheduling ใช้ requests อย่างไร

```text
Node มี 4 CPU / 8Gi ที่จัดสรรได้
Scheduler รวม REQUEST ของ Pod ที่วางแล้ว; Pod ใหม่จะพอดีก็ต่อเมื่อ request ของมัน
ยังพอดีกับส่วนที่เหลือ (LIMIT ไม่ถูกใช้ในการวางตำแหน่ง)
→ ตั้ง request ต่ำเกินไป → node ถูก overcommit, Pod แย่งทรัพยากรกัน
→ ตั้ง request สูงเกินไป → เสียกำลังการรองรับ, Pod ค้าง Pending (ไม่มีอะไรพอดี)
```

## คลาส QoS (ตัดสินลำดับ eviction เมื่อ memory ตึง)

```text
Guaranteed  → requests == limits ทั้ง cpu & memory (ทุก container)
              → ถูก evict เป็นตัวสุดท้าย (ลำดับสูงสุด)
Burstable   → มี requests แต่น้อยกว่า limits (หรือตั้งเพียงบางส่วน)
              → ถูก evict หลัง BestEffort
BestEffort  → ไม่ตั้ง requests หรือ limits เลย
              → ถูก evict เป็นตัวแรกเมื่อ node เหลือ memory น้อย
```

```bash
kubectl describe pod app | grep -i qos    # QoS Class: Guaranteed/Burstable/BestEffort
kubectl top pods                           # การใช้ CPU/memory จริง
kubectl describe node <node>               # ทรัพยากรที่จัดสรรแล้วเทียบกับความจุ
```

## คำแนะนำเชิงปฏิบัติ

```text
✓ ตั้ง memory requests = limits เสมอ เพื่อพฤติกรรมที่คาดเดาได้และปลอดภัยจาก OOM สำหรับแอปสำคัญ
✓ ตั้ง CPU requests ตามความต้องการช่วง steady-state; CPU limits มักปล่อยว่างเพื่อให้ burst ได้
✓ กำหนดขนาดให้พอดีจากการใช้จริง (kubectl top / metrics) — ไม่ใช่เดา
✓ ใช้ LimitRange / ResourceQuota เพื่อบังคับค่าเริ่มต้นที่สมเหตุสมผลต่อ namespace
```

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

Requests และ limits คือวิธีที่ Kubernetes แบ่งปันทรัพยากร node ที่มีจำกัดอย่างเป็นธรรมและคาดเดาได้ ดังนั้นการเข้าใจความแตกต่างและผลของมันจึงเป็นความรู้ด้านประสิทธิภาพและความน่าเชื่อถือที่จำเป็น ประเด็นหลักคือมันมีจุดประสงค์ต่างกัน: **requests** เป็นการจองที่รับประกันซึ่ง **scheduler** ใช้ในการวาง Pod (รวม request เพื่อตัดสินว่า node มีที่ว่างไหม โดยไม่สนใจ limits) ขณะที่ **limits** เป็นเพดานตอน runtime ที่บังคับใช้ต่างกันตามชนิดทรัพยากร — เกิน limit **CPU** จะถูก **throttle** (ช้าลง) แต่เกิน limit **memory** จะทำให้ container ถูก **OOM-kill** แล้ว restart การตั้ง request ผิดมีต้นทุนจริงทั้งสองด้าน: ต่ำเกินไปแล้ว node ถูก overcommit จน Pod อดอาหารกัน; สูงเกินไปแล้วเสียกำลังการรองรับขณะที่ Pod นั่งค้าง Pending เพราะไม่มีอะไรพอดี สามคลาส **QoS** — Guaranteed (requests เท่า limits), Burstable (requests ต่ำกว่า limits) และ BestEffort (ไม่ตั้งอะไร) — ตัดสินลำดับ eviction เมื่อ memory ตึง โดย BestEffort ถูก kill ก่อนและ Guaranteed สุดท้าย ซึ่งคือสิ่งที่คุณต้องเข้าใจเพื่อปกป้อง workload สำคัญ การรู้คำแนะนำเชิงปฏิบัติ (ตั้ง memory requests เท่า limits สำหรับแอปสำคัญ, กำหนดขนาดให้พอดีจากการใช้จริงผ่าน `kubectl top`, บังคับค่าเริ่มต้นด้วย LimitRange/ResourceQuota) เปลี่ยนสิ่งนี้จากทฤษฎีเป็นการวางแผนความจุที่มั่นคง เพราะการตั้งค่าทรัพยากรผิดเป็นหนึ่งในสาเหตุที่พบบ่อยที่สุดของความไม่เสถียร, การเสียเงินเปล่า และ Pod ที่ Pending ใน cluster จริง การเชี่ยวชาญ requests, limits และ QoS จึงเป็นรากฐานของการรัน workload Kubernetes อย่างมีประสิทธิภาพและเสถียร

Requests เทียบกับ limits

scheduling ใช้ requests อย่างไร

คลาส QoS (ตัดสินลำดับ eviction เมื่อ memory ตึง)

คำแนะนำเชิงปฏิบัติ

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

คำถามที่เกี่ยวข้อง