Configurer la gestion du trafic pour les équilibreurs de charge d'application internes

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 :

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.

Avant de commencer

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 l'équilibreur de charge d'application interne régional, vous pouvez également utiliser la console Google Cloud pour configurer la gestion du trafic.

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

Accéder aux exemples YAML dans la console Google Cloud

Pour accéder aux exemples YAML dans la console Google Cloud, procédez comme suit :

  1. Dans la console Google Cloud, accédez à la page Équilibrage de charge.

    Accéder à la page "Équilibrage de charge"

  2. Cliquez sur Créer un équilibreur de charge.
  3. Suivez les étapes de l'assistant pour créer un équilibreur de charge d'application interne régional.
  4. Sous Règles de routage, sélectionnez Règle avancée d'hôte, de chemin d'accès et de routage.
  5. Cliquez sur Ajouter des hôtes et un outil de mise en correspondance des chemins d'accès.
  6. Cliquez sur le lien Conseils de codage.

La page Exemples YAML d'outils de mise en correspondance des chemins d'accès s'affiche.

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 :

  1. Créer des modèles distincts pour les différents services.

  2. Créer des groupes d'instances pour ces modèles.

  3. Créer des règles de routage qui configurent une répartition du trafic de type 95 % / 5 %.

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

Ces instructions partent du principe qu'une vérification d'état HTTP regional-lb-basic-check a été créée. Pour obtenir des instructions, consultez la page Configurer un équilibreur de charge d'application interne. 
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

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

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

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

Créer une VM cliente

Pour obtenir des instructions, consultez la section Créer une instance de VM dans la zone pour tester la connectivité.

Envoyer des requêtes à FORWARDING_RULE_IP_ADDRESS

  1. Utilisez ssh pour vous connecter au client.

    gcloud compute ssh global-lb-client-us-west1-a \
   --zone=us-west1-a

  2. Exécutez la commande suivante :

    for LB_IP in FORWARDING_RULE_IP_ADDRESS; do
   RESULTS=
   for i in {1..1000}; do RESULTS="$RESULTS:`curl ${LB_IP}`"; done >/dev/null 2>&1
   IFS=':'
   echo "***"
   echo "*** Results of load balancing to $LB_IP: "
   echo "***"
   for line in $RESULTS; do echo $line; done | grep -Ev "^$" | sort | uniq -c
   echo
done
Vérifier les résultats
***
***Results of load balancing to FORWARDING_RULE_IP_ADDRESS:
***
502 red-instance-group-9jvq
498 red-instance-group-sww8

Envoyer des requêtes à FORWARDING_RULE_IP_ADDRESS/PREFIX

Envoyez les requêtes à FORWARDING_RULE_IP_ADDRESS/PREFIX et notez la répartition du trafic.

for LB_IP in FORWARDING_RULE_IP_ADDRESS; do
    RESULTS=
    for i in {1..1000}; do RESULTS="$RESULTS:`curl ${LB_IP}/PREFIX/index.html`"; done >/dev/null 2>&1
    IFS=':'
    echo "***"
    echo "*** Results of load balancing to $LB_IP/PREFIX: "
    echo "***"
    for line in $RESULTS; do echo $line; done | grep -Ev "^$" | sort | uniq -c
    echo
done
Vérifier les résultats
***
***Results of load balancing to FORWARDING_RULE_IP_ADDRESS/PREFIX:
***
21 blue-instance-group-8n49
27 blue-instance-group-vlqc
476 green-instance-group-c0wv
476 green-instance-group-rmf4

La configuration Canary envoie effectivement 95 % des requêtes /PREFIX au service green et 5 % au service blue.

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.

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

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

  3. Dans le fichier red-service-config.yaml, supprimez la ligne suivante :

    sessionAffinity: NONE

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

Pour plus d'informations sur la journalisation et la surveillance, consultez la section Journaux et surveillance HTTP(S) internes.

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