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

Cloud Intelligence™

GKE Gateway API et Service Extensions : la nouvelle boîte à outils pour relever les défis de trafic les plus complexes…

By Chimbu ChinnaduraiAug 12, 20258 min read

Cette page est également disponible en English, Deutsch, Español, Italiano, 日本語 et Português.

Kubernetes a transformé l'orchestration de conteneurs, et Google Kubernetes Engine (GKE) offre une plateforme managée puissante pour déployer et faire évoluer des applications conteneurisées. Si GKE propose des fonctionnalités robustes pour la découverte de services et la répartition de charge, certaines limites subsistent dès qu'il s'agit d'appliquer une logique de traitement personnalisée au trafic avant qu'il n'atteigne les workloads.

C'est précisément là qu'interviennent les Service Extensions, qui apportent une réponse convaincante pour personnaliser et enrichir le Cloud Load Balancing avec la GKE Gateway API (à noter : il s'agit d'une fonctionnalité Kubernetes, sans rapport avec le service Google Cloud API Gateway).

Que sont les Service Extensions dans GCP ?

Les Service Extensions permettent d'injecter une logique personnalisée directement dans le data path, autorisant des modifications avancées du trafic qui transite par le load balancer. C'est une sorte de pipeline dans lequel vous pouvez insérer votre propre code à différents stades pour manipuler les requêtes et les réponses sans impacter les backends.

Il existe deux principaux types de Service Extensions :

  • Plugins : ils permettent d'insérer du code personnalisé en inline directement dans le data path réseau. Conçus avec WebAssembly (Wasm) et l'ABI Proxy-Wasm, les plugins s'exécutent comme des modules Wasm sur une infrastructure sandbox managée par Google. Pensés pour des opérations à faible latence, ils conviennent parfaitement à une logique légère qui doit s'exécuter au plus près du data plane.

  • Callouts : ils permettent à Cloud Load Balancing d'effectuer des appels gRPC vers des services externes — qu'ils soient managés par Google ou par l'utilisateur (y compris ceux qui s'exécutent sur des Pods GKE). Les callouts offrent davantage de flexibilité : ils peuvent réutiliser des logiciels existants et imposent moins de contraintes d'exécution, ce qui les rend adaptés à une logique plus complexe nécessitant des données ou un état externes.

L'équipe GKE a récemment annoncé la prise en charge en preview des Service Extensions dans la Gateway API. Vous pouvez ainsi manipuler les en-têtes et les payloads HTTP des requêtes et des réponses, et même contrôler le routage du trafic, sans impacter les sélections de services backend ni les politiques de sécurité existantes.

Types de Service Extensions de la GKE Gateway API

Le contrôleur GKE Gateway prend actuellement en charge deux types de Service Extensions de type Callouts, chacun conçu pour des fonctions spécifiques :

  • GCPRoutingExtension : ce type d'extension est dédié au contrôle du routage du trafic. Idéal lorsque vous devez orienter le trafic vers différents services backend ou appliquer une logique de routage personnalisée.

Fonctionnement de GCPRoutingExtension avec les Gateways

  • GCPTrafficExtension : ce type d'extension permet de modifier les en-têtes et les payloads des requêtes et des réponses. Il fonctionne sans affecter la sélection des services backend ni les politiques de sécurité, ce qui le rend parfait pour la transformation et l'enrichissement de données.

Fonctionnement de GCPTrafficExtension avec les Gateways

Configurer les Service Extensions dans la GKE Gateway API

Pour explorer la fonctionnalité des Service Extensions dans GKE, il vous faut un cluster GKE en version 1.33 ou ultérieure avec la Gateway API activée. Pensez également à consulter les restrictions et limitations actuelles des Gateway Service Extensions dans GKE avant de tester cette fonctionnalité.

Déployer une Gateway

Pour configurer une Service Extension, vous devez d'abord déployer une ressource Gateway, ou vérifier que la ressource Gateway existante utilise une GatewayClass prise en charge. Pour connaître les load balancers compatibles, consultez la compatibilité des Google Cloud Service Extensions avec les GatewayClasses.

  • Appliquez le manifeste ci-dessous pour déployer une simple gateway de type application load balancer régional.
---
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

Déployer une application backend store d'exemple

  • Appliquez le manifeste ci-dessous pour déployer l'application backend d'exemple ainsi que les ressources HTTPRoute. La HTTPRoute définit le comportement de routage des requêtes HTTP depuis un listener Gateway vers l'application 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
  • Envoyez une requête d'exemple vers l'adresse IP de la gateway API pour tester la réponse du backend.
curl http://store.example.com --resolve store.example.com:80:GATEWAY_IP_ADDRESS -v

Le résultat ressemble à ceci :

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

Déployer un service backend de callout

Un service de callout porte la logique personnalisée des Gateway Service Extensions dans GKE. Le Load Balancer invoque les applications backend selon les configurations GCPTrafficExtension ou GCPRoutingExtension, afin de modifier ou de router le trafic.

Si vous déployez un service de callout dans le cluster GKE, vous devez respecter l'ensemble des prérequis indiqués dans les limitations.

  • Générez un certificat auto-signé pour le backend du service de callout via mkcert ou toute autre méthode. C'est nécessaire car vous devez utiliser HTTP2 comme appProtocol, ce qui impose un TLS de bout en bout.
mkcert internal
  • Créez un Secret K8S contenant le certificat auto-signé.
kubectl create secret tls extension-service-app-secret \
  --cert=internal.pem \
  --key=internal-key.pem
  • Appliquez le manifeste ci-dessous pour déployer l'application de callout d'exemple. Pour davantage d'exemples de code, consultez le dépôt 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'application d'exemple effectue une modification basique des en-têtes, à la fois sur la requête et sur la réponse. Reportez-vous à service_callout_example.py pour plus de détails ; vous pourrez ensuite développer votre propre application en fonction de vos besoins métier.

Configurer les Service Extensions

Vous pouvez configurer une GCPRoutingExtension ou une GCPTrafficExtension pour personnaliser le flux de votre trafic.

  • Appliquez le manifeste ci-dessous pour créer une ressource GCPRoutingExtension : le load balancer appellera l'application extension service pour les requêtes envoyées vers le chemin routeextension, puis les transmettra à l'application backend store.
---
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
  • Mettez à jour la ressource HTTPRoute avec l'hôte service-extensions.com, car le service de callout modifie l'en-tête host avant de transmettre les requêtes à l'application 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
  • Le contrôleur Gateway API peut prendre quelques minutes pour synchroniser les modifications. Utilisez la commande kubectl describe gateway GATEWAY_NAME pour vérifier que la GCPRoutingExtension est bien rattachée à la 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
...
  • La sortie affiche les annotations utilisées par GKE pour stocker les liens entre la Gateway et les ressources Google Cloud sous-jacentes. L'annotation networking.gke.io/lb-route-extensions confirme l'association entre la gateway et la GCPRoutingExtension.
  • Testez maintenant le trafic vers le chemin routeextension en remplaçant GATEWAY_IP_ADDRESS.
curl -v http://store.example.com/routeextension --resolve store.example.com:GATEWAY_IP_ADDRESS
  • La sortie ressemble à ceci ; vous pouvez constater les modifications apportées au host_header dans la réponse.
{
  "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"
}

Vous pouvez utiliser GCPTrafficExtension pour mettre en œuvre une logique personnalisée sur les requêtes et les réponses, du routage avancé, des transformations et des politiques de sécurité.

  • Appliquez le manifeste ci-dessous pour créer une ressource GCPTrafficExtension : le load balancer appellera l'application extension service pour les requêtes envoyées vers le chemin trafficetension. Vous pouvez personnaliser et contrôler l'invocation du load balancer vers l'application de callout en mettant à jour 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
  • Testez maintenant le trafic vers le chemin trafficextension en remplaçant GATEWAT_IP_ADDRESS.
curl -v http://store.example.com/trafficeextension --resolve store.example.com:GATEWAY_IP_ADDRESS
  • La sortie ressemble à ceci ; vous pouvez constater les modifications apportées à l'en-tête de réponse personnalisé hello, ainsi que la suppression du corps de la réponse.
* 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
<

Exemple de logs de Pod :

Les GCP Service Extensions pour la GKE Gateway API marquent une avancée majeure dans la façon dont les équipes plateforme gèrent, façonnent et sécurisent le trafic au niveau de la couche d'ingress. Que vous deviez appliquer une authentification personnalisée, manipuler des en-têtes, faire du traffic shaping ou vous intégrer à des systèmes externes, les Service Extensions vous permettent de le faire de manière déclarative et à grande échelle.

Bien qu'encore en preview, c'est une excellente occasion d'explorer les Service Extensions, de les tester dans des environnements hors production et de développer des services d'extension réutilisables, taillés pour les besoins de votre plateforme.

Si vous envisagez un PoC, vous n'êtes pas seul. DoiT est là pour vous aider à évaluer, planifier et migrer en gardant le cap sur vos résultats métier. Avec plus de 100 experts cloud seniors spécialisés dans la conception de solutions cloud sur mesure, notre équipe est prête à vous accompagner sereinement dans cette démarche et à optimiser votre infrastructure pour garantir la conformité et répondre efficacement aux exigences à venir.

Nos experts vous apportent un accompagnement stratégique et une expertise technique à chaque étape. Échangeons sur ce qui a le plus de sens pour votre entreprise durant cette phase d'application des politiques, afin de garantir une infrastructure cloud robuste, conforme et taillée pour la réussite. Contactez-nous dès aujourd'hui.