Evaluierung API-Management mit Kubernetes

Zielsetzung

Aktuell ist diese Dokumentation eine vorläufige Entscheidungsgrundlage für den Einsatz eines API-Management-Tools in Kubernetes-Clustern (unabhängig der K8s Distribution: Vanilla K8s, OpenShift, Rancher). Ziel ist es, von Use-Cases bereitgestellte APIs mit möglichst geringem Overhead abzusichern und zu verwalten.

Anforderungen

Muss-Kriterien

Authentifizierung & Autorisierung via OAuth2 / OIDC (Keycloak)
API Key Management
Rate Limiting & DDoS-Schutz
API-Versionierung

Wunschkriterien

Traffic Management (z. B. Canary Releases, A/B Testing)
API Analytics / Monitoring
Vollständig Open Source ohne funktionale Einschränkungen in Enterprise-Versionen
Helm-basiertes Deployment, Kubernetes-native Integration

Vergleich ausgewählter Open-Source API Gateways

Tool	Lizenz / CNCF	OAuth2/OIDC (Keycloak)	API Keys	Rate Limiting	Versionierung	Traffic Mgmt	Analytics	K8s Support	Kommentar
APISIX	Apache-2.0	✓	✓	✓	⚠ via verschd. Routen	✓	✓ Prometheus/Grafana	✓ Helm	Bevorzugt da hohe Verbreitung, schlank und Apache Project
Tyk OSS	MPL-2.0	✓	✓	✓	✓	⚠ via Policies	✓ (Own OSS tool: Tyk Pump)	✓ Helm	Gute Wahl, verglichen mit APISIX mehr Komponenten z.B. Redis. Lizenzwahl abhängig von dahinterliegender Firma (kann geändert werden)
Gravitee	Apache-2.0	✓	✓	✓	✓	✓	✓ Integriert in Platform	✓ Helm	Sehr umfangreich inkl. Enterprise Support etc.
Emissary (Amb.)	Apache-2.0 / CNCF	⚠ AuthService	⚠ Custom	⚠ Extern EnvoyProxy	⚠manuell	✓ Canary	⚠ Grafana möglich, nicht so gut ausgereifte Dashboards	✓ Helm	CNCF Incubator Projekt, DEV orientiert => schlank, weniger häufig verbreitet
Kong OSS	Apache-2.0	✗ (nur Enterprise)							Enterprise Features schränken OSS ein, daher raus
Istio Gateway	Apache-2.0 / CNCF	⚠ JWT + Proxy	✗ Nein	✓	✓	✓	✓ Vollständig	✓ Helm	Ohne ServiceMesh (aktuell out-of-scope) zu viel Overhead
Cilium Gateway	Apache-2.0 / CNCF	⚠ via Envoy Proxy	✗ Nein	⚠ via Envoy	✗	⚠ Canary basic	✓ (Hubble, L7)	✓ Helm	Abhängig zu CNI / K8s Distro
NGINX Ingress (CE)	BSD-2	✗ (bspw. mit oauth2-proxy) nicht nativ	✗	⚠ limitiert	⚠ Gibt Workaorund aber nicht optimiert	⚠ Canary only	✗	✓	Sehr stabil für Ingress, aber nicht API-zentriert

Empfehlungen

Favorisierte Tools

APISIX: Sehr gutes Gesamtpaket, leichtgewichtig, vollständig OSS unter Apache, Keycloak-kompatibel, viele Plugins. Dashboard aktuell in Umbau.
Tyk OSS: Leistungsfähig, voll API-zentriert, Versionierung & Auth integriert, ebenfalls komplett OSS, aber mehr Komponenten Overhead UND Firma dahinter kann Lizenz aktuell MPL eventuell ändern.

Nicht empfohlen

Kong: OIDC nur in Enterprise → disqualifiziert für OSS-only Use Case.
Istio: Hoher Overhead für API Management; sinnvoll nur mit vorhandenem Service Mesh. Wiederum für den Pilotbetrieb nur ein Overhead.
Cilium Gateway: Sehr schlank, noch kein vollwertiger API Gateway | Kopplung CNI Wahl
NGINIX: Keine vollwertiges API Gateway

Integration mit bestehenden Ingress Controllern

Unter der Annahme, dass die Datenfabrik auch auf einem Shared Cluster laufen soll, wäre eine Integration hinter bestehenden Ingress Controllern sinnvoll.

Szenario: APISIX hinter bestehendem Ingress Controller

Der bestehende Ingress (z. B. HAProxy, NGINX) leitet ausgewählte Anfragen an den APISIX-Service weiter.
APISIX übernimmt Auth, Rate-Limiting, Logging usw.
Routing erfolgt z. B. über Ingress-Regel zu apisix-gateway Service.
APISIX hat API Management Regeln für Zielroute. Upstream wird dann der eigentliche Kubernetes Services der API angegeben
Ggf.: Nur bestimmte APIs werden über APISIX bereitgestellt

Alternativ: APISIX als Ingress Controller selbst

APISIX bringt einen eigenen apisix-ingress-controller mit
Diesen zu nutzen ist die direkteste Variante, erfordert aber Integration mit dem externen LB oder Exponierung via weiterer Public IP.

Entscheidungsvorlage: Als OSS-basierten API-Gateway-Stack mit Auth, Keys, Limiting und Monitoring empfehlen wir daher APISIX.

Eine Prüfung in 08/25 mit Dataport Architektur-Vertretern ergab, dass noch keine API Management Lösung im Einsatz ist.