A new framework no longer waits on an adapter: NVIDIA Workload Map describes Kubernetes jobs in one reusable YAML
Synopsis
NVIDIA has moved the structural description of distributed Kubernetes jobs out of adapters compiled into tools and into a readable definition. Workload Map, a custom resource plus a Go library, gives JobSet, PyTorchJob, RayCluster and other frameworks one structural view. Previously each custom resource needed its own adapter to interpret roles, turn status into phases and edit pod templates without breaking the job, so support for a new type often waited for a release. Definitions state template paths, replica counts and status mappings in YAML, shared by schedulers and platforms; a worked JobSet resolves into one leader and two workers totaling 12 GPUs.
Interpretation
Distributed training jobs on Kubernetes can now be read through one shared description rather than only through each framework's own parsing code. The earlier pattern was an adapter per custom resource, answering what the workload's structure is, how its status becomes a phase and how a pod spec can be edited without breaking the job, so adapter work became a roadmap item per framework and support for a new workload type often waited for a release. One JobSet definition is reused by several consumers: a command-line tool renders the live object into leader and worker roles and totals the example's 12-GPU request, KAI Scheduler falls back to it for pod grouping and gang scheduling on types without a native plugin, and NVIDIA Run:ai registers the workload type with a single API call and no extra code.
Each workload type is described by a YAML definition saying which field holds its pod templates, how replica counts are computed, and which shared phase its status maps to. What carries the description is a Kubernetes custom resource plus a Go library that resolves live objects through the definition into a uniform structural view; JobSet never reports a plain running condition, so the definition derives it with an expression over replicated-job status and maps the native completed and failed conditions onto phase names consumers already use. A catalog ships prebuilt, tested definitions for JobSet, PyTorchJob, RayCluster, KServe, MPIJob, LeaderWorkerSet, Milvus, NVIDIA Dynamo and others, and a new type arrives by writing one YAML file describing its structure and status.
Perspective
The demonstrated scope is the supported workload types on Kubernetes: the walkthrough is one JobSet with a leader and two workers, the definitions ship under Apache 2.0 and are used in production inside NVIDIA Run:ai, Elotl's multi-cluster scheduler Nova uses them to read structure and resource requirements when picking a cluster, and a type outside the catalog is added by writing one YAML definition.
The walkthrough covers one JobSet, with the role tree, the 12-GPU total and the grouping all coming from the same definition, while the catalog definitions for other frameworks are not shown at equal detail. KAI Scheduler treats such definitions as a fallback where no native plugin exists and native plugins retain precedence, so grouping and gang scheduling depend on whether the target type already has one.