k8s-launch-kit-troubleshoot

par nvidia

Utilisez cette compétence lorsque l'utilisateur rencontre des problèmes avec l'opérateur réseau NVIDIA sur Kubernetes, ou souhaite analyser un vidage de diagnostic sosreport. Activer pour : OFED…

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

l8k: Troubleshooting

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

Debug NVIDIA Network Operator issues on Kubernetes, with or without a sosreport.

l8k Troubleshooting Commands

# Show validation endpoints, planning, route-cache statistics, stage/batch
# progress, timings, and failed RDMA evidence.
l8k validate --kubeconfig <PATH> --deployment-files <DIR> --log-level debug

# Add bounded route command output, RDMA client stdout/stderr, and server logs.
l8k validate --kubeconfig <PATH> --deployment-files <DIR> --log-level trace --keep

# Collect a diagnostic dump from the cluster
l8k sosreport [--kubeconfig <PATH>] --output-dir ./sosreport

Start with debug. Escalate to trace when a route, ICMP, rping, or ib_write_bw failure needs command output. Trace fields are bounded; failed RDMA server logs are collected before cleanup. Add --keep only when the workload must remain available for follow-up kubectl exec inspection.

l8k sosreport gathers cluster state, CRDs, operator logs, and per-node NIC info into a structured directory for offline analysis. Release installations include the Network Operator collection script under share/l8k/scripts/; the command never downloads executable code at runtime. If the script is missing, report the upstream URL and exact expected path emitted by l8k so the user can install it manually. Use the diagnostic commands and triage workflow below to interpret the dump.

Diagnostic Commands

# NicClusterPolicy status (check state: ready vs notReady)
kubectl get nicclusterpolicy -o yaml

# Network operator pods
kubectl get pods -n <operator-ns> -o wide

# SR-IOV node states (VF allocation)
kubectl get sriovnetworknodestates -A -o yaml

# OFED driver pod logs
kubectl logs -n <operator-ns> -l app=mofed-<os> --tail=100

# NIC configuration daemon logs
kubectl logs -n <operator-ns> -l app=nic-configuration-daemon --tail=100

# Check for pods stuck on network resources
kubectl get pods -A -o wide | grep -E 'ContainerCreating|Init'

Common Failure Patterns

SymptomLikely CauseFix
NicClusterPolicy state: notReadyOFED driver pods failingCheck mofed pod logs, verify kernel/driver compatibility
Pods stuck in ContainerCreatingVFs not allocated or SR-IOV policy not appliedCheck sriovnetworknodestates, verify device plugin pods
CrashLoopBackOff on mofed podsKernel module conflictCheck thirdPartyRDMAModules, enable unloadThirdPartyRDMAModules
No VFs on nodeSriovNetworkNodePolicy not matchingVerify nodeSelector labels match worker nodes
RDMA not workingMissing RDMA device plugin or wrong resource nameCheck rdma-shared-dp pods, verify resource annotations
Phase 0 Helm chart download returns HTTP 401 or an image-pull-Secret errorThe configured Secret is missing from the operator namespace, unreadable by the kubeconfig, or has no compatible Docker auth entryVerify the Secret in networkOperator.namespace; for NGC, its .dockerconfigjson must contain nvcr.io credentials
l8k discover daemon pods stuck (ImagePullBackOff / Pending)Bad image tag, missing pull secret, or no Ready schedulable nodesRe-run with --keep-namespace then kubectl describe pod -n nvidia-k8s-launch-kit. Fix networkOperator.componentVersion, pass --image-pull-secrets, or restore node readiness. NFD is not required.
l8k discover waits for a node that has only a BlueFieldThe BlueField is in zero-trust (restricted) mode and NIC Configuration Operator will not publish a NicDeviceUse a Launch Kit version that excludes restricted BlueFields from the wait set; confirm the mode with mlxprivhost -d <pci> q in the daemon pod.
l8k validate / deploy can't find Network Operator podsOperator namespace mismatchVerify --network-operator-namespace matches actual namespace (does NOT apply to l8k discover — it ignores the flag and uses its own nvidia-k8s-launch-kit namespace)
IPPool not allocatingNV-IPAM subnet exhausted or misconfiguredCheck ippools CR status, verify CIDR ranges
--for requires --node-selector--for was passed without --node-selectorAdd --node-selector key=val,…. The synthesized clusterConfig has no live worker-node list; the selector identifies target nodes at apply time.
--for and --discover-cluster-config are mutually exclusiveBoth flags passed simultaneouslyPick one: --for skips discovery, --discover-cluster-config runs it.
unknown preset "X"; available: …--for X doesn't match any directory under presets/Run l8k preset list and re-run with one of those names.
preset has no capabilities blockPreset YAML used by --for is missing capabilities.nodes.{sriov,rdma,ib}Add the block to the preset's topology.yaml. Discovery-time overlay does not require it; only --for does.
unknown field "productType" in YAMLHand-authored config still uses the old key nameRename productType: to gpuType: (the field was renamed).

For detailed triage workflow, read references/common-failures.md.

sosreport Analysis

If the user has a pre-collected sosreport directory (from l8k sosreport or manual collection):

sosreport/
├── metadata/          # Cluster info, node list
├── crds/              # NicClusterPolicy, SriovNetworkNodePolicy, IPPool, etc.
├── operator/          # Network operator pod logs
├── nodes/             # Per-node device info
└── network/           # Interface config, routing tables

Triage Checklist

  1. Read metadata/diagnostic-summary.yaml for overview
  2. Check pod health in operator/pods.yaml
  3. Inspect CRDs in crds/ for status fields
  4. Read operator logs in operator/logs/ for errors
  5. Check per-node NIC state in nodes/<node>/

See Also

OpenShift

For OpenShift, check expected operator CSV/API status, SR-IOV device prefix openshift.io, NV-IPAM pools in the Network Operator namespace, and temporary SCC admission in the workload namespace.

Plus de skills de nvidia

fhir-basics
nvidia
Apprend aux agents comment fonctionnent les API FHIR R4, quelles ressources sont disponibles, comment les interroger avec des paramètres de recherche, et comment analyser correctement tous les formats de réponse…
compileiq-validate-result
nvidia
Utiliser APRÈS qu'une recherche soit terminée et AVANT de réclamer un accélérateur ou d'expédier un ACF. Charge le CSV dump_results, extrait les K meilleurs candidats (mono-objectif)…
changelog-audit
nvidia
Auditer le CHANGELOG.md de Warp avant une publication : récupérer les entrées perdues, trier par impact utilisateur, affiner le langage des entrées, ajuster les retours à la ligne et (en mode branche de publication) mettre à jour la comparaison…
dgx-diagnose
nvidia
Diagnostiquer les problèmes courants du DGX Station GB300 — plantages CUDA, ciblage incorrect du GPU, bugs de conteneur vLLM/SGLang, problèmes d'état MIG, erreurs NVLink/Fabric Manager,…
aicr-managing-openvex
nvidia
Use when adding, updating, or removing CVE/GHSA suppressions in `.openvex.json` — the OpenVEX document consumed by the daily image vulnerability scan workflow.…
aicr-creating-slide-decks
nvidia
À utiliser lors de la création d'un diaporama HTML autonome ou d'un support visuel pour un concept technique ou un flux de travail (par exemple un demos/*.html) — affiché en plein écran ou…
aicr-creating-guided-demos
nvidia
Génère un script de démonstration guidée interactive (demos/*.sh), en direct ou à son rythme, avec le modèle Frame → Tell → Show → Close. Se déclenche sur « script de démonstration », « guidé…
aicr-analyzing-snapshots
nvidia
À utiliser lors de l'analyse d'un fichier YAML de snapshot AICR, de l'examen de l'état du cluster, de la comparaison des caractéristiques des fournisseurs, de l'extraction d'informations sur la topologie GPU/réseau, ou…