Déployer des ressources Gateway

Autopilot Standard

---

Cette page explique comment déployer des ressources Gateway Kubernetes pour équilibrer la charge du trafic entrant sur un seul cluster Google Kubernetes Engine (GKE).

Pour déployer des ressources Gateway afin d'équilibrer la charge du trafic entrant sur plusieurs clusters (ou sur un parc), consultez la page Déployer des passerelles multiclusters.

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

• Activez l'API Google Kubernetes Engine.
Activer l'API Google Kubernetes Engine
• Si vous souhaitez utiliser Google Cloud CLI pour cette tâche, installez puis initialisez gcloud CLI. Si vous avez déjà installé gcloud CLI, assurez-vous de disposer de la dernière version en exécutant la commande gcloud components update.
  Remarque : Pour les installations de gcloud CLI existantes, veillez à définir les propriétés compute/region et compute/zone. En définissant des emplacements par défaut, vous pouvez éviter les erreurs gcloud CLI telles que celle-ci : One of [--zone, --region] must be supplied: Please specify location.

Conditions requises pour le contrôleur GKE Gateway

• Pour l'environnement standard, GKE version 1.24 ou ultérieure.

• Pour Autopilot, la version 1.26 de GKE ou une version ultérieure.
• Google Cloud CLI version 407.0.0 ou ultérieure.
• L'API Gateway n'est compatible qu'avec les clusters de VPC natif.
• Si vous utilisez les GatewayClasses internes, vous devez activer un sous-réseau proxy réservé.
• Le module complémentaire HttpLoadBalancing doit être activé sur votre cluster.
• Si vous utilisez Istio, vous devez mettre à niveau Istio vers l'une des versions suivantes :
  • 1.15.2 ou ultérieure
  • 1.14.5 ou ultérieure
  • 1.13.9 ou ultérieure
• Si vous utilisez un VPC partagé, vous devez attribuer le rôle Compute Network User au compte de service GKE du projet de service dans le projet hôte.

Restrictions et limitations

• GKE GatewayClasses offre différentes fonctionnalités en fonction de l'équilibreur de charge qu'elles utilisent. Pour en savoir plus sur les différentes fonctionnalités compatibles avec chaque objet GatewayClass, consultez la page Fonctionnalités GatewayClass.

• Vous ne pouvez pas utiliser FrontendConfig ni BackendConfig pour configurer une ressource Gateway. Vous devez utiliser une règle.

• GKE Gateway se comporte différemment de la ressource Ingress, en ce sens qu'il ne déduit pas les paramètres de vérification d'état. Si votre service ne renvoie pas 200 pour les requêtes adressées à GET / ou si vous avez d'autres vérifications d'aptitude des pods réglées, vous devez configurer une règle HealthCheckPolicy pour votre service.

• Vous pouvez afficher les ressources de l'équilibreur de charge que GKE crée pour les ressources Gateway dans la console Google Cloud, mais ces ressources ne font pas référence à la ressource Gateway ni au cluster GKE auquel elles sont associées.

• Vous ne pouvez pas voir les ressources Gateway, HTTPRoute et Policy dans la console Google Cloud. Vous pouvez découvrir et gérer les ressources Gateway à l'aide de l'API Kubernetes.

• Vous ne pouvez pas générer automatiquement un certificat SSL géré par Google avec Gateways, mais vous pouvez créer et référencer manuellement un certificat SSL géré par Google. Pour en savoir plus, consultez la page Sécuriser une passerelle.

• HTTPRoute est le seul type de route accepté. TCPRoutes, UDPRoutes et TLSRoutes ne sont pas compatibles. Pour afficher la liste des champs compatibles avec GKE Gateway Controller, consultez la page Fonctionnalités GatewayClass.

• Les en-têtes de requêtes et de réponses personnalisés avec Gateway ou des redirections de chemins d'accès et des réécritures d'URL avec Gateway ne sont disponibles que sur GKE 1.27 ou une version ultérieure.

• Pour les en-têtes de requêtes et de réponses personnalisés avec Gateway, et des redirections de chemins d'accès et des réécritures d'URL avec Gateway, l'objet gke-l7-gxlb GatewayClass n'est pas accepté.

• Les variables d'en-tête Google Cloud suivantes ne sont pas acceptées :

  • cdn_cache_id (Cloud CDN n'est pas compatible avec GKE Gateway)
  • cdn_cache_status (Cloud CDN n'est pas compatible avec GKE Gateway)
  • origin_request_header (CORS n'est pas compatible avec GKE Gateway)

• GKE Gateway n'est pas compatible avec la fonctionnalité d'équilibrage de charge Cloud CDN.

• Les en-têtes TLS mutuels personnalisés ne sont pas compatibles (mTLS avec GKE Gateway n'est pas compatible).

• Les limites de l'équilibreur de charge d'application classique de Google Cloud s'appliquent à GKE Gateway avec une limite supplémentaire :

  • Vous ne pouvez pas configurer d'en-tête de réponse d'hôte personnalisé dans le service de backend.

• Les redirections de chemin d'accès et les réécritures d'URL s'excluent mutuellement. Vous ne pouvez pas utiliser les deux filtres en même temps dans les mêmes règles.

• La redirection du trafic vers un autre port n'est pas compatible avec Cloud Load Balancing. Pour afficher la liste des champs compatibles avec GKE Gateway Controller, consultez la page Fonctionnalités GatewayClass.

• GKE Gateway n'est pas compatible avec les caractères génériques, les expressions régulières et les URL dynamiques.

• Si vous spécifiez une ressource Gateway avec une classe de passerelle externe régionale, le contrôleur provisionne une adresse IP interne au lieu de l'adresse externe. Pour apprendre à utiliser une adresse nommée avec l'équilibreur de charge d'application externe régional, consultez la section Déployer une ressource Gateway externe régionale.

• Gateway utilise des NEG autonomes pour le provisionnement des groupes de points de terminaison du réseau. Pour vous assurer que le contrôleur Gateway rapproche correctement la configuration de l'équilibreur de charge, vous ne pouvez pas modifier l'annotation cloud.google.com/neg d'un service faisant partie de la passerelle.

• GKE Gateway ne permet pas de référencer un service qui est également référencé par une ressource GKE Ingress.

• Lorsqu'une ressource Gateway est configurée pour provisionner une adresse IP, il n'est pas possible de modifier Gateway.spec.gatewayClass. Pour vous assurer que le contrôleur Gateway rapproche correctement l'équilibreur de charge, supprimez la ressource Gateway existante et redéployez le fichier manifeste avec la valeur gatewayClass mise à jour.

• L'annotation networking.gke.io/app-protocols n'est pas acceptée. Utilisez plutôt le champ appProtocol pour obtenir le même résultat.

Activer l'API Gateway dans votre cluster

Avant d'utiliser les ressources Gateway dans GKE, l'API Gateway doit être activée sur votre cluster.

Créer un cluster avec l'API Gateway activée

GKE est compatible avec l'API Gateway sur les clusters Autopilot à partir de la version 1.26 de GKE. Si vous créez des clusters Autopilot sur GKE 1.26 et versions ultérieures, l'API Gateway est activée par défaut. Pour les clusters existants sur GKE 1.25 et versions antérieures, l'API Gateway est désactivée par défaut.

Autopilot

Créez un cluster GKE Autopilot avec l'API Gateway activée :

  gcloud container clusters create-auto CLUSTER_NAME \
      --location=CLUSTER_LOCATION \
      --release-channel=RELEASE_CHANNEL \
      --cluster-version=VERSION

Remplacez les éléments suivants :

• CLUSTER_NAME : nom du cluster.
• CLUSTER_LOCATION : région ou zone Compute Engine du nouveau cluster.
• RELEASE_CHANNEL : nom de la version disponible.
• VERSION : version de GKE, qui doit être 1.26 ou ultérieure. Vous pouvez également utiliser l'option --release-channel pour sélectionner un canal de publication. La version disponible doit disposer de la version par défaut 1.26 ou ultérieure.

Remarque : Vous n'avez pas besoin d'utiliser gcloud flag --gateway-api=standard lors de la création du cluster.

Standard

Avec GKE Standard, l'API Gateway est contrôlée par l'option --gateway-api. Vous pouvez utiliser la valeur standard lors de l'activation et de la désactivation lors de sa désactivation.

Créez un cluster GKE VPC natif avec l'API Gateway activée :

  gcloud container clusters create CLUSTER_NAME \
    --gateway-api=standard \
    --cluster-version=VERSION \
    --location=CLUSTER_LOCATION

Remplacez les éléments suivants :

• RELEASE_CHANNEL : nom de la version disponible.
• CLUSTER_NAME : nom du cluster.
• VERSION : version de GKE, qui doit être 1.24 ou ultérieure. Vous pouvez également utiliser l'option --release-channel pour sélectionner un canal de publication. La version disponible doit disposer de la version par défaut 1.24 ou ultérieure.
• CLUSTER_LOCATION : région ou zone Compute Engine du nouveau cluster.

L'option --gateway-api=standard demande à GKE d'installer les objets CRD v1beta1 avec le cluster.

Activer l'API Gateway sur un cluster existant

Remarque : Lorsque vous activez Gateway sur un cluster existant, un délai de 45 minutes peut être nécessaire pour que le cluster effectue le rapprochement et l'installation des CRD.

Assurez-vous que la version de votre cluster Autopilot est 1.26 ou ultérieure et que votre version de cluster standard est la version 1.24 ou ultérieure.

Pour activer l'API Gateway sur un cluster GKE existant (Autopilot ou Standard), utilisez la commande suivante :

gcloud container clusters update CLUSTER_NAME \
    --location=CLUSTER_LOCATION\
    --gateway-api=standard

Remplacez les éléments suivants :

• CLUSTER_NAME : nom du cluster existant.

• CLUSTER_LOCATION : région ou zone Compute Engine du cluster.

L'option --gateway-api=standard demande à GKE d'installer les objets CRD v1beta1 avec le cluster.

Remarque : Si vous mettez à jour un cluster GKE standard existant pour activer l'API Gateway, assurez-vous que les conditions minimales requises sont remplies avant de poursuivre la mise à jour. Pour en savoir plus sur la mise à niveau de la version Standard d'un cluster, consultez la page Mises à niveau de cluster Standard. Pour en savoir plus sur la mise à niveau de votre version de cluster Autopilot, consultez la page Mises à niveau des clusters Autopilot.

Vérifier le cluster

Après la création ou la mise à niveau du cluster, GKE Gateway Controller installe automatiquement GatewayClasses. La reconnaissance des CRD et l'installation des ressources GatewayClasses par le contrôleur peut prendre quelques minutes.

1. Vérifiez que l'API Gateway est activée dans le plan de contrôle GKE :

   gcloud container clusters describe CLUSTER_NAME \
     --location=CLUSTER_LOCATION \
     --format json
   

   Le résultat renvoyé ressemble à ceci : Si ce résultat est vide, exécutez à nouveau la commande de mise à jour de cluster.

   "networkConfig": {
     ...
     "gatewayApiConfig": {
       "channel": "CHANNEL_STANDARD"
     },
     ...
   },
   

2. Vérifiez que les GatewayClasses sont installées dans votre cluster :

   kubectl get gatewayclass
   

   Le résultat ressemble à ce qui suit :

   NAME                             CONTROLLER                  ACCEPTED   AGE
   gke-l7-global-external-managed   networking.gke.io/gateway   True       16h
   gke-l7-regional-external-managed networking.gke.io/gateway   True       16h
   gke-l7-gxlb                      networking.gke.io/gateway   True       16h
   gke-l7-rilb                      networking.gke.io/gateway   True       16h
   

Pour comprendre les fonctionnalités de chaque ressource GatewayClass de GKE, consultez la page Fonctionnalités de la ressource GatewayClass.

Remarque : Seules les ressources GatewayClass à un seul cluster sont installées automatiquement. Pour installer et utiliser les ressources GatewayClass multiclusters pour l'équilibrage de charge multicluster interne et externe, consultez la page Activer les passerelles multiclusters.

Déployer une passerelle interne

Une passerelle interne expose des applications qui ne sont accessibles qu'à partir du VPC ou des réseaux connectés au VPC.

Déployer une ressource Gateway interne régionale

L'exemple suivant vous montre comment déployer une ressource Gateway interne régionale permettant une communication efficace et sécurisée entre des services au sein d'une région géographique spécifique.

Configurer un sous-réseau proxy réservé

Vous devez configurer un sous-réseau proxy réservé avant de créer une passerelle utilisant un équilibreur de charge d'application interne. Chaque région d'un VPC dans lequel vous utilisez des équilibreurs de charge d'application internes doit comporter un sous-réseau proxy réservé. Ce sous-réseau permet de fournir des adresses IP internes aux proxys des équilibreurs de charge.

1. Créer un sous-réseau proxy réservé :

   gcloud compute networks subnets create SUBNET_NAME \
       --purpose=REGIONAL_MANAGED_PROXY \
       --role=ACTIVE \
       --region=COMPUTE_REGION \
       --network=VPC_NETWORK_NAME \
       --range=CIDR_RANGE
   

   Remplacez les éléments suivants :

   • SUBNET_NAME : nom du sous-réseau proxy réservé.
   • COMPUTE_REGION : région du sous-réseau proxy réservé.
   • VPC_NETWORK_NAME : nom du réseau VPC contenant le sous-réseau.
   • CIDR_RANGE : plage d'adresses IP principale du sous-réseau. Vous devez utiliser un masque de sous-réseau ne dépassant pas /26 afin qu'au moins 64 adresses IP soient disponibles pour les proxys de la région. Le masque de sous-réseau recommandé est /23.

2. Vérifiez votre sous-réseau proxy réservé :

   gcloud compute networks subnets describe SUBNET_NAME \
       --region=COMPUTE_REGION
   

   Le résultat ressemble à ce qui suit :

   ...
   gatewayAddress: 10.1.1.1
   ipCidrRange: 10.1.1.0/24
   kind: compute#subnetwork
   name: proxy-subnet
   network: https://www.googleapis.com/compute/v1/projects/PROJECT_NAME/global/networks/default
   privateIpGoogleAccess: false
   privateIpv6GoogleAccess: DISABLE_GOOGLE_ACCESS
   purpose: REGIONAL_MANAGED_PROXY
   region: https://www.googleapis.com/compute/v1/projects/PROJECT_NAME/regions/REGION
   role: ACTIVE
   selfLink: https://www.googleapis.com/compute/v1/projects/PROJECT_NAME/regions/REGION/subnetworks/proxy-subnet
   state: READY
   

Créer une ressource Gateway

Une ressource Gateway représente un plan de données qui achemine le trafic dans Kubernetes. Une ressource Gateway peut représenter de nombreux types d'équilibrage de charge et de routage différents en fonction de la ressource GatewayClass dont elle est dérivée. Pour en savoir plus sur la ressource Gateway, consultez la description de la ressource Gateway ou la spécification de l'API.

Dans ce cas, l'administrateur du cluster GKE souhaite créer une ressource Gateway que les différentes équipes peuvent utiliser pour exposer leurs applications en interne. L'administrateur déploie la ressource Gateway et les équipes applications déploient leurs routes indépendamment et les associent à cette ressource Gateway.

1. Enregistrez le fichier de manifeste de passerelle suivant dans un fichier nommé gateway.yaml :

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

   Ce fichier manifeste comprend les champs suivants :

   • gatewayClassName: gke-l7-rilb : spécifie la ressource GatewayClass à partir de laquelle cette ressource Gateway est dérivée. gke-l7-rilb correspond à l'équilibreur de charge d'application interne.
   • port: 80 : indique que la ressource Gateway n'expose que le port 80 pour l'écoute du trafic HTTP.

2. Déployez la ressource Gateway dans votre cluster :

   kubectl apply -f gateway.yaml
   

3. Confirmez que la ressource Gateway a été correctement déployée. Le déploiement de toutes ses ressources peut prendre quelques minutes.

   kubectl describe gateways.gateway.networking.k8s.io internal-http
   

   Le résultat ressemble à ce qui suit :

   Name:         internal-http
   Namespace:    default
   Spec:
     Gateway Class Name:  gke-l7-rilb
     Listeners:
       Allowed Routes:
         Kinds:
           Group:  gateway.networking.k8s.io
           Kind:   HTTPRoute
         Namespaces:
           From:  Same
       Name:      http
       Port:      80
       Protocol:  HTTP
   Status:
     Addresses:
       Type:   IPAddress
       Value:  192.168.1.14
     Conditions:
       Last Transition Time:  1970-01-01T00:00:00Z
       Message:               Waiting for controller
       Reason:                NotReconciled
       Status:                False
       Type:                  Scheduled
   Events:
     Type    Reason  Age                From                       Message
     ----    ------  ----               ----                       -------
     Normal  ADD     92s                networking.gke.io/gateway  test/internal-http
     Normal  UPDATE  45s (x3 over 91s)  networking.gke.io/gateway  test/internal-http
     Normal  SYNC    45s                networking.gke.io/gateway  SYNC on test/internal-http was a success
   

   À ce stade, votre cluster comporte une ressource Gateway qui a provisionné un équilibreur de charge et une adresse IP. Cependant, la ressource Gateway ne dispose d'aucune route. Elle ne sait donc pas comment envoyer du trafic aux backends. Sans route, tout le trafic est dirigé vers un backend par défaut, qui renvoie une erreur HTTP 404. Vous allez ensuite déployer une application et des routes qui indiquent à la ressource Gateway comment accéder aux backends d'application.

Déployer les applications de démonstration

Les équipes applications peuvent déployer leurs applications et routes indépendamment du déploiement des ressources Gateway. Dans certains cas, l'équipe applications peut également vouloir posséder la ressource Gateway et la déployer elle-même en tant que ressource dédiée à ses applications. Consultez la section Liaison de route pour différents modèles de propriété de ressources Gateway et de routes. Cependant, dans cet exemple, l'équipe du magasin déploie son application et une ressource HTTPRoute associée pour exposer son application via la ressource Gateway internal-http créée à la section précédente.

La ressource HTTPRoute comporte de nombreux champs configurables pour la mise en correspondance du trafic. Pour obtenir une explication des champs de la ressource HTTPRoute, consultez la spécification de l'API.

1. Déployez l'application magasin (déploiements "store-v1", "store-v2" et "store-german") sur votre cluster :

   kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/main/gateway/gke-gateway-controller/app/store.yaml
   

   Cela crée trois déploiements et trois services nommés "store-v1", "store-v2" et "store-german".

2. Vérifiez que l'application a bien été déployée :

   kubectl get pod
   

   Le résultat ressemble à ce qui suit après l'exécution de l'application :

   NAME                        READY   STATUS    RESTARTS   AGE
   store-german-66dcb75977-5gr2n   1/1     Running   0          38s
   store-v1-65b47557df-jkjbm       1/1     Running   0          14m
   store-v2-6856f59f7f-sq889       1/1     Running   0          14m
   

3. Confirmez que les services ont également été déployés :

   kubectl get service
   

   Le résultat affiche un service pour chaque déploiement du magasin :

   NAME           TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)    AGE
   store-german   ClusterIP   10.48.3.183   <none>        8080/TCP   4s
   store-v1       ClusterIP   10.48.2.224   <none>        8080/TCP   5s
   store-v2       ClusterIP   10.48.4.48    <none>        8080/TCP   5s
   

Déployer HTTPRoute

Les ressources de routage définissent des règles spécifiques au protocole pour mapper le trafic d'une ressource Gateway vers les backends Kubernetes. La ressource HTTPRoute effectue une correspondance et un filtrage du trafic HTTP et HTTPS, et est compatible avec toutes les ressources GatewayClass gke-l7.

Dans cette section, vous déployez une ressource HTTPRoute, qui programme la ressource Gateway avec les règles de routage nécessaires pour atteindre votre application de magasin.

1. Enregistrez le fichier manifeste HTTPRoute suivant dans un fichier nommé store-route.yaml :

   kind: HTTPRoute
   apiVersion: gateway.networking.k8s.io/v1beta1
   metadata:
     name: store
   spec:
     parentRefs:
     - kind: Gateway
       name: internal-http
     hostnames:
     - "store.example.com"
     rules:
     - backendRefs:
       - name: store-v1
         port: 8080
     - matches:
       - headers:
         - name: env
           value: canary
       backendRefs:
       - name: store-v2
         port: 8080
     - matches:
       - path:
           value: /de
       backendRefs:
       - name: store-german
         port: 8080
   

2. Déployez la ressource HTTPRoute dans votre cluster :

   kubectl apply -f store-route.yaml
   

   La ressource HTTPRoute store est liée à la ressource Gateway internal-http à l'aide de la propriété parentRefs : Ces règles de routage sont configurées sur l'équilibreur de charge sous-jacent comme dans ce schéma :

   

   Ces règles de routage traitent le trafic HTTP de la manière suivante :

   • Le trafic vers store.example.com/de est acheminé vers le service store-german.
   • Le trafic vers store.example.com avec l'en-tête HTTP "env: canary" est envoyé au service store-v2.
   • Le trafic restant vers store.example.com est acheminé vers le service store-v1.

3. Vérifiez que le fichier HTTPRoute a été déployé :

   kubectl describe httproute store
   

   Le résultat ressemble à ce qui suit :

   Name:         store
   Namespace:    default
   Labels:       <none>
   Annotations:  <none>
   API Version:  gateway.networking.k8s.io/v1beta1
   Kind:         HTTPRoute
   <...>
   Spec:
     Hostnames:
       store.example.com
     Parent Refs:
       Group:  gateway.networking.k8s.io
       Kind:   Gateway
       Name:   internal-http
     Rules:
       Backend Refs:
         Group:
         Kind:    Service
         Name:    store-v1
         Port:    8080
         Weight:  1
       Matches:
         Path:
           Type:   PathPrefix
           Value:  /
       Backend Refs:
         Group:
         Kind:    Service
         Name:    store-v2
         Port:    8080
         Weight:  1
       Matches:
         Headers:
           Name:   env
           Type:   Exact
           Value:  canary
         Path:
           Type:   PathPrefix
           Value:  /
       Backend Refs:
         Group:
         Kind:    Service
         Name:    store-german
         Port:    8080
         Weight:  1
       Matches:
         Path:
           Type:   PathPrefix
           Value:  /de
   Status:
     Parents:
       Conditions:
         Last Transition Time:  2022-11-01T04:18:52Z
         Message:
         Reason:                Accepted
         Status:                True
         Type:                  Accepted
         Last Transition Time:  2022-11-01T04:18:52Z
         Message:
         Reason:                ReconciliationSucceeded
         Status:                True
         Type:                  Reconciled
       Controller Name:         networking.gke.io/gateway
       Parent Ref:
         Group:  gateway.networking.k8s.io
         Kind:   Gateway
         Name:   internal-http
   Events:
     Type    Reason  Age                From                   Message
     ----    ------  ----               ----                   -------
     Normal  ADD     24m                sc-gateway-controller  default/store
     Normal  SYNC    16m (x4 over 23m)  sc-gateway-controller  Bind of HTTPRoute "default/store" to ParentRef {Group:       gateway.networking.k8s.io",
     <...>
   

4. Vérifiez que la route HTTPRoute est liée à la ressource Gateway :

   kubectl describe gateway
   

   Le résultat ressemble à ce qui suit :

   Name:         internal-http
   Namespace:    default
   Labels:       <none>
   <...>
   Status:
     Addresses:
       Type:   IPAddress
       Value:  10.128.15.203
     Conditions:
       Last Transition Time:  2022-11-01T03:47:01Z
       Message:
       Reason:                Scheduled
       Status:                True
       Type:                  Scheduled
       Last Transition Time:  2022-11-01T03:47:01Z
       Message:
       Reason:                Ready
       Status:                True
       Type:                  Ready
     Listeners:
       Attached Routes:  1
       Conditions:
         Last Transition Time:  2022-11-01T03:47:01Z
         Message:
         Reason:                Ready
         Status:                True
         Type:                  Ready
       Name:                    http
       Supported Kinds:
         Group:  gateway.networking.k8s.io
         Kind:   HTTPRoute
         <...>
   

Envoyer du trafic vers votre application

Maintenant que votre ressource Gateway, votre route et votre application sont déployées dans votre cluster, vous pouvez transmettre du trafic à votre application.

1. Récupérez l'adresse IP à partir de la ressource Gateway afin de pouvoir envoyer du trafic vers votre application :

   kubectl get gateways.gateway.networking.k8s.io internal-http -o=jsonpath="{.status.addresses[0].value}"
   

   Le résultat est une adresse IP.

2. Envoyez du trafic vers cette adresse IP depuis le shell d'une instance de machine virtuelle (VM) disposant d'une connectivité au cluster. Vous pouvez créer une VM à cette fin. Cette opération est nécessaire, car la ressource Gateway dispose d'une adresse IP interne et n'est accessible qu'à partir de votre réseau VPC. Comme internal-http est un équilibreur de charge régional, le shell du client doit se trouver dans la même région que le cluster GKE.

   Comme vous n'êtes pas propriétaire du nom d'hôte "example.com", définissez l'en-tête hôte manuellement afin que le routage du trafic puisse être observé. Commencez par envoyer une requête à "store.example.com" :

   curl -H "host: store.example.com" VIP
   

   Remplacez VIP par l'adresse IP de l'étape précédente.

   Le résultat de l'application de démonstration affiche des informations sur l'emplacement d'exécution de l'application :

   {
     "cluster_name": "gke1",
     "host_header": "store.example.com",
     "metadata": "store-v1",
     "node_name": "gke-gke1-pool-2-bd121936-5pfc.c.gateway-demo-243723.internal",
     "pod_name": "store-v1-84b47c7f58-pmgmk",
     "pod_name_emoji": "💇🏼‍♀️",
     "project_id": "gateway-demo-243723",
     "timestamp": "2022-10-25T13:31:17",
     "zone": "ZONE_NAME"
   }
   

3. Testez la correspondance de chemin en accédant à la version allemande du service de magasin à l'adresse store.example.com/de :

   curl -H "host: store.example.com" VIP/de
   

   Le résultat confirme que la requête a été diffusée par un pod store-german :

   {
     "cluster_name": "gke1",
     "host_header": "store.example.com",
     "metadata": "Gutentag!", 
     "node_name": "gke-gke1-pool-2-bd121936-n3xn.c.gateway-demo-243723.internal",
     "pod_name": "store-german-5cb6474c55-lq5pl", 
     "pod_name_emoji": "🧞‍♀",
     "project_id": "gateway-demo-243723",
     "timestamp": "2022-10-25T13:35:37",
     "zone": "ZONE_NAME"
   }
   

4. Enfin, utilisez l'en-tête HTTP env: canary pour envoyer du trafic vers la version Canary du service de magasin :

   curl -H "host: store.example.com" -H "env: canary " VIP
   

   Le résultat confirme que la requête a été diffusée par un pod store-v2 :

   {
     "cluster_name": "gke1",
     "host_header": "store.example.com",
     "metadata": "store-v2", 
     "node_name": "gke-gke1-pool-2-bd121936-5pfc.c.gateway-demo-243723.internal",
     "pod_name": "store-v2-5788476cbd-s9thb", 
     "pod_name_emoji": "🦰",
     "project_id": "gateway-demo-243723",
     "timestamp": "2022-10-25T13:38:26",
     "zone": "ZONE_NAME"
   }
   

Déployer une ressource Gateway externe

Une ressource Gateway externe expose des applications accessibles depuis Internet ou sur des réseaux en dehors de votre VPC. Ce déploiement est semblable à un déploiement de ressource Gateway interne, sauf que vous devez sécuriser vos applications, car la ressource Gateway est accessible à l'Internet public.

Vous disposez de deux options pour créer une ressource Gateway externe : une ressource Gateway externe globale ou une ressource Gateway externe régionale.

Une ressource Gateway externe globale utilise une adresse IP globale (ou adresse IP Anycast) comme interface de la ressource Gateway annoncée dans toutes les régions Google Cloud Compute. Les clients qui envoient du trafic vers cette adresse IP Anycast sont acheminés vers l'emplacement Google le plus proche de l'emplacement d'annonce de l'adresse IP. La ressource Gateway externe globale n'est disponible qu'avec le niveau de service réseau Premium.

Une ressource Gateway externe régionale utilise une adresse IP régionale comme interface de la ressource Gateway annoncée uniquement dans la région Google Cloud Compute locale dans laquelle la ressource Gateway externe régionale est déployée. Les clients qui envoient du trafic vers cette adresse IP régionale sont acheminés par leur FAI local et via Internet avant d'atteindre la région Google dans laquelle l'adresse IP est annoncée. La ressource Gateway externe régionale n'est disponible qu'avec le niveau de service réseau standard.

Déployer une ressource Gateway externe globale

L'exemple suivant montre comment exposer une application de magasin avec plusieurs certificats associés à la ressource Gateway externe globale, et regroupés dans un mappage de certificat, à l'aide du gestionnaire de certificats et d'un routeur HTTPRoute.

Créer un mappage de certificat

Google vous recommande d'utiliser le gestionnaire de certificats pour gérer les certificats lorsque vous avez besoin d'au moins 15 certificats par ressource Gateway ou si vous devez utiliser des certificats génériques.

Vous pouvez également sécuriser votre ressource Gateway externe à l'aide de secrets Kubernetes ou de certificats SSL gérés par Google. Pour en savoir plus, consultez la section Sécurité des passerelles.

Dans cette section, vous allez créer des certificats à l'aide du gestionnaire de certificats pour sécuriser les applications exécutées sur le cluster.

1. Activez l'API Certificate Manager :

   gcloud services enable certificatemanager.googleapis.com
   

2. Créez un mappage de certificat :

   gcloud beta certificate-manager maps create store-example-com-map
   

3. Chargez votre certificat et vos clés gérés par Google dans un Certificat :

   gcloud beta certificate-manager certificates create store-example-com-cert \
       --certificate-file="CERTIFICATE_FILE" \
       --private-key-file="PRIVATE_KEY_FILE"
   

   Remplacez les éléments suivants :

   • CERTIFICATE_FILE : nom du nouveau fichier que vous choisissez Le fichier doit avoir l'extension .pem. Exemple : cert.pem.
   • PRIVATE_KEY_FILE : nom de votre fichier de clé privée.

   Pour plus d'informations, consultez la section Créer une clé privée et un certificat.

4. Créez un CertificateMapEntry qui attribue le certificat à la carte des certificats :

   gcloud beta certificate-manager maps entries create store-example-com-map-entry \
       --map=store-example-com-map \
       --hostname=store.example.com \
       --certificates=store-example-com-cert
   

Pour savoir comment sécuriser une ressource Gateway à l'aide d'autres sources pour les certificats, tels que les secrets Kubernetes ou les certificats SSL, consultez la page Sécuriser une passerelle.

Créer une ressource Gateway

Une ressource Gateway représente un plan de données qui achemine le trafic dans Kubernetes. Une ressource Gateway peut représenter de nombreux types d'équilibrage de charge et de routage en fonction de la classe GatewayClass utilisée.

Pour en savoir plus sur la ressource Gateway, consultez la description de la ressource Gateway ou la spécification de l'API.

Dans cette section, vous allez créer une ressource Gateway. Les équipes applications peuvent utiliser la ressource Gateway pour exposer leurs applications sur Internet en déployant des routes indépendamment et en les associant à la ressource Gateway de manière sécurisée.

1. Enregistrez le fichier manifeste suivant dans un fichier nommé gateway.yaml :

   kind: Gateway
   apiVersion: gateway.networking.k8s.io/v1beta1
   metadata:
     name: external-http
     annotations:
       networking.gke.io/certmap: store-example-com-map
   spec:
     gatewayClassName: gke-l7-global-external-managed
     listeners:
     - name: https
       protocol: HTTPS
       port: 443
   
   

   Ce fichier manifeste décrit une ressource Gateway avec les propriétés suivantes :

   • gatewayClassName: gke-l7-global-external-managed : spécifie la classe GatewayClass pour cette ressource Gateway. Cette classe de passerelle utilise un équilibreur de charge d'application externe global.
   • protocol: HTTPS et port: 443 : spécifiez que la ressource Gateway expose le port 443 pour le trafic HTTPS. Ces champs activent TLS.
   • networking.gke.io/certmap: store-example-com-map : nom du mappage de certificats dans le gestionnaire de certificats.

   Il n'y a pas de section TLS, car TLS est configuré avec le gestionnaire de certificats à l'aide de l'annotation networking.gke.io/certmap.

2. Appliquez le fichier manifeste à votre cluster :

   kubectl apply -f gateway.yaml
   

   Le déploiement des ressources par GKE peut prendre quelques minutes.

3. Vérifiez que la ressource Gateway a bien été déployée :

   kubectl describe gateway
   

   Le résultat ressemble à ce qui suit :

   Name:         external-http
   Namespace:    default
   Labels:       <none>
   ...
   Spec:
     Gateway Class Name:  gke-l7-global-external-managed
     Listeners:
       Allowed Routes:
         Namespaces:
           From:  Same
       Name:      https
       Port:      443
       Protocol:  HTTPS
       Tls:
         Certificate Refs:
           Group:
           Kind:   Secret
           Name:   store-example-com
         Mode:     Terminate
    ...
   

   Ce résultat montre que la ressource Gateway déployée dans votre cluster dispose d'un équilibreur de charge et d'une adresse IP publique. La ressource Gateway ne dispose d'aucune route, ce qui signifie qu'elle ne peut pas envoyer de trafic aux backends. Sans route, tout le trafic est dirigé vers un backend par défaut, qui renvoie une réponse HTTP 404. Dans la section suivante, vous allez déployer les routes, qui indiquent à la ressource Gateway d'envoyer du trafic vers les backends.

Déployer les applications de démonstration

Les équipes applications peuvent déployer leurs applications et routes indépendamment du déploiement des ressources Gateway. Dans certains cas, l'équipe applications peut également vouloir posséder la ressource Gateway et la déployer elle-même en tant que ressource dédiée à ses applications. Consultez la section Liaison de route pour différents modèles de propriété de ressources Gateway et de routes. Cependant, dans cet exemple, l'équipe du magasin déploie son application et une ressource HTTPRoute associée pour exposer son application via la ressource Gateway external-http créée à la section précédente.

Pour en savoir plus sur les champs HTTPRoute, consultez la spécification d'API.

1. Déployez l'exemple d'application sur votre cluster :

   kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/main/gateway/gke-gateway-controller/app/store.yaml
   

   Cet exemple d'application crée trois déploiements et trois services nommés store-v1, store-v2 et store-german.

2. Vérifiez que l'application a bien été déployée :

   kubectl get pod
   

   Le résultat ressemble à ce qui suit :

   NAME                            READY   STATUS    RESTARTS   AGE
   store-german-66dcb75977-5gr2n   1/1     Running   0          38s
   store-v1-65b47557df-jkjbm       1/1     Running   0          14m
   store-v2-6856f59f7f-sq889       1/1     Running   0          14m
   

3. Vérifiez que les services ont bien été déployés :

   kubectl get service
   

   Le résultat ressemble à ce qui suit :

   NAME           TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)    AGE
   store-german   ClusterIP   10.48.3.183   <none>        8080/TCP   4s
   store-v1       ClusterIP   10.48.2.224   <none>        8080/TCP   5s
   store-v2       ClusterIP   10.48.4.48    <none>        8080/TCP   5s
   

Créer une ressource HTTPRoute

Les ressources de routage définissent des règles spécifiques au protocole pour mapper le trafic d'une ressource Gateway vers les backends Kubernetes. La ressource HTTPRoute effectue une correspondance et un filtrage du trafic HTTP et HTTPS, et est compatible avec toutes les ressources GatewayClass gke-l7-*.

Dans cette section, vous allez déployer une ressource HTTPRoute, qui configure la ressource Gateway avec les règles de routage requises pour atteindre l'exemple d'application.

1. Enregistrez le fichier manifeste suivant dans un fichier nommé store-route-external.yaml :

   kind: HTTPRoute
   apiVersion: gateway.networking.k8s.io/v1beta1
   metadata:
     name: store-external
   spec:
     parentRefs:
     - kind: Gateway
       name: external-http
     hostnames:
     - "store.example.com"
     rules:
     - backendRefs:
       - name: store-v1
         port: 8080
     - matches:
       - headers:
         - name: env
           value: canary
       backendRefs:
       - name: store-v2
         port: 8080
     - matches:
       - path:
           value: /de
       backendRefs:
       - name: store-german
         port: 8080
   

   Ce fichier manifeste décrit une configuration HTTPRoute faisant référence à la ressource Gateway external-http.

2. Appliquez le fichier manifeste à votre cluster :

   kubectl apply -f store-route-external.yaml
   

   La ressource HTTPRoute store est liée à la ressource Gateway external-http à l'aide de la propriété parentRefs : Le schéma suivant illustre les règles de routage configurées sur l'équilibreur de charge sous-jacent :

   

   Les règles de routage traitent le trafic HTTP comme suit :

   • Trafic vers store.example.com/de routes vers le service store-german.
   • Le trafic vers store.example.com avec l'en-tête HTTP "env: canary" est acheminé vers le service store-v2.
   • Le trafic restant vers store.example.com est acheminé vers le service store-v1.

3. Vérifiez que le fichier HTTPRoute a été déployé :

   kubectl describe httproute store-external
   

   Le résultat ressemble à ce qui suit :

   Name:         store-external
   Namespace:    default
   Labels:       <none>
   Annotations:  <none>
   API Version:  gateway.networking.k8s.io/v1beta1
   Kind:         HTTPRoute
   <...>
   Spec:
     Hostnames:
       store.example.com
     Parent Refs:
       Group:  gateway.networking.k8s.io
       Kind:   Gateway
       Name:   external-http
     Rules:
       Backend Refs:
         Group:
         Kind:    Service
         Name:    store-v1
         Port:    8080
         Weight:  1
       Matches:
         Path:
           Type:   PathPrefix
           Value:  /
       Backend Refs:
         Group:
         Kind:    Service
         Name:    store-v2
         Port:    8080
         Weight:  1
       Matches:
         Headers:
           Name:   env
           Type:   Exact
           Value:  canary
         Path:
           Type:   PathPrefix
           Value:  /
       Backend Refs:
         Group:
         Kind:    Service
         Name:    store-german
         Port:    8080
         Weight:  1
       Matches:
         Path:
           Type:   PathPrefix
           Value:  /de
   Status:
     Parents:
       Conditions:
         Last Transition Time:  2022-11-01T05:42:31Z
         Message:
         Reason:                Accepted
         Status:                True
         Type:                  Accepted
         Last Transition Time:  2022-11-01T05:43:18Z
         Message:
         Reason:                ReconciliationSucceeded
         Status:                True
         Type:                  Reconciled
       Controller Name:         networking.gke.io/gateway
       Parent Ref:
         Group:  gateway.networking.k8s.io
         Kind:   Gateway
         Name:   external-http
   Events:
     Type     Reason  Age    From                   Message
     ----     ------  ----   ----                   -------
     Normal   ADD     2m48s  sc-gateway-controller  default/store-external
     Normal  SYNC  61s (x3 over 2m27s)  sc-gateway-controller  Bind of HTTPRoute "default/store-external" to ParentRef Group:       "gateway.networking.k8s.io",
     ...
   

4. Vérifiez que la route HTTPRoute est liée à la ressource Gateway :

   kubectl describe gateway external-http
   

   Le résultat ressemble à ce qui suit :

   Name:         external-http
   Namespace:    default
   Labels:       <none>
   <...>
   Status:
     Addresses:
       Type:   IPAddress
       Value:  34.149.207.45
     Conditions:
       Last Transition Time:  2022-11-01T05:37:21Z
       Message:
       Reason:                Scheduled
       Status:                True
       Type:                  Scheduled
       Last Transition Time:  2022-11-01T05:43:18Z
       Message:
       Reason:                Ready
       Status:                True
       Type:                  Ready
     Listeners:
       Attached Routes:  1
       Conditions:
         Last Transition Time:  2022-11-01T05:43:18Z
         Message:
         Reason:                Ready
         Status:                True
         Type:                  Ready
       Name:                    https
       Supported Kinds:
         Group:  gateway.networking.k8s.io
         Kind:   HTTPRoute
         <...>
   

Envoyer du trafic vers votre application

Maintenant que votre ressource Gateway, votre route et votre application sont déployées dans votre cluster, vous pouvez transmettre du trafic à votre application.

1. Obtenez l'adresse IP de la passerelle :

   kubectl get gateways.gateway.networking.k8s.io external-http -o=jsonpath="{.status.addresses[0].value}"
   

   Le résultat est une adresse IP.

2. Créez une VM :

   gcloud cloud-shell ssh
   

3. Envoyez du trafic vers l'adresse IP de la ressource Gateway à partir de la VM. Vous devez définir l'en-tête d'hôte manuellement, car vous n'êtes pas propriétaire du nom d'hôte example.com.

   curl -H "host: store.example.com" https://GATEWAY_IP_ADDRESS --resolve store.example.com:443:GATEWAY_IP_ADDRESS --cacert cacert.pem -v
   

   Remplacez GATEWAY_IP_ADDRESS par l'adresse IP de la ressource Gateway de l'étape précédente.

   La sortie affiche des informations de l'application de démonstration sur l'emplacement d'exécution de l'application :

   {
     "cluster_name": "gke1",
     "host_header": "store.example.com",
     "metadata": "store-v1",
     "node_name": "gke-gke1-pool-2-bd121936-5pfc.c.gateway-demo-243723.internal",
     "pod_name": "store-v1-84b47c7f58-pmgmk",
     "pod_name_emoji": "💇🏼‍♀️",
     "project_id": "gateway-demo-243723",
     "timestamp": "2022-09-25T13:31:17",
     "zone": "us-central1-a"
   }
   

4. Testez la correspondance de chemin en accédant à la version allemande du service store à l'adresse store.example.com/de :

   curl -H "host: store.example.com" https://GATEWAY_IP_ADDRESS/de --resolve store.example.com:443:GATEWAY_IP_ADDRESS --cacert cacert.pem -v
   

   Le résultat confirme que la requête a été diffusée par un pod store-german :

   {
     "cluster_name": "gke1",
     "host_header": "store.example.com",
     "metadata": "Gutentag!",
     "node_name": "gke-gke1-pool-2-bd121936-n3xn.c.gateway-demo-243723.internal",
     "pod_name": "store-german-5cb6474c55-lq5pl",
     "pod_name_emoji": "🧞‍♀",
     "project_id": "gateway-demo-243723",
     "timestamp": "2022-09-25T13:35:37",
     "zone": "us-central1-a"
   }
   

5. Envoyez du trafic vers la version Canary du service store à l'aide de l'en-tête HTTP env: canary :

   curl -H "host: store.example.com" -H "env: canary " https://GATEWAY_IP_ADDRESS/de --resolve store.example.com:443:GATEWAY_IP_ADDRESS --cacert cacert.pem -v
   

   Le résultat confirme que la requête a été diffusée par un pod store-v2 :

   {
     "cluster_name": "gke1",
     "host_header": "store.example.com",
     "metadata": "store-v2",
     "node_name": "gke-gke1-pool-2-bd121936-5pfc.c.gateway-demo-243723.internal",
     "pod_name": "store-v2-5788476cbd-s9thb",
     "pod_name_emoji": "👩🏿",
     "project_id": "gateway-demo-243723",
     "timestamp": "2022-09-25T13:38:26",
     "zone": "us-central1-a"
   }
   

Déployer une ressource Gateway externe régionale

L'exemple suivant montre comment exposer une application de magasin avec plusieurs certificats associés à la ressource Gateway externe régionale, à l'aide de certificats autogérés et d'une ressource HTTPRoute.

Créer un sous-réseau proxy pour votre ressource Gateway régionale

Vous devez configurer un sous-réseau proxy réservé avant de créer une ressource Gateway qui utilise un équilibreur de charge d'application externe régional. Chaque région d'un VPC dans lequel vous utilisez un équilibreur de charge d'application externe régional doit disposer d'un sous-réseau external_managed_proxy. Ce sous-réseau permet de fournir des adresses IP internes aux proxys des équilibreurs de charge.

Créer un certificat pour sécuriser le trafic client

Vous pouvez utiliser un certificat émis et validé par votre autorité de certification (CA) ou créer un certificat autosigné. Pour en savoir plus sur la création d'un certificat, consultez la section Stocker un certificat dans un secret Kubernetes.

Remarque : CertificateMap ou les certificats SSL gérés par Google ne sont pas compatibles avec les ressources Gateway régionales. Utilisez des certificats SSL ou des secrets régionaux autogérés pour sécuriser le trafic entre vos clients et votre ressource Gateway régionale. Pour en savoir plus sur les certificats et les équilibreurs de charge Google Cloud, consultez la page Certificats et équilibreurs de charge Google Cloud

Créer une ressource Gateway HTTP(S) externe régionale

1. Créez une adresse IP statique régionale pour l'équilibreur de charge externe.

   gcloud compute addresses create IP_ADDRESS_NAME \
     --region=COMPUTE_REGION \
     --network-tier=STANDARD
   

   Remplacez les éléments suivants :

   • IP_ADDRESS_NAME : nom de la nouvelle adresse IP statique
   • COMPUTE_REGION : région Compute Engine dans laquelle le cluster est exécuté.

2. Créez une ressource Gateway d'équilibreur de charge d'application externe régionale à l'aide d'un certificat autogéré comme suit et enregistrez le fichier manifeste sous le nom regional-gateway.yaml :

     kind: Gateway
     apiVersion: gateway.networking.k8s.io/v1beta1
     metadata:
       name: external-regional-http
     spec:
       gatewayClassName: gke-l7-regional-external-managed
       listeners:
       - name: https
         protocol: HTTPS
         port: 443
         tls:
           mode: Terminate
           certificateRefs:
           - name: store-example-com
       addresses:
       - type: NamedAddress
         value: IP_ADDRESS_NAME
   

3. Appliquez le fichier manifeste regional-gateway :

     kubectl apply -f regional-gateway.yaml
   

4. Vérifiez votre configuration.

     kubectl get gateway
   

   Le résultat ressemble à ce qui suit :

   NAME            CLASS                              ADDRESS         READY   AGE
   external-http   gke-l7-regional-external-managed   35.118.32.224   True    49s
   

   Pour obtenir plus de détails, utilisez une commande describe :

   kubectl describe gateway
   

   Le résultat ressemble à ce qui suit :

   Name:         external-regional-http
   Namespace:    default
   Labels:       <none>
   ...
   Spec:
     Gateway Class Name:  gke-l7-regional-external-managed
     Listeners:
       Allowed Routes:
         Namespaces:
           From:  Same
       Name:      https
       Port:      443
       Protocol:  HTTPS
       Tls:
         Certificate Refs:
           Group:
           Kind:   Secret
           Name:   store-example-com
         Mode:     Terminate
     ...
   

Déployer l'application de démonstration

Vous pouvez déployer vos applications et routes indépendamment du déploiement des ressources Gateway.

Pour en savoir plus sur le déploiement des applications de démonstration, consultez la section Déployer les applications de démonstration.

Créer une ressource HTTPRoute

Vous devez créer une ressource HTTPRoute pour effectuer la mise en correspondance et le filtrage du trafic HTTP et HTTPS.

Envoyer du trafic vers votre application

Après avoir déployé votre application et créé des ressources HTTPRoute, vous pouvez transmettre du trafic à votre application.

Pour en savoir plus sur l'envoi de trafic vers votre application, consultez la page Envoyer du trafic vers votre application.

Utiliser des ressources Gateway partagées

Les API Gateway utilisent des ressources distinctes, des ressources Gateway et Route, pour déployer les équilibreurs de charge et les règles de routage. Cela diffère d'Ingress, qui combine tout dans une ressource. En répartissant la responsabilité entre les ressources, Gateway permet à l'équilibreur de charge et à ses règles de routage d'être déployés séparément, et d'être déployés par différents utilisateurs ou équipes. Cela permet aux ressources Gateway de devenir des ressources Gateway partagées qui se lient à de nombreuses routes différentes et qui peuvent être entièrement détenues et gérées par des équipes indépendantes, même sur différents espaces de noms.

Déployer des routes sur une ressource Gateway partagée

Cet exemple s'appuie sur la ressource Gateway internal-http déployée dans la section Déployer une passerelle interne.

Dans cet exemple, l'équipe chargée du site déploie son application, ses services et une ressource HTTPRoute pour faire correspondre le trafic de la ressource Gateway à ces services.

1. Déployez l'exemple d'application :

   kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/main/gateway/gke-gateway-controller/app/site.yaml
   

2. Enregistrez le fichier manifeste suivant dans un fichier nommé site-route-internal.yaml :

   kind: HTTPRoute
   apiVersion: gateway.networking.k8s.io/v1beta1
   metadata:
     name: site-internal
   spec:
     parentRefs:
     - kind: Gateway
       name: internal-http
     hostnames:
     - "site.example.com"
     rules:
     - backendRefs:
       - name: site-v1
         port: 8080
   

   Ce fichier manifeste décrit une route HTTPRoute qui correspond à tout le trafic pour site.example.com et l'achemine vers le service site-v1.

3. Appliquez le fichier manifeste à votre cluster :

   kubectl apply -f site-route-internal.yaml
   

4. Vérifiez que la route HTTPRoute est rattachée à la ressource Gateway :

   kubectl describe httproute.gateway.networking.k8s.io site-internal
   

   Le résultat ressemble à ce qui suit :

   Status:
     Parents:
       Conditions:
         Last Transition Time:  2023-01-09T15:05:43Z
         Message:
         Reason:                Accepted
         Status:                True
         Type:                  Accepted
         Last Transition Time:  2023-01-09T15:05:43Z
         Message:
         Reason:                ReconciliationSucceeded
         Status:                True
         Type:                  Reconciled
       Controller Name:         networking.gke.io/gateway
       Parent Ref:
         Group:  gateway.networking.k8s.io
         Kind:   Gateway
         Name:   internal-http
         ...
   

   Si la valeur de la condition Accepted pour la ressource Gateway est True, la ressource HTTPRoute a bien été liée à la ressource Gateway. Pour en savoir plus sur le champ "État", consultez la section État des routes.

5. Vérifiez que le trafic vers la passerelle est correctement acheminé :

   curl -H "host: site.example.com" GATEWAY_IP_ADDRESS
   curl -H "host: store.example.com" GATEWAY_IP_ADDRESS
   

   Remplacez GATEWAY_IP_ADDRESS par l'adresse IP de la passerelle.

   Vous devez utiliser une machine virtuelle (VM) dans le même VPC que la passerelle.

   Le résultat ressemble à ce qui suit :

   {
     "cluster_name": "CLUSTER_NAME",
     "host_header": "site.example.com",
     "metadata": "site-v1",
     "pod_name": "site-v1-5d64fc4d7d-fz6f6",
     "pod_name_emoji": "👩🏼‍🍳",
     "project_id": "PROJECT_ID",
     "timestamp": "2022-11-02T19:07:01",
     "zone": "ZONE_NAME"
   }
   ...
   {
     "cluster_name": "CLUSTER_NAME",
     "host_header": "store.example.com",
     "metadata": "store-v1",
     "pod_name": "store-v1-6d8d58d78-vz8pn",
     "pod_name_emoji": "🧝🏻‍♂️",
     "project_id": "PROJECT_ID",
     "timestamp": "2022-11-02T19:07:01",
     "zone": "ZONE_NAME"
   }
   

Configurer le backend par défaut de la passerelle

Toutes les classes GatewayClasses gke-l7-* renvoient un code HTTP 404 pour le trafic sans correspondance. Vous pouvez configurer le backend par défaut en utilisant une route par défaut explicite qui envoie le trafic sans correspondance à un service fourni par l'utilisateur.

Remarque : Les passerelles sont configurées pour gérer des codes d'erreur tels que 404 (page introuvable) et 500 (erreur du serveur), même sans définitions de backend explicites. Le comportement par défaut peut varier entre les mises en œuvre de Gateway. Pour un meilleur contrôle sur la gestion des erreurs, envisagez de configurer des backends personnalisés.

La ressource HTTPRoute suivante montre comment personnaliser le backend par défaut. Si vous appliquez une route HTTPRoute semblable à la suivante, elle est prioritaire sur le backend implicite par défaut :

kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: custom-default-backend
spec:
  parentRefs:
  - kind: Gateway
    name: my-internal-gateway
  rules:
  - backendRefs:
    - name: my-custom-default-backend-service
      port: 8080

Cette ressource HTTPRoute correspond à tout le trafic provenant d'une ressource Gateway spécifique. Vous ne pouvez disposer que d'une seule règle de ce type pour chaque passerelle, sans quoi les règles seront en conflit et l'ordre de priorité sera appliqué.

Vous pouvez utiliser un backend par défaut pour empêcher une personne de créer un backend de routage par défaut qui achemine tout le trafic de la passerelle. Une route HTTPRoute explicite est toujours prioritaire sur les nouvelles routes HTTP comportant des règles de routage en conflit.

Configurer une adresse IP statique pour une passerelle

Chaque passerelle possède une adresse IP qu'elle utilise pour écouter le trafic. Si vous ne spécifiez pas d'adresse IP sur la passerelle, le contrôleur de passerelle fournit automatiquement une adresse IP. Vous pouvez également créer une adresse IP statique afin que l'adresse IP existe indépendamment du cycle de vie de la passerelle.

Une fois la passerelle déployée, son adresse IP apparaît dans le champ d'état :

kind: Gateway
...
status:
  addresses:
    - value: 10.15.32.3

Selon la GatewayClass, l'adresse IP est allouée à partir des sous-réseaux suivants :

Ressources GatewayClass	Pool d'adresses IP par défaut
gke-l7-rilb gke-l7-rilb-mc	Adresses IP privées régionales à partir de la plage d'adresses IPv4/IPv6 du nœud principal
gke-l7-regional-external-managed gke-l7-regional-external-managed-mc	Adresses IP publiques régionales des plages d'adresses IPv4/IPv6 externes régionales de Google
gke-l7-global-external-managed gke-l7-global-external-managed-mc gke-l7-gxlb gke-l7-gxlb-mc	Adresses IP publiques globales issues des plages d'adresses IPv4/IPv6 externes globales de Google

Le champ addresses.NamedAddress vous permet de spécifier une adresse IP indépendamment de la passerelle. Vous pouvez créer une ressource d'adresse IP statique avant le déploiement de la passerelle, la ressource étant référencée par le NamedAddress. Vous pouvez réutiliser l'adresse IP statique même si la passerelle est supprimée.

Utiliser une adresse IP nommée

Vous pouvez configurer une adresse IP en spécifiant un NamedAddress. Vous devez provisionner une adresse IP statique avant de créer une passerelle.

1. Créez une ressource d'adresse IP statique.

   gcloud compute addresses create IP_ADDRESS_NAME \
       --purpose=SHARED_LOADBALANCER_VIP \
       --region=COMPUTE_REGION \
       --subnet=SUBNET \
       --project=PROJECT_ID
   

   Remplacez les éléments suivants :

   • IP_ADDRESS_NAME : nom de la nouvelle adresse IP statique
   • COMPUTE_REGION : pour les passerelles régionales, la région Compute Engine dans laquelle votre cluster s'exécute. Cette option n'est pas nécessaire pour les passerelles externes globales.
   • SUBNET : sous-réseau de l'adresse IP. Cette option n'est pas nécessaire pour les passerelles externes globales.
   • PROJECT_ID : projet dans lequel votre cluster GKE s'exécute.

2. Enregistrez le fichier manifeste suivant dans un fichier nommé named-ip-gateway.yaml :

   kind: Gateway
   apiVersion: gateway.networking.k8s.io/v1beta1
   metadata:
     name: internal-http
   spec:
     gatewayClassName: gke-l7-rilb
     listeners:
     - name: http
       protocol: HTTP
       port: 80
     addresses:
     - type: NamedAddress
       value: IP_ADDRESS_NAME
   

   Ce fichier manifeste décrit une passerelle qui référence l'adresse IP nommée.

3. Appliquez le fichier manifeste à votre cluster :

   kubectl apply -f named-ip-gateway.yaml
   

4. Vérifiez l'adresse IP de votre passerelle :

   kubectl describe gateway internal-http
   

   Le résultat ressemble à ce qui suit :

   Name:         internal-http
   Namespace:    default
   Labels:       <none>
   ...
   Spec:
     Addresses:
       Type:              NamedAddress
       Value:             IP_ADDRESS_NAME
     Gateway Class Name:  gke-l7-rilb
     Listeners:
       Allowed Routes:
         Namespaces:
           From:  Same
       Name:      http
       Port:      80
       Protocol:  HTTP
   Status:
     Addresses:
       Type:   IPAddress
       Value:  10.15.32.103
   

Configurer les redirections HTTP vers HTTPS

Cloud Load Balancing propose une fonctionnalité de redirection HTTP vers HTTPS. Un équilibreur de charge d'application externe redirige les requêtes HTTP non chiffrées vers un équilibreur de charge HTTPS qui utilise la même adresse IP. Lorsque vous créez une passerelle avec des redirections HTTP vers HTTPS activées, ces deux équilibreurs de charge sont créés automatiquement. Les requêtes adressées à l'adresse IP externe de la passerelle sur le port 80 sont automatiquement redirigées vers la même adresse IP externe sur le port 443.

Par défaut, les redirections HTTP vers HTTPS ne sont pas définies sur la passerelle.

Pour rediriger le trafic HTTP vers HTTPS, configurez une passerelle pour gérer le trafic HTTP et HTTPS. Si vous désactivez HTTP ou HTTPS, la passerelle ne redirige pas le trafic.

Les exemples suivants montrent comment utiliser la redirection HTTP vers HTTPS pour vous assurer que le trafic de vos clients allant vers vos applications Web est toujours redirigé vers une page sécurisée.

Remarque : Les redirections HTTP vers HTTPS ne sont pas compatibles avec les ressources GatewayClass gke-l7-gxlb et gke-l7-gxlb-mc. Pour en savoir plus sur les différentes fonctionnalités compatibles avec chaque GatewayClass, consultez la page Fonctionnalités de GatewayClass.

Rediriger le trafic HTTP provenant de l'espace de noms de la passerelle

Dans l'exemple suivant, la passerelle est configurée pour autoriser Same (rattachement à partir du même espace de noms) sur l'écouteur HTTP, tandis que l'écouteur HTTPS est ouvert à tous les espaces de noms. Lorsque vous utilisez cette configuration, seule la redirection HTTPRoute doit exister dans le même espace de noms que la passerelle.

Cette configuration garantit qu'aucune ressource HTTPRoute supplémentaire ne peut être liée à l'écouteur HTTP de la ressource Gateway. Cela nécessite que les ressources HTTPRoute de l'équipe applications ne soient pas autorisées dans l'espace de noms gateway-infra.

1. Créez l'espace de noms gateway-infra de la passerelle. Enregistrez le manifeste sous le nom gateway-namespace.yaml :

   apiVersion: v1
   kind: Namespace
   metadata:
     name: gateway-infra
   

2. Appliquer le fichier manifeste :

   kubectl apply -f gateway-namespace.yaml
   

3. Créez une passerelle en utilisant le fichier manifeste suivant et enregistrez-le sous le nom external-gateway.yaml :

   kind: Gateway
   apiVersion: gateway.networking.k8s.io/v1beta1
   metadata:
     name: external-http
     namespace: gateway-infra
   spec:
     gatewayClassName: gke-l7-global-external-managed
     listeners:
     - name: http
       protocol: HTTP
       port: 80
       allowedRoutes:
         kinds:
         - kind: HTTPRoute
         namespaces:
           from: Same
     - name: https
       protocol: HTTPS
       port: 443
       allowedRoutes:
         kinds:
         - kind: HTTPRoute
         namespaces:
           from: All
       tls:
         mode: Terminate
         options:
           networking.gke.io/pre-shared-certs: store-example-com
   

   • Le champ namespaces de la section allowedRoutes limite l'écouteur http à l'espace de noms gateway-infra de la passerelle uniquement.

   • L'écouteur https n'inclut pas de restriction sur les espaces de noms autorisés. Par conséquent, tous les espaces de noms utilisent l'écouteur https avec une route HTTPRoute.

4. Appliquer le fichier manifeste :

   kubectl apply -f external-gateway.yaml
   

5. Pour forcer la redirection HTTPS, créez une ressource HTTPRoute par défaut à l'aide du fichier manifeste suivant et enregistrez-le sous le nom redirect-httproute.yaml :

   kind: HTTPRoute
   apiVersion: gateway.networking.k8s.io/v1beta1
   metadata:
     name: redirect
     namespace: gateway-infra
   spec:
     parentRefs:
     - namespace: gateway-infra
       name: external-http
       sectionName: http
     rules:
     - filters:
       - type: RequestRedirect
         requestRedirect:
           scheme: https
   

   • Le champ sectionName indique à la ressource Gateway de ne correspondre qu'à l'écouteur HTTP. Le filtre RequestRedirect force la redirection vers l'écouteur https.

   Cette configuration redirige tout trafic reçu sur le port 80 de la ressource Gateway vers l'écouteur sur le port 443 en appliquant une communication sécurisée entre le client et l'équilibreur de charge.

6. Appliquer le fichier manifeste :

   kubectl apply -f redirect-httproute.yaml
   

7. Créez un service pour une application à l'aide du fichier manifeste suivant. Enregistrez le fichier manifeste sous le nom service-deployment.yaml.

   apiVersion: v1
   kind: Service
   metadata:
     name: store-v1
   spec:
     selector:
       app: store
       version: v1
     ports:
     - port: 8080
       targetPort: 8080
   
   ---
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: store-v1
   spec:
     replicas: 2
     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"
   

8. Appliquer le fichier manifeste :

   kubectl apply -f service-deployment.yaml
   

9. Créez une ressource HTTPRoute pour une application qui n'autorise que le protocole HTTPS. Enregistrez le fichier manifeste sous le nom httproute.yaml.

   kind: HTTPRoute
   apiVersion: gateway.networking.k8s.io/v1beta1
   metadata:
     name: store-external
     labels:
       gateway: external-http
   spec:
     parentRefs:
     - name: external-http
       namespace: gateway-infra
       sectionName: https
     hostnames:
     - "store.example.com"
     rules:
     - backendRefs:
       - name: store-v1
         port: 8080
   

10. Appliquez le fichier manifeste :

    kubectl apply -f httproute.yaml
    

Rediriger le trafic HTTP depuis un espace de noms d'infrastructure

Dans certains cas, il n'existe pas de distinction claire entre l'équipe d'administration de l'infrastructure ou de la plate-forme et les équipes applications, et éviter une utilisation abusive de la passerelle peut devenir un défi.

L'exemple suivant restreint l'utilisation de l'écouteur HTTP pour éviter tout usage involontaire du protocole non sécurisé des équipes applications. Cet exemple configure la ressource Gateway pour permettre à une ressource HTTPRoute d'utiliser l'écouteur HTTP uniquement si la route se trouve dans un espace de noms donné (http-redirect) lorsqu'elle ouvre l'écouteur HTTPS dans tous les espaces de noms. Vous pouvez limiter l'espace de noms http-redirect à l'aide de Kubernetes RBAC afin que les équipes d'application ne puissent pas créer de ressource HTTPRoute dans cet espace de noms par erreur.

1. Créez l'espace de noms d'une passerelle. Enregistrez le fichier manifeste sous le nom gateway-namespace.yaml.

   apiVersion: v1
   kind: Namespace
   metadata:
     name: gateway-infra
   

2. Appliquer le fichier manifeste :

   kubectl apply -f gateway-namespace.yaml
   

3. Créez l'espace de noms d'une passerelle et enregistrez le fichier manifeste sous le nom redirect-namespace.yaml :

   apiVersion: v1
   kind: Namespace
   metadata:
     name: http-redirect
     labels:
       otherInfra: httpToHttps
   

   • Des libellés spécifiques sont définis pour cet espace de noms.

4. Appliquer le fichier manifeste :

   kubectl apply -f redirect-namespace.yaml
   

5. Pour restreindre l'utilisation de l'écouteur HTTP, créez une passerelle à l'aide du fichier manifeste suivant. Enregistrez le manifeste sous le nom external-gateway.yaml :

   kind: Gateway
   apiVersion: gateway.networking.k8s.io/v1beta1
   metadata:
     name: external-http
     namespace: gateway-infra
   spec:
     gatewayClassName: gke-l7-global-external-managed
     listeners:
     - name: http
       protocol: HTTP
       port: 80
       allowedRoutes:
         kinds:
         - kind: HTTPRoute
         namespaces:
           from: selector
           selector:
             matchLabels:
               otherInfra: httpToHttps
     - name: https
       protocol: HTTPS
       port: 443
       allowedRoutes:
         kinds:
         - kind: HTTPRoute
         namespaces:
           from: All
       tls:
         mode: Terminate
         options:
           networking.gke.io/pre-shared-certs: store-example-com
     ```
   

   • Le champ namespace indique que la passerelle est créée dans l'espace de noms gateway-infra.

   • Le champ namespaces de la section allowedRoutes limite l'écouteur http à l'espace de noms correspondant au libellé otherInfra: httpToHttps.

6. Appliquer le fichier manifeste :

   kubectl apply -f external-gateway.yaml
   

7. Pour forcer la redirection HTTPS, créez une ressource HTTPRoute par défaut à l'aide du fichier manifeste suivant. Enregistrez le manifeste sous le nom http-redirect.yaml :

   kind: HTTPRoute
   apiVersion: gateway.networking.k8s.io/v1beta1
   metadata:
     name: redirect
     namespace: http-redirect
   spec:
     parentRefs:
     - namespace: gateway-infra
       name: external-http
       sectionName: http
     rules:
     - filters:
       - type: RequestRedirect
         requestRedirect:
           scheme: https
   

   • Le champ sectionName indique à la ressource Gateway de ne correspondre qu'à l'écouteur HTTP. Le filtre RequestRedirect force la redirection vers l'écouteur https.

8. Appliquer le fichier manifeste :

   kubectl apply -f http-redirect.yaml
   

9. Créez un service pour une application à l'aide du fichier manifeste suivant. Enregistrez le fichier manifeste sous le nom service-deployment.yaml.

   apiVersion: v1
   kind: Service
   metadata:
     name: store-v1
   spec:
     selector:
       app: store
       version: v1
     ports:
     - port: 8080
       targetPort: 8080
   ---
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: store-v1
   spec:
     replicas: 2
     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"
   

10. Appliquer le fichier manifeste :

    kubectl apply -f service-deployment.yaml
    

11. Créez une ressource HTTPRoute pour une application qui n'autorise HTTPS que à l'aide du fichier manifeste suivant. Enregistrez le manifeste sous le nom http-route.yaml :

    kind: HTTPRoute
    apiVersion: gateway.networking.k8s.io/v1beta1
    metadata:
      name: store-external
      labels:
        gateway: external-http
    spec:
      parentRefs:
      - name: external-http
        namespace: gateway-infra
        sectionName: https
      hostnames:
      - "store.example.com"
      rules:
      - backendRefs:
        - name: store-v1
          port: 8080
    

12. Appliquez le fichier manifeste :

    kubectl apply -f http-route.yaml
    

Configurer les redirections de chemin d'accès et les réécritures d'URL

Les redirections de chemin d'accès impliquent la redirection d'une requête entrante depuis un chemin d'URL vers un autre. Les redirections de chemin d'accès vous permettent de modifier la structure d'une URL lorsque vous devez gérer des URL obsolètes.

Les réécritures d'URL permettent de modifier l'URL entrante avant de la traiter sur le serveur. Cela vous permet de modifier la structure ou le format de l'URL sans modifier réellement la structure du contenu sous-jacent ou du fichier. La réécriture d'URL permet de créer des URL conviviales et basées sur les principes du SEO, faciles à retenir et à comprendre. Par défaut, les redirections de chemin d'accès et les réécritures d'URL ne sont pas configurées. Vous devez les configurer explicitement à l'aide d'un filtre dans votre ressource HTTPRoute.

GKE Gateway est compatible avec les redirections de chemin d'accès et les réécritures d'URL. Pour en savoir plus, consultez la page Redirections et réécritures de chemins HTTP.

Configurer les redirections de chemin d'accès

Vous pouvez configurer des redirections de chemin d'accès pour remplacer l'intégralité du chemin d'accès ou seulement un préfixe dans l'URL.

Remplacer le chemin d'accès complet

1. Pour remplacer un chemin d'accès complet, configurez un filtre dans une ressource HTTPRoute qui remplace toute URL contenant le préfixe /any-path dans le chemin de l'URL par la valeur stricte /new-path.

2. Créez un fichier manifeste HTTPRoute comme suit et nommez-le store.yaml :

     apiVersion: gateway.networking.k8s.io/v1beta1
     kind: HTTPRoute
     metadata:
       name: store
     spec:
       parentRefs:
         - kind: Gateway
           name: external-http
       hostnames:
       - store.example.com
       rules:
       - matches:
         - path:
             type: PathPrefix
             value: /any-path
         filters:
         - type: RequestRedirect
           requestRedirect:
             path:
               type: ReplaceFullPath
               replaceFullPath: /new-path
             statusCode: 302
   

   Par exemple, ce fichier manifeste définit une règle de routage pour une ressource HTTPRoute comme suit : toute route vers l'URL https://store.example.com/any-path/... doit être redirigée vers un nouvel emplacement, https://store.example.com/new-path/ (strict).

3. Appliquez le fichier manifeste :

   kubectl apply -f store.yaml
   

Cette règle de routage suit une règle de redirection stricte, ce qui signifie que le navigateur ne tente pas de mettre en cache la redirection, mais qu'il redirige vers la dernière version.

Remplacer uniquement un préfixe

1. Pour ne remplacer qu'un préfixe, configurez un filtre dans une ressource HTTPRoute qui remplace toute URL contenant le préfixe /any-prefix dans le chemin de l'URL par la valeur stricte /new-prefix.

2. Créez un fichier manifeste HTTPRoute comme suit et nommez-le store.yaml :

   apiVersion: gateway.networking.k8s.io/v1beta1
   kind: HTTPRoute
   metadata:
     name: store
   spec:
     parentRefs:
       - kind: Gateway
         name: external-http
     hostnames:
     - store.example.com
     rules:
     - matches:
         - path:
             type: PathPrefix
             value: /any-prefix
       filters:
       - type: RequestRedirect
         requestRedirect:
           path:
             type: ReplacePrefixMatch
             replacePrefixMatch: /new-prefix
           statusCode: 302
   

   Par exemple, ce fichier manifeste définit une règle de routage pour une ressource HTTPRoute comme suit : toute route vers l'URL https://store.example.com/any-path/v1/... doit être redirigée vers un nouvel emplacement, https://store.example.com/new-path/v1/... (uniquement)

3. Appliquez le fichier manifeste :

     kubectl apply -f store.yaml
   

Cette règle de routage suit la seule règle de redirection, qui garantit que le navigateur vous redirige toujours vers la même page prévue.

Configurer les réécritures d'URL

Définissez les réécritures d'URL pour modifier la façon dont une URL s'affiche pour les utilisateurs. Vous pouvez utiliser des réécritures d'URL pour rendre les URL plus conviviales, pour améliorer le SEO ou pour rediriger les utilisateurs vers une nouvelle page.

Réécrire l'intégralité du nom d'hôte

Pour réécrire l'intégralité du nom d'hôte, procédez comme suit :

1. Configurez un filtre dans une ressource HTTPRoute qui indique à la ressource Gateway de modifier les informations Host de l'en-tête de requête en remplaçant www.example.com par store.example.com avant de transmettre la requête au service de backend.

2. Créez un fichier manifeste HTTPRoute comme suit et nommez-le www.yaml :

     apiVersion: gateway.networking.k8s.io/v1beta1
     kind: HTTPRoute
     metadata:
       name: www
     spec:
       parentRefs:
         - kind: Gateway
           name: external-http
       hostnames:
       - www.example.com
       rules:
       - filters:
         - type: URLRewrite
           urlRewrite:
             hostname: store.example.com
         backendRefs:
         - name: store-v1
           port: 8080
   

   Par exemple, avec la configuration ci-dessus, toute requête envoyée àhttps://www.example.com est transférée au service de backend avec l'en-tête Host: store.example.com au lieu de Host: www.example.com.

3. Appliquez le fichier manifeste :

     kubectl apply -f www.yaml
   

Réécrire à l'aide de modificateurs de chemin d'accès

Vous pouvez combiner des réécritures avec des modificateurs de chemin d'accès pour fournir des modifications avancées d'URL et de chemins d'accès avant de relayer la requête au service de backend.

Pour réécrire à l'aide des modificateurs de chemin d'accès, procédez comme suit :

1. Configurez un filtre dans une ressource HTTPRoute qui indique à la ressource Gateway de modifier les informations "Hôte" dans l'en-tête de requête en remplaçant www.example.com par store.example.com et en remplaçant la valeur /store par/ avant de transmettre la requête au service de backend.

2. Créez un fichier manifeste HTTPRoute comme suit et nommez-le www.yaml :

     apiVersion: gateway.networking.k8s.io/v1beta1
     kind: HTTPRoute
     metadata:
       name: www
     spec:
       parentRefs:
         - kind: Gateway
           name: external-http
       hostnames:
       - www.example.com
       rules:
       - matches:
         - path:
             type: PathPrefix
             value: /store
         filters:
         - type: URLRewrite
           urlRewrite:
             hostname: store.example.com
             path:
               type: ReplacePrefixMatch
               replacePrefixMatch: /de
         backendRefs:
         - name: store-german
           port: 8080
   

   Par exemple, avec la configuration ci-dessus, toute requête envoyée à https://www.example.com/store/... est transférée au service de backend avec Host: store.example.com dans l'en-tête de requête (au lieu de Host: www.example.com), et /store est remplacé par /de.

3. Appliquez le fichier manifeste :

   kubectl apply -f www.yaml
   

Vérifiez votre configuration

Pour vérifier que le filtre a été appliqué après la création de votre ressource HTTPRoute avec la réécriture d'URL ou les filtres de redirection de chemin d'accès, procédez comme suit :

kubectl get httproute www -o yaml

Le résultat ressemble à ce qui suit :

  apiVersion: gateway.networking.k8s.io/v1beta1
  kind: HTTPRoute
  metadata:
    annotations:
      kubectl.kubernetes.io/last-applied-configuration: |
        {"apiVersion":"gateway.networking.k8s.io/v1beta1","kind":"HTTPRoute","metadata":{"annotations":{},"name":"www","namespace":"default"},"spec":{"hostnames":["www.example.com"],"parentRefs":[{"kind":"Gateway","name":"external-http"}],"rules":[{"backendRefs":[{"name":"store-german","port":8080}],"filters":[{"type":"URLRewrite","urlRewrite":{"hostname":"store.example.com","path":{"replacePrefixMatch":"/de","type":"ReplacePrefixMatch"}}}],"matches":[{"path":{"type":"PathPrefix","value":"/store"}}]}]}}
    creationTimestamp: "2023-06-22T01:00:42Z"
    generation: 3
    name: www
    namespace: default
    resourceVersion: "51268631"
    uid: e516493e-806d-44d6-ae0d-1c9ff25682cf
  spec:
    hostnames:
    - www.example.com
    parentRefs:
    - group: gateway.networking.k8s.io
      kind: Gateway
      name: external-http
    rules:
    - backendRefs:
      - group: ""
        kind: Service
        name: store-german
        port: 8080
        weight: 1
      filters:
      - type: URLRewrite
        urlRewrite:
          hostname: store.example.com
          path:
            replacePrefixMatch: /de
            type: ReplacePrefixMatch
      matches:
      - path:
          type: PathPrefix
          value: /store
  status:
    parents:
    - conditions:
      - lastTransitionTime: "2023-06-22T01:11:26Z"
        message: ""
        observedGeneration: 2
        reason: Accepted
        status: "True"
        type: Accepted
      - lastTransitionTime: "2023-06-22T01:11:26Z"
        message: ""
        observedGeneration: 2
        reason: ReconciliationSucceeded
        status: "True"
        type: Reconciled
      controllerName: networking.gke.io/gateway
      parentRef:
        group: gateway.networking.k8s.io
        kind: Gateway
        name: external-http

Pour obtenir plus de détails, utilisez la commande describe :

kubectl describe httproute

Configurer des en-têtes de requêtes et de réponses personnalisés

Les en-têtes de requêtes et de réponses personnalisés vous permettent de spécifier des en-têtes supplémentaires pour les requêtes et les réponses HTTP(S). En fonction des informations détectées par l'équilibreur de charge, ces en-têtes peuvent inclure les informations suivantes :

• Latence vis-à-vis du client
• Emplacement géographique de l'adresse IP du client
• Paramètres de la connexion TLS

Par défaut, aucun en-tête personnalisé n'est ajouté à la requête envoyée/reçue vers/depuis vos services de backend. Vous devez configurer explicitement les en-têtes personnalisés à l'aide d'un filtre dans votre ressource HTTPRoute.

Vous pouvez configurer des en-têtes personnalisés en ajoutant une section de filtre dans les règles de la ressource HTTPRoute en procédant comme suit :

Configurer des en-têtes de requête personnalisés

Créez un fichier manifeste HTTPRoute avec un filtre RequestHeaderModifier et enregistrez-le sous le nom http-route-request.yaml:.

  apiVersion: gateway.networking.k8s.io/v1beta1
  kind: HTTPRoute
  metadata:
    name: store
  spec:
    <...>
    rules:
        filters:
          - type: RequestHeaderModifier
            requestHeaderModifier:
              <...>

Appliquez le fichier manifeste :

  kubectl apply -f http-route-request.yaml

Configurer des en-têtes de réponse personnalisés

Créez un fichier manifeste HTTPRoute avec un filtre ResponseHeaderModifier et enregistrez-le sous le nom http-route-response.yaml:.

apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: store
spec:
  <...>
  rules:
      filters:
        - type: ResponseHeaderModifier
          responseHeaderModifier:
            <...>

Appliquez le fichier manifeste :

  kubectl apply -f http-route-response.yaml

Remarque : GKE Gateway controller met en œuvre des en-têtes personnalisés dans le mappage d'URL et non dans le service de backend.

Vous pouvez ajouter, définir et supprimer des en-têtes comme décrit dans la mise en œuvre de l'API Gateway. Vous pouvez configurer votre ressource HTTPRoute avec un en-tête personnalisé à l'aide des variables compatibles avec Google Cloud.

Exemple 1 :

Pour configurer une ressource HTTPRoute qui ajoute des informations sur la localisation des clients à la requête HTTP avant de l'envoyer au service de backend, créez un fichier manifeste HTTPRoute et nommez-le external-http-request.yaml :

  apiVersion: gateway.networking.k8s.io/v1beta1
  kind: HTTPRoute
  metadata:
    name: store
  spec:
    parentRefs:
      - kind: Gateway
        name: external-http
    hostnames:
    - store.example.com
    rules:
      - matches:
        - path:
            type: PathPrefix
            value: /fr
        filters:
          - type: RequestHeaderModifier
            requestHeaderModifier:
              add:
                - name: X-Client-Geo-Location
                  value: "{client_region},{client_city}"
        backendRefs:
          - name: store-french
            port: 8080

Par exemple, pour les clients situés à Strasbourg, en France, la ressource Gateway ajoute un en-tête X-Client-Geo-Location:FR,Strasbourg.

Exemple 2 :

Pour configurer une ressource HTTPRoute qui ajoute un en-tête de réponse personnalisé compatible avec HTTP Strict Transport Security, créez un fichier manifeste HTTPRoute et nommez-le external-http-response.yaml :

  apiVersion: gateway.networking.k8s.io/v1beta1
  kind: HTTPRoute
  metadata:
    name: store
  spec:
    parentRefs:
      - kind: Gateway
        name: external-http
    hostnames:
    - store.example.com
    rules:
      - matches:
        - path:
            type: PathPrefix
            value: /de
        filters:
          - type: ResponseHeaderModifier
            responseHeaderModifier:
              add:
                - name: Strict-Transport-Security
                  value: max-age=63072000
        backendRefs:
          - name: store-german
            port: 8080

Vérifiez votre configuration

1. Pour vérifier votre configuration après avoir configuré les en-têtes de requête et de réponse personnalisés, procédez comme suit :

     kubectl get httproute
   

   Le résultat ressemble à ce qui suit :

     NAME    HOSTNAMES               AGE
     store   ["store.example.com"]   4d23h
   

2. Pour obtenir plus de détails, utilisez la commande describe :

     kubectl describe httproute
   

   Le résultat ressemble à ce qui suit :

     Name:         store
     Namespace:    default
     Labels:       <none>
     Annotations:  <none>
     API Version:  gateway.networking.k8s.io/v1beta1
     Kind:         HTTPRoute
     Metadata:
       Creation Timestamp:  2023-05-27T00:51:01Z
       Generation:          5
       Resource Version:    25418887
       UID:                 2e07a1b8-420b-41b4-acd1-cecbfcd39f42
     Spec:
       Hostnames:
         store.example.com
       Parent Refs:
         Group:  gateway.networking.k8s.io
         Kind:   Gateway
         Name:   external-http
       Rules:
         Backend Refs:
           Group:
           Kind:    Service
           Name:    store-v1
           Port:    8080
           Weight:  1
         Matches:
           Path:
             Type:   PathPrefix
             Value:  /
         Backend Refs:
           Group:
           Kind:    Service
           Name:    store-v2
           Port:    8080
           Weight:  1
         Matches:
           Headers:
             Name:   env
             Type:   Exact
             Value:  canary
           Path:
             Type:   PathPrefix
             Value:  /
         Backend Refs:
           Group:
           Kind:    Service
           Name:    store-german
           Port:    8080
           Weight:  1
         Filters:
           Request Header Modifier:
             Add:
               Name:   X-Client-Geo-Location
               Value:  {client_region},{client_city}
           Type:       RequestHeaderModifier
         Matches:
           Path:
             Type:   PathPrefix
             Value:  /de
     Status:
       <...>
   

État des routes

Les ressources HTTPRoute émettent des conditions et des événements pour aider les utilisateurs à comprendre si une route HTTPRoute a bien été liée à une ou plusieurs passerelles ou si elle a été refusée.

Conditions HTTPRoute

Les conditions HTTPRoute indiquent l'état de la route et des passerelles auxquelles elle est liée. Étant donné qu'une route peut être liée à plusieurs ressources Gateway, il s'agit d'une liste de ressources Gateway et des conditions individuelles entre la route et chaque ressource Gateway.

• Accepted=True indique que la route HTTPRoute est bien liée à une passerelle.
• Accepted=False indique que la route HTTPRoute a été refusée. Elle n'a pas été liée à la passerelle.

Si aucune passerelle n'est répertoriée sous l'en-tête Gateway bindings, il est possible que vos libellés HTTPRoute et vos sélecteurs de libellés de passerelle ne correspondent pas. Cela peut se produire si votre route n'est sélectionnée par aucune passerelle.

Événements HTTPRoute

Les événements HTTPRoute fournissent des détails sur l'état de la route HTTPRoute. Les événements sont regroupés pour les raisons suivantes :

• Les événements ADD sont déclenchés par l'ajout d'une ressource.
• Les événements UPDATE sont déclenchés par une ressource en cours de mise à jour.
• Les événements SYNC sont déclenchés par le rapprochement périodique.

Fusion, priorité et validation des routes

Priorité des routes

L'API Gateway définit des règles de priorité strictes pour la mise en correspondance du trafic par les routes dont les règles de routage se chevauchent. La priorité entre deux ressources HTTPRoute qui se chevauchent est la suivante :

1. Fusion de nom d'hôte : correspondance de nom d'hôte la plus longue/la plus spécifique.
2. Fusion de chemin : correspondance de chemin la plus longue/la plus spécifique.
3. Fusion d'en-tête : le plus grand nombre d'en-têtes HTTP qui correspondent.
4. Conflit : si les trois règles précédentes ne définissent pas de priorité, la priorité est transmise à la ressource HTTPRoute avec l'horodatage le plus ancien.

Fusion des routes

Pour les ressources GatewayClass gke-l7, toutes les ressources HTTPRoute d'une ressource Gateway donnée sont fusionnées dans la même ressource de mappage d'URL. La façon dont les ressources HTTPRoute sont fusionnées dépend du type de chevauchement entre les ressources HTTPRoute. La ressource HTTPRoute de l'exemple précédent peut être divisée en trois ressources HTTPRoute distinctes pour illustrer la fusion et la priorité des routes :

1. Fusion de routes : les trois ressources HTTPRoute sont associées à la même ressource Gateway internal-http. Elles sont donc fusionnées.
2. Fusion de noms d'hôte : les trois routes correspondent à store.example.com. Par conséquent, leurs règles de nom d'hôte sont fusionnées.
3. Fusion de chemin : "store-german-route" possède un chemin d'accès plus spécifique /de ; il n'est donc pas fusionné plus. "store-v1-route" et "store-v2-route" correspondent également au même chemin d'accès /*, et sont donc fusionnés sur le chemin.
4. Fusion d'en-tête : "store-v2-route" dispose d'un ensemble plus spécifique de correspondances d'en-têtes HTTP que "store-v1-route".Ils ne sont donc pas fusionnés plus.
5. Conflit : étant donné que les routes peuvent être fusionnées sur le nom d'hôte, le chemin d'accès et les en-têtes, il n'existe pas de conflit, et toutes les règles de routage s'appliquent au trafic.

La ressource HTTPRoute unique utilisée dans l'exemple précédent est équivalente à ces trois routes distinctes :

kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: store-v1-route
spec:
  parentRefs:
  - kind: Gateway
    name: internal-http
  hostnames:
  - "store.example.com"
  rules:
  - backendRefs:
    - kind: Service
      name: store-v1
      port: 8080
---
kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: store-v2-route
spec:
  parentRefs:
  - kind: Gateway
    name: internal-http
  hostnames:
  - "store.example.com"
  rules:
  - matches:
    - headers:
      - type: Exact
        name: env
        value: canary
    backendRefs:
    - kind: Service
      name: store-v2
      port: 8080
---
kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: store-german-route
spec:
  parentRefs:
  - kind: Gateway
    name: internal-http
  hostnames:
  - "store.example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /de
    backendRefs:
    - kind: Service
      name: store-german
      port: 8080

Ressources Kubernetes Gateway et Istio Gateway

Notez que l'API Kubernetes Gateway et l'API Istio disposent toutes deux d'une ressource nommée Gateway. Même si elles exécutent des fonctions similaires, elles ne sont pas identiques. Si vous utilisez Istio et l'API Gateway dans le même cluster Kubernetes, ces noms se chevauchent lors de l'utilisation de kubectl sur la ligne de commande. kubectl get gateway peut renvoyer les ressources Kubernetes Gateway et non les ressources Istio Gateway, ou inversement.

$ kubectl api-resources
NAME       SHORTNAMES   APIGROUP                       NAMESPACED   KIND
gateways   gw           networking.istio.io/v1beta1    true         Gateway
gateways   gtw          networking.k8s.io/v1beta1      true         Gateway

Si vous utilisez Istio et effectuez une mise à niveau vers GKE 1.20 et versions ultérieures, il est recommandé de commencer à utiliser le nom abrégé de la ressource Gateway ou de spécifier le groupe d'API. Le nom abrégé d'une ressource Kubernetes Gateway est gtw et le nom abrégé d'une ressource Istio Gateway est gw. Les commandes suivantes renvoient les ressources Kubernetes Gateway et Istio Gateway, respectivement.

# Kubernetes Gateway
$ kubectl get gtw
NAME                        CLASS
multi-cluster-gateway       gke-l7-global-external-managed-mc

$ kubectl get gateway.networking.x-k8s.io
NAME                        CLASS
multi-cluster-gateway       gke-l7-global-external-managed-mc

# Istio Gateway
$ kubectl get gw
NAME               AGE
bookinfo-gateway   64m

$ kubectl get gateway.networking.istio.io
NAME               AGE
bookinfo-gateway   64m

Dépannage

Sous-réseau proxy réservé manquant dans la région

Symptôme :

Le problème suivant peut se produire lorsque vous créez une ressource Gateway régionale (interne ou externe) :

generic::invalid_argument: error ensuring load balancer: Insert: Invalid value for field 'resource.target': 'regions/[REGION_NAME]/targetHttpProxies/gkegw-x5vt-default-internal-http-[ID]'. A reserved managed proxy subnetwork with purpose REGIONAL_MANAGED_PROXY is required.

Explication :

Ce message d'erreur indique qu'aucun sous-réseau proxy réservé n'existe dans la région de votre ressource Gateway.

Solution :

Pour résoudre ce problème, déployez un sous-réseau proxy réservé.

Un sous-réseau proxy réservé existe déjà dans la région avec un objectif inapproprié

Symptôme :

Le problème suivant peut se produire lorsque vous créez un sous-réseau proxy réservé pour votre ressource Gateway régionale (interne ou externe) :

ERROR: (gcloud.compute.networks.subnets.create) Could not fetch resource:
 - The resource 'projects/[PROJECT_NAME]/regions/[REGION_NAME]/subnetworks/[PROXY_ONLY_SUBNET_NAME]' already exists

Explication :

Ce message d'erreur indique que vous avez tenté de créer un sous-réseau proxy réservé régional dans une région qui en possède déjà un.

Solution :

Essayez les solutions suivantes pour résoudre ce problème :

1. Vérifiez qu'un sous-réseau proxy réservé existe déjà dans la région et qu'il remplit le bon objectif :

   1. Répertoriez vos sous-réseaux pour trouver celui qui est le sous-réseau proxy réservé dans la région :

      gcloud compute networks subnets list --regions=COMPUTE_REGION
      

      Remplacez COMPUTE_REGION par la région Compute Engine dans laquelle vous souhaitez créer votre ressource Gateway régionale.

   2. Décrivez votre sous-réseau proxy réservé dans la région pour connaître son objectif :

      gcloud compute networks subnets describe PROXY_ONLY_SUBNET \
          --region COMPUTE_REGION | grep -E 'name|purpose'
      

      Remplacez PROXY_ONLY_SUBNET par le sous-réseau proxy réservé.

   GKE Gateway n'accepte que les sous-réseaux proxy réservés REGIONAL_MANAGED_PROXY pour les ressources Gateway régionales (internes ou régionales).

2. Si le sous-réseau proxy réservé existant de la région a été créé avec un objectif INTERNAL_HTTPS_LOAD_BALANCER, migrez son objectif vers REGIONAL_MANAGED_PROXY.

Étapes suivantes

• Apprenez-en davantage sur le contrôleur Gateway.
• Apprenez à configurer des ressources Gateway à l'aide de règles.