Anthos Service Mesh et Traffic Director sont désormais Cloud Service Mesh. Pour en savoir plus, consultez la présentation de Cloud Service Mesh.

Cette page a été traduite par l'API Cloud Translation.

Configurer la gestion avancée du trafic avec Envoy

Cette configuration est compatible avec les clients en version Preview, mais nous ne la recommandons pas aux nouveaux utilisateurs de Cloud Service Mesh. Pour en savoir plus, consultez la présentation du routage des services Cloud Service Mesh.

Ce document fournit des informations sur la configuration de la gestion avancée du trafic pour les déploiements Cloud Service Mesh qui utilisent Envoy.

Avant de commencer

Avant de configurer la gestion avancée du trafic, suivez les instructions de la section Préparer la configuration de Cloud Service Mesh avec Envoy, y compris la configuration de Cloud Service Mesh et des hôtes de machine virtuelle (VM) ou des 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 Cloud Service Mesh 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 Cloud Service Mesh 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é.

Si vous répartissez le trafic vers un nouveau service qui n'a pas encore été référencé par le mappage d'URL, ajoutez d'abord le nouveau service à weightedBackendServices et attribuez-lui une pondération de 0. Ensuite, augmentez progressivement la pondération attribuée à ce service.

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

Console

Dans la console Google Cloud, accédez à la page Cloud Service Mesh.

Accéder à Cloud Service Mesh
Cliquez sur Cartes des règles de routage.
Cliquez sur Créer une carte des règles de routage.
Sur la page Créer une carte des règles de routage, saisissez un Nom.
Dans le menu Protocole, sélectionnez HTTP.
Sélectionnez une règle de transfert existante.
Sous Règles de routage, sélectionnez Règle avancée d'hôte, de chemin d'accès et de routage.
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é.

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

Cliquez sur OK.
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

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

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

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 une version partielle

Utilisez un processus de déploiement partiel, parfois appelé création de versions Canary, pour publier une nouvelle version logicielle sur une petite partie de serveurs avant de publier la nouvelle version jusqu'à l'équilibre de vos serveurs de production.

Une version partielle utilise weightedBackendServices. Pour activer une version partielle, désignez un service de backend en tant que service de test, ou Canary, et attribuez-lui une pondération faible, par exemple 2 ou 5. Déployez votre nouvelle version logicielle uniquement sur ces serveurs. Une fois que vous êtes certain que la nouvelle version ne présente aucun problème, déployez-la dans le reste de vos services.

Pour activer une version partielle, utilisez l'exemple de code YAML suivant :

pathMatchers:
     - defaultService: DEFAULT_SERVICE_URL
       name: matcher1
       routeRules:
       - matchRules:
         - prefixMatch: '/'
         routeAction:
          weightedBackendServices:
          - backendService: BACKEND_SERVICE_PARTIAL_URL
            weight: 2
          - backendService: BACKEND_SERVICE_URL
            weight: 98

DEFAULT_SERVICE_URL est l'URL par défaut de votre service.
BACKEND_SERVICE_PARTIAL_URL est l'URL du service de backend qui reçoit 2 % du trafic.
BACKEND_SERVICE_URL est l'URL du service de backend qui reçoit 98 % du trafic.

Configurer des déploiements bleu-vert

Les déploiements bleu-vert sont des modèles de version qui réduisent le temps nécessaire pour basculer le trafic de production vers une nouvelle version d'un service ou pour effectuer un rollback d'une version précédente. Ces déploiements conservent les deux versions du service en production et basculent le trafic de l'une à l'autre.

Les déploiements bleu-vert utilisent weightedBackendServices. Dans l'exemple YAML qui suit, les backends de SERVICE_BLUE_URL sont entièrement déployés avec la version de production actuelle et les backends vers SERVICE_GREEN_URL sont entièrement déployés avec la nouvelle version. Dans l'exemple de configuration, le déploiement GREEN reçoit 100 % du trafic de production. Si vous rencontrez des problèmes, vous pouvez inverser les pondérations des deux déploiements, ce qui rétablit la version GREEN défectueuse et rétablit la version BLUE correcte. Dans les deux cas, le transfert du trafic peut être rapide, car les deux versions sont disponibles pour recevoir du trafic.

Pour activer un déploiement bleu-vert, utilisez l'exemple de code YAML suivant :

pathMatchers:
     - defaultService: DEFAULT_SERVICE_URL
       name: matcher1
       routeRules:
       - matchRules:
         - prefixMatch: '/'
         routeAction:
          weightedBackendServices:
          - backendService: BACKEND_SERVICE_BLUE_URL
            weight: 0
          - backendService: BACKEND_SERVICE_GREEN_URL
            weight: 100

DEFAULT_SERVICE_URL est l'URL par défaut de votre service.
BACKEND_SERVICE_BLUE_URL est l'URL du service de backend qui ne reçoit aucun trafic.
BACKEND_SERVICE_GREEN_URL est l'URL du service de backend qui reçoit 100 % de votre trafic.

Configurer la mise en miroir du trafic

Utilisez la mise en miroir du trafic lorsque vous souhaitez qu'il soit dirigé vers deux services de backend différents à des fins de débogage ou de test des nouveaux services.

Dans l'exemple suivant, toutes les requêtes sont envoyées à SERVICE_URL et à MIRROR_SERVICE_URL. Seules les réponses de SERVICE_URL sont renvoyées au client. MIRROR_SERVICE_URL n'a aucun impact sur le client.

Pour configurer la mise en miroir du trafic, procédez comme suit :

Console

Dans la console Google Cloud, accédez à la page Cloud Service Mesh.

Accéder à Cloud Service Mesh
Cliquez sur Cartes des règles de routage.
Cliquez sur Créer une carte des règles de routage.
Sur la page Créer une carte des règles de routage, saisissez un Nom.
Dans la liste Protocole, sélectionnez HTTP.
Sélectionnez une règle de transfert existante.
Sous Règles de routage, sélectionnez Règle avancée d'hôte, de chemin d'accès et de routage.
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 mettre en miroir le trafic est ainsi ajouté.

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

    - defaultService: DEFAULT_SERVICE_URL
      name: matcher1
      routeRules:
      - matchRules:
        - prefixMatch: '/'
        routeAction:
         weightedBackendServices:
         - backendService: BACKEND_SERVICE_URL
           weight: 100
         requestMirrorPolicy:
           backendService: BACKEND_SERVICE_MIRROR_URL

DEFAULT_SERVICE_URL est l'URL par défaut de votre service.
BACKEND_SERVICE_URL est l'URL du backend mis en miroir.
BACKEND_SERVICE_MIRROR_URL est l'URL du service de backend vers lequel vous effectuez la mise en miroir.

Cliquez sur OK.
Cliquez sur Enregistrer.

gcloud

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

Ajoutez la section suivante au fichier review-url-map-config.yaml :

     hostRules:
     - description: ''
      hosts:
       - '*'
     pathMatcher: matcher1
     pathMatchers:
    - defaultService: DEFAULT_SERVICE_URL
      name: matcher1
      routeRules:
      - matchRules:
        - prefixMatch: '/'
        routeAction:
         weightedBackendServices:
         - backendService: BACKEND_SERVICE_URL
           weight: 100
         requestMirrorPolicy:
           backendService: BACKEND_SERVICE_MIRROR_URL

DEFAULT_SERVICE_URL est l'URL par défaut de votre service.
BACKEND_SERVICE_URL est l'URL du backend mis en miroir.
BACKEND_SERVICE_MIRROR_URL est l'URL du service de backend vers lequel vous effectuez la mise en miroir.

Mettez à jour le mappage d'URL :

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

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

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

Dans la console Google Cloud, accédez à la page Cloud Service Mesh.

Accéder à Cloud Service Mesh
Cliquez sur le nom du service de backend que vous souhaitez modifier.
Cliquez sur Modifier ().
Cliquez sur Configurations avancées.
Sous Ruptures de circuit, cochez la case Activer.
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.
Cliquez sur Enregistrer, puis à nouveau sur Enregistrer.

gcloud

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
```

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

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

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

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

Dans la console Google Cloud, accédez à la page Cloud Service Mesh.

Accéder à Cloud Service Mesh
Cliquez sur le nom du service de backend que vous souhaitez modifier.
Cliquez sur Modifier ().
Cliquez sur Configurations avancées.
Sous Affinité de session, sélectionnez Cookie HTTP.
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.
Cliquez sur Enregistrer.

gcloud

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
```

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

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, Cloud Service Mesh 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

Dans la console Google Cloud, accédez à la page Cloud Service Mesh.

Accéder à Cloud Service Mesh
Cliquez sur le nom d'un service.
Cliquez sur Modifier ().
Cliquez sur Configurations avancées.
Cochez la case Détection des anomalies.
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.
Cliquez sur Enregistrer, puis à nouveau sur Enregistrer.

gcloud

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
```

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

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 Cloud Service Mesh. 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

Dans la console Google Cloud, accédez à la page Cloud Service Mesh.

Accéder à Cloud Service Mesh
Cliquez sur le nom d'un service.
Cliquez sur Modifier ().
Cliquez sur Configurations avancées.
Sous Règle de trafic, dans le menu Règle d'équilibrage de charge de la zone, sélectionnez Hachage en anneau.
Cliquez sur Enregistrer.

gcloud

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
```

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

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 la redirection d'URL

Ces instructions partent du principe que :

Votre déploiement Cloud Service Mesh 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 souhaitez rediriger le trafic d'un hôte à un autre.

Pour configurer la redirection d'URL, procédez comme suit :

Console

Dans la console Google Cloud, accédez à la page Cloud Service Mesh.

Accéder à Cloud Service Mesh
Cliquez sur Cartes des règles de routage.
Cliquez sur Créer une carte des règles de routage.
Sur la page Créer une carte des règles de routage, saisissez un Nom.
Dans le menu Protocole, sélectionnez HTTP.
Sélectionnez une règle de transfert existante.
Sous Règles de routage, sélectionnez Règle avancée d'hôte, de chemin d'accès et de routage.
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. Cela ajoute un outil de mise en correspondance des chemins d'accès qui redirige le trafic.

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

    - defaultService: global/backendServices/review1
      name: matcher1
      routeRules:
      - matchRules:
        - prefixMatch: ''
        urlRedirect:
         hostRedirect: '[REDIRECT_HOST]'
         pathRedirect: '[REDIRECT_URL]'
         redirectResponseCode: 'FOUND',
        stripQuery: True

Cliquez sur OK.
Cliquez sur Enregistrer.

gcloud

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

Ajoutez la section suivante au fichier review-url-map-config.yaml :

     hostRules:
     - description: ''
      hosts:
       - '*'
     pathMatcher: matcher1
     pathMatchers:
    - defaultService: global/backendServices/review1
      name: matcher1
      routeRules:
      - matchRules:
        - prefixMatch: ''
        urlRedirect:
         hostRedirect: '[REDIRECT_HOST]'
         pathRedirect: '[REDIRECT_URL]'
         redirectResponseCode: 'FOUND',
        stripQuery: True

Mettez à jour le mappage d'URL :

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

Configurer l'orientation du trafic avec la réécriture d'URL

L'orientation du trafic vous permet de diriger le trafic vers différents services de backend en fonction d'attributs de la requête tels que les valeurs d'en-tête. En outre, vous pouvez configurer des actions telles que la réécriture de l'URL dans la requête avant que la requête ne soit dirigée vers le service de backend.

Dans l'exemple suivant, la requête est dirigée vers SERVICE_ANDROID_URL si le chemin de la requête porte le préfixe /mobile/ et le User-Agent de la requête contient Android. Avant d'envoyer la requête au service de backend, vous pouvez remplacer le préfixe d'URL par REWRITE_PATH_ANDROID, par exemple, /android/. Cependant, si le chemin est précédé de /mobile/ et comporte un User-Agent contenant iPhone, le trafic est dirigé vers SERVICE_IPHONE_URL et le préfixe d'URL est remplacé par REWRITE_PATH_IPHONE. Toutes les autres requêtes précédées du préfixe /mobile/ et dont le champ User-Agent a une valeur autre que Android ou iOS sont adressées à SERVICE_GENERIC_DEVICE_URL.

pathMatchers:
     - defaultService: [DEFAULT_SERVICE_URL]
       name: matcher1
       routeRules:
       - matchRules:
         - prefixMatch: /mobile/
           headerMatches:
           - headerName: User-Agent
             regexMatch: .*Android.*
         service: $[SERVICE_ANDROID_URL]
         routeAction:
           urlRewrite:
             pathPrefixRewrite: [REWRITE_PATH_ANDROID]
       - matchRules:
         - prefixMatch: /mobile/
           headerMatches:
           - headerName: User-Agent
             regexMatch: .*iPhone.*
         service: [SERVICE_IPHONE_URL]
         routeAction:
           urlRewrite:
             pathPrefixRewrite: [REWRITE_PATH_IPHONE]
       - matchRules:
         - prefixMatch: /mobile/
         service: [SERVICE_GENERIC_DEVICE_URL]

Configurer l'injection de pannes

L'injection de pannes permet d'injecter un délai fixe ou un arrêt forcé, appelé un abandon, sur une route particulière, afin de tester la résilience d'une application.

Dans l'exemple suivant, toutes les requêtes sont envoyées à SERVICE_URL, avec un délai fixe de 10 secondes ajouté à 100 % des requêtes. Le client qui envoie les requêtes voit que toutes les réponses sont retardées de 10 secondes. De plus, une erreur d'arrêt avec une réponse 503 Service Unavailable est appliquée à 50 % des requêtes. Le client voit que 50 % de ses requêtes reçoivent une réponse 503. Ces requêtes n'atteignent pas du tout le service de backend.

pathMatchers:
     - defaultService: [DEFAULT_SERVICE_URL]
       name: matcher1
       routeRules:
       - matchRules:
         - prefixMatch: '/'
         routeAction:
          weightedBackendServices:
          - backendService: [SERVICE_URL]
            weight: 100
          faultInjectionPolicy:
            delay:
              fixedDelay:
                seconds: 10
                nanos: 0
              percentage: 100
            abort:
              httpStatus: 503
              percentage: 50

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

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

Supprimez la règle de transfert :

gcloud compute forwarding-rules delete forwarding-rule1 \
    --global

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'

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.

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

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 Cloud Service Mesh 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 Cloud Service Mesh de façon à isoler project1, procédez comme suit:

gcloud

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'

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'
```
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 Cloud Service Mesh 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

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'
```

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'

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

Bloquer le trafic entre les services

Si vous souhaitez bloquer le trafic entre le service A et le service B, et que votre déploiement se trouve sur GKE, configurez la sécurité du service et utilisez une règle d'autorisation pour bloquer le trafic entre les services. Pour obtenir des instructions complètes, consultez la page Sécurité du service Cloud Service Mesh et les instructions de configuration avec Envoy et gRPC sans proxy.

Étape suivante

Pour vous aider à résoudre les problèmes de configuration de Cloud Service Mesh, consultez la page Résoudre les problèmes de déploiement qui utilisent Envoy.

Configurer la gestion avancée du trafic avec Envoy

Avant de commencer

Configurer la répartition du trafic

Console

gcloud

Configurer une version partielle

Configurer des déploiements bleu-vert

Configurer la mise en miroir du trafic

Console

gcloud

Configurer la rupture de circuit

Console

gcloud

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

Console

gcloud

Configurer la détection des anomalies

Console

gcloud

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

Console

gcloud

Configurer la redirection d'URL

Console

gcloud

Configurer l'orientation du trafic avec la réécriture d'URL

Configurer l'injection de pannes

Configurer le filtrage des configurations en fonction de la correspondance MetadataFilters

gcloud

Exemples de filtrage de métadonnées

gcloud

gcloud

Dépannage

Bloquer le trafic entre les services

Étape suivante

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

Configurer le filtrage des configurations en fonction de la correspondance `MetadataFilters`