Configurer des ressources Gateway à l'aide de règles

Autopilot Standard

---

Cette page explique comment configurer l'équilibreur de charge créé par Google Kubernetes Engine (GKE) lorsque vous déployez une ressource Gateway dans un cluster GKE.

Lorsque vous déployez une ressource Gateway, la configuration de GatewayClass détermine l'équilibreur de charge créé par GKE. Cet équilibreur de charge géré est préconfiguré avec des paramètres par défaut que vous pouvez modifier à l'aide d'une règle.

Vous pouvez personnaliser les ressources Gateway pour les adapter aux contraintes de votre infrastructure ou de votre application, en associant des règles à des ressources Gateway, Service ou ServiceImport. Une fois que vous avez appliqué ou modifié une règle, vous n'avez pas besoin de supprimer ni de recréer vos ressources Gateway, Route ou Service. La règle est traitée par le contrôleur Gateway et la ressource d'équilibreur de charge sous-jacente est (re)configurée conformément à la (nouvelle) règle.

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

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

Conditions requises pour le contrôleur GKE Gateway

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

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

Restrictions et limitations

Outre les restrictions et limitations de GKE Gateway Controller, les limites suivantes concernent spécifiquement les règles appliquées à des ressources Gateway :

• Les ressources GCPGatewayPolicy ne peuvent être associées qu'à un gateway.networking.k8s.io Gateway.

• Les ressources GCPGatewayPolicy doivent exister dans le même espace de noms que la cible Gateway.

• Lorsque vous utilisez une seule ressource Gateway de cluster, les ressources GCPBackendPolicy et HealthCheckPolicy doivent faire référence à une ressource Service.

• Lorsque vous utilisez une ressource Gateway multicluster, les ressources GCPBackendPolicy et HealthCheckPolicy doivent faire référence à une ressource ServiceImport.

• Un seul GCPGatewayPolicy peut être associé à un service à la fois. Lorsque deux règles GCPGatewayPolicy sont créées et ciblent la même règle Service ou ServiceImport, la règle la plus ancienne est prioritaire et la deuxième ne peut pas être associée.

• Les règles hiérarchiques ne sont pas compatibles avec GKE Gateway.

• Les ressources HealthCheckPolicy et GCPBackendPolicy doivent exister dans le même espace de noms que la ressource cible Service ou ServiceImport.

• Les ressources GCPBackendPolicy et HealthCheckPolicy sont structurées de manière à ne pouvoir référencer qu'un seul service de backend.

• GCPBackendPolicy n'est pas compatible avec les options HEADER_FIELD ou HTTP_COOKIE pour l'affinité de session.

Configurer l'accès mondial pour votre ressource Gateway interne régionale

Cette section décrit une fonctionnalité disponible sur les clusters GKE exécutant la version 1.24 ou ultérieure.

Pour activer l'accès mondial avec votre ressource Gateway interne, associez une règle à la ressource Gateway.

Le fichier manifeste GCPGatewayPolicy suivant active la ressource Gateway interne régionale pour un accès mondial :

apiVersion: networking.gke.io/v1
kind: GCPGatewayPolicy
metadata:
  name: my-gateway-policy
  namespace: default
spec:
  default:
    allowGlobalAccess: true
  targetRef:
    group: gateway.networking.k8s.io
    kind: Gateway
    name: my-gateway

Remarque : La mise à niveau d'une ressource Gateway interne existante en ajoutant un accès mondial recrée la règle de transfert de votre équilibreur de charge interne régional. Cette mise à niveau supprime, puis recrée des équilibreurs de charge Google Cloud, ce qui entraîne une indisponibilité pouvant aller jusqu'à 15 minutes. Nous vous recommandons d'effectuer cette opération pendant un intervalle de maintenance afin d'éviter tout temps d'arrêt de l'application.

Configurer des règles SSL pour sécuriser le trafic client vers équilibreur de charge

Cette section décrit une fonctionnalité disponible sur les clusters GKE exécutant la version 1.24 ou ultérieure.

Pour sécuriser le trafic client vers équilibreur de charge, configurez la règle SSL en ajoutant son nom à GCPGatewayPolicy. Par défaut, aucune règle SSL n'est définie ni associée à la ressource Gateway.

Assurez-vous de créer une règle SSL avant de référencer la règle dans GCPGatewayPolicy.

Remarque : Si vous utilisez une ressource Gateway régionale, assurez-vous de créer une règle SSL régionale.

Le fichier manifeste GCPGatewayPolicy suivant spécifie une règle de sécurité nommée gke-gateway-ssl-policy :

apiVersion: networking.gke.io/v1
kind: GCPGatewayPolicy
metadata:
  name: my-gateway-policy
  namespace: team1
spec:
  default:
    sslPolicy: gke-gateway-ssl-policy
  targetRef:
    group: gateway.networking.k8s.io
    kind: Gateway
    name: my-gateway

Configurer les vérifications d'état

Cette section décrit une fonctionnalité disponible sur les clusters GKE exécutant la version 1.24 ou ultérieure.

Vous pouvez utiliser une règle HealthCheckPolicy pour contrôler les paramètres de vérification de l'état de l'équilibreur de charge. Chaque type de vérification d'état (http, https, grpc et http2) possède des paramètres que vous pouvez définir. Google Cloud crée une vérification d'état unique pour chaque service de backend et pour chaque service GKE.

Pour que votre équilibreur de charge fonctionne normalement, vous devrez peut-être configurer une HealthCheckPolicy personnalisée si le chemin d'accès de la vérification d'état n'est pas le chemin standard "/". Cette configuration est également nécessaire si le chemin d'accès nécessite des en-têtes spéciaux ou si vous devez ajuster les paramètres de vérification d'état. Par exemple, si le chemin de requête par défaut est "/", mais que votre service n'est pas accessible via ce chemin de requête et utilise plutôt "/health" pour signaler son état, vous devez configurer requestPath dans votre HealthCheckPolicy en conséquence.

Le fichier manifeste HealthCheckPolicy suivant affiche tous les champs disponibles lors de la configuration d'une règle de vérification de l'état :

Service

apiVersion: networking.gke.io/v1
kind: HealthCheckPolicy
metadata:
  name: lb-healthcheck
  namespace: lb-service-namespace
spec:
  default:
    checkIntervalSec: INTERVAL
    timeoutSec: TIMEOUT
    healthyThreshold: HEALTHY_THRESHOLD
    unhealthyThreshold: UNHEALTHY_THRESHOLD
    logConfig:
      enabled: ENABLED
    config:
      type: PROTOCOL
      httpHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        portName: PORT_NAME
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      httpsHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        portName: PORT_NAME
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      grpcHealthCheck:
        grpcServiceName: GRPC_SERVICE_NAME
        portSpecification: PORT_SPECIFICATION
        port: PORT
        portName: PORT_NAME
      http2HealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        portName: PORT_NAME
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
  targetRef:
    group: ""
    kind: Service
    name: lb-service

Service multicluster

apiVersion: networking.gke.io/v1
kind: HealthCheckPolicy
metadata:
  name: lb-healthcheck
  namespace: lb-service-namespace
spec:
  default:
    checkIntervalSec: INTERVAL
    timeoutSec: TIMEOUT
    healthyThreshold: HEALTHY_THRESHOLD
    unhealthyThreshold: UNHEALTHY_THRESHOLD
    logConfig:
      enabled: ENABLED
    config:
      type: PROTOCOL
      httpHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        portName: PORT_NAME
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      httpsHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        portName: PORT_NAME
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      grpcHealthCheck:
        grpcServiceName: GRPC_SERVICE_NAME
        portSpecification: PORT_SPECIFICATION
        port: PORT
        portName: PORT_NAME
      http2HealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        portName: PORT_NAME
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

Remplacez les éléments suivants :

• INTERVAL : spécifie l'intervalle entre deux tests, en secondes, pour chaque vérificateur d'état. Il s'agit du temps écoulé entre le début du test d'un vérificateur et le début du test suivant. Si vous omettez ce paramètre, la valeur Google Cloud par défaut est de 15 secondes si aucune HealthCheckPolicy n'est spécifiée, et de 5 secondes lorsqu'une HealthCheckPolicy est spécifiée sans valeur checkIntervalSec. Pour en savoir plus, consultez la section Vérifications multiples et fréquence de vérification.
• TIMEOUT : spécifie la durée pendant laquelle Google Cloud attend une réponse à une vérification. La valeur de TIMEOUT doit être inférieure ou égale à celle de INTERVAL. Cette valeur est exprimée en secondes. Chaque vérificateur requiert un code de réponse HTTP 200 (OK) avant la fin du délai avant expiration du vérificateur.
• HEALTHY_THRESHOLDet UNHEALTHY_THRESHOLD : spécifie le nombre de tentatives de connexion séquentielles qui doivent réussir ou échouer pour au moins un vérificateur, pour modifier l'état de fonctionnement allant de "opérationnel" à "non opérationnel", ou "non opérationnel" à "opérationnel". Si vous omettez l'un de ces paramètres, la valeur par défaut de Google Cloud est 2.
• PROTOCOL : spécifie un protocole utilisé par les systèmes de vérification pour la vérification de l'état. Pour plus d'informations, consultez les sections Critères de réussite pour HTTP, HTTPS et HTTP/2 et Critères de réussite pour gRPC. Ce paramètre est obligatoire.
• ENABLED : indique si la journalisation est activée ou désactivée.
• PORT_SPECIFICATION : indique si la vérification d'état utilise un port fixe (USE_FIXED_PORT), un port nommé (USE_NAMED_PORT) ou un port de diffusion (USE_SERVING_PORT). Si cette option n'est pas spécifiée, la vérification de l'état suit le comportement spécifié dans les champs port et portName. Si vous ne spécifiez pas port ni portName, la valeur par défaut de ce champ est USE_SERVING_PORT.
• PORT : une ressource HealthCheckPolicy n'accepte que la spécification du port de vérification de l'état de l'équilibreur de charge à l'aide d'un numéro de port. Si vous omettez ce paramètre, la valeur par défaut de Google Cloud est 80. Étant donné que l'équilibreur de charge envoie directement des vérifications à l'adresse IP du pod, vous devez sélectionner un port correspondant à un containerPort de pods actifs, même si containerPort est référencé par un targetPort du service. Vous n'êtes pas limité à l'élément containerPorts référencé par l'élément targetPort d'un service.
• PORT_NAME : spécifie le nom du port tel que défini dans InstanceGroup.NamedPort.name. Si port et portName sont tous deux définis, Google Cloud prend d'abord la valeur port.
• HOST : valeur de l'en-tête d'hôte dans la requête de vérification d'état. Cette valeur utilise la définition RFC 1123 d'un nom d'hôte, à l'exception du fait que les adresses IP numériques ne sont pas acceptées. Si elle n'est pas spécifiée ou qu'elle est vide, cette valeur est définie par défaut sur l'adresse IP de la vérification d'état.
• REQUEST_PATH : spécifie le chemin de requête de vérification d'état. Si aucune valeur n'est spécifiée ou qu'elle est vide, la valeur par défaut est /.
• RESPONSE : spécifie les octets à mettre en correspondance avec le début des données de réponse. Si cette valeur n'est pas spécifiée ou est vide, GKE interprète toute réponse comme étant opérationnelle. Les données de réponse ne peuvent être qu'ASCII.
• PROXY_HEADER : spécifie le type d'en-tête du proxy. Vous pouvez utiliser NONE ou PROXY_V1. La valeur par défaut est NONE.
• GRPC_SERVICE_NAME : nom facultatif du service gRPC. Omettez ce champ pour spécifier tous les services.

Pour en savoir plus sur les champs HealthCheckPolicy, consultez la documentation de référence sur healthChecks.

Configurer une règle de sécurité de backend Google Cloud Armor pour sécuriser vos services de backend

Cette section décrit une fonctionnalité disponible sur les clusters GKE exécutant la version 1.24 ou ultérieure.

Remarque : Google Cloud a remplacé la règle LbPolicy par la règle GCPBackendPolicy. La règle LbPolicy est toujours acceptée, mais sans attributs supplémentaires.

Configurez la règle de sécurité de backend Google Cloud Armor en ajoutant son nom à GCPBackendPolicy afin de sécuriser vos services de backend. Par défaut, aucune règle de sécurité de backend Google Cloud Armor n'est définie ni associée à la ressource Gateway.

Assurez-vous de créer une règle de sécurité de backend Google Cloud Armor avant de référencer la règle dans GCPBackendPolicy.

Le fichier manifeste GCPBackendPolicy suivant spécifie une règle de sécurité de backend nommée example-security-policy :

Service

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    securityPolicy: example-security-policy
  targetRef:
    group: ""
    kind: Service
    name: lb-service

Service multicluster

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    securityPolicy: example-security-policy
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

Configurer IAP

Cette section décrit une fonctionnalité disponible sur les clusters GKE exécutant la version 1.24 ou ultérieure.

Identity-Aware Proxy (IAP) applique des stratégies de contrôle des accès aux services de backend associés à une ressource HTTPRoute. Avec cette mesure d'application, seuls les utilisateurs ou les applications authentifiés disposant du rôle IAM (Identity and Access Management) approprié peuvent accéder à ces services de backend.

Par défaut, aucun service IAP n'est appliqué à vos services de backend. Vous devez configurer explicitement IAP dans un objet GCPBackendPolicy.

Pour configurer IAP avec Gateway, procédez comme suit :

1. Activer IAP pour GKE. Ne configurez pas le backend (Configurer BackendConfig), car BackendConfig n'est valide que dans le cas d'un déploiement Ingress.

2. Créez un secret pour votre IAP :

   1. Dans la console Google Cloud, accédez à la page Identifiants.

      Accéder à "Identifiants"

   2. Cliquez sur le nom du client et téléchargez le fichier client OAuth.

   3. À partir du fichier client OAuth, copiez le secret OAuth dans le presse-papiers.

   4. Créez un fichier appelé iap-secret.txt :

   5. Collez le secret OAuth dans le fichier iap-secret.txt à l'aide de la commande suivante :

      echo -n CLIENT_SECRET > iap-secret.txt
      kubectl create secret generic SECRET_NAME --from-file=key=iap-secret.txt
      

3. Pour spécifier une règle IAP faisant référence à un secret, procédez comme suit :

   1. Créez le fichier manifeste GCPBackendPolicy suivant, en remplaçant respectivement SECRET_NAME et CLIENT_ID. Enregistrez le manifeste sous le nom backend-policy.yaml :

      Service

      apiVersion: networking.gke.io/v1
      kind: GCPBackendPolicy
      metadata:
        name: backend-policy
      spec:
        default:
          iap:
            enabled: true
            oauth2ClientSecret:
              name: SECRET_NAME
            clientID: CLIENT_ID
        targetRef:
          group: ""
          kind: Service
          name: lb-service
      

      Service multicluster

      apiVersion: networking.gke.io/v1
      kind: GCPBackendPolicy
      metadata:
        name: backend-policy
      spec:
        default:
          iap:
            enabled: true
            oauth2ClientSecret:
              name: SECRET_NAME
            clientID: CLIENT_ID
        targetRef:
          group: net.gke.io
          kind: ServiceImport
          name: lb-service
      

   2. Appliquez le fichier manifeste backend-policy.yaml :

      kubectl apply -f backend-policy.yaml
      

4. Vérifiez votre configuration :

   1. Vérifiez que la stratégie a été appliquée après avoir créé le GCPBackendPolicy avec IAP :

      kubectl get gcpbackendpolicy
      

      Le résultat ressemble à ce qui suit :

      NAME             AGE
      backend-policy   45m
      

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

      kubectl describe gcpbackendpolicy
      

      Le résultat ressemble à ce qui suit :

      Name:         backend-policy
      Namespace:    default
      Labels:       <none>
      Annotations:  <none>
      API Version:  networking.gke.io/v1
      Kind:         GCPBackendPolicy
      Metadata:
        Creation Timestamp:  2023-05-27T06:45:32Z
        Generation:          2
        Resource Version:    19780077
        UID:                 f4f60a3b-4bb2-4e12-8748-d3b310d9c8e5
      Spec:
        Default:
          Iap:
            Client ID:  441323991697-luotsrnpboij65ebfr13hlcpm5a4heke.apps.googleusercontent.com
            Enabled:    true
            oauth2ClientSecret:
              Name:  my-iap-secret
        Target Ref:
          Group:
          Kind:   Service
          Name:   lb-service
      Status:
        Conditions:
          Last Transition Time:  2023-05-27T06:48:25Z
          Message:
          Reason:                Attached
          Status:                True
          Type:                  Attached
      Events:
        Type     Reason  Age                 From                   Message
        ----     ------  ----                ----                   -------
        Normal   ADD     46m                 sc-gateway-controller  default/backend-policy
        Normal   SYNC    44s (x15 over 43m)  sc-gateway-controller  Application of GCPGatewayPolicy "default/backend-policy" was a success
      

Configurer le délai avant expiration du service de backend

Cette section décrit une fonctionnalité disponible sur les clusters GKE exécutant la version 1.24 ou ultérieure.

Remarque : Google Cloud a remplacé la règle LbPolicy par la règle GCPBackendPolicy. La règle LbPolicy est toujours acceptée, mais sans attributs supplémentaires.

Le fichier manifeste GCPBackendPolicy suivant spécifie un délai avant expiration du service de backend de 40 secondes. La valeur par défaut du champ timeoutSec est de 30 secondes.

Service

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    timeoutSec: 40
  targetRef:
    group: ""
    kind: Service
    name: lb-service

Service multicluster

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    timeoutSec: 40
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

Configurer l'affinité de session

Cette section décrit une fonctionnalité disponible sur les clusters GKE exécutant la version 1.24 ou ultérieure.

Remarque : Google Cloud a remplacé la règle LbPolicy par la règle GCPBackendPolicy. La règle LbPolicy est toujours acceptée, mais sans attributs supplémentaires.

Vous pouvez configurer l'affinité de session en fonction des critères suivants :

• Adresse IP du client
• Cookie généré

Lorsque vous configurez l'affinité de session pour votre service, le paramètre localityLbPolicy de la passerelle est défini sur MAGLEV.

Lorsque vous supprimez une configuration d'affinité de session de GCPBackendPolicy, la passerelle rétablit la valeur par défaut du paramètre localityLbPolicy, ROUND_ROBIN.

Avertissement : Cette valeur est définie en mode silencieux sur le service de backend géré par GKE (associé à l'équilibreur de charge) et n'est pas reflétée dans le résultat d'une commande de gcloud CLI, dans l'interface utilisateur ou avec Terraform.

Le fichier manifeste GCPBackendPolicy suivant spécifie une affinité de session basée sur l'adresse IP du client :

Service

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    sessionAffinity:
      type: CLIENT_IP
  targetRef:
    group: ""
    kind: Service
    name: lb-service

Service multicluster

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    sessionAffinity:
      type: CLIENT_IP
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

Le fichier manifeste GCPBackendPolicy suivant spécifie une affinité de session basée sur un cookie généré et configure la valeur TTL des cookies sur 50 secondes :

Service

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    sessionAffinity:
      type: GENERATED_COOKIE
      cookieTtlSec: 50
  targetRef:
    group: ""
    kind: Service
    name: lb-service

Service multicluster

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    sessionAffinity:
      type: GENERATED_COOKIE
      cookieTtlSec: 50
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

Vous pouvez utiliser les valeurs suivantes pour le champ sessionAffinity.type :

• CLIENT_IP
• GENERATED_COOKIE
• NONE

Configurer le délai avant expiration du drainage de connexion

Cette section décrit une fonctionnalité disponible sur les clusters GKE exécutant la version 1.24 ou ultérieure.

Remarque : Google Cloud a remplacé la règle LbPolicy par la règle GCPBackendPolicy. La règle LbPolicy est toujours acceptée, mais sans attributs supplémentaires.

Vous pouvez configurer le délai avant expiration du drainage de connexion à l'aide de GCPBackendPolicy. Le délai avant expiration du drainage de connexion est le délai d'attente, exprimé en secondes, pour le drainage des connexions. La durée de ce délai peut être comprise entre 0 et 3 600 secondes. La valeur par défaut est 0, ce qui correspond à la désactivation du drainage de connexion.

Le fichier manifeste GCPBackendPolicy suivant spécifie un délai avant expiration du drainage de connexion de 60 secondes :

Service

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    connectionDraining:
      drainingTimeoutSec: 60
  targetRef:
    group: ""
    kind: Service
    name: lb-service

Service multicluster

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    connectionDraining:
      drainingTimeoutSec: 60
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

Pendant la durée spécifiée pour le délai d'expiration, GKE attend la fin des requêtes existantes adressées au backend en cours de suppression. L'équilibreur de charge n'envoie plus de nouvelles requêtes au backend en cours de suppression. Une fois le délai écoulé, GKE ferme toutes les connexions restantes au backend.

Journalisation des accès HTTP

Cette section décrit une fonctionnalité disponible sur les clusters GKE exécutant la version 1.24 ou ultérieure.

Remarque : Google Cloud a remplacé la règle LbPolicy par la règle GCPBackendPolicy. La règle LbPolicy est toujours acceptée, mais sans attributs supplémentaires.

Par défaut :

• Le contrôleur Gateway consigne toutes les requêtes HTTP des clients dans Cloud Logging.
• Le taux d'échantillonnage est de 1 000 000, ce qui signifie que toutes les requêtes sont consignées.

Vous pouvez désactiver la journalisation des accès sur votre ressource Gateway avec GCPBackendPolicy de trois manières :

• Vous pouvez laisser GCPBackendPolicy sans section logging.
• Vous pouvez définir logging.enabled sur false.
• Vous pouvez définir logging.enabled sur true et logging.sampleRate sur 0.

Vous pouvez également configurer le taux d'échantillonnage des journaux d'accès.

Le fichier manifeste GCPBackendPolicy suivant modifie le taux d'échantillonnage par défaut de la journalisation des accès et le définit sur 50 % des requêtes HTTP pour une ressource Service donnée :

Service

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    logging:
      enabled: true
      sampleRate: 500000
  targetRef:
    group: ""
    kind: Service
    name: lb-service

Service multicluster

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    logging:
      enabled: true
      sampleRate: 500000
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

Ce fichier manifeste contient les champs suivants :

• enable: true : active explicitement la journalisation des accès. Les journaux sont disponibles dans Logging.
• sampleRate: 500000 : indique que 50 % des paquets sont enregistrés. Vous pouvez utiliser une valeur comprise entre 0 et 1 000 000. GKE convertit cette valeur en valeur à virgule flottante comprise dans la plage [0, 1] en divisant cette valeur par 1 000 000. Ce champ n'est pertinent que si enable est défini sur true. sampleRate est un champ facultatif, mais s'il est configuré, enable: true doit également être défini. Si enable est défini sur true et que sampleRate n'est pas fourni, GKE définit enable sur false.

Dépannage

Plusieurs GCPBackendPolicy associées au même Service

Symptôme :

La condition d'état suivante peut se produire lorsque vous associez une GCPBackendPolicy à Service ou ServiceImport:

status:
  conditions:
    - lastTransitionTime: "2023-09-26T20:18:03Z"
      message: conflicted with GCPBackendPolicy "[POLICY_NAME]" of higher precedence, hence not applied
      reason: Conflicted
      status: "False"
      type: Attached

Explication :

Cette condition d'état indique que vous essayez d'appliquer une seconde GCPBackendPolicy à une Service ou à une ServiceImport qui est déjà associée à une GCPBackendPolicy.

Plusieurs GCPBackendPolicy associés au même Service ou ServiceImport ne sont pas compatibles avec GKE Gateway. Pour en savoir plus, consultez la section Restrictions et limitations.

Solution :

Configurez un seul fichier GCPBackendPolicy qui inclut toutes les configurations personnalisées et associez-le à votre Service ou ServiceImport.

Étapes suivantes

• Apprenez-en davantage sur le contrôleur Gateway.
• Apprenez à référencer une ressource Gateway à partir d'une ressource.
• Consultez la documentation de référence de l'API Policy Types.
• Consultez les définitions de type d'API.