ResourceQuota trong Kubernetes: Khái niệm, Cấu hình và Phương pháp triển khai hiệu quả

Một team vô tình triển khai hàng loạt pod chiếm hết tài nguyên cụm, khiến các team khác không thể deploy thêm bất kỳ ứng dụng nào. Đây chính là vấn đề mà ResourceQuota được sinh ra để ngăn chặn.  Cùng Viettel IDC tìm hiểu rõ hơn ResourceQuota là gì trong bài viết dưới đây.

ResourceQuota là gì?

ResourceQuota là một object của Kubernetes, đặt giới hạn cứng (hard limit) cho tổng mức tiêu thụ tài nguyên, bao gồm CPU, bộ nhớ, dung lượng lưu trữ và số lượng object, trong phạm vi một namespace cụ thể.

Dưới góc nhìn kỹ thuật, ResourceQuota hoạt động như một plugin của Admission Controller bên trong API Server. Khi một ResourceQuota tồn tại trong namespace, Kubernetes sẽ theo dõi liên tục mức sử dụng tích lũy của toàn bộ object bên trong namespace đó. Khi có yêu cầu tạo mới hoặc cập nhật một object, Admission Controller sẽ tính toán tài nguyên sắp tiêu tốn, cộng với tài nguyên đang dùng, và từ chối ngay lập tức (lỗi 403 Forbidden) nếu tổng mức tiêu thụ vượt quá giới hạn đã đặt.

Nói cách khác, nếu một namespace không có ResourceQuota, các team hoặc ứng dụng chạy trong namespace đó có thể tạo ra số lượng pod hoặc yêu cầu tài nguyên gần như không giới hạn, miễn là cụm còn đủ tài nguyên vật lý để đáp ứng. Trong một cụm Kubernetes dùng chung bởi nhiều team, đây rõ ràng là một rủi ro lớn về công bằng tài nguyên và tính ổn định chung.

Vì sao cần ResourceQuota trong cụm Kubernetes dùng chung

Ngăn một namespace chiếm dụng toàn bộ tài nguyên cụm

Trong môi trường nhiều team cùng chia sẻ một cụm Kubernetes, ResourceQuota mang lại một phương thức tiện lợi để phân chia (divvy up) CPU, bộ nhớ và các tài nguyên khác giữa nhiều workload hoặc các nhóm người dùng.

Nếu không có cơ chế giới hạn, một namespace triển khai quá nhiều workload có thể vô tình chiếm dụng phần lớn tài nguyên vật lý của cụm. Điều này dẫn đến tình trạng tranh chấp tài nguyên khốc liệt, khiến các namespace khác không còn đủ tài nguyên để lên lịch pod mới, đồng thời gây ra các vấn đề nghiêm trọng về hiệu suất như Kubernetes CPU throttling (nghẽn CPU).

ResourceQuota giải quyết triệt để vấn đề này bằng cách áp đặt giới hạn mức sử dụng trên phạm vi toàn bộ namespace. Lợi ích của việc quản lý ở cấp độ namespace là rất lớn:

- Ưu tiên tài nguyên chiến lược: Cluster administrators có thể dễ dàng "để dành" sức mạnh tính toán cho các workload quan trọng bằng cách cấp cho namespace của chúng một hạn mức Quota cao hơn.

- Quản lý tập trung: Vì một namespace có thể chứa hàng chục ứng dụng và được chia sẻ bởi nhiều người dùng, việc dùng một cấu hình duy nhất để định hình giới hạn cho toàn bộ các workload bên trong nó giúp tiết kiệm thời gian quản trị đáng kể.

Sự ưu việt so với việc chỉ thiết lập theo từng workload

Nếu không có tính năng ResourceQuota, bạn sẽ buộc phải dùng LimitRange (hoặc cấu hình thủ công trong file YAML) để thiết lập giới hạn cho từng workload riêng lẻ. Dù việc thiết lập Request và Limit cho từng container cũng mang lại kết quả tương tự, nhưng nó đòi hỏi rất nhiều công sức. Bạn phải giám sát từng workload một và luôn phải đảm bảo không quên thiết lập giới hạn mỗi khi có một ứng dụng mới được deploy.

Với ResourceQuota, một file cấu hình duy nhất sẽ tự động áp dụng quy tắc giám sát lên toàn bộ workload đang chạy, bao gồm cả những workload sẽ được thêm vào namespace trong tương lai. Cơ chế bao phủ tự động này chặn đứng mọi rủi ro bỏ sót cấu hình và ngăn chặn hoàn toàn nguy cơ độc quyền tài nguyên.

Bảo vệ control plane khỏi tình trạng quá tải object

Ngoài tài nguyên tính toán, ResourceQuota còn có thể giới hạn số lượng object như pod, secret, service, configmap được phép tồn tại trong một namespace. Đây là lớp bảo vệ quan trọng cho control plane của cụm, tránh tình trạng một controller gặp lỗi logic liên tục tạo ra hàng nghìn object không kiểm soát, gây quá tải cho cơ sở dữ liệu etcd và làm tê liệt toàn bộ hệ thống điều phối của Kubernetes.

Các loại ResourceQuota phổ biến

Compute resource quota

Loại quota phổ biến nhất, giới hạn tổng giá trị requests.cpu, requests.memory, limits.cpu và limits.memory cộng dồn của toàn bộ pod trong namespace. Ngoài ra, ở các môi trường huấn luyện AI hoặc dữ liệu lớn, compute quota còn được dùng để kiểm soát tài nguyên phần cứng chuyên dụng (Extended Resources) như requests.nvidia.com/gpu. Đây là công cụ chính để kiểm soát mức tiêu thụ sức mạnh tính toán ở cấp độ namespace.

Storage quota

Giới hạn tổng dung lượng lưu trữ được yêu cầu (requests.storage) và số lượng PersistentVolumeClaim (PVC) mà namespace được phép tạo. Đặc biệt, bạn có thể phân rã quota theo từng StorageClass. Ví dụ: cho phép tạo tối đa 500Gi với ổ cứng HDD giá rẻ, nhưng chỉ cho phép 50Gi với ổ SSD NVMe đắt đỏ, hữu ích khi cần kiểm soát chi phí lưu trữ hoặc tránh một namespace chiếm dụng quá nhiều dung lượng ổ đĩa hiệu năng cao dùng chung.

Object count quota

Giới hạn số lượng cụ thể của từng loại object như số pod, số service, số secret, số configmap. Loại quota này không liên quan trực tiếp đến tài nguyên tính toán, mà tập trung vào việc kiểm soát số lượng object nhằm bảo vệ control plane như đã đề cập ở phần trước. Thậm chí, việc giới hạn count/services.loadbalancers còn giúp bảo vệ ngân sách trên môi trường Cloud, ngăn chặn việc sinh ra quá nhiều Cloud Load Balancer tính phí.

Mối quan hệ giữa ResourceQuota và LimitRange

Đây là điểm kỹ thuật quan trọng nhất mà nhiều người mới triển khai ResourceQuota thường bỏ qua và gặp lỗi khó hiểu. Khi một namespace đã có ResourceQuota áp dụng cho compute resource (CPU, memory), mọi pod tạo mới trong namespace đó bắt buộc phải khai báo rõ ràng cả request lẫn limit. Nếu một pod được submit mà thiếu khai báo này, API Server sẽ ném ra lỗi HTTP 403 Forbidden, từ chối ngay tại thời điểm tạo, trước khi pod kịp được đưa cho Scheduler để tìm node.

LimitRange chính là công cụ (Mutating Admission Controller) giải quyết vấn đề này. LimitRange cho phép đặt giá trị mặc định sẽ tự động được "bơm" vào container không khai báo resource trước khi đi qua màng lọc ResourceQuota. Đồng thời, nó thiết lập ngưỡng tối thiểu và tối đa cho từng container, ngăn một container đơn lẻ yêu cầu resource vượt quá mức hợp lý.

Ví dụ cấu hình ResourceQuota thực tế

Để hiểu rõ hơn cách thức hoạt động của ResourceQuota, hãy cùng phân tích các kịch bản cấu hình phổ biến nhất dưới đây. Các cấu hình này giới hạn tài nguyên khác nhau trong cùng một namespace giả định là my-namespace.

Ví dụ 1: Giới hạn tài nguyên tính toán (Compute Resources)

Cấu hình dưới đây tập trung vào việc quản lý CPU, đảm bảo rằng tổng tài nguyên yêu cầu (requests) và giới hạn (limits) của toàn bộ Pod không được vượt quá ngưỡng phần cứng cho phép:

Ví dụ 2: Giới hạn tài nguyên lưu trữ (Storage Quotas)

Nếu bạn cần kiểm soát chi phí cho ổ đĩa hoặc ngăn một namespace tạo ra quá nhiều Volume, hãy sử dụng Storage Quota. Cấu hình này giới hạn cả tổng dung lượng lưu trữ lẫn số lượng yêu cầu cấp phát (PVC):

Ví dụ 3: Giới hạn số lượng đối tượng (Object Count Quotas)

Đây là lớp khiên bảo vệ Control Plane cực kỳ hiệu quả, giúp tránh tình trạng rác hệ thống (ví dụ: một vòng lặp tạo ra hàng nghìn Secret không cần thiết):

Ví dụ 4: Giới hạn tài nguyên mở rộng (Extended Resources)

Từ phiên bản 1.10 trở đi, Kubernetes hỗ trợ quản lý các "tài nguyên mở rộng" – tức là các tài nguyên phần cứng đặc thù gắn trên Node (như card đồ họa GPU, FPGA) nhưng không được Kubernetes quản lý trực tiếp như một object thông thường.

Dưới đây là một ví dụ thiết lập hạn ngạch cho việc sử dụng GPU (rất cần thiết cho các môi trường chạy AI/Machine Learning):

Các phương pháp triển khai ResourceQuota hiệu quả

Để tận dụng tối đa sức mạnh của ResourceQuota mà không gây rủi ro đứt gãy dịch vụ, đội ngũ vận hành nên tuân thủ các nguyên tắc vàng sau đây:

- Quy hoạch Namespace có chiến lược: ResourceQuota sẽ trở nên vô nghĩa nếu bạn nhồi nhét tất cả workload vào chung một namespace hoặc vứt chúng rải rác không có tổ chức. Hãy bắt đầu bằng việc thiết lập các namespace theo một logic rõ ràng (ví dụ: chia theo từng team, từng môi trường dev/staging/prod hoặc từng dự án) và gán Quota tương ứng với mức độ quan trọng của chúng.

- Chiến thuật "Khởi đầu rộng rãi, thu hẹp dần" (Start high and scale down): Đừng vội "bóp nghẹt" tài nguyên ngay từ đầu. Nguyên tắc an toàn là hãy đặt hạn mức Quota rộng rãi lúc mới triển khai để ứng dụng chạy ổn định. Sau một thời gian, khi đã có dữ liệu thực tế chứng minh namespace đó không cần nhiều tài nguyên đến vậy, bạn mới tiến hành cắt giảm. Điều này an toàn hơn rất nhiều so với việc cấp thiếu tài nguyên ngay từ đầu và khiến ứng dụng gặp lỗi thắt cổ chai hiệu năng (performance issues).

- Giám sát và điều chỉnh Quota liên tục: Bạn sẽ không bao giờ biết chính xác workload của mình thực sự "ăn" bao nhiêu tài nguyên nếu không giám sát. Thay vì coi ResourceQuota là cấu hình "đặt một lần rồi quên", hãy liên tục theo dõi các chỉ số (metrics) của Kubernetes và tỷ lệ sử dụng quota (quota usage) theo thời gian để tinh chỉnh cho sát với thực tế.

- Luôn thiết lập song song cả Resource Requests và Limits: Để khai thác trọn vẹn giá trị của ResourceQuota, hãy luôn định nghĩa cả giới hạn tối thiểu (Requests) và tối đa (Limits). Nếu chỉ cấu hình một trong hai, bạn đã đánh mất khả năng tạo ra một khoảng (range) sử dụng tài nguyên an toàn. (Lưu ý: Luôn kết hợp cùng LimitRange để tự động gán giá trị mặc định cho các Pod quên khai báo).

- Minh bạch hóa chính sách tài nguyên: Mọi quy định về Quota và LimitRange cần được tài liệu hóa (document) rõ ràng và phổ biến cho cả đội ngũ Developer lẫn Administrator. Khi Developer hiểu rõ "luật chơi" và giới hạn sân chơi của mình, họ sẽ có ý thức tối ưu code hơn thay vì phó mặc hạ tầng cho bộ phận Ops.

Lưu ý đặc biệt khi áp dụng cho Namespace đã có sẵn Workload

Một tình huống thực tế cần hết sức cẩn trọng là khi áp dụng ResourceQuota cho một namespace đã tồn tại nhiều workload đang chạy ổn định. Vì ResourceQuota chỉ kiểm tra điều kiện tại thời điểm tạo mới hoặc cập nhật object, các Pod đang chạy sẵn sẽ không bị ảnh hưởng ngay lập tức (dù tổng mức sử dụng của chúng đã vượt Quota mới).

Tuy nhiên, ở những lần cập nhật tiếp theo (ví dụ: khi thực hiện rolling update cho một Deployment), Pod mới sinh ra sẽ bị hệ thống đối chiếu với Quota hiện hành và có thể bị từ chối cấp phép (lỗi HTTP 403). Do đó, phải luôn khảo sát kỹ mức sử dụng thực tế của hệ thống hiện tại trước khi "ép" Quota mới.

Câu hỏi thường gặp (FAQs) về ResourceQuota

ResourceQuota có ngăn được OOMKilled hay Evicted Pod không? Không trực tiếp, nhưng có tác dụng phòng ngừa gián tiếp. Quota ngăn chặn Node bị overcommit, giảm thiểu rủi ro sinh ra Evicted Pod. Tuy nhiên, nó không thể ngăn OOMKilled nếu một container tự thân nó bị memory leak và chạm ngưỡng limit của chính nó.

Pod bị từ chối do vượt Quota sẽ báo lỗi gì? Quá trình triển khai sẽ thất bại ngay tại API Server với lỗi 403 Forbidden: exceeded quota. Lỗi sẽ chỉ rõ loại tài nguyên nào bị vượt (ví dụ: requested: requests.cpu=1, used: requests.cpu=3.5, limited: requests.cpu=4).

Có thể áp dụng ResourceQuota cho toàn cụm Cluster được không? Không. Theo thiết kế, ResourceQuota chỉ hoạt động ở cấp độ Namespace.

Kết luận

ResourceQuota là công cụ nền tảng để đảm bảo công bằng tài nguyên trong một cụm Kubernetes dùng chung bởi nhiều team, nhưng chỉ thực sự hiệu quả khi được triển khai đúng cách cùng với LimitRange. Hiểu rõ các loại quota, cách quota scope hoạt động dưới Admission Controller, và đặc biệt là mối quan hệ bắt buộc giữa ResourceQuota và LimitRange giúp đội ngũ vận hành tránh được những lỗi từ chối pod khó hiểu, đồng thời xây dựng một chính sách quản trị tài nguyên bền vững theo thời gian.

Việc thiết kế, triển khai và liên tục điều chỉnh ResourceQuota phù hợp với nhu cầu thực tế của từng team đòi hỏi kinh nghiệm vận hành và công cụ giám sát chuyên sâu. Viettel Dedicated Kubernetes Service (vDKS) là dịch vụ Kubernetes chuyên biệt của Viettel IDC, cung cấp hạ tầng cụm Kubernetes được quản lý toàn diện. Đi kèm với khả năng giám sát mức sử dụng tài nguyên theo namespace theo thời gian thực và sự hỗ trợ từ các chuyên gia kỹ thuật, giải pháp này giúp doanh nghiệp triển khai chính sách quản trị tài nguyên hợp lý mà không cần tự xây dựng toàn bộ quy trình giám sát phức tạp từ đầu.

Dịch vụ Viettel Dedicated Kubernetes Service (vDKS) của Viettel IDC: https://viettelidc.com.vn/viettel-kubernetes-service