Résoudre des problèmes pour les déploiements qui utilisnt le protocole gRPC sans proxy

Ce document fournit des informations pour vous aider à résoudre les problèmes de configuration lorsque vous déployez des services gRPC sans proxy avec 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.

Résoudre les problèmes liés aux échecs RPC dans une application gRPC

Il existe deux méthodes courantes permettant de résoudre les problèmes d'échec d'un appel RPC dans une application gRPC :

  1. Examinez l'état renvoyé en cas d'échec RPC. Dans la plupart des cas, l'état contient suffisamment d'informations pour vous aider à comprendre la cause d'un échec RPC. La gestion des erreurs d'état dans gRPC est expliquée dans la documentation sur le traitement des erreurs gRPC.
  2. Activez la journalisation dans l'environnement d'exécution gRPC. Parfois, vous devez examiner les journaux d'exécution gRPC pour comprendre un échec susceptible de ne pas être propagé vers un état de renvoi RPC. Par exemple, lorsqu'un RPC échoue avec un état indiquant que le délai a été dépassé, les journaux peuvent vous aider à comprendre l'échec sous-jacent ayant entraîné le dépassement du délai. Les mises en œuvre de gRPC différentes possèdent des manières variées d'activer la journalisation dans l'environnement d'exécution gRPC.

    • gRPC dans Java : gRPC utilise java.util.logging pour la journalisation. Définissez io.grpc.level sur le niveau FINE pour activer une journalisation détaillée suffisante dans l'environnement d'exécution gRPC. Une méthode courante pour activer la journalisation dans Java consiste à charger la configuration de journalisation à partir d'un fichier et à fournir l'emplacement de ce fichier à la JVM à l'aide d'une option de ligne de commande. Exemple :
    # Create a file called logging.properties with the following contents.
    handlers=java.util.logging.ConsoleHandler
    io.grpc.level=FINE
    io.grpc.xds.level=FINEST
    java.util.logging.ConsoleHandler.level=ALL
    java.util.logging.ConsoleHandler.formatter=java.util.logging.SimpleFormatter
    
    # Pass the location of the file to JVM via this command-line flag
    -Djava.util.logging.config.file=logging.properties
    

    Pour activer la journalisation spécifique aux modules xDS, définissez io.grpc.xds.level sur FINE. Pour afficher des informations de journalisation plus détaillées, définissez le niveau sur FINER ou FINEST.

    GRPC_GO_LOG_VERBOSITY_LEVEL=99 GRPC_GO_LOG_SEVERITY_LEVEL=info
    
    • Pour activer la journalisation avec gRPC dans C++, consultez les instructions ici. Pour activer la journalisation spécifique aux modules xDS, activez les traceurs suivants à l'aide de la variable d'environnement GRPC_TRACE, comme décrit ici, pour xds_client, xds_resolver, cds_lb, eds_lb, priority_lb, weighted_target_lb et lrs_lb.

Selon l'erreur qui figure dans l'état RPC ou dans les journaux d'exécution, votre problème peut appartenir à l'une des catégories suivantes.

Impossible de se connecter à Traffic Director

Pour résoudre les problèmes de connexion, procédez comme suit :

  • Vérifiez que la valeur server_uri dans le fichier d'amorçage est trafficdirector.googleapis.com:443.
  • Vérifiez que la variable d'environnement GRPC_XDS_BOOTSTRAP est définie et qu'elle pointe vers le fichier d'amorçage.
  • Veillez à utiliser le schéma xds dans l'URI lorsque vous créez un canal gRPC.
  • Assurez-vous que vous avez accordé les autorisations IAM requises pour créer des instances de calcul et modifier un réseau dans un projet.
  • Vérifiez que vous avez activé l'API Traffic Director dans le projet. Sous la section API et services Google Cloud Console de votre projet, recherchez les erreurs dans l'API Traffic Director.
  • Vérifiez que le compte de service dispose des autorisations appropriées. Les applications gRPC qui s'exécutent dans la VM ou le pod utilisent le compte de service de l'hôte de VM Compute Engine ou de l'instance de nœud Google Kubernetes Engine.
  • Vérifiez que le niveau d'accès aux API des VM Compute Engine ou des clusters GKE est défini de façon à accorder un accès complet aux API Compute Engine. Pour ce faire, spécifiez --scopes=https://www.googleapis.com/auth/cloud-platform lorsque vous créez les VM ou les clusters.
  • Vérifiez que vous pouvez accéder à trafficdirector.googleapis.com:443 à partir de la VM. En cas de problèmes d'accès, les causes possibles incluent un pare-feu empêchant l'accès à trafficdirector.googleapis.com via le port TCP 443 ou des problèmes de résolution DNS pour le nom d'hôte trafficdirector.googleapis.com.

Impossible de résoudre le nom d'hôte spécifié dans l'URI

Un message d'erreur semblable au suivant peut s'afficher dans vos journaux :

[Channel<1>: (xds:///my-service:12400)] Failed to resolve name. status=Status{code=UNAVAILABLE, description=NameResolver returned no usable address. addrs=[], attrs={}

Pour résoudre les problèmes liés à la résolution du nom d'hôte, procédez comme suit :

  • Consultez la section Versions et langages gRPC compatibles pour vous assurer que vous utilisez une version appropriée de gRPC.
  • Assurez-vous que le port utilisé dans l'URI pour créer un canal gRPC correspond à la valeur de port dans la règle de transfert utilisée dans votre configuration. Si aucun port n'est spécifié dans l'URI, la valeur 80 est utilisée pour mettre en correspondance une règle de transfert.
  • Assurez-vous que le nom d'hôte et le port utilisés dans l'URI pour créer un canal gRPC correspondent exactement à une règle d'hôte dans le mappage d'URL utilisé dans votre configuration.
  • Assurez-vous qu'une même règle d'hôte n'est pas configurée dans plusieurs mappages d'URL.
  • Assurez-vous qu'aucun caractère générique n'est utilisé. Les règles d'hôte contenant le caractère générique * sont ignorées.

Échec du RPC car le service n'est pas disponible

Pour résoudre les problèmes d'échec RPC lorsqu'un service n'est pas disponible, procédez comme suit :

  • Vérifiez l'état général de Traffic Director et l'état de vos services de backend sur Cloud Console. Assurez-vous que les mappages d'URL corrects font référence aux services de backend. Pour ce faire, consultez la colonne Cartes des règles de routage associées.
  • Vérifiez que les backends associés à vos services de backend sont opérationnels, comme indiqué dans la colonne Backends.
  • Si les backends ne sont pas opérationnels, cliquez sur le service de backend correspondant et assurez-vous que la vérification d'état correcte est configurée. Les vérifications d'état échouent généralement en raison de règles de pare-feu incorrectes ou manquantes, ou d'une différence au niveau des tags spécifiés dans la VM et dans les règles de pare-feu. Pour en savoir plus, consultez la page Créer des vérifications d'état.
  • Pour que les vérifications d'état gRPC fonctionnent correctement, les backends gRPC doivent mettre en œuvre le protocole de vérification de l'état gRPC. Si ce protocole n'est pas mis en œuvre, utilisez plutôt une vérification d'état TCP. N'utilisez pas de vérification d'état HTTP, HTTPS ou HTTP/2 avec les services gRPC.
  • Lorsque vous utilisez des groupes d'instances, assurez-vous que le port nommé spécifié dans le groupe d'instances correspond au port utilisé dans la vérification d'état. Lorsque vous utilisez des NEG, assurez-vous que la spécification du service GKE dispose de l'annotation NEG correcte et que la vérification d'état est configurée pour utiliser le port de diffusion des NEG.
  • Vérifiez que le protocole du point de terminaison est configuré en tant que GRPC.
  • Cliquez sur Cartes des règles de routage associées et vérifiez que les services de backend spécifiés dans les règles de correspondance de l'hôte sont corrects.

Étape suivante

Pour obtenir des informations de dépannage générales sur Traffic Director, consultez la page Dépannage des déploiements Traffic Director.