Risolvere i problemi di deployment gRPC senza proxy
Questo documento fornisce informazioni per aiutarti a risolvere i problemi di configurazione quando esegui il deployment di servizi gRPC senza proxy con Cloud Service Mesh. Per informazioni su come utilizzare l'API Client Status Discovery Service (CSDS) per analizzare i problemi relativi a Cloud Service Mesh, consulta Informazioni sullo stato del client Cloud Service Mesh.
Risoluzione dei problemi relativi agli errori RPC in un'applicazione gRPC
Esistono due modi comuni per risolvere gli errori delle chiamata di procedura remota (RPC) in un'applicazione gRPC:
Esamina lo stato restituito in caso di errore di una RPC. In genere, lo stato contiene informazioni sufficienti per capire la causa di un errore RPC.
La gestione degli errori di stato in gRPC è spiegata nella documentazione sulla gestione degli errori gRPC.
Esempio di gestione degli errori di stato in gRPC-Java. Un'eccezione potrebbe avere come causa altre eccezioni, che potrebbero fornire informazioni aggiuntive.
Abilita il logging nel runtime gRPC. A volte è necessario esaminare i log di runtime gRPC per comprendere un errore che potrebbe non essere propagato nuovamente a uno stato di restituzione RPC. Ad esempio, in caso di errore di una RPC con uno stato che indica che la scadenza è stata superata, i log possono aiutarti a comprendere l'errore sottostante che ha causato il superamento della scadenza.
Le diverse implementazioni dei linguaggi di gRPC hanno modi diversi per abilitare il logging nel runtime gRPC:
gRPC in Java:gRPC utilizza
java.util.logging
per il logging. Impostaio.grpc.level
sul livelloFINE
per abilitare un logging dettagliato sufficiente nel runtime gRPC. Un modo tipico per abilitare il logging in Java è caricare la configurazione di logging da un file e fornire il percorso del file a JVM utilizzando un flag della riga di comando. Ad esempio:# 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
Per abilitare il logging specifico per i moduli xDS, imposta
io.grpc.xds.level
suFINE
. Per visualizzare il logging più dettagliato, imposta il livello suFINER
oFINEST
.gRPC in Go: attiva il logging impostando le variabili di ambiente.
GRPC_GO_LOG_VERBOSITY_LEVEL=99 GRPC_GO_LOG_SEVERITY_LEVEL=info
gRPC in C++:per abilitare il logging con gRPC in C++, consulta le istruzioni in Risoluzione dei problemi di gRPC. Per abilitare il logging specifico per i moduli xDS, attiva le seguenti tracce di traccia utilizzando la variabile di ambiente
GRPC_TRACE
perxds_client
,xds_resolver
,cds_lb
,eds_lb
,priority_lb
,weighted_target_lb
elrs_lb
.gRPC in Node.js: per abilitare il logging con gRPC in Node.js, consulta le istruzioni in Risoluzione dei problemi relativi a gRPC-JS. Per abilitare il logging specifico per i moduli xDS, attiva le seguenti tracce di traccia utilizzando la variabile di ambiente
GRPC_TRACE
perxds_client
,xds_resolver
,cds_balancer
,eds_balancer
,priority
eweighted_target
.
A seconda dell'errore nello stato RPC o nei log di runtime, il problema potrebbe rientrare in una delle seguenti categorie.
Impossibile connettersi a Cloud Service Mesh
Per risolvere i problemi di connessione, prova a procedere nel seguente modo:
- Verifica che il valore server_uri nel file di bootstrap sia
trafficdirector.googleapis.com:443
. - Assicurati che la variabile di ambiente
GRPC_XDS_BOOTSTRAP
sia definita e che rimandi al file di bootstrap. - Quando crei un canale gRPC, assicurati di utilizzare lo schema
xds
nell'URI. - Assicurati di aver concesso le autorizzazioni IAM necessarie per la creazione di istanze di calcolo e la modifica di una rete in un progetto.
- Assicurati di aver abilitato l'API Traffic Director per il progetto. Sotto API e servizi della console Google Cloud per il tuo progetto, cerca gli errori nell'API Traffic Director.
- Verifica che l'account di servizio disponga delle autorizzazioni corrette. Le applicazioni gRPC in esecuzione nella VM o nel pod utilizzano l'account di servizio dell'host delle VM di Compute Engine o dell'istanza del nodo Google Kubernetes Engine (GKE).
Verifica che l'ambito di accesso API delle VM di Compute Engine o dei cluster GKE sia impostato in modo da consentire l'accesso completo alle API Compute Engine. Per farlo, specifica quanto segue quando crei le VM o il cluster:
--scopes=https://www.googleapis.com/auth/cloud-platform
Conferma di poter accedere a
trafficdirector.googleapis.com:443
dalla VM. In caso di problemi di accesso, le possibili cause includono un firewall che impedisce l'accesso atrafficdirector.googleapis.com
sulla porta TCP443
o problemi di risoluzione DNS per il nome hosttrafficdirector.googleapis.com
.
Il nome host specificato nell'URI non può essere risolto
Nei tuoi log potrebbe essere visualizzato un messaggio di errore simile al seguente:
[Channel<1>: (xds:///my-service:12400)] Failed to resolve name. status=Status{code=UNAVAILABLE, description=NameResolver returned no usable address. addrs=[], attrs={}
Per risolvere i problemi di risoluzione dei nomi host, prova a procedere nel seguente modo:
- Assicurati di utilizzare una versione e una lingua gRPC supportati.
- Assicurati che la porta utilizzata nell'URI per creare un canale gRPC corrisponda al valore della porta nella regola di forwarding utilizzata nella configurazione. Se nell'URI non è specificata una porta, viene utilizzato il valore
80
per trovare corrispondenze con una regola di forwarding. - Assicurati che il nome host e la porta utilizzati nell'URI per creare un canale gRPC corrispondano esattamente a una regola host nella mappa URL utilizzata nella configurazione.
- Assicurati che la stessa regola host non sia configurata in più di una mappa URL.
- Assicurati che non siano in uso caratteri jolly. Le regole host contenenti un carattere jolly
*
vengono ignorate.
L'RPC non va a buon fine perché il servizio non è disponibile
Per risolvere gli errori RPC quando un servizio non è disponibile, prova quanto segue:
Controlla lo stato generale di Cloud Service Mesh e lo stato dei servizi di backend nella console Google Cloud:
- Nella colonna Mappe di regole di routing associate, assicurati che le mappe di URL corrette facciano riferimento ai servizi di backend. Fai clic sulla colonna per verificare che i servizi di backend specificati nelle regole di corrispondenza dell'host siano corretti.
- Nella colonna Backend, controlla che i backend associati ai servizi di backend siano integri.
- Se i backend non sono integri, fai clic sul servizio di backend corrispondente e assicurati che sia configurato il controllo di integrità corretto. In genere i controlli di integrità non riescono a causa di regole firewall errate o mancanti o di una mancata corrispondenza tra i tag specificati nella VM e nelle regole firewall. Per ulteriori informazioni, consulta la sezione Creazione di controlli di integrità.
Affinché i controlli di integrità gRPC funzionino correttamente, i backend gRPC devono implementare il protocollo per il controllo di integrità gRPC. Se questo protocollo non è implementato, utilizza un controllo di integrità TCP. Non utilizzare un controllo di integrità HTTP, HTTPS o HTTP/2 con i servizi gRPC.
Quando utilizzi i gruppi di istanze, assicurati che la porta denominata specificata nel gruppo di istanze corrisponda a quella utilizzata nel controllo di integrità. Quando utilizzi i gruppi di endpoint di rete (NEG), assicurati che la specifica di servizio GKE abbia l'annotazione NEG corretta e che il controllo di integrità sia configurato per utilizzare la porta di pubblicazione NEG.
Verifica che il protocollo dell'endpoint sia configurato come
GRPC
.
L'RPC non riesce perché il criterio di bilanciamento del carico non è supportato
Nei log potrebbe essere visualizzato un messaggio di errore simile a uno dei seguenti:
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)
Questo perché RING_HASH non è supportato dalla lingua e dalla versione specifiche del client in uso. Per risolvere il problema, aggiorna la configurazione del servizio di backend in modo che utilizzi solo i criteri di bilanciamento del carico supportati oppure esegui l'upgrade del client a una versione supportata. Per le versioni client supportate, consulta Funzionalità xDS in gRPC.
La configurazione di sicurezza non è stata generata come previsto
Se stai configurando la sicurezza dei servizi e la configurazione di sicurezza non viene generata come previsto, esamina i criteri degli endpoint nel deployment.
Cloud Service Mesh non supporta scenari in cui esistono due o più risorse dei criteri degli endpoint che corrispondono equamente a un endpoint, ad esempio due criteri con le stesse etichette e porte oppure due o più criteri con etichette diverse che corrispondono equamente alle etichette di un endpoint. Per ulteriori informazioni su come i criteri degli endpoint vengono abbinati alle etichette di un endpoint, consulta le API per EndpointPolicy.EndpointMatcher.MetadataLabelMatcher. In questi casi, Cloud Service Mesh non genera una configurazione di sicurezza da nessuno dei criteri in conflitto.
Risolvi i problemi relativi all'integrità del mesh di servizi
Questa guida fornisce informazioni per aiutarti a risolvere i problemi di configurazione di Cloud Service Mesh.
Comportamento di Cloud Service Mesh quando la maggior parte degli endpoint non è integro
Per una maggiore affidabilità, quando il 99% degli endpoint non è integro, Cloud Service Mesh configura il piano dati in modo da ignorare lo stato di integrità degli endpoint. Al contrario, il piano dati bilancia il traffico tra tutti gli endpoint perché è possibile che la porta di gestione sia ancora funzionante.
I backend in stato non integro causano una distribuzione non ottimale del traffico
Cloud Service Mesh utilizza le informazioni nella risorsa HealthCheck
associata a un servizio di backend per valutare l'integrità dei backend.
Cloud Service Mesh utilizza questo stato di integrità per instradare il traffico al backend integro più vicino. Se alcuni backend non sono integri, il traffico potrebbe continuare a essere elaborato, ma con una distribuzione non ottimale. Ad esempio, il traffico potrebbe passare in una regione in cui sono ancora presenti backend integri, ma molto più distante dal client, con conseguente latenza. Per identificare e monitorare lo stato di integrità dei tuoi backend, prova a seguire questi passaggi:
- Controlla lo stato di integrità del tuo servizio di backend nella console Google Cloud.
Vai ai servizi Cloud Service Mesh - Assicurati che il logging sia abilitato per la risorsa
HealthCheck
. - Se i controlli di integrità hanno iniziato a non riuscire di recente, controlla Cloud Audit Logs per determinare se la configurazione di
HealthCheck
è stata modificata di recente.
Passaggi successivi
- Per informazioni sul funzionamento di Cloud Service Mesh, consulta la panoramica di Cloud Service Mesh.
- Per scoprire come funziona Cloud Service Mesh con i servizi gRPC senza proxy, consulta la panoramica su Cloud Service Mesh con servizi gRPC senza proxy.
- Per trovare informazioni generali sulla risoluzione dei problemi di Cloud Service Mesh, consulta Risoluzione dei problemi relativi ai deployment che utilizzano Envoy.
- Per ulteriore assistenza per l'utilizzo di Cloud Service Mesh, consulta Ricevere assistenza.