Gateway API: Der neue Kubernetes Ingress Standard

TL;DR

Die Kubernetes Gateway API ersetzt das klassische Ingress-Objekt durch ein rollenbasiertes Ressourcen-Modell mit GatewayClass, Gateway und HTTPRoute. Infrastruktur-Teams verwalten Gateways, Entwickler definieren Routing-Regeln per HTTPRoute -- ohne sich um Load Balancer oder TLS-Konfiguration zu kuemmern. Traffic Splitting, Header-basiertes Routing und Cross-Namespace-Referenzen sind nativ integriert.

Warum Ingress nicht mehr reicht

Das Ingress-Objekt existiert seit Kubernetes 1.1 und hat einen fundamentalen Design-Fehler: Es vermischt Infrastruktur- und Anwendungskonfiguration in einer einzigen Ressource. TLS-Zertifikate, Load-Balancer-Einstellungen und Routing-Regeln stehen alle im selben YAML. In der Praxis fuehrt das zu zwei Problemen:

1. Annotations-Wildwuchs: Jeder Ingress Controller definiert eigene Annotations. Was bei NGINX funktioniert, bricht bei Traefik oder HAProxy.
2. Fehlende Rollentrennung: Cluster-Admins und Entwickler bearbeiten dieselbe Ressource.

Die Gateway API loest beide Probleme durch ein geschichtetes Ressourcen-Modell, das seit Kubernetes 1.26 als Beta verfuegbar ist und ab 1.31 als GA gilt.

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

# Installierte CRDs pruefen
kubectl get crds | grep gateway
# gatewayclasses.gateway.networking.k8s.io
# gateways.gateway.networking.k8s.io
# httproutes.gateway.networking.k8s.io
# referencegrants.gateway.networking.k8s.io

Die drei Ressourcen-Schichten

GatewayClass: Infrastruktur-Provider definieren

Die GatewayClass beschreibt, welcher Controller das Gateway verwaltet. Sie wird typischerweise vom Cluster-Admin oder dem Gateway-Provider erstellt:

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: istio
spec:
  controllerName: istio.io/gateway-controller
  description: "Istio-basiertes Gateway fuer Production"

Die GatewayClass ist vergleichbar mit einer StorageClass -- sie definiert den Provider, nicht die konkrete Instanz. Gaengige Controller: Istio, Envoy Gateway, Cilium, Traefik, NGINX Gateway Fabric.

Gateway: Listener und Ports konfigurieren

Das Gateway erstellt den eigentlichen Load Balancer mit Listener-Konfiguration. Hier definieren Plattform-Teams Ports, Protokolle und TLS:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: production-gateway
  namespace: infra
spec:
  gatewayClassName: istio
  listeners:
    - name: https
      protocol: HTTPS
      port: 443
      tls:
        mode: Terminate
        certificateRefs:
          - name: wildcard-cert
            namespace: cert-manager
      allowedRoutes:
        namespaces:
          from: Selector
          selector:
            matchLabels:
              gateway-access: "true"
    - name: http-redirect
      protocol: HTTP
      port: 80

Der entscheidende Punkt: allowedRoutes steuert, welche Namespaces HTTPRoutes an dieses Gateway binden duerfen. Plattform-Teams behalten die Kontrolle, ohne jeden einzelnen Service konfigurieren zu muessen.

HTTPRoute: Anwendungs-Routing definieren

Die HTTPRoute ist die Ressource fuer Entwickler-Teams. Sie definiert Routing-Regeln und referenziert ein Gateway:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: shop-api
  namespace: shop
spec:
  parentRefs:
    - name: production-gateway
      namespace: infra
  hostnames:
    - "api.shop.example.de"
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /products
      backendRefs:
        - name: product-service
          port: 8080
    - matches:
        - path:
            type: PathPrefix
            value: /orders
      backendRefs:
        - name: order-service
          port: 8080

Entwickler brauchen keine Kenntnisse ueber den Load Balancer, TLS-Zertifikate oder den Ingress Controller. Sie definieren nur Pfade und Ziel-Services.

Traffic Splitting fuer Canary Deployments

Die Gateway API unterstuetzt gewichtetes Routing nativ -- ohne zusaetzliche Tools:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: shop-api-canary
  namespace: shop
spec:
  parentRefs:
    - name: production-gateway
      namespace: infra
  hostnames:
    - "api.shop.example.de"
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /products
      backendRefs:
        - name: product-service
          port: 8080
          weight: 90
        - name: product-service-canary
          port: 8080
          weight: 10

90% des Traffics geht an die stabile Version, 10% an den Canary. Die Gewichtung laesst sich schrittweise anpassen -- von 95/5 ueber 80/20 bis zur vollstaendigen Umstellung.

Mehr zu Deployment-Strategien: Kubernetes Blue-Green Deployment.

Header-basiertes Routing

Fuer A/B-Tests oder Feature-Flags kann Traffic anhand von HTTP-Headern geroutet werden:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: shop-api-feature
  namespace: shop
spec:
  parentRefs:
    - name: production-gateway
      namespace: infra
  hostnames:
    - "api.shop.example.de"
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /products
          headers:
            - name: X-Feature-Flag
              value: new-search
      backendRefs:
        - name: product-service-v2
          port: 8080
    - matches:
        - path:
            type: PathPrefix
            value: /products
      backendRefs:
        - name: product-service
          port: 8080

Requests mit dem Header X-Feature-Flag: new-search landen bei der neuen Version. Alle anderen Requests werden normal geroutet. Die Reihenfolge der Rules ist relevant -- spezifischere Matches muessen zuerst stehen.

Gateway API vs. Ingress im Vergleich

Migration: Von Ingress zu Gateway API

Eine schrittweise Migration ist moeglich. Beide Ressourcen koennen parallel existieren:

# Bestehendes Ingress anzeigen
kubectl get ingress -A

# Gateway API Status pruefen
kubectl get gateways -A
kubectl get httproutes -A

# HTTPRoute-Status detailliert anzeigen
kubectl describe httproute shop-api -n shop

Der empfohlene Migrationspfad:

1. Gateway API CRDs und Controller installieren
2. GatewayClass und Gateway erstellen
3. Neue Services direkt mit HTTPRoute deployen
4. Bestehende Ingress-Objekte schrittweise durch HTTPRoutes ersetzen
5. Alten Ingress Controller entfernen

Grundlagen zu Kubernetes-Networking: Kubernetes Network Policies.

FAQ

Ersetzt die Gateway API das Ingress-Objekt vollstaendig?

Langfristig ja. Das Ingress-Objekt wird nicht entfernt, aber die Gateway API ist der empfohlene Standard fuer neues Routing. Die meisten Ingress Controller unterstuetzen bereits beide APIs parallel.

Welche Gateway-Controller gibt es fuer Production?

Istio, Envoy Gateway, Cilium und Traefik sind die ausgereiftesten Implementierungen. NGINX Gateway Fabric ist ebenfalls GA. Die vollstaendige Liste der konformen Implementierungen pflegt die SIG Network auf der Gateway API Website.

Brauche ich ein Service Mesh fuer die Gateway API?

Nein. Die Gateway API funktioniert unabhaengig von einem Service Mesh. Istio kann als reiner Gateway Controller ohne Sidecar-Injection eingesetzt werden. Envoy Gateway ist eine schlanke Alternative ohne Mesh-Overhead.

Wie funktioniert TLS mit der Gateway API?

TLS wird am Gateway terminiert, nicht an der HTTPRoute. Das Gateway referenziert ein Kubernetes Secret oder ein Zertifikat von cert-manager. Entwickler-Teams muessen sich nicht um TLS kuemmern -- sie definieren nur die Routing-Regeln.

Ist die Gateway API production-ready?

Ja. HTTPRoute ist seit v1.0 (Oktober 2023) GA. GRPCRoute ist seit v1.1 GA. TLSRoute und TCPRoute befinden sich noch in der Beta-Phase.

Verwandte Artikel

• Kubernetes Network Policies
• Kubernetes Blue-Green Deployment
• Kubernetes Service Mesh Istio Guide
• Kubernetes CNI Vergleich Calico Cilium