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 de Traffic Director. Pour en savoir plus sur l'utilisation de l'API Client Status Discovery Service (CSDS) pour vous aider à résoudre les problèmes liés à Traffic Director, consultez la section Comprendre l'état du client Traffic Director.

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

Déterminer la version avec déploiement Envoy automatique

Pour déterminer ou vérifier la version Envoy avec déploiement automatique, vous pouvez procéder comme suit :

  • 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 ZONE --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",
...
}

Déterminer la version avec déploiement Envoy manuel

Pour déterminer ou vérifier la version Envoy avec le déploiement manuel, procédez comme suit :

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

Dans Google Kubernetes Engine (GKE), les proxys Envoy s'exécutent avec les pods d'application. Toutes les erreurs s'affichent dans les journaux du pod de l'application filtrés par le conteneur envoy.

  • Si la journalisation de la charge de travail est activée sur le cluster, vous pouvez consulter les erreurs dans Cloud Logging. Voici un filtre possible :

    resource.type="K8S_CONTAINER"
resource.labels.project_id="PROJECT_NAME"
resource.labels.location="CLUSTER_ZONE"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.namespace_name="WORKLOAD_NAMESPACE"
labels.k8s-pod/app="WORKLOAD_NAME"
resource.labels.container_name="envoy"

  • Si la journalisation de la charge de travail n'est pas activée sur le cluster, vous pouvez afficher les erreurs à l'aide d'une commande telle que la suivante :

    kubectl logs $(kubectl get po -l app=WORKLOAD_NAME -o=jsonpath='{.items[0].metadata.name}') -c envoy --tail 50 #NOTE: This assumes the default namespace.

  • Vous pouvez également afficher les journaux de tous les Envoy s'exécutant dans tous les clusters et n'importe quelle charge de travail avec le filtre suivant :

    resource.type="K8S_CONTAINER"
resource.labels.container_name="envoy"

Avec Compute Engine et le déploiement manuel, définissez LOG_DIR avant d'exécuter le script run.sh dans le guide de configuration.

  • Exemple :

    LOG_DIR='/var/log/envoy/'

  • Par défaut, les erreurs sont affichées dans le journal suivant :

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

Si l'utilisateur n'a effectué aucune configuration supplémentaire pour exporter ces données vers Logging, les erreurs ne sont visibles que si vous utilisez SSH pour vous connecter à l'instance et obtenir ce fichier.

Si vous utilisez le déploiement Envoy automatique, vous pouvez utiliser SSH pour vous connecter à l'instance afin d'obtenir le fichier journal. Le chemin d'accès est probablement identique à celui mentionné précédemment.

Impossible de connecter les proxys à Traffic Director

Si les proxys ne se connectent pas à Traffic Director, 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.

  • Vérifiez que vous avez activé l'API Traffic Director dans le projet. Dans la section API et services de votre projet, recherchez les erreurs de l'API Traffic Director.

  • 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.9.1 ou ultérieure.

Le service configuré avec Traffic Director n'est pas accessible

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

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

  1. Dans la ligne de commande, vérifiez que le processus Envoy est en cours d'exécution.

    ps aux | grep envoy

  2. Examinez la configuration de l'environnement d'exécution Envoy pour vérifier que les ressources dynamiques ont été configurées par Traffic Director. Pour afficher la configuration, exécutez la commande suivante :

    curl http://localhost:15000/config_dump

  3. 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 Traffic Director, assurez-vous que l'utilisateur système exécutant le proxy Envoy dispose des autorisations en écriture sur 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.

Impossible de connecter les applications à des services non configurés dans Traffic Director

Assurez-vous d'avoir configuré l'interception du trafic uniquement pour les adresses IP des services configurés dans Traffic Director. Si l'ensemble du trafic est intercepté, le proxy side-car supprime en mode silencieux les connexions aux services non configurés dans Traffic Director.

Une boucle de trafic s'affiche dans un nœud ou un nœud plante

Si vous avez configuré netfilter (iptables) pour intercepter l'ensemble du trafic, assurez-vous que l'utilisateur (UID) utilisé pour exécuter le proxy side-car est exclu de l'interception du trafic. Sinon, le trafic envoyé par le proxy side-car est renvoyé en boucle au proxy. Par conséquent, le processus de proxy side-car peut planter. Dans la configuration de référence, les règles de netfilter sont programmées pour ne pas intercepter le trafic de l'utilisateur du proxy.

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

Si vous rencontrez des problèmes avec votre configuration Traffic Director, l'un des messages d'erreur suivants peut s'afficher dans les journaux Envoy :

  • warning envoy config    StreamAggregatedResources gRPC config stream closed:
5, Traffic Director configuration was not found for network "VPC_NAME" in
project "PROJECT_NUMBER".
  • warning envoy upstream  StreamLoadStats gRPC config stream closed:
5, Traffic Director 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.
  • Traffic Director configuration was not found.

Ce message d'erreur (Traffic Director configuration was not found) indique généralement qu'Envoy demande une configuration à Traffic Director, mais qu'aucune configuration correspondante n'est disponible. Lorsque Envoy se connecte à Traffic Director, il présente un nom de réseau VPC (par exemple, my-network). Traffic Director recherche ensuite les règles de transfert qui utilisent le schéma d'équilibrage de charge INTERNAL_SELF_MANAGED et font référence au même nom de réseau VPC.

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

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

  2. Si vous utilisez Traffic Director avec des déploiements Envoy automatiques sur Compute Engine, assurez-vous que la valeur fournie à l'option --service-proxy:network correspond au nom du réseau de la règle de transfert.

  3. Si vous utilisez Traffic Director avec des déploiements Envoy manuels 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.

  4. Si vous procédez au 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 sont correctement configurés selon les instructions fournies dans la section Configuration de Traffic Director pour les pods GKE avec injection Envoy automatique.

Résoudre des problèmes de déploiement automatique pour Compute Engine

Cette section fournit des instructions permettant de résoudre des problèmes de déploiement Envoy automatique 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, le BIOS et d'autres entités de niveau système d'une VM écrivent généralement des données en 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 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. Cela inclut les événements système, en commençant par l'installation du package de base via l'obtention de données à partir du serveur de métadonnées d'une instance, la configuration iptables et l'état d'installation Envoy.

La VM agent enregistre l'état des processus Envoy, les nouveaux services Traffic Director découverts et toute autre information pouvant être utile au dépannage 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 Traffic Director à partir d'une VM créée à l'aide d'un modèle d'instance pour lequel le proxy est activé

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

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

  2. L'interception du trafic sur la VM n'est pas configurée correctement pour les services basés sur Traffic Director. Connectez-vous à la VM et vérifiez la configuration 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. L'absence d'entrée pour l'adresse IP virtuelle indique un problème lors du remplissage de la configuration du proxy Envoy à partir de Traffic Director, ou la VM agent a échoué.

  3. Les proxys Envoy n'ont pas encore reçu leur configuration de Traffic Director. 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 par Traffic Director. 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 correspond à l'adresse IP virtuelle d'un service Traffic Director. 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.

  4. La VM agent ne s'exécute pas. La VM agent configure automatiquement l'interception du trafic lorsque de nouveaux services Traffic Director 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 Traffic Director 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 :

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

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

  3. Les proxys Envoy n'ont pas encore reçu leur configuration pour le port entrant de la part de Traffic Director. 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 de l'écouteur inbound reçue de Traffic Director :

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

Résoudre des problèmes de déploiement automatique pour les pods GKE

Cette section fournit des instructions permettant de résoudre des problèmes de déploiement Envoy automatique pour les pods GKE.

Les pods ne démarrent pas après l'activation de l'injection Envoy automatique

Dans certains cas, les pods d'application peuvent ne pas démarrer correctement. Cela peut se produire lorsque vous utilisez un cluster GKE privé avec des règles de pare-feu restrictives.

Si vous souhaitez utiliser Traffic Director avec un cluster GKE privé, vous devez créer une règle de pare-feu supplémentaire pour le webhook d'injecteur side-car. Pour créer une règle de pare-feu permettant au plan de contrôle GKE d'atteindre les pods sur le port TCP 9443, consultez la section Ajouter des règles de pare-feu pour des cas d'utilisation spécifiques.

Vous pouvez observer ce problème lors de la création d'un pod autonome ou lorsqu'un déploiement tente de créer des pods.

Lors de la création d'un pod autonome (par exemple, en utilisant kubectl apply ou kubectl run), la ligne de commande kubectl peut renvoyer un message d'erreur semblable à celui-ci :

Error from server (InternalError): Internal error occurred: failed calling webhook "sidecar-injector.istio.io": Post https://istio-sidecar-injector.istio-control.svc:443/inject?timeout=30s: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

Lorsque vous créez des pods à partir d'un déploiement, vous pouvez rencontrer les symptômes suivants :

  • kubectl get pods n'affiche aucun pod associé au déploiement.

  • kubectl get events --all-namespaces affiche un message d'erreur semblable à celui-ci :

    Warning  FailedCreate  15s   replicaset-controller  Error creating: Internal error occurred: failed calling webhook "sidecar-injector.istio.io": Post https://istio-sidecar-injector.istio-control.svc:443/inject?timeout=30s: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

Lorsque vous suivez le guide de configuration, vous pouvez commencer par rencontrer ce problème lors de l'étape Déployer un exemple de client et valider l'injection. Après avoir exécuté kubectl create -f demo/client_sample.yaml, exécutez kubectl get deploy busybox pour afficher les pods 0/1 READY. Vous pouvez également identifier l'erreur en décrivant le replicaset associé au déploiement en exécutant la commande kubectl describe rs -l run=client.

Connexion refusée après validation de la configuration

Lorsque vous configurez Traffic Director avec une injection Envoy automatique, vous pouvez recevoir une erreur de connexion refusée lorsque vous essayez de valider la configuration. L'une des causes suivantes peut être à l'origine du problème :

  • La valeur de discoveryAddress dans le fichier specs/01-configmap.yaml n'est pas correcte. La valeur doit être trafficdirector.googleapis.com:443.
  • La valeur du réseau VPC dans le fichier specs/01-configmap.yaml n'est pas correcte.
  • La valeur du projet Traffic Director dans le fichier specs/01-configmap.yaml n'est pas correcte.
  • La valeur de discoveryAddress est incorrecte dans le pod.
  • L'injecteur side-car Istio est en cours d'exécution plutôt que l'injecteur side-car Traffic Director.

Pour consulter un exemple du fichier specs/01-configmap.yaml, reportez-vous à la section Configurer l'injecteur side-car. Si le fichier specs/01-configmap.yaml ne contient pas de valeurs correctes, Envoy ne peut pas obtenir la configuration de correction auprès de Traffic Director. Pour résoudre ce problème, examinez le fichier specs/01-configmap.yaml et assurez-vous que les valeurs sont correctes, puis recréez l'injecteur automatique.

Assurez-vous de vérifier la valeur de discoveryAddress dans le fichier specs/01-configmap.yaml et dans le pod. Dans le pod, la valeur est définie par l'injecteur side-car. Pour vérifier la valeur de discoveryAddress dans le pod, exécutez cette commande :

kubectl get po $BUSYBOX_POD -o yaml|grep -Po '\"discoveryAddress\":\"[^,]*\"'

Le résultat doit ressembler à ce qui suit :

"discoveryAddress":"trafficdirector.googleapis.com:443"

Connexion refusée avec injection Envoy manuelle et pods GKE

Si vous recevez un message de connexion refusée, consultez les journaux Busybox pour savoir si l'API Traffic Director est activée ou si les autorisations sont incorrectes dans les journaux Envoy.

Délai avant expiration de la connexion avec injection Envoy manuelle et pods GKE

Si vous recevez un message de connexion expirée, le problème provient probablement d'une configuration incorrecte du mappage d'URL, des règles de transfert ou du service de backend dans votre déploiement. Consultez ces ressources pour vérifier si elles sont correctement configurées.

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 Traffic Director.

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 Traffic Director.

Comportement de Traffic Director lorsque la plupart des points de terminaison ne sont pas opérationnels

Pour une meilleure fiabilité, lorsque 99% des points de terminaison ne sont pas opérationnels, Traffic Director configure le plan de données de façon à ignorer l'état de fonctionnement 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 diffusion soit toujours opérationnel.

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

Traffic Director utilise les informations de la ressource HealthCheck associée à un service de backend pour évaluer l'état des backends. Traffic Director utilise cet état 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 distribution sous-optimale. Par exemple, le trafic peut transiter vers une région où des backends opérationnels sont toujours présents, mais qui est beaucoup plus éloignée du client, ce qui entraîne une latence. Pour identifier et surveiller l'état de vos backends, procédez comme suit :

Les backends rejettent le trafic de manière inattendue

Si vous avez configuré la sécurité du service Traffic Director, vous utilisez la ressource EndpointPolicy pour appliquer des règles de sécurité aux backends. Une erreur de configuration EndpointPolicy peut entraîner le refus du trafic par le backend. Utilisez les journaux suivants pour résoudre ce scénario :

Étapes suivantes