NVIDIA Workload Map: một định nghĩa chung cho AI workload trên Kubernetes
NVIDIA Workload Map đưa kiến thức về cấu trúc workload ra khỏi adapter riêng cho từng CRD. Một definition có thể giúp scheduler, controller và nền tảng vận hành cùng diễn giải JobSet, Ray, PyTorchJob và nhiều framework AI khác.
Một JobSet có leader và worker có thể rất rõ ràng trong manifest. Nhưng với kubectl, nó hiện ra thành một JobSet, nhiều Job và nhiều Pod tách rời.
Khi cần trả lời các câu hỏi như “đây là workload nào?”, “có bao nhiêu role?”, “đang yêu cầu tổng bao nhiêu GPU?” hay “trạng thái chung là gì?”, đội platform thường phải tự ghép các mảnh đó lại. Và mỗi CRD mới lại có thể kéo theo một adapter mới.
NVIDIA Workload Map hướng tới việc chuẩn hóa chính phần mô tả cấu trúc này, để scheduler, controller và công cụ vận hành có thể hiểu cùng một workload theo cùng một cách.
Điểm nghẽn: mỗi CRD lại cần một adapter
Workload AI phân tán hiếm khi chỉ là một Pod. Nó thường là một cây resource, gồm nhiều nhóm Pod với role, số replica, pod template, trạng thái và quan hệ cha-con khác nhau.
Ví dụ NVIDIA đưa ra là một JobSet gồm một leader và hai worker. Mỗi Job yêu cầu bốn GPU, nên toàn bộ workload yêu cầu 12 GPU. Tuy nhiên, lệnh sau sẽ liệt kê JobSet, các Job và Pod thành những resource riêng:
bash
kubectl get jobset,jobs,pods
Điều này tạo ra một số vấn đề quen thuộc cho đội SRE và platform:
Dashboard có thể nhìn thấy nhiều thành phần thay vì một training workload thống nhất.
Scheduler cần hiểu cách các Pod được nhóm lại để hỗ trợ gang scheduling.
Công cụ quản lý workload cần tổng hợp tài nguyên từ các thành phần.
Controller cần hiểu cấu trúc CRD trước khi thay đổi pod spec, label hoặc annotation.
Framework mới có thể đòi hỏi thêm adapter và một chu kỳ phát hành mới.
Điểm chính của Workload Map không phải thay thế scheduler Kubernetes. Nó tách phần kiến thức về cấu trúc workload khỏi từng consumer, để nhiều công cụ không phải tự viết parser riêng cho cùng một CRD.
Một mô tả chung, nhiều consumer
Workload Map, trước đây có tên Karta, gồm một Kubernetes CRD và thư viện Go để diễn giải definition workload. Dù dự án đổi tên, kind của CRD vẫn là Karta.
Mỗi definition mô tả nơi consumer có thể tìm thấy:
Pod template;
số replica;
trạng thái;
metadata;
quan hệ phân cấp giữa resource gốc và thành phần con.
Catalog của dự án có các definition dựng sẵn cho JobSet, PyTorchJob, RayCluster, RayJob, RayService, KServe, Knative, MPIJob, NVIDIA NIM, LeaderWorkerSet, Milvus, Grove PodCliqueSet và NVIDIA Dynamo.
Với JobSet, root component xác định loại resource và cách diễn giải trạng thái:
yaml
apiVersion: run.ai/v1alpha1
kind: Karta
spec:
structureDefinition:
rootComponent:
name: jobset
kind:
group: jobset.x-k8s.io
version: v1alpha2
kind: JobSet
statusDefinition:
conditionsDefinition:
path: .status.conditions
statusMappings:
running:
byExpression:
expression: "(.status.replicatedJobsStatus // []) | any(.ready > 0 and .active > 0) and all(.failed == 0)"
expectedResult: "true"
completed:
byConditions:
type: Completed
status: "True"
failed:
byConditions:
type: Failed
status: "True"
Phần quan trọng là statusMappings. Theo ví dụ của NVIDIA, JobSet không cung cấp một condition Running đơn giản. Definition dùng biểu thức jq trên replicatedJobsStatus để suy ra trạng thái chạy: có Job sẵn sàng và active, đồng thời không có Job failed.
Các trạng thái riêng của JobSet sau đó được đưa về các nhãn chung như running, completed và failed. Nhờ vậy, consumer có thể làm việc trên một cách diễn giải thống nhất thay vì tự viết logic trạng thái cho từng framework.
JobSet được diễn giải như thế nào
Child component dưới đây mô tả các Job nằm trong JobSet:
yaml
childComponents:
name: replicatedjob
kind: { group: batch, version: v1, kind: Job }
ownerRef: jobset
specDefinition:
podTemplateSpecPath: .spec.replicatedJobs[].template.spec.template
scaleDefinition:
replicasPath: .spec.replicatedJobs[] | .replicas .template.spec.parallelism
instanceIdPath: .spec.replicatedJobs[].name
Có thể đọc definition này như một contract cho consumer:
ownerRef: jobset liên kết Job con với JobSet ở root.
podTemplateSpecPath trỏ đến pod template của từng role.
replicasPath tính số Pod theo replicas parallelism.
instanceIdPath lấy tên role, chẳng hạn leader hoặc worker.
Thay vì xem ba Job là ba đơn vị không liên quan, consumer có thể hiểu chúng là các thành phần của một workload: có role, template Pod và quy mô riêng.
Theo NVIDIA, cùng definition JobSet có thể được Workload Map CLI dùng để inspection, KAI Scheduler dùng cho gang scheduling, và NVIDIA Run:ai dùng để quản lý cũng như hiển thị workload hợp nhất. Elotl Nova cũng sử dụng thông tin này để diễn giải cấu trúc workload và nhu cầu tài nguyên cho các quyết định scheduling đa cluster.
Gợi ý đưa definition vào quy trình platform
Với đội DevOps, definition workload nên được xử lý như IaC: lưu trong Git, có người sở hữu, được review qua pull request và có kế hoạch quay lui nếu mapping không đúng.
Một quy trình tham khảo:
Kiểm kê CRD đang chạy: Xác định framework nào đã có definition trong catalog và framework nào cần definition mới.
Đối chiếu manifest và status thực tế: Kiểm tra pod template, replica, owner reference và condition trên object đang chạy.
Viết definition trong nhánh riêng: Đặc biệt cẩn thận với đường dẫn và biểu thức jq, cũng như logic ánh xạ trạng thái.
Review chéo: Mời người sở hữu framework, scheduler và observability cùng xem xét.
Kiểm tra trước khi áp dụng: Dùng cơ chế validation, dry-run hoặc kiểm tra GitOps mà tổ chức đang có.
Canary với workload phù hợp: Xác nhận tool hiển thị đúng role, replica, tài nguyên và phase trước khi mở rộng phạm vi.
Definition sai vẫn có thể khiến scheduler hoặc dashboard hiểu sai workload. Phần status mapping đặc biệt cần được review kỹ: một Pod active chưa chắc đồng nghĩa workload đang khỏe mạnh theo định nghĩa vận hành của tổ chức.
Dùng AI để review YAML, không thay thế kiểm chứng
AI có thể hỗ trợ chỉ ra đường dẫn đáng nghi, phép tính replica chưa rõ ràng hoặc logic trạng thái cần xác minh. Nhưng kết quả vẫn cần được đối chiếu với schema CRD, manifest và status thật đã được loại bỏ dữ liệu nhạy cảm.
text
Bạn là platform engineer Kubernetes.
Hãy review definition Workload Map/Karta dưới đây cho CRD <group/version/kind>.
Manifest mẫu đã được loại bỏ secret:
<manifestsample>
Status mẫu đã được loại bỏ dữ liệu nhạy cảm:
<statussample>
Definition cần review:
<workloadmapdefinition>
Yêu cầu:
Liệt kê các đường dẫn có thể không khớp schema.
Kiểm tra phép tính replica và cách phân tách role/instance.
Đánh giá mapping running, completed, failed.
Nêu các tình huống failure hoặc scale mà definition có thể diễn giải sai.
Không tạo lệnh áp dụng lên cluster.
Đưa checklist xác minh bằng manifest và status thật trước khi merge.
Không đưa kubeconfig, token, URL nội bộ, manifest chứa biến môi trường nhạy cảm hay Secret vào chatbot khi nhờ AI hỗ trợ review.
Kết luận
Workload Map không loại bỏ sự phức tạp của AI workload trên Kubernetes. Nhưng nó chuyển kiến thức về cấu trúc CRD từ các adapter khó bảo trì sang definition có thể viết, review và áp dụng như manifest.
Nếu đội platform đang phải hỗ trợ nhiều framework AI, giá trị tiềm năng nằm ở chỗ scheduler, controller và dashboard có thể cùng dựa trên một mô tả workload — thay vì mỗi công cụ hiểu một CRD theo một cách khác nhau.