„Kubernetes ist ein Biest“, so die Cloud-Native-Experten Narang und Pathak Für LLMs ist Kubernetes das perfekte Zuhause, man muss es nur einrichten

Die Einrichtung von Kubernetes für KI-Workloads ist in vollem Gange, im neuen Zuhause wird auch schon munter produziert. Wie das funktioniert, wo es noch tropft, was provisorisch ist und was noch hinzukommen wird, erläutern Saloni Narang und Saiyam Pathak, die Köpfe hinter der Cloud Native-Lernplattform „Kubesimplify“.

Kubernetes kann längst viel mehr als Container. Ausgerechnet auf den Container Days 2025 in Hamburg war die Aussage unüberhörbar. Das soll etwa für standardisierte Cloud-APIs im europäischen Projekt „Neonephos“ gelten, aber auch für die Skalierung von KI-Workloads (Künstliche Intelligenz).

Wie genau sich Kubernetes für KI-Workloads einrichten lässt und was noch gemacht werden muss, erklärten auf der Konferenz und im Gespräch mit DataCenter-Insider Saiyam Pathak und Saloni Narang. Gemeinsam koordinieren Pathak und Narang das Lernportal Kubesimplify, das Entwickler für Cloud Native fit machen will.

Als etablierte Plattform für die Orchestrierung und das Ressourcenmanagement komplexer Machine-Learning-Workloads sei Kubernetes das natürliche Zuhause für LLMs (Large Language Models, große Sprachmodelle), betont Saloni Narang. Dies habe gerade OpenAI bei „ChatGPT“ und „DALL-E“ demonstriert. Dem Unternehmen gelang es noch 2018, seine Trainings-Cluster in Kubernetes auf 2.500 und 2021 auf 7.500 Nodes (virtuelle oder physische Maschinen) zu skalieren. Auch heute „ist Kubernetes ein zentraler Bestandteil der Fähigkeit von OpenAI, seine Operationen sowohl in Cloud- als auch in Bare-Metal-Umgebungen effizient zu skalieren“, so Narang.

Skalierung bleibt dabei eine beständige Herausforderung. Wo OpenAI seinerzeit mit mehreren Netzwerk-Backend-Systemen hantieren, die IP-Adressierung manuell optimieren und auch die einzelnen Geräte im Voraus einzeln und statisch über Device Plugins deklarieren musste, hat die Kubernetes-Community seitdem mehrere Werkzeuge für die dynamische Orchestrierung komplexer KI-Workloads geschaffen, die sich allerdings in sehr verschiedenen Entwicklungsstadien befinden.

Dynamische Ressourcenverteilung mit DRA und Dranet

Zu den ausgereifteren Werkzeugen gehört „Dynamic Resource Allocation“ (DRA). Als Core-Feature von Kubernetes entwickelt, erlaubt DRA, Hardware wie GPUs und Speicher für mehrere Container und Pods bereitzustellen, so dass diese genau auf die benötigten Ressourcen zurückgreifen können. Zwar haben die einzelnen Funktionen von DRA einen Beta- und teils noch einen Alpha-Status, seit September 2025 aber gehört DRA zu den für alle Nutzer standardmäßig aktivierten Features von Kubernetes.

Cloud Native for ever...

KI-Agenten und Observability waren die Top-Themen der CNCF-Konferenz

Weniger weit, aber bereits in der Beta-Phase, befindet sich „Dranet“. Der auf DRA aufbauende und maßgeblich von Google entwickelte Netzwerktreiber soll gerade bei anspruchsvollen KI-Lasten eine optimierte Ressourcenverteilung und eine einfache Skalierung über das gesamte Cluster hinweg ermöglichen.

Durch die Erweiterung der Ressourcenabstraktion auf Netzwerkgeräte ermöglicht Dranet, Netzwerkfunktionen direkt über die Konfigurationen der Cluster und Pods im YAML-Format zu steuern. Angesichts der im September 2025 erschienen Version 0.7 ist Pathak mittlerweile von der breiten Einsatzbereitschaft des Tools überzeugt: „es ist Open Source, mit 50 Megabyte sehr leichtgewichtig, schnell, sicher und nun in der Beta“.

Neue Architekturen, nicht nur Erweiterungen

Eine dynamische Ressourcenverteilung in Kubernetes bringt ein Problem mit sich: Verteilt man ein Pod auf mehrere Maschinen, kann es dazu kommen, dass Chips nicht erst auf ihren eigenen lokalen Speicher, sondern auf den Speicher anderer Server zugreifen, was zu erheblichen Leistungseinbußen führt. „Dies ist besonders schmerzhaft bei Tranings-Workloads und latenzkritischer Inferenz, wo die Leistung allein durch eine schlechte Speicherverteilung einbricht“, erläutert Narang. Hier ist es entscheidend, Kubernetes ein Verständnis für die lokalen Nodes mit den konkreten Chips und dem dazugehörigen lokalen Speicher beizubringen, also für Non-Uniform Memory Access (NUMA).

Ein so genannter Topology Manager in Kubernetes kann mit den nötigen Informationen zwar genau das leisten. Das Procedere ist allerdings für CPUs und Speicher wesentlich ausgereifter als für den GPU-Einsatz im großen Stil, wie ihn LLMs fordern. Kubernetes war hier lange von den Informationen abhängig, die die Device Plugins der einzelnen Hersteller liefern.

Zusätzlich werden teils spezielle und in verschiedenem Ausmaß ausgereifte Erweiterungen benötigt, um eine passende topologische Verteilung der Workloads zu gewährleisten. Wo DRA einen großen Teil des Konfigurationsaufwandes abstrahiert, kann dieser bei der NUMA-Optimierung wieder einziehen.

Zugleich MCP-Unterstützung in „Kgateway“ angekündigt

Solo.io übergibt quelloffenes KI-Framework an CNCF

„Kubernetes ist ein Biest“, zeigt sich Saiyam Pathak überzeugt. „Für CPU-Workloads funktioniert es perfekt, aber es war nie für den Maßstab gedacht, in dem es heute eingesetzt wird – für den Maßstab generativer KI. Das ist ein neues Niveau, und daher müssen sich die Architekturen ändern“.

Ein vielversprechender Schritt dahingehend ist für Pathak der von Nvidia entwickelte „KAI Scheduler“. Dieser berücksichtigt von vornherein die Topologie auch komplexer GPU-Cluster. Im Fall von Nvidia-GPUs ist insbesondere die eingebaute Differenzierung zwischen herkömmlichen PCIe-Anschlüssen und dem schnellen proprietären „NVLink“ entscheidend. KAI Scheduler wurde kürzlich auf Open Source umgestellt und soll im Verlauf von 2025 zudem Hersteller-neutral werden.

Große Modellentwickler bauen sich eigene Implementierungen

Dennoch bringt „Kubernetes seine eigenen Limitierungen mit sich“, gesteht Pathak. Etcd, die Key-Value-Datenbank von Kubernetes, wird durch Zehntausende startende und stoppende GPU-Aufgaben oft an ihre Grenzen gebracht und die vielen kleinen Schreibvorgänge können sich nachteilig auf der Latenz auswirken. Hinzu kommen nach Pathak Limiteriungen bei dem Netzwerk-System (CNI), das auf auf Microservices statt GPU-Cluster ausgelegt ist.

Die Herausforderung sei aber nicht unüberwindbar. Das zeige nicht nur OpenAI, das längst sehr weit über die 2021 erreichten 7.500 Nodes hinweggeschritten sei. Pathak illustriert: „Google hat auf 65.000 Nodes skalieren können und Amazon hat jüngst 100.000 Nodes erreicht.

Gewiss haben sie für einige Aufgaben ihre eigenen Implementierungen entwickelt“. Google etwa hat „etcd“ durch das proprietäre SQL-System „Spanner“ ausgetauscht. „Aber auch schon mit der „Google Kubernetes Engine“ kann man problemlos auf 6.500 Nodes skalieren und in diesem Rahmen GPUs effektiv nutzen.“

Baustellen: GPU-Auslastung und Caching

Ist Kubernetes für KI-Workloads also keine Baustelle mehr, sind wir bereits bei der Endeinrichtung? Fast, meint Pathak.

Großes Potenzial gäbe es noch für eine optimierte Zwischenspeicherung von Tokens (KV Caching) bei immer wieder aufkommenden Anfragen, insbesondere bei Inferenz auf Unternehmensebene. Hier bestünden noch große Ineffizienzen.

Gleiches gelte für bei parallelen Berechnungen oft nicht voll ausgelastete GPUs. Die beständige Hardware-Knappheit verschärfe das Problem. Hier habe die Inferenz-Engine „vLLM“ große Effizienzgewinne ermöglicht, das Projekt gehöre aber nicht ohne Grund auch weiterhin zu den größten Hype-Themen der Entwickler-Community.

Semantik, Sicherheit, Skalierung und die Performance an der Edge

WebAssembly ist die stille Revolution der Cloud-Infrastruktur

Dieser „Hype-Zug” selbst schaffe zudem „viele neue Möglichkeiten für weitere Innovationen bestehender Technologien“. Wo vLLM nicht auf Cloud Native-Umgebungen ausgelegt sei und etwa fordere, jedes Modell in ein schwergewichtiges Pod zu packen, entstehe momentan mit „llm-d“ bei Red Hat eine von Beginn an für Kuberenetes entwickelte und vielversprechende Alternative.

Mehr Baustellen: Mandantenfähigkeit und Bare Metal

Viel zu tun gebe es auch bei der Mandantenfähigkeit und Bare-Metal-Orchestrierung, Pathak gibt sich aber mit Verweis auf die eigene Erfahrung optimistisch. Ein herkömmlicher Ansatz, für jedes Team eigene virtuelle Maschinen einzurichten, sei nicht im Sinne von Kubernetes. Erwartbar preist Pathak hier als Alternative „vCluster“; er ist Head of Developer Relations im Projekt von vCluster Labs.

Mit vCluster im Verbund mit „vNode“ könne man so einen großen GPU-Cluster mit gepoolten Ressourcen für verschiedene Nutzer einrichten, wobei jeder Nutzer seine separate, Kuberenetes-artige Kontrollebene erhalte und die auf den gleichen GPUs laufenden Workloads verschiedener Nutzer sicher getrennt blieben. Statt Virtualisierung werde Isolation dann mithilfe von Treibern und Firmware-Funktionen auf GPU-Ebene erreicht, was von Nvidia ab den „Nvidia H100“-GPUs unterstützt werde.

Das eigene Datacenter für die eigenen KI-Workloads nutzen

Dies sei auch ein Weg zu Skalierung auf Bare-Metal-GPUs ohne zusätzliche Virtualisierungsschichten. Bare Metal ist gerade in der Trainingsphase großer KI-Modelle bislang Standard. Flexible Scheduling- und Skalierungsmechanismen, wie sie etwa das AWS-Tool „Karpenter“ in der Cloud liefert, entfallen hier natürlicherweise.

Während vCluster für die nötige Isolierung ohne Abstraktionsschichten sorge, könnten Instrumente wie KAI Scheduler laut Pathak aber zunehmend souverän mit GPU-Topologien und Aufgabenprioritäten auf Bare Metal umgehen. Sicher bedeute eine Bare Metal-Grundlage weniger Flexibilität, der reduzierte Overhead mache das aber regulär wett.

Pathak gesteht hier mit Bereitschaft die voreingenommene Perspektive einer „Cloud Native-Person“ ein. Er plädiert aber mit Nachdruck dafür, „statt alles [nur] auf Bare Metal auszuführen, Kubernetes auf Bare Metal zu bringen“. So ließe sich ein großer und dennoch sicher zwischen verschiedenen Nutzern geteilter Cluster auf der im eigenen Rechenzentrum konkret vorhandenen Hardware organisieren.

Open Source Summit 2025 in Amsterdam

Digitale Souveränität rückt ins Zentrum der Open-Source-Strategien

„Die Tendenz dahingehend wird auch zunehmen, weil jeder seine Daten lokalisiert haben will, jeder über Datenschutz spricht und seine Daten nicht an die öffentlichen LLMs liefern will. Leute wenden sich so Open Source-Modellen zu und hosten sie im eigenen Datacenter auf ihren Bare Metal-Maschinen. Wir sehen diesen Anwendungsfall oft und ich denke, das eigene Datacenter für die eigenen KI-Workloads ist die Zukunft“.

(ID:50581136)