Configurer la gestion avancée du trafic avec Envoy

Ce document fournit des informations sur la configuration de la gestion avancée du trafic pour votre déploiement Traffic Director.

Avant de commencer

Avant de configurer la gestion avancée du trafic, suivez les instructions de la section Préparer la configuration de Traffic Director avec Envoy, y compris la configuration de Traffic Director et des hôtes de machine virtuelle (VM) ou les clusters Google Kubernetes Engine (GKE) dont vous avez besoin. Créez les ressources Google Cloud requises.

La disponibilité des fonctionnalités avancées de gestion du trafic varie en fonction du protocole de requête que vous choisissez. Ce protocole est configuré lorsque vous configurez le routage à l'aide du proxy HTTP ou HTTPS cible, du proxy gRPC cible ou de la ressource de proxy TCP cible :

  • Avec le proxy HTTP cible et le proxy HTTPS cible, toutes les fonctionnalités décrites dans ce document sont disponibles.
  • Avec le proxy gRPC cible, certaines fonctionnalités sont disponibles.
  • Avec le proxy TCP cible, aucune fonctionnalité avancée de gestion du trafic n'est disponible.

Pour en savoir plus, consultez les pages Fonctionnalités de Traffic Director et Gestion avancée du trafic. Pour obtenir un guide de configuration de bout en bout, consultez la page Configurer la gestion avancée du trafic avec des services gRPC sans proxy.

Configurer la répartition du trafic

Ces instructions partent du principe que :

  • Votre déploiement Traffic Director dispose d'un mappage d'URL appelé review-url-map.
  • Le mappage d'URL envoie tout le trafic vers un service de backend, appelé review1, qui sert de service de backend par défaut.
  • Vous prévoyez d'acheminer 5 % du trafic vers une nouvelle version d'un service. Ce service s'exécute sur une VM de backend ou un point de terminaison dans un groupe de points de terminaison du réseau (NEG) associé au service de backend review2.
  • Aucune règle d'hôte ni aucun outil de mise en correspondance des chemins d'accès n'est utilisé.

Pour configurer la répartition du trafic, procédez comme suit.

Console

  1. Dans Google Cloud Console, accédez à la page Traffic Director.

    Accéder à Traffic Director

  2. Cliquez sur Cartes des règles de routage.

  3. Cliquez sur Créer une carte des règles de routage.

  4. Sur la page Créer une carte des règles de routage, saisissez un Nom.

  5. Dans le menu Protocole, sélectionnez HTTP.

  6. Sélectionnez une règle de transfert existante.

  7. Sous Règles de routage, sélectionnez Règle avancée d'hôte, de chemin d'accès et de routage.

  8. Sous Hôtes et outils de mise en correspondance des chemins d'accès, cliquez sur Ajouter des hôtes et un outil de mise en correspondance des chemins d'accès. Un nouvel outil de mise en correspondance des chemins d'accès que vous pouvez configurer pour répartir le trafic est ainsi ajouté.

  9. Ajoutez les paramètres suivants à la zone Outil de mise en correspondance des chemins d'accès :

        - defaultService: global/backendServices/review1
          name: matcher1
          routeRules:
          - priority: 2
            matchRules:
            - prefixMatch: ''
            routeAction:
             weightedBackendServices:
             - backendService: global/backendServices/review1
               weight: 95
             - backendService: global/backendServices/review2
               weight: 5
    
  10. Cliquez sur OK.

  11. Cliquez sur Enregistrer.

Une fois que vous êtes satisfait de la nouvelle version, vous pouvez ajuster progressivement les pondérations des deux services et envoyer tout le trafic vers review2.

gcloud

  1. Exécutez la commande gcloud export pour obtenir la configuration de mappage d'URL :

    gcloud compute url-maps export review-url-map \
        --destination=review-url-map-config.yaml
    
  2. Ajoutez la section suivante au fichier review-url-map-config.yaml :

         hostRules:
         - description: ''
          hosts:
           - '*'
         pathMatcher: matcher1
         pathMatchers:
         - defaultService: global/backendServices/review1
           name: matcher1
           routeRules:
           - priority: 2
             matchRules:
             - prefixMatch: ''
             routeAction:
              weightedBackendServices:
              - backendService: global/backendServices/review1
                weight: 95
              - backendService: global/backendServices/review2
                weight: 5
    
  3. Mettez à jour le mappage d'URL :

    gcloud compute url-maps import review-url-map \
        --source=review-url-map-config.yaml
    

Une fois que vous êtes satisfait de la nouvelle version, vous pouvez ajuster progressivement les pondérations des deux services et envoyer tout le trafic vers review2.

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 une limite que vous avez définie, le client cesse 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.

Ainsi, la rupture du circuit évite les défaillances en cascade en renvoyant une erreur au client plutôt que de surcharger un backend. Cela permet de diffuser du trafic tout en palliant les situations de surcharge, telles que les pics de charge, en augmentant la capacité via l'autoscaling.

Dans l'exemple suivant, vous définissez les ruptures de circuit comme suit :

  • Nombre maximal de requêtes par connexion : 100
  • Nombre maximal de connexions : 1 000
  • Nombre maximal de requêtes en attente : 200
  • Nombre maximal de requêtes : 1000
  • Nombre maximal de nouvelles tentatives : 3

Pour configurer la rupture de circuit, procédez comme suit.

Console

  1. Dans Cloud Console, accédez à la page Traffic Director.

    Accéder à Traffic Director

  2. Cliquez sur le nom du service de backend que vous souhaitez modifier.

  3. Cliquez sur Modifier ().

  4. Cliquez sur Configurations avancées.

  5. Sous Ruptures de circuit, cochez la case Activer.

  6. Cliquez sur Modifier ().

    1. Dans le champ Nombre maximal de requêtes par connexion, saisissez 100.
    2. Dans le champ Nombre maximal de connexions, saisissez 1000.
    3. Dans Nombre maximal de requêtes en attente, saisissez 200.
    4. Dans le champ Nombre maximal de requêtes, saisissez 1000.
    5. Dans le champ Nombre maximal de nouvelles tentatives saisissez 3.
  7. Cliquez sur Enregistrer, puis à nouveau sur Enregistrer.

gcloud

  1. Exécutez la commande gcloud export pour exporter la configuration du service de backend. Remplacez BACKEND_SERVICE_NAME par le nom du service de backend.

     gcloud compute backend-services export BACKEND_SERVICE_NAME \
         --destination=BACKEND_SERVICE_NAME-config.yaml --global
    
  2. Mettez à jour le fichier BACKEND_SERVICE_NAME.yaml comme suit :

     affinityCookieTtlSec: 0
     backends:
     - balancingMode: UTILIZATION
       capacityScaler: 1.0
        group:https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instanceGroups/INSTANCE_GROUP_NAME
       maxUtilization: 0.8
     circuitBreakers:
       maxConnections: 1000
       maxPendingRequests: 200
       maxRequests: 1000
       maxRequestsPerConnection: 100
       maxRetries: 3
     connectionDraining:
       drainingTimeoutSec: 300
     healthChecks:
       - https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/healthChecks/HEALTH_CHECK_NAME
     loadBalancingScheme: INTERNAL_SELF_MANAGED
     localityLbPolicy: ROUND_ROBIN
     name: BACKEND_SERVICE_NAME
     port: 80
     portName: http
     protocol: HTTP
     sessionAffinity: NONE
     timeoutSec: 30
    
  3. Mettez à jour le fichier de configuration du service de backend :

    gcloud compute backend-services import BACKEND_SERVICE_NAME \
        --source=BACKEND_SERVICE_NAME-config.yaml --global
    

Exemple de rupture de circuit

L'exemple de disjoncteur suivant est un cas d'utilisation dans lequel un service de panier comporte un groupe d'instances en tant que backend. Les paramètres du disjoncteur indiquent les limites suivantes :

  • Nombre maximal de requêtes par connexion : 100
  • Nombre maximal de connexions : 1 000
  • Nombre maximal de requêtes en attente : 200
  • Nombre maximal de requêtes : 20 000
  • Nombre maximal de nouvelles tentatives : 3

Pour configurer cet exemple de rupture de circuit, procédez comme suit :

Console

  1. Dans Cloud Console, accédez à la page Traffic Director.

    Accéder à Traffic Director

  2. Cliquez sur le nom du service de backend que vous souhaitez modifier.

  3. Cliquez sur Modifier ().

  4. Cliquez sur Configurations avancées.

  5. Sous Ruptures de circuit, cochez la case Activer.

  6. Cliquez sur Modifier ().

    1. Dans le champ Nombre maximal de requêtes par connexion, saisissez 100.
    2. Dans le champ Nombre maximal de connexions, saisissez 1000.
    3. Dans Nombre maximal de requêtes en attente, saisissez 200.
    4. Dans le champ Nombre maximal de requêtes, saisissez 20000.
    5. Dans le champ Nombre maximal de nouvelles tentatives saisissez 3.
  7. Cliquez sur Enregistrer, puis à nouveau sur Enregistrer.

gcloud

  1. Exécutez la commande gcloud export pour exporter la configuration du service de backend. Remplacez BACKEND_SERVICE_NAME par le nom du service de backend.

    gcloud compute backend-services export BACKEND_SERVICE_NAME \
        --destination=BACKEND_SERVICE_NAME-config.yaml --global
    
  2. Mettez à jour le fichier BACKEND_SERVICE_NAME.yaml comme suit :

     affinityCookieTtlSec: 0
     backends:
     - balancingMode: UTILIZATION
       capacityScaler: 1.0
        group:https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instanceGroups/INSTANCE_GROUP_NAME
       maxUtilization: 0.8
     circuitBreakers:
       maxConnections: 1000
       maxPendingRequests: 200
       maxRequests: 20000
       maxRequestsPerConnection: 100
       maxRetries: 3
     connectionDraining:
       drainingTimeoutSec: 300
     healthChecks:
       -  https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/healthChecks/HEALTH_CHECK_NAME
     loadBalancingScheme: INTERNAL_SELF_MANAGED
     localityLbPolicy: ROUND_ROBIN
     name: BACKEND_SERVICE_NAME
     port: 80
     portName: http
     protocol: HTTP
     sessionAffinity: NONE
     timeoutSec: 30
    
  3. Mettez à jour le fichier de configuration du service de backend :

    gcloud compute backend-services import BACKEND_SERVICE_NAME \
        --source=BACKEND_SERVICE_NAME-config.yaml --global
    

La gestion avancée du trafic vous permet de configurer l'affinité de session en fonction d'un cookie fourni.

Pour configurer l'affinité de session avec HTTP_COOKIE, procédez comme suit.

Console

  1. Dans Cloud Console, accédez à la page Traffic Director.

    Accéder à Traffic Director

  2. Cliquez sur le nom du service de backend que vous souhaitez modifier.

  3. Cliquez sur Modifier ().

  4. Cliquez sur Configurations avancées.

  5. Sous Affinité de session, sélectionnez Cookie HTTP.

  6. Sous Règle d'équilibrage de charge de la zone, sélectionnez Hachage en anneau.

    1. Dans le champ Nom du cookie HTTP, saisissez http_cookie.
    2. Dans le champ Chemin du cookie HTTP, saisissez /cookie_path.
    3. Dans le champ Valeur TTL du cookie HTTP, saisissez 100.
    4. Dans le champ Taille minimale de hachage en anneau, saisissez 10000.
  7. Cliquez sur Enregistrer.

gcloud

  1. Exécutez la commande gcloud export pour exporter la configuration du service de backend. Remplacez BACKEND_SERVICE_NAME par le nom du service de backend.

    gcloud compute backend-services export BACKEND_SERVICE_NAME \
        --destination=BACKEND_SERVICE_NAME-config.yaml --global
    
  2. Mettez à jour le fichier YAML comme suit :

    sessionAffinity: 'HTTP_COOKIE'
    localityLbPolicy: 'RING_HASH'
    consistentHash:
    httpCookie:
      name: 'http_cookie'
      path: '/cookie_path'
      ttl:
        seconds: 100
        nanos: 30
    minimumRingSize: 10000
    
  3. Importez le fichier de configuration du service de backend :

    gcloud compute backend-services import BACKEND_SERVICE_NAME \
        --source=BACKEND_SERVICE_NAME-config.yaml --global
    

Configurer la détection des anomalies

La détection d'anomalies permet de contrôler l'exclusion des hôtes défaillants du pool d'équilibrage de charge. Pour ce faire, Traffic Director constitue un ensemble de règles qui spécifient les critères d'exclusion des VM de 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.

Dans l'exemple suivant, le service de backend dispose d'un groupe d'instances en tant que backend. Le paramètre de détection des anomalies spécifie que l'analyse de détection des anomalies est exécutée toutes les secondes. Si un point de terminaison renvoie cinq erreurs 5xx consécutives, il est exclu de la décision d'équilibrage de charge pendant 30 secondes la première fois. Le temps d'éjection réel d'un même point de terminaison est de 30 secondes multiplié par le nombre de fois où il est éjecté.

Pour configurer la détection des anomalies sur la ressource du service de backend, procédez comme suit.

Console

  1. Dans Cloud Console, accédez à la page Traffic Director.

    Accéder à Traffic Director

  2. Cliquez sur le nom d'un service.

  3. Cliquez sur Modifier ().

  4. Cliquez sur Configurations avancées.

  5. Cochez la case Détection des anomalies.

  6. Cliquez sur Modifier ().

    1. Définissez Erreurs consécutives sur 5.
    2. Définissez l'intervalle sur 1000 millisecondes.
    3. Définissez la durée d'éjection de base sur 30000 millisecondes.
  7. Cliquez sur Enregistrer, puis à nouveau sur Enregistrer.

gcloud

  1. Exécutez la commande gcloud export pour exporter la configuration du service de backend. Remplacez BACKEND_SERVICE_NAME par le nom du service de backend.

    gcloud compute backend-services export BACKEND_SERVICE_NAME \
        --destination=BACKEND_SERVICE_NAME-config.yaml --global
    
  2. Mettez à jour le fichier YAML comme suit, en remplaçant le nom du service de backend par BACKEND_SERVICE_NAME :

    name: BACKEND_SERVICE_NAME
    loadBalancingScheme: INTERNAL_SELF_MANAGED
    backends:
    - balancingMode: UTILIZATION
     capacityScaler: 1.0
     group: $INSTANCE_GROUP_URL
    healthChecks:
    - $HEALTH_CHECK_URL
    port: 80
    portName: http
    protocol: HTTP
    outlierDetection:
     consecutiveErrors: 5,
     interval:
         seconds: 1,
         nanos: 0
     baseEjectionTime:
         seconds: 30,
         nanos: 0
    
  3. Importez le fichier de configuration du service de backend :

    gcloud compute backend-services import BACKEND_SERVICE_NAME \
        --source=BACKEND_SERVICE_NAME-config.yaml --global
    

Définir la règle d'équilibrage de charge de la zone

Utilisez la règle d'équilibrage de charge de la zone pour choisir un algorithme d'équilibrage de charge en fonction de la pondération et de la priorité de la zone fournie par Traffic Director. Par exemple, vous pouvez effectuer une interrogation pondérée à répétition alternée (round robin) entre les points de terminaison opérationnels, ou effectuer un hachage cohérent.

Dans l'exemple suivant, le service de backend dispose d'un groupe d'instances en tant que backend. La règle d'équilibrage de charge de la zone géographique est définie sur RING_HASH.

Pour définir la règle d'équilibrage de charge de la zone, procédez comme suit.

Console

  1. Dans Cloud Console, accédez à la page Traffic Director.

    Accéder à Traffic Director

  2. Cliquez sur le nom d'un service.

  3. Cliquez sur Modifier ().

  4. Cliquez sur Configurations avancées.

  5. Sous Règle de trafic, dans le menu Règle d'équilibrage de charge de la zone, sélectionnez Hachage en anneau.

  6. Cliquez sur Enregistrer.

gcloud

  1. Exécutez la commande gcloud export pour exporter la configuration du service de backend. Remplacez BACKEND_SERVICE_NAME par le nom du service de backend.

    gcloud compute backend-services export BACKEND_SERVICE_NAME \
        --destination=BACKEND_SERVICE_NAME-config.yaml --global
    
  2. Mettez à jour le fichier BACKEND_SERVICE_NAME.yaml comme suit :

    name: shopping-cart-service
    loadBalancingScheme: INTERNAL_SELF_MANAGED
    backends:
    - balancingMode: UTILIZATION
     capacityScaler: 1.0
     group: $INSTANCE_GROUP_URL
    healthChecks:
    - $HEALTH_CHECK_URL
    port: 80
    portName: http
    protocol: HTTP
    localityLbPolicy: RING_HASH
    
  3. Importez le fichier de configuration du service de backend :

    gcloud compute backend-services import BACKEND_SERVICE_NAME \
        --source=BACKEND_SERVICE_NAME-config.yaml --global
    

Pour en savoir plus sur le fonctionnement de l'équilibrage de charge de la zone, consultez la documentation sur la ressource backendService.

Configurer le filtrage des configurations en fonction de la correspondance MetadataFilters

Les filtres MetadataFilters sont activés avec des règles de transfert et HttpRouteRuleMatch. Utilisez cette fonctionnalité pour contrôler une règle de transfert ou une règle de routage particulière de sorte que le plan de contrôle envoie la règle de transfert ou la règle de routage uniquement aux proxys dont les métadonnées de nœud correspondent au paramètre de filtre de métadonnées. Si vous ne spécifiez aucun filtre MetadataFilters, la règle est envoyée à tous les proxys Envoy.

Cette fonctionnalité facilite le déploiement progressif d'une configuration. Par exemple, créez une règle de transfert nommée forwarding-rule1, que vous ne souhaitez transmettre qu'aux Envoy dont les métadonnées de nœud contiennent app: review et version: canary.

Pour ajouter MetadataFilters à une règle de transfert, procédez comme suit.

gcloud

  1. Utilisez la commande gcloud export pour obtenir la configuration de la règle de transfert :

    gcloud compute forwarding-rules export forwarding-rule1 \
        --destination=forwarding-rule1-config.yaml \
        --global
    
  2. Supprimez la règle de transfert :

    gcloud compute forwarding-rules delete forwarding-rule1 \
        --global
    
  3. Mettez à jour le fichier forwarding-rule1-config.yaml.

    L'exemple suivant crée un filtre de métadonnées MATCH_ALL:

     metadataFilters:
     - filterMatchCriteria: 'MATCH_ALL'
       filterLabels:
       - name: 'app'
         value: 'review'
       - name: 'version'
         value: 'canary'
    

    L'exemple suivant crée un filtre de métadonnées MATCH_ANY:

     metadataFilters:
     - filterMatchCriteria: 'MATCH_ANY'
       filterLabels:
       - name: 'app'
         value: 'review'
       - name: 'version'
         value: 'production'
    
  4. Supprimez tous les champs exclusivement de sortie du fichier forwarding-rule1-config.yaml. Pour en savoir plus, consultez la documentation de gcloud compute forwarding-rules import.

  5. Utilisez la commande gcloud import pour mettre à jour le fichier forwarding-rule1-config.yaml :

    gcloud compute forwarding-rules import forwarding-rule1 \
        --source=forwarding-rule1-config.yaml \
        --global
    
  6. Suivez ces instructions pour ajouter des métadonnées de nœud à Envoy avant de démarrer Envoy. Seule une valeur de chaîne est acceptée.

    a. Pour un déploiement basé sur une VM, dans le fichier bootstrap_template.yaml, ajoutez les éléments suivants sous la section metadata :

       app: 'review'
       version: 'canary'
    

    b. Pour un déploiement basé sur Google Kubernetes Engine ou Kubernetes, dans le fichier trafficdirector_istio_sidecar.yaml, ajoutez les éléments suivants sous la section env :

       - name: ISTIO_META_app
         value: 'review'
       - name: ISTIO_META_version
         value: 'canary'
    

Exemples de filtrage de métadonnées

Utilisez les instructions suivantes pour un scénario dans lequel plusieurs projets se trouvent dans le même réseau VPC partagé et où vous souhaitez que les ressources Traffic Director de chaque projet de service soient visibles par les proxys du même projet.

La configuration du VPC partagé est la suivante :

  • Nom du projet hôte : vpc-host-project
  • Projets de service : project1, project2
  • Services de backend avec instances ou points de terminaison exécutant un proxy compatible xDS dans project1 et project2

Pour configurer Traffic Director de façon à isoler project1, procédez comme suit.

gcloud

  1. Créez toutes les règles de transfert dans project1 avec le filtre de métadonnées suivant :

         metadataFilters:
         - filterMatchCriteria: 'MATCH_ALL'
           filterLabels
           - name: 'project_name'
             value: 'project1'
           - name: 'version'
             value: 'production'
    
  2. Lorsque vous configurez les proxys déployés sur des instances ou des points de terminaison dans project1, incluez les métadonnées suivantes dans la section des métadonnées de nœud du fichier d'amorçage :

       project_name: 'project1'
       version: 'production'
    
  3. Vérifiez que les proxys déjà déployés dans project2 n'ont pas reçu la règle de transfert créée à la première étape. Pour ce faire, essayez d'accéder aux services de project1 à partir d'un système exécutant un proxy dans project2. Pour savoir comment vérifier qu'une configuration Traffic Director fonctionne correctement, consultez la page Vérifier la configuration.

Pour tester une nouvelle configuration sur un sous-ensemble de proxys avant de la rendre disponible pour tous les proxys, procédez comme suit.

gcloud

  1. Démarrez les proxys que vous utilisez pour les tests avec les métadonnées de nœud suivantes. N'incluez pas ces métadonnées de nœuds pour les proxys que vous n'utilisez pas pour les tests.

      version: 'test'
    
  2. Pour chaque nouvelle règle de transfert que vous souhaitez tester, incluez le filtre de métadonnées suivant :

      metadataFilters:
      - filterMatchCriteria: 'MATCH_ALL'
        filterLabels:
        - name: 'version'
          value: 'test'
    
  3. Testez la nouvelle configuration en envoyant du trafic aux proxys de test et apportez les modifications nécessaires. Si la nouvelle configuration fonctionne correctement, seuls les proxys que vous testez reçoivent la nouvelle configuration. Les proxys restants ne reçoivent pas la nouvelle configuration et ne peuvent pas l'utiliser.

  4. Lorsque vous vérifiez que la nouvelle configuration fonctionne correctement, supprimez le filtre de métadonnées qui lui est associé. Cela permet à tous les proxys de recevoir la nouvelle configuration.

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 : Les règles de routage étant interprétées dans l'ordre de priorité, examinez la priorité attribuée à chaque règle.

Lorsque vous définissez des règles de routage, assurez-vous que les règles de priorité supérieure (c'est-à-dire avec des numéros de priorité inférieurs) n'acheminent pas accidentellement du trafic qui aurait été acheminé par une règle de routage ultérieure. Prenons l'exemple suivant :

  • Première règle de routage

    • La règle de routage correspond à pathPrefix = /shopping/
    • Action de redirection : envoyer du trafic au service de backend service-1
    • Priorité de la règle : 4
  • Deuxième règle de routage

    • La règle de routage correspond à regexMatch = /shopping/cart/ordering/.*
    • Action de redirection : envoyer du trafic au service de backend service-2
    • Priorité de la règle : 8

Dans ce cas, une requête dont le chemin est /shopping/cart/ordering/cart.html est acheminée vers service-1. Même si la deuxième règle avait correspondu, elle aurait été ignorée, car la première règle avait la priorité.

Étape suivante