NVIDIA AICR intègre k8s-aibom pour inventorier les charges de travail d'IA dans les clusters GPU Kubernetes

Les recettes de plateforme à versions figées décrivent comment construire un cluster GPU, mais elles n'indiquent pas quelles charges de travail d'IA y tournent réellement. Les équipes qui déploient via NVIDIA Dynamo, Kubeflow ou Slurm mettent à jour leurs charges de travail indépendamment de la recette de plateforme. Les tags modifiables comme :latest aggravent le problème : deux nœuds peuvent exécuter un code différent sous le même tag, et un téléchargement ultérieur peut récupérer une image qu'aucune revue de sécurité n'a jamais couverte. NVIDIA AI Cluster Runtime (AICR), composant open source de la plateforme NVIDIA DSX AI Factory Platform, inclut désormais un composant qualifié de nomenclature d'IA. Il repose sur k8s-aibom, un projet open source de Google qui inventorie les charges de travail d'IA sur Kubernetes.

Les deux outils interviennent à des niveaux différents. AICR transforme des configurations GPU éprouvées en recettes à versions figées et en bundles reproductibles. Une recette cible une combinaison donnée de matériel, de cloud, d'OS et d'usage, et consigne les composants, les versions épinglées, les valeurs, les contraintes, l'ordre de déploiement et les validations attendues. Les bundles contiennent des sommes de contrôle, et aicr bundle --attest ajoute une signature facultative. k8s-aibom surveille les API des charges de travail et des pods et produit, pour chaque charge de travail d'IA reconnue, un AIBOM au format CycloneDX 1.6. Il prend en charge les graphes Dynamo natifs, NIMService, LeaderWorkerSet, DisaggregatedSet et CronJob, et les charges de travail enfants sont regroupées dans l'AIBOM de leur propriétaire. La qualification signifie qu'AICR épingle la source amont, le chart, les CRD et l'image du contrôleur (épinglée par digest) en un ensemble unique testé. AICR vérifie également la provenance par rapport à l'identité de build de Google, examine le RBAC et les paramètres de sécurité par défaut, et teste l'installation, la mise à niveau, l'état de santé et la désinstallation.

Dans les recettes h100-gke-cos-inference et h100-gke-cos-inference-dynamo k8s-aibom est activé par défaut. Dans les autres recettes GKE, on l'active avec --runtime-inventory enabled, et le désactive --runtime-inventory disabled. Les exemples utilisent AICR v1.2.0, dont le catalogue fixe la version k8s-aibom 1.6.2, et fonctionnent sur GKE avec Kubernetes 1.32 ou version ultérieure et des nœuds H100 sous Container-Optimized OS avec des pilotes gérés par GKE. La recette est générée par aicr recipe --service gke --accelerator h100 --os cos --intent inference, les valeurs résolues sont renvoyées par aicr query avec --selector components.k8s-aibom.version. aicr bundle construit le bundle avec des sélecteurs de nœuds système et accélérés. Le déployeur Helm est utilisé par défaut, et helmfile, flux et argocd sont également pris en charge. Après aicr verify et deploy.sh le contrôleur s'exécute dans l'espace de noms k8s-aibom-system. Les bundles Helm appliquent les CRD du chart principal, tandis que Flux et Argo CD les mettent à jour via leurs contrôleurs. Avec Helmfile, Terraform et Fleet, les CRD doivent être mises à jour manuellement lorsqu'une transition l'exige ; la version de stockage attendue est v1beta1.

L'équipe aicr snapshot, suivie de aicr validate --phase deployment --phase conformance, exécute la vérification de l'état de santé de k8s-aibom. Elle requiert un contrôleur disponible, un AIBOMControllerConfig avec Ready=True et la version de stockage CRD attendue. Une version de stockage correspondante ne garantit pas que l'ensemble du schéma est à jour : lors des mises à niveau, vérifiez donc aussi Degraded=True avec la raison SchemaPredatesController. L'inventaire s'active par espace de noms via le label aibom.k8saibom.dev/enabled=true. Le label limite les espaces de noms qui produisent des enregistrements AIBOM, mais les informers mettent toujours en cache les spécifications des charges de travail et des pods dans tout le cluster, y compris les arguments et les valeurs d'environnement en ligne. Aucun récepteur de données ni accès aux secrets n'est configuré par défaut. Dans la démo, un Deployment vLLM sert Qwen/Qwen2.5-0.5B-Instruct à partir de l'image vllm/vllm-openai:latest. Son AIBOM est classé dans la catégorie inférence avec le runtime vllm. Comme les enregistrements sont construits à partir de la spécification, un AIBOM peut afficher Ready=True avant que le pod ait fini de télécharger son image : il ne prouve ni la planification ni l'exécution.

Le BOM est stocké directement dans la ressource avec un hachage SHA-256 des octets canoniques : on peut l'extraire avec jq et base64, puis vérifier le hachage avec shasum. Ses composants listent l'application (vllm), l'image de conteneur (vllm/vllm-openai) et le modèle d'apprentissage automatique (Qwen/Qwen2.5-0.5B-Instruct). Un SBOM classique identifie l'image, tandis qu'un AIBOM identifie aussi le modèle et le runtime de service. Chaque attribut porte un niveau de confiance (declared, inferred, unresolved ou verified) et un localisateur de preuve indiquant comment la valeur a été déterminée. Les développeurs de k8s-aibom ont mesuré la surcharge du contrôleur de la version 1.6.1 sur GKE avec Dynamo et la configuration d'AICR. Le test a utilisé des nœuds CPU uniquement, avec les pods de charge de travail laissés en attente.

Certaines lacunes sont volontaires. Les observations à l'exécution ne sont pas encore signées, bien que les octets canoniques et le hachage rendent la signature facile à mettre en œuvre. k8s-aibom peut vérifier les signatures Sigstore des déclarations relatives aux modèles, imposer l'identité du signataire et vérifier l'inclusion dans Rekor, mais AICR désactive cette fonction par défaut. Relier les attestations des bundles AICR à l'inventaire des charges de travail reste à faire. Il en va de même pour la comparaison entre l'intention de la recette et les charges de travail réellement observées : elle nécessite des identités d'artefacts partagées, des règles de fraîcheur et une cartographie de la couverture. AICR est disponible sur NVIDIA/aicr et k8s-aibom sur GoogleCloudPlatform/k8s-aibom ; les deux projets sont open source.