Skip to main content
Version: main 🚧

NVIDIA Run:ai

NVIDIA Run:ai schedules and manages artificial intelligence and machine learning workloads across Kubernetes clusters. vCluster provides isolated Kubernetes APIs and flexible GPU-node models for NVIDIA Run:ai tenants.

Platform 4.12 bundles native StackTemplates for NVIDIA Run:ai. The templates coordinate registry setup, ingress, TLS, NVIDIA GPU components, the NVIDIA Run:ai control plane, tenant registration, and cluster agents.

Review verified versions​

ComponentVersion
vCluster Platform4.12
vCluster0.37
Kubernetes1.34
NVIDIA Run:ai2.26

The bundled Apps pin their chart versions. Review the certified bundle for the exact component versions in a Platform patch release.

Choose a deployment model​

ModelControl plane and GPU componentsTenant lifecycleUse case
Dedicated control planeEach tenant cluster runs its own NVIDIA Run:ai control plane and GPU Operator.Deleting the tenant removes its dedicated StackInstance.Independent NVIDIA Run:ai and GPU Operator lifecycles per tenant.
Central control planeOne control plane cluster runs a shared NVIDIA Run:ai control plane and GPU Operator.Each tenant has a separate registration and in-cluster agent Stack.Trusted internal tenants sharing nodes and one control-plane lifecycle.
Shared nodes are for trusted tenants

Shared nodes are a supported, common model for trusted tenants. They give each tenant control-plane, API, and namespace isolation, but tenant workloads share the same kernel and physical nodes. They aren't a security boundary for untrusted tenants with Kubernetes access or arbitrary workload execution. Good fits are development, testing, CI/CD, and internal engineering teams.

Use private nodes for external, resale, regulated, or otherwise untrusted tenant offerings, optionally with vNode for runtime isolation.

NetworkPolicy is an added isolation layer worth enabling even for trusted tenants. vCluster can create the policies for you through policies.networkPolicy, and your control plane cluster's CNI enforces them. Confirm your CNI supports enforcement, since some accept NetworkPolicy resources without acting on them. See the security baseline.

If you accept shared nodes for a trusted-tenant use case, follow the shared-node hardening guide as the required next step.

Both bundled tenant templates use shared control plane cluster nodes by default. The dedicated model separates the NVIDIA Run:ai and GPU Operator lifecycle, but doesn't create private worker nodes. The central model uses disjoint node labels to control which GPU nodes each tenant can see. Labels are scheduling policy, not a runtime security boundary.

Understand dedicated control-plane tenancy​

Use the runai-tenant VirtualClusterTemplate. It creates a tenant cluster and declares a deploy.stacks entry named runai. This entry references the run-ai-dedicated-control-plane StackTemplate. Platform generates the StackInstance name from the tenant cluster name and Stack configuration name.

This model installs ingress-nginx, the NVIDIA GPU Operator, the NVIDIA Run:ai control plane, and the tenant components inside one tenant-cluster lifecycle. The Stack captures the ingress address and registration credentials as task outputs.

Choose this model when each tenant needs an independent NVIDIA Run:ai and GPU Operator lifecycle. It consumes more resources because every tenant runs control-plane and GPU-management components.

Understand central control-plane tenancy​

The central model separates three lifecycles:

  1. run-ai-central-control-plane-host installs shared infrastructure once on the control plane cluster.
  2. run-ai-central-control-plane-registration registers and deregisters one tenant.
  3. run-ai-central-control-plane installs the agent and tenant components inside that tenant cluster.

The runai-tenant-central-control-plane VirtualClusterTemplate creates the registration and tenant StackInstances. Secrets carry registration facts, registry credentials, and certificate trust into the tenant cluster.

Each tenant needs a unique, persistent node-label value. A tenant with no matching nodes sees no GPU capacity. Overlapping tenant labels can let independent schedulers allocate the same GPU.

The central model doesn't provide per-tenant GPU utilization views. DCGM Exporter runs on the control plane cluster, outside each tenant API. GPU allocation still uses the capacity on synced Node objects.

Plan TLS and ingress​

The dedicated template can derive a nip.io hostname after its ingress LoadBalancer receives an IPv4 address. The central host template reuses an existing ingress-nginx LoadBalancer.

Both models default to a self-signed certificate authority. Use a certificate for a domain you control in production. The central host and tenant Stack must agree about whether a private certificate authority is required.

Get started​