Kubernetes AI at Scale: Von Cloud Native zu Accelerator Native

TL;DR

• 66 % der Kubernetes-Organisationen hosten GenAI-Workloads — aber nur 7 % deployen Modelle täglich. Die Prototypen-Phase endet, Produktion beginnt.
• Kubernetes macht den Sprung von „Cloud Native" zu „Accelerator Native": Hardware (GPUs, TPUs, Topologie, schnelle Netze) ist nicht mehr austauschbar, sondern entscheidend.
• Drei Bausteine zählen: AI-Apps & Agents (Sandbox, Snapshots, In-Place Resize), Compute für Inference (DRA, LLMD, Gang-Scheduling) und Networking (DRANet, KV-aware Routing).
• DRA (Dynamic Resource Allocation) ist die wichtigste Neuerung: Workloads beschreiben Hardware-Anforderungen granular und landen auf der passendsten Kapazität.
• Viele Features helfen auch ohne eigenes Model-Hosting — 52 % nutzen ohnehin Model-as-a-Service.

Warum „eine Node ist eine Node" nicht mehr reicht

Lange abstrahierte Kubernetes Hardware weg: Cattle, not Pets. Bei GenAI ist die Hardware das Produkt. GPUs sind teuer, topologieabhängig und nicht fungibel.

Laut CNCF-Jahressurvey hosten zwei Drittel der Kubernetes-Organisationen GenAI. Gleichzeitig trainieren 52 % keine eigenen Modelle — sie konsumieren Model-as-a-Service. Trotzdem brauchen Agents, Inference-Gateways und Batch-Jobs eine Plattform, die Acceleratoren versteht.

Die zentrale Verschiebung: Workloads drücken aus, welche Hardware sie brauchen — und der Scheduler platziert sie dort, wo Auslastung und Latenz stimmen.

Baustein 1: AI-Apps und Agents

Agents sind Microservices mit besonderen Anforderungen: Instructions + Tools + Modell. Tools liefern deterministische Ergebnisse; das Modell bleibt nicht-deterministisch.

Agent Sandbox

Open Source und vendor-agnostisch: CRD + Controller isolieren Code-ausführende Agents mit gVisor oder Kata Containers. Warm Pools halten vorgewärmte Pods bereit — Agents starten in unter einer Sekunde. Details dazu im Artikel zur AI-Agent-Sandbox mit Kata Containers.

In-Place Pod Resize

Seit Kubernetes 1.35 GA: Container-Ressourcen ohne Neustart anpassen. Praxisbeispiel: Apps brauchen zum Start viel CPU, im Leerlauf fast nichts. Ohne Restart-Resize wird Bin-Packing zum Glücksspiel.

# Konzept: Ressourcen zur Laufzeit anpassen (In-Place Resize)
apiVersion: v1
kind: Pod
metadata:
  name: agent-worker
spec:
  containers:
    - name: worker
      image: your-agent:latest
      resources:
        requests:
          cpu: '500m'
          memory: 1Gi
        limits:
          cpu: '2'
          memory: 4Gi
# Resize später über die Pod-API — ohne Pod-Neustart

Pod Snapshots (plattformabhängig)

Auf manchen Managed-Plattformen speichern Snapshots den exakten Pod-Zustand — inklusive geladener Modell-Gewichte. Weitere Model-Server-Kopien starten dann in Sekunden statt Minuten. Das Feature ist nicht überall verfügbar; Open-Source-Alternativen setzen auf Warm Pools und Image-Lazy-Load.

Baustein 2: Compute für Inference

DRA — Dynamic Resource Allocation

DRA ist das Framework, mit dem Kubernetes Hardware-Topologie und -Fähigkeiten granular beschreibt: Acceleratoren, Netzwerk-Interfaces, Device Classes. Workloads stellen Resource Claims; der Scheduler platziert sie auf passende Nodes.

Das Ziel: reservierte Kapazität besser auslasten — „feste Kapazität, bestmögliche Befüllung", wie im klassischen Rechenzentrum.

# Beispiel-Skizze: ResourceClaim für GPU-Kapazität (DRA-Muster)
apiVersion: resource.k8s.io/v1beta1
kind: ResourceClaim
metadata:
  name: inference-gpu
spec:
  devices:
    requests:
      - name: gpu
        deviceClassName: gpu.example.com
        allocationMode: ExactCount
        count: 1

DRA ist die Zukunft — das Scheduler-Verständnis (workload-aware) ist aber noch im Aufbau. SIG-Scheduling und Device-Plugin-Ökosystem einbeziehen.

LLMD — Modelle über mehrere Nodes

LLMD (LLM Deployment) ist ein Kubernetes-natives Framework über vLLM für Modelle, die nicht in eine Node passen:

• Disaggregated Serving: Prefill (Prompt/Kontext) und Decode (Token-Generierung) als getrennte Workloads — unterschiedliche GPU-Profile, gemeinsame KV-Caches.
• Multi-Node-KV-Cache: Caching wie in Datenbanken — weniger Neuberechnung auf teurer Hardware.

Mehr dazu im Artikel zu LLM-D und verteilter Inference.

Workload-aware Scheduling

Muster: Bewährte Ökosystem-Lösungen wandern in den Kern („Erfolg wegen Kubernetes, nicht trotz").

Baustein 3: Networking für Inference

DRANet

Dieselben Objekte wie DRA — Device Classes, Resource Claims — für physische Netzwerk-Interfaces. Dedizierte RDMA-/TPU-Pfade reduzieren Interferenz. Auf GKE wurden bis zu +60 % Bandbreite für verteilte AI/ML-Workloads berichtet.

Gateway API und Inference Gateway

Ingress wird nicht mehr gepflegt; die Gateway API ist der Community-Standard. Inference-Gateways erweitern sie um KV-aware Routing: Prefix-Cache-Matches und Server-Metriken steuern, wohin Requests landen.

Gemeldete Effekte (plattformabhängig): höhere Prefix-Cache-Hit-Rate und deutlich niedrigere Time-to-First-Token. LLMD optimiert auf System-Ebene; das Gateway im Load Balancer — beides ergänzt sich.

# Gateway API — Basis für Inference-Routing
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: inference-gw
spec:
  gatewayClassName: eg
  listeners:
    - name: http
      protocol: HTTP
      port: 80

Was Open Source ist — und was plattformspezifisch

Wer Multi-Cloud oder On-Prem plant, sollte zuerst auf DRA, Sandbox, Kueue und Gateway API setzen — und Vendor-Features als Bonus behandeln.

Lessons Learned für Plattform-Teams

1. DRA früh evaluieren, aber nicht als fertiges Allheilmittel verkaufen — Scheduler und Device-Ökosystem reifen noch.
2. Netzwerk ist oft der Flaschenhals bei Multi-Node-Inference — RDMA/Topologie von Anfang an mitdenken.
3. In-Place-Resize braucht Automatisierung — manuell über Hunderte Pods skaliert nicht; ein Operator gehört dazu.
4. 52 % hosten keine eigenen Modelle — Agent Sandbox, Scheduling und Resize lohnen trotzdem.
5. Die Investition kommt jedem Workload zugute — besseres Bin-Packing und Caching senken Kosten auch außerhalb von GenAI.

Fazit

Kubernetes für AI at Scale heißt nicht „noch ein Helm-Chart für vLLM". Es heißt: Hardware granular beschreiben (DRA), Inference disaggregieren (LLMD), Agents isolieren (Sandbox) und Requests cache-bewusst routen (Inference Gateway).

Wer die Plattform betreibt — nicht nur baut — holt den Nutzen aus Auslastung, Latenz und Kosten heraus. Genau dort entscheidet sich, ob GenAI auf Kubernetes Prototyp bleibt oder Produktion wird.

FAQ

Brauche ich DRA, wenn ich keine eigenen Modelle hoste? Viele Features (In-Place-Resize, Scheduling, Agent Sandbox) helfen trotzdem — Agents und Apps profitieren unabhängig vom Model-Hosting.

Was ist der Unterschied zwischen LLMD und Inference Gateway? LLMD orchestriert Modelle über Nodes (System-Ebene); das Gateway macht KV-aware Routing im Load Balancer. Beide senken Latenz und verbessern Auslastung.

Ist DRA produktionsreif? Nutzbar und strategisch zentral — aber Scheduler- und Ökosystem-Reife noch „in progress". Pilotieren, nicht blind flächendeckend ausrollen.

Verwandte Artikel

• LLM-D: Verteilte Inference auf Kubernetes
• GPU in Kubernetes: CDI, Sharing und DRA
• Ray auf Kubernetes: Distributed OS for AI
• Open-Source-AI-Stack auf Kubernetes
• Agentic AI auf Kubernetes in der Praxis