GPU Pod Pending trên Kubernetes: khi scheduler và autoscaler lệch nhau
Pod AI Pending không phải lúc nào cũng do hết GPU. Kubernetes đang thu hẹp khoảng trống giữa scheduler và autoscaler bằng DRA, provisioning request và các cơ chế nhận biết workload.
Một cụm Kubernetes có accelerator chưa được tận dụng hết, nhưng pod AI vẫn ở trạng thái Pending. Autoscaler có thể đã thêm node, song node đó lại không đáp ứng topology hoặc cách chia sẻ tài nguyên mà scheduler cần để đặt workload.
Đây không phải lúc nào cũng là chuyện “hết GPU”. Với workload AI, scheduler và autoscaler có thể hiểu khác nhau về một node “phù hợp”. Hệ quả là cụm vẫn mở rộng, nhưng job chưa chạy được và phần cứng đắt tiền có thể bị bỏ phí.
Hai control loop, một mô hình phần cứng chưa thống nhất
Kubernetes vốn phân chia trách nhiệm rõ ràng:
Scheduler đặt pod lên những node đã tồn tại.
Autoscaler bổ sung node khi pod không thể được đặt.
Mô hình này phù hợp với nhiều workload truyền thống, nơi năng lực tính toán tương đối thay thế được cho nhau. Nhưng accelerator khiến bài toán phức tạp hơn một con số tài nguyên đơn giản.
Một workload có thể phụ thuộc vào:
CPU và bộ nhớ trong cùng miền NUMA;
NIC có quan hệ gần với accelerator qua đường PCIe;
liên kết băng thông cao giữa nhiều accelerator;
vị trí phần cứng từ bên trong máy chủ đến rack và mạng trung tâm dữ liệu.
Vì vậy, một node có “đủ số GPU” chưa chắc đã là node scheduler có thể dùng cho pod. Nếu autoscaler thêm một kiểu node không tương thích với yêu cầu placement, pod vẫn Pending dù capacity dường như vẫn còn.
> Khi điều tra pod Pending, câu hỏi không chỉ là còn bao nhiêu accelerator, mà là accelerator còn lại có đúng topology, đúng cách chia sẻ và đúng dạng capacity mà workload yêu cầu hay không.
DRA: mô tả nhu cầu phần cứng thay vì chỉ đếm thiết bị
Dynamic Resource Allocation (DRA) bổ sung cách mô tả tài nguyên có cấu trúc hơn. Thay vì chỉ yêu cầu một số lượng accelerator, workload có thể tạo claim thể hiện nhu cầu phần cứng và các quan hệ giữa chúng, chẳng hạn accelerator cùng NIC cấp dữ liệu cho accelerator đó.
Scheduler có thể đọc các claim này để đưa ra quyết định placement. Autoscaler có hỗ trợ DRA cũng bắt đầu sử dụng cùng thông tin khi mô phỏng liệu một node mới có đáp ứng workload hay không. Tuy nhiên, mức hỗ trợ vẫn tùy thuộc từng implementation.
DRA đặc biệt liên quan đến hai vấn đề của cụm accelerator.
Topology: không chỉ là số lượng GPU
Topology mô tả cách thiết bị kết nối với CPU, bộ nhớ, NIC và accelerator khác. Với các workload chạy qua nhiều accelerator hoặc nhiều máy chủ, độ gần phần cứng và liên kết giữa thiết bị có thể ảnh hưởng trực tiếp đến khả năng chạy hiệu quả.
Trước đây, Kubernetes thường biểu diễn accelerator dưới dạng số lượng: node quảng bá một số thiết bị, pod yêu cầu một số thiết bị, scheduler ghép hai con số này. DRA hướng tới việc bổ sung ngữ cảnh mà cách biểu diễn đó còn thiếu.
Sharing: sử dụng thiết bị theo phần nhỏ hơn
Một accelerator hiện đại có thể quá lớn đối với một workload nhỏ. Tài liệu CNCF nêu hai hướng chia sẻ:
Partitionable devices: chia một thiết bị thành các phần cô lập cố định.
Consumable capacity: cho phép nhiều workload sử dụng các phần dung lượng được đo lường từ cùng một thiết bị.
Consumable capacity khác với time-slicing của runtime. Đây là mô hình biểu diễn capacity có thể cấp phát, trong đó scheduler theo dõi allocation trực tiếp. Autoscaler có hỗ trợ DRA có thể dùng mô hình này khi cân nhắc capacity cần bổ sung.
Việc chia nhỏ cũng có thể tạo ra các phần dung lượng còn dư. Tuy vậy, kích thước cấp phát tối thiểu và bước cấp phát hợp lý có thể giúp giảm lãng phí so với mô hình cấp trọn thiết bị cho từng workload.
Reservation cũng là một phần của quyết định scale-up
Khi accelerator khan hiếm và chi phí cao, tổ chức có thể cam kết hoặc giữ trước capacity. Trong trường hợp đó, autoscaler không chỉ cần quyết định có mở rộng hay không, mà còn cần cân nhắc node mới có sử dụng phần capacity đã được cam kết hay không.
Điểm này cho thấy autoscaling cho accelerator không đơn thuần là thêm node. Nó phải đánh giá node nào thực sự phù hợp với workload và với nguồn capacity mà tổ chức đã chuẩn bị.
Gang scheduling: ngôn ngữ chung vẫn chưa đủ
DRA giúp scheduler và autoscaler dùng chung mô tả phần cứng. Nhưng dùng chung “ngôn ngữ” không đồng nghĩa hai control loop sẽ hành động như một.
Ví dụ rõ nhất là gang scheduling: một job lớn cần toàn bộ pod được đặt cùng lúc, hoặc không pod nào nên chạy. Nếu chỉ đặt được một phần pod, job có thể không thực hiện được nhưng vẫn giữ tài nguyên.
Kubernetes đang phát triển workload-aware scheduling, trong đó API Workload và PodGroup ở trạng thái beta upstream và bị tắt mặc định. Cơ chế này giúp scheduler xem một nhóm pod như đơn vị all-or-nothing, tránh tình huống một phần job được đặt còn phần còn lại chờ vô thời hạn.
Tuy nhiên, autoscaler chưa tự động có cùng cách suy luận. Nó vẫn có thể phản ứng theo từng pod, thêm một hoặc vài node cho một phần thành viên của nhóm, trong khi tổng capacity vẫn không đủ để khởi động cả job.
Provisioning request là cầu nối hiện tại
Cơ chế provisioning request cho phép workload yêu cầu capacity cho cả một nhóm thay vì để autoscaler phản ứng từng pod.
Khi admission check được cấu hình, Kueue có thể:
Reserve quota;
Tạo provisioning request;
Chờ capacity được báo là sẵn sàng;
Admit workload.
Cách làm này giúp kết nối admission, quota và provisioning cho workload theo nhóm. Tuy nhiên, scale-up nguyên tử vẫn là cơ chế best effort và phụ thuộc vào hỗ trợ của provider.
Nói cách khác, provisioning request là cầu nối qua ranh giới giữa scheduler và autoscaler, chưa phải một cơ chế hợp nhất hoàn toàn hai bên.
Điều cần theo dõi khi vận hành workload AI
Với đội hạ tầng chạy GPU hoặc accelerator chuyên dụng, điểm cần chú ý là mức độ thống nhất giữa scheduler và autoscaler:
Workload có yêu cầu topology hoặc claim DRA hay không?
Autoscaler đang dùng có hiểu các claim đó khi chọn node mới không?
Capacity được thêm vào có phù hợp với reservation đã cam kết không?
Workload có cần gang scheduling hay không?
Chuỗi hỗ trợ từ workload-aware scheduling, provisioning request, Kueue đến autoscaler đã đầy đủ chưa?
Nếu câu trả lời khác nhau giữa các thành phần, scale-out có thể vẫn xảy ra nhưng pod vẫn Pending.
Kết luận: quản lý một mô hình phần cứng, không phải hai danh sách tài nguyên
Vấn đề không hẳn là scheduler hay autoscaler làm sai phần việc của mình. Accelerator đã biến capacity thành bài toán có topology, cơ chế chia sẻ và ràng buộc theo nhóm workload — trong khi hai control loop có thể chưa hiểu những ràng buộc đó theo cùng một cách.
DRA đang giúp tạo ngôn ngữ chung cho scheduler và autoscaler. Provisioning request cùng Kueue hỗ trợ một phần bài toán cấp phát theo nhóm. Nhưng khi pod AI bị Pending, đừng mặc định rằng cluster đã hết capacity: hãy kiểm tra liệu scheduler và autoscaler có đang cùng nhìn thấy một node khả dụng hay không.