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) jetzt GA, ermöglicht granulare GPU-Partitionierung und Time-Slicing. NVIDIA GPU Operator 24.6+ fügt Blackwell-Unterstützung und verbesserte MIG-Verwaltung hinzu. Kueue (Kubernetes-native Job-Warteschlangen) erreicht Produktionsreife für AI-Workloads. Run:ai und CoreWeave demonstrieren 50.000+ GPU-Cluster auf Kubernetes. Multi-Cluster-Föderationswerkzeuge (Liqo, Admiralty) ermöglichen Cloud-übergreifende GPU-Orchestrierung. vGPU-Unterstützung verbessert sich für Multi-Tenant-Inferenz-Deployments.

OpenAI orchestriert 25.000 GPUs über mehrere Kubernetes-Cluster zur Schulung von GPT-Modellen, verwendet benutzerdefinierte Operatoren, die automatisch GPU-Ausfälle handhaben, Workloads in Echtzeit ausbalancieren und 97% Auslastung trotz Hardware-Ausfällen aufrechterhalten, die durchschnittlich alle 2,5 Stunden auftreten.¹ Das Infrastruktur-Team des Unternehmens entdeckte, dass Standard-Kubernetes bei etwa 5.000 Knoten ohne umfangreiche Modifikationen zusammenbricht, was sie dazu zwang, hierarchische Cluster-Föderation, benutzerdefinierte Scheduling-Algorithmen und GPU-bewusstes Autoscaling zu implementieren, das jede $30.000 H100 als wertvolle Ressource behandelt, die individuelle Überwachung erfordert. GPU-Management im großen Maßstab unterscheidet sich grundlegend von CPU-Orchestrierung—eine ausgefallene GPU während verteilten Trainings kann Millionen an Rechenzeit verschwenden, während schlechtes Scheduling, das über NVLink verbundene GPUs trennt, zu 8-facher Leistungsverschlechterung führt. Organisationen, die erfolgreich Tausende von GPUs auf Kubernetes orchestrieren, berichten von 35% besserer Auslastung, 60% schnelleren Bereitstellungszeiten und 90% Reduzierung des betrieblichen Aufwands 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 endlich Enterprise-Grade GPU-Management zu Kubernetes und ermöglichte Funktionen wie dynamische Treiberinstallation, automatische Device-Plugin-Bereitstellung und GPU-Gesundheitsüberwachung. Organisationen, die AI-Workloads auf Kubernetes betreiben, müssen Device-Plugin-Konfigurationen, Node-Affinity-Regeln, topologie-bewusstes Scheduling und Ressourcenkontingente navigieren, die verhindern, dass einzelne Teams GPU-Ressourcen monopolisieren. Dennoch gewinnen diejenigen, die Kubernetes für GPU-Orchestrierung beherrschen, die Fähigkeit, Tausende von GPUs als einen einzigen programmierbaren Ressourcenpool zu behandeln und Auslastungsraten und betriebliche Effizienz zu erreichen, die mit traditionellen HPC-Schedulern unmöglich sind.

GPU Device Plugin Architektur

Das Kubernetes Device Plugin Framework ermöglicht GPU-Erkennung, -Zuordnung 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-Knoten 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, Rechenleistung und Interconnect-Topologie zu entdecken. Das Plugin bewirbt GPUs beim Kubernetes-Scheduler unter Verwendung des Ressourcennamens nvidia.com/gpu und ermöglicht es Pods, GPUs durch Standard-Ressourcenspezifikationen anzufordern.

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

Multi-Instance GPU (MIG) Unterstützung ermöglicht die Partitionierung von A100 und H100 GPUs in isolierte Instanzen.⁵ Jede MIG-Instanz erscheint als separate GPU für Kubernetes und ermöglicht granulare Ressourcenzuordnung. Das Device Plugin verwaltet MIG-Profile und behandelt Erstellung, Löschung und Zuordnung 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 Knoten-Drainage geändert werden können.

Alternative Device Plugins bieten Anbietervielfalt: - AMD Device Plugin unterstützt ROCm-aktivierte 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 Leistungserhaltung:

Gang Scheduling stellt sicher, dass verteilte Trainings-Jobs alle angeforderten GPUs gleichzeitig erhalten. Ohne Gang Scheduling verursacht partielle Ressourcenzuordnung 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 ordnet entweder alle Ressourcen zu oder reiht den gesamten Job ein. Gang Scheduling reduziert die Cluster-Auslastung um 10-15%, verhindert aber Trainings-Job-Verarmung.

Topologie-bewusstes Scheduling optimiert GPU-Platzierung basierend auf Hardware-Interconnects. GPUs, die über NVLink verbunden sind, erreichen 600GB/s Bandbreite gegenüber 32GB/s über PCIe.⁷ Der Scheduler untersucht Knoten-Topologie, um verwandte Pods auf GPUs mit schnellen Interconnects zu platzieren. NVIDIA GPU Feature Discovery kennzeichnet Knoten mit Topologie-Informationen, die Affinitätsregeln ermöglichen. Schlechte Topologie-Entscheidungen verursachen 3-8-fache Leistungsverschlechterung für kommunikationsintensive Workloads. Topologie-Bewusstsein wird kritisch jenseits von 8 GPUs pro Job.

Bin Packing vs Spreading: Bin Packing konsolidiert Workloads auf weniger Knoten und verbessert Cache-Lokalität und reduziert Netzwerkverkehr. Spreading verteilt Arbeit über Knoten für bessere Fehlertoleranz und Wärmemanagement. Die optimale Strategie hängt von Workload-Charakteristika ab—Trainings-Jobs profitieren von Bin Packing, während Inferenz Spreading 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 niedrigere Prioritäts-Pods, wenn Ressourcen knapp werden. Sorgfältige Prioritätskonfiguration verhindert, dass Forschungs-Jobs Produktions-Inferenz blockieren. Preemption-Checkpointing stellt sicher, dass Trainings-Fortschritt nicht verloren geht. Prioritätsklassen reichen von systemkritisch (1000000) bis Entwicklung (100).

Fair Sharing und Kontingente: Ressourcenkontingente verhindern, dass einzelne Teams GPUs monopolisieren. Hierarchische Kontingente ermöglichen organisationsweite Limits mit teamspezifischen Unter-Kontingenten. Fair-Share-Scheduling sorgt für gerechte Ressourcenverteilung über die Zeit. Benutzer, die weniger Ressourcen verbrauchen, sammeln Kredite für zukünftige Burst-Kapazität. Warteschlangensysteme wie Kueue bieten Job-Warteschlangen mit ausgeklügelter Zugangssteuerung.

Skalierungsüberlegungen

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

Cluster-Größen-Limitierungen: Einzelne Kubernetes-Cluster unterstützen maximal 5.000 Knoten, bevor die etcd-Performance nachlässt.⁸ API-Server-Last steigt quadratisch mit Knotenzahl aufgrund von Watch-Mechanismen. Controller-Manager-Reconciliation-Schleifen verlangsamen sich jenseits von 1.000 Knoten. Netzwerk-Policies werden im großen Maßstab unhandlich. Die meisten Organisationen begrenzen Cluster auf 500-1.000 GPU-Knoten für betriebliche 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-übergreifende Vernetzung. Föderation fügt Komplexität hinzu, ermöglicht aber horizontale Skalierung jenseits von Einzel-Cluster-Limits.

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 der Verantwortlichkeiten vereinfacht Fehlerbehebung.

Custom Resource Definitions (CRDs) für AI-Workloads: - TrainingJob: Definiert verteilte Trainings-Spezifikationen - InferenceService: Verwaltet Model-Serving-Deployments - GPUPool: Repräsentiert logische GPU-Gruppierungen - Checkpoint: Behandelt Trainings-Zustand-Persistierung - ModelVersion: Verfolgt Modell-Iterationen und -Abstammung

Performance-Optimierungen für Skalierung: - Deaktivieren Sie ungenutzte Admission Webhooks zur Reduzierung der API-Latenz - Implementieren Sie Pod-Topologie-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-Zuordnung - Konfigurieren Sie Huge Pages für große Modell-Speicheranforderungen

Überwachung und Observability

Umfassende Überwachung verhindert millionenschwere GPU-Leerlaufzeiten:

NVIDIA Data Center GPU Manager (DCGM) bietet 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 Metrik-Speicherung und Alerting. Grafana-Dashboards visualisieren GPU-Performance über die gesamte Flotte. Benutzerdefinierte Alerts erkennen unterausgelastete GPUs, thermische Drosselung und Hardware-Degradation vor Ausfällen.

Wichtige GPU-Metriken für Kubernetes-Monitoring: - GPU-Auslastung: Prozentsatz aktiver SMs (Ziel >90%) - Speicher-Auslastung: Zugeordneter vs. verfügbarer GPU-Speicher - Stromverbrauch: Tatsächlicher vs. TDP zeigt Drosselung an - Temperatur: GPU- und Speichertemperaturen - PCIe-Bandbreite: Datenübertragungsraten zu/von GPU - NVLink-Traffic: Inter-GPU-Kommunikationsbandbreite - Trainings-Metriken: Verlustkurven, Gradient-Normen, Lernraten - Inferenz-Metriken: Anfragen pro Sekunde, P99-Latenz, Batch-Größen

Distributed Tracing verfolgt Anfragen über mehrere GPUs und Knoten. OpenTelemetry-Instrumentierung erfasst Trainings-Schritt-Zeiten, Datenlade-Latenz und Checkpoint-Dauern. Jaeger oder Tempo bieten verteilte Trace-Speicherung und -Analyse. Korrelation zwischen Traces und Metriken identifiziert Performance-Engpässe. End-to-End-Sichtbarkeit reduziert mittlere Zeit zur Lösung um 70%.

Log-Aggregation zentralisiert Logs von Tausenden 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 Fehlerbehebung. Alert bei Fehlermustern, die systemische Probleme anzeigen.

Introl stellt Kubernetes-Cluster für GPU-Orchestrierung in unserem globalen Abdeckungsbereich bereit und verwaltet sie, mit Expertise in der Skalierung auf 10.000+ GPU-Deployments.¹⁰ Unsere Platform-Engineering-Teams haben benutzerdefinierte Operatoren und Scheduling-Verbesserungen für optimale GPU-Auslastung implementiert.

Produktions-Deployment-Muster

Trainings-Cluster-Architektur bei Anthropic: - Größe: 4.000 GPUs über 8 Kubernetes-Cluster - Topologie: Hierarchische Föderation mit zentralem Scheduler - Speicher: Verteiltes Lustre-Dateisystem für Trainingsdaten - Netzwerk: RoCE v2 Fabric mit 200Gbps pro Knoten - Scheduling: Benutzerdefinierter Gang Scheduler mit Topologie-Bewusstsein - Monitoring: DCGM + Prometheus mit 15-Sekunden-Scrape-Intervallen - Ergebnis: 94% GPU-Auslastung, 50% Reduzierung der Trainingszeit

Inferenz-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: Prädiktive Skalierung basierend auf Traffic-Mustern - Load Balancing: Envoy Proxy mit Least-Latency-Routing - Optimierung: Modell-Caching reduziert Cold Start auf 2 Sekunden - Ergebnis: 65% Kostenreduzierung 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