With PerfectScale™ for Commitments, we're bringing rate optimization to every cloud
Cloud Intelligence™Cloud Intelligence™

Cloud Intelligence™

GKE Gateway API e Service Extensions: il toolkit per gestire il traffico più complesso in…

By Chimbu ChinnaduraiAug 12, 20258 min read

Questa pagina è disponibile anche in English, Deutsch, Español, Français, 日本語 e Português.

Kubernetes ha rivoluzionato l'orchestrazione dei container e Google Kubernetes Engine (GKE) mette a disposizione una piattaforma gestita e potente per distribuire e scalare applicazioni containerizzate. Pur offrendo solide funzionalità di service discovery e load balancing, GKE presenta ancora alcuni limiti quando si tratta di applicare logiche di elaborazione personalizzate al traffico prima che raggiunga i workloads.

È qui che entrano in gioco le Service Extensions: una soluzione efficace per personalizzare e potenziare il Cloud Load Balancing tramite la GKE Gateway API (Nota: si tratta di una funzionalità Kubernetes, non collegata al servizio Google Cloud API Gateway).

Cosa sono le Service Extensions in GCP?

Le Service Extensions permettono di iniettare logica personalizzata direttamente nel data path, abilitando modifiche avanzate al traffico che attraversa il load balancer. È come una pipeline in cui inserire il proprio codice in vari punti per manipolare richieste e risposte senza alcun impatto sui backend.

Esistono due tipi principali di Service Extensions:

  • Plugins: consentono di inserire codice personalizzato inline direttamente nel data path di rete. Realizzati con WebAssembly (Wasm) e l'ABI Proxy-Wasm, i plugin vengono eseguiti come moduli Wasm su un'infrastruttura sandbox gestita da Google. Sono pensati per operazioni a bassa latenza e si prestano a logiche leggere che devono essere eseguite molto vicino al data plane.

  • Callouts: consentono al Cloud Load Balancing di effettuare chiamate gRPC verso servizi esterni, sia gestiti da Google sia gestiti dall'utente (inclusi quelli in esecuzione su Pod GKE). I callout offrono maggiore flessibilità: possono riutilizzare software esistente e hanno meno restrizioni di runtime, risultando adatti a logiche più complesse che richiedono dati o stato esterni.

Il team GKE ha annunciato di recente il supporto in preview delle Service Extensions all'interno della Gateway API. Questo permette di manipolare header e payload HTTP di richieste e risposte e perfino di controllare il routing del traffico, il tutto senza incidere sulle selezioni esistenti dei servizi backend o sulle policy di sicurezza.

Tipi di Service Extensions per la GKE Gateway API

Il controller GKE Gateway supporta attualmente due tipi di Callouts Service Extensions, ciascuno pensato per finalità specifiche:

  • GCPRoutingExtension: estensione orientata al controllo del routing del traffico. Ideale negli scenari in cui occorre indirizzare il traffico verso diversi servizi backend o applicare logiche di routing personalizzate.

Come funziona GCPRoutingExtension con i Gateway

  • GCPTrafficExtension: estensione che consente di modificare header e payload di richieste e risposte. Opera senza alterare la selezione del servizio backend né le policy di sicurezza, risultando perfetta per la trasformazione e l'arricchimento dei dati.

Come funziona GCPTrafficExtension con i Gateway

Configurare le Service Extensions nella GKE Gateway API

Per esplorare la funzionalità Service Extensions in GKE servono un cluster GKE versione 1.33 o successiva e la Gateway API abilitata. Si consiglia inoltre di consultare le attuali Restrizioni e limitazioni delle Gateway Service Extensions in GKE prima di testare la funzionalità.

Deploy di un Gateway

Per configurare una Service Extension occorre prima effettuare il deploy di una risorsa Gateway o verificare che la risorsa Gateway esistente utilizzi una GatewayClass supportata. Per i dettagli sui load balancer supportati si rimanda a Google Cloud Service Extension compatibility with GatewayClasses.

  • Applicare il manifest seguente per effettuare il deploy di un semplice gateway con application load balancer regionale.
---
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

Deploy di un'applicazione store di backend di esempio

  • Applicare il manifest seguente per effettuare il deploy dell'applicazione di backend di esempio e delle risorse HTTPRoute. La HTTPRoute definisce il comportamento di routing delle richieste HTTP da un listener Gateway verso l'applicazione di backend.
---
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
  • Inviare una richiesta di esempio all'indirizzo IP della Gateway API per verificare la risposta del backend.
curl http://store.example.com --resolve store.example.com:80:GATEWAY_IP_ADDRESS -v

L'output sarà simile al seguente:

{
  "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"
}

Deploy di un servizio callout di backend

Un servizio callout implementa la logica personalizzata per le Gateway Service Extensions in GKE. Il Load Balancer richiama le applicazioni di backend in base alle configurazioni di GCPTrafficExtension o GCPRoutingExtension, per modificare o instradare il traffico.

Se si effettua il deploy del servizio callout nel cluster GKE, occorre soddisfare tutti i requisiti indicati nelle limitazioni.

  • Generare un certificato self-signed per il backend del servizio callout con mkcert o un altro metodo. È un passaggio necessario perché bisogna utilizzare HTTP2 come appProtocol, che richiede TLS end-to-end.
mkcert internal
  • Creare un Secret K8S con il certificato self-signed.
kubectl create secret tls extension-service-app-secret \
  --cert=internal.pem \
  --key=internal-key.pem
  • Applicare il manifest seguente per il deploy dell'applicazione callout di esempio. Per ulteriori esempi di codice si rimanda al repository GitHub 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
  • L'applicazione di esempio esegue una modifica base degli header sia in richiesta sia in risposta. Per i dettagli si rimanda a service_callout_example.py; è poi possibile sviluppare la propria applicazione in base ai requisiti di business.

Configurare le Service Extensions

Per personalizzare il flusso di traffico è possibile configurare un GCPRoutingExtension oppure un GCPTrafficExtension.

  • Applicare il manifest seguente per creare una risorsa GCPRoutingExtension: il load balancer richiamerà l'extension service app per le richieste inviate al path routeextension e le inoltrerà poi all'applicazione store di backend.
---
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
  • Aggiornare la risorsa HTTPRoute con l'host service-extensions.com, dato che il servizio callout modifica l'host header prima di inoltrare le richieste all'app store.
---
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
  • Il controller della Gateway API può richiedere alcuni minuti per sincronizzare le modifiche. Eseguire il comando kubectl describe gateway GATEWAY_NAME per verificare che il GCPRoutingExtension sia associato al Gateway.
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
...
  • L'output mostra le annotation utilizzate da GKE per memorizzare i collegamenti tra il Gateway e le risorse Google Cloud sottostanti. L'annotation networking.gke.io/lb-route-extensions conferma il binding del gateway al GCPRoutingExtension.
  • A questo punto è possibile testare il traffico verso il path routeextension sostituendo GATEWAY_IP_ADDRESS.
curl -v http://store.example.com/routeextension --resolve store.example.com:GATEWAY_IP_ADDRESS
  • L'output sarà simile al seguente: si possono notare le modifiche all'host_header nella risposta.
{
  "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"
}

GCPTrafficExtension consente di implementare logiche personalizzate su richieste e risposte, routing avanzato, trasformazioni e policy di sicurezza.

  • Applicare il manifest seguente per creare una risorsa GCPTrafficExtension: il load balancer richiamerà l'extension service app per le richieste inviate al path trafficetension. È possibile personalizzare e controllare la chiamata del load balancer all'applicazione callout aggiornando i supportedEvents.
---
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
  • A questo punto è possibile testare il traffico verso il path trafficextension sostituendo GATEWAT_IP_ADDRESS.
curl -v http://store.example.com/trafficeextension --resolve store.example.com:GATEWAY_IP_ADDRESS
  • L'output sarà simile al seguente: si notano le modifiche al response header personalizzato hello e la rimozione del corpo della risposta.
* 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
<

Esempio di log del Pod:

Le GCP Service Extensions per la GKE Gateway API rappresentano un significativo passo avanti nel modo in cui i team di piattaforma possono gestire, modellare e proteggere il traffico a livello di ingress. Che si tratti di applicare autenticazioni personalizzate, manipolare header, eseguire traffic shaping o integrarsi con sistemi esterni, le Service Extensions consentono di farlo in modo dichiarativo e scalabile.

Pur essendo ancora in preview, offrono un'ottima occasione per esplorare le Service Extensions, testarle in ambienti non di produzione e sviluppare extension service riutilizzabili e su misura per i requisiti della propria piattaforma.

Se sta valutando un PoC, non è il solo. DoiT è al Suo fianco per supportarLa nelle fasi di valutazione, pianificazione e migrazione, sempre con un forte focus sui Suoi obiettivi di business. Con oltre 100 senior cloud expert specializzati nella progettazione di soluzioni cloud su misura, il nostro team è pronto ad accompagnarLa lungo tutto il percorso e a ottimizzare la Sua infrastruttura per garantire compliance e rispondere in modo efficiente alle esigenze future.

I nostri esperti sono pronti a offrirLe guida strategica e competenza tecnica in ogni fase. Valutiamo insieme la soluzione più adatta alla Sua azienda in questa fase di policy enforcement, per assicurare un'infrastruttura cloud robusta, conforme e ottimizzata per il successo. Ci contatti oggi stesso.