GKE Gateway API & Service Extensions: Traffic anpassen

Kubernetes hat die Container-Orchestrierung grundlegend verändert, und Google Kubernetes Engine (GKE) bietet eine leistungsstarke Managed-Plattform, um containerisierte Anwendungen auszurollen und zu skalieren. GKE liefert zwar starke Funktionen für Service Discovery und Load Balancing, doch beim Anwenden eigener Verarbeitungslogik auf den Traffic, bevor dieser die workloads erreicht, stößt man weiterhin an Grenzen.

Genau hier kommen Service Extensions ins Spiel: Sie sind eine überzeugende Lösung, um Cloud Load Balancing in Verbindung mit der GKE Gateway API gezielt zu erweitern und anzupassen (Hinweis: Es handelt sich um ein Kubernetes-Feature, das nichts mit dem Google Cloud API Gateway-Service zu tun hat).

Was sind Service Extensions in GCP?

Mit Service Extensions lässt sich eigene Logik direkt in den Datenpfad einklinken und der Traffic, der durch den Load Balancer fließt, gezielt manipulieren. Stellen Sie sich das wie eine Pipeline vor, in die Sie an verschiedenen Stellen eigenen Code einsetzen, um Requests und Responses zu verändern – ohne die Backends zu beeinträchtigen.

Es gibt zwei Haupttypen von Service Extensions:

Plugins: Sie ermöglichen das Einfügen von Inline-Code direkt in den Netzwerk-Datenpfad. Plugins werden mit WebAssembly (Wasm) und der Proxy-Wasm ABI gebaut und laufen als Wasm-Module auf einer von Google verwalteten Sandbox-Infrastruktur. Ausgelegt sind sie auf Operationen mit niedriger Latenz – ideal für leichtgewichtige Logik, die sehr nah an der Data Plane ausgeführt werden soll.
Callouts: Damit kann Cloud Load Balancing gRPC-Aufrufe an externe Dienste absetzen – entweder an von Google verwaltete oder an selbst betriebene Dienste (einschließlich solcher, die auf GKE Pods laufen). Callouts bieten mehr Flexibilität, da sich bestehende Software wiederverwenden lässt und weniger Laufzeit-Restriktionen gelten. Sie eignen sich daher für komplexere Logik, die externe Daten oder Zustände benötigt.

Das GKE-Team hat kürzlich Preview-Support für Service Extensions in der Gateway API angekündigt. Damit lassen sich HTTP-Header und Payloads von Requests und Responses verändern und sogar das Traffic-Routing steuern – ohne bestehende Backend-Service-Auswahl oder Sicherheitsrichtlinien zu beeinflussen.

Typen von GKE Gateway API Service Extensions

Der GKE Gateway Controller unterstützt aktuell zwei Typen von Callouts Service Extensions, die jeweils auf bestimmte Aufgaben zugeschnitten sind:

GCPRoutingExtension: Dieser Typ konzentriert sich auf die Steuerung des Traffic-Routings. Ideal für Szenarien, in denen Sie Traffic auf unterschiedliche Backend-Services verteilen oder eigene Routing-Logik anwenden möchten.

So funktioniert GCPRoutingExtension mit Gateways

GCPTrafficExtension: Mit diesem Typ können Sie Header und Payloads von Requests und Responses verändern. Backend-Service-Auswahl und Sicherheitsrichtlinien bleiben dabei unberührt – perfekt für die Transformation und Anreicherung von Daten.

So funktioniert GCPTrafficExtension mit Gateways

Service Extensions in der GKE Gateway API konfigurieren

Um das Service-Extensions-Feature in GKE auszuprobieren, brauchen Sie einen GKE-Cluster ab Version 1.33 mit aktivierter Gateway API. Werfen Sie vor dem Test außerdem einen Blick auf die aktuellen Einschränkungen und Limitierungen der Gateway Service Extensions in GKE.

Ein Gateway bereitstellen

Bevor Sie eine Service Extension konfigurieren, müssen Sie zunächst eine Gateway-Ressource bereitstellen oder sicherstellen, dass die vorhandene Gateway-Ressource eine unterstützte GatewayClass nutzt. Details zu den unterstützten Load Balancern finden Sie unter Google Cloud Service Extension compatibility with GatewayClasses.

Wenden Sie das folgende Manifest an, um ein einfaches regionales Application Load Balancer Gateway bereitzustellen.

---
kind: Gateway
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: gke-l7-regional-external-managed
spec:
  gatewayClassName: gke-l7-regional-external-managed
  listeners:
  - name: http
    protocol: HTTP
    port: 80

Eine Beispiel-Backend-Anwendung (Store) bereitstellen

Wenden Sie das folgende Manifest an, um die Beispiel-Backend-Anwendung und die HTTPRoute-Ressourcen bereitzustellen. Die HTTPRoute legt fest, wie HTTP-Requests vom Gateway-Listener an die Backend-Anwendung geroutet werden.

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: store-v1
spec:
  replicas: 1
  selector:
    matchLabels:
      app: store
      version: v1
  template:
    metadata:
      labels:
        app: store
        version: v1
    spec:
      containers:
      - name: whereami
        image: us-docker.pkg.dev/google-samples/containers/gke/whereami:v1.2.20
        ports:
          - containerPort: 8080
        env:
        - name: METADATA
          value: "store-v1"
---
apiVersion: v1
kind: Service
metadata:
  name: store-v1
spec:
  selector:
    app: store
    version: v1
  ports:
  - port: 8080
    targetPort: 8080
------
kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: store
spec:
  parentRefs:
  - kind: Gateway
    name: gke-l7-regional-external-managed
  hostnames:
  - "store.example.com"
  rules:
  - backendRefs:
    - name: store-v1
      port: 8080

Schicken Sie einen Beispiel-Request an die IP-Adresse der Gateway API, um die Backend-Antwort zu prüfen.

curl http://store.example.com --resolve store.example.com:80:GATEWAY_IP_ADDRESS -v

Die Ausgabe sieht in etwa so aus:

{
  "cluster_name": "gateway-api-service-extensio-demo",
  "gce_instance_id": "2936941014208025864",
  "gce_service_account": "chimbuc-playground.svc.id.goog",
  "host_header": "store.example.com",
  "metadata": "store-v1",
  "pod_name": "store-v1-796c8ff75-mnssb",
  "pod_name_emoji": "🧑🏿‍⚖",
  "project_id": "chimbuc-playground",
  "timestamp": "2025-07-30T12:21:44",
  "zone": "us-central1-a"
}

Einen Backend-Callout-Service bereitstellen

Ein Callout-Service implementiert die individuelle Logik für die Gateway Service Extensions in GKE. Der Load Balancer ruft die Backend-Anwendungen anhand der Konfigurationen von GCPTrafficExtension oder GCPRoutingExtension auf, um Traffic zu verändern oder zu routen.

Wenn Sie einen Callout-Service im GKE-Cluster betreiben, müssen Sie alle in den Limitierungen genannten Voraussetzungen erfüllen.

Erstellen Sie ein selbstsigniertes Zertifikat für das Backend des Callout-Service – mit mkcert oder einem anderen Tool. Das ist nötig, weil als appProtocol HTTP2 verwendet werden muss, was wiederum Ende-zu-Ende-TLS voraussetzt.

mkcert internal

Legen Sie ein K8S Secret mit dem selbstsignierten Zertifikat an.

kubectl create secret tls extension-service-app-secret \
  --cert=internal.pem \
  --key=internal-key.pem

Wenden Sie das folgende Manifest an, um die Beispiel-Callout-Anwendung bereitzustellen. Weitere Codebeispiele finden Sie im GitHub-Repository service-extensions.

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: extension-service-app
spec:
  selector:
    matchLabels:
      app: store
  replicas: 1
  template:
    metadata:
      labels:
        app: store
    spec:
      containers:
      - name: serviceextensions
        image: us-docker.pkg.dev/service-extensions-samples/callouts/python-example-basic:main
        ports:
        - containerPort: 8080
        - containerPort: 443
        volumeMounts:
        - name: certs
          mountPath: "/etc/certs/"
          readOnly: true
        env:
        - name: POD_NAME
          valueFrom:
            fieldRef:
              fieldPath: metadata.name
        - name: NAMESPACE
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace
        - name: TLS_SERVER_CERT
          value: "/etc/certs/tls.crt"
        - name: TLS_SERVER_PRIVKEY
          value: "/etc/certs/tls.key"
        resources:
          requests:
            cpu: 10m
      volumes:
      - name: certs
        secret:
          secretName: "extension-service-app-secret"
          optional: false
---
apiVersion: v1
kind: Service
metadata:
  name: extension-service
spec:
  ports:
  - port: 443
    targetPort: 443
    appProtocol: HTTP2
  selector:
    app: store

Die Beispielanwendung führt eine einfache Header-Modifikation für Request und Response durch. Details dazu finden Sie in service_callout_example.py – darauf aufbauend können Sie eigene Anwendungen passend zu Ihren Anforderungen entwickeln.

Die Service Extensions konfigurieren

Zur Anpassung Ihres Traffic-Flusses können Sie wahlweise eine GCPRoutingExtension oder eine GCPTrafficExtension konfigurieren.

Wenden Sie das folgende Manifest an, um eine GCPRoutingExtension-Ressource zu erstellen. Der Load Balancer ruft daraufhin die Extension-Service-App für Requests an den Pfad routeextension auf und leitet sie anschließend an die Backend-Store-Anwendung weiter.

---
kind: GCPRoutingExtension
apiVersion: networking.gke.io/v1
metadata:
  name: my-gateway-extension
  namespace: default
spec:
  targetRefs:
  - group: "gateway.networking.k8s.io"
    kind: Gateway
    name: gke-l7-regional-external-managed
  extensionChains:
  - name: chain1
    matchCondition:
      celExpressions:
      - celMatcher: request.path.contains("routeextension")
    extensions:
    - name: routeextension
      authority: "store.example.com"
      timeout: 1s
      backendRef:
        group: ""
        kind: Service
        name: extension-service
        port: 443

Ergänzen Sie die HTTPRoute-Ressource um den Host service-extensions.com, da der Callout-Service den Host-Header anpasst, bevor die Requests an die Store-App weitergehen.

---
kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: store
spec:
  parentRefs:
  - kind: Gateway
    name: gke-l7-regional-external-managed
  hostnames:
  - "store.example.com"
  - "service-extensions.com"
  rules:
  - backendRefs:
    - name: store-v1
      port: 8080

Der Gateway-API-Controller braucht unter Umständen ein paar Minuten, um die Änderungen zu synchronisieren. Mit kubectl describe gateway GATEWAY_NAME prüfen Sie, ob die GCPRoutingExtension an das Gateway gebunden ist.

Name:         gke-l7-regional-external-managed
Namespace:    default
Labels:       <none>
Annotations:  networking.gke.io/addresses:
                /projects/269684357132/regions/us-central1/addresses/gkegw1-jorz-default-gke-l7-regional-external-manag-8wyhl317c00c
              networking.gke.io/backend-services:
                /projects/269684357132/regions/us-central1/backendServices/gkegw1-jorz-default-extension-service-443-e1aovl10z449, /projects/269684357132/...
              networking.gke.io/firewalls: /projects/269684357132/global/firewalls/gkegw1-jorz-l7-default-us-central1
              networking.gke.io/forwarding-rules:
                /projects/269684357132/regions/us-central1/forwardingRules/gkegw1-jorz-default-gke-l7-regional-external-manag-5s86aj5tzcoj
              networking.gke.io/health-checks:
                /projects/269684357132/regions/us-central1/healthChecks/gkegw1-jorz-default-extension-service-443-e1aovl10z449, /projects/269684357132/reg...
              networking.gke.io/last-reconcile-time: 2025-07-30T12:46:15Z
              networking.gke.io/lb-route-extensions:
                projects/269684357132/locations/us-central1/lbRouteExtensions/gkegw1-jorz-default-gke-l7-regional-external-manag-xivagz6clt0t
              networking.gke.io/lb-traffic-extensions:
                projects/269684357132/locations/us-central1/lbTrafficExtensions/gkegw1-jorz-default-gke-l7-regional-external-manag-lu8d7n5p4kbs
              networking.gke.io/ssl-certificates:
              networking.gke.io/target-http-proxies:
                /projects/269684357132/regions/us-central1/targetHttpProxies/gkegw1-jorz-default-gke-l7-regional-external-manag-kaecv0bs2nyx
              networking.gke.io/target-https-proxies:
              networking.gke.io/url-maps:
                /projects/269684357132/regions/us-central1/urlMaps/gkegw1-jorz-default-gke-l7-regional-external-manag-kaecv0bs2nyx
API Version:  gateway.networking.k8s.io/v1
Kind:         Gateway
Metadata:
  Creation Timestamp:  2025-07-30T07:45:42Z
  Finalizers:
    gateway.finalizer.networking.gke.io
  Generation:        1
  Resource Version:  1753879575407087021
...

Die Ausgabe zeigt die Annotations, über die GKE die Verknüpfungen zwischen dem Gateway und den zugrunde liegenden Google-Cloud-Ressourcen speichert. Die Annotation networking.gke.io/lb-route-extensions bestätigt, dass das Gateway an die GCPRoutingExtension gebunden ist.
Testen Sie nun den Traffic auf dem Pfad routeextension, indem Sie GATEWAY_IP_ADDRESS ersetzen.

curl -v http://store.example.com/routeextension --resolve store.example.com:GATEWAY_IP_ADDRESS

Die Ausgabe sieht in etwa so aus – beachten Sie die Änderungen am host_header in der Response.

{
  "cluster_name": "gateway-api-service-extensio-demo",
  "gce_instance_id": "2936941014208025864",
  "gce_service_account": "chimbuc-playground.svc.id.goog",
  "host_header": "service-extensions.com",
  "metadata": "store-v1",
  "pod_name": "store-v1-796c8ff75-mnssb",
  "pod_name_emoji": "🧑🏿‍⚖",
  "project_id": "chimbuc-playground",
  "timestamp": "2025-07-30T12:51:06",
  "zone": "us-central1-a"
}

Mit GCPTrafficExtension setzen Sie individuelle Request- und Response-Logik, anspruchsvolles Routing, Transformationen sowie Sicherheitsrichtlinien um.

Wenden Sie das folgende Manifest an, um eine GCPTrafficExtension-Ressource zu erstellen. Der Load Balancer ruft daraufhin die Extension-Service-App für Requests an den Pfad trafficetension auf. Über das Feld supportedEvents steuern Sie, in welchen Fällen der Load Balancer die Callout-Anwendung aufruft.

---
kind: GCPTrafficExtension
apiVersion: networking.gke.io/v1
metadata:
  name: my-traffic-extension
  namespace: default
spec:
  targetRefs:
  - group: "gateway.networking.k8s.io"
    kind: Gateway
    name: gke-l7-regional-external-managed
  extensionChains:
  - name: chain1
    matchCondition:
      celExpressions:
      - celMatcher: request.path.contains("trafficeextension")
    extensions:
    - name: trafficeextension
      authority: "store.example.com"
      timeout: 1s
      supportedEvents: ["RequestHeaders", "RequestBody", "ResponseHeaders", "ResponseBody", "RequestTrailers", "ResponseTrailers"]
      backendRef:
        group: ""
        kind: Service
        name: extension-service
        port: 443

Testen Sie jetzt den Traffic auf dem Pfad trafficextension, indem Sie GATEWAT_IP_ADDRESS ersetzen.

curl -v http://store.example.com/trafficeextension --resolve store.example.com:GATEWAY_IP_ADDRESS

Die Ausgabe sieht in etwa so aus. Sie erkennen die Änderungen am benutzerdefinierten Response-Header hello; der Response-Body wurde entfernt.

* Request completely sent off
< HTTP/1.1 200 OK
< server: Werkzeug/2.3.7 Python/3.11.3
< date: Wed, 30 Jul 2025 12:58:00 GMT
< content-type: application/json
< access-control-allow-origin: *
< hello: service-extensions
< via: 1.1 google
< transfer-encoding: chunked
<

Beispielhafte Pod-Logs: