Kubernetes API Gateway: Kong, Ambassador und Gloo im Vergleich

TL;DR

• API Gateways uebernehmen Routing, Authentifizierung, Rate Limiting und Observability am Cluster-Eingang -- weit mehr als ein Standard-Ingress-Controller.
• Kong bietet das groesste Plugin-Oekosystem und eignet sich besonders fuer heterogene Umgebungen mit vielen Integrationen.
• Ambassador (Emissary-Ingress) basiert auf Envoy und ist ideal fuer Teams, die deklarative Kubernetes-native Konfiguration bevorzugen.
• Gloo Edge kombiniert Envoy mit einer Function-Level-Routing-Schicht und unterstuetzt REST, gRPC und GraphQL nativ.
• Alle drei Loesungen sind kompatibel mit der Kubernetes Gateway API -- ein Wechsel ist dadurch weniger riskant.

Warum ein Standard-Ingress-Controller nicht ausreicht

Ein NGINX Ingress Controller deckt grundlegendes HTTP-Routing und TLS-Termination ab. Sobald Anforderungen wie OAuth2-Integration, API Key Management, granulares Rate Limiting oder Request/Response-Transformation hinzukommen, stoesst der Ingress an seine Grenzen.

API Gateways sind speziell fuer diese Aufgaben konzipiert. Sie sitzen als zentrale Kontrollschicht zwischen externem Traffic und internen Services. Fuer eine grundlegende Einfuehrung in die neue Gateway API als Ingress-Nachfolger lohnt sich der Blick auf Kubernetes Gateway API: Der Ingress-Nachfolger.

Entscheidungskriterien im Ueberblick

Kong: Setup und Konfiguration

Installation mit Helm

helm repo add kong https://charts.konghq.com
helm repo update

helm install kong kong/ingress -n kong-system --create-namespace \
  --set gateway.env.database=off \
  --set gateway.env.plugins="bundled,oidc" \
  --set controller.ingressController.installCRDs=true

Der DB-less Mode (database=off) speichert die Konfiguration deklarativ in Kubernetes-Ressourcen. Fuer Produktionsumgebungen mit vielen dynamischen Aenderungen kann PostgreSQL als Backend sinnvoll sein.

Routing mit KongIngress und HTTPRoute

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: user-api-route
  namespace: production
  annotations:
    konghq.com/strip-path: "true"
spec:
  parentRefs:
    - name: kong-gateway
      namespace: kong-system
  hostnames:
    - "api.example.com"
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /users
      backendRefs:
        - name: user-service
          port: 8080
    - matches:
        - path:
            type: PathPrefix
            value: /orders
      backendRefs:
        - name: order-service
          port: 8080

Rate Limiting mit Kong Plugin

apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
  name: rate-limit-api
  namespace: production
spec:
  plugin: rate-limiting
  config:
    minute: 60
    hour: 1000
    policy: redis
    redis_host: redis.infrastructure
    redis_port: 6379
    redis_database: 0
    fault_tolerant: true
    hide_client_headers: false
---
apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
  name: key-auth
  namespace: production
spec:
  plugin: key-auth
  config:
    key_names:
      - X-API-Key
    hide_credentials: true

Plugins werden per Annotation an Services oder Routes gebunden:

apiVersion: v1
kind: Service
metadata:
  name: user-service
  namespace: production
  annotations:
    konghq.com/plugins: rate-limit-api,key-auth
spec:
  selector:
    app: user-service
  ports:
    - port: 8080

Ambassador (Emissary-Ingress): Setup und Konfiguration

Installation

helm repo add datawire https://app.getambassador.io
helm repo update

helm install emissary datawire/emissary-ingress -n emissary-system \
  --create-namespace \
  --set replicaCount=2

Mapping-basiertes Routing

Ambassador verwendet Mappings als zentrale Routing-Ressource:

apiVersion: getambassador.io/v3alpha1
kind: Mapping
metadata:
  name: user-api-mapping
  namespace: production
spec:
  hostname: api.example.com
  prefix: /users/
  service: user-service.production:8080
  timeout_ms: 5000
  retry_policy:
    retry_on: "5xx"
    num_retries: 3
  labels:
    ambassador:
      - request_label:
        - user-api

OAuth2-Authentifizierung mit AuthService

apiVersion: getambassador.io/v3alpha1
kind: AuthService
metadata:
  name: oauth2-filter
  namespace: emissary-system
spec:
  auth_service: "oauth2-proxy.auth-system:4180"
  proto: http
  path_prefix: "/oauth2/auth"
  allowed_request_headers:
    - "Authorization"
    - "Cookie"
  allowed_authorization_headers:
    - "X-Auth-Request-User"
    - "X-Auth-Request-Email"

Rate Limiting mit Ambassador

apiVersion: getambassador.io/v3alpha1
kind: RateLimitService
metadata:
  name: ratelimit
  namespace: emissary-system
spec:
  service: ratelimit.infrastructure:8081
  protocol_version: v3
---
apiVersion: getambassador.io/v3alpha1
kind: Mapping
metadata:
  name: rate-limited-api
  namespace: production
spec:
  hostname: api.example.com
  prefix: /api/
  service: api-service.production:8080
  labels:
    ambassador:
      - request_label:
        - api-rate-limit

Gloo Edge: Setup und Konfiguration

Installation

helm repo add gloo https://storage.googleapis.com/solo-public-helm
helm repo update

helm install gloo gloo/gloo -n gloo-system --create-namespace \
  --set discovery.enabled=true \
  --set gateway.enabled=true

Gloo Edge erkennt durch sein Discovery-System automatisch Services im Cluster und erstellt sogenannte Upstreams.

Routing mit VirtualService

apiVersion: gateway.solo.io/v1
kind: VirtualService
metadata:
  name: api-gateway
  namespace: gloo-system
spec:
  virtualHost:
    domains:
      - "api.example.com"
    routes:
      - matchers:
          - prefix: /users
        routeAction:
          single:
            upstream:
              name: production-user-service-8080
              namespace: gloo-system
        options:
          prefixRewrite: /
          timeout: 10s
          retries:
            retryOn: "5xx,connect-failure"
            numRetries: 3
      - matchers:
          - prefix: /orders
        routeAction:
          single:
            upstream:
              name: production-order-service-8080
              namespace: gloo-system

Rate Limiting mit Gloo

apiVersion: ratelimit.solo.io/v1alpha1
kind: RateLimitConfig
metadata:
  name: api-rate-limit
  namespace: gloo-system
spec:
  raw:
    descriptors:
      - key: remote_address
        rateLimit:
          requestsPerUnit: 100
          unit: MINUTE
      - key: header_match
        value: "premium"
        rateLimit:
          requestsPerUnit: 1000
          unit: MINUTE

Authentifizierungsmuster im Vergleich

Alle drei Gateways unterstuetzen gaengige Authentifizierungsmethoden, unterscheiden sich aber in der Implementierung:

API Key Authentication:

• Kong: Natives Plugin key-auth, Keys in Kubernetes Secrets
• Ambassador: Ueber AuthService oder External Filter
• Gloo: Natives API Key Secret mit automatischer Rotation

JWT Validation:

• Kong: Plugin jwt mit konfigurierbaren Claims
• Ambassador: JWT Filter mit JWKS-Endpoint
• Gloo: Natives JWT-Feature mit lokaler und Remote-Validierung

OAuth2/OIDC:

• Kong: Enterprise-Plugin openid-connect
• Ambassador: Integration mit oauth2-proxy
• Gloo: Enterprise-Feature mit Keycloak, Auth0, Okta

Fuer die Absicherung der Services hinter dem Gateway sollten Health Checks korrekt konfiguriert sein. Details dazu finden Sie unter Kubernetes Health Checks und Probes.

Observability und Monitoring

Ein API Gateway ohne Metriken ist wie ein Flugzeug ohne Instrumente. Alle drei Gateways exportieren Prometheus-Metriken:

# Kong Metriken pruefen
kubectl port-forward -n kong-system svc/kong-gateway-metrics 8100:8100
curl http://localhost:8100/metrics | grep kong_http_requests_total

# Ambassador Metriken
kubectl port-forward -n emissary-system svc/emissary-ingress-admin 8877:8877
curl http://localhost:8877/metrics | grep envoy_http_downstream_rq

# Gloo Metriken
kubectl port-forward -n gloo-system svc/gloo 9091:9091
curl http://localhost:9091/metrics | grep envoy_cluster_upstream_rq

Wichtige Metriken fuer Alerting:

Welches Gateway fuer welchen Anwendungsfall?

Kong waehlen, wenn:

• Sie ein grosses Plugin-Oekosystem benoetigen
• Bestehende NGINX-Expertise im Team vorhanden ist
• Multi-Protocol-Support (REST, gRPC, WebSocket, GraphQL) wichtig ist
• Kong Konnect als SaaS-Management-Plane genutzt werden soll

Ambassador waehlen, wenn:

• Das Team bereits Envoy-Erfahrung hat
• GitOps-Workflows mit deklarativen CRDs gewuenscht sind
• Telepresence fuer lokale Entwicklung genutzt wird
• Einfache Integration in bestehende Service Mesh Setups benoetigt wird

Gloo Edge waehlen, wenn:

• Function-Level-Routing (einzelne Endpunkte statt Services) benoetigt wird
• GraphQL als nativer Proxy ohne separaten Server gewuenscht ist
• WebAssembly-basierte Erweiterungen geplant sind
• Integration mit Serverless-Funktionen (AWS Lambda, Google Cloud Functions) noetig ist

Migration von Ingress zum API Gateway

Eine schrittweise Migration minimiert das Risiko. Der empfohlene Weg:

1. API Gateway parallel zum bestehenden Ingress installieren -- eigener LoadBalancer-Service
2. Unkritische Routes zuerst migrieren -- interne APIs, Staging-Umgebungen
3. DNS mit gewichtetem Routing -- 10% Traffic auf neues Gateway, 90% auf alten Ingress
4. Monitoring vergleichen -- Latenz, Error Rates, Throughput
5. Schrittweise umstellen -- Route fuer Route, Namespace fuer Namespace

Fuer die Planung verschiedener Deployment-Strategien waehrend der Migration ist Kubernetes Deployment Strategien hilfreich.

Haeufige Fehler bei der Gateway-Konfiguration

Kein Timeout konfiguriert: Ohne explizites Timeout haengen Requests bei Backend-Ausfaellen bis zum Client-Timeout. Immer ein sinnvolles Timeout setzen (5-30 Sekunden je nach Anwendungsfall).

Rate Limits zu global: Ein einzelnes globales Limit trifft alle Clients gleich. Besser: Gestaffelte Limits pro API Key, Tenant oder Endpunkt.

TLS nur am Gateway: TLS-Termination am Gateway ist Standard, aber die Kommunikation zwischen Gateway und Backend-Services sollte ebenfalls verschluesselt sein. Ein Service Mesh wie Istio Ambient kann mTLS transparent bereitstellen.

Health Checks ignoriert: Konfigurieren Sie aktive Health Checks im Gateway, damit ungesunde Backends fruehzeitig aus dem Pool entfernt werden.

Fazit

Die Wahl des API Gateways haengt von den Anforderungen des Teams und der bestehenden Infrastruktur ab. Kong bietet die breiteste Plugin-Landschaft, Ambassador die beste Kubernetes-Integration und Gloo Edge die staerkste Function-Level-Kontrolle. Alle drei unterstuetzen die Kubernetes Gateway API und lassen sich in Service Mesh Architekturen integrieren.

Starten Sie mit dem Gateway, das am besten zu Ihrem bestehenden Workflow passt, und beginnen Sie mit einem nicht-kritischen Service. Die Gateway API sorgt dafuer, dass ein spaeterer Wechsel kein komplettes Rewrite erfordert.