Cảm giác vận hành một hệ thống Kubernetes nhìn rất mượt: có autoscaling, workload được chia nhỏ, deploy nhanh, rollback dễ, monitoring cũng có đủ dashboard. Nhưng khi cầm hóa đơn cloud trên tay rồi soi lại mức sử dụng thực tế, câu chuyện thường khác hẳn :Đ
Nhiều hệ thống hiện nay chỉ dùng một phần nhỏ CPU và Memory so với mức đã bỏ tiền ra mua (tôi thấy khá nhiều luôn). Với GPU thì vấn đề còn chát hơn, vì một con GPU để không tốn kém hơn CPU rất nhiều.
Số liệu từ Cast AI cho thấy một thực tế: GPU trung bình chỉ dùng khoảng 5%, CPU khoảng 8%, và memory khoảng 20%. Kubernetes giúp anh em điều phối workload tốt thật, nhưng nó không thể tự sửa những lỗi sai trong cấu hình của mình được.
Vấn đề không nằm ở Kubernetes, mà nằm ở cách chúng ta vận hành
Có bác nghĩ chỉ cần đưa workload lên Kubernetes là xong, hệ thống sẽ tự scale cần thiết và… tiết kiệm tiền cho mình… Nhưng thực tế, Kubernetes chỉ cung cấp nền tảng. Còn việc request bao nhiêu CPU, limit memory thế nào, chọn node size ra sao hay autoscaling theo chỉ số gì, tất cả vẫn là trách nhiệm của chúng ta tự cấu hình.
Lỗi hay gặp nhất là chúng ta thường đặt resource request cao hơn nhiều so với nhu cầu thực tế để đảm bảo an toàn. Ví dụ: Một service thực tế chỉ dùng 200 millicore, nhưng mình lại cấu hình tận 2 core cho chắc cóp. Khi chạy hàng chục services như vậy, cluster nhìn thì có vẻ đang gánh nhưng thực tế CPU vẫn ở mức thấp.
Với memory cũng vậy. Vì sợ ứng dụng bị OOMKilled, nhiều người set request memory cao hơn nhu cầu thật rất nhiều. Scheduler của Kubernetes sẽ đặt pod dựa trên request, không dựa trên mức sử dụng thật tại thời điểm đó dẫn đến việc tài nguyên bị khóa trên giấy trong khi vật lý thì không dùng đến.
GPU là nơi lãng phí dễ bị bỏ qua
Lãng phí CPU thì hóa đơn tăng, nhưng lãng phí GPU là chuyện khác vì chi phí rất cao.
Tôi thấy nhiều team chạy AI/ML trên Kubernetes nhưng chưa có thói quen đo GPU utilization một cách nghiêm túc. Có job chiếm nguyên GPU nhưng chỉ dùng vài phần trăm. Có notebook chạy xong nhưng không tắt. pod vẫn giữ tài nguyên dù training job đã thất bại.
Với GPU, đừng hỏi là có đủ hay không, mà hãy hỏi là mình đã dùng nó hiệu quả chưa. Một GPU không chạy vẫn tính tiền theo giờ; nếu anh em không có cảnh báo hay cơ chế dọn dẹp workload nhàn rỗi, chi phí sẽ tăng rất nhanh.
Bài học 1: Đừng cấu hình resource bằng cảm giác
Anh em đừng nên đặt request và limit theo cảm tính hay kinh nghiệm cũ. Mỗi service cần có dữ liệu thực tế.
Cách làm thực tế là quan sát workload trong khoảng 7 đến 14 ngày, tính cả giờ cao điểm, rồi mới điều chỉnh request và limit dựa trên con số thực tế.
Ví dụ:
| Loại tài nguyên | Cách nên làm |
|---|---|
| CPU request | Dựa trên mức dùng ổn định trong giờ bình thường |
| CPU limit | Cẩn thận khi đặt quá thấp vì dễ gây throttling |
| Memory request | Dựa trên mức dùng thực tế cộng thêm biên an toàn |
| Memory limit | Cần có nhưng phải tránh bóp chết ứng dụng trong giờ cao điểm |
| GPU | Phải đo utilization, memory GPU, thời gian idle và thời gian job chạy thật |
Điều quan trọng là phải review định kỳ. Resource đúng hôm nay chưa chắc còn đúng sau 3 tháng.
Bài học 2: HPA không giải quyết được mọi thứ
Horizontal Pod Autoscaler rất hữu ích, nhưng nhiều team dùng HPA rồi nghĩ rằng mình đã tối ưu. Thực tế HPA chỉ tăng giảm số pod. Nếu mỗi pod request tài nguyên quá cao, scale down vẫn không giải quyết được phần lãng phí gốc.
Ngoài ra, HPA thường dựa trên CPU hoặc custom metrics. Nếu metric không phản ánh đúng tải thật, hệ thống sẽ chạy sai. Có service CPU thấp nhưng queue đang nghẽn. Có service CPU cao vì code không tối ưu, scale thêm pod chỉ làm tốn tiền hơn. Tối ưu chi phí cần kết hợp thêm nhiều công cụ:
Cần kết hợp thêm:
| Công cụ hoặc cơ chế | Mục đích |
|---|---|
| VPA | Gợi ý request phù hợp hơn |
| Cluster Autoscaler hoặc Karpenter | Tự động thêm bớt node |
| ResourceQuota | Giới hạn tài nguyên theo namespace |
| LimitRange | Đặt mặc định request và limit |
| Pod Disruption Budget | Giữ ổn định khi scale hoặc thay node |
| Monitoring chi phí | Gắn tài nguyên với tiền thật |
Bài học 3: Namespace nào cũng cần Resource Quota
Một sai lầm tôi gặp nhiều là chỉ kiểm soát production, còn dev, staging, sandbox thì để tự do. Nhưng chính các môi trường này thường gây lãng phí nhiều nhất.
Developer tạo môi trường test rồi quên xóa. Data scientist tạo notebook GPU rồi để qua đêm. QA chạy load test xong không dọn. Một team thử nghiệm vài service mới nhưng request tài nguyên như production.
Tôi thường đề xuất mỗi namespace phải có quota rõ ràng. Không phải để làm khó đội phát triển, mà để mọi người có ý thức rằng tài nguyên cloud là tiền thật.
Ví dụ:
| Namespace | nên có |
|---|---|
| production | Quota cao hơn, kiểm soát chặt, cảnh báo sớm |
| staging | Quota vừa đủ, tự động tắt workload không cần thiết |
| development | Quota thấp, có TTL cho môi trường tạm |
| data science | Quota GPU riêng, bắt buộc có owner và thời gian hết hạn |
| sandbox | Giới hạn nghiêm ngặt, không cho chạy tài nguyên lớn nếu không có lý do |
Bài học 4: Autoscaling node phải đi cùng rightsizing pod
Nhiều người bật autoscaling node và nghĩ cluster sẽ tự tối ưu. Nhưng nếu pod request quá cao, autoscaler sẽ phải tạo thêm node dù tài nguyên thực tế vẫn còn nhiều.
Ví dụ một node có 8 CPU. Nếu mỗi pod request 4 CPU nhưng thực tế chỉ dùng 300 millicore, node chỉ chứa được 2 pod theo scheduler. Cluster Autoscaler nhìn thấy không đủ chỗ cho pod mới và tạo thêm node. Hóa đơn tăng, nhưng CPU thực tế vẫn thấp.
Vì vậy, muốn autoscaling node hiệu quả thì phải làm đúng từ pod request trước. Rightsizing pod là nền tảng. Autoscaling node chỉ là bước tiếp theo.
Bài học 5: GPU workload cần policy riêng
Không nên quản lý GPU giống CPU. GPU đắt hơn, ít linh hoạt hơn và dễ bị giữ tài nguyên lâu hơn.
Với GPU workload, tôi thường muốn có các quy tắc sau:
| Chính sách | Lý do |
|---|---|
| Bắt buộc khai báo owner | Biết ai chịu trách nhiệm khi workload idle |
| Bắt buộc khai báo mục đích | Tránh dùng GPU cho việc không cần GPU |
| Có thời gian hết hạn cho job thử nghiệm | Tránh pod tồn tại nhiều ngày không ai để ý |
| Cảnh báo khi GPU utilization thấp | Phát hiện workload chiếm GPU nhưng không dùng |
| Tách node pool GPU riêng | Dễ kiểm soát chi phí và scheduling |
| Ưu tiên job queue thay vì cấp GPU tự do | Tăng tỷ lệ sử dụng GPU |
Nếu đội làm AI và ML tăng nhanh, phần này càng cần làm sớm. Khi số lượng GPU còn ít, mọi người thường xử lý thủ công được. Khi số lượng tăng lên, vận hành thủ công sẽ trở thành điểm gây lãng phí lớn.
Bài học 6: Minh bạch chi phí
Một dashboard CPU đẹp không đủ. Một dashboard memory đẹp cũng không đủ. Chúng ta cần nhìn thấy chi phí.
Tôi thích cách hiển thị chi phí theo namespace, team, service và environment. Khi một team thấy service của mình đang tiêu tốn bao nhiêu mỗi ngày, hành vi sẽ thay đổi rất nhanh.
Không nên biến tối ưu chi phí thành việc riêng của FinOps hoặc quản lý. Người viết code và người vận hành hệ thống cần thấy tác động tài chính từ quyết định kỹ thuật của mình.
Một thay đổi nhỏ như giảm request CPU từ 2 core xuống 500 millicore cho 100 pod có thể tiết kiệm rất nhiều tiền mỗi tháng. Nhưng nếu không ai nhìn thấy con số tiền, việc tối ưu thường bị xem là việc phụ.
Bài học 7: Đừng tối ưu bằng cách làm hệ thống ép tài nguyên
Tối ưu tài nguyên không có nghĩa là ép mọi thứ xuống mức thấp nhất. Làm vậy rất dễ tạo sự cố.
Một hệ thống tốt cần cân bằng giữa chi phí, hiệu năng và độ ổn định. Production cần có biên an toàn. Service quan trọng cần đủ tài nguyên để chịu tải tăng bất thường. Database, message broker, ingress controller và workload stateful cần được đánh giá cẩn thận hơn service stateless thông thường.
Điều tôi tránh là tối ưu quá mức. Giảm chi phí 20% nhưng làm tăng rủi ro downtime là một quyết định tệ. Ngược lại, để tài nguyên dư 80-90% trong thời gian dài cũng là một quyết định tệ.
Cách tốt hơn là tối ưu có dữ liệu, có theo dõi sau thay đổi và có khả năng rollback.
Checklist khi review chi phí
Tôi đưa ra đây để anh em nào cần thì dùng nhé, dù biết đến đây là dài phết rồi nhưng mất công viết thì viết cho đầy đủ anh em nào chăm đọc chắc là có thêm được gì đó, mong vậy : )
| Câu hỏi | Vì sao quan trọng |
|---|---|
| Pod nào có request cao nhưng usage thấp | Tìm điểm lãng phí rõ nhất |
| Namespace nào tăng chi phí nhanh nhất | Phát hiện team hoặc môi trường bất thường |
| Node nào idle nhiều giờ | Giảm node hoặc đổi instance type |
| Workload nào chạy ngoài giờ làm việc | Tắt dev và staging khi không cần |
| GPU nào utilization thấp | Xử lý nguồn lãng phí đắt nhất |
| Có pod nào không có owner không | Tránh tài nguyên vô chủ |
| HPA có scale đúng metric không | Tránh scale sai nguyên nhân |
| Có quota cho dev và staging chưa | Ngăn lãng phí lan rộng |
| Có cảnh báo chi phí bất thường chưa | Phát hiện sớm trước khi hóa đơn tăng mạnh |
| Có review resource định kỳ không | Tránh cấu hình cũ kéo dài nhiều tháng |
Kết luận
Kubernetes không đảm bảo tiết kiệm chi phí. Kubernetes chỉ cho chúng ta công cụ để vận hành linh hoạt hơn. Nếu request sai, limit sai, autoscaling sai, quota thiếu và monitoring chi phí không rõ, cluster vẫn sẽ lãng phí rất nhiều.
Theo tôi thì bài học quan trọng nhất là phải coi tài nguyên cloud như một phần của thiết kế hệ thống, không phải phần xử lý sau cùng. Mỗi CPU core, mỗi GB memory, mỗi GPU hour đều cần có lý do tồn tại.
Một team DevOps tốt không chỉ giữ hệ thống chạy ổn. Một team DevOps tốt còn giúp hệ thống chạy đúng nhu cầu, đúng chi phí và đủ an toàn để phát triển lâu dài.
