Bạn đã deploy ứng dụng lên Kubernetes và mọi thứ đều hoạt động ổn.

Nhưng một ngày đẹp trời, có một Pod bất ngờ sử dụng 100% CPU và chiếm gần hết RAM của Node.

Kết quả?

• Các Pod khác bắt đầu chạy chậm.
• Một vài Pod bị Kubernetes "đuổi" khỏi Node.
• Thậm chí cả ứng dụng của bạn có thể bị sập.

Làm thế nào để ngăn chuyện này xảy ra?

Đó là lúc Requests và Limits xuất hiện.

---

Một ví dụ rất đời thường

Hãy tưởng tượng bạn ở trong một căn hộ có 4 phòng ngủ.

Có 4 người cùng thuê nhà.

Nếu không có quy định, một người có thể chiếm luôn 3 phòng, khiến những người còn lại không còn chỗ.

Để tránh điều đó, chủ nhà đặt ra hai quy tắc:

• Bạn được đảm bảo ít nhất 1 phòng.
• Bạn không được chiếm quá 2 phòng.

Kubernetes cũng làm điều tương tự với CPU và Memory.

---

1. Requests là gì?

Requests là lượng tài nguyên Kubernetes cam kết dành cho Pod.

Ví dụ:

resources:
  requests:
    cpu: "500m"
    memory: "256Mi"

Điều này có nghĩa:

• Pod cần tối thiểu 0.5 CPU
• Pod cần tối thiểu 256 MB RAM

Scheduler sẽ chỉ đặt Pod lên những Node còn đủ tài nguyên này.

💡 Hãy nhớ: Requests ảnh hưởng đến việc Pod được đặt ở Node nào.

---

2. Limits là gì?

Limits là mức tài nguyên tối đa Pod được phép sử dụng.

resources:
  limits:
    cpu: "1"
    memory: "512Mi"

Nghĩa là:

• CPU tối đa: 1 core
• RAM tối đa: 512 MB

Nếu Pod cố sử dụng nhiều hơn?

Với CPU

Kubernetes sẽ giới hạn tốc độ sử dụng CPU.

Ứng dụng không bị tắt, nhưng sẽ chạy chậm hơn.

Với Memory

Nếu Pod vượt quá giới hạn RAM, Kubernetes sẽ kill Pod và khởi động lại nếu cần.

Đây là lỗi mà rất nhiều người mới gặp khi ứng dụng bị OOMKilled (Out Of Memory).

---

3. Requests và Limits hoạt động cùng nhau

resources:
  requests:
    cpu: "500m"
    memory: "256Mi"
  limits:
    cpu: "1"
    memory: "512Mi"

Hiểu đơn giản:

• Kubernetes đảm bảo cho Pod 0.5 CPU và 256 MB RAM.
• Pod có thể dùng nhiều hơn khi Node còn dư tài nguyên.
• Nhưng sẽ không bao giờ vượt quá 1 CPU và 512 MB RAM.

---

Tại sao không đặt Limits thật lớn?

Nhiều người mới thường nghĩ:

"Cứ đặt 8 CPU và 16 GB RAM cho chắc."

Điều này lại gây lãng phí.

Scheduler sẽ nghĩ Pod cần rất nhiều tài nguyên và có thể không tìm được Node phù hợp, khiến Pod cứ ở trạng thái Pending.

Hãy đặt giá trị gần với nhu cầu thực tế của ứng dụng.

---

Một số giá trị khởi đầu tham khảo

Loại ứng dụng	Requests	Limits
API nhỏ	100m CPU / 128Mi	500m CPU / 256Mi
Web Backend	250m CPU / 256Mi	1 CPU / 512Mi
Java Spring Boot	500m CPU / 512Mi	2 CPU / 1Gi

Đây chỉ là giá trị tham khảo. Trong thực tế, bạn nên theo dõi ứng dụng bằng công cụ monitoring để điều chỉnh phù hợp.

---

Tổng kết

Chỉ cần nhớ hai câu sau là đủ:

• Requests = Kubernetes đảm bảo lượng tài nguyên tối thiểu cho Pod.
• Limits = Kubernetes giới hạn lượng tài nguyên tối đa Pod được sử dụng.

Hai cấu hình nhỏ này giúp:

• Tránh một Pod chiếm hết tài nguyên của Node.
• Giúp Scheduler phân bổ Pod hợp lý.
• Hạn chế tình trạng ứng dụng bị OOMKilled hoặc làm ảnh hưởng đến các Pod khác.

---

👉 Ở bài tiếp theo, chúng ta sẽ tìm hiểu Horizontal Pod Autoscaler (HPA) – làm thế nào để Kubernetes tự động tăng hoặc giảm số lượng Pod khi lượng truy cập thay đổi, thay vì bạn phải scale thủ công.