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, 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.

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 GCPBackendPolicy peut être associé à un service à la fois. Lorsque deux règles GCPBackendPolicy 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

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 flotte comporte des clusters dans plusieurs régions, vous devrez peut-être déployer des passerelles régionales dans différentes régions pour différents 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 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.

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 et http2) possède des paramètres que vous pouvez définir. Google Cloud 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 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 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. Google Cloud Pour en savoir plus, consultez la section Vérifications multiples et fréquence de vérification.
  • TIMEOUT: spécifie la durée pendant laquelleGoogle 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 est 2. Google Cloud
  • 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 est 80. Google Cloud É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.

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. Si vous activez une passerelle régionale, vous devez créer une stratégie de sécurité de backend Google Cloud Armor régionale.

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 backend associés à un 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, puis téléchargez le fichier client OAuth.

    3. Dans le 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, puis remplacez SECRET_NAME et CLIENT_ID respectivement. 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 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 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 la sélection du backend à l'aide de GCPBackendPolicy

Le mode d'équilibrage CUSTOM_METRICS dans 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 distribuent le trafic. Ce mode d'équilibrage permet d'équilibrer la charge en fonction des métriques personnalisées que vous définissez et qui sont signalées par les backends de l'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 de 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 cette valeur est définie sur "true", les données de métrique sont envoyées à Cloud Monitoring, mais n'ont aucune incidence sur 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:
targetRef:
  kind: Service
  name: super-service
default:
  backends:
  - location: "*"
    balancingMode: RATE
    maxRatePerEndpoint: 9000
  - location: us-central1-a  # specific block applies to given zone / region only.
    # maxRatePerEndpoint: 9000 inherited from unnamed
    balancingMode: CUSTOM_METRICS
    customMetrics:
    - name: gpu-load
      maxUtilization: 100 # value ranges from 0 to 100 and maps to the floating pointrange [0.0, 1.0]
      dryRun: false

  2. Appliquez le fichier manifeste à votre cluster :

    kubectl apply -f my-backend-policy.yaml

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

Configurer le routage au niveau du point de terminaison avec GCPTrafficDistributionPolicy

GCPTrafficDistributionPolicy configure l'algorithme d'équilibrage de charge pour la sélection de point de terminaison dans un backend. Lorsque vous sélectionnez WEIGHTED_ROUND_ROBIN, l'équilibreur de charge utilise des poids dérivés des métriques signalées (y compris les métriques personnalisées) pour répartir le trafic entre les instances ou les points de terminaison individuels.

Le champ WEIGHTED_ROUND_ROBIN localityLbPolicy de la ressource GCPTrafficDistributionPolicy spécifie un algorithme d'équilibrage de charge pour sélectionner des instances ou des points de terminaison individuels dans un backend. Lorsque vous utilisez cet algorithme, la règle utilise des métriques personnalisées pour calculer les pondérations de l'attribution de charge.

Le tableau customMetrics[] de la configuration GCPTrafficDistributionPolicy contient les champs suivants:

  • name: spécifie le nom défini par l'utilisateur de la métrique personnalisée.
  • dryRun: champ booléen. Lorsque cette valeur est définie sur "true", les données de métriques sont envoyées à Cloud Monitoring, mais n'ont aucune incidence sur l'équilibrage de charge.

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 du point 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:
  - kind: Service
    group: ""
    name: echoserver-v2
  default:
    localityLbAlgorithm: WEIGHTED_ROUND_ROBIN
    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 vers les points de terminaison en fonction de l'algorithme WEIGHTED_ROUND_ROBIN et à l'aide des métriques personnalisées fournies.

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.

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.

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.

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.

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 enregistré.

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 et une liste de champs facultatifs, par exemple "tls.cipher" ou "orca_load_report".

Pour activer la journalisation des champs facultatifs:

  • Définissez logging.OptionalMode sur CUSTOM.
  • Indiquez la liste des champs facultatifs à consigner dans logging.optionalFields. Pour obtenir la liste des champs compatibles, consultez la section 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 active également la journalisation de deux champs facultatifs 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
      optionalMode: CUSTOM
      optionalFields:
      - tls.cipher
      - orca_load_report.cpu_utilization
  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
      optionalMode: CUSTOM
      optionalFields:
      - tls.cipher
      - orca_load_report.cpu_utilization
  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.
  • optionalMode: CUSTOM: spécifie qu'un ensemble de optionalFields doit être inclus dans les entrées de journal.
  • optionalFields: tls.cipher, orca_load_report.cpu_utilization: spécifie que les entrées de journal doivent inclure à la fois le nom du chiffrement utilisé pour l'échange TLS et l'utilisation du processeur du service, lorsqu'ils 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é de service. La capacité de service est la possibilité 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 un GCPBackendPolicy associé. 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 la page Autoscaling basé sur le trafic de l'équilibreur de charge.

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.

Stratégie de sécurité Google Cloud Armor introuvable

Symptôme :

Le message d'erreur suivant peut s'afficher lorsque vous activez Google 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 règle de sécurité Google Cloud Armor régionale spécifiée n'existe pas dans votre projet Google Cloud .

Solution :

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

Étapes suivantes