Kubernetes v1.32 kích hoạt QueueingHint để tối ưu hóa thông lượng lập lịch pod

Trong một bài đăng trên Kubernetes Blog vào tháng 12 năm 2024, Kensei Nakada từ Tetrate.io đã trình bày chi tiết về một cải tiến nội bộ quan trọng đối với scheduler của Kubernetes được giới thiệu trong phiên bản 1.32. Bản cập nhật này ổn định và mặc định bật cơ chế QueueingHint, một tính năng được thiết kế để giảm tải xử lý không cần thiết cho scheduler bằng cách quản lý thông minh thời điểm thử lại các pod không thể lập lịch.

Chuyện gì đã xảy ra

Scheduler của Kubernetes chịu trách nhiệm gán các Pod mới vào các node trong cụm. Nó xử lý các Pod này theo tuần tự, nghĩa là khi các cụm trở nên lớn hơn, thông lượng của scheduler trở thành một nút thắt cổ chai hiệu suất nghiêm trọng. Trong nhiều năm qua, nhóm SIG Scheduling của Kubernetes đã triển khai nhiều cải tiến khác nhau để nâng cao thông lượng này. Cải tiến lớn gần nhất, bao gồm trong Kubernetes v1.32, giới thiệu một thành phần ngữ cảnh lập lịch gọi là QueueingHint.

Trước bản phát hành này, scheduler quản lý các Pod chưa được lập lịch bằng ba cấu trúc dữ liệu nội bộ: ActiveQ dành cho các Pod mới hoặc sẵn sàng thử lại, BackoffQ dành cho các Pod đang chờ hết thời gian backoff sau các lần thử thất bại, và Unschedulable Pod Pool (Hồ chứa Pod không thể lập lịch) dành cho các Pod hiện tại không thể được lập lịch. Khi một Pod thất bại trong chu kỳ lập lịch, nó thường chuyển sang Unschedulable Pod Pool. Scheduler chỉ di chuyển các Pod này trở lại ActiveQ hoặc BackoffQ nếu có những thay đổi cụ thể trong cụm có thể giải quyết lỗi lập lịch.

Trước đây, logic xác định sự kiện cụm nào có thể giải quyết lỗi khá rộng và thường kém hiệu quả. Các plugin đăng ký các sự kiện cụm chung, chẳng hạn như tạo hoặc xóa đối tượng, thông qua EnqueueExtensions. Nếu bất kỳ sự kiện đã đăng ký nào xảy ra, scheduler sẽ thử lại Pod, ngay cả khi sự kiện đó không liên quan đến lý do cụ thể gây ra lỗi trước đó. Ngoài ra, một tính năng nội bộ gọi là preCheck đã cố gắng lọc các sự kiện dựa trên các ràng buộc cốt lõi, nhưng nó không mở rộng được cho các plugin tùy chỉnh và thiếu độ chính xác.

Cách thức hoạt động

QueueingHint tinh chỉnh cơ chế thử lại này bằng cách cho phép mỗi plugin đăng ký các sự kiện cụm cụ thể và đưa ra quyết định chi tiết về việc liệu một sự kiện đầu vào có thực sự làm cho một Pod cụ thể trở nên khả thi để lập lịch hay không. Thay vì thử lại rộng rãi một Pod mỗi khi bất kỳ sự kiện đã đăng ký nào xảy ra, scheduler giờ đây hỏi plugin liên quan xem thay đổi cụ thể đó có quan trọng hay không.

Ví dụ, hãy xem xét một Pod tên là pod-a yêu cầu một Pod affinity cụ thể. Nếu plugin InterPodAffinity từ chối pod-a vì không có node hiện có nào khớp với Pod, pod-a sẽ đi vào Unschedulable Pod Pool. Scheduler ghi nhận rằng InterPodAffinity là nguyên nhân gây ra sự từ chối. Với QueueingHint, plugin InterPodAffinity đăng ký cập nhật nhãn Pod. Nếu một Pod đang chạy nhận được bản cập nhật nhãn mà giờ đây khớp với yêu cầu affinity của pod-a, callback QueueingHint của plugin sẽ phát hiện sự khớp này và nhắc scheduler di chuyển pod-a trở lại ActiveQ hoặc BackoffQ. Nếu bản cập nhật nhãn không khớp, Pod vẫn nằm trong hồ chứa, tiết kiệm một chu kỳ lập lịch.

Tính năng này đã được phát triển kể từ Kubernetes v1.28. Ban đầu nó được bật mặc định nhưng đã bị tắt trong một bản vá do báo cáo về rò rỉ bộ nhớ. Giữa v1.28 và v1.31, các cộng tác viên đã sửa lỗi rò rỉ bộ nhớ và triển khai QueueingHints trên tất cả các plugin in-tree. Trong v1.32, tính năng này một lần nữa được bật mặc định, với việc triển khai hoàn tất và các vấn đề về độ ổn định đã được giải quyết.

Chi tiết chính

• Phiên bản: Tính năng QueueingHint được bật mặc định trong Kubernetes v1.32.
• Cơ chế: QueueingHint cho phép các plugin đánh giá các sự kiện cụm cụ thể để quyết định xem một Pod không thể lập lịch có nên được thử lại hay không.
• Vấn đề trước đó: Các phương pháp cũ sử dụng đăng ký sự kiện rộng rãi, dẫn đến các lần thử lại lập lịch không cần thiết cho các Pod vẫn không thể lập lịch.
• Khả năng mở rộng: Khác với tính năng preCheck cũ, QueueingHint có khả năng mở rộng và hoạt động với các plugin tùy chỉnh, giải quyết vấn đề #110175.
• Lịch sử: Tính năng này được giới thiệu dưới dạng thử nghiệm trong v1.28, bị tắt do rò rỉ bộ nhớ và được ổn định qua các phiên bản tiếp theo.
• Thành phần: Tối ưu hóa nhắm vào hàng đợi lập lịch, cụ thể là việc di chuyển các Pod giữa Unschedulable Pod Pool và ActiveQ/BackoffQ.

Tại sao điều này quan trọng

Đối với các kỹ sư quản lý cụm Kubernetes quy mô lớn, thông lượng của scheduler ảnh hưởng trực tiếp đến tốc độ triển khai ứng dụng và mức độ sử dụng tài nguyên. Mỗi lần scheduler cố gắng đặt một Pod không có cơ hội được lập lịch, nó tiêu tốn chu kỳ CPU và thêm độ trễ vào quá trình xử lý các Pod đang chờ khác. Bằng cách loại bỏ các lần thử lại vô ích, QueueingHint giảm bớt gánh nặng tính toán lên control plane.

Tối ưu hóa này đặc biệt có giá trị đối với các cụm có yêu cầu lập lịch phức tạp, chẳng hạn như những cụm sử dụng nhiều quy tắc Pod affinity hoặc anti-affinity. Trong các môi trường như vậy, các Pod thường xuyên đi vào Unschedulable Pod Pool. Nếu không có logic thử lại chính xác, scheduler có thể đánh thức các Pod này lặp đi lặp lại cho những thay đổi cụm không liên quan, tạo ra nhiễu và làm chậm việc lập lịch các Pod khả thi. QueueingHint đảm bảo rằng chỉ những thay đổi có ý nghĩa mới kích hoạt việc thử lại, giữ cho đường ống lập lịch hiệu quả.

Hơn nữa, khả năng mở rộng của QueueingHint mang lại lợi ích cho các nhà phát triển viết plugin lập lịch tùy chỉnh. Trước đây, các plugin tùy chỉnh không thể tận dụng khả năng lọc hiệu quả của preCheck, buộc chúng phải dựa vào các trigger sự kiện rộng hơn và kém hiệu quả hơn. Giờ đây, các plugin tùy chỉnh có thể triển khai logic QueueingHint riêng, đảm bảo chúng tích hợp liền mạch với cơ chế thử lại đã được tối ưu hóa của scheduler. Điều này dẫn đến hiệu suất nhất quán hơn trên cả quy trình lập lịch tiêu chuẩn và tùy chỉnh.

Bạn có thể làm gì

• Nâng cấp các cụm thử nghiệm của bạn lên Kubernetes v1.32 để quan sát hành vi QueueingHint đã được ổn định.
• Xem xét các plugin lập lịch tùy chỉnh để đảm bảo chúng triển khai các callback QueueingHint cho việc xử lý sự kiện chính xác.
• Giám sát các chỉ số của scheduler để thấy tỷ lệ thử lại giảm và thông lượng cải thiện trong các kịch bản tải cao.
• Kiểm tra các mẫu sử dụng bộ nhớ còn sót lại nếu trước đây bạn gặp vấn đề với triển khai thử nghiệm v1.28.
• Tham khảo tài liệu của Kubernetes SIG Scheduling để hướng dẫn chi tiết về việc triển khai QueueingHint trong các plugin tùy chỉnh.
• Đánh giá hiệu suất cụm trước và sau khi nâng cấp để định lượng mức giảm các chu kỳ lập lịch không cần thiết.