Kong: Vom Nginx-basierten API Gateway zur vereinheitlichten AI Traffic Control Plane

CNCF Cloud Native Landscape: The Practical Guide

A practical guide to the CNCF Cloud Native Landscape — the tools and categories that actually matter for building production infrastructure.

Es gibt nur wenige Open-Source-Projekte, die ein Jahrzehnt und einen Pivot überstehen – und noch weniger, die von 43.000 GitHub-Sternen zur Referenzarchitektur für das API- und AI-Traffic-Management heranwachsen. Kong, das erste Mal im November 2014 committet und mittlerweile in der Version 3.14+, ist eines davon. Auf OpenResty (Nginx plus LuaJIT) aufbauend, startete es als Reverse Proxy für REST-APIs und hat seitdem AI-Workloads, das Model Context Protocol (MCP) und die Agent-to-Agent (A2A)-Kommunikation in einer einzigen Control Plane vereint.

Dieser Artikel ist ein technischer Deep Dive in die Architektur von Kong, sein Plugin-System, seine AI Gateway-Funktionen und die Frage, wo es in der API-Gateway-Landschaft des Jahres 2026 einzuordnen ist.

Architektur: OpenResty unter der Haube

Kong ist kein Rewrite. Es ist eine Nginx-Distribution, die LuaJIT-kompilierte Plugins innerhalb des Request-Lifecycles ausführt. Jeder Request durchläuft einen festen Satz von Phasen — rewrite, access, balancer, header_filter, body_filter, log — und Kong fügt die Plugin-Ausführung genau an diesen Punkten ein.

Request-Verarbeitung

Wenn Kong einen Request empfängt, identifiziert der Router die passende Route und den Service. Plugins werden über einen dreistufigen Iterator geladen: Globale Plugins werden für jeden Request ausgeführt (typischerweise in certificate und rewrite), ein collecting Iterator läuft während access, um Route- und Service-spezifische Plugins zu sammeln, und ein collected Iterator spielt diesen gesammelten Satz während der Response-Phasen erneut ab.

Der Router selbst verwendet einen Rebuild-Counter im gemeinsamen Nginx-Speicher — wenn sich die Konfiguration ändert (via Admin API, deklarativer Konfiguration oder Hybrid-Mode-Sync), wird der Router invalidiert und beim nächsten Request lazy neu aufgebaut. Dies vermeidet Neustarts, bedeutet aber, dass es ein kurzes Zeitfenster gibt, in dem veraltete Routen bedient werden könnten.

Hybrid Mode (Control Plane / Data Plane)

Seit Version 2.x unterstützt Kong ein hybrides Deployment-Modell:

• Control Plane: Läuft mit einer Datenbank (PostgreSQL oder Cassandra), stellt die Admin API bereit und pusht die Konfiguration an die Data Planes.
• Data Plane: Operiert im DB-less-Modus, empfängt die Konfiguration über WebSocket und verarbeitet ausschließlich den Traffic.

Die Control Plane serialisiert die gesamte Gateway-Konfiguration via declarative.export_config(), komprimiert sie mit gzip, berechnet einen Hash zur Änderungserkennung und pusht sie an jede verbundene Data Plane. Data Planes senden periodische Pings mit ihrem Config-Hash; stimmt der Hash nicht überein, pusht die Control Plane die Konfiguration erneut. Dies ist im Wesentlichen ein CDN-ähnliches Konfigurations-Propagationsmodell mit einer Konvergenz im Sub-Sekundenbereich beim Push.

Kong 3.10+ unterstützt zudem RPC-basierten Sync V2 über JSON-RPC, wodurch der legacy WebSocket-Loop durch eine bidirektionale Capability-Negotiation ersetzt wird.

Plugin-System: Kongs „Moat“

Wenn die Architektur das Fundament von Kong ist, dann sind die Plugins sein „Moat“ (Wettbewerbsvorteil). Das Gateway wird mit über 100 offiziellen Plugins im Plugin Hub ausgeliefert, und das Plugin Development Kit (PDK) macht das Schreiben benutzerdefinierter Plugins unkompliziert.

Plugin-Phasen

Plugins definieren einen PRIORITY Integer — höhere Werte werden zuerst ausgeführt. Kong unterstützt zudem eine dynamische Plugin-Reihenfolge über die Felder ordering.before und ordering.after, sodass Sie beispielsweise erzwingen können, dass Rate Limiting vor der Authentifizierung läuft, selbst wenn die numerischen Prioritäten dagegen sprechen.

Plugin Development Kit (PDK)

Das PDK wird über die globale Variable kong bereitgestellt und bietet vorwärtskompatible APIs:

-- Example: custom rate-limiting plugin
local Kong = require "kong"

local MyPlugin = {
  PRIORITY = 1000,
  VERSION = "1.0.0",
}

function MyPlugin:access(conf)
  local key = kong.client.get_ip()
  local allowed, limit, remaining = kong.rate_limiting.consume(key, conf.limit, conf.window)
  if not allowed then
    return kong.response.exit(429, { message = "Rate limit exceeded" })
  end
end

return MyPlugin

Die PDK-Module decken Request-Inspektion (kong.request), Response-Manipulation (kong.response), Upstream-Modifikation (kong.service.request), Logging (kong.log) und Client-Metadaten (kong.client) ab. Jede PDK-Funktion ist phasenabhängig — der Aufruf von kong.response.get_status() in der access Phase löst einen Fehler aus.

Multi-Language Plugins

Neben Lua unterstützt Kong externe Plugins via plugin_servers — ein gRPC-basiertes Out-of-Process-Protokoll. Plugins können in Go, Python oder JavaScript geschrieben werden und laufen als separate Prozesse, die über Unix-Sockets kommunizieren. Für performance-kritische Pfade unterstützt Kong 3.x zudem Wasm-Plugins über die Wasm-Runtime.

Die AI Gateway Transformation

Die bedeutendste Evolution von Kong begann 2024 mit dem AI Gateway — einem Satz von Plugins und Funktionen, die auf dem Core-Gateway aufbauen. Dies ist kein separates Produkt, sondern eine Plugin-Suite, die auf jeder Kong Gateway-Instanz läuft.

Universal LLM API

Das AI Proxy Plugin (und seine Advanced-Variante) normalisiert Requests an jeden LLM-Provider hinter einer einzigen API:

# decK declarative config
plugins:
  - name: ai-proxy
    config:
      route_type: llm/v1/chat
      model:
        provider: openai
        name: gpt-4o
      auth:
        header_name: Authorization
        header_value: Bearer ${OPENAI_API_KEY}

Zu den unterstützten Providern gehören OpenAI, Anthropic, GCP Gemini, AWS Bedrock, Azure AI, Databricks, Mistral, Hugging Face, xAI/Grok, Aliyun/Qwen, Cerebras und Ollama für lokale Deployments. Ein Wechsel des Providers erfordert genau eine Konfigurationsänderung — keine Modifikationen am Client-Code.

Semantic Caching und Routing

Zwei Plugins, die das Verhalten von LLM-Traffic grundlegend verändern:

• AI Semantic Cache: Cacht LLM-Antworten basierend auf semantischer Ähnlichkeit, nicht auf exaktem String-Match. Wenn ein Benutzer fragt „Was ist die Hauptstadt von Frankreich?“ und ein anderer „Hauptstadt von Frankreich?“, greift der zweite Request auf den Cache zu. Konfigurierbar über einen Ähnlichkeitsschwellenwert (Standard 0,9) und jeden beliebigen Vector Store (Redis, AWS MemoryDB).
• AI Semantic Router: Routet Requests basierend auf der Prompt-Semantik an verschiedene Modelle. Einfache Abfragen gehen an ein schnelles, günstiges Modell; komplexes Reasoning an ein Frontier-Modell — alles über einen einzigen Endpunkt.

PII-Sanitisation und RAG-Injection

Kong AI Gateway 3.10 führte ein:

• AI PII Sanitisation: Erkennt und schwärzt über 20 Kategorien personenbezogener Daten (PII) in 12 Sprachen — einschließlich Passwörtern, Kreditkartennummern, API-Keys und Adressen. Entscheidend ist, dass es geschwärzte Daten in der Response wieder einfügen kann (ein „De-redact“-Modus), sodass Endbenutzer vollständige Informationen erhalten, ohne dass Entwickler die Sanitisation manuell in jede App programmieren müssen.
• AI RAG Injector: Fragt bei jedem LLM-Request automatisch eine Vektordatenbank ab, fügt dem Prompt den relevanten Kontext hinzu und sendet diesen upstream. Dies eliminiert das Programmieren von RAG-Pipelines pro Anwendung — das Gateway übernimmt die Generierung von Embeddings, die Vektorsuche und die Kontext-Injection.

MCP Traffic Gateway

Eingeführt in Version 3.12 und schnell ausgereift, basiert die MCP-Unterstützung von Kong auf dem AI MCP Proxy Plugin, das in vier Modi operiert:

Das Plugin liest OpenAPI-Schemas und generiert dynamisch MCP-Tool-Definitionen – ohne zusätzlichen Code. ACLs können auf Tool-Ebene angewendet werden, sodass ein als developer authentifizierter Agent deploy_service aufrufen darf, während viewer dies nicht kann, obwohl beide Tools auf demselben MCP-Server liegen.

Kong 3.12 führte zudem die native OAuth 2.1-Unterstützung für MCP ein, was mit dem Authentifizierungsmodell der MCP-Spezifikation übereinstimmt. Das Gateway fungiert als OAuth Resource Server und delegiert die Token-Ausstellung an externe Authorisation Server.

Agent-to-Agent (A2A) Gateway

Mit dem AI Gateway 3.14 im April 2026 angekündigt, unterstützt Kong nun das A2A-Protokoll für die Kommunikation zwischen Agenten. Dies erweitert dasselbe Governance-Modell – Rate Limiting, Audit-Logging, Kostenverfolgung und Zugriffskontrolle – auf den Inter-Agenten-Traffic und macht Kong zum einzigen Gateway, das LLM-, MCP- und A2A-Traffic in einer einzigen Control Plane abdeckt.

Kubernetes-Integration

Kong läuft nativ auf Kubernetes über den Kong Ingress Controller (KIC), derzeit in Version v3.5.9. KIC unterstützt sowohl die Standard-Kubernetes-Ingress-Ressource als auch die Gateway API (GatewayClass, Gateway, HTTPRoute, ReferenceGrant).

helm install kong --namespace kong --create-namespace \
  --repo https://charts.konghq.com ingress

KIC übersetzt Kubernetes-Ressourcen automatisch in die Kong-Konfiguration – das Hinzufügen eines Service mit Annotationen stellt Routen, Plugins und Upstreams im Gateway bereit, ohne die Admin-API zu berühren.

Für neue Deployments empfiehlt Kong den Kong Operator, der KIC und den Kong Gateway Operator in einer einzigen Methode kombiniert, um Kong-Produkte auf Kubernetes bereitzustellen, zu verwalten und zu konfigurieren.

Kong in der Gateway-Landschaft 2026

Kongs Performance ist wettbewerbsfähig, aber nicht marktführend beim reinen Durchsatz – der DB-less-Modus erreicht etwa 25.000 Anfragen/Sekunde pro Kern bei einer P99-Latenz von ~2ms. Envoy und APISIX liefern in synthetischen Benchmarks jeweils höhere Werte. In der Praxis dominiert die Backend-Latenz (zehn bis hunderte Millisekunden), und Kongs Plugin-Ökosystem sowie die AI/MCP-Funktionen gleichen die Performance-Lücke für die meisten Deployments aus.

Wo Kong überzeugt

• API-Management in großem Maßstab: Developer Portal, API-Versionierung, Monetarisierung, Service-Katalog – Funktionen, die kein eigenständiger Proxy bietet.
• Einheitliche AI-Infrastruktur: Ein Gateway für REST-APIs, LLM-Routing, MCP-Server und Agenten-Traffic, mit konsistenten Auth- und Observability-Richtlinien über alle vier Bereiche hinweg.
• Plugin-Anpassung: Das Schreiben eines Lua-Plugins dauert nur wenige Minuten. Das PDK ist gut dokumentiert und phasenweise abgesichert, um Fehlkonfigurationen zu vermeiden.

Wo es Schwächen hat

• Enterprise-Features hinter einer Paywall: RBAC, OIDC, erweitertes Rate Limiting, Kong Manager UI – all dies erfordert ein Kong Enterprise- oder Konnect-Abonnement. Die OSS-Edition ist leistungsstark, hat aber klare Grenzen.
• Lua-Abhängigkeit: Kern-Plugins sind in Lua geschrieben. Obwohl externe Plugin-Server Go, Python und JS unterstützen, bedeutet der Latenz-Overhead der Out-of-Process-Ausführung, dass performance-kritische Plugins in Lua geschrieben sein sollten.
• Speicherbedarf: Im DB-less-Modus liegt der Leerlaufverbrauch bei ~80MB, etwa doppelt so viel wie bei Traefik oder einem reinen Nginx.

Kong in der Produktion bereitstellen

Kong unterstützt vier Deployment-Modi:

1. Traditional — Ein Kong-Knoten mit direktem Datenbankzugriff (PostgreSQL). Einfachstes Setup für kleine Deployments.
2. Hybrid — Trennung von Control Plane (CP) und Data Plane (DP). Empfohlen für die Produktion: Die CP verwaltet die Konfiguration, die DP verarbeitet den Traffic im DB-less-Modus.
3. DB-less — Einzelner Knoten mit deklarativer YAML/JSON-Konfiguration. Keine Datenbank erforderlich. Konfiguration wird bei Dateiänderung neu geladen.
4. Konnect — Managed SaaS Control Plane mit selbst gehosteten oder Cloud-basierten Data Planes. Beinhaltet Analytics, Developer Portal und Multi-Cloud-Management.

Für Kubernetes ist der Standardweg:

# Gateway API HTTPRoute
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: my-api
spec:
  parentRefs:
    - name: kong
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /api/v1
      backendRefs:
        - name: my-service
          port: 8080

Rate Limiting über das Kong-Standard-Plugin anwenden:

apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
  name: rate-limit
config:
  minute: 100
  policy: local
plugin: rate-limiting

Sollten Sie Kong 2026 einsetzen?

Wenn Sie sowohl ein API-Gateway als auch ein AI-Gateway benötigen und Ihre Infrastruktur auf Kubernetes läuft oder eine CP/DP-Trennung erfordert, ist Kong die ausgereifteste Option mit dem tiefsten Ökosystem. Der Plugin-Hub und das PDK ermöglichen es, das System an fast jedes Traffic-Management-Muster anzupassen, ohne die Infrastruktur von Grund auf neu schreiben zu müssen.

Wenn Sie maximalen Durchsatz bei einfachem Routing benötigen, werden APISIX oder ein reiner Envoy-Proxy beim Preis-Leistungs-Verhältnis überlegen sein. Wenn Sie einen Service-Mesh-Sidecar benötigen, ist Envoy (via Istio) der Industriestandard. Aber wenn Sie eine einzige Control Plane für APIs, LLMs, MCP-Server und Agenten-Traffic benötigen – dafür gibt es keine echte Alternative zu Kong.

Die 145 Releases, 340 Mitwirkenden und ein Jahrzehnt an Produktionseinsätzen sprechen für seine Beständigkeit. Der Pivot vom API-Proxy zur AI-Control-Plane war keine reine Rebranding-Maßnahme – die Architektur, das Plugin-System und das Hybrid-Deployment-Modell waren vom ersten Tag an auf diese Erweiterung ausgelegt.