GKE Gateway API vs Ingress 2026: Wann nginx Geschichte ist

Jahrelang bedeutete das Exponieren einer Anwendung auf Kubernetes eines von zwei Dingen: ein Cloud-Ingress-Objekt vollgestopft mit Annotationen, oder ein selbst gehosteter nginx-Ingress-Controller, der als Pods im Cluster läuft. Beides funktioniert. Beides ist jetzt der alte Weg.

2026 lautet die Antwort der Kubernetes-Community Gateway API, und auf GKE ist es allgemein verfügbar, rollenorientiert und direkt von Googles Cloud Load Balancing getragen. Das hier ist ein praktischer Leitfaden dazu, was es ist, welche vier GatewayClasses du wirklich bekommst, was regionale Cluster zwingend konfigurieren müssen und wann sich das Abschalten von nginx lohnt.

Warum Ingress am Ende war

Ingress wurde als eine Ressource entworfen, die alles macht: sie definiert das Frontend (Ports, TLS), die Routing-Regeln (Host und Pfad zum Service) und — weil die Basisspezifikation dünn ist — einen Haufen controller-spezifischer Annotationen für alles Fortgeschrittene. Rewrites, Redirects, Timeouts, CORS, Body-Size: alles Annotationen.

Das erzeugt zwei Probleme. Erstens vermischt ein Objekt in der Hand eines Teams Plattform-Belange (TLS, IP-Adressen) mit Applikations-Belangen (Routen). Zweitens ist jede Annotation anbieterspezifisch, also ist deine Konfiguration weder portabel noch auf standardisierte Weise ausdrucksstark.

Das Gateway-API-Modell: drei Rollen statt einem Objekt

Gateway API ist eine Weiterentwicklung von Ingress, die das eine Objekt in drei Ressourcen aufbricht, ausgerichtet daran, wer welchen Belang wirklich besitzt:

• GatewayClass — eine cluster-weite Vorlage für einen Load Balancer. Auf GKE stellt Google sie bereit; du schreibst sie nicht. Jede GatewayClass entspricht einem bestimmten Cloud-Load-Balancer-Typ.
• Gateway — erstellt vom Plattform- / Cluster-Operator. Es deklariert, wo und wie gelauscht wird: Ports, Protokolle, TLS und IP-Adressen. Es wählt eine GatewayClass.
• HTTPRoute — erstellt von App-Teams. Sie deklariert das Routing: welche Hostnamen und Pfade auf welche Services zeigen, plus Header-Matching, Traffic-Splitting, Redirects und Rewrites — alles native Felder, keine Annotationen.

Gateway und Route binden bidirektional: ein Gateway deklariert, welche Namespaces sich anhängen dürfen, und eine Route deklariert, an welches Gateway sie sich anhängt. Genau das macht einen einzelnen Load Balancer sicher teilbar über Teams und Namespaces hinweg — die Mehrmandantenfähigkeit, die Ingress nie hatte.

Der GKE-Gateway-Controller selbst ist Google-gehostet und läuft out of band: er beobachtet die Kubernetes-API und gleicht Cloud-Load-Balancing-Ressourcen ab. Er ist keine Datenebene, sitzt nicht im Anfragepfad und läuft weder auf deiner Control Plane noch in deinem Projekt. Das ist ein spürbarer Robustheits- und Skalierungsunterschied gegenüber einem In-Cluster-nginx-Controller.

Die vier GatewayClasses, die du standardmäßig bekommst

Aktiviere Gateway API und GKE installiert die Single-Cluster-GatewayClasses automatisch. Vier zählen für die tägliche Arbeit:

Google empfiehlt ausdrücklich gke-l7-global-external-managed gegenüber dem klassischen gke-l7-gxlb, um die fortgeschrittenen Sicherheits- und Traffic-Management-Funktionen zu erhalten. Es gibt auch Multi-Cluster-Varianten (-mc) für Fleets und eine Service-Mesh-Klasse (gke-td), aber die obigen vier decken die große Mehrheit der Single-Cluster-Deployments ab.

Regionale Cluster: Das Proxy-only-Subnetz ist Pflicht

Das ist der Schritt, über den Leute stolpern, also bekommt er einen eigenen Abschnitt.

Beide regionalen GatewayClasses — gke-l7-regional-external-managed und gke-l7-rilb — benötigen ein Proxy-only-Subnetz in jeder Region, in der du sie einsetzt. Die globale externe Klasse nicht. Das Proxy-only-Subnetz ist der Ort, an dem Cloud Load Balancing seine verwalteten Envoy-Proxys platziert; ohne es scheitert der Gateway-Controller mit einem Fehler, dass ein reserviertes Managed-Proxy-Subnetz mit Purpose REGIONAL_MANAGED_PROXY erforderlich ist.

Erstelle es einmal pro Region, vor dem Gateway:

gcloud compute networks subnets create proxy-only-subnet \
    --purpose=REGIONAL_MANAGED_PROXY \
    --role=ACTIVE \
    --region=europe-west3 \
    --network=my-vpc \
    --range=10.129.0.0/23

Ein /23 ist der empfohlene Bereich, damit genug IPs für die Skalierung der Proxys da sind; /26 (64 Adressen) ist das harte Minimum. Ein ACTIVE-Proxy-only-Subnetz bedient alle regionalen Gateways in dieser Region und VPC — du erstellst nicht eines pro Gateway.

Existiert in der Region bereits ein Proxy-only-Subnetz mit dem älteren Purpose INTERNAL_HTTPS_LOAD_BALANCER, migriere es zu REGIONAL_MANAGED_PROXY; GKE Gateway akzeptiert nur Letzteres.

Ein minimales Gateway + HTTPRoute

Das Plattform-Team deployt das Gateway einmal:

kind: Gateway
apiVersion: gateway.networking.k8s.io/v1
metadata:
  name: external-http
spec:
  gatewayClassName: gke-l7-global-external-managed
  listeners:
  - name: https
    protocol: HTTPS
    port: 443
    tls:
      mode: Terminate
      certificateRefs:
      - name: store-example-com

Ein App-Team hängt dann eigenständig Routen an, im eigenen Namespace:

kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1
metadata:
  name: store
spec:
  parentRefs:
  - kind: Gateway
    name: external-http
  hostnames:
  - "store.example.com"
  rules:
  - matches:
    - path:
        value: /de
    backendRefs:
    - name: store-german
      port: 8080
  - backendRefs:
    - name: store-v1
      port: 8080

Header-Matching, gewichtetes Traffic-Splitting, Pfad-Redirects und URL-Rewrites sind erstklassige Felder auf der HTTPRoute — was früher nginx-Annotationen waren, ist jetzt portable Spezifikation. Für alles Load-Balancer-Spezifische (Health Checks, Backend-Policies) hängst du eine Policy-Ressource an (HealthCheckPolicy, GCPBackendPolicy) statt eines BackendConfig.

Wann man nginx ablöst

Hier die ehrliche Version.

Ein selbst gehosteter nginx-Ingress-Controller läuft als Deployment-Pods in deinem Cluster. Du besitzt ihr Autoscaling, ihren Ressourcen-Fußabdruck, ihre Upgrades und jede nginx- und Ingress-Controller-CVE, die auftaucht. Dafür bekommst du einen sehr fähigen In-Cluster-L7-Proxy.

GKE Gateway entfernt diese Betriebsfläche vollständig. Die Datenebene ist Google-verwaltetes Cloud Load Balancing. Es gibt keine Ingress-Pods zu betreiben, skalieren oder patchen; der Controller läuft out of band; und der Load Balancer ist Googles globale Infrastruktur, nicht drei Repliken, die du per Schätzung dimensioniert hast.

Migriere zu Gateway, wenn:

• Du willst, dass die L7-Datenebene jemand anderes Betriebsproblem ist — der Normalfall.
• Du globales Load Balancing, Anycast-IPs oder Cloud-Armor-/Cloud-CDN-Integration brauchst, die direkt in Cloud Load Balancing einklinkt.
• Du Rollentrennung willst: Plattform besitzt Gateways, App-Teams besitzen Routen, über Namespaces hinweg.
• Du bei null anfängst — jedes bestehende Ingress bildet sich sauber auf ein Gateway plus eine HTTPRoute ab.

Behalte nginx nur, wenn:

• Du von In-Cluster-L7-Funktionen abhängst, die Cloud Load Balancing nicht bietet (exotische Lua-/Rewrite-Logik, spezielle Auth-Module, Protokolle jenseits HTTP/S).
• Du TCP/UDP- oder TLS-Passthrough-Routing brauchst — GKE Gateway unterstützt derzeit nur HTTPRoute; TCPRoute, UDPRoute und TLSRoute nicht.
• Du eine selbst verwaltete L7-Datenebene willst, die du über Clouds hinweg vollständig kontrollierst und nicht an den Managed-Load-Balancer des jeweiligen Anbieters gebunden ist. Ehrlicher Vorbehalt: Gateway API ist selbst ein portabler Standard, also passt eine portable Gateway-Implementierung (Envoy Gateway, NGINX Gateway Fabric) hier meist besser als klassisches nginx-Ingress.

Die Feldregel

Gateway API ist die Richtung, in die Kubernetes-Ingress geht, und auf GKE ist es GA, kostenlos mit der Plattform und von Googles Cloud Load Balancing getragen. Teile das alte Ingress in GatewayClass + Gateway + HTTPRoute, nimm standardmäßig gke-l7-global-external-managed für Internet-Apps, wechsle zu gke-l7-rilb für privaten Verkehr, und merke dir die eine harte Voraussetzung: regionale Klassen brauchen ein Proxy-only-Subnetz pro Region. Für die meisten Teams ist genau diese Kombination der Moment, in dem selbst gehostetes nginx sich nicht mehr lohnt.

Zum Cluster-Modus, auf dem das alles läuft, siehe GKE Autopilot vs Standard 2026. Um einzugrenzen, was diese Workloads erreichen dürfen, sobald Verkehr drin ist, siehe Service-Account-Schlüssel abschaffen: Workload Identity Federation auf GKE.