Kong AI Gateway: Kubernetes-natives API-Gateway mit LLM-Plugins

Was ist Kong AI Gateway?

Kong (konghq.com) ist seit 2015 das verbreitete Open-Source-API-Gateway in der Cloud-Native-Welt. Die Engine basiert auf NGINX und OpenResty, ist in Lua und Go geschrieben und wird häufig in Kubernetes-Clustern als Ingress-Controller eingesetzt. Stand Mai 2026 liegt die stabile Version bei Kong Gateway 3.8 (LTS); die Enterprise-Variante heisst Kong Konnect.

Das AI Gateway ist keine eigene Komponente, sondern eine Sammlung von Plugins, die das bestehende Gateway um LLM-spezifische Fähigkeiten erweitern. Die wichtigsten Plugins (Stand Mai 2026): ai-proxy (Routing zu OpenAI, Anthropic, Azure, Cohere, Mistral, Llama, Hugging Face, AWS Bedrock), ai-prompt-guard (Filter für Prompt-Injection-Pattern und verbotene Inhalte), ai-prompt-decorator (System-Prompts und Header-Injection vor dem Upstream), ai-prompt-template (zentrale Template-Bibliothek), ai-request-transformer und ai-response-transformer (Schema-Konvertierung zwischen Providern), ai-rate-limiting-advanced (Token-basiertes Rate-Limit statt Request-basiert), ai-semantic-caching (Cache-Hits basierend auf Embedding-Ähnlichkeit statt exaktem Match), ai-azure-content-safety (Integration mit Azure-Content-Filter).

Die Lizenz ist hybrid. Kong Gateway in der Community-Variante ist Apache-2.0; viele AI-Plugins sind in der OSS-Variante enthalten (ai-proxy, ai-prompt-guard, ai-prompt-decorator). Das semantische Caching, ai-rate-limiting-advanced und ai-azure-content-safety sind Enterprise-Plugins und benötigen eine Konnect-Lizenz. Die Lizenz-Kosten sind nicht öffentlich, bewegen sich aber im fünfstelligen USD-Bereich pro Jahr je nach Cluster-Grösse.

Für fairlane.systems ist Kong AI Gateway in zwei Fällen interessant: erstens für Plattform-Teams, die bereits Kong als Standard-Gateway betreiben und LLM nur eine weitere Backend-Route ist; zweitens für Kubernetes-native Setups mit hohem Volumen, in denen Self-Host-LLM-Gateway integraler Teil der Plattform sein soll.

Warum es für Plattform-Teams relevant ist

Drei Vorteile machen Kong AI Gateway in bestimmten Setups attraktiv. Erstens: ein Gateway für alles. Wer schon Kong für REST-APIs, gRPC-Services und WebSockets betreibt, fügt LLM-Routing als weitere Route hinzu, ohne eine zweite Gateway-Schicht aufzubauen. Authentifizierung, Rate-Limit, Logging, Tracing – alles läuft durch die gleiche Kong-Pipeline. Das reduziert die Betriebs-Komplexität erheblich.

Zweitens: Kubernetes-native Integration. Kong wird als Kubernetes-Ingress-Controller oder als Operator (Kong Gateway Operator) installiert; Routes, Plugins, Consumers, virtuelle Keys liegen als Kubernetes-CRDs vor. Das passt zur GitOps-Praxis: alles in Git, alles über kubectl apply oder Argo CD deployed, alles in Helm versioniert. Für Teams, die ihre Plattform vollständig deklarativ verwalten, ist das die natürliche Wahl.

Drittens: harte Performance. Kong basiert auf NGINX/OpenResty und ist für hohe Last optimiert. Bei einem CH-Mandanten mit 5.000 LLM-Calls pro Stunde liegt der Kong-Overhead unter 5 ms pro Request – vergleichbar mit Bifrost und deutlich besser als Python-basierte Gateways. Bei einer Plattform mit 100+ Mandanten lohnt diese Performance.

Unter revDSG ist Kong AI Gateway gut positioniert. Da das Gateway vollständig self-hostable ist (Bare-Metal, Kubernetes, Docker), verlassen Prompts und Antworten die eigene Infrastruktur nur in Richtung der konfigurierten Upstream-LLMs. Mit Upstreams in EU/CH (Mistral La Plateforme, Azure OpenAI EU, lokales Ollama) ist die Datenfluss-Kette komplett unter eigener Kontrolle. Audit-Log läuft über Kong-Plugins (file-log, http-log, syslog) in beliebige Backends – PostgreSQL, Loki, Elasticsearch.

Wie es funktioniert

Die Architektur folgt dem klassischen Kong-Pattern. Eine Service-Definition zeigt auf das Upstream-LLM (z. B. https://api.mistral.ai), eine Route definiert den eingehenden Pfad (z. B. /v1/chat/completions), und Plugins hängen entweder am Service, an der Route oder global. Für LLM-Routing wird das ai-proxy-Plugin am Service aktiviert, das die OpenAI-Schema-Anfrage je nach Provider transformiert.

Ein Beispiel: Kong soll Anfragen an /llm/v1/chat/completions empfangen und je nach Header oder Pfad auf Mistral, Anthropic oder lokales Ollama leiten. Die Konfiguration via deklarativer YAML (decK oder Kong Gateway Operator):

services: - name: mistral-eu url: https://api.mistral.ai routes: - name: chat-mistral paths: [/llm/mistral] plugins: - name: ai-proxy config: route_type: llm/v1/chat auth: header_name: Authorization header_value: Bearer ${MISTRAL_API_KEY} model: provider: mistral name: mistral-large-2411

Konsumenten (Consumers) bekommen Credentials (Key-Auth, JWT, OAuth2) und werden via Plugin ai-rate-limiting-advanced auf Token-Budgets begrenzt. Das Plugin zählt nicht Requests, sondern Input- und Output-Tokens – passend zur LLM-Abrechnung.

Das ai-prompt-guard-Plugin läuft als Pre-Filter. Es prüft den Prompt gegen Regex- oder Wort-Listen (z. B. für Prompt-Injection-Pattern wie "ignore previous instructions") und kann den Request blockieren oder einen Audit-Log-Eintrag schreiben. In der Enterprise-Variante kommt Azure Content Safety hinzu für LLM-basierte Inhaltsklassifikation.

Semantisches Caching (Enterprise-Plugin) speichert Embeddings der Prompts in Redis oder einer Vektor-Datenbank. Bei einem neuen Prompt wird das Embedding berechnet und gegen den Cache verglichen – bei Ähnlichkeit über einem Schwellwert (z. B. 0.95 Cosine) wird die gecachte Antwort zurückgegeben. Das senkt Kosten und Latenz bei wiederkehrenden Anfragen drastisch.

Kong-AI-Setup in 5 Schritten

1. 01Kong Gateway 3.8 als Helm-Chart oder Docker-Compose installieren, Postgres oder DB-less-Modus konfigurieren.
2. 02Services und Routes für jeden LLM-Provider definieren (z. B. mistral-eu, anthropic, ollama-local) und ai-proxy-Plugin aktivieren.
3. 03Consumers anlegen, Key-Auth-Credentials ausstellen, ai-rate-limiting-advanced auf Token-Budgets konfigurieren.
4. 04ai-prompt-guard-Plugin global aktivieren, Regex-Listen für Prompt-Injection-Pattern hinterlegen, Audit-Log via http-log-Plugin in Loki schreiben.
5. 05Anwendungen umstellen: base_url=https://kong.intern/llm/v1, api_key=Consumer-Key, Modell-Wahl über Route oder Header; Tests, dann Rollout.

Wann Kong AI Gateway passt

Erstens, wenn Kong bereits als API-Gateway läuft. In dem Fall ist das AI Gateway eine kleine Erweiterung, kein neuer Layer. Eine bestehende Kong-Installation mit 30 Services bekommt drei LLM-Services hinzu – der Operations-Overhead bleibt minimal.

Zweitens für Kubernetes-Plattform-Teams. Wer GitOps-orientiert arbeitet und alles als CRD verwalten will, profitiert vom Kong Gateway Operator. Routes, Plugins, Consumers liegen als YAML in Git, werden via Argo CD oder Flux deployt und sind reproduzierbar. Ein Python-basierter Gateway wie LiteLLM passt schlechter in diesen Workflow.

Drittens bei Mehrfach-Mandanten-Plattformen mit Token-basiertem Billing. Das ai-rate-limiting-advanced-Plugin zählt Tokens pro Consumer und kann harte Budgets pro Mandant durchsetzen. In Kombination mit den Logging-Plugins entsteht eine vollständige Abrechnungs-Grundlage pro Mandant.

Viertens bei hohem Volumen mit Latenz-Anspruch. Kong mit OpenResty/NGINX liefert konstant unter 5 ms Overhead pro Request, auch bei mehreren tausend Requests pro Sekunde. Python-Gateways skalieren schlechter und brauchen mehr Hardware für gleiche Last.

Fünftens, wenn das Procurement Open-Source-Pflicht haben will. Die Community-Edition ist Apache-2.0; viele Kern-Plugins für AI sind in der OSS-Variante enthalten. Enterprise-Plugins lassen sich später nachrüsten, wenn semantischer Cache oder erweiterte Rate-Limits gebraucht werden.

Wann NICHT

Erstens bei kleinen Setups ohne Kubernetes. Kong lässt sich zwar auch als Docker-Container oder Bare-Metal-Service betreiben, aber sein Sweet-Spot ist die Kubernetes-Welt. Für ein KMU mit einer einzelnen VM und drei Anwendungen ist LiteLLM einfacher zu betreiben.

Zweitens, wenn das Team kein NGINX/Lua-Wissen hat. Eigene Plugins zu schreiben oder bestehende zu debuggen erfordert Kenntnisse in OpenResty/Lua oder Go (für Kong PDK Go). Wer in Python-Stacks zuhause ist, kommt mit LiteLLM oder Helicone schneller voran.

Drittens, wenn Prompt-Versionierung und A-B-Testing zentral sind. Kong AI Gateway hat ai-prompt-template-Plugin, aber kein vollausgebautes Prompt-Repository wie Portkey oder Langfuse. Wer Prompts als versionierte Artefakte mit Eval-Sets pflegt, sollte Portkey oder Langfuse parallel betreiben.

Viertens, wenn semantischer Cache zwingend ist, aber das Budget keine Enterprise-Lizenz trägt. Das ai-semantic-caching-Plugin ist Enterprise-only – in der OSS-Variante fehlt es. Einen eigenen semantischen Cache zu bauen ist machbar, aber Aufwand; LiteLLM mit Redis-Cache oder Portkey Cloud sind alternative Wege.

Fünftens, wenn Multi-LLM-Modell-Routing nach Antwort-Qualität gefragt ist (Martian-Stil). Kong leitet auf konfigurierte Modelle, ohne den Inhalt zu klassifizieren. Wer pro Anfrage automatisch das beste Modell wählen will, braucht einen spezialisierten Router.

Vor- und Nachteile

Häufige Fragen

Verwandte Themen

Quellen

1. Kong AI Gateway Documentation – plugins, routes, providers · 2026-05
2. Kong Gateway 3.8 Release Notes – new AI plugins and improvements · 2026-04
3. Kong AI Plugin reference – ai-prompt-guard, ai-rate-limiting-advanced, ai-semantic-caching · 2026-05
4. Kong Gateway Operator – Kubernetes CRDs for AI routes · 2026-03