Kubernetes Gateway API vs Nginx Ingress: Modernes Traffic-Management im Vergleich 2026

Die Kubernetes Gateway API ist der neue Standard für Traffic-Management. Wir vergleichen sie mit dem bewährten Nginx Ingress Controller für dein Cluster.

Das Problem mit Kubernetes Ingress

Der Kubernetes Ingress-Typ existiert seit Kubernetes v1.1 (2015) und hat eine wichtige Schwäche: Das API ist zu einfach für moderne Anforderungen. Header-basiertes Routing, Traffic-Splitting, Canary-Deployments, TLS-Terminierung mit mehreren Backends – alles erfordert Annotations, die nicht standardisiert sind. Was beim Nginx Ingress Controller funktioniert, funktioniert nicht beim Traefik oder Haproxy Ingress.

Die Kubernetes Gateway API (GA seit Kubernetes v1.28) löst dieses Problem mit einem standardisierten, erweiterbaren API, das von fast allen Ingress-Controllern und Service-Meshes unterstützt wird.

Nginx Ingress Controller: Der bewährte Standard

Mit weit über 100 Millionen Downloads ist der Nginx Ingress Controller der meistgenutzte Ingress-Controller für Kubernetes. Er basiert auf Nginx und bietet eine einfache, gut dokumentierte Konfiguration über Kubernetes Annotations.

Installation

# Via Helm
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm install ingress-nginx ingress-nginx/ingress-nginx \
  -n ingress-nginx --create-namespace

Basis-Ingress-Konfiguration

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  namespace: production
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
spec:
  ingressClassName: nginx
  rules:
    - host: app.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: app-service
                port:
                  number: 80
  tls:
    - hosts:
        - app.example.com
      secretName: app-tls

Annotations für fortgeschrittene Features

Canary-Deployments und Traffic-Splitting sind nur über proprietäre Annotations möglich:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-canary
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "20"  # 20% Canary-Traffic
spec:
  ingressClassName: nginx
  rules:
    - host: app.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: app-canary-service
                port:
                  number: 80

Dieses Annotations-Modell ist der Kernkritikpunkt: Es ist nicht portierbar – beim Wechsel zu einem anderen Ingress-Controller muss die gesamte Konfiguration neu geschrieben werden.

Kubernetes Gateway API: Der neue Standard

Die Kubernetes Gateway API (SIG-Network) wurde entwickelt, um die Limitierungen von Ingress zu überwinden. Das API ist role-oriented: Infrastructure Provider (Cluster-Ops), Cluster-Operator und Applikations-Entwickler haben getrennte API-Objekte.

API-Hierarchie

GatewayClass (Infrastruktur-Provider)
    └── Gateway (Cluster-Operator)
            └── HTTPRoute (Applikations-Entwickler)
            └── TCPRoute
            └── TLSRoute
            └── GRPCRoute

Installation (am Beispiel mit Nginx Gateway Fabric)

# CRDs installieren
kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.1.0/standard-install.yaml

# Nginx Gateway Fabric
helm repo add nginx-stable https://helm.nginx.com/stable
helm install nginx-gateway-fabric nginx-stable/nginx-gateway-fabric \
  -n nginx-gateway --create-namespace

GatewayClass und Gateway

# GatewayClass (einmalig pro Cluster)
apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: nginx
spec:
  controllerName: gateway.nginx.org/nginx-gateway-controller
---
# Gateway (pro Namespace oder Cluster)
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: prod-gateway
  namespace: nginx-gateway
spec:
  gatewayClassName: nginx
  listeners:
    - name: http
      port: 80
      protocol: HTTP
    - name: https
      port: 443
      protocol: HTTPS
      tls:
        certificateRefs:
          - kind: Secret
            name: wildcard-tls

HTTPRoute: Traffic-Management ohne Annotations

# Einfaches Routing
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: app-route
  namespace: production
spec:
  parentRefs:
    - name: prod-gateway
      namespace: nginx-gateway
  hostnames:
    - app.example.com
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /
      backendRefs:
        - name: app-service
          port: 80
          weight: 100

Traffic-Splitting mit Gateway API (standardisiert)

# Canary-Deployment: 80/20 Split
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: app-canary-route
  namespace: production
spec:
  parentRefs:
    - name: prod-gateway
      namespace: nginx-gateway
  hostnames:
    - app.example.com
  rules:
    - backendRefs:
        - name: app-stable
          port: 80
          weight: 80
        - name: app-canary
          port: 80
          weight: 20

Dieser Traffic-Split ist standardisiertes Kubernetes-API – portierbar zwischen Nginx Gateway Fabric, Cilium, Istio, Envoy Gateway und allen anderen GA-kompatiblen Implementierungen.

Direktvergleich: Nginx Ingress vs Gateway API

Kriterium	Nginx Ingress	Gateway API
Kubernetes-Version	Ab v1.1	GA ab v1.28
API-Standardisierung	Niedrig (Annotations)	Hoch (CRDs)
Portierbarkeit	Gering	Hoch
Canary/Traffic-Split	Annotations-basiert	Nativ
Rolle-Trennung	Nein	Ja (3 Rollen)
gRPC-Support	Annotations	Nativ (GRPCRoute)
TCP/UDP-Routing	Begrenzt	✅ TCPRoute
Reifegrad	Sehr hoch (10 Jahre)	Mittel (GA 2023)
Dokumentation	Exzellent	Gut, wächst
Implementierungen	1 (Nginx)	20+ (Cilium, Istio...)
Migration	-	Tools vorhanden

Migration von Ingress zu Gateway API

Für bestehende Ingress-Konfigurationen gibt es das Tool ingress2gateway:

# Konvertierung bestehender Ingress-Ressourcen
kubectl krew install ingress2gateway
kubectl ingress2gateway print --providers nginx \
  --input-file ingress.yaml

Das Tool konvertiert Ingress-Objekte automatisch in HTTPRoute-Objekte – die manuelle Überprüfung der Annotations ist dennoch empfohlen.

Wann welche Lösung?

Nginx Ingress Controller ist die bessere Wahl wenn:

Kubernetes-Versionen < 1.28 betrieben werden
Das Team keine Migration-Zeit hat
Exzellente Nginx-spezifische Features (Lua, ModSecurity WAF) benötigt werden
Die Komplexität gering gehalten werden soll

Gateway API ist besser wenn:

Neue Cluster aufgebaut werden
Multi-Tenant-Cluster mit Rolle-Trennung betrieben werden
Portierbarkeit zwischen Implementierungen wichtig ist
Service-Mesh-Integration geplant ist (Istio, Cilium unterstützen nativ)
gRPC oder TCP-Routing ohne Workarounds benötigt wird

Fazit: Gateway API für neue Cluster, Nginx für bestehende

Für neue Kubernetes-Cluster ist die Gateway API der empfohlene Weg – sie ist GA-stable, wird von allen großen Projekten unterstützt und löst die jahrelangen Portierbarkeits-Probleme von Ingress.

Für bestehende Cluster mit Nginx Ingress lohnt die Migration nur, wenn klare Vorteile wie Multi-Tenant-Isolation oder standardisierte Traffic-Splitting-Konfigurationen gebraucht werden. Eine parallele Betreibung während der Migration ist problemlos möglich.

Die Zukunft gehört der Gateway API – Nginx bietet mit dem Nginx Gateway Fabric eine offizielle Gateway-API-Implementierung, sodass auch Nginx-Nutzer schrittweise migrieren können.