Résoudre les problèmes de déploiement de Traffic Director

Ce guide fournit des informations pour vous aider à résoudre les problèmes de configuration de Traffic Director.

Emplacements de journaux Envoy

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

Dans Google Kubernetes Engine, les proxys Envoy s'exécutent avec les pods d'application. Vous verrez donc les erreurs dans les journaux des pods d'application, en filtrant sur le conteneur istio-proxy. Si la journalisation de la charge de travail est activée sur le cluster, vous pouvez les voir 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="istio-proxy"

Si la journalisation de la charge de travail n'est pas activée sur le cluster, vous pouvez voir 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 istio-proxy --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="istio-proxy"

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.

Par exemple : LOG_DIR='/var/log/envoy/'

Par défaut, les erreurs sont affichées dans /var/log/envoy/envoy.err.log.

Si aucune configuration supplémentaire n'a été effectuée par l'utilisateur pour exportation vers Logging, les erreurs ne seraient visibles que si vous vous connectez à l'instance et que vous obtenez ce fichier en SSH.

Si vous utilisez le déploiement automatique Envoy, vous pouvez vous connecter en SSH à l'instance pour obtenir le fichier journal. Le chemin du fichier est probablement identique à celui décrit ci-dessus.

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 les services" de votre projet, recherchez les erreurs de l'API Traffic Director.
    Accédez à la page "Bibliothèque d'API".
  • Vérifiez que le niveau d'accès de la VM à l'API est configuré pour autoriser l'accès complet aux API GCP. Pour ce faire, spécifiez "--scopes=https://www.googleapis.com/auth/cloud-platform" au moment de la création de la VM.
  • Vérifiez que le compte de service dispose des autorisations appropriées. Pour en savoir plus, consultez la page Autoriser le compte de service à accéder à l'API Traffic Director.
  • Confirmez 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. Vous pouvez afficher la configuration en exécutant 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 1.5001 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 la console GCP, 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 des commandes gcloud 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 configuré le journal des accès Envoy à l'aide de l'attribut TRAFFICDIRECTOR_ACCESS_LOG_PATH, comme indiqué dans la section Configurer des attributs supplémentaires pour les proxys side-car, 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_LISTENER:
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é, les connexions aux services non configurés dans Traffic Director sont ignorées par le proxy side-car.

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

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

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

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 des points de terminaison et équilibrer le trafic entre tous les points de terminaison, car il est possible que le port de diffusion soit toujours opérationnel.

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 indique généralement qu'Envoy demande une configuration à Traffic Director, mais qu'aucune configuration correspondante n'est disponible. Lorsqu'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 (1) qui utilisent le schéma d'équilibrage de charge INTERNAL_SELF_MANAGED et (2) font référence au même nom de réseau (par exemple, my-network).

  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 réseau VPC de cette règle de transfert.

  2. Si vous utilisez Traffic Director avec des déploiements Envoy automatisés 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, consultez le fichier d'amorçage Envoy :

    1. Vérifiez la valeur de la variable TRAFFICDIRECTOR_NETWORK_NAME et assurez-vous que cette valeur correspond au nom du réseau de la règle de transfert.
    2. Assurez-vous que le numéro de projet est défini dans la variable TRAFFICDIRECTOR_GCP_PROJECT_NUMBER du fichier d'amorçage Envoy.
  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 Google Kubernetes Engine avec injection Envoy automatique

Résoudre les problèmes liés aux déploiements automatisés d'Envoy

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

Canaux de communication pour le dépannage

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.

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.

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. Notez qu'il s'agit d'un journal au niveau de l'instance. Par conséquent, 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 :

    • [aucun] 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 le processus d'installation et de configuration s'est terminé 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 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 est 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.

    Pour vérifier l'état de la VM agent, exécutez la commande suivante :

    gcloud compute instances get-guest-attributes INSTANCE_NAME \
        --query-path=gce-service-proxy/ --zone=ZONE
    
  5. Vous pouvez examiner 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 gcloud compute instance-groups managed recreate-instance.

  6. 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 :

    • [aucun] 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 le processus d'installation et de configuration s'est terminé 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 entrant 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 dans destination_port.

Étape suivante