AI Gateway, API Gateway, Gateway API und Co: Eine Landkarte durch die Gateway-Verwirrung

Spricht man mit einem zufälligen Besucher der KubeCon, einer der größten Open-Source-Konferenzen überhaupt, über Gateways, ist es nicht unwahrscheinlich, dass einer dieser Begriffe fällt: API Gateway, Ingress Gateway, Service Mesh Gateway, Gateway API, Envoy Gateway, Agent Gateway, AI Gateway, LLM Gateway.

Wer könnte da schon den Überblick verlieren? Die Begriffe klingen verwandt, meinen aber sehr unterschiedliche Dinge.

Mit dem aktuellen Hype rund um sogenannte "AI Gateways" ist die Verwirrung nicht kleiner geworden. Allein im Open-Source-Umfeld findet man Projekte wie Envoy AI Gateway, agentgateway, APISIX AI Gateway, Higress AI Gateway, LiteLLM, Portkey oder AI-Gateway-Funktionen in größeren Plattformen wie MLflow. Sie alle haben mit AI-Traffic zu tun. Aber sie lösen nicht dasselbe Problem.

In unserem nächsten Release werden wir eine neue Gateway-Technologie integrieren. Daher mussten wir uns durch diesen Dschungel aus Begriffen, Marketingmaterialien und Dokumentationen kämpfen. Dieser Beitrag ist ein Versuch, das Ergebnis dieser Arbeit zu destillieren und etwas Licht in diese Landschaft zu bringen.

Er richtet sich an technische Leserinnen und Leser, die zwar ein Grundverständnis von Kubernetes, Containern und LLMs mitbringen sollten, aber keine Networking-Expert:innen oder Hardcore-DevOps-Nerds sein müssen. Dieser Beitrag hat nicht den Anspruch, jede einzelne Technologie im Detail zu erklären. Das Ziel ist, ein mentales Modell zu schaffen: Welche Arten von Gateways gibt es? Auf welcher Ebene arbeiten sie? Welche Probleme lösen sie? Und warum ist es wichtig, diese Ebenen nicht durcheinanderzuwerfen? Für welches Gateway wir uns entschieden haben und warum, ist möglicherweise Gegenstand eines Folgebeitrags.

Disclaimer: Wir sind eine AI-Infrastructure-Company. Selbstverständlich ist dieser Beitrag KI-unterstützt entstanden. Er ist aber keineswegs one-shot AI slop. Wir haben liebevoll mit den LLMs iteriert und ihn mehrfach gereviewt und editiert.

Warum "Gateway" so verwirrend ist

Ein Gateway ist im einfachsten Sinne ein kontrollierter Übergang zwischen zwei Bereichen, zum Beispiel:

• zwischen Internet und Kubernetes-Cluster,
• zwischen Services innerhalb eines Clusters,
• zwischen einer Anwendung und mehreren LLM-Providern,
• zwischen Agenten und Tools,
• zwischen Agenten und anderen Agenten,
• zwischen einem Benutzer und einer Plattform,
• oder zwischen einem internen AI-System und externen APIs.

Genau deshalb ist der Begriff so flexibel und so verwirrend. Zwei Teams, oder sogar zwei Entwickler im selben Team, können mit "AI Gateway" völlig unterschiedliche Schichten meinen.

Die klassische Gateway-Welt: Ingress, API Gateways und Service Meshes

Bevor man AI Gateways versteht, lohnt sich ein kurzer Blick auf die klassische Cloud-Native-Welt. In unserer Community werden "Cloud Native" und "Kubernetes" nahezu synonym verwendet.

In Kubernetes hilft eine einfache Unterscheidung: Eine Ressource beschreibt gewünschten Zustand, ein Controller liest diese Ressource und übersetzt sie in Konfiguration, und ein Proxy sitzt tatsächlich im Datenverkehr. Der Proxy nimmt Requests entgegen, entscheidet anhand seiner Konfiguration, wohin sie weitergeleitet werden, und gibt Antworten zurück. Je nach Proxy kommen Funktionen wie TLS-Termination, Load Balancing, Routing, Retries, Timeouts, Header-Manipulation, Authentifizierung oder Observability dazu.

Ingress war lange die Standard-Ressource, um HTTP-Traffic von außen in den Cluster zu bringen. Ingress selbst routet aber keinen Traffic. Erst ein Ingress Controller macht daraus echte Proxy-Konfiguration. Typische Implementierungen sind zum Beispiel NGINX Ingress Controller, Traefik, HAProxy oder Contour.

Die modernere Kubernetes Gateway API verfolgt ein ähnliches Ziel und kann in vielen Szenarien als Nachfolger von Ingress verstanden werden. Sie ist aber nicht nur ein "besseres Ingress", sondern expliziter, mächtiger und stärker auf Rollenverteilung zwischen Plattform-, Netzwerk- und Applikationsteams ausgelegt. Auch hier gilt: Die Gateway API ist eine Kubernetes-API, keine Datenpfad-Komponente. Implementierungen wie Envoy Gateway, Kong, Cilium oder Istio müssen diese Ressourcen lesen und in echte Proxy-Konfiguration übersetzen.

Ein API Gateway, ein Schelm, wer das mit der Gateway API verwechselt, ist dagegen eine Funktions- oder Produktkategorie. Es exponiert APIs für Clients und bündelt typischerweise Funktionen wie Authentifizierung, Rate Limits, Quotas, API Keys, Transformationen oder Analytics. Es kann vor Kubernetes stehen, in Kubernetes laufen oder mit Ingress und Gateway API kombiniert werden.

Ein Service Mesh wie Istio oder Linkerd geht noch einen Schritt weiter. Es kümmert sich nicht nur um Ingress-Traffic, sondern auch um Service-to-Service-Kommunikation innerhalb des Clusters: mTLS, Policies, Traffic Splitting, Observability und Authorization. Für diesen Beitrag ist vor allem wichtig: Istio ist eine Control Plane, nicht der Proxy selbst.

Eine hoffentlich hilfreiche Vereinfachung:

• Gateway API ist die Kubernetes-standardisierte API für Gateways und Routen.
• Envoy ist der eigentliche Proxy im Datenpfad.
• Envoy Gateway ist ein Beispiel für einen Controller, der mit Gateway-API-Ressourcen arbeitet und Envoy als zugrunde liegenden Proxy konfiguriert.
• Istio ist eine Service-Mesh-Control-Plane; es kann ebenfalls Gateway-API-Ressourcen nutzen, ist aber für diesen Beitrag eher ein Zusatzkontext.

Mit Datenpfad ist der Pfad gemeint, den echte Requests und Responses zur Laufzeit nehmen. Die Control Plane entscheidet und konfiguriert. Die Data Plane verarbeitet den tatsächlichen Traffic.

Was macht ein "AI Gateway" anders?

Bei klassischem API-Traffic ist das Ziel oft ein bekannter Backend-Service: ein Request kommt rein, das Gateway routet ihn anhand von Host, Pfad, Headern oder anderen Regeln an den passenden Service weiter. LLM- und Agenten-Traffic bringt zusätzliche Fragen mit:

• Welcher Provider oder welches Modell soll verwendet werden?
• Wie verwaltet man API Keys und Secrets?
• Wie setzt man Budgets, Quotas und Rate Limits um?
• Wie trackt man Token, Kosten und Latenzen?
• Wie geben Client-Anwendungen einen einheitlichen Zugriff auf externe Provider wie Azure OpenAI, Anthropic, Gemini oder Bedrock und auf selbstgehostete Modelle über vLLM, Ollama oder interne Endpoints?
• Wie routet man Queries effizient zu lokalen LLM-Instanzen, zum Beispiel KV-cache-aware?
• Wie behandelt man Fallbacks, Retries und Timeouts?
• Wie macht man Observability für Prompts, Completions und Tool Calls?
• Wie kontrolliert man Zugriff auf MCP-Server und Tools?
• Wie trennt man Tenants, Teams oder Workspaces voneinander?
• Wie verhindert man, dass Agenten unkontrolliert auf interne Systeme zugreifen?

Für unsere internen Diskussionen hat es sich als hilfreich erwiesen, AI Gateways entlang dieser Fragen in drei Kategorien zu unterteilen.

1. LLM Provider Gateways

Diese Gateways sitzen zwischen Anwendung und LLM-Provider. Sie bieten oft eine OpenAI-kompatible API, die faktische Schnittstelle vieler LLM-Anwendungen, und routen Requests an verschiedene Modelle oder Provider weiter.

Typische Funktionen sind API-Key-Management, Provider-Abstraktion, Kostenkontrolle, Fallbacks, Rate Limits und Logging. Ein wichtiges Muster ist dabei die Trennung zwischen Client-Zugriff und Provider-Zugriff: Eine Anwendung oder ein User bekommt nicht direkt den API-Key von OpenAI, Anthropic oder Bedrock, sondern einen vom Gateway ausgestellten Key. Das Gateway hält die eigentlichen Provider-Secrets zentral, entscheidet pro Request, ob die Anfrage erlaubt ist, und kann Nutzung, Kosten, Limits und Fehler pro App, Team oder Key erfassen.

Es gibt eine große Zahl von SaaS-Lösungen in diesem Bereich, zum Beispiel OpenRouter, Helicone, Keywords AI oder Portkey. Daneben gibt es Kandidaten, die sich selbst betreiben lassen, etwa LiteLLM, Portkey Gateway oder Teile von MLflow AI Gateway. agentgateway kann ebenfalls LLM-Provider-Traffic abdecken, ist aber breiter angelegt und taucht deshalb weiter unten noch einmal auf.

Das zentrale Problem lautet hier:

Wie gebe ich Anwendungen, Entwicklern und Nutzern einen einheitlichen, kontrollierten Zugriff auf verschiedene LLMs?

Anmerkung: Bei allen Open-Source-Projekten lohnt sich ein genauer Blick auf die Editions- und Feature-Grenzen. Source Code verfügbar heißt nicht automatisch, dass alle produktionsrelevanten Betriebsfeatures wie SSO, feingranulares RBAC, Audit, HA-Setups oder Enterprise-Support bedingungslos in der freien Variante enthalten sind.

2. Kubernetes-native AI Traffic Gateways

Diese Gateways kommen stärker aus der Cloud-Native- und Infrastrukturwelt. Sie bauen auf Kubernetes, Envoy, Gateway API oder verwandten Standards auf.

Hier geht es nicht nur um Provider-Abstraktion, sondern um Traffic Management als Plattformfähigkeit: Custom Resource Definitions, im Kubernetes-Jargon kurz CRDs, Gateway-Ressourcen, Policies, Self-hosted Inference, Routing zu Model-Backends, Observability und Integration in bestehende Kubernetes-Netzwerkmodelle.

Ein wichtiger Baustein in dieser Kategorie ist die Kubernetes Gateway API Inference Extension. Sie adressiert ein Problem, das bei klassischem HTTP-Routing kaum vorkommt: Für selbstgehostete Inferenz reicht es oft nicht, einen Request einfach per Round Robin an irgendeinen Pod zu schicken. LLM-Serving braucht modellbewusstes Routing, Endpoint-Auswahl nach Last und Fähigkeiten, Prioritäten, Rollouts und Metriken aus den Model-Servern. Konzepte wie InferencePool, Endpoint Picker, Prefix-/KV-cache-aware Routing, LoRA-Adapter-Verfügbarkeit oder GPU-Auslastung werden damit Teil der Routing-Entscheidung.

Wer sich für Autoscaling und KV-cache-aware Routing bei selbstgehosteten LLMs interessiert, ist herzlich eingeladen, unser Paper zu diesem Thema zu lesen, das wir kürzlich auf der VDI Automation vorgestellt haben. Link folgt, sobald es veröffentlicht ist.

Envoy AI Gateway ist ein Beispiel in dieser Kategorie. Als Erweiterung von Envoy Gateway gibt es Anwendungen einen einheitlichen Weg, mit vielen verschiedenen Modellen zu sprechen, egal ob sie bei einem externen Provider oder auf der eigenen Infrastruktur laufen. Es kümmert sich um umliegende Themen wie Authentifizierung, Fallbacks, Usage Limits und Metriken. Gleichzeitig knüpft es direkt an das oben beschriebene Routing an: Statt modellbewusstes Routing neu zu erfinden, kann es auf der Gateway API Inference Extension aufbauen. Ein Request kann an ein InferencePool Backend gehen, wo der Endpoint Picker den passenden Model Server auswählt, während Envoy AI Gateway diese intelligente Routing-Schicht in die äußere API verpackt, die Anwendungen tatsächlich sehen.

Das zentrale Problem lautet hier:

Wie betreibe ich AI-Traffic als Kubernetes-native Infrastrukturkomponente?

3. Agent-, MCP- und Tool-Gateways

Ja, natürlich geht es in diesem Beitrag auch um Agentic AI. KI-Agenten kombinieren LLM-Aufrufe mit Tool Calls, MCP-Servern, internen APIs und zunehmend auch Kommunikation mit anderen Agenten. Damit entstehen neue Security- und Governance-Fragen:

• Welche Agenten dürfen welche Tools verwenden?
• Wie wird Tool-Zugriff authentifiziert und autorisiert?
• Wie beobachtet man Agent-to-Tool- und Agent-to-Agent-Kommunikation?
• Wie verhindert man unkontrollierte laterale Bewegung durch interne Systeme?
• Wie setzt man Policies für MCP-Server, Tool Calls und Agent Workflows durch?
• Wie weist man Agenten eine eigene Identität zu, und wie verbindet man diese Identität mit Access Permissions?

Spätestens bei der letzten Frage fallen Gateway-, Identity- und Policy-Themen zusammen. Konzepte wie SPIFFE und SPIRE werden dann relevant. Das ist allerdings ein eigenes Thema und möglicherweise Stoff für einen Folgebeitrag.

Das zentrale Problem lautet hier:

Wie kontrolliere ich die Kommunikation von Agenten mit Tools, Services, Modellen und anderen Agenten?

Beispiele für solche Agent-, MCP- und Tool-Gateways sind agentgateway, das Agent-, MCP-, LLM- und Service-Traffic unter einer gemeinsamen Gateway-Schicht adressiert, das Docker MCP Gateway, das MCP-Server zentral verwaltet, oder Googles Agent Gateway in der Gemini Enterprise Agent Platform.

Warum diese Unterscheidung wichtig ist

Wenn man diese Kategorien vermischt, vergleicht man schnell Äpfel mit Birnen.

LiteLLM, Envoy AI Gateway und agentgateway können alle unter dem Label "AI Gateway" auftauchen. Trotzdem stehen sie für unterschiedliche Schichten: Provider-Abstraktion, Kubernetes-natives Traffic Management oder Agent-/Tool-Kommunikation. Für Architekturentscheidungen ist das nur hilfreich, wenn man die gemeinte Schicht benennt.

Die richtige Frage ist daher nicht:

Welches AI Gateway ist das beste?

Sondern:

Welche Gateway-Schicht brauchen wir eigentlich?

Als grobes Raster bleibt damit:

Das Raster ist nicht perfekt. Viele Tools bewegen sich zwischen mehreren Kategorien. Es hilft dennoch, die Konzepte einzuordnen und das richtige Tool für den richtigen Zweck zu wählen.

Was das für prokube.ai bedeutet

Bei prokube.ai bauen wir eine souveräne, Kubernetes-native Plattform für AI-, Agent- und klassische MLOps-Workloads. Wir sind große Open-Source-Fans, setzen unsere Plattform bewusst auf vollständig offene Tools und geben, wann immer sinnvoll möglich, Beiträge an Upstream-Projekte zurück. Deshalb betrachten wir AI Gateways nicht isoliert, sondern als Teil einer größeren Plattformarchitektur aus Kubernetes, Gateway API, Envoy, MCP, Observability, Identity, Policy und Workspace-Isolation. Welche Gateway-Komponente wir in unserem kommenden Release integrieren und warum, werden wir im nächsten Beitrag beleuchten.

Fazit

"AI Gateway" ist kein einzelner klar definierter Produkttyp. Es ist ein Sammelbegriff für verschiedene Schichten, die alle irgendwo zwischen Anwendung, Modell, Agent, Tool, Plattform und Infrastruktur sitzen.

Wer heute über AI Gateways spricht, sollte deshalb zuerst klären:

• Welche Grenze soll kontrolliert werden: Anwendung zu Modell, Agent zu Tool, Agent zu Agent, Service zu Service oder Internet zu Cluster?
• Brauchen wir primär LLM-Provider-Routing, oder eine breitere Agent-/MCP-/A2A-Kommunikationsschicht?
• Soll das Gateway Kubernetes-native Infrastruktur sein, oder ein anwendungsnaher Proxy?
• Geht es um Self-hosted Inference und Model-Serving, oder um externe Provider APIs?
• Welche Rolle spielen Identity, Policy, Tenant-Isolation, Observability und Kostenkontrolle?
• Brauchen wir ein spezialisiertes Gateway für eine Schicht oder bewusst eine gemeinsame Gateway-Schicht für mehrere dieser Verkehrsarten?

Erst wenn diese Fragen beantwortet sind, wird ein Tool-Vergleich sinnvoll.

Uns hat es jedenfalls geholfen, diese Begriffe einmal aufzuräumen und im Team klarer zu benennen, worüber wir eigentlich sprechen. Wir hoffen, dass es dir ähnlich geht. Falls nicht, hoffen wir, dass der Beitrag dir wenigstens zu einem gut platzierten Klugscheißer-Hinweis in der nächsten Nerd-Runde verhilft.