Von Ingress API zu Gateway API: Warum sich der Wechsel lohnt

Kubernetes-Nutzer kennen die Ingress API seit Jahren als Standardweg, um HTTP(S)-Traffic ins Cluster zu routen. Aber die Ingress API zeigt inzwischen deutliche Grenzen – und genau deshalb hat sich die Gateway API als moderner, flexiblerer Nachfolger etabliert. In diesem Artikel schauen wir uns an, warum sich der Umstieg lohnt, was sich konzeptionell ändert und wie sich konkrete Ingress-Features auf die Gateway API übertragen lassen.

Warum überhaupt wechseln?

Die Ingress API hat drei grundlegende Schwachstellen, die im Alltag schnell spürbar werden:

1. Eingeschränkte Funktionalität

Die Ingress API unterstützt nur TLS-Terminierung und einfaches, inhaltsbasiertes Routing von HTTP-Traffic. TCP, UDP oder gRPC-Routing? Fehlanzeige. Um trotzdem erweiterte Funktionen anzubieten, greifen Ingress-Controller auf Annotationen zurück – proprietäre Erweiterungen, die außerhalb des eigentlichen Standards liegen.

Das Problem dabei: Jede Implementierung (NGINX, Traefik, Envoy, …) bringt ihre eigenen Annotationen mit, die nicht zwangsläufig zu anderen Controllern kompatibel sind. Wer den Ingress-Controller wechselt, muss:

1. Alle verwendeten Annotationen identifizieren,
2. die entsprechenden Funktionen im neuen Controller suchen,
3. und die Konfiguration manuell nachbauen.

Das macht den Wechsel zwischen Implementierungen mühsam bis unmöglich.

2. Fehlendes Berechtigungsmodell

Das klassische Ingress-Modell wurde um eine einzige zentrale Ressource herum entworfen. Dadurch gibt es faktisch nur eine Hauptrolle: die Person, die die Ingress-Ressource erstellt. Diese kann gleichzeitig Routing-Regeln definieren, TLS konfigurieren und teilweise sogar Einfluss auf die zugrunde liegende Load-Balancing-Infrastruktur nehmen.

In kleinen Clustern mit einem Team ist das kein Problem. Aber stell dir folgendes Szenario vor:

• Team A betreibt einen Shop
• Team B betreibt eine API
• Team C betreibt ein Kundenportal
• Alle teilen sich denselben Load Balancer bzw. Ingress Controller

Mit dem Ingress-Modell fehlt eine saubere Trennung zwischen Infrastruktur-Verantwortlichen, Applikations-Administratoren und Entwicklern. Entwickler können dadurch potenziell Konfigurationen erstellen, die sich auf die gemeinsam genutzte Infrastruktur auswirken – ohne dass es dafür ein standardisiertes Rollenmodell gibt.

3. Unhandliches API-Design

Annotationen sind einfache Key-Value-Strings und werden pauschal im Metadata-Block gesetzt statt strukturiert im relevanten Teil der Spec. Sobald viele Annotationen zusammenkommen, wird eine Ingress-Ressource schnell unübersichtlich.

Die Kernunterschiede:

Personas

Einer der größten konzeptionellen Sprünge der Gateway API ist ein sauber definiertes Rollenmodell.

Bei der Ingress API gibt es im Kern nur eine explizite Persona:

• Der User: Besitzer der Ingress-Ressourcen

Implizit kommen dazu:

• Infrastructure Provider: verwaltet einen providerseitig bereitgestellten Ingress-Controller
• Cluster Operator/Admin: verwaltet selbst gehostete Ingress-Controller

Beide wurden erst mit der späten Einführung der IngressClass-Ressource zu offiziellen Personas.

Bei der Gateway API ist die Rollenverteilung von Anfang an klar strukturiert:

• Application Developer: definiert Routing-Regeln für seine Anwendungen
• Application Admin: definiert Entry Points für externen Client-Traffic inkl. TLS-Terminierung
• Cluster Operator: definiert ebenfalls Entry Points und TLS-Konfiguration
• Infrastructure Provider: stellt GatewayClass/Controller bereit

Diese Aufteilung passt zu Organisationen, in denen mehrere Teams sich dieselbe Load-Balancing-Infrastruktur teilen. Wichtig: Das Self-Service-Modell muss dadurch nicht aufgegeben werden – es lässt sich weiterhin eine einzelne RBAC-Rolle definieren, die alle drei Verantwortlichkeiten (Developer, Admin, Operator) übernimmt.

Funktionsumfang und Erweiterbarkeit

Die Gateway API deckt sämtliche Ingress-Features ab – plus viele Funktionen, die bei Ingress nur über Annotationen erreichbar waren. Dadurch ist sie deutlich portabler.

Für Features, die nicht standardisiert werden können (z. B. Authentifizierung, Connection Timeouts, Health Checks), bietet die Gateway API drei definierte Extension Points:

External References

Ein Feld einer Gateway-API-Ressource kann auf eine implementierungsspezifische Custom Resource verweisen. So bleibt der Standard schlank, während Hersteller wie Envoy Gateway oder Istio eigene Spezialfunktionen anbieten können:

HTTPRoute
   |
   +--> Standardisierte Gateway API Felder
   |
   +--> Hersteller-spezifische Erweiterungsfelder (Custom Resource)

Beispiel: Ein HTTPRouteFilter kann über extensionRef auf eine herstellerspezifische Ressource verweisen, etwa eine JWT-Authentifizierung, die kein Standardfilter ist:

filters:
- type: ExtensionRef
  extensionRef:
    group: gateway.envoyproxy.io
    kind: JwtAuthentication
    name: company-auth

Custom Implementations

Manche Features werden bewusst der jeweiligen Implementierung überlassen – etwa der RegularExpression-Typ von HTTPPathMatch. Diese gelten als „implementation-specific" bzw. „custom" im Konformitätslevel.

Policies

Für Data-Plane-Funktionen wie Authentifizierung, Autorisierung, Rate Limiting, WAF-Regeln oder Caching können Hersteller eigene Policy-Ressourcen definieren. Die Gateway API schreibt dabei nicht vor, wie diese Ressourcen aussehen – aber sie schreibt vor, wie eine Policy an eine Gateway-Ressource angebunden wird. Das sorgt für eine einheitliche UX über verschiedene Hersteller hinweg.

Der entscheidende Unterschied zu External References: Bei Policies referenziert die Policy die Route, nicht umgekehrt.

Statt:

kind: HTTPRoute
spec:
  auth:
    enabled: true

sieht das bei Gateway API so aus:

kind: HTTPRoute
metadata:
  name: webshop
---
kind: AuthenticationPolicy
spec:
  targetRef:
    kind: HTTPRoute
    name: webshop

Annotationen als Extension Point sind bei der Gateway API übrigens explizit nicht vorgesehen und werden für Implementierungen stark abgeraten.

Feature-Mapping: Von Ingress zu Gateway API

Ingress-Konzept	Gateway-API-Äquivalent
Entry Points	Müssen explizit als Listener in einer Gateway-Ressource definiert werden
TLS-Terminierung	Eigenschaft des Gateway-Listeners; Zertifikat weiterhin im Secret
Routing-Regeln	Path-Matching wandert 1:1 in die HTTPRoute
Default Backend	Kein direktes Äquivalent – muss explizit als Routing-Regel (/-Prefix) definiert werden
IngressClass	parentRef in der HTTPRoute verweist auf das jeweilige Gateway

Routing im Detail: hostnamespezifisch vs. global

Ein wichtiger Unterschied: Bei Ingress besitzt jeder Hostname seinen eigenen Regelblock:

spec:
  rules:
  - host: shop.example.com
    http:
      paths:
      - path: /
        backend: shop-service
  - host: api.example.com
    http:
      paths:
      - path: /
        backend: api-service

Bei der HTTPRoute gelten die Regeln automatisch für alle angegebenen Hostnamen:

spec:
  hostnames:
  - shop.example.com
  - api.example.com
  rules:
  - matches:
      - path:
          value: /
    backendRefs:
      - name: app

Merging & Conflict Resolution

Bei Ingress ist weder das Zusammenführen von Regeln noch die Konfliktauflösung standardisiert – jeder Controller kann das anders handhaben. Die Gateway API hingegen legt genau fest, wie Regeln gemergt und Konflikte aufgelöst werden.

Was ist mit Annotationen?

Annotationen sind naturgemäß implementierungsspezifisch, deshalb hängt ihre Migration sowohl vom alten Ingress-Controller als auch vom neuen Gateway-Implementation ab.

Nehmen wir NGINX als Beispiel:

metadata:
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    nginx.ingress.kubernetes.io/ssl-redirect: "true"

Diese Annotationen versteht ausschließlich der NGINX Ingress Controller – andere Controller ignorieren sie oder nutzen eigene Pendants.

Die gute Nachricht: Viele früher annotationsbasierte Funktionen sind heute Teil des offiziellen Standards. Aus

annotations:
  nginx.ingress.kubernetes.io/ssl-redirect: "true"

wird bei Gateway API ein offizieller Filter:

filters:
- type: RequestRedirect

Für alles, was implementierungsspezifisch bleibt (JWT-Auth, WAF-Regeln, spezielle Envoy-Features), gilt: Ab in die Doku der jeweiligen Gateway-Implementierung, um den passenden Extension Point zu finden.

Implementierungen und Konformität

Die Gateway API unterscheidet zwei Implementierungsprofile:

• Gateway: für North-South-Traffic
• Mesh: für East-West-Traffic innerhalb eines Clusters oder Cluster-Sets

Jedes Profil hat eigene Konformitätstests. Aktuell gibt es drei Konformitätsstufen:

• Conformant: z. B. Traefik (Controller), Cilium (Controller & Mesh)
• Partially Conformant: z. B. Envoy Gateway (u. a. im Einsatz bei Giant Swarm)
• Stale: z. B. Azure Application Gateway for Containers (Controller)

Automatisierte Migration

Für die tatsächliche Migration muss man nicht bei null anfangen: Das ingress2gateway-Projekt von Kubernetes SIGs konvertiert bestehende Ingress-Ressourcen automatisiert in Gateway-API-Ressourcen und nimmt einem damit einen guten Teil der manuellen Arbeit ab.

Fazit

Die Gateway API löst die drei größten Schwachstellen der Ingress API auf einmal: mehr Features out-of-the-box, ein klares Rollenmodell für Multi-Team-Cluster und ein sauberes, strukturiertes API-Design statt eines Annotations-Wildwuchses. Wer aktuell mit vielen implementierungsspezifischen Annotationen kämpft oder mehrere Teams über dieselbe Ingress-Infrastruktur koordinieren muss, sollte sich die Migration ernsthaft anschauen – idealerweise mit Unterstützung durch ingress2gateway als Ausgangspunkt.