Risolvere i problemi di deployment di 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 aiutarti a esaminare i problemi relativi a Cloud Service Mesh, consulta Informazioni sullo stato del client di Cloud Service Mesh.

Risolvere i problemi di errori RPC in un'applicazione gRPC

Esistono due modi comuni per risolvere i problemi di chiamata di procedura remota (RPC) in un'applicazione gRPC:

  1. Esamina lo stato restituito quando un RPC non va a buon fine. In genere, lo stato contiene informazioni sufficienti per aiutarti a capire la causa di un errore RPC.

  2. Abilita il logging nel runtime gRPC. A volte è necessario esaminare i log di runtime gRPC per comprendere un errore che potrebbe non essere propagato a uno stato di ritorno RPC. Ad esempio, quando un RPC non va a buon fine con uno stato che indica che la scadenza è stata superata, i log possono aiutarti a comprendere l'errore di fondo che ha causato il superamento della scadenza.

    Le implementazioni in lingue diverse di gRPC hanno modi diversi per attivare il logging nel runtime gRPC:

    • gRPC in Java: gRPC utilizza java.util.logging per il logging. Imposta io.grpc.level sul livello FINE per attivare un logging sufficientemente dettagliato nel runtime gRPC. Un modo tipico per attivare il logging in Java è caricare la configurazione di logging da un file e fornire la posizione del file alla JVM utilizzando un flag a 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 attivare il logging specifico per i moduli xDS, imposta io.grpc.xds.level su FINE. Per visualizzare un logging più dettagliato, imposta il livello su FINER o FINEST.

    • 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 attivare la registrazione con gRPC in C++, consulta le istruzioni riportate in Risoluzione dei problemi di gRPC. Per attivare la registrazione specifica per i moduli xDS, attiva i seguenti tracer utilizzando la variabile di ambiente GRPC_TRACE per xds_client, xds_resolver, cds_lb, eds_lb, priority_lb,weighted_target_lb e lrs_lb.

    • gRPC in Node.js: per attivare il logging con gRPC in Node.js, consulta le istruzioni riportate in Risoluzione dei problemi di gRPC-JS. Per attivare la registrazione specifica per i moduli xDS, attiva i seguenti tracer utilizzando la variabile di ambiente GRPC_TRACE per xds_client, xds_resolver, cds_balancer, eds_balancer, priority e weighted_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 quanto segue:

  • 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 indichi il file di bootstrap.
  • Assicurati di utilizzare lo schema xds nell'URI quando crei un canale gRPC.
  • Assicurati di aver concesso le autorizzazioni IAM richieste per la creazione di istanze di calcolo e la modifica di una rete in un progetto.
  • Assicurati di abilitare l'account di servizio per accedere all'API Traffic Director. Nella sezione API e servizi della console Google Cloud per il tuo progetto, cerca gli errori nell'API Traffic Director.
  • Verifica che l'account di servizio abbia le autorizzazioni corrette. Le applicazioni gRPC in esecuzione nella VM o nel pod utilizzano l'account di servizio dell'host della VM Compute Engine o dell'istanza del nodo Google Kubernetes Engine (GKE).

  • Verifica che l'ambito di accesso alle API delle VM Compute Engine o dei cluster GKE sia impostato per 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

  • Verifica di poter accedere a trafficdirector.googleapis.com:443 dalla VM. Se si verificano problemi di accesso, i motivi possibili includono un firewall che impedisce l'accesso a trafficdirector.googleapis.com tramite la porta TCP 443 o problemi di risoluzione DNS per il nome host trafficdirector.googleapis.com.

Impossibile risolvere il nome host specificato nell'URI

Nei log potresti visualizzare un messaggio di errore come il 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 quanto segue:

  • Assicurati di utilizzare una versione e una lingua gRPC supportate.
  • 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 una porta non è specificata nell'URI, viene utilizzato il valore 80 per trovare una corrispondenza 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 riesce perché il servizio non è disponibile

Per risolvere i problemi di 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 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, verifica che i backend associati ai tuoi servizi di backend siano operativi.
    • Se i backend non sono in stato di integrità, fai clic sul servizio di backend corrispondente e assicurati che sia configurato il controllo di integrità corretto. I controlli di integrità spesso non vanno a buon fine a causa di regole firewall errate o mancanti o di una mancata corrispondenza dei tag specificati nella VM e nelle regole firewall. Per ulteriori informazioni, consulta Creare controlli di integrità.

  • Affinché i controlli di integrità gRPC funzionino correttamente, i backend gRPC devono implementare il protocollo di 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 del servizio GKE abbia l'annotazione NEG corretta e che il controllo di integrità sia configurato per utilizzare la porta di servizio 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 potresti visualizzare un messaggio di errore come 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 del client in uso. Per risolvere il problema, aggiorna la configurazione del servizio di backend in modo da utilizzare solo i criteri di bilanciamento del carico supportati o esegui l'upgrade del client a una versione supportata. Per le versioni client supportate, consulta Funzionalità xDS in gRPC.

La configurazione di sicurezza non viene generata come previsto

Se stai configurando la sicurezza del servizio e la configurazione di sicurezza non viene generata come previsto, esamina i criteri di endpoint nel tuo deployment.

Cloud Service Mesh non supporta gli scenari in cui sono presenti due o più risorse di criteri endpoint che corrispondono allo stesso modo a un endpoint, ad esempio due criteri con le stesse etichette e porte o due o più criteri con etichette diverse che corrispondono allo stesso modo alle etichette di un endpoint. Per ulteriori informazioni su come vengono abbinati i criteri relativi agli endpoint alle etichette di un endpoint, consulta le API per EndpointPolicy.EndpointMatcher.MetadataLabelMatcher. In queste situazioni, Cloud Service Mesh non genera la configurazione di sicurezza da nessuno dei criteri in conflitto.

Risolvere i problemi di 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 è in stato operativo

Per una maggiore affidabilità, quando il 99% degli endpoint non è in stato di salute, Cloud Service Mesh configura il piano dati in modo da ignorare lo stato di salute degli endpoint. Il piano dati bilancia invece il traffico tra tutti gli endpoint perché è possibile che la porta di pubblicazione sia ancora funzionale.

I backend non integri causano una distribuzione non ottimale del traffico

Cloud Service Mesh utilizza le informazioni nella risorsa HealthCheck collegata 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 dei tuoi backend non sono operativi, il traffico potrebbe continuare a essere elaborato, ma con una distribuzione non ottimale. Ad esempio, il traffico potrebbe essere indirizzato a una regione in cui sono ancora presenti backend funzionanti, ma che è molto più lontana dal client, introducendo la latenza. Per identificare e monitorare lo stato di salute dei tuoi backend, prova a seguire questi passaggi:

Passaggi successivi