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 liés à Clients Envoy lorsque vous exécutez Cloud Service Mesh avec les API Google. Pour des informations sur l'utilisation de l'API CSDS (Client Status Discovery Service) pour vous aider à résoudre les problèmes liés à Cloud Service Mesh, consultez 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-versionNAMESPACE 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 est par exemple.
/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
(viaiptables
) 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é Cloud Service Mesh API pour le projet. Sous API et services pour votre projet, recherchez pour 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 TCP443
ou il existe des problèmes de résolution DNS pour le nom d'hôtetrafficdirector.googleapis.com
.Si vous utilisez Envoy pour le proxy side-car, vérifiez que la version d'Envoy est est 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 des ressources dynamiques configurées. 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 commandeiptables
, puis la commandegrep
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 pariptables
et transférée à un proxy Envoy s'exécutant sur le port15001
en tant qu'UID1006
:-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
Les journaux d'accès Envoy, comme décrit dans
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 spécifié pour le journal d'accès.
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 avec la configuration de Cloud Service Mesh, peut voir l'un des messages d'erreur suivants 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 que Envoy demande une configuration
Cloud Service Mesh, mais 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
qui comportent le schéma d'équilibrage de charge INTERNAL_SELF_MANAGED
et qui font référence au
le 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 déploiements automatiques d'Envoy sur Compute Engine, assurez-vous que la valeur fournie pour l'option
--service-proxy:network
correspond le nom du réseau VPC de la règle de transfert.Si vous utilisez Cloud Service Mesh avec des déploiements Envoy manuels sur Compute Engine, Recherchez les éléments suivants dans le fichier d'amorçage Envoy:
- Assurez-vous que la valeur de la variable
TRAFFICDIRECTOR_NETWORK_NAME
correspond au nom du réseau VPC de la règle de transfert. - Assurez-vous que le numéro du projet est défini dans la variable
TRAFFICDIRECTOR_GCP_PROJECT_NUMBER
.
- Assurez-vous que la valeur de la variable
Si vous effectuez le déploiement sur GKE et que vous utilisez l'injecteur automatique, vérifiez que le numéro du projet et le nom du réseau VPC sont correctement configuré, conformément aux instructions Configuration de 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 à Envoy. des déploiements 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 génèrent souvent des données en sortie sur les ports série. Ces données sont utiles pour résoudre les plantages du système, les échecs de démarrage, les problèmes de démarrage et les problèmes d'arrêt.
Les agents d'amorçage Compute Engine enregistrent toutes les actions effectuées sur le port série 1, ainsi que les événements système, en commençant par l'installation du package de base jusqu'à l'obtention des données de serveur à partir des métadonnées d'une instance, la configuration iptables
et l'état d'installation d'Envoy.
Les agents sur VM consignent l'état de fonctionnement du processus Envoy, récemment découvert les services Cloud Service Mesh et toute autre information utiles lorsque vous examinez les 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 à partir d'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'attributgce-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 de trafic sur la VM n'est pas correctement configurée pour Services basés sur Cloud Service Mesh. Connectez-vous à la VM et vérifiez le
iptables
configuration: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 typeSERVICE_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
. En l'absence d'entrée pour l'adresse IP virtuelle (VIP), un problème se produit lors du remplissage de la configuration du proxy Envoy depuis Cloud Service Mesh ou l'agent de VM ont échoué.Les proxys Envoy n'ont pas reçu leur configuration de Cloud Service Mesh pour l'instant. 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 maillage de services Cloud. Google Cloud. 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 lors de la création de services Cloud Service Mesh. 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.
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
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
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 estCannot 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'attributgce-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 typeSERVICE_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 colonnedestination
. 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 reçu leur configuration pour le port entrant. depuis Cloud Service Mesh. Se connecter à la VM pour vérifier le proxy Envoy configuration:
gcloud compute ssh INSTANCE_NAME \ --zone=ZONE \ sudo curl localhost:15000/config_dump
Recherchez la configuration d'écouteur entrante 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 parinbound
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 sousdestination_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 liés à Cloud Service Mesh de configuration.
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 pour qu'il ignore l'état l'état des points de terminaison. Au lieu de cela, le plan de données équilibre le trafic entre tous les points de terminaison, car il est possible que le port de service soit toujours fonctionnel.
Les backends non opérationnels entraînent une répartition non optimale du trafic
Cloud Service Mesh utilise les informations de la ressource HealthCheck
à un service de backend pour
évaluer l'état de vos backends.
Cloud Service Mesh utilise cet état de fonctionnement pour acheminer le trafic vers
backend opérationnel le plus proche. Si certains de vos backends ne sont pas opérationnels, le trafic peut
mais leur répartition n'est pas 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 loin du client, ce qui entraîne une latence. Pour identifier et surveiller
l'état de fonctionnement 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 de l'état ont récemment échoué, examinez les journaux d'audit Cloud.
pour déterminer si votre configuration
HealthCheck
a récemment été modifiée.
Étape suivante
- 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 concernant l'utilisation de Cloud Service Mesh, consultez Obtenir de l'aide