Kubernetes und GPUs: Orchestrierung für ML/KI-Workloads

Der Blickwinkel dieses Artikels: wie Kubernetes eine GPU-Last platziert, die Rolle des Schedulers, die Knappheit der Ressource, und was Observability zeigen muss. Eine Ebene über der technischen Integration. Das Teilen zwischen Teams behandelt MIG, Time-Slicing und Quoten, die Optimierung der Inferenz-Engine Batching und Latenz.

Einleitung

Die Explosion der KI-Nutzung, vom Training komplexer Modelle bis zu Inferenzlasten im grossen Massstab, hat GPUs ins Zentrum moderner Architekturen gerückt. Knapp und teuer, müssen diese Beschleuniger optimal genutzt werden. Kubernetes, inzwischen Orchestrierungsstandard für cloud-native Anwendungen, setzt sich schrittweise als zentrale Plattform durch, auf der GPU-Verwaltung, Skalierbarkeit und Automatisierung der KI-Pipelines zusammenlaufen.

Zunehmend native GPU-Einbindung in Kubernetes

Die GPU-Unterstützung in Kubernetes beruht vor allem auf dem Device Plugin Framework, seit mehreren Versionen stabil. Dieser Mechanismus stellt spezialisierte Hardwareressourcen, GPUs von NVIDIA und AMD sowie weitere Beschleuniger, der Kubernetes-API bereit, ohne das Kubelet zu ändern. In den meisten Umgebungen stützt sich diese Einbindung auf Stacks der Hersteller wie den NVIDIA GPU Operator, der Treiber, DCGM, das Device Plugin und die nötigen Komponenten automatisch ausrollt.

Das NVIDIA-Plugin bleibt am weitesten verbreitet: Es registriert GPUs dynamisch und stellt sie als Ressourcen nvidia.com/gpu bereit. Dieses Modell sichert die exklusive Zuteilung der Ressourcen und lässt dem Scheduler zugleich die Freiheit, KI-Pods nur auf passenden Knoten zu platzieren. Kubernetes unterstützt so Lasten mit 1, 2 oder mehr GPUs, wie sie beim Fine-Tuning oder bei Multi-Modell-Inferenz häufig sind.

Aufkommende Fähigkeiten wie Multi-Instance GPU (MIG), Formen von GPU-Sharing über MPS oder Operatoren Dritter sowie feingranulare Zuteilungsprofile zeigen einen Trend: leichten Inferenzlasten isolierte Partitionen geben und ganze GPUs dem intensiven Training vorbehalten.

Fortgeschrittene Orchestrierung von Machine-Learning-Lasten

Über die Zuteilung hinaus liefert Kubernetes die Primitive, um verteilte Verarbeitung zu orchestrieren. Moderne Modelle, LLM, multimodale Architekturen, Vision-Pipelines, laufen selten auf einer einzigen GPU. KI-Umgebungen stützen sich in der Regel auf spezialisierte Operatoren:

• Kubeflow Training Operator, DeepSpeed und Megatron-LM für verteiltes Training
• Ray Serve für verteilte Inferenz und parallele Ausführungsgraphen
• MPI Operator für Lasten mit hohen Kommunikationsanforderungen

Diese Operatoren übernehmen die kritischen Phasen des Lebenszyklus, Initialisierung der Worker, Umgang mit Ausfällen, Synchronisation, horizontale Skalierung und das automatische Sichern von Checkpoints auf NVMe-Volumes oder verteiltem Storage (CephFS, Longhorn, Lustre und weitere).

Netzseitig profitieren die schwersten KI-Lasten von CNI mit RDMA- oder SR-IOV-Unterstützung, um die Synchronisationslatenz zwischen Knoten zu senken. Kubernetes kann diese Schnittstellen über eigene Device Plugins für Hochdurchsatz-NICs bereitstellen, ein kritischer Punkt bei Modellen mit mehreren zehn Milliarden Parametern. Manche Multi-AZ- oder Multi-Rechenzentrums-Umgebungen, etwa von souveränen Cloud-Anbietern wie Hikube, optimieren diese Kommunikation zusätzlich über Interconnects mit niedriger Latenz.

Mit der Knappheit an GPUs umgehen: Quoten, Governance und Effizienz

In Multi-Tenant-Umgebungen, Data Labs, interne Plattformen, F&E-Cluster, sind GPUs ein betrieblicher Engpass. Kubernetes bringt eine Reihe von Governance-Mechanismen, um die Zuteilung zu steuern:

• ResourceQuota, um die GPU-Nutzung je Namespace zu deckeln
• LimitRange, um Mindest- oder Höchstwerte je Pod vorzugeben
• PriorityClass, um zwischen kritischen Lasten (Live-Inferenz) und Batch-Jobs (Training) abzuwägen
• Affinitäten und Anti-Affinitäten, um die Platzierung anspruchsvoller Aufgaben zu optimieren

Compliance-Controller wie OPA Gatekeeper und Kyverno gehen weiter und erzwingen Sicherheitsrichtlinien, Beschränkung der zugelassenen Images, Kontrolle der Privilegien, geforderte Labels für das GPU-Scheduling oder Prüfung der Rechte für den Zugriff auf die Devices /dev/nvidia*.

Observability, unerlässlich, um Leistung und Kosten zu optimieren

Sicht auf die reale GPU-Nutzung ist unerlässlich. Kubernetes stützt sich auf das Ökosystem NVIDIA DCGM, um präzise Metriken bereitzustellen:

• Auslastung der Streaming Multiprocessors (SM)
• Speicherbandbreite
• Energieverbrauch
• PCIe- und NVLink-Nutzung
• ECC-Fehler

Mit den DCGM-Prometheus-Exportern lässt sich die GPU-Sättigung analysieren und erkennen, welche Lasten unterdurchschnittlich laufen oder wo bei verteiltem Training Netzengpässe entstehen. Diese Daten speisen die Optimierungsstrategien: Anpassung der Batch-Grösse, Neuverteilung der Worker, Feinabstimmung der topologischen Platzierung oder Neukonfiguration des GPU-Pools innerhalb der Knoten.

Dabei gelten für Trainingslasten (Batch-Jobs, oft verdrängbar und sehr anspruchsvoll) andere Bedingungen als für Inferenzlasten (durchlaufende Dienste mit Latenzanforderungen). Kubernetes bietet einen einheitlichen Rahmen, um beide Familien stimmig zu behandeln.

Kubernetes als Eckpfeiler moderner KI-Architekturen

Das Kubernetes-Ökosystem hat sich um die Bedürfnisse der KI verdichtet:

• schnelle NVMe-Volumes für Datensätze,
• für die Modellsynchronisation optimierte Netze,
• spezialisierte Inferenzserver (vLLM, TGI, Triton),
• integrierte MLOps-Werkzeuge (MLflow, Argo, Kubeflow Pipelines).

Die laufenden Entwicklungen, topologiebewusstes Scheduling, Unterstützung heterogener Beschleuniger (TPU, NPU, RDU), Mechanismen zur GPU-Autoskalierung, dynamische logische Aufteilung und Optimierung der Multi-GPU-Platzierung, verstärken diesen Trend weiter. In einer Zeit, in der GPUs zu einem strategischen Aktivum werden, etabliert sich Kubernetes als eines der Schlüsselwerkzeuge, um ihre Nutzung zu maximieren und dabei Kosten, Leistung und Servicequalität in modernen KI-Umgebungen im Griff zu behalten.