4. Kubernetes Integration — 5%

What: Kubernetes-managed NVIDIA networking components and the resources that make network devices available to workloads.

Why: Distributed GPU workloads need the correct devices and network paths inside scheduled pods, not only healthy cluster services.

How: Follow operator reconciliation from host prerequisites to node resources, pod interfaces, and an end-to-end communication test.

NVIDIA Network Operator

What: A Kubernetes operator that manages selected NVIDIA networking components on supported clusters.

Why: It coordinates deployment and reconciliation of networking software and resources across nodes, reducing manual per-node setup.

How: Follow the compatibility matrix and versioned install guide, configure the required components, then verify reconciliation, pods, node state, and events.

The NVIDIA Network Operator manages networking components in Kubernetes clusters that use supported NVIDIA adapters and software. Depending on the version and selected components, it can help deploy drivers, device plugins, RDMA-related capabilities, and network components such as SR-IOV support. Consult the operator's compatibility matrix and installation guide: exact custom resources, prerequisites, and supported combinations are versioned.

Understand the control flow: install prerequisites and the operator, configure the required components, allow its controllers to reconcile nodes, then verify the resulting pods and node resources. Kubernetes desired state does not guarantee the host is ready; check device health, drivers, and relevant Kubernetes events as well.

RDMA device plugins and network attachments

What: Device plugins advertise hardware resources to the scheduler; network attachments connect pods to additional networks using supported CNI and RDMA components.

Why: GPU workloads need the right node resource and network path, not only an ordinary pod interface.

How: Trace adapter and driver to device plugin, node resource, pod request, attachment configuration, and pod-visible interface; test communication between workloads.

Device plugins advertise supported hardware resources to the Kubernetes scheduler so workloads can request them. A network attachment definition and its CNI integration can connect a pod to an additional network; an RDMA-capable attachment may expose a high-performance path when the host and configuration support it. These are distinct from ordinary pod networking.

Follow the chain from physical adapter to host driver, device plugin, node advertised resource, pod request, and pod-visible interface. Learn how resource names and attachment configuration are defined in the chosen deployment. Security, resource allocation, and topology alignment matter: a pod must land on a node with the requested resource and a usable path to its peers.

Deployment and verification

What: A version-aware process for installing the operator/components and confirming the resulting Kubernetes and host network state.

Why: A ready operator pod does not prove that a workload received a working RDMA-capable network path.

How: Check component readiness, node allocatable resources, pod scheduling, interfaces/devices inside the workload, and a suitable end-to-end test.

Use the official deployment guide for the matching Kubernetes and operator versions. Verify operator/controller health, component pod readiness on the expected nodes, node allocatable resources, successful pod scheduling, and interfaces/devices visible inside a test workload. Then run an appropriate connectivity or RDMA test between pods/nodes; a Running pod alone is not a network validation.

Review questions: Which component advertises devices to the scheduler? How does a pod request the resource? What evidence proves that the pod has an RDMA-capable path rather than only a normal network interface?