Kong vs. Envoy Gateway: API Gateway für Kubernetes im Vergleich 2026

Kong oder Envoy Gateway als API Gateway für Kubernetes? Wir vergleichen Plugin-Ökosystem, Performance und Gateway API-Kompatibilität für 2026.

Kong vs. Envoy Gateway: API Gateway für Kubernetes

Kubernetes-native Applikationen brauchen ein leistungsfähiges API Gateway für Authentifizierung, Rate Limiting, Observability und Traffic-Management. Kong ist seit Jahren der Marktführer, während Envoy Gateway als neue Kubernetes-native Alternative aufsteigt. Dieser Vergleich zeigt, was beide Tools 2026 leisten.

Was ist Kong?

Kong ist ein Open-Source API Gateway und Service Mesh, das ursprünglich auf NGINX aufgebaut wurde, heute aber auf Envoy Proxy umsteigen kann. Es bietet ein umfangreiches Plugin-Ökosystem (200+ Plugins), ein Dashboard (Kong Manager) und ist über das Kubernetes Ingress-Controller-Modell oder als standalone Gateway nutzbar.

Kong-Komponenten:

Kong Gateway: Der eigentliche Proxy (NGINX/Envoy-basiert)
Kong Manager: Web-UI für Konfiguration und Monitoring
Kong Admin API: REST API für programmatische Konfiguration
KIC (Kong Ingress Controller): Kubernetes-native Integration
Kong Plugins: 200+ Plugins für Auth, Logging, Transformation

# Beispiel: Kong mit KongIngress (Rate Limiting)
apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
  name: rate-limiting
  namespace: production
config:
  minute: 60
  hour: 1000
  policy: local
plugin: rate-limiting
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api-gateway
  namespace: production
  annotations:
    konghq.com/plugins: rate-limiting
spec:
  ingressClassName: kong
  rules:
    - host: api.example.com
      http:
        paths:
          - path: /v1
            pathType: Prefix
            backend:
              service:
                name: backend-service
                port:
                  number: 8080

Was ist Envoy Gateway?

Envoy Gateway (CNCF Sandbox-Projekt) ist eine Kubernetes-native API-Gateway-Implementierung, die direkt auf dem Envoy Proxy aufbaut und die neue Kubernetes Gateway API (statt Ingress) als primäre Konfigurationsschnittstelle nutzt. Es wurde von Google, Tetrate und der CNCF-Community entwickelt, um einen standardisierten, zukunftssicheren Weg für API Gateways in Kubernetes zu bieten.

Envoy Gateway-Architektur:

Envoy Proxy: Hochperformanter Proxy (auch Basis für Istio, Cilium)
Gateway API: Standard-Kubernetes-CRDs (GatewayClass, Gateway, HTTPRoute)
extensionServer: Plugin-Mechanismus für Custom-Policies
Keine zusätzliche UI: Konfiguration ausschließlich über Kubernetes-Ressourcen

# Beispiel: Envoy Gateway mit Kubernetes Gateway API
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: production-gateway
  namespace: envoy-gateway-system
spec:
  gatewayClassName: eg
  listeners:
    - name: https
      port: 443
      protocol: HTTPS
      tls:
        mode: Terminate
        certificateRefs:
          - name: tls-cert
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api-route
  namespace: production
spec:
  parentRefs:
    - name: production-gateway
      namespace: envoy-gateway-system
  hostnames:
    - "api.example.com"
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /v1
      backendRefs:
        - name: backend-service
          port: 8080

Direkter Vergleich

Kriterium	Kong	Envoy Gateway
Proxy-Basis	NGINX (optional Envoy)	Envoy Proxy
Konfiguration	Admin API, Ingress, Gateway API	Gateway API (Standard)
Plugin-Ökosystem	200+ Plugins	Wächst (extensionServer)
Web-UI	Kong Manager (OSS + Enterprise)	Keins (CLI/kubectl)
Performance	Sehr gut	Exzellent (Envoy-nativ)
CNCF Status	Nicht CNCF	Sandbox
Kubernetes Gateway API	Ja (ab v3.x)	Primäre API
Lernkurve	Mittel	Mittel–Steil
Community	Sehr groß	Wächst
Enterprise Support	Kong Inc.	Tetrate, Envoy-Community

Performance-Vergleich

Envoy Gateway profitiert direkt von Envoys hochoptimierter C++-Codebasis und dem asynchronen I/O-Modell. Benchmarks zeigen:

Latenz (p99): Envoy Gateway ~20% niedriger als Kong-NGINX
Throughput: Beide > 100.000 RPS auf Standard-Hardware
Memory: Envoy Gateway ca. 30% effizienter bei hohem Traffic
Kong mit Envoy-Backend: Ähnliche Performance wie Envoy Gateway, aber höherer Verwaltungs-Overhead

Für die meisten Deployments spielt der Performance-Unterschied keine praktische Rolle — erst bei mehr als 50.000 RPS wird die Differenz merkbar.

Plugin-Ökosystem: Kong gewinnt deutlich

Kongs größter Vorteil ist das Plugin-Ökosystem:

Authentifizierung: JWT, OAuth2, API Keys, LDAP, OpenID Connect
Rate Limiting: Token Bucket, Sliding Window, Redis-basiert
Transformationen: Request/Response-Modifikation, Header-Rewriting
Logging: Elasticsearch, Datadog, Prometheus, Syslog
Security: IP Restriction, Bot Detection, CORS, CSRF

Envoy Gateway bietet ähnliche Funktionen über EnvoyPatchPolicy und ExtensionPolicy, jedoch erfordern individuelle Erweiterungen eigene Envoy-Filter in Wasm oder C++.

Wann Kong wählen?

Kong ist die bessere Wahl für:

Teams, die sofortige Produktivität mit 200+ fertigen Plugins brauchen
Bestehende Ingress-Deployments, die einen graduellen Migration-Pfad zur Gateway API brauchen
Komplexe API-Management-Anforderungen (API Keys, Billing, Developer Portal)
Kleine bis mittlere Cluster, wo einfache Konfiguration wichtiger ist als maximale Performance
Kong Enterprise-Kunden mit kommerziellen Support-Anforderungen

Wann Envoy Gateway wählen?

Envoy Gateway überzeugt bei:

Neuen Kubernetes-Deployments, die von Anfang auf die Gateway API setzen
Hochperformanten API-Gateways mit mehr als 50.000 RPS
Envoy/Istio-Umgebungen, wo ein einheitlicher Proxy-Stack gewünscht wird
GitOps-Teams, die ausschließlich mit Kubernetes-Ressourcen arbeiten (kein Admin-API)
Zukunftssicherheit: Gateway API ist der Kubernetes-Standard, Ingress ist deprecated

Migration von Kong zu Envoy Gateway

# Envoy Gateway installieren
helm install eg oci://docker.io/envoyproxy/gateway-helm \
  --version v1.1.0 \
  --namespace envoy-gateway-system --create-namespace

# GatewayClass erstellen
kubectl apply -f - <<EOF
apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: eg
spec:
  controllerName: gateway.envoyproxy.io/gatewayclass-controller
EOF

# Kong-Ingress zu HTTPRoute migrieren
# (Tool: ingress2gateway für automatische Konvertierung)
ingress2gateway print --input-file kong-ingress.yaml \
  --providers kong

Fazit

Kong ist 2026 weiterhin die pragmatische Wahl für Teams, die ein reiches Plugin-Ökosystem, eine Web-UI und breite Kompatibilität mit bestehenden Workflows brauchen. Die Unterstützung der Kubernetes Gateway API ab v3 macht Kong zukunftssicher.

Envoy Gateway ist der Blick in die Zukunft: maximal Kubernetes-native, Performance-optimiert und mit der Gateway API als primärem Konfigurations-Interface. Wer heute einen neuen Cluster aufbaut, sollte Envoy Gateway ernsthaft in Betracht ziehen.

Kong vs. Envoy Gateway: API Gateway für Kubernetes im Vergleich 2026