Agentic AI auf Kubernetes: Was in der Praxis zählt

TL;DR

• Kubernetes bleibt das Substrat für produktive AI-Workloads — nicht weil es „AI-native" ist, sondern weil Isolation, Scheduling, Portabilität und Open Tooling zusammenkommen.
• Der Stack hat vier Schichten: Inference → Serving → Training → Agentic Systems. Teams scheitern, wenn sie bei Chat-Demos stehen bleiben.
• Was heute funktioniert: GPU-Nodes, Device Plugins, Model Serving, Basis-Observability. Was schwerer ist: Gang-Scheduling, Topologie, Session-State, sichere Agent-Sandboxes, Cost-per-Token.
• Self-hosted gibt Kontrolle (Scheduler, Acceleratoren, Datenresidenz, Unit Economics) — der Preis ist Betriebskomplexität.
• Agents brauchen Sandbox + Identity, sonst „laufen sie wild" über Tool-Calls und Secrets.

Für wen dieser Artikel ist

Für Teams, die bereits Kubernetes betreiben und herausfinden wollen, was AI-Workloads zusätzlich brauchen — nicht für den ersten Cluster-Workshop.

Die ehrliche Agenda aus der Praxis:

1. Was heute funktioniert
2. Was schwerer aussieht, als es in Folien steht
3. Wohin das Ökosystem geht (Agents, Sandboxes, Reference Stacks)

Warum Kubernetes als Substrat auftaucht

Managed AI-Stacks sind schnell. Self-managed auf Kubernetes gewinnt, wenn eines davon zählt:

Der Trade-off ist klar: Flexibilität gegen Operational Overhead. Wer die Plattform nicht betreiben will, sollte Managed Inference einkaufen. Wer Cost-per-Token und Souveränität braucht, bleibt auf Kubernetes — und investiert in Plattform-Engineering.

Der Vier-Schichten-Stack

Von unten nach oben denken — nicht mit dem Agent-Framework starten:

┌─────────────────────────────┐
│  4. Agentic Systems         │  Orchestrierung, Tools, Sandbox, Identity
├─────────────────────────────┤
│  3. Training / Fine-Tuning  │  Jobs, Queues, Checkpointing
├─────────────────────────────┤
│  2. Serving                 │  Endpoints, Autoscaling, SLOs
├─────────────────────────────┤
│  1. Inference Engine        │  vLLM u. a. auf GPU/CPU
├─────────────────────────────┤
│  Kubernetes + Accelerators  │  Nodes, DRA, Device Plugin, Netz
└─────────────────────────────┘

Schicht 1–2: Inference und Serving

Modelle brauchen GPUs (oder passende Acceleratoren), Device Plugins und klare Resource-Requests. Serving macht daraus Endpoints mit Metriken — TTFT, Tokens/s, Fehlerquoten.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: inference-engine
spec:
  replicas: 1
  selector:
    matchLabels:
      app: inference-engine
  template:
    metadata:
      labels:
        app: inference-engine
    spec:
      tolerations:
        - key: nvidia.com/gpu
          operator: Exists
          effect: NoSchedule
      containers:
        - name: engine
          image: vllm/vllm-openai:latest
          resources:
            limits:
              nvidia.com/gpu: 1

Mehr zu GPU-Grundlagen: GPU Workloads auf Kubernetes. Mehr zu verteilter Inference: LLM-D.

Schicht 3: Training und Queues

Training startet oft Tausende Pods gemeinsam (Gang-Scheduling). Der Default-Scheduler reicht dafür nicht. Kueue, Volcano und verwandte Projekte füllen die Lücke — Topologie, NUMA und Accelerator-Generation werden First-Class-Signale.

Schicht 4: Agentic Systems

Agents verketteten Tool-Calls, halten Session-State und führen Code aus. Hier scheitern Naive-Deployments:

• State: lange Sessions überleben Evictions und Topology-Changes nicht von allein
• Security: untrusted Tool-Code braucht VM-Sandboxen
• Identity: keine statischen Secrets — siehe Keyless Identity

# Agent-Workload mit eigener RuntimeClass (Sandbox)
apiVersion: v1
kind: Pod
metadata:
  name: agent-session
spec:
  runtimeClassName: kata-containers
  containers:
    - name: agent
      image: your-agent:latest
      env:
        - name: INFERENCE_URL
          value: http://inference-engine.svc:8000

Was schwerer ist, als es aussieht

1. Heterogene Acceleratoren: Neue GPU-Generation ≠ Plattform-Neubau — aber Topology-Awareness muss ins Scheduling.
2. Skalierung am richtigen Signal: CPU/Memory reichen nicht; Queue-Tiefe, Token-Latenz und Cache-Hits zählen.
3. Cost per Token: Ohne Messung wird „mehr GPUs" zur Default-Antwort.
4. Sandbox-Lifecycle: Agents sind keine normalen Deployments — create → execute → reset → destroy.
5. Confused Deputy: Agents mit zu breiten Tokens — abfangen über Identity Chaining.

Checkliste für die nächste Woche

• GPU-Nodes + Device Plugin verifiziert, Taints/Tolerations dokumentiert
• Ein Inference-Endpoint mit TTFT- und Fehler-Metriken
• Klare Trennung: Demo-Chat vs. produktiver Serving-Pfad
• Entscheidung: Managed Inference vs. Self-host für welche Modelle
• Agent-PoC nur in Sandbox-Runtime, nicht auf Shared-Kernel-Default
• Keine langlebigen Client-Secrets in Agent-Pods
• Cost-per-Token grob schätzen (Hardware + Tokens/Tag)

Vendor-Reference-Stacks (z. B. integrierte Agent-Sandboxes auf Managed Kubernetes) können den Einstieg beschleunigen — die Architekturprinzipien bleiben dieselben: Isolation, Identity, messbare Inference.

Fazit

Agentic AI auf Kubernetes ist kein einzelnes Produkt. Es ist ein Schichtmodell: solide Inference, Serving mit SLOs, Training mit Queues — und erst dann Agents mit Sandbox und Zero-Trust.

Was heute funktioniert, reicht für Demos. Was in Produktion zählt, sind Scheduling, Topologie, Session-Härte und Security. Wer das ehrlich priorisiert, spart sich den teuren Umweg über „Agent Framework first".

Verwandte Artikel

• Kubernetes AI at Scale: DRA und Inference
• AI-Agent-Sandbox mit Kata Containers
• Keyless Identity für MCP-Agents
• Non-Human Identities und Identity Chaining
• Open-Source-AI-Stack auf Kubernetes
• Ray auf Kubernetes