Gateway API: Der Nachfolger von Kubernetes Ingress

Das Gateway API ist der Nachfolger der Ingress-Schnittstelle in Kubernetes. Es löst eine Reihe von Beschränkungen, die Ingress in der Praxis hatte, und ist seit Version 1.0 stabil. Wer heute ein neues Cluster aufsetzt, sollte Gateway API prüfen statt Ingress zu verwenden.

Was an Ingress nicht genügte

Die Ingress-Ressource hat einen einzigen Annotations-Katalog – und der ist implementierungsabhängig. Wer eine Weiterleitung, ein Zeitlimit oder eine Ratenbegrenzung wollte, schrieb herstellerspezifische Anmerkungen wie nginx.ingress.kubernetes.io/rewrite-target in das Objekt. Damit war die Konfiguration nicht übertragbar: Ein Wechsel des Controllers bedeutete, jede Anmerkung von Hand zu übersetzen.

Weitere Einschränkungen:

  • Keine Rollentrennung. Ingress war ein einzelnes Objekt für alle Zwecke. Ein Anwendungsteam, das nur seine eigene Route ändern darf, war nicht vorgesehen.
  • Nur HTTP. Für TCP, UDP oder gRPC brauchte es Sonderwege.
  • Kein Verkehr zwischen Diensten. Für Ost-West-Verkehr (also innerhalb des Clusters) fehlte eine eigene Ressource.

Das Rollenmodell

Der wesentliche Unterschied ist die Aufteilung in drei Ressourcen mit unterschiedlichen Zuständigkeiten:

  • GatewayClass: wird vom Infrastrukturbetreiber definiert und benennt den Controller, der die Gateways tatsächlich umsetzt. Vergleichbar mit StorageClass.
  • Gateway: beschreibt einen konkreten Einstiegspunkt – also Listener, Ports, Protokolle und TLS-Zertifikate. Das ist die Ebene des Plattformteams.
  • HTTPRoute, TCPRoute, GRPCRoute: beschreiben die Regeln, wie Anfragen auf Dienste verteilt werden. Diese Objekte gehören den Anwendungsteams und lassen sich über RBAC auf ihren Namespace beschränken.
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: main-gateway
  namespace: infra
spec:
  gatewayClassName: example-controller
  listeners:
    - name: https
      protocol: HTTPS
      port: 443
      tls:
        mode: Terminate
        certificateRefs:
          - name: wildcard-example-org
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: webapp-route
  namespace: app-team
spec:
  parentRefs:
    - name: main-gateway
      namespace: infra
  hostnames: ["app.example.org"]
  rules:
    - matches:
        - path: {type: PathPrefix, value: /api}
      backendRefs:
        - name: api-service
          port: 8080
      filters:
        - type: RequestHeaderModifier
          requestHeaderModifier:
            set:
              - name: X-Forwarded-Host
                value: app.example.org

Vorteile in der Praxis

  • Übertragbare Konfiguration: Filter wie Weiterleitungen, Kopfzeilenänderungen, Spiegelung oder Zeitlimits sind Teil der Spezifikation – nicht controller-spezifisch.
  • Rollen und Rechte: Über parentRefs mit allowedRoutes lässt sich steuern, welche Namespaces über ein Gateway veröffentlichen dürfen. Das ist der Grund für die Aufnahme in regulierte Umgebungen.
  • Mehr als HTTP: TCP, UDP, gRPC und TLS-Durchleitung sind eigene Ressourcentypen mit demselben Modell.
  • Erweiterbar: Policy-Anhänge und eigene Filter erlauben Ergänzungen, ohne die Kern-API zu ändern.

Umstieg

Ein Ingress-Objekt lässt sich weitgehend mechanisch in HTTPRoute übersetzen: rules[].host wird zu hostnames, paths[].path zu matches, backend.service zu backendRefs. Für die Migration existiert das Werkzeug ingress2gateway, das Ingress-Objekte liest und Gateway-API-Ressourcen ausgibt. Bei Anmerkungen bleibt Handarbeit – sie sind gerade der Teil, der sich nicht übertragen lässt.

Für den Übergang ist ein Parallelbetrieb üblich: Beide Controller laufen, Routen werden schrittweise umgestellt, und der Verkehr wird von außen verglichen. Der Rückweg bleibt offen, solange die alten Objekte noch existieren.

Empfehlung

Für Neuentwicklungen ist Gateway API die richtige Wahl – die API ist stabil, das Rollenmodell ist durchdacht, und die Controller-Landschaft unterstützt sie breit. Bestehende Ingress-Installationen müssen nicht sofort migriert werden, aber die Planung sollte beginnen: Viele Ingress-Controller haben ihrerseits eine angekündigte Abkündigung, und ein späterer Wechsel unter Zeitdruck ist deutlich aufwendiger.

Verwandte Grundlagen: Kubernetes, Reverse-Proxy, Service Mesh, TLS.