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.

Résoudre des problèmes pour les déploiements Envoy

Ce guide fournit des informations pour vous aider à résoudre les problèmes de configuration avec les clients Envoy lorsque vous exécutez Cloud Service Mesh avec des API Google. Pour plus d'informations sur l'utilisation de l'API CSDS (Client Status Discovery Service) afin d'analyser les problèmes liés à Cloud Service Mesh, consultez la page Comprendre l'état du client Cloud Service Mesh.

Déterminer la version d'Envoy installée sur une VM

Suivez ces instructions pour vérifier quelle version d'Envoy est exécutée sur une instance de machine virtuelle (VM).

Pour vérifier la version d'Envoy, vous pouvez effectuer l'une des opérations suivantes:

Vérifiez les attributs d'invité de la VM sous le chemin d'accès gce-service-proxy/proxy-version :

gcloud compute --project cloud-vm-mesh-monitoring instances get-guest-attributes INSTANCE_NAME
--zone ZONEc --query-path=gce-service-proxy/proxy-version

NAMESPACE KEY VALUE gce-service-proxy proxy-version dc78069b10cc94fa07bb974b7101dd1b42e2e7bf/1.15.1-dev/Clean/RELEASE/BoringSSL

Consultez les journaux de l'instance Cloud Logging à partir de la page "Informations sur l'instance de VM" de Google Cloud Console à l'aide d'une requête telle que la suivante :

  resource.type="gce_instance"
  resource.labels.instance_id="3633122484352464042"
  jsonPayload.message:"Envoy version"

Vous recevez une réponse de ce type :

  {
    "insertId": "9zy0btf94961a",
    "jsonPayload": {
      "message": "Envoy Version: dc78069b10cc94fa07bb974b7101dd1b42e2e7bf/1.15.1-dev/Clean/RELEASE/BoringSSL",
      "localTimestamp": "2021-01-12T11:39:14.3991Z"
    },
    "resource": {
      "type": "gce_instance",
      "labels": {
        "zone": "asia-southeast1-b",
        "instance_id": "3633122484352464042",
        "project_id": "cloud-vm-mesh-monitoring"
      }
    },
    "timestamp": "2021-01-12T11:39:14.399200504Z",
    "severity": "INFO",
    "logName": "projects/cloud-vm-mesh-monitoring/logs/service-proxy-agent",
    "receiveTimestamp": "2021-01-12T11:39:15.407023427Z"
  }

Utilisez SSH pour vous connecter à une VM et vérifier la version binaire :

YOUR_USER_NAME@backend-mig-5f5651e1-517a-4269-b457-f6bdcf3d98bc-m3wt:~$ /usr/local/bin/envoy --version

/usr/local/bin/envoy version: dc78069b10cc94fa07bb974b7101dd1b42e2e7bf/1.15.1-dev/Clean/RELEASE/BoringSSL

Utilisez SSH pour vous connecter à une VM et à l'interface d'administration en tant qu'utilisateur racine :

  root@backend-mig-5f5651e1-517a-4269-b457-f6bdcf3d98bc-m3wt:~# curl localhost:15000/server_info
  {
   "version": "dc78069b10cc94fa07bb974b7101dd1b42e2e7bf/1.15.1-dev/Clean/RELEASE/BoringSSL",
   "state": "LIVE",
   "hot_restart_version": "disabled",
   ...
  }

Emplacements de journaux Envoy

Pour résoudre certains problèmes, vous devez examiner les journaux du proxy Envoy.

Vous pouvez utiliser SSH pour vous connecter à l'instance de VM afin d'obtenir le fichier journal. Le chemin d'accès se présente probablement comme suit :

  /var/log/envoy/envoy.err.log

Les proxys ne se connectent pas à Cloud Service Mesh

Si vos proxys ne se connectent pas à Cloud Service Mesh, procédez comme suit:

Consultez les journaux des proxys Envoy pour détecter d'éventuelles erreurs de connexion à trafficdirector.googleapis.com.
Si vous avez configuré netfilter (via iptables) pour rediriger tout le trafic vers le proxy Envoy, assurez-vous que l'utilisateur (UID) au nom duquel vous exécutez le proxy est exclu de la redirection. Sinon, le trafic sera renvoyé en boucle sur le proxy.
Assurez-vous d'avoir activé l'API Cloud Service Mesh pour le projet. Sous API et services pour votre projet, recherchez les erreurs concernant l'API Cloud Service Mesh.
Vérifiez que le niveau d'accès à l'API de la VM est défini pour autoriser un accès complet aux API Google Cloud en spécifiant les éléments suivants lors de la création de la VM :
```
--scopes=https://www.googleapis.com/auth/cloud-platform
```
Vérifiez que le compte de service dispose des autorisations appropriées. Pour en savoir plus, consultez la section Autoriser le compte de service à accéder à l'API Traffic Director.
Vérifiez que vous pouvez accéder à trafficdirector.googleapis.com:443 à partir de la VM. En cas de difficultés avec cet accès, le pare-feu vous empêche peut-être d'accéder à trafficdirector.googleapis.com sur le port TCP 443 ou il existe des problèmes de résolution DNS pour le nom d'hôte trafficdirector.googleapis.com.
Si vous utilisez Envoy pour le proxy side-car, vérifiez qu'il s'agit de la version 1.24.9 ou ultérieure.

Le service configuré avec Cloud Service Mesh est inaccessible

Si un service configuré avec Cloud Service Mesh n'est pas accessible, vérifiez que le proxy side-car est en cours d'exécution et peut se connecter à Cloud Service Mesh.

Si vous utilisez Envoy en tant que proxy side-car, vous pouvez le vérifier en exécutant les commandes suivantes.

Dans la ligne de commande, vérifiez que le processus Envoy est en cours d'exécution.
```
ps aux | grep envoy
```
Inspectez la configuration de l'environnement d'exécution d'Envoy pour vérifier que Cloud Service Mesh a configuré les ressources dynamiques. Pour afficher la configuration, exécutez la commande suivante :
```
curl http://localhost:15000/config_dump
```
Assurez-vous que l'interception du trafic pour le proxy side-car est correctement configurée. Pour la configuration de la redirection avec iptables, exécutez la commande iptables, puis la commande grep sur le résultat pour vous assurer que vos règles sont bien présentes :
```
sudo iptables -t nat -S | grep ISTIO
```
Voici un exemple de résultat dans lequel l'adresse IP virtuelle 10.0.0.1/32 est interceptée par iptables et transférée à un proxy Envoy s'exécutant sur le port 15001 en tant qu'UID 1006 :
```
-N ISTIO_IN_REDIRECT
-N ISTIO_OUTPUT
-N ISTIO_REDIRECT
-A OUTPUT -p tcp -j ISTIO_OUTPUT
-A ISTIO_IN_REDIRECT -p tcp -j REDIRECT --to-ports 15001
-A ISTIO_OUTPUT -m owner --uid-owner 1006 -j RETURN
-A ISTIO_OUTPUT -d 127.0.0.1/32 -j RETURN
-A ISTIO_OUTPUT -d 10.0.0.1/32 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -j RETURN
```

Si l'instance de VM est créée via Google Cloud Console, certains modules associés à ipv6 ne sont pas installés et accessibles avant un redémarrage. Cela provoque l'échec du script iptables en raison des dépendances manquantes. Dans ce cas, redémarrez la VM et exécutez à nouveau le processus de configuration, ce qui devrait résoudre le problème. Une VM Compute Engine que vous avez créée à l'aide de Google Cloud CLI ne devrait pas rencontrer ce problème.

Le service cesse d'être accessible lorsque la journalisation des accès Envoy est configurée

Si vous avez utilisé TRAFFICDIRECTOR_ACCESS_LOG_PATH pour configurer un journal d'accès Envoy comme décrit dans la section Configurer les attributs d'amorçage Envoy pour Cloud Service Mesh, assurez-vous que l'utilisateur système exécutant le proxy Envoy est autorisé à écrire dans l'emplacement du journal d'accès spécifié.

Si vous ne fournissez pas les autorisations nécessaires, les écouteurs ne sont pas programmés sur le proxy et peuvent être détectés en recherchant le message d'erreur suivant dans le journal du proxy Envoy :

gRPC config for type.googleapis.com/envoy.api.v2.Listener rejected:
Error adding/updating listener(s) TRAFFICDIRECTOR_INTERCEPTION_PORT:
unable to open file '/var/log/envoy.log': Permission denied

Pour résoudre le problème, modifiez les autorisations du fichier choisi pour que le journal d'accès soit accessible en écriture à l'utilisateur Envoy.

Messages d'erreur dans les journaux Envoy indiquant un problème de configuration

Cette section s'applique aux déploiements utilisant les API d'équilibrage de charge.

Si vous rencontrez des difficultés pour configurer Cloud Service Mesh, l'un des messages d'erreur suivants peut s'afficher dans les journaux Envoy:

warning envoy config    StreamAggregatedResources gRPC config stream closed:
5, Cloud Service Mesh configuration was not found for network "VPC_NAME" in
project "PROJECT_NUMBER".

warning envoy upstream  StreamLoadStats gRPC config stream closed:
5, Cloud Service Mesh configuration was not found for network "VPC_NAME" in
project "PROJECT_NUMBER".

warning envoy config    StreamAggregatedResources gRPC config stream closed:
5, Requested entity was not found.

warning envoy upstream  StreamLoadStats gRPC config stream closed:
5, Requested entity was not found.

Cloud Service Mesh configuration was not found.

Le dernier message d'erreur (Traffic Director configuration was not found) indique généralement qu'Envoy demande une configuration à Cloud Service Mesh, mais qu'aucune configuration correspondante n'a été trouvée. Lorsque Envoy se connecte à Cloud Service Mesh, il présente un nom de réseau VPC (par exemple, my-network). Cloud Service Mesh recherche ensuite les règles de transfert ayant le schéma d'équilibrage de charge INTERNAL_SELF_MANAGED et faisant référence au même nom de réseau VPC.

Pour résoudre cette erreur, procédez comme suit :

Assurez-vous qu'une règle de transfert de votre réseau présente le schéma d'équilibrage de charge INTERNAL_SELF_MANAGED. Notez le nom du réseau VPC de la règle de transfert.
Si vous utilisez Cloud Service Mesh avec des déploiements automatiques Envoy sur Compute Engine, assurez-vous que la valeur fournie pour l'option --service-proxy:network correspond au nom du réseau VPC de la règle de transfert.
Si vous utilisez Cloud Service Mesh avec des déploiements manuels Envoy sur Compute Engine, recherchez les éléments suivants dans le fichier d'amorçage Envoy:
1. Assurez-vous que la valeur de la variable TRAFFICDIRECTOR_NETWORK_NAME correspond au nom du réseau VPC de la règle de transfert.
2. Assurez-vous que le numéro du projet est défini dans la variable TRAFFICDIRECTOR_GCP_PROJECT_NUMBER.
Si vous effectuez le déploiement sur GKE et que vous utilisez l'injecteur automatique, assurez-vous que le numéro de projet et le nom du réseau VPC sont correctement configurés, conformément aux instructions de la section Configurer Cloud Service Mesh pour les pods GKE avec injection Envoy automatique.

Dépannage pour Compute Engine

Cette section fournit des instructions pour résoudre les problèmes liés aux déploiements Envoy pour Compute Engine.

Les processus d'amorçage du proxy Envoy et des VM, ainsi que d'autres opérations de gestion du cycle de vie, peuvent échouer pour de nombreuses raisons, y compris des problèmes de connectivité temporaire, des dépôts non fonctionnels, des bugs dans les scripts d'amorçage et les VM agents, et des actions utilisateur inattendues.

Canaux de communication pour le dépannage

Google Cloud propose des canaux de communication qui vous permettent de comprendre le processus d'amorçage et l'état actuel des composants résidant sur vos VM.

Journalisation des données en sortie du port série virtuel

Le système d'exploitation d'une VM, le BIOS et d'autres entités de niveau système écrivent généralement des données de sortie sur les ports série. Cette sortie est utile pour résoudre les plantages du système, les échecs de démarrage, les problèmes de démarrage et d'arrêt.

Les agents d'amorçage Compute Engine consignent toutes les actions effectuées sur le port série 1. Cela inclut les événements système, à commencer par l'installation de base du package via l'obtention de données à partir du serveur de métadonnées d'une instance, la configuration iptables et l'état d'installation d'Envoy.

Les agents sur VM enregistrent l'état de fonctionnement du processus Envoy, les services Cloud Service Mesh récemment découverts et toute autre information pouvant vous être utile lorsque vous examinez des problèmes liés aux VM.

Journalisation Cloud Monitoring

Les données exposées en sortie du port série sont également consignées dans Monitoring, qui utilise la bibliothèque Golang et exporte les journaux vers un journal distinct pour réduire le bruit. Comme ce journal est un journal au niveau de l'instance, vous trouverez peut-être les journaux du proxy de service sur la même page que les autres journaux d'instances.

Attributs d'invité de VM

Les attributs d'invité sont un type spécifique de métadonnées personnalisées auxquelles vos applications peuvent accéder en écriture alors qu'elles sont en cours d'exécution sur votre instance. Une application ou un utilisateur de vos instances peut lire et écrire des données dans ces valeurs de métadonnées d'attributs d'invité.

Les scripts d'amorçage d'Envoy Compute Engine les VM agents exposent des attributs avec des informations sur le processus d'amorçage et l'état actuel d'Envoy. Tous les attributs d'invité sont exposés dans l'espace de noms gce-service-proxy :

gcloud compute instances get-guest-attributes INSTANCE_NAME  \
    --query-path=gce-service-proxy/ \
    --zone=ZONE

Si vous rencontrez des problèmes, nous vous recommandons de vérifier la valeur des attributs d'invité bootstrap-status et bootstrap-last-failure. Toute valeur bootstrap-status autre que FINISHED indique que l'environnement Envoy n'est pas encore configuré. La valeur de bookstrap-last-failure peut indiquer la nature du problème.

Impossible d'accéder au service Cloud Service Mesh depuis une VM créée à l'aide d'un modèle d'instance compatible avec le proxy de service

Pour résoudre ce problème, procédez comme suit :

L'installation des composants du proxy de service sur la VM peut ne pas être terminée ou a échoué. Exécutez la commande suivante pour déterminer si tous les composants sont correctement installés :
```
gcloud compute instances get-guest-attributes INSTANCE_NAME \
    --query-path=gce-service-proxy/ \
    --zone=ZONE
```
L'attribut d'invité bootstrap-status est défini sur l'un des éléments suivants :
- [none] indique que l'installation n'a pas encore commencé. Il se peut que la VM soit encore en cours de démarrage. Vérifiez à nouveau l'état au bout de quelques minutes.
- IN PROGRESS indique que l'installation et la configuration des composants du proxy de service ne sont pas encore terminées. Vérifiez à nouveau l'état afin de rechercher des mises à jour sur le processus.
- FAILED indique que l'installation ou la configuration d'un composant a échoué. Vérifiez le message d'erreur en interrogeant l'attribut gce-service-proxy/bootstrap-last-failure1.
- FINISHED indique que les processus d'installation et de configuration se sont terminés sans erreur. Suivez les instructions ci-dessous pour vérifier que l'interception du trafic et le proxy Envoy sont correctement configurés.
L'interception du trafic sur la VM n'est pas configurée correctement pour les services basés sur Cloud Service Mesh. Connectez-vous à la VM et vérifiez la configuration de iptables:
```
gcloud compute ssh INSTANCE_NAME \
    --zone=ZONE \
    sudo iptables -L -t nat
```
Examinez la chaîne SERVICE_PROXY_SERVICE_CIDRS pour rechercher des entrées de type SERVICE_PROXY_REDIRECT telles que les suivantes :
```
Chain SERVICE_PROXY_SERVICE_CIDRS (1 references)
target                   prot opt source         destination ...
SERVICE_PROXY_REDIRECT   all  --  anywhere       10.7.240.0/20
```
Chaque service doit disposer d'une adresse IP ou d'un CIDR correspondant dans la colonne destination. S'il n'existe aucune entrée pour l'adresse IP virtuelle (VIP), un problème se produit lors du remplissage de la configuration du proxy Envoy à partir de Cloud Service Mesh, ou l'agent de VM a échoué.
Les proxys Envoy n'ont pas encore reçu leur configuration de Cloud Service Mesh. Connectez-vous à la VM pour vérifier la configuration du proxy Envoy:
```
gcloud compute ssh INSTANCE_NAME \
    --zone=ZONE \
    sudo curl localhost:15000/config_dump
```
Examinez la configuration de l'écouteur reçue de Cloud Service Mesh. Exemple :
```
"dynamic_active_listeners": [
  ...
  "filter_chains": [{
    "filter_chain_match": {
      "prefix_ranges": [{
        "address_prefix": "10.7.240.20",
        "prefix_len": 32
      }],
      "destination_port": 80
    },
  ...
    "route_config_name": "URL_MAP/PROJECT_NUMBER.td-routing-rule-1"
  ...
]
```
address_prefix est l'adresse IP virtuelle (VIP) d'un service Cloud Service Mesh. Il pointe vers le mappage d'URL nommé td-routing-rule-1. Vérifiez si le service auquel vous souhaitez vous connecter est déjà inclus dans la configuration de l'écouteur.
La VM agent ne s'exécute pas. L'agent de VM configure automatiquement l'interception du trafic lorsque des services Cloud Service Mesh sont créés. Si l'agent ne s'exécute pas, tout le trafic vers les nouveaux services est directement dirigé vers des adresses IP virtuelles, en contournant le proxy, puis expire.
1. Vérifiez l'état de la VM agent en exécutant la commande suivante :
```
gcloud compute instances get-guest-attributes INSTANCE_NAME \
   --query-path=gce-service-proxy/ \
   --zone=ZONE
```
2. Examinez les attributs de la VM agent. La valeur de l'attribut agent-heartbeat correspond à l'heure de la dernière action ou vérification effectuée par l'agent. Si la valeur est supérieure à cinq minutes, l'agent est bloqué et vous devez recréer la VM à l'aide de la commande suivante :
```
gcloud compute instance-groups managed recreate-instance
```
3. L'attribut agent-last-failure expose la dernière erreur qui s'est produite dans l'agent. Il peut s'agir d'un problème temporaire qui sera résolu lors de la prochaine vérification de l'agent, par exemple si l'erreur est Cannot reach the Cloud Service Mesh API server ou qu'il s'agit d'une erreur permanente. Attendez quelques minutes et vérifiez à nouveau l'erreur.

L'interception du trafic entrant est configurée sur le port de la charge de travail, mais vous ne pouvez pas vous connecter au port depuis l'extérieur de la VM.

Pour résoudre ce problème, procédez comme suit :

L'installation des composants du proxy de service sur la VM peut ne pas être terminée ou a échoué. Exécutez la commande suivante pour déterminer si tous les composants sont correctement installés :
```
gcloud compute instances get-guest-attributes INSTANCE_NAME \
    --query-path=gce-service-proxy/ \
    --zone=ZONE
```
L'attribut d'invité bootstrap-status est défini sur l'un des éléments suivants :
- [none] indique que l'installation n'a pas encore commencé. Il se peut que la VM soit encore en cours de démarrage. Vérifiez à nouveau l'état au bout de quelques minutes.
- IN PROGRESS indique que l'installation et la configuration des composants du proxy de service ne sont pas encore terminées. Vérifiez à nouveau l'état afin de rechercher des mises à jour sur le processus.
- FAILED indique que l'installation ou la configuration d'un composant a échoué. Vérifiez le message d'erreur en interrogeant l'attribut gce-service-proxy/bootstrap-last-failure1.
- FINISHED indique que les processus d'installation et de configuration se sont terminés sans erreur. Suivez les instructions ci-dessous pour vérifier que l'interception du trafic et le proxy Envoy sont correctement configurés.
L'interception du trafic sur la VM n'est pas correctement configurée pour le trafic entrant. Connectez-vous à la VM et vérifiez la configuration de iptables:
```
gcloud compute ssh INSTANCE_NAME \
    --zone=ZONE \
    sudo iptables -L -t nat
```
Examinez la chaîne SERVICE_PROXY_INBOUND pour rechercher des entrées de type SERVICE_PROXY_IN_REDIRECT telles que les suivantes :
```
Chain SERVICE_PROXY_INBOUND (1 references)
target                      prot opt source       destination ...
SERVICE_PROXY_IN_REDIRECT   tcp  --  anywhere     anywhere  tcp dpt:mysql
```
Chaque port défini dans service-proxy:serving-ports doit disposer d'un port correspondant dans la colonne destination. S'il n'y a pas d'entrée pour le port, tout le trafic entrant est directement dirigé vers ce port, en contournant le proxy Envoy.

Vérifiez qu'aucune autre règle ne supprime le trafic vers ce port ou tous les ports, à l'exception d'un port spécifique.
Les proxys Envoy n'ont pas encore reçu leur configuration pour le port entrant de Cloud Service Mesh. Connectez-vous à la VM pour vérifier la configuration du proxy Envoy:
```
gcloud compute ssh INSTANCE_NAME \
    --zone=ZONE \
    sudo curl localhost:15000/config_dump
```
Recherchez la configuration d'écouteur inbound reçue de Cloud Service Mesh:
```
"dynamic_active_listeners": [
  ...
  "filter_chains": [{
    "filter_chain_match": {
      "prefix_ranges": [{
        "address_prefix": "10.0.0.1",
        "prefix_len": 32
      }],
      "destination_port": 80
    },
  ...
    "route_config_name": "inbound|default_inbound_config-80"
  ...
]
```
Le nom route_config_name commençant par inbound indique un service spécial créé à des fins d'interception du trafic entrant. Vérifiez si le port auquel vous souhaitez vous connecter est déjà inclus dans la configuration de l'écouteur sous destination_port.

Problèmes liés aux connexions utilisant des protocoles orientés serveur

Certaines applications, telles que MySQL, utilisent des protocoles où le serveur envoie le premier paquet. Cela signifie qu'à la première connexion, le serveur envoie les premiers octets. Ces protocoles et applications ne sont pas compatibles avec Cloud Service Mesh.

Résoudre les problèmes liés à l'état de votre maillage de services

Ce guide fournit des informations pour vous aider à résoudre les problèmes de configuration de Cloud Service Mesh.

Comportement de Cloud Service Mesh lorsque la plupart des points de terminaison sont non opérationnels

Pour améliorer la fiabilité, lorsque 99% des points de terminaison ne sont pas opérationnels, Cloud Service Mesh configure le plan de données de manière à ignorer l'état de fonctionnement des points de terminaison. À la place, le plan de données équilibre le trafic entre tous les points de terminaison, car il est possible que le port de diffusion reste fonctionnel.

Les backends non opérationnels entraînent une répartition non optimale du trafic

Cloud Service Mesh évalue l'état de vos backends à l'aide des informations de la ressource HealthCheck associée à un service de backend. Cloud Service Mesh utilise cet état de fonctionnement pour acheminer le trafic vers le backend opérationnel le plus proche. Si certains de vos backends ne sont pas opérationnels, le trafic peut continuer à être traité, mais avec une répartition non optimale. Par exemple, le trafic peut circuler vers une région où des backends opérationnels sont toujours présents, mais qui est beaucoup plus éloigné du client, ce qui entraîne une latence. Pour identifier et surveiller l'état de vos backends, procédez comme suit:

Vérifiez l'état de votre service de backend dans Google Cloud Console.
Accéder à la page "Services Cloud Service Mesh"
Assurez-vous que la journalisation est activée pour la ressource HealthCheck.
Si les vérifications d'état ont récemment échoué, inspectez les journaux d'audit Cloud pour déterminer si votre configuration HealthCheck a récemment été modifiée.

Étapes suivantes

Pour résoudre les problèmes de configuration lorsque vous déployez des services gRPC sans proxy, consultez la page Résoudre les problèmes de déploiement qui utilisent gRPC sans proxy.
Pour obtenir une assistance supplémentaire sur l'utilisation de Cloud Service Mesh, consultez la page Obtenir de l'aide.