Veröffentlicht am

Kubernetes Gateway API: HTTPRoute, GRPCRoute und Migration

Teilen:
Authors

Kubernetes Gateway API: Der Ingress-Nachfolger fuer Enterprise Traffic Management

TL;DR

  • Die Kubernetes Gateway API ersetzt das Ingress-Objekt durch ein rollenbasiertes Modell mit GatewayClass, Gateway und Route-Ressourcen.
  • HTTPRoute, GRPCRoute und TLSRoute bieten protokollspezifisches Routing ohne Annotations-Hacks.
  • Traffic Splitting, Header-basiertes Routing und Cross-Namespace-Referenzen sind nativ unterstuetzt.
  • Cilium, Envoy Gateway, NGINX Gateway Fabric und Istio implementieren den Standard produktionsreif.
  • Die Migration von Ingress ist schrittweise moeglich -- beide APIs laufen parallel.

Warum die Ingress API an ihre Grenzen stoesst

Das Ingress-Objekt existiert seit Kubernetes 1.1. Nach Jahren in der Praxis zeigen sich klare Schwaechen:

Annotations-Wildwuchs: Jeder Ingress Controller hat eigene Annotations. Was bei NGINX funktioniert, existiert bei Traefik nicht. Typische Ingress-Probleme beschreibt Kubernetes Ingress 502/503/504 Troubleshooting.

Keine Rollentrennung: Ingress mischt Infrastruktur-Konfiguration (TLS, Listener-Ports) mit Anwendungslogik (Routing-Regeln).

Eingeschraenkte Protokolle: Ingress unterstuetzt nur HTTP und HTTPS. TCP, UDP, gRPC erfordern Workarounds.

Das rollenbasierte Ressourcenmodell

Die Gateway API trennt Verantwortlichkeiten auf drei Ebenen:

RessourceVerantwortlichFunktion
GatewayClassInfrastruktur-AdminDefiniert den Controller-Typ
GatewayCluster-Admin / Platform TeamKonfiguriert Listener, Ports, TLS
HTTPRoute / GRPCRoute / TLSRouteEntwicklerDefiniert Routing-Regeln

GatewayClass: Die Infrastruktur-Ebene

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: envoy-gateway
spec:
  controllerName: gateway.envoyproxy.io/gatewayclass-controller

Die GatewayClass wird einmalig vom Infrastruktur-Admin erstellt. Entwickler referenzieren sie indirekt ueber das Gateway.

Gateway: Listener und TLS

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

Das Feld allowedRoutes kontrolliert, welche Namespaces Routes binden duerfen. Fuer Cross-Namespace-Zugriff auf TLS-Secrets braucht ihr einen ReferenceGrant:

apiVersion: gateway.networking.k8s.io/v1beta1
kind: ReferenceGrant
metadata:
  name: allow-gateway-cert-access
  namespace: cert-manager
spec:
  from:
    - group: gateway.networking.k8s.io
      kind: Gateway
      namespace: gateway-system
  to:
    - group: ""
      kind: Secret

HTTPRoute: Routing fuer Entwickler

Einfaches Routing

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: webapp-route
  namespace: webapp
spec:
  parentRefs:
    - name: production-gateway
      namespace: gateway-system
  hostnames:
    - "app.example.com"
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /
      backendRefs:
        - name: webapp-service
          port: 8080

Header-basiertes Routing

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api-versioned-route
  namespace: api
spec:
  parentRefs:
    - name: production-gateway
      namespace: gateway-system
  hostnames:
    - "api.example.com"
  rules:
    - matches:
        - headers:
            - name: X-API-Version
              value: "v2"
      backendRefs:
        - name: api-v2-service
          port: 8080
    - matches:
        - path:
            type: PathPrefix
            value: /api
      backendRefs:
        - name: api-v1-service
          port: 8080

Traffic Splitting fuer Canary Deployments

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: canary-route
  namespace: webapp
spec:
  parentRefs:
    - name: production-gateway
      namespace: gateway-system
  hostnames:
    - "app.example.com"
  rules:
    - backendRefs:
        - name: webapp-stable
          port: 8080
          weight: 90
        - name: webapp-canary
          port: 8080
          weight: 10

10% des Traffics gehen an die Canary-Version. Ueber weight laesst sich der Split stufenweise anpassen.

GRPCRoute: Natives gRPC-Routing

apiVersion: gateway.networking.k8s.io/v1
kind: GRPCRoute
metadata:
  name: grpc-route
  namespace: grpc-services
spec:
  parentRefs:
    - name: production-gateway
      namespace: gateway-system
  hostnames:
    - "grpc.example.com"
  rules:
    - matches:
        - method:
            service: myapp.UserService
            method: GetUser
      backendRefs:
        - name: user-service
          port: 50051
    - matches:
        - method:
            service: myapp.OrderService
      backendRefs:
        - name: order-service
          port: 50051

TLSRoute: TLS-Passthrough

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: TLSRoute
metadata:
  name: tls-passthrough-route
  namespace: secure-apps
spec:
  parentRefs:
    - name: production-gateway
      namespace: gateway-system
      sectionName: tls-passthrough
  hostnames:
    - "secure.example.com"
  rules:
    - backendRefs:
        - name: secure-backend
          port: 8443

Gateway API vs. Ingress: Vergleich

FeatureIngressGateway API
RollentrennungKeineDrei Ebenen
ProtokolleHTTP/HTTPSHTTP, HTTPS, gRPC, TLS, TCP, UDP
Traffic SplittingAnnotations (controller-spezifisch)Nativ via weight
Header-RoutingAnnotations (controller-spezifisch)Nativ via matches
Cross-NamespaceNicht moeglichNativ mit ReferenceGrant
PortabilitaetGering (Annotations-Lock-in)Hoch (standardisierte API)

Unterstuetzte Implementierungen

Envoy Gateway (Referenzimplementierung)

helm install envoy-gateway \
  oci://docker.io/envoyproxy/gateway-helm \
  --version v1.2.0 \
  -n envoy-gateway-system --create-namespace

Cilium Gateway API

helm upgrade cilium cilium/cilium \
  --namespace kube-system \
  --set gatewayAPI.enabled=true \
  --set kubeProxyReplacement=true

Cilium kombiniert CNI und Gateway API in einem Stack. Mehr zu Netzwerk-Policies: Kubernetes Network Policies.

NGINX Gateway Fabric

helm install ngf oci://ghcr.io/nginx/charts/nginx-gateway-fabric \
  --version 1.5.0 --create-namespace -n nginx-gateway

Istio

istioctl install --set profile=minimal \
  --set values.pilot.env.PILOT_ENABLE_GATEWAY_API=true

Fuer einen Service-Mesh-Vergleich: Istio vs. Linkerd.

Migration von Ingress zur Gateway API

Schritt 1: CRDs installieren

kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.2.0/standard-install.yaml
kubectl get crds | grep gateway.networking.k8s.io

Schritt 2: Gateway erstellen

kubectl apply -f - <<EOF
apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: production
spec:
  controllerName: gateway.envoyproxy.io/gatewayclass-controller
---
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: main-gateway
  namespace: gateway-system
spec:
  gatewayClassName: production
  listeners:
    - name: https
      protocol: HTTPS
      port: 443
      tls:
        mode: Terminate
        certificateRefs:
          - kind: Secret
            name: wildcard-cert
      allowedRoutes:
        namespaces:
          from: All
EOF

Schritt 3: Ingress-Objekte schrittweise durch HTTPRoutes ersetzen

Beide APIs laufen parallel. Ersetzt ein Ingress nach dem anderen und validiert per Monitoring, dass der Traffic korrekt fliesst. Monitoring-Strategien beschreibt Kubernetes Monitoring und Observability.

Schritt 4: DNS umschalten und altes Ingress loeschen

# Gateway-IP ermitteln
kubectl get gateway main-gateway -n gateway-system \
  -o jsonpath='{.status.addresses[0].value}'

# DNS-Eintrag auf neue IP umschalten, dann:
kubectl delete ingress webapp -n webapp

Troubleshooting

# Route-Status pruefen
kubectl get httproute webapp -n webapp -o jsonpath='{.status.parents[0].conditions}' | jq .

# Namespace-Label fehlt?
kubectl label namespace webapp gateway-access=true

# Gateway-Status
kubectl describe gateway main-gateway -n gateway-system

# Controller-Logs
kubectl logs -n envoy-gateway-system -l app.kubernetes.io/name=envoy-gateway

Fazit

Die Kubernetes Gateway API ist GA und loest reale Probleme, die mit Ingress nur ueber Workarounds loesbar waren. Jedes neue Projekt sollte direkt auf die Gateway API setzen. Fuer Helm-basierte Deployments laesst sich die Gateway API nahtlos integrieren: Helm Charts Einfuehrung.

Verwandte Artikel

Braucht ihr Unterstuetzung bei der Migration auf die Gateway API oder beim Aufbau einer Traffic-Management-Strategie? Kontaktiert uns fuer eine individuelle Beratung.

Diskutieren auf Twitter

Kubernetes-Beratung gesucht?

Wir helfen deutschen Unternehmen bei der Kubernetes-Implementierung, Migration und Optimierung. DSGVO-konform und praxiserprobt.

Termin buchenKontakt aufnehmen

📖 Verwandte Artikel

Weitere interessante Beiträge zu ähnlichen Themen

Alle Artikel durchsuchen