Isolierte GPU-Nodes auf Abruf mit vCluster Auto Nodes

Hinweis: Dieser Beitrag wurde aus dem Englischen übersetzt. Fachbegriffe, Code und Befehle wurden bewusst im Original belassen.

Ihre Data-Science-Teams streiten sich um GPUs. Drei Teams teilen sich einen GKE-Cluster und konkurrieren um denselben Pool aus A100s und T4s, um ihre Modelle zu trainieren. Der langlaufende Job eines Teams belegt nahezu alle Ressourcen, die übrigen warten. Schlimmer noch: Es treten Noisy-Neighbor-Effekte auf – ein falsch konfigurierter Workload belegt den gesamten GPU-Speicher und bringt benachbarte Pods zum Absturz. Sicherheitsprüfungen haben ergeben, dass Teams auf gemeinsam genutzten Nodes die Prozesse der anderen einsehen können. Das Scheduling wird unvorhersehbar, und Ihre ML-Engineers verbringen am Ende mehr Zeit mit Warten als mit Training.

Klassische GKE-Ansätze zwingen zu unangenehmen Kompromissen. Dedizierte Node Pools je Team garantieren zwar Isolation, lassen aber teure GPUs zwischen den Jobs brachliegen. Namespace-Isolation bietet eine logische Trennung, jedoch nichts auf Hardwareebene. GKE Autopilot vereinfacht den Betrieb, schränkt aber die GPU-Konfigurationen und Node-Anpassungen ein, die ML-Workloads benötigen.

Und was ist mit Karpenter? Man könnte meinen, es löse dieses Problem – und beim dynamischen Bereitstellen von Nodes leistet es Hervorragendes. Allein adressiert Karpenter jedoch nicht die Herausforderung der Mandantenfähigkeit. Von Karpenter bereitgestellte Nodes gehören weiterhin zum gemeinsamen Host-Cluster. Alle Mandanten können potenziell Workloads darauf platzieren. Teams können weiterhin die Prozesse der anderen einsehen, und ein falsch konfigurierter Job kann nach wie vor benachbarte Prozesse auf demselben Node beeinträchtigen. Karpenter liefert Effizienz, aber keine Isolation.

Wir brauchen beides: die Kosteneffizienz bedarfsgerechter GPU-Bereitstellung und Mandantenisolation auf Hardwareebene. GPU-Nodes, die automatisch hochfahren, sobald ein Mandant einen Job einreicht, ausschließlich diesem Mandanten gehören und in dem Moment beendet werden, in dem der Job abgeschlossen ist. Keine ungenutzten Ressourcen, keine gemeinsame Hardware, keine Scheduling-Konflikte.

Genau das leistet vCluster Auto Nodes. In dieser Anleitung setzen wir bedarfsgerechte GPU-Isolation auf GKE Schritt für Schritt um, sodass jeder Mandant eigene, dedizierte Rechenressourcen erhält – ohne den Aufwand, separate Cluster zu verwalten. Am Ende dieses Tutorials verfügen Sie über eine voll funktionsfähige vCluster-Umgebung, die dedizierte GPU-Nodes bedarfsgerecht bereitstellt und wieder abbaut.

Voraussetzungen

Stellen Sie vor dem Start sicher, dass Sie über folgende Werkzeuge und Zugänge verfügen:

• gcloud-CLI v400+ (Installationsanleitung)

• kubectl v1.28+ (Installationsanleitung)

• Helm v3.12+ (Installationsanleitung)

• vcluster-CLI v0.30+ (Installationsanleitung)

• GCP-Projekt mit freigegebener GPU-Quota für Ihre Zielregion

Wie vCluster Auto Nodes auf GKE funktioniert

Was wir brauchen, steht fest: bedarfsgerechte GPU-Bereitstellung mit Mandantenisolation auf Hardwareebene. Genau darin liegt der Vorteil der Kombination aus Auto Nodes und Private Nodes gegenüber Karpenter allein.

Bei klassischem Karpenter treten neu bereitgestellte Nodes dem Host-Cluster bei und bleiben für alle Mandanten zugänglich. vCluster dreht dieses Modell um: Private Nodes sind Compute-Engine-VMs, die Ihrem vCluster gehören, nicht dem Host-Cluster. Die GPU-Workloads jedes Mandanten laufen auf vollständig getrennter Hardware – ohne gemeinsamen Kernel, ohne gemeinsame GPU-Treiber und ohne Noisy Neighbors. Das ist Isolation auf Hardwareebene, nicht bloß eine Namespace-Grenze.

Auto Nodes liefert die Karpenter-artige Intelligenz, die das wirtschaftlich tragfähig macht. Wenn Sie einen GPU-Workload einreichen, erkennt Karpenter den nicht schedulebaren Pod und erzeugt einen NodeClaim, der die benötigten Ressourcen beschreibt. Die vCluster-Plattform fängt diesen Claim ab und stößt den GCP Node Provider an, der eine Compute-Engine-VM mit dem passenden GPU-Typ bereitstellt. Die neue VM startet über Cloud-Init und tritt Ihrem vCluster als dedizierter Worker Node bei. Ihr Pod wird innerhalb von Sekunden nach der Bereitschaft des Nodes geplant.

Entscheidend: Die Nodes werden automatisch beendet, sobald die Workloads abgeschlossen sind. Bei A100-Instanzen für über 3 US-Dollar pro Stunde macht das aus der GPU-Bereitstellung ein bedarfsgerechtes Utility. Sie profitieren von Karpenters Scheduling-Kompetenz in Kombination mit echter Mandantenisolation.

Netzwerkseitig nutzt vCluster Konnectivity, um die Control Plane mit den Worker Nodes zu verbinden. Die Nodes bauen sichere ausgehende Verbindungen zum vCluster-API-Server auf (über einen LoadBalancer bereitgestellt), sodass Sie kubectl-Befehle nutzen können, ohne direkten Netzwerkzugriff zu benötigen. VPC-Peering oder Firewall-Änderungen sind nicht erforderlich.

Da Sie die Provisionierungsarchitektur nun verstehen, bauen wir sie auf.

Aufbau des GKE-Clusters

📋 Bevor Sie beginnen: Die Bearbeitung von GPU-Quota-Anträgen in GCP kann 24 bis 48 Stunden dauern. Falls noch nicht geschehen, beantragen Sie die GPU-Quota für Ihre Zielregion vor Beginn dieses Tutorials, um Verzögerungen beim Testen der GPU-Workloads zu vermeiden.

Bevor GPU-Nodes automatisch bereitgestellt werden können, brauchen Sie ein sauber konfiguriertes GKE-Fundament. Alle in diesem Tutorial genannten Konfigurationsdateien finden Sie im Repository Liquid-Reply/vCluster-Demo. Klonen Sie es jetzt, um mitzuarbeiten:

Definieren Sie zunächst die Umgebungsvariablen, auf die die folgenden Befehle im weiteren Verlauf zurückgreifen:

Diese Variablen legen Ihren GCP-Projektkontext, die Cluster-Benennung und die Service-Account-Zuordnungen fest, die später für die Workload-Identity-Bindings nötig sind. Passen Sie LOCATION an eine Region mit verfügbarer GPU-Quota für Ihre Ziel-Instanztypen an.

Aktivieren Sie als Nächstes die GCP-APIs, die die Provisionierungskette von Auto Nodes tragen. Die Container-API verwaltet GKE selbst, Compute ermöglicht das Erstellen von VMs für Private Nodes. IAM und Cloud Resource Manager kümmern sich um die Service-Account-Berechtigungen, und Service Usage erlaubt es der Plattform, die API-Verfügbarkeit programmatisch zu prüfen.

Wir legen bewusst einen GKE-Standard-Cluster an und nicht Autopilot. Der von Autopilot verwaltete Node-Lebenszyklus kollidiert mit Private Nodes – vCluster benötigt direkte Kontrolle über die Compute-Engine-VMs, die dem virtuellen Cluster beitreten, was die Abstraktion von Autopilot verhindert. Das Flag --workload-pool aktiviert Workload Identity, sodass sich Kubernetes-Service-Accounts ohne statische Zugangsdaten bei GCP-APIs authentifizieren können.

Installieren Sie bei laufendem Cluster die vCluster Platform:

vcluster platform start

Dieser Befehl rollt die Plattformkomponenten in Ihren Cluster aus und startet die Konfigurationsoberfläche. Prüfen Sie anschließend, ob die Pods im Namespace vcluster-platform den Status Running erreichen. Der soeben installierte Plattform-Controller orchestriert die gesamte weitere GPU-Node-Bereitstellung.

IAM und Workload Identity konfigurieren

Damit die vCluster Platform in Ihrem Namen Compute-Engine-VMs bereitstellen kann, benötigt sie authentifizierten Zugriff auf GCP-APIs. Workload Identity ermöglicht das ohne die Sicherheitsrisiken statischer Service-Account-Schlüssel: Ihr Kubernetes-Service-Account wird direkt auf einen GCP-Service-Account abgebildet, sodass sich Platform-Pods nativ über die Identity Federation von GKE authentifizieren.

Wir folgen dem Prinzip der geringsten Rechte und legen eine eigene IAM-Rolle mit ausschließlich den Berechtigungen an, die Auto Nodes benötigt. Die Datei auto_nodes_role.yaml aus dem Repository definiert diese Berechtigungen präzise – Verwaltung von Compute-Engine-Instanzen, Netzwerkzugriff und die Möglichkeit, Service Accounts an bereitgestellte Nodes anzuhängen.

Erstellen Sie als Nächstes den GCP-Service-Account und richten Sie das Workload-Identity-Binding ein. Dieser dreistufige Vorgang verbindet Ihren Kubernetes-Service-Account (loft im Namespace vcluster-platform) mit einem GCP-Service-Account, der die eigene Auto-Nodes-Rolle trägt.

Die abschließende Annotation vervollständigt die Identitätskette. Wenn Platform-Pods GCP-API-Aufrufe tätigen, tauscht GKE das Kubernetes-Token automatisch gegen GCP-Zugangsdaten ein, die auf Ihren Service Account begrenzt sind.

Prüfen Sie Ihre IAM-Konfiguration, bevor Sie fortfahren:

gcloud iam service-accounts get-iam-policy $GSA_EMAIL

Sie sollten die Rolle workloadIdentityUser an Ihren Kubernetes-Service-Account gebunden sehen.

Wenden Sie schließlich die Node-Provider-Konfiguration an, die der vCluster Platform mitteilt, wie GCP-Ressourcen bereitzustellen sind.

kubectl apply -f auto-nodes/node-provider.yaml

Die Node-Provider-Konfiguration definiert die Node-Typen, die Auto Nodes bereitstellen kann.

Jeder nodeType-Eintrag bildet einen logischen Namen auf eine konkrete Compute-Engine-Instanzkonfiguration ab. Der Block „resources” beschreibt die Angaben, die Kubernetes kennt (CPU, Arbeitsspeicher und GPU-Anzahl), während „properties” die tatsächlichen GCP-Instanzparameter festlegt. Beachten Sie, dass der GPU-Node-Typ im Feld „resources” den Eintrag „nvidia.com/gpu: 1” enthält und „nvidia-tesla-t4” als Beschleuniger referenziert. So ordnet Karpenter GPU-Ressourcenanforderungen dem passenden Instanztyp zu. Nach demselben Muster lassen sich weitere Node-Typen für A100s, L4s oder andere GPU-Konfigurationen ergänzen.

vCluster ausrollen und GPU-Workloads testen

Mit konfiguriertem IAM und gebundener Workload Identity können Sie nun Ihre isolierte GPU-Umgebung anlegen. Der folgende Befehl erstellt einen neuen vCluster mit aktivierten Private Nodes.

Nach dem Verbinden wechselt Ihr kubectl-Kontext in den vCluster. Ab hier zielt jeder Befehl auf Ihre isolierte Umgebung, vollständig getrennt von anderen Mandanten auf demselben GKE-Cluster.

Installieren Sie als Nächstes den NVIDIA GPU Operator, um GPU-Ressourcen innerhalb Ihres vCluster zu verwalten. Fügen Sie zuerst das NVIDIA-Helm-Repository hinzu und installieren Sie dann den Operator. Wir deaktivieren die Treiberinstallation, da Ihre Node-Images bereits vorinstallierte NVIDIA-Treiber enthalten.

Installieren Sie den GPU Operator nun mit aktiviertem Toolkit, Device Plugin und DCGM Exporter, um GPUs für Kubernetes bereitzustellen und Monitoring-Metriken zu liefern.

Und jetzt der Moment der Wahrheit. Die folgenden Befehle rollen einen GPU-Workload aus und lassen Sie Auto Nodes bei der Arbeit beobachten. Der Pod geht zunächst in den Status Pending, da noch keine GPU-Nodes existieren. Karpenter erkennt den nicht schedulebaren Pod, stößt den GCP Node Provider an, und eine Compute-Engine-VM mit Ihrer angegebenen GPU-Konfiguration fährt automatisch hoch.

Ein kurzer Hinweis zum Test-Workload: gpu-workload.yaml ist eine Simulation eines KI-Jobs, keine echte GPU-Berechnung. Es prüft den GPU-Zugriff über nvidia-smi, gibt Treiber- und Speicherinformationen aus und nutzt anschließend Sleep-Befehle, um das Laden eines Modells und Inferenz-Batches nachzustellen. Für Produktiv-Workloads würden Sie echte ML-Frameworks wie PyTorch oder TensorFlow einsetzen. Die GPU-Ressourcenkonfiguration bleibt identisch.

Innerhalb von drei bis fünf Minuten erscheint ein neuer Node in kubectl get nodes. Der Pod wird auf diesem Node geplant, führt Ihren GPU-Workload aus, und nach Abschluss wird der Node automatisch beendet. Ohne manuelles Eingreifen, ohne verschwendete Ressourcen, mit vollständiger Mandantenisolation.

Erkenntnisse und nächste Schritte

Sie haben nun eine leistungsfähige Lösung umgesetzt: die Einfachheit eines einzelnen GKE-Clusters, kombiniert mit der Isolation dedizierter Cluster für teure GPU-Workloads. Diese Architektur beseitigt den Betriebsaufwand für die Verwaltung mehrerer Cluster und liefert zugleich die Trennung auf Hardwareebene, die mandantenfähiges KI-Training erfordert.

Fassen wir zusammen, was wir gebaut haben. Workload Identity ermöglicht eine schlüssellose Authentifizierung zwischen vCluster Platform und GCP-APIs. Karpenter-gestützte Auto Nodes stellen GPU-Instanzen nur dann bereit, wenn Workloads sie benötigen. Private Nodes sorgen für vollständige Mandantenisolation, sodass die Trainingsjobs jedes Teams auf dedizierten Compute-Engine-VMs laufen, auf die kein anderer Mandant zugreifen kann.

Vor der Skalierung in die Produktion sind einige Punkte zu klären. Beantragen Sie ausreichend GPU-Quota in Ihren Zielregionen rechtzeitig im Voraus. Konfigurieren Sie Disruption Policies, um Kosteneinsparungen und Unterbrechungen von Trainingsjobs auszubalancieren. Der installierte DCGM Exporter speist GPU-Metriken in Ihren bestehenden Monitoring-Stack ein, um die Auslastung nachzuverfolgen.

Sie möchten tiefer einsteigen? Das Repository Liquid-Reply/vCluster-demo enthält alle in diesem Tutorial genannten Konfigurationsdateien. Für Produktiv-Deployments mit erweiterten Funktionen wie Team-Verwaltung, Single Sign-on (SSO) und Audit-Logging werfen Sie einen Blick auf die Enterprise-Funktionen der vCluster Platform (VclusterKubernetes Solutions for AI, Platform Engineering & Cost Efficiency | vCluster).