AI Agents auf Kubernetes deployen: Architektur, Skalierung und wann sich K8s lohnt

AI Agents auf Kubernetes zu deployen bedeutet, die Komponenten eines Agenten-Systems – Agent-Service, Tool- bzw. MCP-Server, Vektor-Store, Inferenz-Engine und Message-Queue – als containerisierte Workloads auf einem K8s-Cluster zu betreiben. Kubernetes liefert Skalierung, GPU-Scheduling, State-Handling, Secrets-Management und Observability für produktiven, EU-souveränen Agenten-Betrieb. Es ist mächtig, aber kein Selbstzweck – dieser Artikel zeigt die Architektur, die Skalierungs-Mechanik und vor allem, wann sich der Aufwand überhaupt rechnet.

• Architektur: Zerlegen Sie das Agenten-System in entkoppelte Dienste – Orchestrator, Tool-/MCP-Server, Inferenz-Engine, Vektor-Store, Queue – und betreiben Sie jeden als eigenen Workload.
• Skalierung: Stateless Agent-Pods skalieren elastisch über den Horizontal Pod Autoscaler; GPU-Inferenz-Pods werden auf dedizierte GPU-Nodes gescheduled und bleiben aus Kostengründen warm.
• Entscheidung: Kubernetes lohnt sich bei hoher Dauerlast oder strengen Souveränitäts-/Latenz-Vorgaben – darunter sind Managed APIs und Serverless schneller live und günstiger.

Die Container-Architektur eines Agenten-Systems

Ein produktiver KI-Agent ist kein Monolith, sondern ein Verbund von Microservices. Diese Aufteilung ist nicht Selbstzweck, sondern folgt unterschiedlichen Skalierungs-, State- und Sicherheitsprofilen der einzelnen Komponenten.

Agent-Service (Orchestrator)

Der Agent-Service ist das Gehirn: Er führt die Orchestrierungs-Logik aus, entscheidet über Tool-Aufrufe und plant Schritte. Aufgebaut wird er typischerweise auf einem Framework wie LangGraph, CrewAI oder AutoGen, oder auf einer Vendor-Plattform wie PhariaAI (Heidelberg) bzw. Azure AI Foundry Agents. Architektonisch entscheidend: Dieser Dienst muss stateless bleiben, damit Kubernetes ihn frei skalieren, neu starten und über mehrere Replicas verteilen kann. Sämtlicher Zustand wandert in externe Stores.

Tool- und MCP-Server

Das Model Context Protocol (MCP) hat sich als Standardschnittstelle etabliert, über die Agenten externe Werkzeuge und Datenquellen ansprechen. In einer DACH-Enterprise-Umgebung laufen MCP-Server meist als In-VPC-Dienste, co-located mit der Agent-Runtime und über mTLS angebunden – das ist das Default-Muster für Integrationen zu SAP, Salesforce, ServiceNow, M365 und internen Datenbanken. Für Fabrik- oder Filial-Szenarien werden MCP-Server am Edge deployed, nahe an den Daten, und die zentrale Orchestrierung ruft sie über dedizierte Leitungen (ExpressRoute, Direct Connect) auf. Bei regulierten Workloads gilt: dedizierte MCP-Server pro Business-Unit mit getrennten Audit-Trails statt eines Multi-Tenant-Servers.

Inferenz-Engine

Hier läuft das Sprachmodell. Stand 2026 ist die Auswahl klar umrissen:

• vLLM (Ursprung UC Berkeley) ist der De-facto-Standard für produktives Self-Hosting – PagedAttention, breiteste Hardware-Unterstützung, OpenAI-kompatible Endpunkte.
• SGLang (LMSYS) liefert laut LMSYS-Benchmarks rund 29 Prozent höheren Durchsatz auf 7B–8B-Modellen auf H100 und bessere Tail-Latenz; ideal für Multi-Turn-Chat, RAG-lastige und strukturierte Workloads.
• NVIDIA NIM verpackt vLLM/TensorRT-LLM/SGLang in vorgefertigte Container und ist der pragmatischste On-Prem-Weg im DACH-Mittelstand – gebunden allerdings an die NVIDIA-AI-Enterprise-Lizenz.
• TensorRT-LLM liefert Spitzendurchsatz auf NVIDIA-Hardware, ist aber NVIDIA-only und operativ anspruchsvoll.

Wichtiger Hinweis für Bestandssysteme: Hugging Face hat TGI (Text Generation Inference) am 11. Dezember 2025 in den Maintenance-Modus überführt und verweist neue Deployments auf vLLM oder SGLang. Wer heute auf TGI läuft, muss nicht panisch migrieren, sollte Neuentwicklungen aber nicht mehr darauf aufsetzen.

Vektor-Store und Message-Queue

Der Vektor-Store (Qdrant, Weaviate oder pgvector) hält Embeddings für RAG. Er ist ein klassischer StatefulSet-Kandidat mit PersistentVolumes, weil Embeddings plus Original-Chunks Terabyte-Größen erreichen und stabile Pod-Identität sowie persistenten Speicher brauchen. Eine Message-Queue (etwa RabbitMQ, NATS oder Redis Streams) entkoppelt langlaufende, asynchrone Agenten-Jobs – Dokumentenverarbeitung, Batch-Analysen – vom synchronen Request-Pfad und ermöglicht Worker-Pools, die unabhängig skalieren.

Komponenten-Mapping: Was auf welche K8s-Ressource gehört

Die folgende Tabelle ist die Kern-Referenz für ein Agenten-Deployment. Sie ordnet jede Komponente der passenden Kubernetes-Ressource zu und nennt den entscheidenden Architektur-Hinweis.

Skalierung: HPA, GPU-Scheduling und die zwei Achsen

Agenten-Stacks skalieren auf zwei völlig unterschiedlichen Achsen, und das ist der häufigste Stolperstein.

Stateless-Achse (CPU): Agent-Service, MCP-Server und AI-Gateway sind günstige CPU-Workloads. Sie skalieren elastisch über den Horizontal Pod Autoscaler (HPA) – bei Lastspitzen kommen Replicas dazu, bei Leerlauf werden sie abgebaut. Für queue-getriebene Worker eignet sich KEDA, das anhand der Queue-Tiefe skaliert statt nur an CPU.

GPU-Achse (Inferenz): Hier gilt eine andere Logik. GPU-Nodes werden über das NVIDIA Device-Plugin dem Cluster bekanntgemacht; Pods fordern GPUs per Resource-Limit nvidia.com/gpu an. Mit Node-Selektoren, Taints und Tolerations landen Inferenz-Pods gezielt auf den teuren GPU-Nodes, während Stateless-Workloads auf CPU-Nodes bleiben. Der zentrale Unterschied: GPU-Kapazität bleibt meist warm statt elastisch, weil leerlaufende GPUs der teuerste Capex überhaupt sind. Echte Elastizität über den Cluster-Autoscaler funktioniert nur dort, wo der Cloud-Provider GPU-Nodes schnell genug nachliefert – bei dedizierter, allokationsgetriebener Blackwell-Kapazität (B200/GB200) ist das nicht gegeben.

Die GPU-Speicher-Mathematik bestimmt, wie viele Modelle pro Node passen. Faustregel für die Gewichte: Parameter mal Bytes pro Parameter. Ein 70B-Modell braucht bei BF16 (2 Byte) rund 140 GB, bei FP8 rund 70 GB, bei AWQ-INT4 rund 35 GB – dazu kommt der KV-Cache, der mit Batch-Größe und Sequenzlänge wächst (Größenordnung 10–40 GB im Produktivbetrieb). Praktisch passt 70B bei BF16 für niedrige Concurrency auf eine H200 (141 GB), braucht aber für produktive Batch-Größen typischerweise 2x H100 oder Tensor-Parallelismus über mehrere GPUs eines Nodes via NVLink.

State, Memory und EU-Region

Agenten sind im Gegensatz zu klassischen Web-Apps stateful – Konversations-Memory, Task-Pläne und Tool-Call-Historie müssen überleben, auch wenn ein Pod neu startet oder ein Region-Failover passiert. Architektonisch heißt das: Session-State in einen regionalen Redis oder Cosmos DB mit Geo-Replikation, Langzeit-Memory und Vektor-Store synchron oder asynchron repliziert, je nach gefordertem RPO. Der Vektor-Store ist dabei die Bulk-Daten-Herausforderung, weil Embeddings und Chunks die größten Datenmengen ausmachen.

Beim Thema EU-Region und Souveränität lauert die wichtigste Falle: Eine Frankfurt-Region eines US-Hyperscalers liefert Daten-Residency, nicht CLOUD-Act-resistente Souveränität – der Betreiber bleibt eine US-Rechtsperson. Für Managed Kubernetes mit echter Souveränität kommen souveräne Clouds ins Spiel: Infomaniak (Genf/Zürich, voll Schweizer Kontrolle, FADP plus GDPR) und Exoscale (Schweiz, OpenStack, Managed K8s) bieten gemanagtes Kubernetes ohne Hyperscaler-Exposure; Swisscom hat einen Kubermatic-basierten souveränen K8s-Dienst; STACKIT (Schwarz Digits, mit Rechenzentrum in Österreich) und Open Telekom Cloud setzen auf OpenStack-basierte Plattformen mit GPU-Instanzen. Für Workloads ohne strenge Souveränitäts-Anforderung bleibt Managed Kubernetes der Hyperscaler (AKS/EKS/GKE) in einer EU-Region der pragmatische Default – so löst es auch die Referenzarchitektur für Lean-Scale-ups.

Secrets, Tool-Zugriff und Observability

Agenten haben einen ungewöhnlich großen Blast-Radius: Ein kompromittierter Agent kann viele Tools aufrufen. Daher gilt als Best Practice ein Service-Account pro Agent-Tool-Paar statt eines geteilten Accounts, Just-in-Time-Elevation für sensible Operationen und Audit-Trails, die über eine Token-Exchange-Kette bis zur Nutzeridentität zurückreichen.

Konkret auf Kubernetes:

• Workload Identity statt statischer Credentials: Azure Managed Identity, AWS IRSA (IAM Roles for Service Accounts in EKS), GCP Workload Identity Federation – bei souveränen Clouds Keystone- bzw. K8s-Service-Accounts. Das Ziel ist identisch: kein Schlüssel im Code, kein Mensch im Credential-Pfad.
• Secrets-Backbone: HashiCorp Vault ist der verbreitetste Secrets- und PKI-Layer in DACH-Plattform-Stacks; in BFSI und Public Sector mit HSM-Seal gegen eine Utimaco- (Aachen) oder Thales-HSM. Das External-Secrets-Pattern synchronisiert diese in K8s-Secrets, ohne sie im Repo zu hinterlegen.
• Egress-Kontrolle: Das in DACH-BFSI etablierte Muster ist deny-by-default mit expliziter Allowlist der Modell-API-FQDNs, geloggt am Gateway. Das verhindert versehentliche Datenexfiltration und zwingt allen Modell-Traffic durch das AI-Gateway (LiteLLM, Portkey, Kong), wo Rate-Limits, PII-Filter und Budgets liegen.

Für Health und Observability liefert Kubernetes die Basis: Liveness- und Readiness-Probes pro Pod stellen sicher, dass nur gesunde Inferenz-Pods Traffic erhalten – was bei langen Modell-Ladezeiten kritisch ist (die Readiness-Probe darf erst grün werden, wenn das Modell geladen ist). Darüber kommt eine Tracing-Schicht via OpenTelemetry, mit Token-genauer Kostenattribution und einem EU-residenten Backend wie Langfuse (self-hosted).

Wann Kubernetes – und wann nicht

Hier die ehrliche Komplexitäts-Warnung. Kubernetes mit selbst-gehosteter GPU-Inferenz ist kein Wochenend-Projekt. Es lohnt sich, wenn mindestens einer dieser Treiber zutrifft:

• Hohe, stetige Last: Eine in DACH-Plattform-Teams kursierende Faustregel besagt, dass selbst-gehostete Inferenz ab rund 8–12 H100-äquivalenter Dauerlast pro Token günstiger wird als Managed APIs – aber mit 6–9 Monaten Engineering-Vorlauf. Darunter dominieren Managed APIs die TCO.
• Strenge Latenz: Latenzbudgets unter 200–500 ms mit mehreren Tool-Call-Runden verlangen co-located Inferenz; transatlantische API-Aufrufe (Frankfurt → US-East: ~80–120 ms one-way) sind dann disqualifiziert.
• Vertragliche Souveränität: Wenn die Rechtsabteilung CLOUD-Act-Exposure nicht akzeptiert oder BSI C5 Type 2 bindend ist.

Dagegen sprechen Managed APIs und Serverless, wenn die Last spikig ist (leerlaufende GPUs sind der schlimmste Capex), wenn hohe Modellvielfalt gebraucht wird (Azure Foundry allein ergänzte 2025 DeepSeek R1, GPT-4.1, Mistral Large 3, Claude Opus 4.5, Llama 4) oder wenn schlicht kein Plattform-Team vorhanden ist. Den Betrieb von vLLM, GPU-Scheduling und NCCL-Fehlerbildern im 24x7-Modus beherrschen die wenigsten DACH-Mittelständler in-house – und genau dieser Mangel, nicht die Technik selbst, ist der häufigste Grund, warum Self-Hosting-Projekte scheitern.

Konkretes Beispiel: Lean-Cluster für einen B2B-Agenten

Ein typischer Scale-up-Stack (angelehnt an die Referenzarchitektur „Lean Cloud") sieht so aus:

```text
Managed Kubernetes (AKS/EKS in EU-Region oder Exoscale/Infomaniak souverän)
├── Deployment: agent-orchestrator (LangGraph, 3 Replicas, HPA 2-10, CPU-Nodes)
├── Deployment: mcp-tools-sap (mTLS, 1 Service-Account je Tool)
├── Deployment: ai-gateway-litellm (Failover: Azure OpenAI EU -> Mistral La Plateforme)
├── StatefulSet: qdrant (3 Replicas, PVC, Vektor-Store)
├── StatefulSet: redis (Session-State, Geo-Replikation)
└── Worker-Deployment: doc-processor (KEDA, skaliert auf RabbitMQ-Queue-Tiefe)
Modell-Inferenz: Managed API (kein eigener GPU-Node) -> über Gateway
```

Hier läuft keine eigene GPU – die Inferenz liegt bei einer Managed API in EU-Geo, abstrahiert über das Gateway. Das ist bewusst so: Bei modester Last ist Pay-per-Token günstiger und in Wochen statt Monaten live. Erst wenn der monatliche API-Spend die Run-Rate von rund 10 H100-äquivalenten in einer souveränen Cloud übersteigt – oder eine neue Regulator-Vorgabe einen Control verlangt, den die Managed API nicht nachweisen kann – lohnt die Migration zu eigenen GPU-Nodes mit vLLM oder NIM auf demselben Cluster. Genau dafür ist Kubernetes ideal: Die Architektur bleibt gleich, nur die Inferenz-Komponente wandert von „Managed API hinter dem Gateway" zu „GPU-Deployment im Cluster".

Für Agenturen und B2B-Entscheider

Kubernetes ist die richtige Grundlage für Agenten-Systeme, die langfristig wachsen, EU-souverän bleiben oder strenge Latenz einhalten müssen – aber der Einstieg sollte fast immer über Managed APIs und Managed Kubernetes erfolgen, mit einem klar dokumentierten Migrations-Trigger für den Wechsel zu eigener GPU-Inferenz. Wer diese Schwelle nicht sauber definiert, baut entweder zu früh einen teuren GPU-Cluster oder zu spät, wenn die API-Rechnung bereits aus dem Ruder läuft. Blck Alpaca begleitet DACH-Unternehmen und Marketing-Agenturen bei genau dieser Architektur-Entscheidung – von der Make-Buy-Rent-Bewertung pro Komponente bis zum souveränen, observability-fähigen Cluster-Design. Sprechen Sie uns an, bevor die erste GPU bestellt wird.