Tại sao autoscaling của Kubernetes thất bại với khối lượng công việc AI và cách DRA khắc phục

Kubernetes từ lâu đã dựa vào sự tách biệt rõ ràng giữa bộ lập lịch (scheduler), chịu trách nhiệm đặt các pod lên các node hiện có, và bộ tự động mở rộng quy mô (autoscaler), chịu trách nhiệm thêm các node mới khi hết dung lượng. Sự phân công lao động này hoạt động tốt cho tính toán tiêu chuẩn nhưng hiện đang gặp vấn đề dưới áp lực của các khối lượng công việc AI đòi hỏi cấu trúc liên kết bộ tăng tốc cụ thể. Tính đến tháng 10 năm 2026, cộng đồng đang tích cực thiết kế lại các thành phần này để đảm bảo chúng hiểu thống nhất về các ràng buộc phần cứng.

Chuyện gì đã xảy ra

Trong một thập kỷ, giả định rằng các tài nguyên tính toán phần lớn là có thể thay thế lẫn nhau cho phép bộ lập lịch và bộ autoscaler hoạt động độc lập. Tuy nhiên, các bộ tăng tốc AI như GPU không phải là chung chung; hiệu suất của chúng phụ thuộc rất nhiều vào cách chúng được kết nối với CPU, bộ nhớ và các GPU khác. Một chế độ lỗi phổ biến hiện nay là các pod vẫn ở trạng thái chờ (pending) ngay cả khi cụm dường như còn dung lượng. Bộ autoscaler thêm một node, nhưng bộ lập lịch từ chối nó vì cấu trúc liên kết phần cứng không khớp với các yêu cầu nghiêm ngặt về tính cục bộ của khối lượng công việc.

Vấn đề cốt lõi là bộ autoscaler trả lời câu hỏi "có nên thêm một node hay không", trong khi câu hỏi thực sự là "node được thêm có đúng hình dạng cho công việc hay không". Nếu bộ autoscaler cung cấp một node mà không hiểu rõ cách thức kết nối phức tạp của các bộ tăng tốc, bộ lập lịch sẽ không thể đặt pod. Sự không khớp này khiến dung lượng bộ tăng tốc đắt tiền bị lãng phí và làm chậm trễ các tác vụ suy luận hoặc huấn luyện quan trọng. Cloud Native Computing Foundation (CNCF) nhấn mạnh rằng đây không chỉ là vấn đề đặc thù của nhà cung cấp mà là một thách thức kiến trúc cơ bản trong Kubernetes upstream.

Để giải quyết điều này, cộng đồng đang hướng tới một từ vựng chung cho mô tả phần cứng. Trước đây, Kubernetes coi các bộ tăng tốc là số nguyên đơn giản. Giờ đây, với sự ra mắt của Dynamic Resource Allocation (DRA), các khối lượng công việc có thể gửi các yêu cầu (claims) có cấu trúc, mô tả không chỉ số lượng thiết bị cần thiết mà còn cách các thiết bị đó phải liên quan với nhau và với các giao diện mạng. Điều này cho phép cả bộ lập lịch và các bộ autoscaler nhận biết DRA đánh giá dung lượng bằng cùng các tiêu chí chi tiết.

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

Dynamic Resource Allocation thay đổi mô hình tài nguyên từ một con số đếm thô sang một yêu cầu có cấu trúc. Thay vì yêu cầu bốn GPU, một khối lượng công việc chỉ định rằng nó cần bốn GPU nằm trong cùng một miền NUMA và được kết nối qua các liên kết băng thông cao. Bộ lập lịch đọc trực tiếp các yêu cầu này để đưa ra quyết định đặt chỗ. Quan trọng hơn, các bộ autoscaler nhận biết DRA bắt đầu sử dụng thông tin tương tự khi mô phỏng các bổ sung dung lượng tiềm năng. Điều này đảm bảo rằng khi bộ autoscaler quyết định mở rộng quy mô, nó chọn các loại node thực sự thỏa mãn các ràng buộc cấu trúc liên kết do khối lượng công việc xác định.

Ngoài cấu trúc liên kết, DRA còn cho phép chia sẻ bộ tăng tốc ở mức độ chi tiết hơn. Các thiết bị hiện đại đủ mạnh để việc gán toàn bộ một GPU cho một tác vụ nhỏ là lãng phí. DRA hỗ trợ các thiết bị có thể phân vùng, cho phép một bộ tăng tốc vật lý duy nhất được chia thành các phiên bản cô lập hoặc các phần dùng được (consumable shares). Nhiều khối lượng công việc có thể lấy các phần đo lường được của một thiết bị đồng thời. Bộ lập lịch theo dõi các phân bổ phân số này, và các bộ autoscaler có thể cân nhắc các node tiềm năng dựa trên các lát cắt khả dụng thay vì chỉ toàn bộ thiết bị. Điều này giảm thiểu lãng phí kiểu "tất cả hoặc không gì cả" vốn từng gây khó khăn cho việc sử dụng GPU.

Bất chấp những tiến bộ này, vẫn còn khoảng trống đối với gang scheduling (lập lịch nhóm), nơi một nhóm pod phải được lập lịch cùng nhau hoặc không được lập lịch. Các API lập lịch nhận biết khối lượng công việc hiện tại cho phép bộ lập lịch giữ các pod cho đến khi toàn bộ nhóm có thể được đặt, nhưng bộ autoscaler vẫn suy luận theo từng pod. Nó có thể cung cấp dung lượng một phần cho một vài thành viên của nhóm, lãng phí tài nguyên trong khi công việc chờ đợi phần còn lại. Một cơ chế tạm thời gọi là provisioning request cố gắng thu hẹp khoảng cách này bằng cách cho phép các khối lượng công việc yêu cầu dung lượng nhóm một cách nguyên tử, nhưng nó vẫn là một giải pháp ghép nối thêm chứ không phải một tính năng tích hợp sâu.

Chi tiết chính

• Cấu trúc liên kết quan trọng: Hiệu suất của bộ tăng tốc phụ thuộc vào tính cục bộ, bao gồm các miền NUMA của CPU, đường dẫn PCIe và các liên kết giữa GPU, chứ không chỉ số lượng thiết bị.
• Dynamic Resource Allocation (DRA): Thay thế các yêu cầu tài nguyên dựa trên số nguyên bằng các yêu cầu có cấu trúc mô tả mối quan hệ thiết bị và giao diện mạng.
• Từ vựng chung: DRA cho phép cả bộ lập lịch và bộ autoscaler hiểu các ràng buộc phần cứng giống hệt nhau, giảm thiểu sự không khớp trong việc cấp phát.
• Chia sẻ phân số: DRA hỗ trợ các thiết bị có thể phân vùng và dung lượng dùng được, cho phép nhiều khối lượng công việc chia sẻ hiệu quả một bộ tăng tốc duy nhất.
• Khoảng trống gang scheduling: Trong khi bộ lập lịch hỗ trợ đặt chỗ nhóm nguyên tử, bộ autoscaler vẫn mở rộng quy mô theo từng pod, dẫn đến lãng phí tiềm tàng cho các công việc phân tán lớn.
• Tích hợp trong tương lai: SIG-Autoscaling và SIG-Scheduling đang thiết kế các API để cho phép bộ lập lịch nhìn thấy dung lượng có thể cung cấp và yêu cầu nó một cách rõ ràng.

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

Đối với các đội ngũ kỹ thuật quản lý cơ sở hạ tầng AI, sự không khớp này chuyển đổi trực tiếp thành ngân sách lãng phí và chu kỳ lặp lại chậm hơn. Giờ GPU rất đắt đỏ, và việc chúng ngồi nhàn rỗi do bất đồng giữa lập lịch và cấp phát là một chi phí vận hành đáng kể. Hiểu rằng một pod đang chờ có thể không chỉ báo hiệu thiếu dung lượng khu vực, mà là sự không khớp cấu trúc liên kết, sẽ thay đổi cách các đội gỡ lỗi và tối ưu hóa cụm của họ. Nó chuyển trọng tâm từ việc đơn thuần thêm nhiều node sang đảm bảo rằng các node được thêm tương thích với nhu cầu cấu trúc của khối lượng công việc.

Hơn nữa, xu hướng thiết kế tích hợp có nghĩa là các tính năng Kubernetes trong tương lai sẽ xem xét các hàm ý của autoscaling ngay từ đầu. Thay vì chỉnh sửa lại hỗ trợ autoscaling sau khi một nguyên thủy lập lịch mới được phát hành, cộng đồng đang xây dựng các giao diện cho phép hai vòng điều khiển phối hợp chủ động. Sự tiến hóa này rất quan trọng để hỗ trợ các khối lượng công việc suy luận đột biến và agentic (tác nhân) không thể chịu đựng được độ trễ của khởi động lạnh hoặc các node cấp phát sai. Các đội vận hành bộ tăng tốc hiện nay có lợi ích trong các cuộc thảo luận upstream này, vì các tiêu chuẩn kết quả sẽ xác định hiệu quả của cơ sở hạ tầng của họ trong nhiều năm tới.

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

• Kiểm tra các pod đang chờ: Xác minh xem các pod GPU đang chờ có phải do không khớp cấu trúc liên kết hay không, thay vì cạn kiệt dung lượng thực sự.
• Áp dụng DRA: Di chuyển các khối lượng công việc để sử dụng các yêu cầu Dynamic Resource Allocation nhằm diễn đạt rõ ràng các yêu cầu về cấu trúc liên kết và chia sẻ.
• Kích hoạt lập lịch nhận biết khối lượng công việc: Kiểm thử các API Workload và PodGroup beta để cải thiện hành vi gang scheduling, lưu ý rằng chúng bị tắt theo mặc định.
• Đánh giá khả năng tương thích của autoscaler: Xác minh xem triển khai autoscaler hiện tại của bạn có nhận biết DRA và có thể mô phỏng các ràng buộc cấu trúc liên kết trong quá trình mở rộng quy mô hay không.
• Giám sát sự phân mảnh: Theo dõi các chỉ số sử dụng GPU để xác định lãng phí từ các phân bổ "tất cả hoặc không gì cả" và cân nhắc kích hoạt chia sẻ phân số.
• Tham gia với các SIG: Tham gia các cuộc thảo luận của SIG-Autoscaling và SIG-Scheduling để ảnh hưởng đến thiết kế của các API tích hợp sắp tới.