// HEISE ONLINE — LINUX & OPEN SOURCE
NVKE: Nvidia bringt eigene Kubernetes Engine als Preview
Mit Nvidias NVKE sollen Betreiber von GPU-Rechenzentren Managed Kubernetes anbieten können. Die Preview lässt sich jetzt ausprobieren.
This article is also available in
English.
It was translated with technical assistance and editorially reviewed before publication.
Nvidia hat seine neue Kubernetes Engine, kurz NVKE, als Preview auf GitHub vorgestellt. Betreiber eigener GPU-Rechenzentren können ihren Kunden so Kubernetes als Managed Service bereitstellen, ähnlich wie bei AWS mit EKS.
Ein zentraler Management-Cluster legt dafür auf Anfrage isolierte Kubernetes-Cluster auf Bare-Metal-Servern an. Jeder Cluster erhält eine eigene Control Plane, ein eigenes etcd und eigene Node-Pools. Auch die Control Plane läuft auf eigenen Servern. Über NVKE skalieren Betreiber dann die Node-Pools und spielen Kubernetes-Upgrades ein. Der Code steht unter der Apache-2.0-Lizenz bereit – Nvidia empfiehlt NVKE aber noch nicht für den Produktivbetrieb.
NVKE stellt die GPU-Server ohne GPU- und Fabric-Software bereit. Treiber, Container-Toolkit und Device-Plugin installiert erst Nvidias GPU Operator. Die passenden Rezepte liefert Nvidias AI Cluster Runtime. Die Steuerung erfolgt dann über das Kommandozeilenwerkzeug nvkectl oder die NVKE-API, eine REST-Schnittstelle der Management Plane. Über sie lassen sich Cluster mit Kubernetes-Version, Node-Pools und Netzwerkeinstellungen anfordern.
nvkectl erledigt dieselben Aufgaben an der Kommandozeile und richtet zusätzlich die Installation ein. Neue Cluster erhalten ovn-kubernetes als Netzwerk-Plug-in. NVKE unterstützt Calico dabei nur noch für bestehende Installationen, für neue Cluster ist es nicht mehr verfügbar. Hochverfügbare Control Planes und Kubernetes-Upgrades setzen außerdem eine virtuelle IP voraus, die NVKE per kube-vip einrichtet. Ohne ist die Kubernetes-API nur über die IP des ersten Control-Plane-Nodes erreichbar.
Nach der Installation nimmt die NVKE-API Anfragen per unverschlüsseltem HTTP auf Port 30080 jedes Management-Nodes an. Einen eigenen TLS-Endpunkt müssen Betreiber selbst davorschalten. Nvidia rät, nur die nötigen Netze freizugeben und die Authentifizierung per JWT des eigenen Identity Providers einzuschalten. Eine Rechteverwaltung fehlt dann aber immer noch: Jeder zugelassene Aufrufer darf alle Workload-Cluster anlegen und löschen.
Der Management-Cluster selbst besteht aus einer ungeraden Zahl von Servern mit TPM 2.0 (Trusted Platform Module), etwa einem, drei oder fünf. Jeder davon arbeitet als Control-Plane-Node und betreibt zugleich die Management Plane. Der Cluster verwaltet sich aber nicht selbst, die eigenen Nodes aktualisiert, skaliert und ersetzt er nicht. In der Preview gibt es außerdem noch kein Verfahren für den Wechsel auf ein neueres NVKE-Release, auch nicht für Backup und Restore von Management-Cluster und Management Plane.
Nvidia koppelt NVKE eng an den eigenen Infrastruktur-Stack. In der Preview bezieht NVKE die Server standardmäßig über den Nvidia Infra Controller, kurz NICo, mit dem Bare-Metal-Infrastruktur über APIs statt über Runbooks betrieben werden kann. NICo läuft selbst auf einem Kubernetes-Cluster mit mindestens drei Nodes – wer NVKE auf echter Hardware einsetzen will, betreibt damit also zwei Verwaltungsschichten übereinander. Ähnliche Aufgaben lösen schon etablierte Open-Source-Werkzeuge: Gardener und Kamaji betreiben die Control Planes der Kunden-Cluster als Pods in einem zentralen Cluster.
In der Standardkonfiguration isoliert NICo die Mandanten außerdem über BlueField-DPUs – Nvidias hauseigene Netzwerkkarten mit eigenen ARM-Rechenkernen. Alternativ unterstützt NVKE den Provider LaunchLayer, den man über Argo CD aus Nvidias DSX-Umfeld installieren kann. Ihre Identität weisen die Nodes per SPIFFE/SPIRE mit ihrem TPM nach. Node-Images und Komponenten baut das Schwesterprojekt Nvidia Kubernetes Recipes.