Déployer des ressources Gateway


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.

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 ne pouvez pas spécifier un numéro de port directement dans le nom d'hôte (par exemple, web.example.com:80) pour le routage du trafic.

  • 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 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é.
  • Lors de la configuration des en-têtes de requête et de réponse personnalisés HTTPRoute, les variables 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 (les règles CORS ne sont pas compatibles 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.

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

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 :

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

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.

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 :

    Les règles de routage configurées par la ressource HTTPRoute du magasin

    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 configurées par la ressource HTTPRoute du magasin

    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 comporter 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 votre 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.

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.

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.

    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. Appliquez 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. Appliquez 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. Appliquez 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. Appliquez 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. Appliquez 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. Appliquez 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. Appliquez 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. Appliquez 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. Appliquez 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 section 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, ce 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 réécrire des URL pour rendre les URL plus conviviales, améliorer le SEO ou rediriger les internautes 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ête et de réponse 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
    

    Vous pouvez ajouter, définir et supprimer des en-têtes comme décrit dans la section Implémentation 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