How to Integrate NVIDIA DGX Station GB300 With Kubernetes and Existing IT Infrastructure

A DGX Station GB300 can join Kubernetes, but it is a partly documented path, so plan it as a project. NVIDIA's GPU Operator lists the DGX Station among its supported Blackwell GPUs. Its Arm platform table, though, names only HGX GB300 NVL72 and DGX Spark, not the Station. NVIDIA Run:ai's requirements say workstations are not supported, and NVIDIA publishes no Kubernetes reference architecture for the Station. What is documented works in your favour. You can install the GPU Operator against the driver the Station already ships with, use its MIG Manager to re-apply GPU partitions, and keep NVIDIA's host networking stack. For a single team running a few model servers, plain Docker with NVIDIA's container toolkit is often enough. This guide records what NVIDIA's documentation says as of 9 Nov 2026. SourceIT has not built this integration on a unit.

What does each Kubernetes component officially support?

Source: NVIDIA GPU Operator platform support (updated 3 Nov 2026) and MIG page (updated 14 Oct 2026); github.com/NVIDIA/k8s-device-plugin README; NVIDIA Network Operator v26.1.0 platform support (updated 31 Mar 2026); NVIDIA Run:ai system requirements; Slurm GRES documentation. All fetched 9 Nov 2026.

Should a DGX Station run Kubernetes at all?

Only if Kubernetes is already how your organisation runs software. Kubernetes earns its overhead when several teams deploy services on a schedule and IT wants one way to manage everything. It also helps when the Station must sit alongside existing clusters for monitoring, storage and access control. If one team runs a handful of model servers, Docker with the pre-installed NVIDIA Container Toolkit is simpler, and our vLLM deployment guide takes that route. Sharing the GPU between departments doesn't require Kubernetes either. MIG can split it into up to seven isolated instances, as explained in sharing one GB300 between seven teams. Kubernetes is one way to hand those slices out. The private AI cloud foundation post covers the wider service model.

What has to be in place in your IT first?

Most failures here are basic plumbing rather than GPU problems. The Station needs reliable DNS and time sync. It needs a route to NVIDIA's container registry, and NVIDIA's DGX connectivity reference notes that if port 443 is proxied, "WebSocket protocol traffic must be supported". It also needs your internal certificate authority if your registry or cluster uses one. NVIDIA publishes no Active Directory, LDAP or single-sign-on guide for the Station, so plan identity integration with your own team. Security settings matter too, because Secure Boot is on by default; our security hardening checklist covers the host. If you haven't commissioned the unit yet, start with the setup guide.

Single-node cluster or worker in an existing cluster?

There are two patterns. In the first, the Station runs its own small, single-node cluster. That is self-contained and easy to reason about, but it adds another cluster for IT to maintain. In the second, the Station joins an existing cluster as a GPU worker node. That reuses your monitoring, storage and access controls. The catch is architecture. The Station's 72-core Grace CPU is Arm, so every image scheduled onto it must have an arm64 build, and workloads built only for x86 must be kept off it. Kubernetes provides taints, tolerations and node affinity for exactly this, and GPU requests keep ordinary pods away from the GPU. NVIDIA has published no reference design for either pattern on the Station. Arm software compatibility is covered in our Grace Arm software guide.

How do you install the GPU Operator when the driver is already there?

The Station ships with the NVIDIA GPU driver installed, so use the GPU Operator's pre-installed-driver option instead of letting it install its own. NVIDIA's MIG page shows the install as:

helm install gpu-operator \
    -n gpu-operator --create-namespace \
    nvidia/gpu-operator \
    --version=v26.7.2 \
    --set driver.enabled=false

Source: NVIDIA GPU Operator, GPU Operator with MIG. That page doesn't say whether to disable the bundled container toolkit as well, so don't add flags it doesn't document. Check the Operator's install guide for your release.

On a Station, MIG layouts disappear at every reboot. Let the GPU Operator's MIG Manager own the layout through a node label, rather than relying on someone remembering to re-run commands.

How should MIG work under Kubernetes?

The GPU Operator offers two MIG strategies. NVIDIA defines single as "MIG mode is enabled on all GPUs on a node" and mixed as "MIG mode is not enabled on all GPUs on a node". A Station with an RTX PRO display card has a second GPU that won't be partitioned, which points to mixed. That is our inference; NVIDIA's page doesn't discuss this case. The MIG Manager applies a named layout when you set the nvidia.com/mig.config label on the node. NVIDIA warns that it "requires that no user workloads are running on the GPUs being configured" and "stops all operator-managed pods that have access to GPUs". Treat a layout change as a maintenance event. This matters because NVIDIA's MIG guide says MIG mode and MIG devices are "not persistent across system reboots". On a single Station with no other GPU nodes, a reboot or layout change briefly takes every GPU workload offline.

What about networking, storage and monitoring?

For networking, NVIDIA's Network Operator lists the ConnectX-8 SuperNIC and Grace systems. However, its precompiled DOCA-OFED driver images are described as "currently unsigned", and the "nvidia" kernel variant is a Tech Preview. With Secure Boot on and DOCA-OFED already installed on the host, keeping the host driver is the safer default unless NVIDIA documents otherwise. For storage, back persistent volumes with your NAS; our NAS and high-speed storage guide covers mounts and throughput. Remember that GPUDirect Storage through the GPU Operator is not supported with Secure Boot. For monitoring, the GPU Operator can run DCGM-Exporter for you; our DCGM, Prometheus and Grafana guide explains what to watch. Finally, register the Station in your CMDB and service desk like any server, and agree who owns it, as discussed in who manages a DGX Station. When one Station isn't enough, how NVIDIA scales from desk to data centre shows the next steps.

Buying in Singapore

For connecting a Station to an existing cluster network, the D-Link DXS-1210-28T (24 × 10GBASE-T plus 4 × 25G SFP28) is S$4,122.00 and the HPE Aruba Instant On 1960 12-port 10G is S$2,444.40 (listed 9 Nov 2026). Prices change; ask for a current quotation. The six DGX Station GB300 systems we list are price on request, including the ASUS ExpertCenter Pro ET900N G3 and Supermicro ARS-511GD-NB-LCC, each supplied through its OEM's channel. Use Request for Quotation on the product page, call (65) 6978 3502, email Sales@sourceit.com.sg or use our contact page.

Frequently asked questions

Does the NVIDIA GPU Operator support the DGX Station GB300? It lists the DGX Station as a supported Blackwell GPU, but its Arm platform table names only HGX GB300 NVL72 and DGX Spark. Treat the Station as usable but less documented.

Can I use NVIDIA Run:ai on a DGX Station? Run:ai's system requirements say workstations are not supported, so plan without it unless NVIDIA confirms otherwise for your use.

Should the GPU Operator install its own driver? No. The Station ships with the NVIDIA driver, and NVIDIA's MIG page shows the install with --set driver.enabled=false.

Do MIG partitions survive a reboot? No. NVIDIA's MIG guide says MIG mode and devices are not persistent across reboots. The GPU Operator's MIG Manager re-applies a layout from a node label.

Do I need Kubernetes to share a Station between teams? No. MIG and containers can share it without Kubernetes. Kubernetes helps when you already run it and want one way to deploy and manage everything.