Published on

Kubernetes für AI at Scale: von Cloud Native zu Accelerator Native

Authors

Kubernetes für AI at Scale: Hardware wird wieder entscheidend

TL;DR

Kubernetes macht den Sprung von „Cloud Native" zu „Accelerator Native". Früher abstrahierte K8s die Hardware weg — heute, wo 66 % der Kubernetes-Organisationen GenAI-Workloads hosten, ist die Hardware das Entscheidende: GPUs, schnelle Netzwerke, Topologie. Die drei Bausteine: Agent Sandbox und In-Place Pod Resize für AI-Apps, DRA und LLMD für Inference-Compute, sowie DRANet und Inference Gateway für Networking.

Die Verschiebung: Cattle trifft Acceleratoren

Laut CNCF-Jahressurvey hosten 66 % der Kubernetes-Organisationen GenAI-Workloads. Gleichzeitig bauen oder trainieren 52 % keine eigenen Modelle — sie nutzen Model-as-a-Service. Nur 7 % deployen Modelle täglich; die Prototypen-Phase endet, Produktion beginnt.

Die zentrale Verschiebung: Von „eine Node ist eine Node" (fungibel, austauschbar) zu „Hardware ist spezialisiert, teuer, wichtig". Kubernetes lernt, Topologie und Fähigkeiten der Hardware granular zu verstehen — statt sie wegzudrücken.

Baustein 1: AI-Apps und Agents

Ein Agent ist Instructions plus Tools plus ein Modell. Tools liefern deterministischen Code; das Modell bleibt nicht-deterministisch. Drei Kubernetes-Neuerungen helfen:

  1. Agent Sandbox (Open Source): CRD und Controller zur sicheren Isolation von Code-ausführenden Agents — mit Runtimes wie gVisor oder Kata Containers. Warm Pools starten Agents in unter einer Sekunde.
  2. Pod Snapshots (teils managed-spezifisch): Speichern und restaurieren den exakten Pod-Zustand — Modell-Gewichte inklusive. Weitere Model-Server-Kopien starten in Sekunden; Batch-Workloads können GPU freigeben und später fortsetzen.
  3. In-Place Pod Resize (GA in Kubernetes 1.35): Container-Ressourcen ohne Neustart anpassen. Praxisbeispiel: Apps brauchen 0,5 Core zum Start, laufen dann mit 0,02 Cores im Leerlauf — besseres Bin-Packing, weniger verschwendete Kapazität.

Baustein 2: Compute für Inference

DRA (Dynamic Resource Allocation) ist die wichtigste Neuerung: ein Framework zur granularen Beschreibung von Hardware-Topologie und -Fähigkeiten. Workloads drücken ihre Anforderungen aus und landen auf der passendsten Hardware. Das verbessert die Auslastung reservierter Kapazität — feste GPUs, bestmögliche Befüllung.

LLMD orchestriert Modelle über mehrere Nodes (Schicht über vLLM), wenn ein Modell nicht in eine Node passt. Der Durchbruch: Disaggregated Serving — Prefill und Decode als getrennte Phasen — plus Multi-Node-KV-Cache.

Workload-aware Scheduling ergänzt das Bild: Gang-Scheduling (viele Pods gleichzeitig), Preemption für High-Priority-Jobs und Topology-aware Placement in schnellen Compute-Domains. Das Muster: Bewährte Ökosystem-Lösungen (etwa Kueue) wandern in den Kern.

Baustein 3: Networking für Inference

DRANet nutzt dieselben Objekte wie DRA für physische Netzwerk-Interfaces — dedizierte RDMA-/Accelerator-Pfade ohne Interferenzen. In Praxisberichten bis zu +60 % Bandbreite für verteilte AI/ML-Workloads.

Die Gateway API ersetzt Ingress als Community-Standard. Inference Gateways verlagern KV-aware Routing in den Load Balancer: Prefix-Cache-Matches und Server-Metriken steuern, welche Instanz den Request bekommt. Berichte zeigen verdoppelte Prefix-Cache-Hit-Rate und Time-to-First-Token um 35–52 % gesenkt.

Was das für den Mittelstand heißt

Nicht jedes Feature ist überall verfügbar. Einiges ist managed-spezifisch (Pod Snapshots, manche Inference Gateways), anderes Open Source (Agent Sandbox, DRA, LLMD). Die ehrliche Einordnung:

  1. DRA ist die Zukunft, aber noch im Aufbau — Scheduler-Verständnis für Workload-aware Placement reift weiter.
  2. In-Place-Resize will Automatisierung — manuelles Resizen über viele Pods erzwingt einen Operator.
  3. Netzwerk ist oft der Flaschenhals — verteilte Inference hängt an schnellen Pfaden; früh mitdenken.
  4. Modell-Hosting ist nicht für jeden — 52 % nutzen Model-as-a-Service; Features wie Agent Sandbox, Resize und Scheduling helfen trotzdem.
  5. Die Investition kommt jedem Workload zugute — bessere Auslastung und Isolation verbessern den ganzen Cluster.

Häufige Fragen

Was ist DRA?

Ein Framework, das Hardware-Topologie und -Fähigkeiten (GPUs, Netzwerke) granular beschreibt — Workloads landen auf der passendsten Hardware.

Brauche ich das ohne eigene Modelle?

Ja. In-Place-Resize, Scheduling und Agent Sandbox kommen auch Agents und Apps zugute, die externe Modelle nutzen.

LLMD oder Inference Gateway?

LLMD orchestriert Modelle über Nodes (System-Ebene). Inference Gateways machen KV-aware Routing im Load Balancer. Beide verbessern Latenz und Auslastung — auf unterschiedlichen Ebenen.

Fazit

Kubernetes für AI heißt nicht „mehr YAML", sondern Accelerator Native: Hardware verstehen, Isolation für Agents, Inference über Nodes und Netzwerke, die zur Topologie passen. Wer den Einstieg plant, sollte zuerst klären, ob Kubernetes überhaupt nötig ist — und dann die Bausteine Agent Sandbox, GPU-Betrieb und Zero-Trust (Keyless Identity) gezielt aufbauen.

Wir beraten neutral, welche Kubernetes-AI-Features Ihre Plattform braucht — und übernehmen den Betrieb, wenn der Cluster produktiv werden soll.

📖 Verwandte Artikel

Weitere interessante Beiträge zu ähnlichen Themen