PENALGO

Giao diện

Resource Requests, Limits & QoS ​

Trong Kubernetes, tài nguyên (CPU & RAM) là tiền bạc. Nếu bạn không kiểm soát mức tiêu thụ, một ứng dụng tồi ("Noisy Neighbor") có thể kéo sập cả hệ thống.

💡 Metaphors for Understanding

  • CPU = Pin (Battery): Có thể "bóp" (throttle) dòng điện nếu dùng quá nhiều. Ứng dụng sẽ chạy chậm lại, nhưng KHÔNG CHẾT.
  • RAM = Cái xô nước (Hard Bucket): Nước đầy xô mà đổ thêm thì tràn. Không thể nén nước được. Nếu dùng quá giới hạn -> OOM Kill (Trảm ngay lập tức).

1. The "Noisy Neighbor" Problem ​

Tưởng tượng bạn có một Node 8GB RAM.

  • App A (Web) đang chạy êm ả với 2GB.
  • App B (AI Worker) đột nhiên memory leak, ăn sạch 6GB còn lại và đòi thêm nữa.
  • Hệ quả: Hệ điều hành bị thiếu RAM trầm trọng. Nó buộc phải kích hoạt OOM Killer (Out Of Memory Killer) và bắn bỏ bất kỳ process nào ngốn RAM nhất (thường là App B, nhưng đôi khi xui xẻo bắn nhầm App A).

Để tránh tình trạng "Hàng xóm ồn ào" này, K8s cung cấp cơ chế Requests & Limits.

2. Requests vs Limits (Crucial) ​

yaml
resources:
  requests:
    memory: "64Mi"  # Cam kết tối thiểu
    cpu: "250m"     # 1/4 Core
  limits:
    memory: "128Mi" # Giới hạn tối đa
    cpu: "500m"     # 1/2 Core

Requests: "Lời hứa của Scheduler" ​

  • Ý nghĩa: "Tôi cần ít nhất chừng này để sống".
  • Tác dụng: Kubernetes Scheduler dùng số này để tìm Node. Nếu Node còn trống 60Mi mà bạn Request 64Mi -> Pod sẽ Pending (không nhét vừa).
  • Runtime: Sau khi chạy, nếu app dùng ít hơn request -> Không sao.

Limits: "Cảnh sát trật tự" ​

  • Ý nghĩa: "Ngươi không được phép vượt qua ngưỡng này".
  • Tác động với CPU (Compressible): Nếu app dùng quá CPU Limit -> K8s sẽ Throttle (bóp băng thông). App chạy chậm như rùa nhưng vẫn sống.
  • Tác động với RAM (Non-compressible): Nếu app dùng quá RAM Limit -> Kernel sẽ Kill container ngay lập tức (OOMKilled).

3. Class of Service (QoS) ​

Dựa trên cách bạn đặt Request và Limit, K8s chia Pod thành 3 giai cấp. Khi Node bị cạn kiệt tài nguyên, K8s sẽ ưu tiên giết ai trước?

🥇 Guaranteed (Hạng Nhất) ​

  • Cấu hình: Requests == Limits (cho cả CPU và RAM).
  • Đặc quyền: Được bảo vệ kỹ nhất. Chỉ bị giết khi Node thực sự sụp đổ.
  • Ví dụ: Database chính, Core Payment Service.

🥈 Burstable (Hạng Phổ thông) ​

  • Cấu hình: Requests < Limits.
  • Đặc điểm: Cho phép "bùng nổ" (burst) tài nguyên khi cần, nhưng nếu Node hết chỗ, bạn sẽ bị giết trước bọn Hạng Nhất.
  • Ví dụ: Web Server, API (Lượng traffic không ổn định).

🥉 Best Effort (Hạng Bét - Cỏ rác) ​

  • Cấu hình: Không đặt Requests cũng chẳng có Limits.
  • Số phận: Chạy được thì chạy. Khi Node hơi thiếu tài nguyên tí xíu -> Bị giết ĐẦU TIÊN không thương tiếc.
  • Ví dụ: Dev/Test pods, script nghịch ngợm.

4. HPN Production Policy 🛡️ ​

⛔ STRICT ENFORCEMENT

Tại HPN, mọi Pod triển khai lên Production BẮT BUỘC phải có settings Request & Limits. CẤM TUYỆT ĐỐI triển khai Pod dạng Best Effort.

Lý do:

  1. Predictability: Chúng ta cần biết Cluster chịu được bao nhiêu Pod.
  2. Stability: Để tránh việc một Pod dev-test vớ vẩn làm sập Database Production vì ăn hết RAM.

Quy tắc vàng:

  • Set Requests dựa trên mức sử dụng trung bình (Average).
  • Set Limits cao hơn khoảng 20-50% để chịu tải đỉnh (Peak), nhưng đừng set quá cao (tránh overcommit ảo).

Professional Engineering Standards | © 2025 HPN Corporation