k8s-launch-kit-deploy

par nvidia

Use this skill when the user wants to deploy generated NVIDIA networking manifests to a Kubernetes cluster using k8s-launch-kit (l8k). Activate for: applying…

npx skills add https://github.com/nvidia/k8s-launch-kit --skill k8s-launch-kit-deploy

l8k: Deploy

PREREQUISITE: Read ../k8s-launch-kit-shared/SKILL.md for install paths, global flags, and output modes.

Apply previously generated NVIDIA networking manifests to a Kubernetes cluster.

Usage

The standalone subcommand (preferred):

l8k deploy [--deployment-files <DIR>] [--kubeconfig <PATH>] [--dry-run]

l8k deploy reads YAML files from --deployment-files (default ./deployment) and applies them in dependency order. It auto-prefers <DIR>/network-operator/ (the layout l8k generate produces) and falls back to <DIR> itself.

When the deployment directory contains a values.yaml (the l8k generate profile renderer emits one per profile), Phase 0 runs first: the Helm Go SDK installs (or upgrades, with --overwrite-existing) the nvidia/network-operator chart in the namespace from networkOperator.namespace. The chart version and Helm repo URL come from the embedded release catalog selected via --network-operator-release. Phase 0 is skipped silently when values.yaml is absent — backward compatible with users managing the chart out of band.

Network Operator 26.1+ requestor mode is a Helm-level change: the generated values add Network Operator Deployment environment variables and enable the SR-IOV external drainer where applicable. Applying only the generated CRs cannot enable requestor mode. When upgrading an existing release whose values differ, pass --overwrite-existing; otherwise l8k intentionally stops at the values conflict.

The legacy one-shot form (still supported, useful when you want to generate and apply in a single step):

l8k generate --user-config <CONFIG> --fabric <FABRIC> --deployment-type <TYPE> --deploy [--kubeconfig <PATH>]

Flags

FlagRequiredDescription
--deployment-filesDirectory with manifests to apply (default ./deployment)
--kubeconfigPath to kubeconfig with cluster-admin access (falls back to $KUBECONFIG)
--dry-runServer-side dry-run (client.DryRunAll) — cluster validates without persisting
--overwrite-existingWhen a network-operator helm release already exists with values that differ from the freshly rendered values.yaml, promote Phase 0 to helm upgrade --install. Off by default to avoid clobbering an out-of-band install.

Examples

# Apply manifests from ./deployment to the cluster reachable via $KUBECONFIG
l8k deploy

# Apply from a specific directory with explicit kubeconfig
l8k deploy --deployment-files /tmp/my-output --kubeconfig ~/.kube/config

# Server-side dry-run before a production apply
l8k deploy --dry-run

# Apply newly generated requestor-mode values to an existing release
l8k deploy --deployment-files ./output --kubeconfig ~/.kube/config \
  --overwrite-existing

# Agent mode
l8k deploy --output json --yes 2>/dev/null

# Legacy single-shot: generate + deploy in one invocation
l8k generate --user-config cluster-config.yaml \
  --fabric ethernet --deployment-type sriov \
  --save-deployment-files ./output \
  --deploy --kubeconfig ~/.kube/config

Resource Apply Order

l8k applies resources in dependency order:

  1. NicClusterPolicy (cluster-wide: Multus, CNI, NV-IPAM, operators) — wait for ready before continuing
  2. NicNodePolicy per group (OFED driver, device plugins) — wait for each
  3. Network resources (SriovNetwork / HostDeviceNetwork / MacvlanNetwork / IPoIBNetwork)
  4. IPPool (NV-IPAM address allocation)
  5. NicInterfaceNameTemplate (when needed)
  6. Example workload DaemonSets (optional)

Post-Deploy Verification

kubectl get nicclusterpolicy -o yaml          # Check policy state
kubectl get nicnodepolicy                     # Per-group state
kubectl get pods -n <operator-ns>             # Verify all pods Running
kubectl get sriovnetworknodestates -A         # Check SR-IOV VF allocation
kubectl get maintenanceoperatorconfigs -A -o yaml # Check global concurrency
kubectl get nodemaintenances -A                # Check active requests

For SR-IOV on release 26.1+, verify that the generated Helm values contain both operator.maintenanceOperator.useDrainControllerRequestor: true and sriov-network-operator.operator.externalDrainer.enabled: true. For OFED, verify operator.maintenanceOperator.useRequestor: true. Do not try to enable these by applying MaintenanceOperatorConfig alone.

[!CAUTION] This is a write command — confirm with the user before executing on production clusters.

See Also