Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Risolvere i problemi relativi ai deployment gRPC proxyless

Questo documento fornisce informazioni che ti aiutano a risolvere i problemi di configurazione quando esegui il deployment di servizi gRPC proxyless con Traffic Director. Per informazioni su come utilizzare l'API CSDS (Client Status Discovery Service) per esaminare i problemi relativi a Traffic Director, consulta Informazioni sullo stato del client di Traffic Director.

Risoluzione degli errori RPC in un'applicazione gRPC

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

  1. Controlla 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 in 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 una RPC non riesce e ha 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 implementazioni in diverse lingue di gRPC hanno modi diversi di abilitare il logging nel runtime di gRPC:

    • gRPC in Java: gRPC utilizza java.util.logging per il logging. Imposta io.grpc.level sul livello FINE 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 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 informazioni di log più dettagliate, 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 abilitare il logging con gRPC in C++, consulta le istruzioni in Risolvere i problemi relativi a gRPC. Per attivare il logging specifico per i moduli xDS, abilita i seguenti tracciatori 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 attivare il logging specifico per i moduli xDS, abilita i seguenti tracciatori 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 Traffic Director

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 sia definita la variabile di ambiente GRPC_XDS_BOOTSTRAP e che rimandi al file bootstrap.
  • Assicurati di utilizzare lo schema xds nell'URI quando crei un canale gRPC.
  • Assicurati di aver concesso le autorizzazioni IAM obbligatori per creare istanze di calcolo e modificare una rete in un progetto.
  • Assicurati di aver attivato l'API Traffic Director per il progetto. Nella sezione API e servizi di Google Cloud Console del 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 VM di Compute Engine o l'istanza del nodo Google Kubernetes Engine (GKE).

  • Conferma che l'ambito dell'accesso API delle VM di Compute Engine o dei cluster GKE sia impostato in modo da consentire l'accesso completo alle API Compute Engine. A tale scopo, 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 ci sono problemi di accesso, i possibili motivi 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.

Il nome host specificato nell'URI non può essere risolto

Nei log potresti visualizzare 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 relativi alla risoluzione dei nomi host, prova a procedere nel seguente modo:

  • Assicurati di utilizzare una lingua e una versione 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 la 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.
  • Verificare che non siano in uso caratteri jolly. Le regole host contenenti un carattere jolly * vengono ignorate.

RPC non riesce perché il servizio non è disponibile

Per risolvere i problemi relativi agli errori RPC quando un servizio non è disponibile, prova a procedere nel seguente modo:

  • Controlla lo stato generale di Traffic Director e lo stato dei tuoi servizi di backend in Google Cloud Console:

    • Nella colonna Mappa di regole di routing associate, assicurati che le mappe degli 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 in stato integro.
    • Se i backend sono in stato non integro, fai clic sul servizio di backend corrispondente e assicurati che sia configurato il controllo di integrità corretto. In genere, i controlli di integrità hanno esito negativo a causa di regole firewall errate o mancanti o di una mancata corrispondenza nei tag specificati nella VM e nelle regole firewall. Per ulteriori informazioni, consulta la sezione Creare controlli di integrità.

  • Affinché i controlli di integrità di 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 nel gruppo di istanze corrisponda alla porta utilizzata nel controllo di integrità. Quando utilizzi gruppi di endpoint di rete (NEG), assicurati che le specifiche del servizio GKE dispongano dell'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.

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 versione specifica del client utilizzato. 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 le 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 è stata generata come previsto, esamina i criteri degli endpoint nel tuo deployment.

Traffic Director non supporta gli scenari in cui sono presenti due o più risorse di criteri endpoint che corrispondono in modo uguale a un endpoint, ad esempio due criteri con le stesse etichette e porte o due o più criteri con etichette diverse che corrispondono alla stessa etichetta 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, Traffic Director non genera una configurazione di sicurezza da uno qualsiasi dei criteri in conflitto.

Risolvere i problemi relativi all'integrità del mesh di servizi

Questa guida fornisce informazioni utili per risolvere i problemi di configurazione di Traffic Director.

Comportamento di Traffic Director quando la maggior parte degli endpoint è in stato non integro

Per una maggiore affidabilità, quando il 99% degli endpoint non è in stato integro, Traffic Director configura il piano dati in modo da ignorare lo stato di integrità degli endpoint. Invece, il piano dati bilancia il traffico tra tutti gli endpoint perché è possibile che la porta di pubblicazione sia ancora funzionante.

I backend in stato non integro causano una distribuzione non ottimale del traffico

Traffic Director utilizza le informazioni nella risorsa HealthCheck collegata a un servizio di backend per valutare l'integrità dei tuoi backend. Traffic Director utilizza questo stato di integrità per instradare il traffico al backend integro più vicino. Se alcuni dei tuoi backend sono in stato non integro, il traffico potrebbe continuare a essere elaborato, ma con una distribuzione non ottimale. Ad esempio, il traffico potrebbe arrivare a un'area geografica in cui sono ancora presenti backend integri, ma molto più lontano dal client. Per identificare e monitorare lo stato di integrità dei backend, prova i passaggi seguenti:

I backend rifiutano inaspettatamente il traffico

Se hai configurato la sicurezza del servizio di Traffic Director, utilizzi la risorsa EndpointPolicy per applicare i criteri di sicurezza ai backend. EndpointPolicy errori di configurazione potrebbero far sì che il tuo backend rifiuti il traffico. Utilizza i seguenti log per risolvere il problema:

Passaggi successivi