Nvidia hat eine Preview von NVKE veröffentlicht, seiner eigenen Kubernetes Engine, auf GitHub unter Apache-2.0. Der Anspruch ist geradlinig: Betreiber von GPU-Rechenzentren sollen Kubernetes als Managed Service verkaufen können, so wie AWS EKS verkauft — und darunter soll Nvidias Stack liegen.
Architektonisch ist NVKE ein Management-Cluster, der auf Anfrage isolierte Workload-Cluster auf Bare-Metal-Servern herausarbeitet. Jeder Mandantencluster bekommt eine eigene Control Plane, ein eigenes etcd und eigene Node-Pools, wobei die Control Plane auf dedizierten Servern läuft und nicht als Pod im Management-Cluster. Betreiber skalieren Node-Pools und spielen Kubernetes-Upgrades über ein CLI namens `nvkectl` oder über die REST-API von NVKE ein.
Die Provisionierungskette ist bewusst GPU-blind: NVKE liefert Server ohne GPU- und Fabric-Software aus, und Nvidias GPU Operator installiert anschließend Treiber, Container-Toolkit und Device-Plugin nach Rezepten der AI Cluster Runtime. Neue Cluster erhalten ovn-kubernetes als Netzwerk-Plugin; Calico bleibt nur für bestehende Installationen. Hochverfügbare Control Planes brauchen eine virtuelle IP, die NVKE per kube-vip einrichtet — ohne sie ist die Kubernetes-API nur über die Adresse des ersten Control-Plane-Nodes erreichbar.
Die Sicherheitslage der Preview ist der Teil, den man genau lesen sollte. Die API nimmt Anfragen unverschlüsselt über HTTP auf Port 30080 jedes Management-Nodes entgegen; TLS davorzusetzen ist Aufgabe des Betreibers. Nvidia empfiehlt, nur die nötigen Netze freizugeben und die Authentifizierung per JWT gegen den eigenen Identity Provider einzuschalten — und merkt dann an, dass eine Rechteverwaltung weiterhin fehlt: Jeder zugelassene Aufrufer darf alle Workload-Cluster anlegen und löschen. Backups, Restore und ein dokumentierter Weg von einem NVKE-Release zum nächsten fehlen in der Preview ebenfalls.
Der Management-Cluster selbst besteht aus einer ungeraden Zahl von Servern mit TPM 2.0 — eins, drei oder fünf —, die jeweils zugleich Control-Plane-Node und Gastgeber der Management Plane sind. Er verwaltet sich nicht selbst: Er aktualisiert, skaliert und ersetzt seine eigenen Nodes nicht.
NVKE ist zudem eng an Nvidias Infrastruktur-Stack gebunden. Standardmäßig bezieht es Server über den Nvidia Infra Controller, kurz NICo, der selbst eine Kubernetes-Anwendung ist und mindestens drei Nodes braucht — ein Deployment auf echter Hardware betreibt damit zwei Verwaltungsschichten übereinander. NICo isoliert Mandanten in der Standardkonfiguration über BlueField-DPUs; Nodes weisen ihre Identität per SPIFFE/SPIRE gegen ihr TPM nach. Node-Images und Komponenten kommen aus dem Schwesterprojekt Nvidia Kubernetes Recipes. Zielgruppe sind Nvidia Cloud Partner und große GPU-Betreiber, die ihre Hardware bereits mit NICo verwalten.
Das ruft den naheliegenden Vergleich auf. Gardener und Kamaji betreiben Kunden-Control-Planes heute als Pods in einem zentralen Cluster und blicken auf Jahre Produktivbetrieb zurück; Nvidia wählt den teureren Weg dedizierter Control-Plane-Server. Was NVKE bietet, das die anderen nicht bieten, ist die Integration: DPU-Mandantentrennung, TPM-Attestierung, GPU Operator und AI Cluster Runtime von Anfang an verdrahtet — vom Hersteller, der den GPU-Stack definiert.
Wer erst schauen will, bevor er sich bindet, bekommt einen lokalen Quickstart, in dem ein Mock-NICo jeden Node eines Workload-Clusters als Docker-Container startet. Nötig sind ein Linux-Host mit mindestens sechs CPUs, 12 GB freiem RAM, 100 GB Plattenplatz, Docker und Unterstützung für ein virtuelles TPM; unter macOS läuft die Evaluierung in einer Colima-VM. Einen Termin für eine produktionsreife Version nennt Nvidia nicht.
Bemerkenswert ist vor allem die Reihenfolge: Nvidia baut die Management-Ebene für GPU-Wolken, bevor der Markt dafür entschieden ist, ob er sie von einem Chiphersteller kaufen will. Die Preview beantwortet diese Frage nicht — sie macht nur klar, dass Nvidia sie stellen will.
