NVIDIA Workload Map Targets Kubernetes’ Framework Adapter Problem

Kubernetes workloads are not single pods. Distributed training jobs and multi-node inference servers form small resource trees, with pod groups, roles, replica counts, pod templates, and status fields that vary by workload type.

NVIDIA Workload Map aims to give those structures one shared description. Schedulers, controllers, and platforms can interpret supported workloads without maintaining framework-specific parsing code for every custom resource definition.

That matters because Kubernetes encodes the same basic information in different ways. JobSet, LeaderWorkerSet, and other custom resources often need separate adapters before a tool can interpret or manage them—turning support for every new framework into another development project.

One workload definition instead of another adapter

Operating an AI factory requires a common understanding of distributed workloads: their components, pod templates, replica counts, resource requirements, and status. Teams building schedulers, controllers, dashboards, or cost tools encounter the problem as soon as they must support more than one workload framework.

The NVIDIA Run:ai team faced that challenge while creating its platform. For each new custom resource definition, developers must determine the workload’s structure, decide how its status maps to a phase, and change the pod specification without breaking the workload.

That process produces a per-CRD adapter. Every new framework a customer brings requires another one, making adapter development a roadmap item per framework rather than a one-time cost. Support for a new workload type then waits for a release, because apparently distributed systems needed another queue.

Workload Map addresses this with a Kubernetes CRD and a Go library that interprets workload definitions. Formerly called Karta, Workload Map retains Karta as the CRD’s resource kind.

Each definition specifies where to find pod templates, replica counts, and status fields for its workload type. That gives scheduling and platform consumers a shared structural view instead of forcing each consumer to reconstruct the workload independently.

The project ships prebuilt definitions for JobSet, PyTorchJob, RayCluster, RayJob, RayService, KServe, Knative, MPIJob, NVIDIA NIM, LeaderWorkerSet, Milvus, Grove PodCliqueSet, and NVIDIA Dynamo.

JobSet becomes reusable across the platform

The example centers on a distributed training job submitted as a JobSet. It contains one leader Job and two worker Jobs, with each pod requesting four GPUs—one leader, two workers, and a total request of 12 GPUs.

Without a shared workload description, a platform must reconstruct that structure and total the GPU requests itself. Kubernetes lists the resources separately, and although owner references connect the Jobs to their JobSet, those references alone do not tell a platform how to interpret roles or aggregate resource requests.

Workload Map lets the JobSet definition describe that structure once, then reuse it across several functions. The Workload Map CLI can inspect the workload, KAI Scheduler can use the definition for pod grouping and gang-scheduling instructions, and NVIDIA Run:ai can use it for workload management and visibility.

The same description therefore supports workload inspection, scheduling, and platform operations. Each consumer acts on the shared definition, reducing the need for separate framework-specific parsing code.

Elotl’s Nova uses Workload Map to interpret workload structure and resource requirements for multi-cluster scheduling decisions. That extends the model beyond a single platform: the definition can inform decisions about where distributed workloads should run across clusters.

NVIDIA positions Workload Map as part of the NVIDIA DSX AI Factory Platform, where integrated schedulers, controllers, and platforms can interpret supported workload types through a common format. Kubernetes runs in production at 82% of organizations that use containers, and the Cloud Native Computing Foundation calls it the de facto operating system for AI.

That footprint makes the adapter problem hard to ignore. Workload Map does not remove the complexity of distributed applications, but it gives the systems managing them a shared way to describe what already exists—and that is a more useful promise than another framework-specific integration slide.

Stay connected via Google News

Follow us for the latest AI News