NVIDIA AICR ergänzt k8s-aibom zur Erfassung von KI-Workloads in Kubernetes-GPU-Clustern

Versionsgebundene Plattform-Rezepte beschreiben, wie ein GPU-Cluster aufgebaut werden soll, zeigen aber nicht, welche KI-Workloads tatsächlich darauf laufen. Teams, die über NVIDIA Dynamo, Kubeflow oder Slurm bereitstellen, aktualisieren Workloads unabhängig vom Rezept. Veränderliche Tags wie :latest verschärfen das Problem: Zwei Knoten können unter demselben Tag unterschiedlichen Code ausführen, und ein späterer Pull kann ein Image abrufen, das nie eine Sicherheitsprüfung durchlaufen hat. NVIDIA AI Cluster Runtime (AICR), eine Open-Source-Komponente der NVIDIA DSX AI Factory Platform, enthält jetzt eine qualifizierte Komponente für KI-Stücklisten. Sie basiert auf k8s-aibom, einem Open-Source-Projekt von Google zur Erfassung von KI-Workloads in Kubernetes.

Die Werkzeuge arbeiten auf unterschiedlichen Ebenen. AICR macht aus bewährten GPU-Konfigurationen versionsfixierte Rezepte und reproduzierbare Bundles. Ein Rezept wird für genau eine Kombination aus Hardware, Cloud, Betriebssystem und Einsatzzweck geschrieben und legt Komponenten, Versionen, Werte, Einschränkungen, Bereitstellungsreihenfolge und erwartete Validierungen fest. Bundles enthalten Prüfsummen, und aicr bundle --attest fügt optional eine Signatur hinzu. k8s-aibom überwacht die Workload- und Pod-APIs und erzeugt für jeden erkannten KI-Workload ein AIBOM im Format CycloneDX 1.6. Unterstützt werden native Dynamo-Graphen, NIMService, LeaderWorkerSet, DisaggregatedSet und CronJob, wobei untergeordnete Workloads in das AIBOM ihres Besitzers einfließen. Qualifizierung bedeutet, dass AICR Upstream-Quellcode, Chart, CRDs und ein per Digest fixiertes Controller-Image als einen getesteten Satz festschreibt. Außerdem prüft AICR die Herkunft anhand der Build-Identität von Google, überprüft RBAC und die Sicherheitsvoreinstellungen und testet Installation, Upgrade, Funktionsfähigkeit und Deinstallation.

In den Rezepten h100-gke-cos-inference und h100-gke-cos-inference-dynamo ist k8s-aibom standardmäßig aktiviert. In anderen GKE-Rezepten wird es aktiviert durch --runtime-inventory enabled, deaktiviert wird sie mit --runtime-inventory disabled. Die Beispiele verwenden AICR v1.2.0, in dessen Katalog k8s-aibom 1.6.2 festgelegt ist, und laufen auf GKE mit Kubernetes 1.32 oder neuer sowie H100-Knoten auf Container-Optimized OS mit von GKE verwalteten Treibern. Das Rezept wird erzeugt mit aicr recipe --service gke --accelerator h100 --os cos --intent inference, die aufgelösten Werte zeigt aicr query mit --selector components.k8s-aibom.version. aicr bundle erstellt das Bundle mit Selektoren für System- und beschleunigte Knoten. Standardmäßig wird Helm verwendet, unterstützt werden außerdem helmfile, flux und argocd. Nach aicr verify und deploy.sh läuft der Controller im Namespace k8s-aibom-system. Helm-Bundles wenden die CRDs des Haupt-Charts an, während Flux und Argo CD sie über ihre eigenen Controller aktualisieren. Bei Helmfile, Terraform und Fleet müssen die CRDs manuell aktualisiert werden, wenn ein Übergang dies erfordert; die erwartete Speicherversion ist v1beta1.

Team aicr snapshot, gefolgt von aicr validate --phase deployment --phase conformance, führt die Integritätsprüfung von k8s-aibom aus. Voraussetzungen sind ein verfügbarer Controller, eine AIBOMControllerConfig mit Ready=True und die erwartete Speicherversion der CRD. Eine übereinstimmende Speicherversion beweist nicht, dass das gesamte Schema aktuell ist. Prüfen Sie daher bei Upgrades zusätzlich auf Degraded=True mit dem Grund SchemaPredatesController. Die Inventarisierung wird pro Namespace über das Label aibom.k8saibom.dev/enabled=true aktiviert. Das Label begrenzt, in welchen Namespaces AIBOM-Einträge entstehen, die Informer cachen aber trotzdem Workload- und Pod-Spezifikationen clusterweit, einschließlich Argumenten und inline angegebener Umgebungsvariablen. Standardmäßig sind weder ein Sink noch ein Zugriff auf Secrets konfiguriert. In der Demo stellt ein vLLM-Deployment Qwen/Qwen2.5-0.5B-Instruct aus dem Image vllm/vllm-openai:latest bereit. Sein AIBOM wird der Kategorie Inferenz mit der Laufzeitumgebung vllm zugeordnet. Da die Einträge aus der Spezifikation erstellt werden, kann ein AIBOM Ready=True anzeigen, bevor der Pod sein Image vollständig heruntergeladen hat: Scheduling und Ausführung belegt es nicht.

Die BOM wird direkt in der Ressource gespeichert, zusammen mit einem SHA-256-Hash über die kanonischen Bytes: Sie lässt sich mit jq und base64 extrahieren, und der Hash kann mit shasum geprüft werden. Unter den Komponenten sind die Anwendung (vllm), das Container-Image (vllm/vllm-openai) und das Machine-Learning-Modell (Qwen/Qwen2.5-0.5B-Instruct) aufgeführt. Eine herkömmliche SBOM identifiziert das Image, eine AIBOM zusätzlich das Modell und die Serving-Laufzeitumgebung. Jedes Attribut trägt eine Vertrauensstufe (declared, inferred, unresolved oder verified) und einen Nachweis-Locator, der zeigt, wie der Wert ermittelt wurde. Die Entwickler von k8s-aibom haben den Overhead des Controllers in Version 1.6.1 auf GKE mit Dynamo und der Konfiguration von AICR gemessen. Der Test lief auf reinen CPU-Knoten, wobei die Workload-Pods im Status Pending blieben.

Einige Lücken sind bewusst so belassen. Laufzeitbeobachtungen werden noch nicht signiert, obwohl die kanonischen Bytes und der Hash eine Signierung praktikabel machen. k8s-aibom kann Sigstore-Signaturen von Modellangaben prüfen, eine bestimmte Signierer-Identität erzwingen und die Aufnahme in Rekor überprüfen, doch in AICR ist dies standardmäßig deaktiviert. Die Verknüpfung von AICR-Bundle-Attestierungen mit dem Laufzeitinventar steht noch aus. Ebenso der Abgleich der Rezeptabsicht mit den tatsächlich beobachteten Workloads: Dafür sind gemeinsame Artefaktidentitäten, Aktualitätsregeln und eine Abdeckungszuordnung erforderlich. AICR ist unter NVIDIA/aicr verfügbar, k8s-aibom unter GoogleCloudPlatform/k8s-aibom; beide Projekte sind Open Source.