CPU/memory requests và limits khác nhau thế nào, và chúng ảnh hưởng ra sao đến scheduling, eviction và QoS?

Question

IT Interview Practice · Accepted Answer

**Requests** là thứ một container được *đảm bảo* (dùng cho scheduling); **limits** là *trần* nó không được vượt qua (áp đặt lúc runtime). Cùng nhau chúng quyết định Pod được đặt ở đâu, bị throttle hay bị giết ra sao khi thiếu tài nguyên, và Pod nhận lớp **Quality of Service (QoS)** nào.

## Requests so với limits

```text
REQUEST → lượng được ĐẶT TRƯỚC cho container. SCHEDULER dùng tổng các request để
          quyết định node còn chỗ không. Đây là sàn được đảm bảo của bạn.
LIMIT   → mức TỐI ĐA container được dùng. Áp đặt lúc runtime:
          CPU vượt limit    → THROTTLE (bị làm chậm, không bị giết)
          memory vượt limit → OOM-KILL (container bị chấm dứt, rồi restart)
```

```yaml
spec:
  containers:
    - name: app
      image: myapp:1.0
      resources:
        requests:
          cpu: "250m"        # 0.25 core, được đảm bảo
          memory: "256Mi"
        limits:
          cpu: "500m"        # có thể bung tới 0.5 core, rồi bị throttle
          memory: "512Mi"    # vượt cái này → OOMKilled
```

## Scheduling dùng requests ra sao

```text
Node có 4 CPU / 8Gi phân bổ được.
Scheduler cộng các REQUEST của Pod đã đặt; một Pod mới chỉ vừa nếu request của nó
vẫn lọt vào phần còn lại. (Limit KHÔNG dùng để đặt chỗ.)
→ Đặt request quá thấp → node bị overcommit, Pod tranh giành tài nguyên.
→ Đặt request quá cao → lãng phí năng lực, Pod kẹt Pending (không gì vừa).
```

## Các lớp QoS (quyết định thứ tự eviction khi thiếu memory)

```text
Guaranteed  → requests == limits cho CẢ cpu & memory (mọi container)
              → bị evict cuối cùng (ưu tiên cao nhất)
Burstable   → có requests nhưng nhỏ hơn limits (hoặc đặt một phần)
              → bị evict sau BestEffort
BestEffort  → không đặt requests hay limits gì cả
              → bị evict ĐẦU TIÊN khi node cạn memory
```

```bash
kubectl describe pod app | grep -i qos    # QoS Class: Guaranteed/Burstable/BestEffort
kubectl top pods                           # mức dùng CPU/memory thực tế
kubectl describe node <node>               # tài nguyên đã cấp so với năng lực
```

## Hướng dẫn thực tế

```text
✓ Luôn đặt memory requests = limits để hành vi dự đoán được, an toàn OOM cho app quan trọng
✓ Đặt CPU requests bằng nhu cầu ổn định; CPU limits thường bỏ trống để cho phép bung (burst)
✓ Định cỡ đúng từ mức dùng thực (kubectl top / metrics) — đừng đoán
✓ Dùng LimitRange / ResourceQuota để áp mặc định hợp lý cho từng namespace
```

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

Requests và limits là cách Kubernetes chia sẻ tài nguyên node hữu hạn một cách công bằng và dự đoán được, nên hiểu sự phân biệt và hệ quả của nó là kiến thức hiệu năng và độ tin cậy thiết yếu. Điểm cốt lõi là chúng phục vụ mục đích khác nhau: **requests** là phần đặt trước được đảm bảo mà **scheduler** dùng để đặt Pod (cộng request để quyết định node còn chỗ, bỏ qua limit), còn **limits** là trần runtime được áp đặt khác nhau theo từng loại tài nguyên — vượt limit **CPU** thì bị **throttle** (làm chậm), nhưng vượt limit **memory** thì container bị **OOM-kill** và restart. Đặt request sai gây tổn thất thật ở cả hai phía: quá thấp thì node bị overcommit nên các Pod bỏ đói nhau; quá cao thì lãng phí năng lực trong khi Pod ngồi Pending vì không gì vừa. Ba lớp **QoS** — Guaranteed (requests bằng limits), Burstable (requests dưới limits), và BestEffort (không đặt gì) — quyết định thứ tự eviction khi thiếu memory, với BestEffort bị giết trước và Guaranteed cuối cùng, đúng thứ bạn cần hiểu để bảo vệ workload quan trọng. Biết các hướng dẫn thực tế (đặt memory requests bằng limits cho app quan trọng, định cỡ đúng từ mức dùng thực qua `kubectl top`, áp mặc định bằng LimitRange/ResourceQuota) biến điều này từ lý thuyết thành lập kế hoạch năng lực vững chắc. Vì cấu hình tài nguyên sai là một trong những nguyên nhân phổ biến nhất gây bất ổn, lãng phí chi phí và Pod Pending trong các cluster thật, thành thạo requests, limits và QoS là điều nền tảng để chạy workload Kubernetes hiệu quả và ổn định.

Requests so với limits

Scheduling dùng requests ra sao

Các lớp QoS (quyết định thứ tự eviction khi thiếu memory)

Hướng dẫn thực tế

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

Câu hỏi liên quan