NCA Social Media
Erstellt:
Aktualisiert:
Autor:
Roland Golla
Grünes Tor mit Schriftzug ENVOY AI GATEWAY auf vier Container Würfeln

Was ist das Envoy AI Gateway?

Das Envoy AI Gateway ist ein offenes LLM Gateway, das als zusätzliche Schicht auf dem CNCF Projekt Envoy Gateway aufsetzt. Anwendungen sprechen mit einem OpenAI kompatiblen Endpunkt, das Gateway übersetzt in das Format des jeweiligen Anbieters.
Der Unterschied zu anderen Gateways liegt im Fundament. Envoy ist der Proxy, der bei Databricks, Google, Lyft, Netflix und Spotify Internet Traffic bewegt. Das AI Gateway bringt dieselbe Zuverlässigkeit in den KI Verkehr, statt eine neue Komponente daneben zu stellen.
Am 23. Juni 2026 erschien Version 1.0 als erste stabile Ausgabe, gut 16 Monate nach dem ersten Release im Februar 2025. Getrieben wird das Projekt von Maintainern bei Tetrate, Bloomberg und Nutanix.
Inhalt
NCA KI Workshop für alle Abteilungen

KI für das ganze Team an einem Tag

Ein Tag inhouse, ohne Vorkenntnisse, mit Live Demo und Live Coding. Am Ende steht ein eigenes kleines Tool statt einer Demo App.

  1. 1
    Kostenloses Vorgespräch
    Aufgaben und Teams klären
  2. 2
    Workshoptag bei euch
    Live Demo, danach gemeinsam bauen
  3. 3
    Praxistag optional
    KI an eigenen Aufgaben einsetzen
Roland Golla
Roland Golla
Fullstack Developer
Zum Workshop für alle Abteilungen arrow_forward

Envoy AI Gateway mit NCA: Schnelle Hilfe vom Experten

Never Code Alone arbeitet aus Duisburg heraus an Softwarequalität und KI gestützter Entwicklung. Wir betreiben KI Infrastruktur auf eigenen Servern in Deutschland und kennen die Frage, wann ein Gateway auf Kubernetes gehört und wann ein einzelner Container reicht. Genau diese Einordnung entscheidet über den Betriebsaufwand der nächsten Jahre.
Auf der einen Seite lokale Modelle über Ollama und offene Modelle wie Qwen, auf der anderen Seite Teams, die Cluster, Deployments und Zugriffsrechte im Griff behalten müssen. Beides zusammenzubringen ist die eigentliche Arbeit.
Passend dazu beraten wir im Vibe Coding Consulting, richten AI Coding Guidelines für PHP Projekte ein, bauen CI CD Pipelines für KI Code und begleiten den Weg zu Self Hosted KI im Unternehmen mit Mandantentrennung. Für gehostete Inferenz mit hohen Datenschutzanforderungen kommt unser Duisburger Netzwerkpartner Conversis dazu.

Was Version 1.0 gebracht hat

Version 1.0 war weniger ein Funktionssprung als eine Zusage. Die Control Plane API gilt seitdem als stabil: AIGatewayRoute, AIServiceBackend, BackendSecurityPolicy, GatewayConfig und MCPRoute, alle unter v1beta1. Innerhalb der 1.x Reihe gibt es keine brechenden Änderungen ohne dokumentierten Migrationspfad.
  • 16 Anbieter hinter einer einheitlichen API mit Übersetzung zwischen den Formaten
  • MCP Gateway für Werkzeuge und Agenten, nicht nur für Modelle
  • Multimodale und Audio Endpunkte
  • Observability auf Enterprise Niveau
  • Mandantenfähiges Routing mit Kontingenten pro Team
Version 1.1 folgte am 21. August 2026. Neu sind unter anderem Token Zählung über Anbieter hinweg, Zugangsdaten pro Anfrage, Stream Idle Timeout mit Failover und optionales OpenTelemetry Tracing. Der Wechsel von 1.0 auf 1.1 braucht keine Migration der Ressourcen.

Erst lokal ausprobieren, dann ins Cluster

Ein verbreitetes Missverständnis: für einen ersten Blick braucht ihr kein Kubernetes. Das Projekt liefert mit aigw eine eigenständige Binärdatei, die lokal gegen eine Konfigurationsdatei läuft. Formatübersetzung, Fallback und MCP lassen sich damit auf dem eigenen Rechner testen.
Code: 
          
# lokal starten, ohne Cluster
aigw run config.yaml

# Anfrage gegen den lokalen Endpunkt
curl -s http://localhost:1975/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"qwen-local","messages":[{"role":"user","content":"Hallo"}]}'
Erst wenn das Verhalten klar ist, geht es über Helm ins Cluster. Dort kommen dann die eigentlichen Stärken dazu: Zugangsdaten zentral verwalten, Kontingente pro Mandant, Routing über CRDs statt über eine Konfigurationsdatei im Container.
Genau diese Reihenfolge empfehlen wir auch bei anderen Werkzeugen. Wer direkt mit dem Cluster anfängt, debuggt zwei Probleme gleichzeitig.

Setup im Cluster: die Befehle der Reihe nach

Voraussetzung sind Kubernetes ab Version 1.32, kubectl und Helm. Wichtig ist die Reihenfolge: erst Envoy Gateway mit der passenden Werte-Datei, dann die CRDs, dann das AI Gateway selbst. Wer die CRDs überspringt, bekommt einen Controller, der seine eigenen Ressourcen nicht kennt.
Code: 
          
# 1. Envoy Gateway mit den Werten fuer das AI Gateway
helm upgrade -i eg oci://docker.io/envoyproxy/gateway-helm \
  --namespace envoy-gateway-system \
  --create-namespace \
  -f https://raw.githubusercontent.com/envoyproxy/ai-gateway/main/manifests/envoy-gateway-values.yaml

kubectl wait --timeout=2m -n envoy-gateway-system \
  deployment/envoy-gateway --for=condition=Available
Der Parameter -f ist der Punkt, an dem die meisten Setups scheitern. Ohne die mitgelieferte Werte-Datei läuft Envoy Gateway zwar, weiß aber nichts vom AI Gateway. Danach folgen CRDs und Controller:
Code: 
          
# 2. CRD Chart zuerst, dann das AI Gateway
helm upgrade -i aieg-crd oci://docker.io/envoyproxy/ai-gateway-crds-helm \
  --namespace envoy-ai-gateway-system --create-namespace

helm upgrade -i aieg oci://docker.io/envoyproxy/ai-gateway-helm \
  --namespace envoy-ai-gateway-system --create-namespace

kubectl wait --timeout=2m -n envoy-ai-gateway-system \
  deployment/ai-gateway-controller --for=condition=Available
Für den ersten Test reicht die Beispielkonfiguration aus dem Repository. Danach zeigt ein einfacher Aufruf, ob die Kette steht:
Code: 
          
# 3. Beispiel ausrollen und testen
kubectl apply -f https://raw.githubusercontent.com/envoyproxy/ai-gateway/main/examples/basic/basic.yaml

kubectl port-forward -n envoy-gateway-system svc/envoy-ai-gateway-basic 8080:80

curl -s http://localhost:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"qwen-local","messages":[{"role":"user","content":"Hallo"}]}'

Befehle und Parameter für den Alltag

Im laufenden Betrieb braucht ihr selten mehr als eine Handvoll Befehle. Das Feld model im Anfragekörper entscheidet über die Route, nicht ein eigener Header. Wer eine neue Route baut, prüft zuerst, ob die Ressource überhaupt akzeptiert wurde:
Code: 
          
# Routen und Backends anzeigen
kubectl get aigatewayroute -A
kubectl get aiservicebackend -A
kubectl get backendsecuritypolicy -A
kubectl get mcproute -A

# Warum greift eine Route nicht
kubectl describe aigatewayroute mein-route -n default

# Logs des Controllers
kubectl logs -n envoy-ai-gateway-system \
  deployment/ai-gateway-controller -f
Lokal ist die Binärdatei aigw das nützlichste Werkzeug. Sie kann sich aus den üblichen Umgebungsvariablen selbst konfigurieren, was für schnelle Tests reicht. Für Ollama liegt eine fertige Beispielkonfiguration im Repository:
Code: 
          
# ohne Konfiguration starten, Variablen genuegen
export OPENAI_API_KEY=sk-XXXX
aigw run

# Beispielkonfiguration fuer Ollama holen und anpassen
curl -o ollama.yaml \
  https://raw.githubusercontent.com/envoyproxy/ai-gateway/main/examples/aigw/ollama.yaml
aigw run ollama.yaml

# ohne lokale Installation, per Docker
docker run --rm -p 1975:1975 \
  -e OPENAI_API_KEY=$OPENAI_API_KEY \
  envoyproxy/ai-gateway-cli run
Zwei Details, die im Alltag Zeit sparen. Erstens: die Konfigurationsdatei für aigw nutzt dieselbe API wie die CRDs im Cluster, ihr könnt also lokal entwickeln und die Ressourcen später fast unverändert übernehmen. Zweitens: pinnt die Chart-Version mit --version, sonst zieht ein Deployment im ungünstigen Moment eine neue Nebenversion.

Die zentralen Ressourcen im Überblick

Ressource Aufgabe Typischer Einsatz
AIGatewayRoute Regeln, welche Anfrage an welches Backend geht Modellauswahl und Fallback definieren
AIServiceBackend Beschreibt einen Anbieter oder ein eigenes Modell Ollama, vLLM oder eine externe API einbinden
BackendSecurityPolicy Verwaltet Zugangsdaten zum Backend Schlüssel zentral halten statt in Anwendungen
MCPRoute Leitet Werkzeugaufrufe an MCP Server Agenten kontrolliert Zugriff auf Tools geben

Das MCP Gateway ist der eigentliche Punkt

Modelle absichern kann jedes Gateway. Interessant wird es bei Agenten, denn die rufen Werkzeuge auf. Ein Agent, der eine Datenbank abfragt oder eine Datei schreibt, ist ein anderes Risiko als ein Chatbot, der Text erzeugt.
Über MCPRoute laufen Werkzeugaufrufe durch dieselbe Kontrolle wie Modellaufrufe. Version 1.1 kam mit Routing über MCP Hostnamen und Backend Auswahl über CEL Ausdrücke dazu. Wie sich Rechte dabei sauber schneiden lassen, steht bei MCP RBAC.
Wer das Thema von der Protokollseite angehen will, findet den Stand der Entwicklung in unserer MCP Roadmap und beim Web MCP.

Wann es passt und wann nicht

Das Envoy AI Gateway passt, wenn Kubernetes bereits läuft und Envoy ohnehin im Cluster steht. Dann ist es keine neue Komponente, sondern eine Erweiterung. Es passt auch, wenn mehrere Teams oder Mandanten getrennt abgerechnet und begrenzt werden müssen.
Es passt nicht, wenn ein kleines Team schnell Kosten sichtbar machen will. Dafür ist LiteLLM in einer Stunde eingerichtet, während hier erst ein Cluster und CRD Verständnis nötig sind.
Vor allem passt es nicht als Grund, Kubernetes einzuführen. Wir sehen das regelmäßig: ein Werkzeug wird zum Argument für eine Plattform, die niemand betreiben will. Die Reihenfolge ist umgekehrt richtig. Ein Vergleich aller Optionen steht im LLM Gateway Überblick.

Coding aus der Cloud, Datenverarbeitung im eigenen Netzwerk

Ein Gateway im eigenen Cluster ist der beste Ort, um diese Trennung technisch zu erzwingen. Große Coding Modelle laufen nicht auf Kundenhardware. Die Datenverarbeitung bleibt trotzdem im eigenen Netz.
Über AIServiceBackend hängen lokale Modelle aus Ollama oder vLLM neben externen Anbietern. Welche Route welche Daten sehen darf, steht in der Konfiguration und nicht in einer Richtlinie, die niemand liest.
Für europäische Inferenz nutzen wir TensorX mit OpenAI kompatibler API und Zero Data Retention. Die rechtliche Einordnung steht bei lokale KI für Compliance.

1.0 is a commitment, not just another feature release.

Envoy AI Gateway Team, Maintainer des Projekts – Release Notes zu Version 1.0

Das Envoy AI Gateway in der NCA Praxis

Wir ordnen das Projekt für Teams ein, statt es überall vorzuschlagen. Die erste Frage ist immer, wer das Cluster betreibt und wer nachts erreichbar ist. Kommt darauf keine klare Antwort, ist ein einfacheres Gateway die bessere Wahl.
Steht die Plattform dagegen, bauen wir Routen zu lokalen Modellen, hängen Langfuse für Observability daran und stellen Open WebUI als Oberfläche davor. Überwacht wird das Ganze mit Sentry und Grafana wie jede andere kritische Komponente.
Wie groß der Aufwand wird, hängt am Bestand: Zustand des Clusters, Zahl der Anbieter, vorhandene Pipeline. Wir schauen uns das an, schätzen den Aufwand und rechnen minutengenau ab. Feste Pakete oder Mindestlaufzeiten gibt es nicht, ein Kennenlernen kostet nichts.
CYPRESS.IO Ambassador und IT Consultant für QA Engenieering und Qualität in PHP Projekten.
NCA Vibe Coding Consulting

Roland Golla ist Entwickler aus Leidenschaft – seit über 20 Jahren. Er hat hunderte Projekte begleitet, von Legacy-Refactoring bis KI-Integration. Bei Vibe Coding verbindet er das Beste aus beiden Welten: Die Geschwindigkeit von KI-generiertem Code mit der Qualität professioneller Softwareentwicklung. Kein Bullshit, keine Agentur-Floskeln – direkte Hilfe von jemandem, der selbst täglich im Code steckt.

E-Mail Kontakt

Häufige Fragen zum Envoy AI Gateway

Die Fragen aus Projekten und Workshops, kurz beantwortet.
Was ist das Envoy AI Gateway 2026?

Ein offenes Gateway für KI Verkehr, das als Schicht auf dem CNCF Projekt Envoy Gateway aufsetzt. Es stellt eine einheitliche OpenAI kompatible API über 16 Anbieter bereit, übersetzt zwischen den Formaten, verwaltet Zugangsdaten zentral und leitet über MCPRoute auch Werkzeugaufrufe von Agenten. Version 1.0 erschien am 23. Juni 2026.

Ist das Envoy AI Gateway 2026 produktionsreif?

Ja. Mit Version 1.0 gilt die Control Plane API als stabil, innerhalb der 1.x Reihe sind keine brechenden Änderungen ohne dokumentierten Migrationspfad vorgesehen. Getestet wurde vor dem Release bei Tetrate, Bloomberg und Nutanix unter echten Lasten. Version 1.1 folgte im August 2026 ohne nötige Migration.

Brauche ich 2026 Kubernetes für das Envoy AI Gateway?

Für den vollen Funktionsumfang ja, für erste Versuche nein. Mit der Binärdatei aigw lässt sich das Gateway lokal gegen eine Konfigurationsdatei starten. Formatübersetzung, Fallback und MCP könnt ihr so ohne Cluster ausprobieren. Kontingente pro Mandant und Routing über CRDs setzen dagegen ein Cluster voraus.

Was kam 2026 mit Version 1.1 dazu?

Version 1.1 erschien am 21. August 2026. Neu sind Token Zählung über Anbieter hinweg, Zugangsdaten pro Anfrage, Stream Idle Timeout mit Failover, Routing über MCP Hostnamen, Backend Auswahl über CEL Ausdrücke und optionales OpenTelemetry Tracing für generative KI. Ein Wechsel von 1.0 erfordert keine Änderung an den Ressourcen.

Envoy AI Gateway oder LiteLLM: was passt 2026 besser?

Das hängt am Betrieb, nicht an Funktionen. Läuft bereits ein Cluster mit Envoy, ist das AI Gateway eine Erweiterung des vorhandenen Proxys. Fehlt diese Basis, ist LiteLLM in einer Stunde eingerichtet und liefert Budgets und Kostentransparenz sofort. Ein Gateway ist kein guter Grund, Kubernetes einzuführen.

Welche Anbieter unterstützt das Gateway?

Mit Version 1.0 sind es 16 Anbieter mit Übersetzung zwischen den Formaten, darunter OpenAI, Anthropic, AWS Bedrock, Google Vertex und Azure OpenAI. Eigene Modelle über vLLM oder Ollama lassen sich als AIServiceBackend einbinden und stehen damit hinter demselben Endpunkt wie externe Dienste.

Was ist MCPRoute und wofür brauche ich das?

MCPRoute leitet Werkzeugaufrufe an MCP Server, so wie AIGatewayRoute Modellaufrufe leitet. Damit laufen Agentenzugriffe auf Datenbanken, Dateien oder interne Systeme durch dieselbe Kontrolle wie Modellanfragen. Wer nur den Modellzugang absichert, lässt bei Agenten die riskantere Hälfte offen.

Wie werden Zugangsdaten verwaltet?

Über BackendSecurityPolicy. Die Schlüssel liegen damit zentral am Gateway statt verstreut in Anwendungen und Umgebungsvariablen. Seit Version 1.1 lassen sich zusätzlich Zugangsdaten pro Anfrage übergeben, was bei mandantenfähigen Setups hilft, in denen jeder Kunde eigene Anbieterkonten mitbringt.

Wer steht hinter dem Projekt?

Das Projekt lebt in der Envoy Community. Der Anstoß kam von Bloomberg, das Routing von KI Verkehr mit derselben Verlässlichkeit lösen wollte wie normalen Verkehr. Maintainer sitzen bei Tetrate, Bloomberg und Nutanix. Die Basis Envoy Gateway ist ein Projekt der Cloud Native Computing Foundation.

Kostet das Gateway Latenz?

Wenig, weil es auf Envoy aufsetzt und keine zusätzliche Anwendungsschicht in einer langsameren Sprache einzieht. Gegenüber der Antwortzeit eines Modells fällt der Aufschlag kaum ins Gewicht. Relevant wird er erst bei sehr hohem Durchsatz oder bei Streaming mit engen Zeitbudgets.

Lässt sich das Gateway mit einem Router kombinieren?

Ja, und genau dafür ist es gebaut. Der vLLM Semantic Router läuft als Envoy Erweiterung über ext_proc und passt damit in dieselbe Architektur. Das Gateway regelt den Zugang, der Router entscheidet, welches Modell die einzelne Anfrage bekommt.

Wie begleitet Never Code Alone die Einführung?

Wir klären zuerst, ob die Plattform überhaupt zum Team passt, und schlagen sonst etwas Einfacheres vor. Danach bauen wir Routen zu lokalen und externen Modellen, hängen Observability daran und übergeben das Ganze dokumentiert. Wir starten mit einem kostenlosen Kennenlernen, schätzen den Aufwand und rechnen minutengenau ab.