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

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, le contrôleur Gateway la traite et reconfigure automatiquement la ressource d'équilibreur de charge sous-jacente. Cela vous évite de supprimer ni de recréer les ressources Gateway, Route ou Service.

Vous pouvez également utiliser une BackendTLSPolicy pour configurer les paramètres TLS authentifiés du backend afin de vérifier l'identité des backends auxquels la passerelle se connecte. Pour en savoir plus, consultez Configurer le protocole TLS du backend.

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

• Activez l'API Google Kubernetes Engine.
Activer l'API Google Kubernetes Engine
• Pour utiliser Google Cloud CLI pour cette tâche, installez puis initialisez gcloud CLI. Si vous avez déjà installé la gcloud CLI, obtenez la dernière version en exécutant la commande gcloud components update. Il est possible que les versions antérieures de la gcloud CLI ne permettent pas d'exécuter les commandes de ce document.

• Assurez-vous de disposer d'un cluster Autopilot ou Standard existant. Pour créer un cluster, consultez la page Créer un cluster Autopilot.

Conditions requises pour le contrôleur GKE Gateway

• L'API Gateway n'est compatible qu'avec les clusters de VPC natif.
• Si vous utilisez les GatewayClasses régionales ou interrégionales, 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 du contrôleur GKE Gateway, les limites suivantes s'appliquent spécifiquement aux règles appliquées aux ressources Gateway :

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

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

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

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

• Un seul GCPBackendPolicy peut être associé à un service à la fois. Lorsque deux règles GCPBackendPolicy sont créées et ciblent le même 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 Service ou ServiceImport cible.

• 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. Pour l'affinité de session HEADER_FIELD ou HTTP_COOKIE, utilisez la ressource GCPTrafficDistributionPolicy.

• N'utilisez pas le même service de backend pour des passerelles de différents types GatewayClass (par exemple, global ou régional, interne ou externe, géré ou classique) si ces passerelles nécessitent des configurations incompatibles. Par exemple, une GCPBackendPolicy configurée avec des fonctionnalités non compatibles avec une GatewayClass "Classic" ne peut pas être appliquée à un service également utilisé par une passerelle "Classic". Pour garantir une configuration correcte, créez un service distinct pour chaque passerelle nécessitant des paramètres de règles différents.

• L'affinité de session configurée à l'aide d'une GCPTrafficDistributionPolicy n'est compatible qu'avec les passerelles à cluster unique.

• L'affinité de session GCPTrafficDistributionPolicy n'est pas compatible avec les ressources InferencePool, car elles utilisent des algorithmes d'équilibrage de charge de localité dédiés.

• GCPTrafficDistributionPolicy n'est pas compatible avec la configuration de l'affinité de session ni des règles d'équilibrage de charge de la localité pour l'équilibreur de charge d'application classique.

• Lorsque vous utilisez une passerelle à cluster unique, les ressources GCPBackendPolicy et HealthCheckPolicy doivent faire référence à une ressource Service ou InferencePool.

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

• Une seule règle GCPBackendPolicy peut être associée à une ressource cible (Service, ServiceImport, InferencePool ou GCPInferencePoolImport) à la fois. Lorsque plusieurs ressources GCPBackendPolicy sont créées et ciblent la même ressource, la règle la plus ancienne est prioritaire et la plus récente ne peut pas être associée.

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

• Les ressources GCPBackendPolicy et HealthCheckPolicy ne peuvent cibler qu'une seule ressource (telle qu'un service ou un InferencePool).

Bonne pratique : Créez un service distinct pour chaque passerelle en utilisant une GatewayClass différente afin d'assurer la compatibilité entre les règles du service et le type d'équilibreur de charge.

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:
    # Enable global access for the regional internal Application Load Balancer.
    allowGlobalAccess: true
  targetRef:
    group: gateway.networking.k8s.io
    kind: Gateway
    name: my-gateway

Configurer la région de votre passerelle multicluster

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

Si votre parc comporte des clusters dans plusieurs régions, vous devrez peut-être déployer des passerelles régionales dans différentes régions pour divers cas d'utilisation, par exemple la redondance interrégionale, la faible latence et la souveraineté des données. Dans votre cluster de configuration de passerelle multicluster, vous pouvez spécifier la région dans laquelle vous souhaitez déployer les passerelles régionales. Si vous ne spécifiez pas de région, la région par défaut est celle du cluster de configuration.

Pour configurer une région pour votre passerelle multicluster, utilisez le champ region dans GCPGatewayPolicy. Dans l'exemple suivant, la passerelle est configurée dans la région us-central1 :

apiVersion: networking.gke.io/v1
kind: GCPGatewayPolicy
metadata:
  name: my-gateway-policy
  namespace: default
spec:
  default:
    region: us-central1
  targetRef:
    group: gateway.networking.k8s.io
    kind: Gateway
    name: my-regional-gateway

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 la ressource GCPGatewayPolicy.

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.

Par défaut, pour les services de backend qui utilisent les protocoles d'application HTTP ou kubernetes.io/h2c, la vérification de l'état est de type HTTP. Pour le protocole HTTPS, la vérification d'état par défaut est de type HTTPS. Pour le protocole HTTP2, la vérification d'état par défaut est de type HTTP2.

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 de l'état'état (http, https, grpc, http2 et tcp) possède des paramètres que vous pouvez définir. Cloud de Confiance crée une vérification de l'état unique pour chaque service de backend pour chaque service GKE.

Pour que votre équilibreur de charge fonctionne normalement, vous devrez peut-être configurer une règle HealthCheckPolicy personnalisée si le chemin d'accès de la vérification de l'état 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 de l'état 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 de vérification de l'état suivant affiche tous les champs disponibles lors de la configuration d'une règle de vérification de l'état :

# Health check configuration for the load balancer. For more information
# about these fields, see https://cloud.google.com/compute/docs/reference/rest/v1/healthChecks.
apiVersion: networking.gke.io/v1
kind: HealthCheckPolicy
metadata:
  name: lb-healthcheck
  namespace: lb-service-namespace
spec:
  default:
    checkIntervalSec: INTERVAL  # The default value is 15 seconds.
    timeoutSec: TIMEOUT
    healthyThreshold: HEALTHY_THRESHOLD
    unhealthyThreshold: UNHEALTHY_THRESHOLD
    logConfig:
      enabled: true
    config:
      type: PROTOCOL
      httpHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      httpsHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      grpcHealthCheck:
        grpcServiceName: GRPC_SERVICE_NAME
        portSpecification: PORT_SPECIFICATION
        port: PORT
      http2HealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      tcpHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        portName: PORT_NAME
        request: REQUEST
        response: RESPONSE
        proxyHeader: PROXY_HEADER
  # Attach to a Service in the cluster.
  targetRef:
    group: ""
    kind: Service
    name: lb-service

apiVersion: networking.gke.io/v1
kind: HealthCheckPolicy
metadata:
  name: lb-healthcheck
  namespace: lb-service-namespace
spec:
  # The default and config fields control the health check configuration for the
  # load balancer. For more information about these fields, see
  # https://cloud.google.com/compute/docs/reference/rest/v1/healthChecks.
  default:
    checkIntervalSec: INTERVAL
    timeoutSec: TIMEOUT
    healthyThreshold: HEALTHY_THRESHOLD
    unhealthyThreshold: UNHEALTHY_THRESHOLD
    logConfig:
      enabled: ENABLED
    config:
      type: PROTOCOL
      httpHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      httpsHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      grpcHealthCheck:
        grpcServiceName: GRPC_SERVICE_NAME
        portSpecification: PORT_SPECIFICATION
        port: PORT
      http2HealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      tcpHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        portName: PORT_NAME
        request: REQUEST
        response: RESPONSE
        proxyHeader: PROXY_HEADER
  # Attach to a multi-cluster Service by referencing the ServiceImport.
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

apiVersion: networking.gke.io/v1
kind: HealthCheckPolicy
metadata:
  name: lb-healthcheck
  namespace: lb-service-namespace
spec:
  default:
    checkIntervalSec: INTERVAL  # The default value is 15 seconds.
    timeoutSec: TIMEOUT
    healthyThreshold: HEALTHY_THRESHOLD
    unhealthyThreshold: UNHEALTHY_THRESHOLD
    logConfig:
      enabled: true
    config:
      type: PROTOCOL
      httpHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      httpsHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      grpcHealthCheck:
        grpcServiceName: GRPC_SERVICE_NAME
        portSpecification: PORT_SPECIFICATION
        port: PORT
      http2HealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      tcpHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        portName: PORT_NAME
        request: REQUEST
        response: RESPONSE
        proxyHeader: PROXY_HEADER
  # Attach to an InferencePool in the cluster.
  targetRef:
    group: inference.networking.k8s.io
    kind: InferencePool
    name: my-inference-pool

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: true
    config:
      type: PROTOCOL
      httpHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      httpsHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      grpcHealthCheck:
        grpcServiceName: GRPC_SERVICE_NAME
        portSpecification: PORT_SPECIFICATION
        port: PORT
      http2HealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      tcpHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        portName: PORT_NAME
        request: REQUEST
        response: RESPONSE
        proxyHeader: PROXY_HEADER
  # Attach to a multi-cluster InferencePool.
  targetRef:
    group: networking.gke.io
    kind: GCPInferencePoolImport
    name: my-inference-pool-import

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 par défaut de Cloud de Confiance 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 Vérifications multiples et fréquence de vérification.
• TIMEOUT : spécifie la durée pendant laquelleCloud de Confiance 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 Cloud de Confiance est 2.
• PROTOCOL : spécifie un protocole utilisé par les systèmes de vérification pour la vérification de l'état. Pour en savoir plus, consultez les sections Critères de réussite pour HTTP, HTTPS et HTTP/2, Critères de réussite pour gRPC et Critères de réussite pour TCP. Ce paramètre est obligatoire.
• ENABLED : indique si la journalisation est activée ou désactivée.
• PORT_SPECIFICATION : indique si la vérification de l'é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 le champ port. Si port n'est pas spécifié, 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 Cloud de Confiance 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.
• 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 : spécifie les données d'application à envoyer une fois la connexion TCP établie. Si aucune valeur n'est spécifiée, la valeur par défaut est vide. Si la requête et la réponse sont vides, la connexion établie suffit à indiquer l'état. Les données de la demande ne peuvent être qu'au format ASCII.
• 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 stratégie de sécurité de backend 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.

Configurez la règle de sécurité de backend 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 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 Cloud Armor avant de référencer la règle dans votre GCPBackendPolicy. Si vous activez une passerelle régionale, vous devez créer une stratégie de sécurité de backend Cloud Armor régionale.

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

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    # Apply a Cloud Armor security policy.
    securityPolicy: example-security-policy
  # Attach to a Service in the cluster.
  targetRef:
    group: ""
    kind: Service
    name: lb-service

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    # Apply a Cloud Armor security policy.
    securityPolicy: example-security-policy
  # Attach to a multi-cluster Service by referencing the ServiceImport.
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    securityPolicy: example-security-policy
  # Attach to an InferencePool in the cluster.
  targetRef:
    group: inference.networking.k8s.io
    kind: InferencePool
    name: my-inference-pool

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    securityPolicy: example-security-policy
  # Attach to a multi-cluster InferencePool.
  targetRef:
    group: networking.gke.io
    kind: GCPInferencePoolImport
    name: my-inference-pool-import

Configurer IAP

Identity-Aware Proxy (IAP) applique des règles de contrôle des accès aux services de backend associés à une 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 une GCPBackendPolicy.

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

1. Obtenez l'ID client et le code secret du client pour votre client OAuth. Le code secret du client n'est disponible que lorsque vous créez votre client OAuth. Pour en savoir plus, consultez Gérer les clients OAuth.

2. Activez IAP pour GKE.

   Vous n'avez pas besoin de créer une ressource BackendConfig, car il s'agit d'une ressource de configuration Ingress.

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

   1. Enregistrez le fichier manifeste GCPBackendPolicy suivant sous le nom backend-policy.yaml :

      Service

      apiVersion: networking.gke.io/v1
      kind: GCPBackendPolicy
      metadata:
        name: backend-policy
      spec:
        default:
          # IAP OAuth2 settings. For more information about these fields,
          # see https://cloud.google.com/iap/docs/reference/rest/v1/IapSettings#oauth2.
          iap:
            enabled: true
            oauth2ClientSecret:
              name: CLIENT_SECRET
            clientID: CLIENT_ID
        # Attach to a Service in the cluster.
        targetRef:
          group: ""
          kind: Service
          name: SERVICE_NAME
      

      Remplacez les éléments suivants :

      • CLIENT_SECRET : code secret du client OAuth.
      • CLIENT_ID : ID client OAuth.
      • SERVICE_NAME : nom du service à cibler dans GCPBackendPolicy.

      Service multicluster

      apiVersion: networking.gke.io/v1
      kind: GCPBackendPolicy
      metadata:
        name: backend-policy
      spec:
        default:
          # IAP OAuth2 settings. For more information about these fields,
          # see https://cloud.google.com/iap/docs/reference/rest/v1/IapSettings#oauth2.
          iap:
            enabled: true
            oauth2ClientSecret:
              name: CLIENT_SECRET
            clientID: CLIENT_ID
        # Attach to a multi-cluster Service by referencing the ServiceImport.
        targetRef:
          group: net.gke.io
          kind: ServiceImport
          name: SERVICEIMPORT_NAME
      

      Remplacez les éléments suivants :

      • CLIENT_SECRET : code secret du client OAuth.
      • CLIENT_ID : ID client OAuth.
      • SERVICEIMPORT_NAME : nom de l'objet ServiceImport à cibler dans GCPBackendPolicy.

   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éé votre 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 GCPBackendPolicy "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.

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

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    # Backend service timeout, in seconds, for the load balancer. The default
    # value is 30.
    timeoutSec: 40
  # Attach to a Service in the cluster.
  targetRef:
    group: ""
    kind: Service
    name: lb-service

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    timeoutSec: 40
  # Attach to a multi-cluster Service by referencing the ServiceImport.
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    timeoutSec: 40
  # Attach to an InferencePool in the cluster.
  targetRef:
    group: inference.networking.k8s.io
    kind: InferencePool
    name: my-inference-pool

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    timeoutSec: 40
  # Attach to a multi-cluster InferencePool.
  targetRef:
    group: networking.gke.io
    kind: GCPInferencePoolImport
    name: my-inference-pool-import

Configurer la sélection du backend à l'aide de GCPBackendPolicy

Le mode d'équilibrage CUSTOM_METRICS de la GCPBackendPolicy vous permet de configurer des métriques personnalisées spécifiques qui influencent la façon dont les services de backend des équilibreurs de charge répartissent le trafic. Ce mode d'équilibrage permet d'équilibrer la charge en fonction de métriques personnalisées que vous définissez et qui sont signalées par les backends d'application.

Pour en savoir plus, consultez Gestion du trafic avec l'équilibrage de charge basé sur des métriques personnalisées.

Le tableau customMetrics[], dans le champ backends[], contient les champs suivants :

• name : spécifie le nom défini par l'utilisateur pour la métrique personnalisée.
• maxUtilization : définit l'utilisation cible ou maximale pour cette métrique. La plage valide est [0, 100].
• dryRun : champ booléen. Si la valeur est "true", les données de métrique sont envoyées à Cloud Monitoring, mais n'influencent pas les décisions d'équilibrage de charge.

Exemple

L'exemple suivant montre un fichier manifeste GCPBackendPolicy qui configure des métriques personnalisées pour la sélection du backend et le routage au niveau du point de terminaison.

1. Enregistrez le manifeste suivant sous le nom my-backend-policy.yaml :

   kind: GCPBackendPolicy
   apiVersion: networking.gke.io/v1
   metadata:
     name: my-backend-policy
     namespace: team-awesome
   spec:
     # Attach to the super-service Service.
     targetRef:
       kind: Service
       name: super-service
     default:
       backends:
       # Configuration for all locations.
       - location: "*"
         # Use the rate balancing mode for the load balancer.
         balancingMode: RATE
         # Maximum number of requests per second for each endpoint.
         maxRatePerEndpoint: 9000
       # Configuration for us-central1-a
       - location: us-central1-a
         # maxRatePerEndpoint: 9000 inherited from the * configuration.
         # Use the custom metrics balancing mode for the load balancer.
         balancingMode: CUSTOM_METRICS
         # Configure the custom metrics for the load balancer to use.
         customMetrics:
         - name: gpu-load
           maxUtilizationPercent: 100 # value ranges from 0 to 100 and maps to the floating point range [0.0, 1.0]
           dryRun: false
   

2. Appliquez le fichier manifeste à votre cluster :

   kubectl apply -f my-backend-policy.yaml
   

L'équilibreur de charge répartit le trafic en fonction du mode d'équilibrage RATE et de la métrique personnalisée gpu-load.

Configurer le routage au niveau du point de terminaison avec GCPTrafficDistributionPolicy

L'API GCPTrafficDistributionPolicy dans Google Kubernetes Engine (GKE) Gateway fournit des fonctionnalités avancées de gestion du trafic qui permettent de contrôler précisément la façon dont le trafic est distribué aux pods de votre application. Cette ressource unifiée et native de GKE simplifie la gestion des algorithmes d'équilibrage de charge et des paramètres d'affinité de session.

GCPTrafficDistributionPolicy vous permet de configurer les éléments suivants :

• Algorithmes d'équilibrage de charge : spécifiez la façon dont le trafic est réparti entre les points de terminaison d'un backend.

  • WEIGHTED_ROUND_ROBIN : lorsque vous sélectionnez cet algorithme, l'équilibreur de charge utilise des métriques personnalisées pour calculer les pondérations et distribuer le trafic en fonction de ces métriques. Le tableau customMetrics[] de la configuration GCPTrafficDistributionPolicy inclut les champs suivants :

    • name : spécifie le nom défini par l'utilisateur pour la métrique personnalisée.
    • dryRun : lorsque la valeur est true, les données de métrique sont signalées à Cloud Monitoring, mais n'ont aucune incidence sur l'équilibrage de charge.

• RING_HASH : cet algorithme est utile pour les services sensibles aux performances du cache. Il utilise un hachage cohérent pour minimiser le remappage des requêtes lorsque des pods de backend sont ajoutés ou supprimés, ce qui contribue à assurer la stabilité lors des événements de scaling. La configuration du champ minimumHashRingSize permet une répartition de la charge plus précise.

• L'affinité de session permet de s'assurer que les requêtes du même client sont systématiquement acheminées vers le même pod de backend. C'est essentiel pour les charges de travail avec état, comme les paniers d'achat d'e-commerce ou les sessions de jeu. GKE Gateway utilise GCPTrafficDistributionPolicy pour prendre en charge tous les types d'affinité de session disponibles sur les instances d'équilibreur de charge d'application Cloud de Confiance, y compris STRONG_COOKIE_AFFINITY, HEADER_FIELD, HTTP_COOKIE, GENERATED_COOKIE et CLIENT_IP.

Pour en savoir plus, consultez Gestion du trafic avec l'équilibrage de charge basé sur des métriques personnalisées.

Exemple

L'exemple suivant montre un fichier manifeste GCPTrafficDistributionPolicy qui configure le routage au niveau des points de terminaison à l'aide de l'algorithme d'équilibrage de charge WEIGHTED_ROUND_ROBIN et de métriques personnalisées.

1. Enregistrez l'exemple de fichier manifeste suivant sous le nom GCPTrafficDistributionPolicy.yaml :

   apiVersion: networking.gke.io/v1
   kind: GCPTrafficDistributionPolicy
   metadata:
     name: echoserver-v2
     namespace: team1
   spec:
     targetRefs:
     # Attach to the echoserver-v2 Service in the cluster.
     - kind: Service
       group: ""
       name: echoserver-v2
     default:
       # Use custom metrics to distribute traffic across endpoints.
       localityLbAlgorithm: WEIGHTED_ROUND_ROBIN
       # Configure metrics from an ORCA load report to use for traffic
       # distribution.
       customMetrics:
       - name: orca.named_metrics.bescm11
         dryRun: false
       - name: orca.named_metrics.bescm12
         dryRun: true
   

2. Appliquez le fichier manifeste à votre cluster :

   kubectl apply -f GCPTrafficDistributionPolicy.yaml
   

L'équilibreur de charge distribue le trafic aux points de terminaison en fonction de l'algorithme WEIGHTED_ROUND_ROBIN et des métriques personnalisées fournies.

Configurer la taille de l'anneau de hachage

Pour les services où il est essentiel de minimiser les échecs de cache, utilisez l'algorithme RING_HASH. Ajuster le champ minimumHashRingSize permet de répartir plus précisément la charge sur les backends. Bien que l'équilibreur de charge gère automatiquement la taille de l'anneau, une valeur minimale plus élevée peut contribuer à assurer une répartition plus uniforme des requêtes pour les ensembles de backends plus volumineux.

apiVersion: networking.gke.io/v1
kind: GCPTrafficDistributionPolicy
metadata:
  name: ring-hash-policy
  namespace: default
spec:
  default:
    localityLbAlgorithm: RING_HASH
    # Defaults to 1024. Larger ring sizes result in more granular
    # load distributions. Supported range is 1 to 2048.
    minimumHashRingSize: 1024
  targetRefs:
  -   group: ""
    kind: Service
    name: my-cache-heavy-service

Configurer l'affinité de session

Configurez l'affinité de session pour vous assurer que les requêtes du même client sont systématiquement acheminées vers le même pod de backend.

Configurer l'affinité de session à l'aide de GCPTrafficDistributionPolicy (par défaut)

Les types d'affinité de session décrits dans cette section nécessitent les versions minimales suivantes de GKE :

• CLIENT_IP, HEADER_FIELD, GENERATED_COOKIE et HTTP_COOKIE : version 1.35.2-gke.1269001 ou ultérieure.
• STRONG_COOKIE_AFFINITY : version 1.36.3-gke.1767000 ou ultérieure.

GKE Gateway est compatible avec tous les types d'affinité de session à l'aide de la ressource GCPTrafficDistributionPolicy. Cette ressource offre un contrôle plus précis, comme le routage basé sur des en-têtes HTTP ou des cookies personnalisés. La configuration de l'affinité de session à l'aide de GCPTrafficDistributionPolicy est la méthode par défaut et recommandée.

Le tableau suivant décrit les types d'affinité compatibles lorsque vous utilisez GCPTrafficDistributionPolicy :

Les exemples suivants montrent comment configurer GCPTrafficDistributionPolicy groupé par catégorie d'affinité : affinité de session basée sur les cookies, sur les en-têtes et sur les adresses IP des clients.

Pour appliquer l'une des configurations d'affinité de session suivantes à votre cluster, procédez comme suit :

1. Enregistrez le fichier manifeste choisi sous le nom policy.yaml.

2. Appliquez le fichier manifeste à votre cluster :

   kubectl apply -f policy.yaml
   

Affinité de session basée sur les cookies

L'affinité de session basée sur les cookies inclut les types d'affinité STRONG_COOKIE_AFFINITY, HTTP_COOKIE et GENERATED_COOKIE.

Affinité de cookie avec état (STRONG_COOKIE_AFFINITY)

L'affinité de cookie avec état (STRONG_COOKIE_AFFINITY) offre une persistance de session avec état qui maintient la permanence même lors des événements de scaling du backend.

apiVersion: networking.gke.io/v1
kind: GCPTrafficDistributionPolicy
metadata:
  name: strong-cookie-affinity-policy
  namespace: default
spec:
  default:
    sessionAffinity:
      type: STRONG_COOKIE_AFFINITY
      cookie:
        name: "GKE_STATEFUL_SESSION"
        path: "/"
        ttl: "24h"
  targetRefs:
  - group: ""
    kind: Service
    name: my-stateful-service

Affinité basée sur les cookies HTTP (HTTP_COOKIE)

Le type d'affinité HTTP_COOKIE repose sur un cookie nommé spécifique renvoyé dans un en-tête Set-Cookie. Pour utiliser des types d'affinité de session autres que NONE et STRONG_COOKIE_AFFINITY, vous devez définir le champ localityLbAlgorithm sur MAGLEV ou RING_HASH.

apiVersion: networking.gke.io/v1
kind: GCPTrafficDistributionPolicy
metadata:
  name: http-cookie-affinity-policy
  namespace: default
spec:
  default:
    sessionAffinity:
      type: HTTP_COOKIE
      cookie:
        name: "my-app-session-id"
        path: "/"
        ttl: "3600s"
    # HTTP_COOKIE affinity requires localityLbAlgorithm to be MAGLEV or RING_HASH.
    localityLbAlgorithm: MAGLEV
  targetRefs:
  - group: ""
    kind: Service
    name: my-stateful-service

Affinité basée sur les cookies générés (GENERATED_COOKIE)

Le type d'affinité GENERATED_COOKIE permet à l'équilibreur de charge de générer et de nommer automatiquement le cookie de session. Vous pouvez éventuellement configurer la valeur du champ cookie.ttl jusqu'à deux semaines (336h).

apiVersion: networking.gke.io/v1
kind: GCPTrafficDistributionPolicy
metadata:
  name: generated-cookie-affinity-policy
  namespace: default
spec:
  default:
    sessionAffinity:
      type: GENERATED_COOKIE
      cookie:
        ttl: "2h30m"
    # GENERATED_COOKIE affinity requires localityLbAlgorithm to be MAGLEV or RING_HASH.
    localityLbAlgorithm: MAGLEV
  targetRefs:
  - group: ""
    kind: Service
    name: my-stateful-service

Le comportement d'une valeur TTL nulle pour l'affinité de session basée sur les cookies inclut les éléments suivants :

• Toutes les affinités de session basées sur les cookies (STRONG_COOKIE_AFFINITY, HTTP_COOKIE et GENERATED_COOKIE) ont un attribut ttl.

• Une valeur TTL de zéro seconde signifie que l'équilibreur de charge n'attribue pas d'attribut Expires au cookie. Dans ce cas, le client traite le cookie comme un cookie de session. La définition d'une session varie en fonction du client :

  • Certains clients, comme les navigateurs Web, conservent le cookie pendant toute la session de navigation. Cette approche signifie que le cookie persiste sur plusieurs requêtes jusqu'à ce que l'application soit fermée.
  • D'autres clients traitent une session comme une requête HTTP unique et suppriment le cookie immédiatement après la fin de la session.

Affinité de session basée sur l'en-tête

Le type d'affinité HEADER_FIELD permet de router le trafic en fonction d'un en-tête HTTP spécifique pour des scénarios tels que les tests A/B ou le routage client spécialisé où un cookie ne convient pas. Pour utiliser des types d'affinité de session autres que NONE et STRONG_COOKIE_AFFINITY, vous devez définir le champ localityLbAlgorithm sur MAGLEV ou RING_HASH. Contrairement à ROUND_ROBIN par défaut, ces algorithmes sont compatibles avec le hachage cohérent basé sur des champs personnalisés tels que les en-têtes HTTP.

apiVersion: networking.gke.io/v1
kind: GCPTrafficDistributionPolicy
metadata:
  name: header-affinity-policy
  namespace: default
spec:
  default:
    sessionAffinity:
      type: HEADER_FIELD
      httpHeaderName: "X-User-Group-ID"
    localityLbAlgorithm: MAGLEV
  targetRefs:
  - group: ""
    kind: Service
    name: SERVICE_NAME

Affinité de session basée sur les adresses IP client

Le type d'affinité CLIENT_IP achemine le trafic provenant d'une adresse IP client spécifique vers le même pod de backend, dans la mesure du possible. Pour utiliser des types d'affinité de session autres que NONE et STRONG_COOKIE_AFFINITY, vous devez définir le champ localityLbAlgorithm sur MAGLEV ou RING_HASH.

apiVersion: networking.gke.io/v1
kind: GCPTrafficDistributionPolicy
metadata:
  name: client-ip-affinity-policy
  namespace: default
spec:
  default:
    sessionAffinity:
      type: CLIENT_IP
    localityLbAlgorithm: MAGLEV
  targetRefs:
  - group: ""
    kind: Service
    name: SERVICE_NAME

Valider la règle

Pour vous assurer que votre GCPTrafficDistributionPolicy est correctement configurée et active, vérifiez son état après l'avoir appliquée :

1. Pour vérifier l'état de la règle, exécutez la commande suivante :

   kubectl describe gcptrafficdistributionpolicy POLICY_NAME
   

   Remplacez POLICY_NAME par le nom de votre règle.

2. Dans le résultat, vérifiez la section Conditions. Un état True avec le motif Attached indique que la configuration est valide et active.

Configurer l'affinité de session à l'aide de GCPBackendPolicy

Cette section explique comment configurer l'affinité de session à l'aide de GCPBackendPolicy.

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

• Adresse IP du client (CLIENT_IP)
• Cookie généré (GENERATED_COOKIE)

Lorsque vous configurez l'affinité de session pour votre service à l'aide de GCPBackendPolicy, la passerelle définit le paramètre localityLbPolicy sur le service de backend sur MAGLEV. Lorsque vous supprimez l'affinité de session de GCPBackendPolicy, la passerelle rétablit la valeur par défaut du paramètre localityLbPolicy, ROUND_ROBIN.

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

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    # On a best-effort basis, send requests from a specific client IP address
    # to the same backend. This field also sets the load balancer locality
    # policy to MAGLEV. For more information, see
    # https://cloud.google.com/load-balancing/docs/backend-service#lb-locality-policy
    sessionAffinity:
      type: CLIENT_IP
  targetRef:
    group: ""
    kind: Service
    name: lb-service

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    # On a best-effort basis, send requests from a specific client IP address
    # to the same backend. This field also sets the load balancer locality
    # policy to MAGLEV. For more information, see
    # https://cloud.google.com/load-balancing/docs/backend-service#lb-locality-policy
    sessionAffinity:
      type: CLIENT_IP
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

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

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    # Include an HTTP cookie in the Set-Cookie header of the response.
    # This field also sets the load balancer locality policy to MAGLEV. For more
    # information, see
    # https://cloud.google.com/load-balancing/docs/l7-internal#generated_cookie_affinity.
    sessionAffinity:
      type: GENERATED_COOKIE
      cookieTtlSec: 50  # The cookie expires in 50 seconds.
  targetRef:
    group: ""
    kind: Service
    name: lb-service

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    # Include an HTTP cookie in the Set-Cookie header of the response.
    # This field also sets the load balancer locality policy to MAGLEV. For more
    # information, see
    # https://cloud.google.com/load-balancing/docs/l7-internal#generated_cookie_affinity.
    sessionAffinity:
      type: GENERATED_COOKIE
      cookieTtlSec: 50  # The cookie expires in 50 seconds.
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

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.

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 :

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

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

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    connectionDraining:
      drainingTimeoutSec: 60
  # Attach to an InferencePool in the cluster.
  targetRef:
    group: inference.networking.k8s.io
    kind: InferencePool
    name: my-inference-pool

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.

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.
• Aucun champ facultatif n'est consigné.

Vous pouvez désactiver la journalisation des accès sur votre passerelle à l'aide d'une 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 et une liste de champs facultatifs, par exemple tls.cipher ou orcaLoadReport.

Pour activer la journalisation des champs facultatifs :

• Définissez logging.OptionalMode sur CUSTOM.
• Indiquez la liste des champs facultatifs à enregistrer dans logging.optionalFields. Pour obtenir la liste des champs compatibles, consultez Journalisation et surveillance.

Vous pouvez désactiver la journalisation des champs facultatifs de deux manières :

• Vous pouvez supprimer toutes les entrées de logging.optionalFields.
• Vous pouvez définir logging.OptionalMode sur EXCLUDE_ALL_OPTIONAL.

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. Le fichier manifeste permet également la journalisation de deux champs facultatifs pour une ressource Service donnée :

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    # Access logging configuration for the load balancer.
    logging:
      enabled: true
      # Log 50% of the requests. The value must be an integer between 0 and
      # 1000000. To get the proportion of requests to log, GKE
      # divides this value by 1000000.
      sampleRate: 500000
      # Log specific optional fields.
      optionalMode: CUSTOM
      optionalFields:
      - tls.cipher
      - orcaLoadReport.cpu_utilization
  targetRef:
    group: ""
    kind: Service
    name: lb-service

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    # Access logging configuration for the load balancer.
    logging:
      enabled: true
      # Log 50% of the requests. The value must be an integer between 0 and
      # 1000000. To get the proportion of requests to log, GKE
      # divides this value by 1000000.
      sampleRate: 500000
      # Log specific optional fields.
      optionalMode: CUSTOM
      optionalFields:
      - tls.cipher
      - orcaLoadReport.cpu_utilization
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    # Access logging configuration for the load balancer.
    logging:
      enabled: true
      # Log 50% of the requests. The value must be an integer between 0 and
      # 1000000. To get the proportion of requests to log, GKE
      # divides this value by 1000000.
      sampleRate: 500000
      # Log specific optional fields.
      optionalMode: CUSTOM
      optionalFields:
      - tls.cipher
      - orcaLoadReport.cpu_utilization
  # Attach to an InferencePool in the cluster.
  targetRef:
    group: inference.networking.k8s.io
    kind: InferencePool
    name: my-inference-pool

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    # Access logging configuration for the load balancer.
    logging:
      enabled: true
      # Log 50% of the requests. The value must be an integer between 0 and
      # 1000000. To get the proportion of requests to log, GKE
      # divides this value by 1000000.
      sampleRate: 500000
      # Log specific optional fields.
      optionalMode: CUSTOM
      optionalFields:
      - tls.cipher
      - orcaLoadReport.cpu_utilization
  # Attach to a multi-cluster InferencePool.
  targetRef:
    group: networking.gke.io
    kind: GCPInferencePoolImport
    name: my-inference-pool-import

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.
• optionalMode: CUSTOM : spécifie qu'un ensemble de optionalFields doit être inclus dans les entrées de journal.
• optionalFields: tls.cipher, orcaLoadReport.cpu_utilization : indique que les entrées de journal doivent inclure à la fois le nom du chiffrement utilisé pour l'établissement de la liaison TLS et l'utilisation du processeur du service, lorsque ces informations sont disponibles.

Configurer l'autoscaling basé sur le trafic pour votre passerelle à cluster unique

Assurez-vous que votre cluster GKE exécute la version 1.31.1-gke.2008000 ou ultérieure.

Pour activer l'autoscaling basé sur le trafic et l'équilibrage de charge basé sur la capacité dans une passerelle à cluster unique, vous pouvez configurer la capacité du service. La capacité de service permet de spécifier la capacité de trafic qu'un service peut recevoir avant que les pods ne soient soumis à l'autoscaling ou que le trafic ne déborde pas vers d'autres clusters disponibles.

Pour configurer la capacité de service, créez un service et une GCPBackendPolicy associée. Le fichier manifeste GCPBackendPolicy utilise le champ maxRatePerEndpoint, qui définit une valeur maximale de requêtes par seconde (RPS) par pod dans un service. Le fichier manifeste GCPBackendPolicy suivant définit un nombre maximal de RPS de 10 :

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: store
spec:
  default:
    maxRatePerEndpoint: 10
  targetRef:
    group: ""
    kind: Service
    name: store

Pour en savoir plus sur l'autoscaling basé sur le trafic, consultez Autoscaling basé sur le trafic de l'équilibreur de charge.

Dépannage

Cette section fournit des conseils pour résoudre les problèmes courants lors de la configuration des ressources Gateway à l'aide de règles.

GCPTrafficDistributionPolicy n'est pas appliqué

Symptôme : le trafic n'est pas distribué en fonction des paramètres d'affinité de session ou de localité définis dans votre règle.

Cause : cela se produit généralement si la règle n'est pas correctement associée au service ou si le contrôleur de passerelle a rencontré une erreur de validation lors de la tentative de synchronisation de la configuration avec l'équilibreur de charge.

Solution :

1. Vérifiez l'état de la stratégie : vérifiez si la stratégie a été associée à votre service :

   kubectl describe gcptrafficdistributionpolicy POLICY_NAME
   

   Remplacez POLICY_NAME par le nom de votre règle.

   Dans le résultat, recherchez la section Conditions. Un état True avec le motif Attached indique que la configuration est valide et a été appliquée. Si l'état est False, vérifiez les champs Reason et Message pour détecter les erreurs de validation (par exemple, un algorithme non compatible avec le type d'affinité choisi).

2. Vérifiez la synchronisation de la configuration de la passerelle : assurez-vous que la passerelle gérant le trafic a bien synchronisé ces paramètres avec l'infrastructure cloud.

   Dans la section Status, vérifiez que la condition Programmed a une Status de True. Si la valeur est False, cela indique que le contrôleur de passerelle a rencontré une erreur, potentiellement liée à votre GCPTrafficDistributionPolicy.

   Consultez les champs Reason et Message à côté de la condition Programmed pour obtenir des informations immédiates. Pour obtenir des messages d'erreur plus précis ou un historique des échecs de synchronisation, consultez Events en bas de la sortie.

Plusieurs règles GCPBackendPolicy associées au même service

Symptôme :

La condition d'état suivante peut se produire lorsque vous associez une GCPBackendPolicy à un Service ou un 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 à un Service ou un ServiceImport qui est déjà associé à une GCPBackendPolicy.

Plusieurs règles GCPBackendPolicy associées au même service ou ServiceImport ne sont pas compatibles avec GKE Gateway. Pour en savoir plus, consultez Restrictions et limites.

Solution :

Configurez une seule GCPBackendPolicy qui inclut toutes les configurations personnalisées et associez-la à votre ressource cible (Service, ServiceImport, InferencePool ou GCPInferencePoolImport).

Affinité de session ignorée lors de la répartition du trafic

Symptôme :

Les requêtes ne sont pas systématiquement acheminées vers le même pod de backend, même si l'affinité de session est configurée.

Explication :

La répartition du trafic pondérée est prioritaire par rapport à l'affinité de session. Si une HTTPRoute définit des pondérations pour plusieurs backends, l'équilibreur de charge sélectionne d'abord un backend en fonction des pondérations avant d'appliquer la logique d'affinité.

Solution :

Évitez d'utiliser la répartition du trafic pondérée sur la même règle HTTPRoute où la persistance de session est requise.

Règle de sécurité Cloud Armor introuvable

Symptôme :

Le message d'erreur suivant peut s'afficher lorsque vous activez Cloud Armor sur votre passerelle régionale :

Invalid value for field 'resource': '{
"securityPolicy":"projects/123456789/regions/us-central1/securityPolicies/<policy_name>"}'.
The given security policy does not exist.

Explication :

Le message d'erreur indique que la stratégie de sécurité Cloud Armor régionale spécifiée n'existe pas dans votre projet Cloud de Confiance .

Solution :

Créez une stratégie de sécurité Cloud Armor régionale dans votre projet et référencez-la dans votre GCPBackendPolicy.

Étapes suivantes

• Découvrez comment déployer une passerelle.
• 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.