Mô phỏng chia sẻ GPU đa thuê bao với Kamaji và HAMi

Các kỹ sư nền tảng thường phải đối mặt với sự đánh đổi khó khăn giữa hiệu quả tài nguyên và tính cô lập của tenant khi quản lý khối lượng công việc GPU. Một buổi trình diễn gần đây bởi Anish Bista cho thấy cách kết hợp Kamaji và HAMi giúp các đội nhóm chia sẻ GPU vật lý một cách an toàn trong khi vẫn duy trì các control plane riêng biệt. Cách tiếp cận này sử dụng phần cứng mô phỏng để xác thực kiến trúc trước khi cam kết đầu tư vào cơ sở hạ tầng đắt đỏ.

Chuyện gì đã xảy ra

Bài viết chi tiết hóa một môi trường phòng thí nghiệm có thể tái tạo được, xây dựng trên một máy chủ Linux duy nhất bằng các container Docker. Mục tiêu là chứng minh rằng hai dự án mã nguồn mở, Kamaji và HAMi, có thể hoạt động cùng nhau để giải quyết vấn đề lãng phí tài nguyên GPU trong các cụm Kubernetes đa thuê bao. Theo truyền thống, việc gán cả một card GPU đầy đủ cho một pod chỉ cần một phần nhỏ bộ nhớ dẫn đến sự lãng phí đáng kể. Ngược lại, việc chia sẻ một cụm giữa nhiều đội nhóm thường dẫn đến tính cô lập yếu kém và rủi ro bảo mật.

Bista đã xây dựng một cụm quản lý (management cluster) sử dụng kind (Kubernetes in Docker) để chạy Kamaji. Trong lớp quản lý này, hai control plane tenant riêng biệt được tạo dưới dạng các pod. Mỗi tenant được cung cấp một node worker riêng, cũng chạy dưới dạng container, tham gia mạng và chạy các thành phần HAMi. Thiết lập bao gồm hai tenant mô phỏng: tenant-a với một NVIDIA A100 mô phỏng và tenant-b với hai card NVIDIA L4 mô phỏng. Phòng thí nghiệm đã vượt qua thành công tám bài kiểm tra, xác nhận rằng mỗi tenant có thể lên lịch các khối lượng công việc GPU theo tỷ lệ mà không nhìn thấy tài nguyên hoặc pods thuộc về tenant kia.

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

Kamaji giải quyết chi phí overhead của control plane bằng cách chạy API server Kubernetes và datastore etcd của từng tenant dưới dạng các pod bên trong một cụm quản lý trung tâm. Điều này loại bỏ nhu cầu về các máy control plane chuyên dụng cho mỗi đội nhóm. Mặt khác, HAMi hoạt động ở cấp độ lập lịch và thiết bị. Nó cho phép các pod yêu cầu các lát cắt cụ thể của GPU, được xác định bởi dung lượng bộ nhớ tính bằng megabyte và phần trăm sức mạnh tính toán, thay vì chiếm giữ toàn bộ card. Điều này cho phép nhiều pod từ các ứng dụng khác nhau cùng tồn tại trên một GPU vật lý đơn lẻ.

Điểm tích hợp quan trọng liên quan đến đường truyền thông giữa API server của tenant và webhook HAMi. Vì API server chạy trong cụm quản lý nhưng webhook nằm trên các node worker của tenant, kết nối phải đi qua một đường hầm Konnectivity. Phòng thí nghiệm đã xác nhận rằng cơ chế proxy ngược này hoạt động chính xác, cho phép API server gọi ngược trở lại môi trường tenant để đưa ra các quyết định lập lịch. Để thử nghiệm điều này mà không cần phần cứng vật lý, tác giả đã sử dụng plugin thiết bị giả lập (mock device plugin) của HAMi, bỏ qua tương tác với driver và đăng ký dung lượng GPU giả thông qua các annotation của node.

Chi tiết chính

• Phòng thí nghiệm chạy trên một máy chủ duy nhất với 4 lõi CPU, 8 GB RAM và 20 GB dung lượng ổ đĩa.
• Tenant-a được cấu hình với một NVIDIA A100 80 GB mô phỏng, trong khi tenant-b có hai card NVIDIA L4 24 GB mô phỏng.
• Mạng IPv6 trong kind gây ra lỗi pool MetalLB, đòi hỏi phải kiểm tra thủ công subnet IPv4 để sửa cấu hình gateway.
• Các pod GPU giả lập ban đầu thất bại do xung đột khóa node (node lock contention) vì plugin giả lập không tự động giải phóng khóa sau khi phân bổ.
• Cần phải chú thích (annotate) thủ công các pod và node để mô phỏng bước hoàn tất của plugin thiết bị trong môi trường giả lập.
• Thiết lập này chứng minh logic kết nối và lập lịch nhưng không xác thực giới hạn bộ nhớ thực tế hay hiệu suất CUDA.

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

Đối với các nhà phát triển phần mềm và kỹ sư nền tảng, kiến trúc này mở ra con đường giảm đáng kể chi phí đám mây liên quan đến các instance GPU. Bằng cách cho phép phân bổ theo tỷ lệ, các tổ chức có thể đóng gói nhiều khối lượng công việc hơn vào ít card hơn, cải thiện tỷ lệ sử dụng mà không hy sinh lợi ích bảo mật của các control plane cô lập. Khả năng kiểm thử toàn bộ stack này bằng phần cứng mô phỏng có nghĩa là các đội nhóm có thể xác thực thiết kế nền tảng và pipeline CI/CD của họ trước khi mua các node GPU đắt tiền.

Hơn nữa, việc tích hợp thành công Kamaji và HAMi chứng minh rằng các yêu cầu đa thuê bao phức tạp không nhất thiết đòi hỏi code dính kết tùy chỉnh (custom glue code) hoặc các giải pháp độc quyền. Việc sử dụng các đường hầm tiêu chuẩn như Konnectivity đảm bảo rằng control plane có thể quản lý an toàn các node worker phân tán. Tính mô-đun này cho phép các đội nhóm áp dụng các công cụ này một cách tăng dần, bắt đầu bằng mô phỏng và chuyển sang phần cứng sản xuất với sự tự tin vào cơ chế lập lịch nền tảng.

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

• Tái tạo môi trường phòng thí nghiệm sử dụng kind và Kamaji để kiểm thử tính cô lập control plane đa thuê bao trên phần cứng cục bộ.
• Sử dụng plugin thiết bị giả lập của HAMi để xác thực các chính sách lập lịch và logic quota mà không cần GPU NVIDIA vật lý.
• Kiểm tra thủ công các subnet mạng Docker nếu bạn gặp các vấn đề liên quan đến IPv6 với MetalLB trong các cụm kind.
• Triển khai các bước giải phóng khóa thủ công trong môi trường kiểm thử để bỏ qua các hạn chế của plugin giả lập trong quá trình phát triển.
• Xác minh kết nối đường hầm Konnectivity giữa các API server của cụm quản lý và webhook của node worker tenant.
• Lên kế hoạch tích hợp plugin thiết bị thật sớm, vì các thiết lập giả lập không thực thi các giới hạn bộ nhớ hoặc sức mạnh tính toán thực tế.