Scheduler trong Kubernetes là gì? Cách Kubernetes quyết định Pod chạy ở đâu

Trong Kubernetes, Pod không tự động chạy ngay sau khi được tạo mà cần được gán vào một node phù hợp trong cluster. Nhiệm vụ này do Kubernetes Scheduler đảm trách, với vai trò quyết định nơi Pod sẽ thực thi. Scheduler giúp phân bổ tài nguyên hợp lý, duy trì tính ổn định và tối ưu hiệu năng hệ thống. Bài viết sau Viettel IDC sẽ phân tích chi tiết cách Scheduler hoạt động, các chiến lược scheduling và những vấn đề thường gặp trong môi trường production.

Scheduler trong Kubernetes là gì?

Scheduler trong Kubernetes là một thành phần thuộc control plane, chịu trách nhiệm quyết định Pod nào sẽ được gán vào node nào trong cluster. Khi một Pod được tạo ra mà chưa được gán node (trạng thái Pending), Scheduler sẽ phân tích trạng thái toàn bộ cluster để lựa chọn node phù hợp nhất cho Pod đó.

Về bản chất, Scheduler không trực tiếp chạy container hay quản lý tài nguyên vật lý. Nhiệm vụ chính của nó là ra quyết định phân bổ dựa trên nhiều yếu tố như tài nguyên còn trống của node, yêu cầu tài nguyên của Pod, các ràng buộc về topology, chính sách ưu tiên và chiến lược vận hành hệ thống.

Scheduler khác với kubelet ở chỗ kubelet chịu trách nhiệm thực thi Pod trên node, còn Scheduler chỉ làm nhiệm vụ quyết định Pod chạy ở đâu. Sau khi Scheduler chọn node và gán Pod vào node đó, kubelet trên node tương ứng mới bắt đầu kéo image và khởi động container.

Trong các hệ thống Kubernetes hiện đại, Scheduler đóng vai trò đặc biệt quan trọng vì nó ảnh hưởng trực tiếp đến hiệu năng, độ ổn định và khả năng mở rộng của toàn bộ cluster.

Scheduler hoạt động như thế nào trong Kubernetes?

Quá trình scheduling trong Kubernetes bắt đầu ngay khi một Pod mới được tạo ra hoặc khi một Pod đang ở trạng thái Pending do chưa có node phù hợp. Scheduler liên tục theo dõi API Server để phát hiện các Pod chưa được gán node và tiến hành xử lý từng Pod một.

Khi Scheduler tiếp nhận một Pod, nó sẽ thu thập thông tin từ nhiều nguồn khác nhau trong cluster. Thông tin này bao gồm trạng thái của các node, tài nguyên còn trống, các Pod đang chạy, các ràng buộc cấu hình trên Pod và node, cũng như các chính sách ưu tiên được khai báo.

Sau khi tổng hợp đầy đủ dữ liệu, Scheduler thực hiện một chuỗi thuật toán để loại bỏ các node không phù hợp, đánh giá các node còn lại và chọn ra node tối ưu nhất cho Pod. Quyết định này được gửi lại API Server dưới dạng một bản ghi binding, chính thức gán Pod vào node đã chọn.

Điểm đáng chú ý là Scheduler không đảm bảo phân phối công bằng tuyệt đối, mà tập trung vào việc thỏa mãn các ràng buộc kỹ thuật và tối ưu theo chiến lược được cấu hình. Vì vậy, cùng một cluster nhưng với cấu hình scheduling khác nhau, kết quả phân bổ Pod có thể hoàn toàn khác.

Các bước scheduling chính của Kubernetes Scheduler

Trong Kubernetes, Scheduler không đưa ra quyết định đặt Pod một cách ngẫu nhiên mà tuân theo một quy trình gồm nhiều bước rõ ràng. Mỗi bước đảm nhiệm một vai trò riêng, từ việc loại bỏ các node không phù hợp, đánh giá mức độ tối ưu của các node còn lại cho đến khi gán Pod vào node được chọn. Ba giai đoạn cốt lõi trong quá trình này lần lượt là Filtering, Scoring và Binding.

- Filtering̣ ̣(Lọc node phù hợp): Filtering là bước đầu tiên và mang tính quyết định trong quá trình scheduling, với mục tiêu thu hẹp danh sách node xuống còn những node thực sự có khả năng chạy Pod. Ở giai đoạn này, Scheduler sẽ kiểm tra tài nguyên khả dụng trên từng node, bao gồm CPU và bộ nhớ, dựa trên giá trị resource requests được khai báo trong Pod. Những node không còn đủ tài nguyên để đáp ứng yêu cầu tối thiểu sẽ bị loại bỏ ngay lập tức.

- Scoring (Chấm điểm node): Sau khi đã lọc xong các node không phù hợp, Scheduler chuyển sang bước Scoring để xác định node nào là lựa chọn tối ưu nhất. Ở giai đoạn này, mỗi node còn lại sẽ được chấm điểm dựa trên nhiều tiêu chí khác nhau, phản ánh mức độ phù hợp của node đối với Pod đang chờ được schedule. Điểm số này thường được tính toán thông qua các thuật toán và plugin scheduling có sẵn trong Kubernetes.

- Binding (Gán Pod vào node): Binding là bước cuối cùng trong quá trình scheduling, nơi Kubernetes Scheduler chính thức gán Pod vào node đã được lựa chọn. Ở bước này, Scheduler gửi một yêu cầu binding thông qua API Server để cập nhật thông tin nodeName trong định nghĩa của Pod. Từ thời điểm này, Pod không còn ở trạng thái Pending mà được xem là đã được schedule thành công.

Các chiến lược scheduling phổ biến trong Kubernetes

Trong thực tế, Kubernetes Scheduler không chỉ đơn thuần chọn node còn trống, mà còn áp dụng nhiều chiến lược khác nhau để phục vụ các mục tiêu vận hành. Tùy vào loại workload và yêu cầu hệ thống, mỗi chiến lược sẽ mang lại lợi ích khác nhau.

Bin packing strategy

Bin packing là chiến lược ưu tiên đóng gói Pod vào một số node nhất định, thay vì phân tán đều trên toàn cluster. Mục tiêu của chiến lược này là tối ưu việc sử dụng tài nguyên, giảm số node đang hoạt động và từ đó tiết kiệm chi phí hạ tầng.

Trong bin packing, Scheduler có xu hướng chọn những node đã có workload, miễn là vẫn còn đủ tài nguyên để chạy Pod mới. Điều này đặc biệt hữu ích trong môi trường cloud, nơi doanh nghiệp muốn giảm số lượng node cần duy trì. Tuy nhiên, bin packing cũng có rủi ro nhất định. Nếu không kiểm soát tốt, việc tập trung quá nhiều Pod vào một node có thể làm tăng nguy cơ quá tải và ảnh hưởng đến tính sẵn sàng của hệ thống khi node gặp sự cố.

Spread strategy

Trái ngược với bin packing, spread strategy hướng tới việc phân tán Pod đều trên các node. Chiến lược này giúp giảm rủi ro khi một node bị lỗi, đồng thời tăng khả năng chịu tải và tính sẵn sàng của ứng dụng.

Spread scheduling thường được áp dụng cho các ứng dụng yêu cầu high availability, nơi việc mất một node không được phép làm gián đoạn toàn bộ dịch vụ. Kubernetes hỗ trợ chiến lược này thông qua các cơ chế như Pod Anti-Affinity và Topology Spread Constraints. Nhược điểm của spread strategy là mức độ sử dụng tài nguyên có thể không tối ưu bằng bin packing, đặc biệt trong các cluster lớn với workload biến động liên tục.

High availability scheduling

High availability scheduling tập trung vào việc đảm bảo ứng dụng vẫn hoạt động ngay cả khi xảy ra lỗi phần cứng hoặc node bị down. Scheduler trong trường hợp này sẽ cố gắng phân bố các Pod thuộc cùng một ứng dụng lên các node khác nhau, thậm chí khác zone hoặc region. Chiến lược này thường kết hợp nhiều cơ chế như Pod Anti-Affinity, ReplicaSet, Deployment và các chính sách topology-aware. Kết quả là hệ thống có khả năng chịu lỗi tốt hơn, nhưng đổi lại là độ phức tạp trong cấu hình và chi phí vận hành cao hơn.

Scheduling cho workload stateful và stateless

Scheduler xử lý workload stateless và stateful theo những cách khác nhau. Với workload stateless như web service hoặc API, Scheduler có nhiều tự do hơn trong việc phân bổ Pod, vì Pod có thể bị thay thế hoặc di chuyển mà không ảnh hưởng đến dữ liệu.

Ngược lại, với workload stateful như database hoặc message queue, Scheduler cần tôn trọng các ràng buộc về dữ liệu, thứ tự khởi tạo và node gắn liền với volume. Trong trường hợp này, Kubernetes thường sử dụng StatefulSet kết hợp với các cấu hình scheduling đặc thù để đảm bảo tính nhất quán.

Scheduler xử lý các tình huống phức tạp như thế nào?

Trong môi trường production, Scheduler thường xuyên phải đối mặt với những tình huống không lý tưởng. Một trong những trường hợp phổ biến nhất là Pod bị Pending trong thời gian dài. Nguyên nhân có thể đến từ việc cluster không còn đủ tài nguyên, hoặc Pod được cấu hình quá nhiều ràng buộc khiến không node nào đáp ứng được.

Khi gặp tình huống này, Scheduler không tự động bỏ qua Pod mà tiếp tục theo dõi và thử schedule lại khi trạng thái cluster thay đổi. Nếu cluster được mở rộng thêm node hoặc workload khác được giải phóng tài nguyên, Pod có thể được schedule thành công.

Một tình huống phức tạp khác là khi cluster sử dụng cơ chế ưu tiên Pod. Trong trường hợp tài nguyên khan hiếm, Scheduler có thể preempt, tức là loại bỏ các Pod có ưu tiên thấp hơn để nhường chỗ cho Pod quan trọng hơn. Đây là một cơ chế mạnh mẽ nhưng cũng tiềm ẩn rủi ro nếu không được cấu hình cẩn thận.

Scheduler cũng đóng vai trò quan trọng trong các hệ thống sử dụng cluster autoscaling. Khi Scheduler không tìm được node phù hợp, autoscaler có thể được kích hoạt để bổ sung node mới, từ đó tạo điều kiện cho Pod được schedule.

Kết luận

Scheduler là một trong những thành phần cốt lõi nhất của Kubernetes, đóng vai trò quyết định trong việc phân bổ workload và tối ưu vận hành cluster. Việc hiểu rõ cách Scheduler hoạt động, các chiến lược scheduling phổ biến và những tình huống phức tạp mà Scheduler phải xử lý sẽ giúp DevOps và kỹ sư hệ thống thiết kế kiến trúc Kubernetes hiệu quả hơn. 

Nếu doanh nghiệp muốn triển khai Kubernetes nhanh chóng, ổn định và tiết kiệm chi phí vận hành, hãy tham khảo dịch vụ Viettel Open Kubernetes Service (vOKS) của Viettel IDC tại đây. Dịch vụ nền tảng Kubernetes giúp các Nhà phát triển phần mềm dễ dàng xây dựng, triển khai, nhân rộng và quản lý các ứng dụng được đóng gói theo hình thái container: 

https://viettelidc.com.vn/viettel-kubernetes-service