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

Risoluzione degli errori RPC in un'applicazione gRPC

Esistono due modi comuni per risolvere gli errori delle chiamata di procedura remota (RPC) in un'applicazione gRPC:

  1. Esamina lo stato restituito in caso di errore di una RPC. Di solito, lo stato contenga informazioni sufficienti per aiutarti a capire la causa di una RPC errore.

  2. Abilita il logging nel runtime gRPC. A volte devi esaminare la richiesta log di runtime per comprendere un errore che potrebbe non essere propagato nuovamente Stato restituito RPC. Ad esempio, quando una RPC ha esito negativo con uno stato che indica che la scadenza sia stata superata, i log possono aiutarti a comprendere un errore sottostante che ha causato il superamento della scadenza.

    Le diverse implementazioni di gRPC in linguaggio possono nel runtime gRPC:

    • gRPC in Java:gRPC utilizza java.util.logging per il logging. Imposta io.grpc.level al livello FINE per abilitare il logging dettagliato sufficiente nel runtime gRPC. Un modo tipico per abilitare il logging in Java è caricare configurazione di logging da un file e fornire la posizione 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 su FINE. Per visualizzare log più dettagliati, imposta il livello su FINER o FINEST.

    • gRPC in Go:attiva il logging entro il giorno l'impostazione delle 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, abilita i seguenti strumenti di tracciabilità 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 abilitare il logging con gRPC in Node.js, consulta le istruzioni in Risoluzione dei problemi di gRPC-JS. Per abilitare il logging specifico per i moduli xDS, abilita i seguenti strumenti di tracciabilità 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 potrebbero 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 che rimanda al file di bootstrap.
  • Assicurati di utilizzare lo schema xds nell'URI quando crei una gRPC canale.
  • Assicurati di aver concesso i Autorizzazioni IAM per creare istanze di calcolo e modificare una rete in un progetto.
  • Assicurati di aver attivato il API Traffic Director per il progetto. Nella sezione API e API 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 l'host della VM di Compute Engine o il nodo Google Kubernetes Engine (GKE) in esecuzione in un'istanza Compute Engine.

  • Verifica che l'ambito di accesso all'API delle VM di Compute Engine I cluster GKE sono impostati per consentire l'accesso completo le API di Compute Engine. Per farlo specificando 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. Se ci sono problemi di accesso, i possibili motivi includono un firewall che impedisce accesso a trafficdirector.googleapis.com tramite la porta TCP 443 o DNS problemi di risoluzione per il nome host trafficdirector.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 un versione e lingua di gRPC supportate.
  • Assicurati che la porta utilizzata nell'URI per creare un canale gRPC corrisponda alla porta nella regola di forwarding utilizzata nella tua configurazione. Se una porta non è specificato nell'URI, il valore 80 viene utilizzato 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 corrisponde 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. Regole host contenenti un carattere jolly * vengono ignorati.

RPC non riesce perché il servizio non è disponibile

Per risolvere gli errori RPC quando un servizio non è disponibile, prova il seguenti:

  • Controlla lo stato generale di Cloud Service Mesh e lo stato della tua di backend nella console Google Cloud:

    • Nella colonna Mappe di regole di routing associate, verifica che l'URL corretto fanno 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 al tuo che i servizi di backend siano in stato integro.
    • Se i backend sono in stato non integro, fai clic sul servizio di backend corrispondente e per assicurarti che sia configurato il controllo di integrità corretto. Controlli di integrità comuni a causa di regole firewall errate o mancanti oppure a causa di una mancata corrispondenza i tag specificati nella VM e nelle regole del firewall. Per ulteriori informazioni, consulta la sezione Creazione dei controlli di integrità.

  • Affinché i controlli di integrità gRPC funzionino correttamente, i backend gRPC devono implementare il parametro protocollo per il controllo di integrità gRPC. Se questo protocollo non è implementato, utilizza un controllo di integrità TCP. Azioni sconsigliate Utilizzare un controllo di integrità HTTP, HTTPS o HTTP/2 con i servizi gRPC.

  • Quando utilizzi gruppi di istanze, assicurati che la porta denominata specificata gruppo di istanze corrisponda alla porta utilizzata nel controllo di integrità. Quando utilizzi la rete di endpoint (NEG), assicurano che la specifica del servizio GKE abbia l'annotazione NEG corretta e il controllo di integrità è configurato per utilizzare il NEG porta di distribuzione.

  • Verifica che il protocollo dell'endpoint sia configurato come GRPC.

RPC non riesce perché il criterio di bilanciamento del carico non è supportato

Nei log potresti visualizzare 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 specifica e del client in uso. Per risolvere il problema, aggiorna il backend configurazione del servizio per utilizzare solo criteri di bilanciamento del carico supportati oppure esegui l'upgrade il 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 della sicurezza generati come previsto, esamina i criteri dell'endpoint nel tuo deployment.

Cloud Service Mesh non supporta scenari in cui sono presenti due o più endpoint di criteri che corrispondano equamente a un endpoint, ad esempio due i criteri con le stesse etichette e porte oppure con due o più criteri che corrispondano equamente alle etichette di un endpoint. Per ulteriori informazioni i criteri dell'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 qualsiasi criterio in conflitto.

Risolvi i problemi relativi all'integrità del tuo mesh di servizi

Questa guida fornisce informazioni per aiutarti a risolvere i problemi di Cloud Service Mesh di configurazione.

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 l'integrità stato degli endpoint. Invece, il piano dati bilancia il traffico tra tutti i gli endpoint perché è possibile che la porta di gestione sia ancora funzionante.

I backend non integri causano una distribuzione non ottimale del traffico

Cloud Service Mesh utilizza le informazioni della risorsa HealthCheck collegato a un servizio di backend per valutare l'integrità dei tuoi backend. Cloud Service Mesh utilizza questo stato di integrità per instradare il traffico alla integro più vicino. Se alcuni dei tuoi backend sono in stato non integro, il traffico potrebbe continuano a essere elaborati, ma con una distribuzione non ottimale. Ad esempio, il traffico potrebbe passare a una regione in cui sono ancora presenti backend integri, ma che molto più lontano dal client, introducendo la latenza. Per identificare e monitorare di integrità dei 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 funzionare di recente, esamina gli audit log di Cloud per determinare se la configurazione di HealthCheck è stata modificata di recente.

Passaggi successivi