Présentation

NVIDIA Kubernetes Engine (NVKE) propose un plan de gestion dédié aux équipes plateformes souhaitant offrir des clusters Kubernetes sur une infrastructure GPU NVIDIA. Chaque cluster de charge de travail possède son propre plan de contrôle, son etcd et ses pools de nœuds, tandis que le plan de gestion reste isolé et ne subit aucune mise à jour automatique. Le produit est actuellement en preview ; les API, la configuration et le comportement peuvent évoluer, et il n’est pas recommandé pour des charges de production.

Architecture et flux de données

Le déploiement démarre par un cluster « seed » temporaire qui héberge le plan de gestion NVKE. Ce plan orchestre la création de clusters de charge de travail via le fournisseur d’infrastructure NVIDIA Infra Controller (NICo), le projet Cluster API et un agent de nœud dédié. Les machines, le réseau, les images de nœuds et les registres sont fournis par l’opérateur ; NICo reste le seul fournisseur compatible en preview. La chaîne de construction repose sur le projet compagnon NVIDIA Kubernetes Recipes (NVKR), qui compile les images de nœuds et les composants NVKE à partir d’entrées figées. Le plan de gestion interagit avec NICo pour provisionner les machines, puis crée les plans de contrôle, etcd et les pools de nœuds pour chaque client.

Sécurité et identité des nœuds

NVKE impose une attestation TPM via le framework SPIFFE/SPIRE : chaque nœud doit prouver son identité matérielle avant de recevoir les informations d’adhésion au cluster. Cette étape garantit que seuls les nœuds authentifiés peuvent rejoindre le plan de contrôle. De plus, le stockage etcd peut être chiffré par cluster, limitant la visibilité des données de configuration. Toutefois, le preview désactive l’authentification de l’API et utilise HTTP en clair après l’installation, ce qui impose à l’opérateur de configurer manuellement une authentification et un accès protégé avant toute utilisation externe.

Limites du preview et considérations d’exploitation

Le plan de gestion ne possède ni procédure de mise à jour, ni mécanisme de sauvegarde/restauration ; il ne peut pas être mis à l’échelle ou remplacé automatiquement. Les images de nœuds à chiffrement complet de disque (FDE) sont uniquement destinées à l’évaluation et ne garantissent aucune confidentialité des données au repos. Le prérequis matériel minimal pour le quick‑start local est de 6 CPU, 12 GiB de RAM et 100 GiB de disque, avec Docker, le support TPM virtuel et les outils listés dans la documentation. Le projet cible Go 1.27.3 et GNU Make 4 ou plus ; la compilation produit neuf binaires, dont 

make build
qui génère les exécutables agent, nvkectl, controller, etc. Aucun de ces binaires ne démarre le plan de gestion ou ne crée un cluster automatiquement ; le nœud agent s’exécute uniquement sur Linux. En l’absence de support officiel pour la production, les opérateurs doivent évaluer soigneusement les risques liés à l’absence d’authentification, de sauvegarde et de chiffrement des disques avant d’envisager un déploiement en environnement réel.