Kubernetes für GPU-Orchestrierung: Verwaltung von Multi-Tausend-GPU-Clustern

Aktualisiert am 8. Dezember 2025

Dezember 2025 Update: Kubernetes 1.31+ Dynamic Resource Allocation (DRA) ist jetzt GA und ermöglicht feinkörnige GPU-Partitionierung und Time-Slicing. NVIDIA GPU Operator 24.6+ fügt Blackwell-Unterstützung und verbessertes MIG-Management hinzu. Kueue (Kubernetes-natives Job-Queueing) erreicht Produktionsreife für KI-Workloads. Run:ai und CoreWeave demonstrieren 50.000+ GPU-Cluster auf Kubernetes. Multi-Cluster-Föderationstools (Liqo, Admiralty) ermöglichen Cloud-übergreifende GPU-Orchestrierung. vGPU-Unterstützung verbessert sich für Multi-Tenant-Inference-Deployments.

OpenAI orchestriert 25.000 GPUs über mehrere Kubernetes-Cluster, um GPT-Modelle zu trainieren, unter Verwendung benutzerdefinierter Operators, die automatisch GPU-Ausfälle behandeln, Workloads in Echtzeit neu verteilen und 97% Auslastung aufrechterhalten, obwohl Hardware-Ausfälle durchschnittlich alle 2,5 Stunden auftreten.¹ Das Infrastruktur-Team des Unternehmens stellte fest, dass Standard-Kubernetes bei etwa 5.000 Nodes ohne umfangreiche Modifikationen kollabiert, was sie zwang, hierarchische Cluster-Föderation, benutzerdefinierte Scheduling-Algorithmen und GPU-bewusstes Autoscaling zu implementieren, das jede 30.000-Dollar-H100 als wertvolle Ressource behandelt, die individuelle Nachverfolgung erfordert. Die Verwaltung von GPUs im großen Maßstab unterscheidet sich grundlegend von CPU-Orchestrierung—eine ausgefallene GPU während des verteilten Trainings kann Millionen an Rechenzeit verschwenden, während schlechtes Scheduling, das über NVLink verbundene GPUs trennt, eine 8-fache Leistungsverschlechterung verursacht. Die Organisationen, die erfolgreich Tausende von GPUs auf Kubernetes orchestrieren, berichten von 35% besserer Auslastung, 60% schnelleren Deployment-Zeiten und 90% Reduktion des operativen Overheads im Vergleich zur Bare-Metal-Verwaltung.²

Kubernetes dominiert die Container-Orchestrierung mit 88% Marktanteil, aber GPU-Unterstützung kam spät und bleibt im großen Maßstab herausfordernd.³ Der NVIDIA GPU Operator, der 2019 eingeführt wurde, brachte schließlich Enterprise-Grade GPU-Management zu Kubernetes und ermöglichte Funktionen wie dynamische Treiberinstallation, automatisches Device-Plugin-Deployment und GPU-Gesundheitsüberwachung. Organisationen, die KI-Workloads auf Kubernetes ausführen, müssen Device-Plugin-Konfigurationen, Node-Affinity-Regeln, topologiebewusstes Scheduling und Ressourcen-Quotas navigieren, die verhindern, dass einzelne Teams GPU-Ressourcen monopolisieren. Doch diejenigen, die Kubernetes für GPU-Orchestrierung beherrschen, erhalten die Fähigkeit, Tausende von GPUs als einen einzigen programmierbaren Ressourcen-Pool zu behandeln und Auslastungsraten sowie operative Effizienz zu erreichen, die mit traditionellen HPC-Schedulern unmöglich sind.

GPU Device Plugin Architektur

Das Kubernetes Device Plugin Framework ermöglicht GPU-Erkennung, -Zuweisung und -Gesundheitsüberwachung über Cluster hinweg:

NVIDIA GPU Device Plugin dient als primäre Schnittstelle zwischen Kubernetes und NVIDIA GPUs.⁴ Das Plugin läuft als DaemonSet auf jedem GPU-Node und registriert GPUs als planbare Ressourcen beim kubelet. Während der Initialisierung fragt das Plugin die NVIDIA Management Library (NVML) ab, um verfügbare GPUs, ihre Speicherkapazität, Compute Capability und Interconnect-Topologie zu ermitteln. Das Plugin bewirbt GPUs beim Kubernetes-Scheduler unter Verwendung des Ressourcennamens nvidia.com/gpu, wodurch Pods GPUs über Standard-Ressourcenspezifikationen anfordern können.

Device Plugin Registrierungsablauf: 1. Plugin startet und erkennt lokale GPUs via NVML 2. Registriert sich beim kubelet über Unix-Socket unter /var/lib/kubelet/device-plugins/ 3. Bewirbt verfügbare GPUs mit eindeutigen Device-IDs 4. Implementiert Allocate() RPC für Container-GPU-Zuweisung 5. Überwacht GPU-Gesundheit und meldet Ausfälle an kubelet 6. Behandelt GPU-Bereinigung bei Pod-Terminierung

Multi-Instance GPU (MIG) Unterstützung ermöglicht die Partitionierung von A100 und H100 GPUs in isolierte Instanzen.⁵ Jede MIG-Instanz erscheint für Kubernetes als separate GPU, was feinkörnige Ressourcenzuweisung ermöglicht. Das Device Plugin verwaltet MIG-Profile und übernimmt Erstellung, Löschung und Zuweisung von Instanzen. Organisationen erreichen 7-fach bessere GPU-Auslastung durch Partitionierung unterausgelasteter GPUs für kleinere Workloads. MIG-Konfiguration erfordert sorgfältige Planung, da Partitionierungsmodi nicht ohne Node-Draining geändert werden können.

Alternative Device Plugins bieten Hersteller-Vielfalt: - AMD Device Plugin unterstützt ROCm-fähige GPUs wie MI250X - Intel Device Plugin verwaltet Intel GPUs und Gaudi-Beschleuniger - Xilinx FPGA Device Plugin orchestriert FPGA-Ressourcen - Google TPU Device Plugin für GKE-Cluster

Scheduling-Strategien für GPU-Workloads

Effektives GPU-Scheduling maximiert die Auslastung bei gleichzeitiger Aufrechterhaltung der Leistung:

Gang Scheduling stellt sicher, dass verteilte Training-Jobs alle angeforderten GPUs gleichzeitig erhalten. Ohne Gang Scheduling verursacht partielle Ressourcenzuweisung Deadlocks—Jobs warten ewig auf verbleibende GPUs, die nie verfügbar werden. Kubernetes-Scheduler-Plugins wie Volcano und Apache YuniKorn implementieren Gang Scheduling durch PodGroups.⁶ Jobs spezifizieren minimale GPU-Anforderungen, und der Scheduler weist entweder alle Ressourcen zu oder reiht den gesamten Job in die Warteschlange ein. Gang Scheduling reduziert die Cluster-Auslastung um 10-15%, verhindert aber Training-Job-Verhungern.

Topologiebewusstes Scheduling optimiert die GPU-Platzierung basierend auf Hardware-Interconnects. Über NVLink verbundene GPUs erreichen 600GB/s Bandbreite gegenüber 32GB/s über PCIe.⁷ Der Scheduler untersucht die Node-Topologie, um verwandte Pods auf GPUs mit schnellen Interconnects zu platzieren. NVIDIA GPU Feature Discovery beschriftet Nodes mit Topologieinformationen, die Affinity-Regeln ermöglichen. Schlechte Topologieentscheidungen verursachen 3-8-fache Leistungsverschlechterung für kommunikationsintensive Workloads. Topologiebewusstsein wird kritisch bei mehr als 8 GPUs pro Job.

Bin Packing vs. Verteilung: Bin Packing konsolidiert Workloads auf weniger Nodes, verbessert Cache-Lokalität und reduziert Netzwerkverkehr. Verteilung verteilt Arbeit über Nodes für bessere Fehlertoleranz und Wärmemanagement. Die optimale Strategie hängt von Workload-Charakteristiken ab—Training-Jobs profitieren von Bin Packing, während Inference Verteilung bevorzugt. Dynamische Strategien passen sich basierend auf Cluster-Auslastung und Workload-Mix an.

Priorität und Preemption: Produktions-Workloads erhalten höhere Priorität als Entwicklungs-Jobs. Der Scheduler verdrängt niedrigerprioritäre Pods, wenn Ressourcen knapp werden. Sorgfältige Prioritätskonfiguration verhindert, dass Forschungs-Jobs Produktions-Inference blockieren. Preemption-Checkpointing stellt sicher, dass Trainingsfortschritt nicht verloren geht. Prioritätsklassen reichen von systemkritisch (1000000) bis Entwicklung (100).

Fair Sharing und Quotas: Ressourcen-Quotas verhindern, dass einzelne Teams GPUs monopolisieren. Hierarchische Quotas ermöglichen organisationsweite Limits mit teamspezifischen Sub-Quotas. Fair-Share-Scheduling stellt gerechte Ressourcenverteilung über Zeit sicher. Nutzer, die weniger Ressourcen verbrauchen, sammeln Credits für zukünftige Burst-Kapazität. Queue-Systeme wie Kueue bieten Job-Queueing mit ausgeklügelter Admission Control.

Skalierungsüberlegungen

Die Skalierung von Kubernetes auf Tausende von GPUs erfordert architektonische Modifikationen:

Cluster-Größenbeschränkungen: Einzelne Kubernetes-Cluster unterstützen maximal 5.000 Nodes, bevor die etcd-Leistung degradiert.⁸ Die API-Server-Last steigt quadratisch mit der Node-Anzahl aufgrund von Watch-Mechanismen. Controller-Manager-Reconciliation-Loops verlangsamen sich über 1.000 Nodes hinaus. Netzwerkrichtlinien werden im großen Maßstab unhandlich. Die meisten Organisationen begrenzen Cluster auf 500-1.000 GPU-Nodes für operative Stabilität.

Multi-Cluster-Föderation: Große Deployments verwenden mehrere Kubernetes-Cluster, die durch Föderation verwaltet werden. Admiralty oder Virtual Kubelet ermöglichen Cluster-übergreifendes Scheduling. GitOps-Tools wie Flux oder ArgoCD synchronisieren Konfigurationen über Cluster hinweg. Service-Mesh-Technologien bieten Cluster-übergreifendes Networking. Föderation fügt Komplexität hinzu, ermöglicht aber horizontale Skalierung über Einzel-Cluster-Limits hinaus.

Hierarchisches Ressourcenmanagement: Organisieren Sie Cluster hierarchisch mit Management-Clustern, die Workload-Cluster steuern. Management-Cluster führen Control-Plane-Komponenten und Scheduling-Logik aus. Workload-Cluster hosten GPU-Pods ohne komplexe Controller. Hierarchisches Design reduziert den Blast-Radius von Ausfällen. Klare Trennung von Verantwortlichkeiten vereinfacht die Fehlerbehebung.

Custom Resource Definitions (CRDs) für KI-Workloads: - TrainingJob: Definiert verteilte Training-Spezifikationen - InferenceService: Verwaltet Model-Serving-Deployments - GPUPool: Repräsentiert logische GPU-Gruppierungen - Checkpoint: Behandelt Training-State-Persistenz - ModelVersion: Verfolgt Modell-Iterationen und Lineage

Leistungsoptimierungen für Skalierung: - Deaktivieren Sie ungenutzte Admission-Webhooks zur Reduzierung der API-Latenz - Implementieren Sie Pod-Topology-Spread-Constraints für gleichmäßige Verteilung - Verwenden Sie lokale SSD für Container-Images zur Vermeidung von Netzwerk-Engpässen - Aktivieren Sie CPU Manager für garantierte CPU-Zuweisung - Konfigurieren Sie Huge Pages für große Modell-Speicheranforderungen

Monitoring und Observability

Umfassendes Monitoring verhindert millionenteure GPU-Leerlaufzeiten:

NVIDIA Data Center GPU Manager (DCGM) liefert GPU-spezifische Metriken, die über Standard-Kubernetes-Monitoring nicht verfügbar sind.⁹ DCGM exportiert 100+ Metriken einschließlich SM-Auslastung, Speicherbandbreite, Temperatur, Stromverbrauch und ECC-Fehlern. Prometheus-Integration ermöglicht langfristige Metrikspeicherung und Alerting. Grafana-Dashboards visualisieren GPU-Leistung über die gesamte Flotte. Benutzerdefinierte Alerts erkennen unterausgelastete GPUs, thermisches Throttling und Hardware-Degradierung, bevor Ausfälle auftreten.

Wichtige GPU-Metriken für Kubernetes-Monitoring: - GPU-Auslastung: Prozentsatz aktiver SMs (Ziel >90%) - Speicherauslastung: Zugewiesener GPU-Speicher versus verfügbar - Stromverbrauch: Tatsächlich versus TDP zeigt Throttling an - Temperatur: GPU- und Speichertemperaturen - PCIe-Bandbreite: Datenübertragungsraten zur/von der GPU - NVLink-Traffic: Inter-GPU-Kommunikationsbandbreite - Training-Metriken: Loss-Kurven, Gradienten-Normen, Learning Rates - Inference-Metriken: Anfragen pro Sekunde, P99-Latenz, Batch-Größen

Distributed Tracing verfolgt Anfragen über mehrere GPUs und Nodes hinweg. OpenTelemetry-Instrumentierung erfasst Training-Step-Zeiten, Datenlade-Latenz und Checkpoint-Dauern. Jaeger oder Tempo bieten verteilte Trace-Speicherung und -Analyse. Korrelation zwischen Traces und Metriken identifiziert Leistungsengpässe. End-to-End-Sichtbarkeit reduziert die Mean Time to Resolution um 70%.

Log-Aggregation zentralisiert Logs von Tausenden von GPU-Pods. Fluentd oder Fluent Bit sammeln Container-Logs mit minimalem Overhead. Elasticsearch speichert Logs mit automatischer Indizierung und Aufbewahrungsrichtlinien. Kibana ermöglicht Log-Suche und -Analyse über den gesamten Cluster. Strukturiertes Logging mit konsistenten Formaten vereinfacht die Fehlerbehebung. Alerting bei Fehlermustern, die auf systemische Probleme hinweisen.

Introl deployt und verwaltet Kubernetes-Cluster für GPU-Orchestrierung in unserem globalen Abdeckungsgebiet, mit Expertise bei Skalierung auf 10.000+ GPU-Deployments.¹⁰ Unsere Platform-Engineering-Teams haben benutzerdefinierte Operators und Scheduling-Erweiterungen für optimale GPU-Auslastung implementiert.

Produktions-Deployment-Muster

Training-Cluster-Architektur bei Anthropic: - Skalierung: 4.000 GPUs über 8 Kubernetes-Cluster - Topologie: Hierarchische Föderation mit zentralem Scheduler - Storage: Verteiltes Lustre-Dateisystem für Trainingsdaten - Networking: RoCE v2 Fabric mit 200Gbps pro Node - Scheduling: Benutzerdefinierter Gang-Scheduler mit Topologiebewusstsein - Monitoring: DCGM + Prometheus mit 15-Sekunden-Scrape-Intervallen - Ergebnis: 94% GPU-Auslastung, 50% Reduktion der Trainingszeit

Inference-Plattform bei Uber: - Workload: 500 Millionen Vorhersagen täglich - Infrastruktur: 2.000 T4 GPUs über 20 Regionen - Orchestrierung: Kubernetes mit Knative für Serverless - Autoscaling: Predictive Scaling basierend auf Traffic-Mustern - Load Balancing: Envoy-Proxy mit Least-Latency-Routing - Optimierung: Model-Caching reduziert Cold Start auf 2 Sekunden - Ergebnis: 65% Kostenreduktion gegenüber vorheriger Architektur

Hybrid Training-Inference bei Spotify: - GPUs: 3.000 gemischte V100/A100/T4-Flotte - Scheduling: Time-Sliced Sharing für Entwicklung - Isolation: Kata-Container für Multi-Tenant-Sicherheit - Cos

[Inhalt für Übersetzung gekürzt]