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 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
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 :
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.
Exemple de traitement d'une erreur d'état dans gRPC-Java. Notez qu'une erreur peut être causée par d'autres erreurs, qui peuvent fournir des informations supplémentaires.
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éfinissezio.grpc.level
sur le niveauFINE
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
surFINE
. Pour afficher des informations de journalisation plus détaillées, définissez le niveau surFINER
ouFINEST
.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 en à l'aide de la variable d'environnement
GRPC_TRACE
; pourxds_client
,xds_resolver
,cds_lb
,eds_lb
,priority_lb
,weighted_target_lb
etlrs_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 en à l'aide de la variable d'environnement
GRPC_TRACE
; pourxds_client
,xds_resolver
,cds_balancer
,eds_balancer
,priority
, etweighted_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 que vous Activez le compte de service pour accéder à l'API Traffic Director. Dans la section API et console Google Cloud services pour 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 TCP443
ou des problèmes de résolution DNS pour le nom d'hôtetrafficdirector.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 celui de votre 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 liés à Cloud Service Mesh de configuration.
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 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 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 :
- Vérifiez l'état de votre service de backend dans Google Cloud Console.
Accéder aux services Cloud Service Mesh - Assurez-vous que la journalisation est activée pour la ressource
HealthCheck
. - Si les vérifications d'état ont échoué récemment, inspectez Cloud Audit Logging pour déterminer si votre configuration
HealthCheck
a récemment été modifiée.
Étape suivante
- Pour découvrir le fonctionnement de Cloud Service Mesh, consultez la présentation de Cloud Service Mesh.
- Pour en savoir plus sur le fonctionnement de Cloud Service Mesh avec des services gRPC sans proxy, consultez la page Présentation de Cloud Service Mesh avec des services gRPC sans proxy.
- Pour obtenir des informations de dépannage générales sur Cloud Service Mesh, consultez la page Résoudre les problèmes des déploiements qui utilisent Envoy.
- Pour obtenir une assistance supplémentaire concernant l'utilisation de Cloud Service Mesh, consultez Obtenir de l'aide