Configurer la gestion du trafic pour les équilibreurs de charge d'applications externes régionaux

Ce document présente des exemples d'utilisation de la gestion du trafic pour certains cas d'utilisation spécifiques. De nombreux autres cas d'utilisation sont possibles.

Ce document contient des exemples pour les équilibreurs de charge suivants :

Équilibreur de charge d'application externe régional
Équilibreur de charge d'application interne régional
Équilibreur de charge d'application interne interrégional

Équilibreur de charge d'application externe régional et équilibreur de charge d'application interne régional. Pour la configuration de la gestion du trafic des équilibreurs de charge régionaux, la documentation sur l'API de mappage d'URL régionales et l'API de service de backend régional fournit une liste complète des champs, y compris la sémantique concernant les relations, les restrictions et la cardinalité.

La seule différence entre ces deux équilibreurs de charge est le schéma d'équilibrage de charge, comme suit :

Les équilibreurs de charge d'application externes régionaux utilisent EXTERNAL_MANAGED.
Les équilibreurs de charge d'application internes régionaux utilisent INTERNAL_MANAGED.

Équilibreur de charge d'application interne régional et équilibreur de charge d'application interne interrégional. Pour la configuration de la gestion du trafic :

Les équilibreurs de charge d'application internes régionaux utilisent l'API de mappage d'URL régionales, et la documentation sur l'API de service de backend régional fournit une liste complète des champs, y compris la sémantique concernant les relations, les restrictions et la cardinalité.
Les équilibreurs de charge d'application internes interrégionaux utilisent l'API de mappage d'URL globales, et la documentation sur l'API de service de backend global fournit une liste complète des champs, y compris la sémantique concernant les relations, les restrictions et la cardinalité.

Remarque : Pour les équilibreurs de charge d'application internes interrégionaux, vous pouvez utiliser les exemples fournis dans ce document en remplaçant regions/REGION/backendServices par global/backendServices).

Outre les fonctionnalités de routage avancées décrites sur cette page, certains équilibreurs de charge d'application s'intègrent aux extensions de service pour vous permettre d'injecter une logique personnalisée dans le chemin d'accès aux données d'équilibrage de charge en configurant des appels d'extensions de service.

Configurer la gestion du trafic

Dans l'environnement de configuration que vous avez choisi, vous configurez la gestion du trafic à l'aide de configurations YAML. Un mappage d'URL et un service de backend possèdent chacun leur propre fichier YAML. Selon les fonctionnalités souhaitées, vous devez rédiger un fichier YAML de mappage d'URL, de service de backend, ou les deux.

Pour obtenir de l'aide concernant l'écriture de ces fichiers YAML, vous pouvez utiliser les exemples de cette page et la documentation de l'API Cloud Load Balancing.

Pour les équilibreurs de charge d'application internes régionaux et les équilibreurs de charge d'application externes régionaux, l'API de mappage d'URL régionales et la documentation sur l'API de service de backend régional fournit une liste complète des champs, y compris la sémantique concernant les relations, les restrictions et la cardinalité.

Mapper le trafic à un service unique

Envoyez l'intégralité du trafic vers un service unique. Veillez à remplacer les espaces réservés.

    defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
    hostRules:
    - hosts:
      - '*'
      pathMatcher: matcher1
    name: URL_MAP_NAME
    pathMatchers:
    - defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
      name: matcher1
      routeRules:
        - matchRules:
            - prefixMatch: /PREFIX
          priority: 1
          routeAction:
            weightedBackendServices:
              - backendService: regions/REGION/backendServices/BACKEND_SERVICE_1
                weight: 100

Répartir le trafic entre deux services

Répartissez le trafic entre deux services au minimum. Veillez à remplacer les espaces réservés.

   defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   name: URL_MAP_NAME
   pathMatchers:
   - defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
     - matchRules:
       - prefixMatch: /PREFIX
       priority: 2
       routeAction:
         weightedBackendServices:
         - backendService: regions/REGION/backendServices/BACKEND_SERVICE_1
           weight: 95
         - backendService: regions/REGION/backendServices/BACKEND_SERVICE_2
           weight: 5

Configurer une redirection d'URL

L'exemple suivant renvoie un code de réponse 3xx configurable. Il définit également l'en-tête de réponse Location à l'aide de l'URI approprié, en remplaçant l'hôte et le chemin d'accès comme spécifié dans l'action de redirection.

   defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
   name: regional-lb-map
   region: region/REGION
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY # 0 is highest
         urlRedirect:
           hostRedirect: "new-host-name.com" # Omit to keep the requested host
           pathRedirect: "/new-path" # Omit to keep the requested path; mutually exclusive to prefixRedirect
           prefixRedirect: "/newPrefix" # Omit to keep the requested path; mutually exclusive to pathRedirect
           redirectResponseCode: FOUND
           stripQuery: True

Mettre en miroir le trafic

En plus de transmettre la requête au service de backend sélectionné, vous pouvez envoyer une requête identique au service de backend en miroir, selon une configuration de type fire and forget. L'équilibreur de charge n'attend pas de réponse du backend auquel il envoie la requête en miroir. La mise en miroir est utile pour tester une nouvelle version d'un service de backend. Elle permet également de déboguer les erreurs de production sur une version de débogage du service de backend, plutôt que sur la version de production.

   defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
   name: regional-lb-map
   region: region/REGION
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: 1
         routeAction:
           weightedBackendServices:
             - backendService: regions/REGION/backendServices/BACKEND_SERVICE_1
               weight: 100
           requestMirrorPolicy:
             backendService: regions/REGION/backendServices/BACKEND_SERVICE_2

Réécrire l'URL demandée

Réécrivez la partie du nom d'hôte de l'URL, la partie du chemin de l'URL, ou les deux, avant d'envoyer une requête au service de backend sélectionné. Veillez à remplacer les espaces réservés.

   defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
   name: regional-lb-map
   region: region/REGION
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: regions/REGION/backendServices/BACKEND_SERVICE_1
               weight: 100
           urlRewrite:
             hostRewrite: "new-host-name.com" # Omit to keep the requested host
             pathPrefixRewrite: "/new-path/" # Omit to keep the requested path

Réessayer une requête

Configurez les conditions dans lesquelles l'équilibreur de charge doit effectuer une nouvelle tentative pour les requêtes ayant échoué, le délai d'attente avant de procéder à une nouvelle tentative et le nombre maximal de tentatives autorisées.

   defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
   name: regional-lb-map
   region: region/REGION
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: regions/REGION/backendServices/BACKEND_SERVICE_1
               weight: 100
           retryPolicy:
             retryConditions: 502, 504
             numRetries: 3
             perTryTimeout:
               seconds: 1
               nanos: 500000000

Spécifier le délai avant expiration de la route

Indiquez le délai avant expiration pour la route sélectionnée. Le délai avant expiration est calculé à partir du moment où la requête est entièrement traitée et jusqu'à ce que la réponse soit elle aussi entièrement traitée. Le délai avant expiration inclut l'ensemble des nouvelles tentatives. Veillez à remplacer les espaces réservés.

   defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
   name: regional-lb-map
   region: region/REGION
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: regions/REGION/backendServices/BACKEND_SERVICE_1
               weight: 100
           timeout:
             seconds: 30
             nanos: 500000000

Configurer l'injection de pannes

Intégrez des erreurs lors du traitement des requêtes pour simuler des pannes, y compris une latence élevée, une surcharge de service, des défaillances de service et un partitionnement réseau. Cette fonctionnalité est utile pour tester la résilience d'un service aux pannes simulées.

   defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
   name: regional-lb-map
   region: region/REGION
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: regions/REGION/backendServices/BACKEND_SERVICE_1
               weight: 100
           faultInjectionPolicy:
             delay:
               fixedDelay:
                 seconds: 10
                 nanos: 500000000
               percentage: 25
             abort:
               httpStatus: 503
               percentage: 50

Configurer le CORS

Configurez les règles CORS (Cross-Origin Resource Sharing) afin de gérer les paramètres d'application des requêtes CORS.

   defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
   name: regional-lb-map
   region: region/REGION
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: regions/REGION/backendServices/BACKEND_SERVICE_1
               weight: 100
           corsPolicy:
               allowOrigins: my-domain.com
               allowMethods: GET, POST
               allowHeaders: Authorization, Content-Type
               maxAge: 1200
               allowCredentials: True

Ajouter et supprimer des en-têtes de requête et de réponse

Ajoutez et supprimez des en-têtes de requête avant d'envoyer les requêtes au service de backend. Ajoutez et supprimez également des en-têtes de réponse après avoir reçu une réponse du service de backend.

Les équilibreurs de charge d'application externes régionaux et les équilibreurs de charge d'application internes acceptent également l'utilisation de variables dans les en-têtes personnalisés. Vous pouvez spécifier une ou plusieurs variables dans les champs de valeur d'en-tête personnalisé (headerValue) qui sont ensuite converties en valeurs par requête correspondantes. Pour obtenir la liste des valeurs d'en-tête acceptées, consultez la page Créer des en-têtes personnalisés dans les mappages d'URL.

   defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
   name: regional-lb-map
   region: region/REGION
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: regions/REGION/backendServices/BACKEND_SERVICE_1
               weight: 100
               headerAction:
                 requestHeadersToAdd:
                 - headerName: header-1-name
                   headerValue: header-1-value
                   replace: True
                 requestHeadersToRemove:
                 - header-2-name
                 - header-3-name
                 responseHeadersToAdd:
                 - headerName: header-4-name
                   headerValue: header-4-value
                   replace: True
                responseHeadersToRemove:
                - header-5-name
                - header-6-name

Configurer la détection des anomalies

Spécifiez les critères d'exclusion des VM backend ou des points de terminaison défaillants dans les NEG, ainsi que des critères permettant de définir à quel moment un backend ou un point de terminaison est considéré comme suffisamment opérationnel pour recevoir à nouveau le trafic. Veillez à remplacer les espaces réservés.

    loadBalancingScheme: LOAD_BALANCING_SCHEME
    localityLbPolicy: RANDOM
    name: regions/REGION/backendServices/BACKEND_SERVICE_1
    outlierDetection:
      baseEjectionTime:
        nanos: 0
        seconds: '30'
      consecutiveErrors: 5
      consecutiveGatewayFailure: 3
      enforcingConsecutiveErrors: 2
      enforcingConsecutiveGatewayFailure: 100
      enforcingSuccessRate: 100
      interval:
        nanos: 0
        seconds: '1'
      maxEjectionPercent: 50
      successRateMinimumHosts: 5
      successRateRequestVolume: 100
      successRateStdevFactor: 1900
    region: region/REGION

Configurer la rupture de circuit

La rupture de circuit vous permet de définir des seuils de défaillance pour empêcher les requêtes client de surcharger vos backends. Une fois que les requêtes atteignent la limite que vous avez définie, l'équilibreur de charge arrête d'autoriser de nouvelles connexions ou n'envoie plus de requêtes, ce qui laisse le temps à vos backends de revenir à l'état normal de fonctionnement. Avec la rupture du circuit, vous pouvez empêcher les défaillances en cascade. Lorsque la limite est atteinte, les requêtes s'interrompent et un message d'erreur est renvoyé aux clients. Vous évitez ainsi tout risque de surcharge des backends. Cela permet de diffuser du trafic tout en gérant la situation de surcharge. Ce fonctionnement est comparable à la gestion d'un pic de trafic via l'augmentation de la capacité (par le biais de l'autoscaling).

Définissez des limites supérieures pour le nombre de requêtes par connexion et le volume de connexions à un service de backend. Limitez également le nombre de requêtes et de tentatives en attente.

    loadBalancingScheme: LOAD_BALANCING_SCHEME # EXTERNAL_MANAGED or INTERNAL_MANAGED
    localityLbPolicy: RANDOM
    affinityCookieTtlSec: 0
    backends:
    - balancingMode: UTILIZATION
      capacityScaler: 1.0
      group: region/REGION/instanceGroups/INSTANCE_GROUP
      maxUtilization: 0.8
    circuitBreakers:
      maxConnections: 1000
      maxPendingRequests: 200
      maxRequests: 1000
      maxRequestsPerConnection: 100
      maxRetries: 3
    connectionDraining:
      drainingTimeoutSec: 0
    healthChecks:
    - region/REGION/healthChecks/HEALTH_CHECK

Configurer la répartition du trafic : étapes détaillées

Cet exemple illustre les étapes suivantes :

Créer des modèles distincts pour les différents services.
Créer des groupes d'instances pour ces modèles.
Créer des règles de routage qui configurent une répartition du trafic de type 95 % / 5 %.
Envoyer des commandes curl pour vérifier que les pourcentages de répartition du trafic correspondent approximativement à la configuration.

Ces instructions partent du principe que :

la région est us-west1 ;
un proxy cible et une règle de transfert ont été créés, de même qu'un mappage d'URL nommé regional-lb-map ;
le mappage d'URL envoie tout le trafic vers un service de backend, nommé red-service, qui est le service de backend par défaut ;
vous avez configuré un autre chemin d'accès qui envoie 5 % du trafic vers blue-service et 95 % du trafic vers green-service ;
un outil de mise en correspondance des chemins d'accès est utilisé ;
vous utilisez Cloud Shell ou un autre environnement avec bash installé.

Définir les services

La fonction bash suivante crée un service de backend, incluant le modèle d'instance et le groupe d'instances géré.

function make_service() {
  local name="$1"
  local region="$2"
  local zone="$3"
  local network="$4"
  local subnet="$5"
  local subdir="$6"

  www_dir="/var/www/html/$subdir"

  (set -x; \
  gcloud compute instance-templates create "${name}-template" \
    --region="$region" \
    --network="$network" \
    --subnet="$subnet" \
    --tags=allow-ssh,load-balanced-backend \
    --image-family=debian-10 \
    --image-project=debian-cloud \
    --metadata=startup-script="#! /bin/bash
  apt-get update
  apt-get install apache2 -y
  a2ensite default-ssl
  a2enmod ssl
  sudo mkdir -p $www_dir
  /bin/hostname | sudo tee ${www_dir}index.html
  systemctl restart apache2"; \
  gcloud compute instance-groups managed create \
    "${name}-instance-group" \
    --zone="$zone" \
    --size=2 \
    --template="${name}-template"; \
  gcloud compute backend-services create "${name}-service" \
    --load-balancing-scheme=LOAD_BALANCING_SCHEME\
    --protocol=HTTP \
    --health-checks=regional-lb-basic-check \
    --health-checks-region="$region" \
    --region="$region"; \
  gcloud compute backend-services add-backend "${name}-service" \
    --balancing-mode='UTILIZATION' \
    --instance-group="${name}-instance-group" \
    --instance-group-zone="$zone" \
    --region="$region")
}

Créer les services

Appelez la fonction permettant de créer trois services : red, green et blue. Le service red sert de service par défaut pour les requêtes envoyées à /. Les services green et blue sont tous deux configurés sur /PREFIX pour traiter respectivement 95 % et 5 % du trafic.

make_service red us-west1 us-west1-a lb-network backend-subnet ""
make_service green us-west1 us-west1-a lb-network backend-subnet /PREFIX
make_service blue us-west1 us-west1-a lb-network backend-subnet /PREFIX

Créer le mappage d'URL

gcloud

Exportez le mappage d'URL existant à l'aide de la commande gcloud compute url-maps export :

gcloud compute url-maps export regional-lb-map \
  --destination=regional-lb-map-config.yaml \
  --region=us-west1

Mettez à jour le fichier de mappage d'URL regional-lb-map-config.yaml en ajoutant ce qui suit à la fin du fichier :

hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
pathMatchers:
- defaultService: regions/us-west1/backendServices/red-service
  name: matcher1
  routeRules:
  - priority: 2
    matchRules:
      - prefixMatch: /PREFIX
    routeAction:
      weightedBackendServices:
        - backendService: regions/us-west1/backendServices/green-service
          weight: 95
        - backendService: regions/us-west1/backendServices/blue-service
          weight: 5

Mettez à jour le mappage d'URL à l'aide de la commande gcloud compute url-maps import :

gcloud compute url-maps import regional-lb-map \
   --region=us-west1 \
   --source=regional-lb-map-config.yaml

Tester la configuration

Pour tester la configuration, vérifiez d'abord que les requêtes envoyées à l'adresse IP de l'équilibreur de charge configurée précédemment sont gérées par la configuration red par défaut.

Vérifiez ensuite que les requêtes envoyées à FORWARDING_RULE_IP_ADDRESS/PREFIX sont réparties comme prévu.

Configurer l'affinité de session basée sur `HTTP_COOKIE`

Le contrôle du trafic vous permet de configurer l'affinité de session en fonction d'un cookie fourni. Suivez ces instructions pour configurer une affinité de session HTTP_COOKIE pour un service de backend nommé red-service.

Exécutez la commande gcloud compute backend-services export pour obtenir la configuration du service de backend.

gcloud compute backend-services export red-service \
    --destination=red-service-config.yaml \
    --region=us-west1

Mettez à jour le fichier red-service-config.yaml comme suit :

sessionAffinity: 'HTTP_COOKIE'
localityLbPolicy: 'RING_HASH'
consistentHash:
 httpCookie:
  name: 'http_cookie'
  path: '/cookie_path'
  ttl:
    seconds: 100
    nanos: 500000000
 minimumRingSize: 10000

Dans le fichier red-service-config.yaml, supprimez la ligne suivante :
```
sessionAffinity: NONE
```

Mettez à jour le fichier de configuration du service de backend :

gcloud compute backend-services import red-service \
    --source=red-service-config.yaml \
    --region=us-west1

Dépannage

Utilisez ces informations pour le dépannage lorsque le trafic n'est pas acheminé conformément aux règles de routage et de trafic que vous avez configurées.

Symptômes :

Augmentation du trafic vers les services dans les règles supérieures à la règle considérée.
Augmentation inattendue des réponses HTTP 4xx et 5xx pour une règle de routage donnée.

Solution : vérifiez l'ordre de tri de vos règles de routage. Les règles de routage sont interprétées dans l'ordre dans lequel elles sont spécifiées.

Les règles de routage dans un mappage d'URL sont interprétées dans l'ordre dans lequel elles sont spécifiées. Cela diffère de la façon dont les règles de chemin d'accès sont interprétées par la correspondance du préfixe le plus long. Pour une règle de chemin d'accès, les équilibreurs de charge d'application internes ne sélectionnent qu'une seule règle de chemin d'accès. Cependant, lorsque vous utilisez des règles de routage, plusieurs règles de chemin d'accès peuvent s'appliquer.

Lorsque vous définissez des règles de routage, assurez-vous que les règles en début de liste n'acheminent pas par inadvertance du trafic qu'une règle de routage définie ultérieurement est sensée rediriger. Le service qui reçoit un trafic mal acheminé rejettera probablement les requêtes, et le trafic du service concerné par vos règles de routage sera réduit ou inexistant.

Étape suivante

Nettoyez la configuration de l'équilibreur de charge.

Configurer la gestion du trafic pour les équilibreurs de charge d'applications externes régionaux

Configurer la gestion du trafic

Mapper le trafic à un service unique

Répartir le trafic entre deux services

Configurer une redirection d'URL

Mettre en miroir le trafic

Réécrire l'URL demandée

Réessayer une requête

Spécifier le délai avant expiration de la route

Configurer l'injection de pannes

Configurer le CORS

Ajouter et supprimer des en-têtes de requête et de réponse

Configurer la détection des anomalies

Configurer la rupture de circuit

Configurer la répartition du trafic : étapes détaillées

Définir les services

Créer les services

Créer le mappage d'URL

gcloud

Tester la configuration

Configurer l'affinité de session basée sur HTTP_COOKIE

Dépannage

Étape suivante

Configurer l'affinité de session basée sur `HTTP_COOKIE`