--- title: "GKE Gateway API vs Ingress 2026: Wann nginx Geschichte ist" description: "GKE Gateway API vs Ingress 2026: das rollenorientierte Modell, die vier GatewayClasses, das Proxy-only-Subnetz für regionale Cluster und wann man nginx ablöst." author: Aleksei Aleinikov date: 2026-07-16 lang: de tags: [gke-gateway-api, kubernetes-ingress, gke, gatewayclass, kubernetes, google-cloud, load-balancing] canonical: https://www.alekseialeinikov.com/de/blog/topics/cloud/gke-gateway-api-vs-ingress-nginx-abloesen-2026 source: alekseialeinikov.com --- # 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. ![Ingress packt Frontend, Routing, TLS und Anbieter-Annotationen in ein Objekt; Gateway API teilt dieselbe Aufgabe in GatewayClass, Gateway und HTTPRoute, jede in der Hand einer anderen Rolle.](https://www.alekseialeinikov.com/blog/gke-gateway-vs-ingress-2026.webp) ## 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: ![Die vier Single-Cluster-GatewayClasses: global-external-managed (empfohlen), regional-external-managed und rilb (beide brauchen ein Proxy-only-Subnetz) und das veraltete gxlb zum Meiden.](https://www.alekseialeinikov.com/blog/gke-gatewayclasses-2026.webp) | GatewayClass | Load Balancer | Wofür | |---|---|---| | `gke-l7-global-external-managed` | Global external Application LB | **Empfohlener** Standard für Internet-Apps; Anycast-IP, Premium Tier, geringste globale Latenz | | `gke-l7-regional-external-managed` | Regional external Application LB | Externer Verkehr, an eine Region gebunden | | `gke-l7-rilb` | Internal Application LB | Privater, VPC-interner Verkehr | | `gke-l7-gxlb` | Classic Application LB | Veraltet — **meiden**; keine HTTP-zu-HTTPS-Weiterleitung, keine Custom Headers | 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: ```bash 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: ```yaml 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: ```yaml 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. ![Entscheidungsfluss: interner Verkehr geht zu gke-l7-rilb; externer Single-Region zu regional-external-managed; externer global zu global-external-managed. In jedem Zweig ist die Datenebene Google-verwaltet, ohne nginx-Pods.](https://www.alekseialeinikov.com/blog/gke-gateway-decision-2026.webp) **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](https://www.alekseialeinikov.com/de/blog/topics/cloud/gke-autopilot-vs-standard-vergleich-2026). Um einzugrenzen, was diese Workloads erreichen dürfen, sobald Verkehr drin ist, siehe [Service-Account-Schlüssel abschaffen: Workload Identity Federation auf GKE](https://www.alekseialeinikov.com/de/blog/topics/security/service-account-schluessel-abschaffen-workload-identity-federation-2026).