Résoudre les problèmes liés au déploiement des services gRPC sans proxy

Ce document fournit des informations pour vous aider à résoudre les problèmes de configuration liés au déploiement de services gRPC sans proxy avec Cloud Service Mesh. 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 à Cloud Service Mesh, consultez la section Comprendre l'état du client Cloud Service Mesh.

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.

  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 by using 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 dans Go : activez la journalisation en définissant des variables d'environnement.

      GRPC_GO_LOG_VERBOSITY_LEVEL=99 GRPC_GO_LOG_SEVERITY_LEVEL=info

    • gRPC dans C++ : pour activer la journalisation avec gRPC dans C++, consultez les instructions de la section Dépannage de gRPC. Pour activer la journalisation spécifique aux modules xDS, activez les traceurs suivants à l'aide de la variable d'environnement GRPC_TRACE pour xds_client, xds_resolver, cds_lb, eds_lb, priority_lb, weighted_target_lb et lrs_lb.

    • gRPC dans Node.js : pour activer la journalisation avec gRPC dans Node.js, consultez les instructions de la section Dépannage de gRPC-JS. Pour activer la journalisation spécifique aux modules xDS, activez les traceurs suivants à l'aide de la variable d'environnement GRPC_TRACE pour xds_client, xds_resolver, cds_balancer, eds_balancer, priority et weighted_target.

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 à Cloud Service Mesh

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.
  • Assurez-vous d'autoriser le compte de service à accéder à l'API Traffic Director. 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 exécutées 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 (GKE).

  • 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 les éléments suivants lorsque vous créez les VM ou le cluster :

    --scopes=https://www.googleapis.com/auth/cloud-platform

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

  • Veillez à utiliser une version et un langage gRPC compatibles.
  • 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 Cloud Service Mesh et l'état de vos services de backend dans la console Google Cloud:

    • Dans la colonne Cartes de règles de routage associés, vérifiez que les mappages d'URL corrects font référence aux services de backend. Cliquez sur la colonne pour vérifier que les services de backend spécifiés dans les règles de correspondance de l'hôte sont corrects.
    • Dans la colonne Backends, vérifiez que les backends associés à vos services de backend sont opérationnels.
    • 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 d'état gRPC. Si ce protocole n'est pas implémenté, 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 groupes de points de terminaison du réseau (NEG), assurez-vous que la spécification de service GKE possède l'annotation NEG appropriée et que la vérification d'état est configurée pour utiliser le port de diffusion du NEG.

  • Vérifiez que le protocole du point de terminaison est configuré en tant que GRPC.

Le RPC échoue, car la règle d'équilibrage de charge n'est pas compatible.

Vous pourriez rencontrer un message d'erreur de ce type dans vos journaux :

error parsing "CDS" response: resource "cloud-internal-istio:cloud_mp_248715":
unexpected lbPolicy RING_HASH in response

error={"description":"errors parsing CDS response",
"file":"external/com_github_grpc_grpc/src/core/ext/xds/xds_api.cc", "file_line":3304,
"referenced_errors":[{"description":"cloud-internal-istio:cloud_mp_248715: LB policy is not supported."

WARNING: RPC failed: Status{code=INTERNAL, description=Panic! This is a bug!, cause=java.lang.NullPointerException: provider
at com.google.common.base.Preconditions.checkNotNull(Preconditions.java:910)
at io.grpc.internal.ServiceConfigUtil$PolicySelection.<init>(ServiceConfigUtil.java:418)
at io.grpc.xds.CdsLoadBalancer2$CdsLbState.handleClusterDiscovered(CdsLoadBalancer2.java:190)

En effet, RING_HASH n'est pas compatible avec le langage et la version du client utilisé. Pour résoudre le problème, mettez à jour la configuration du service de backend pour n'utiliser que les règles d'équilibrage de charge compatibles ou mettez à niveau le client vers une version compatible. Pour connaître les versions de client compatibles, consultez la page Fonctionnalités xDS dans gRPC.

La configuration de la sécurité n'est pas générée comme prévu

Si vous configurez la sécurité du service et que celle-ci n'est pas générée comme prévu, examinez les règles de point de terminaison de votre déploiement.

Cloud Service Mesh n'est pas compatible avec les scénarios dans lesquels deux ressources de règles de point de terminaison ou plus correspondent à un même point de terminaison (par exemple, deux règles ayant les mêmes libellés et ports, ou bien deux règles ou plus ayant des libellés différents qui correspondent de manière identique aux libellés d'un point de terminaison). Pour en savoir plus sur la mise en correspondance des règles de point de terminaison avec les libellés d'un point de terminaison, consultez les API pour EndpointPolicy.EndpointMatcher.MetadataLabelMatcher. Dans de telles situations, Cloud Service Mesh ne génère aucune configuration de sécurité basée sur les règles en conflit.

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 ne sont pas opérationnels

Pour une meilleure fiabilité, lorsque 99% des points de terminaison ne sont pas opérationnels, Cloud Service Mesh 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

Cloud Service Mesh utilise les informations de la ressource HealthCheck associée à un service de backend pour évaluer l'état des backends. Cloud Service Mesh 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:

Étape suivante