LiteLLM auf Kubernetes: Production-Deployment & High Availability

LiteLLM auf Kubernetes produktiv: HA-Architektur mit 3+ Replicas, Helm-Chart, Postgres, Redis-Cache, Prometheus-Monitoring. 2-Wochen-Sprint Festpreis.

30 Aug.. 2026 | DevOps & Security

Inhaltsverzeichnis

 

Pexon Consulting | 11 Min. Lesezeit | 19.06.2026


TL;DR

LiteLLM auf Kubernetes ist der Standard-Pfad für produktive LLM-Gateway-Setups ab 4-8 Mio Anfragen pro Monat — Docker Compose reicht für Pilot, nicht für Production. Pexon Consulting baut LiteLLM-AKS-Setups in 2 Wochen als Festpreis-Sprint zwischen 22 und 38k EUR mit HA-Architektur, Postgres-Backend, semantischem Cache und Prometheus-Monitoring. Erfahrung aus 8+ produktiven Setups.

Aspekt Docker Compose (Pilot) Kubernetes (Production)
Hochverfügbarkeit Single-Point-of-Failure 3+ Replicas mit Failover
Lastverteilung manuell automatisch über Service
Auto-Scaling nicht möglich HPA + KEDA
Postgres-State lokales Volume Managed Postgres oder StatefulSet
Updates Downtime nötig Rolling Update ohne Ausfall
Geeignet bei < 1 Mio Anfragen/Monat > 4 Mio Anfragen/Monat

Warum Docker Compose für Production nicht reicht

Wir sehen das oft beim Pexon-Sprint-Discovery: Engineering-Team hat LiteLLM mit Docker Compose hochgezogen, alles läuft seit 4 Monaten gut, jetzt soll der erste echte Production-Use-Case darauf laufen. Drei Punkte sind dann sofort der Engpass.

Single-Point-of-Failure. Ein einzelner Container, ein einzelner Postgres, ein einzelner Redis-Cache. Bei Container-Restart (typisch 1-3 Mal pro Monat durch Updates oder Bugs) sind alle Anfragen für 30-90 Sekunden offline. Bei 8 produktiven AI-Apps ist das nicht tragbar.

Kein Auto-Scaling. LiteLLM ist meist nicht der Engpass — aber wenn ein Use-Case spitze Anfrage-Volumen hat (z.B. Newsletter-Generator zur Monatsmitte), wird der einzelne Container zur Bremse. Kubernetes mit HPA skaliert automatisch.

Updates mit Downtime. Neue LiteLLM-Version, neuer Provider-Konnektor, neue Configuration. Docker Compose erfordert Container-Restart, Kubernetes macht Rolling Update ohne wahrnehmbaren Ausfall.

Praktischer Daumenwert: Solange ihr unter 1 Mio Anfragen pro Monat seid, ist Docker Compose ok. Ab 4 Mio Anfragen pro Monat oder ab 3 produktiven Apps ist Kubernetes der pragmatische Pfad.


Die Pexon-HA-Architektur

So sieht das Production-Setup konkret aus.

Azure Application Gateway / Ingress
│
┌───────────────┼───────────────┐
▼ ▼ ▼
LiteLLM Pod 1 LiteLLM Pod 2 LiteLLM Pod 3
│ │ │
└───────────────┼───────────────┘
▼
┌───────────────┼───────────────┐
▼ ▼ ▼
Azure Cache Azure DB for Azure Key Vault
for Redis PostgreSQL (Secrets)
(Semantic (Audit-Trail,
Cache) Configuration)

Drei oder mehr LiteLLM-Replicas hinter Service. Bei einem Mittelstand-Setup mit 6-10 Mio Anfragen pro Monat reichen typisch 3 Replicas à 4 vCPU und 8 GB RAM. Über HPA wird auf 6-8 Replicas skaliert bei Lastspitzen.

Managed Postgres als State-Backend. Azure Database for PostgreSQL Flexible Server in Hochverfügbarkeits-Konfiguration (Zone-Redundant). Hier liegen API-Keys, Team-Konfigurationen, Audit-Trail, Cost-Tracking.

Managed Redis als Semantischer Cache. Azure Cache for Redis (Standard-Tier, mindestens C2). Bei semantischem Caching senkt das die OpenAI-Kosten typisch um 25-45%.

Azure Key Vault für Secrets. Provider-API-Keys, Postgres-Credentials, Redis-Connection-Strings — alle als Managed Identity referenziert, keine API-Keys im Helm-Values-File.


Das Helm-Chart-Pattern

# values.yaml für Pexon-LiteLLM-Production-Setup
litellm:
  replicaCount: 3
  
  image:
    repository: ghcr.io/berriai/litellm
    tag: v1.45.2-stable
  
  resources:
    requests:
      cpu: 1000m
      memory: 2Gi
    limits:
      cpu: 4000m
      memory: 8Gi
  
  autoscaling:
    enabled: true
    minReplicas: 3
    maxReplicas: 10
    targetCPUUtilizationPercentage: 70
  
  postgres:
    type: managed
    host: pexon-llm-pg.postgres.database.azure.com
    database: litellm
    sslMode: require
  
  redis:
    type: managed
    host: pexon-llm-cache.redis.cache.windows.net
    port: 6380
    useSSL: true
  
  secrets:
    backend: azure-keyvault
    keyVaultName: pexon-llm-kv
  
  podDisruptionBudget:
    minAvailable: 2
  
  topologySpreadConstraints:
    - maxSkew: 1
      topologyKey: topology.kubernetes.io/zone
      whenUnsatisfiable: DoNotSchedule

Wichtige Designentscheidungen.

PodDisruptionBudget mit minAvailable=2. Bei Cluster-Wartungen oder Node-Updates bleiben immer mindestens 2 Replicas erreichbar. Kein selbstverschuldeter Ausfall.

TopologySpreadConstraints über Availability Zones. Bei AKS in Germany West Central laufen die Pods über alle drei Zonen verteilt. Zone-Ausfall heißt nicht Komplett-Ausfall.

HPA auf CPU-Utilization (70%). Konservativ — bei 85% wären Spitzen schwerer abzufangen. Sub-Sekunden-Reaktion ist nicht nötig, KEDA-basiertes Scaling auf Queue-Length ist Option bei aggressivem Workload-Profil.


Monitoring und Audit-Trail

Drei Schichten, die in jedem Pexon-Setup eingebaut sind.

Prometheus-Metrics aus LiteLLM. Anfragen pro Modell, Latenz pro Provider, Cost pro Team, Failed-Requests, Cache-Hit-Rate. Eigene Grafana-Boards zeigen das in Echtzeit.

Strukturiertes Audit-Logging in Log Analytics. Jede Anfrage mit User-ID, Team-ID, Prompt-Hash, Modell-Wahl, Token-Verbrauch. Aufbewahrung 12-24 Monate je nach Compliance-Anforderung. Mehr zur breiten Audit-Trail-Architektur für regulierte AI-Workloads.

Alert-Pipeline für Cost-Anomalien. Wenn ein Team innerhalb 1 Stunde 80% seines Tagesbudgets verbraucht, geht Alarm an den Team-Lead. Verhindert Cost-Surprises durch Endlos-Loops oder Missbrauch.


Sie wollen LiteLLM von Pilot auf Production migrieren ohne 2-Monats-Engineering-Marathon? Pexon liefert das AKS-Deployment als 2-Wochen-Festpreis-Sprint mit HA-Architektur und Monitoring — LiteLLM-Production-Sprint mit Pexon planen.

Was nach dem Sprint produktiv läuft

Ehrlicher Stand nach den 2 Wochen.

  • 3 LiteLLM-Replicas in AKS mit HPA aktiv
  • Managed Postgres und Redis konfiguriert
  • Provider-Routing für OpenAI, Anthropic, Azure OpenAI plus optional Mistral
  • Audit-Trail in Log Analytics
  • Grafana-Boards für Engineering und Cost-Tracking-Boards für Controlling
  • Schulung Engineering-Team plus Runbook für typische Operations-Szenarien

Was nicht im Sprint enthalten ist. Multi-Region-Setup (Disaster-Recovery in zweite Azure-Region), Cross-Tenant-Mandanten-Isolation für SaaS-Setups, Custom-Guardrails-Pipelines (PII-Detection, Prompt-Injection-Detection). Das sind eigene Folge-Sprints. Mehr zum generischen LLM-Gateway-Konzept und ab wann ein Gateway sinnvoll ist.


Pexon-Sprint und Investment

2-Wochen-Festpreis-Sprint:

  • Woche 1 — AKS-Setup und Initial-Deploy. Cluster-Setup falls noch nicht vorhanden, Helm-Chart-Customization, Managed-Services-Provisioning, Initial-Deployment, Smoke-Tests.
  • Woche 2 — Migration, Monitoring, Übergabe. Anwendungs-Migration auf neue Endpunkte, Audit-Pipeline-Integration, Grafana-Boards, Runbook, Hands-on-Workshop für Engineering-Team.

Investment-Festpreis: 22-38k EUR je nach Komplexität. Untere Spanne bei vorhandenem AKS-Cluster. Obere Spanne bei AKS-Neuaufbau und Multi-Region-Setup.

Laufende Cloud-Kosten: AKS-Cluster-Anteil typisch 400-700 EUR pro Monat, Managed Postgres 280-450 EUR, Managed Redis 180-320 EUR, Application Gateway 150-300 EUR. Gesamt 1.000-1.800 EUR pro Monat für die Gateway-Infrastruktur. Vergleichbar mit Portkey-Cloud-Lizenz, aber ohne Vendor-Lock-in.


Häufig gestellte Fragen

Was kostet LiteLLM auf Kubernetes vs Managed Portkey?

Bei einem Mittelstand-Setup mit 6 Mio Anfragen pro Monat: Self-Hosted LiteLLM auf AKS liegt bei 1.000-1.800 EUR pro Monat Cloud-Kosten, Portkey-Cloud bei 800-1.500 USD/Monat. Self-Hosting hat keinen Vendor-Lock-in und volle Datenresidenz-Kontrolle. Mehr im LiteLLM vs Portkey vs Kong-Vergleich.

Reicht ein einzelner Cluster oder brauchen wir Multi-Region?

Bei reinem DACH-Setup mit AKS in Germany West Central ist ein Cluster mit Zone-Redundanz ausreichend. Multi-Region (Failover auf West Europe) wird sinnvoll bei sehr kritischen Workloads (Banking, KRITIS) oder wenn ihr internationale Standorte habt. Multi-Region-Setup hebt die Komplexität deutlich — wir empfehlen das nur bei klarer Notwendigkeit.

Was bei On-Prem-Anforderungen?

LiteLLM läuft auf jedem Kubernetes-Cluster — also auch on-prem OpenShift, Rancher, vanilla K8s. Pexon hat Setups bei zwei KRITIS-Kunden produktiv. Mehr zur Compute-Strategie zwischen Cloud und On-Prem.

Wie verhält sich das mit Postgres-Backup?

Azure Database for PostgreSQL hat automatische Backups (Point-in-Time-Restore 7-35 Tage konfigurierbar). Bei Audit-Trail-Aufbewahrung über 12 Monate exportieren wir die Audit-Daten ins Cold Storage (Blob Storage mit Archive-Tier).

Können wir LiteLLM und Portkey parallel betreiben?

Theoretisch ja, in der Praxis ist das Double-Operations-Aufwand und nicht empfohlen. Pro Use-Case entscheidet ihr für eine Gateway-Tool-Wahl. Wenn der Entscheidungs-Bedarf unklar ist, machen wir den Decision-Sprint mit Festpreis vorab.


Nächster Schritt

Wenn euer Engineering-Team LiteLLM von Docker Compose auf Kubernetes migrieren will und das Pattern nicht intern aufbauen will: Wir machen einen 45-Minuten-Architektur-Call mit dir und idealerweise dem Platform-Engineer. Du beschreibst die aktuelle Lage und Ziel-Volumen, wir skizzieren den 2-Wochen-Sprint mit Festpreis.


Verwandte Themen


Microsoft Fabric. Bilder Blogtemplate Whitepaper

Blueprint: Sicher On-Premise KI-Architektur in 4 Wochen

  • Ein praxisorientierter Implementierungsplan für souverände, performante und DSGVO-konforme Generative KI

Beratungsgespräch

Sichern Sie sich Ihre kostenfreie Erstberatung

Analyse Ihres individuellen Cloud- oder KI-Bedarfs
Erste Empfehlungen zu Umsetzungsstrategien
Transparente Einblicke in unsere Methoden, Technologien & Referenzen