Risolvere i problemi dei deployment Envoy

Questa guida fornisce informazioni per aiutarti a risolvere i problemi di configurazione con i client Envoy quando esegui Cloud Service Mesh con le API di Google. 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.

Determinazione della versione di Envoy installata su una VM

Utilizza queste istruzioni per verificare quale versione di Envoy è in esecuzione su un'istanza di macchina virtuale (VM).

Per verificare o controllare la versione di Envoy, puoi effettuare una delle seguenti operazioni:

Controlla gli attributi guest della VM nel percorso gce-service-proxy/proxy-version:

  gcloud compute --project cloud-vm-mesh-monitoring instances get-guest-attributes INSTANCE_NAME 

      --zone ZONEc --query-path=gce-service-proxy/proxy-version



NAMESPACE          KEY            VALUE
  gce-service-proxy  proxy-version  dc78069b10cc94fa07bb974b7101dd1b42e2e7bf/1.15.1-dev/Clean/RELEASE/BoringSSL

Controlla i log dell'istanza Cloud Logging nella pagina Logging dei dettagli dell'istanza VM nella console Google Cloud con una query come questa:

  resource.type="gce_instance"
  resource.labels.instance_id="3633122484352464042"
  jsonPayload.message:"Envoy version"

Riceverai una risposta simile alla seguente:

  {
    "insertId": "9zy0btf94961a",
    "jsonPayload": {
      "message": "Envoy Version: dc78069b10cc94fa07bb974b7101dd1b42e2e7bf/1.15.1-dev/Clean/RELEASE/BoringSSL",
      "localTimestamp": "2021-01-12T11:39:14.3991Z"
    },
    "resource": {
      "type": "gce_instance",
      "labels": {
        "zone": "asia-southeast1-b",
        "instance_id": "3633122484352464042",
        "project_id": "cloud-vm-mesh-monitoring"
      }
    },
    "timestamp": "2021-01-12T11:39:14.399200504Z",
    "severity": "INFO",
    "logName": "projects/cloud-vm-mesh-monitoring/logs/service-proxy-agent",
    "receiveTimestamp": "2021-01-12T11:39:15.407023427Z"
  }

Usa SSH per connetterti a una VM e verificare la versione binaria:

  YOUR_USER_NAME@backend-mig-5f5651e1-517a-4269-b457-f6bdcf3d98bc-m3wt:~$ /usr/local/bin/envoy --version



/usr/local/bin/envoy  version: dc78069b10cc94fa07bb974b7101dd1b42e2e7bf/1.15.1-dev/Clean/RELEASE/BoringSSL

Utilizza SSH per connetterti a una VM e all'interfaccia di amministrazione come root:

  root@backend-mig-5f5651e1-517a-4269-b457-f6bdcf3d98bc-m3wt:~# curl localhost:15000/server_info
  {
   "version": "dc78069b10cc94fa07bb974b7101dd1b42e2e7bf/1.15.1-dev/Clean/RELEASE/BoringSSL",
   "state": "LIVE",
   "hot_restart_version": "disabled",
   ...
  }

Posizioni dei log di Envoy

Per risolvere alcuni problemi, è necessario esaminare i log del proxy Envoy.

Puoi utilizzare SSH per connetterti all'istanza VM e ottenere il file di log. È probabile che il percorso sia il seguente.

  /var/log/envoy/envoy.err.log

I proxy non si connettono a Cloud Service Mesh

Se i tuoi proxy non si connettono a Cloud Service Mesh:

  • Verifica la presenza di errori di connessione a trafficdirector.googleapis.com nei log del proxy Envoy.

  • Se configuri netfilter (utilizzando iptables) per reindirizzare tutto il traffico al proxy Envoy, assicurati che l'utente (UID) utilizzato per eseguire il proxy sia escluso dal reindirizzamento. In caso contrario, il traffico torna al proxy in modo continuativo.

  • Assicurati di aver abilitato l'API Cloud Service Mesh per il progetto. Nella sezione API e servizi del tuo progetto, cerca gli errori relativi all'API Cloud Service Mesh.

  • Verifica che l'ambito di accesso API della VM sia impostato in modo da consentire l'accesso completo alle API Google Cloud specificando quanto segue quando crei la VM:

    --scopes=https://www.googleapis.com/auth/cloud-platform

  • Verifica che l'account di servizio disponga delle autorizzazioni corrette. Per ulteriori informazioni, consulta Abilitare l'account di servizio per accedere all'API Traffic Director.

  • Conferma di poter accedere a trafficdirector.googleapis.com:443 dalla VM. Se si verificano problemi con questo accesso, i possibili motivi potrebbero essere un firewall che impedisce l'accesso a trafficdirector.googleapis.com sulla porta TCP 443 o problemi di risoluzione DNS per il nome host trafficdirector.googleapis.com.

  • Se utilizzi Envoy per il proxy sidecar, verifica che la versione di Envoy sia 1.24.9 o successiva.

Il servizio configurato con Cloud Service Mesh non è raggiungibile

Se un servizio configurato con Cloud Service Mesh non è raggiungibile, verifica che il proxy sidecar sia in esecuzione e in grado di connettersi a Cloud Service Mesh.

Se utilizzi Envoy come proxy sidecar, puoi verificarlo eseguendo questi comandi:

  1. Dalla riga di comando, conferma che il processo Envoy sia in esecuzione:

    ps aux | grep envoy

  2. Ispeziona la configurazione di runtime di Envoy per verificare che Cloud Service Mesh abbia configurato le risorse dinamiche. Per visualizzare il file di configurazione, esegui questo comando:

    curl http://localhost:15000/config_dump

  3. Assicurati che l'intercettazione del traffico per il proxy sidecar sia configurata correttamente. Per la configurazione del reindirizzamento con iptables, esegui il comando iptables, quindi grep l'output per assicurarti che le regole siano presenti:

    sudo iptables -t nat -S | grep ISTIO

    Di seguito è riportato un esempio dell'output per iptables che intercetta l'indirizzo IP virtuale (VIP) 10.0.0.1/32 e lo inoltra a un proxy Envoy in esecuzione sulla porta 15001 come UID 1006:

    -N ISTIO_IN_REDIRECT
-N ISTIO_OUTPUT
-N ISTIO_REDIRECT
-A OUTPUT -p tcp -j ISTIO_OUTPUT
-A ISTIO_IN_REDIRECT -p tcp -j REDIRECT --to-ports 15001
-A ISTIO_OUTPUT -m owner --uid-owner 1006 -j RETURN
-A ISTIO_OUTPUT -d 127.0.0.1/32 -j RETURN
-A ISTIO_OUTPUT -d 10.0.0.1/32 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -j RETURN

Se l'istanza VM viene creata tramite la console Google Cloud, alcuni moduli relativi a IPv6 non vengono installati e disponibili prima di un riavvio. Questo causa un errore di iptables a causa di dipendenze mancanti. In questo caso, riavvia la VM ed esegui nuovamente il processo di configurazione per risolvere il problema. Non è previsto che questo problema si verifichi in una VM di Compute Engine che hai creato utilizzando Google Cloud CLI.

Il servizio non è più raggiungibile quando viene configurato il logging degli accessi a Envoy

Se hai utilizzato TRAFFICDIRECTOR_ACCESS_LOG_PATH per configurare un log di accesso a Envoy come descritto in Configurare gli attributi di bootstrap di Envoy per Cloud Service Mesh, assicurati che l'utente del sistema che esegue il proxy Envoy disponga delle autorizzazioni per scrivere nella posizione del log degli accessi specificata.

Se non fornisci le autorizzazioni necessarie, i listener non vengono programmati sul proxy e possono essere rilevati controllando il seguente messaggio di errore nel log del proxy Envoy:

gRPC config for type.googleapis.com/envoy.api.v2.Listener rejected:
Error adding/updating listener(s) TRAFFICDIRECTOR_INTERCEPTION_PORT:
unable to open file '/var/log/envoy.log': Permission denied

Per risolvere il problema, modifica le autorizzazioni del file scelto per consentire all'utente Envoy di scrivere il log di accesso.

I messaggi di errore nei log di Envoy indicano un problema di configurazione

Questa sezione riguarda i deployment che utilizzano le API di bilanciamento del carico.

In caso di problemi con la configurazione di Cloud Service Mesh, nei log di Envoy potrebbe essere visualizzato uno dei seguenti messaggi di errore:

  • warning envoy config    StreamAggregatedResources gRPC config stream closed:
5, Cloud Service Mesh configuration was not found for network "VPC_NAME" in
project "PROJECT_NUMBER".
  • warning envoy upstream  StreamLoadStats gRPC config stream closed:
5, Cloud Service Mesh configuration was not found for network "VPC_NAME" in
project "PROJECT_NUMBER".
  • warning envoy config    StreamAggregatedResources gRPC config stream closed:
5, Requested entity was not found.
  • warning envoy upstream  StreamLoadStats gRPC config stream closed:
5, Requested entity was not found.
  • Cloud Service Mesh configuration was not found.

L'ultimo messaggio di errore (Traffic Director configuration was not found) indica generalmente che Envoy richiede la configurazione a Cloud Service Mesh, ma non è stata trovata alcuna configurazione corrispondente. Quando Envoy si connette a Cloud Service Mesh, visualizza un nome di rete VPC, ad esempio my-network. Cloud Service Mesh cerca quindi le regole di forwarding con lo schema di bilanciamento del carico INTERNAL_SELF_MANAGED e che fanno riferimento allo stesso nome di rete VPC.

Per correggere questo errore:

  1. Assicurati che nella rete sia presente una regola di forwarding con lo schema di bilanciamento del carico INTERNAL_SELF_MANAGED. Prendi nota del nome della rete VPC della regola di forwarding.

  2. Se utilizzi Cloud Service Mesh con deployment automatici di Envoy su Compute Engine, assicurati che il valore fornito nel flag --service-proxy:network corrisponda al nome della rete VPC della regola di forwarding.

  3. Se utilizzi Cloud Service Mesh con deployment manuali di Envoy su Compute Engine, verifica quanto segue nel file di bootstrap di Envoy:

    1. Assicurati che il valore della variabile TRAFFICDIRECTOR_NETWORK_NAME corrisponda al nome della rete VPC della regola di forwarding.
    2. Assicurati che il numero di progetto sia impostato nella variabile TRAFFICDIRECTOR_GCP_PROJECT_NUMBER.

  4. Se stai eseguendo il deployment su GKE e utilizzi l'inserimento automatico, assicurati che il numero di progetto e il nome della rete VPC siano configurati correttamente, in base alle indicazioni riportate in Configurazione di Cloud Service Mesh per i pod GKE con inserimento Envoy automatico.

Risoluzione dei problemi relativi a Compute Engine

Questa sezione fornisce istruzioni per la risoluzione dei problemi relativi ai deployment di Envoy per Compute Engine.

I processi di bootstrap di Envoy e delle VM e le altre operazioni di gestione del ciclo di vita possono avere esito negativo per molti motivi, tra cui problemi di connettività temporanei, repository inaccessibili, bug negli script di bootstrap e negli agenti su VM e azioni utente impreviste.

Canali di comunicazione per la risoluzione dei problemi

Google Cloud fornisce canali di comunicazione che puoi utilizzare per aiutarti a comprendere il processo di bootstrap e lo stato attuale dei componenti che risiedono nelle tue VM.

Logging dell'output della porta seriale virtuale

Il sistema operativo di una VM, il BIOS e altre entità a livello di sistema in genere scrivono l'output sulle porte seriali. Questo output è utile per risolvere i problemi relativi ad arresti anomali del sistema, avvii non riusciti, problemi di avvio e di arresto.

Gli agenti di bootstrap di Compute Engine registrano tutte le azioni eseguite sulla porta seriale 1. Sono inclusi gli eventi di sistema, a partire dall'installazione di base dei pacchetti, tramite il recupero dei dati dal server di metadati di un'istanza, la configurazione iptables e lo stato dell'installazione di Envoy.

Gli agenti su VM registrano lo stato di integrità del processo Envoy, i servizi Cloud Service Mesh appena rilevati e qualsiasi altra informazione che potrebbe essere utile quando si esaminano i problemi relativi alle VM.

Logging di Cloud Monitoring

I dati esposti nell'output della porta seriale vengono registrati anche in Monitoring, che utilizza la libreria Golang ed esporta i log in un log separato per ridurre il rumore. Poiché questo è un log a livello di istanza, potresti trovare i log del proxy di servizio nella stessa pagina di altri log delle istanze.

Attributi guest VM

Gli attributi guest sono un tipo specifico di metadati personalizzati su cui le applicazioni possono scrivere durante l'esecuzione sull'istanza. Qualsiasi applicazione o utente sulle tue istanze può leggere e scrivere dati in questi valori dei metadati degli attributi guest.

Gli script di bootstrap di Envoy di Compute Engine e gli agenti su VM espongono gli attributi con informazioni sul processo di bootstrap e sullo stato attuale di Envoy. Tutti gli attributi guest sono esposti nello spazio dei nomi gce-service-proxy:

gcloud compute instances get-guest-attributes INSTANCE_NAME  \
    --query-path=gce-service-proxy/ \
    --zone=ZONE

In caso di problemi, ti consigliamo di controllare il valore degli attributi ospite bootstrap-status e bootstrap-last-failure. Qualsiasi valore bootstrap-status diverso da FINISHED indica che l'ambiente Envoy non è ancora configurato. Il valore di bookstrap-last-failure potrebbe indicare il problema.

Impossibile raggiungere il servizio Cloud Service Mesh da una VM creata utilizzando un modello di istanza abilitato per il servizio proxy

Per risolvere il problema:

  1. L'installazione dei componenti del proxy di servizio sulla VM potrebbe non essere stata completata o non essere riuscita. Usa il seguente comando per determinare se tutti i componenti sono installati correttamente:

    gcloud compute instances get-guest-attributes INSTANCE_NAME \
    --query-path=gce-service-proxy/ \
    --zone=ZONE

    L'attributo ospite bootstrap-status è impostato su uno dei seguenti valori:

    • [none] indica che l'installazione non è ancora iniziata. La VM potrebbe essere ancora in fase di avvio. Ricontrolla lo stato tra qualche minuto.
    • IN PROGRESS indica che l'installazione e la configurazione dei componenti proxy di servizio non sono ancora state completate. Ripeti il controllo dello stato per aggiornamenti sul processo.
    • FAILED indica che l'installazione o la configurazione di un componente non è riuscita. Controlla il messaggio di errore eseguendo una query sull'attributo gce-service-proxy/bootstrap-last-failure1.
    • FINISHED indica che i processi di installazione e configurazione sono stati completati senza errori. Utilizza le seguenti istruzioni per verificare che l'intercettazione del traffico e il proxy Envoy siano configurati correttamente.

  2. L'intercettazione del traffico sulla VM non è configurata correttamente per i servizi basati su Cloud Service Mesh. Accedi alla VM e controlla la configurazione di iptables:

    gcloud compute ssh INSTANCE_NAME \
    --zone=ZONE \
    sudo iptables -L -t nat

    Esamina la catena SERVICE_PROXY_SERVICE_CIDRS per SERVICE_PROXY_REDIRECT voci come queste:

    Chain SERVICE_PROXY_SERVICE_CIDRS (1 references)
target                   prot opt source         destination ...
SERVICE_PROXY_REDIRECT   all  --  anywhere       10.7.240.0/20

    Per ogni servizio, deve essere presente un indirizzo IP o un CIDR corrispondente nella colonna destination. Se non esiste una voce per l'indirizzo IP virtuale (VIP), si è verificato un problema con il completamento della configurazione proxy Envoy da Cloud Service Mesh, oppure l'agente su VM non è riuscito.

  3. I proxy Envoy non hanno ancora ricevuto la configurazione da Cloud Service Mesh. Accedi alla VM per verificare la configurazione del proxy Envoy:

    gcloud compute ssh INSTANCE_NAME \
    --zone=ZONE \
    sudo curl localhost:15000/config_dump

    Esamina la configurazione del listener ricevuta da Cloud Service Mesh. Ad esempio:

    "dynamic_active_listeners": [
  ...
  "filter_chains": [{
    "filter_chain_match": {
      "prefix_ranges": [{
        "address_prefix": "10.7.240.20",
        "prefix_len": 32
      }],
      "destination_port": 80
    },
  ...
    "route_config_name": "URL_MAP/PROJECT_NUMBER.td-routing-rule-1"
  ...
]

    address_prefix è l'indirizzo IP virtuale (VIP) di un servizio Cloud Service Mesh. Indirizza alla mappa degli URL chiamata td-routing-rule-1. Verifica se il servizio a cui vuoi connetterti è già incluso nella configurazione del listener.

  4. L'agente su VM non è in esecuzione. L'agente su VM configura automaticamente l'intercettazione del traffico quando vengono creati nuovi servizi Cloud Service Mesh. Se l'agente non è in esecuzione, tutto il traffico verso i nuovi servizi passa direttamente ai VIP, ignorando il proxy Envoy e si verifica un timeout.

    1. Verifica lo stato dell'agente su VM eseguendo questo comando:

      gcloud compute instances get-guest-attributes INSTANCE_NAME \
   --query-path=gce-service-proxy/ \
   --zone=ZONE

    2. Esamina gli attributi dell'agente su VM. Il valore dell'attributo agent-heartbeat riporta l'ora in cui l'agente ha eseguito l'ultima azione o controllo. Se il valore risale a più di cinque minuti fa, l'agente è bloccato e devi ricreare la VM utilizzando il seguente comando:

      gcloud compute instance-groups managed recreate-instance

    3. L'attributo agent-last-failure mostra l'ultimo errore che si è verificato nell'agente. Potrebbe trattarsi di un problema temporaneo che si risolve al successivo controllo dell'agente, ad esempio se l'errore è Cannot reach the Cloud Service Mesh API server, oppure potrebbe essere un errore permanente. Attendi qualche minuto e ricontrolla l'errore.

L'intercettazione del traffico in entrata è configurata sulla porta del carico di lavoro, ma non puoi connetterti alla porta dall'esterno della VM

Per risolvere il problema:

  1. L'installazione dei componenti del proxy di servizio sulla VM potrebbe non essere stata completata o non essere riuscita. Usa il seguente comando per determinare se tutti i componenti sono installati correttamente:

    gcloud compute instances get-guest-attributes INSTANCE_NAME \
    --query-path=gce-service-proxy/ \
    --zone=ZONE

    L'attributo ospite bootstrap-status è impostato su uno dei seguenti valori:

    • [none] indica che l'installazione non è ancora iniziata. La VM potrebbe essere ancora in fase di avvio. Ricontrolla lo stato tra qualche minuto.
    • IN PROGRESS indica che l'installazione e la configurazione dei componenti proxy di servizio non sono ancora state completate. Ripeti il controllo dello stato per aggiornamenti sul processo.
    • FAILED indica che l'installazione o la configurazione di un componente non è riuscita. Controlla il messaggio di errore eseguendo una query sull'attributo gce-service-proxy/bootstrap-last-failure1.
    • FINISHED indica che i processi di installazione e configurazione sono stati completati senza errori. Utilizza le seguenti istruzioni per verificare che l'intercettazione del traffico e il proxy Envoy siano configurati correttamente.

  2. L'intercettazione del traffico sulla VM non è configurata correttamente per il traffico in entrata. Accedi alla VM e controlla la configurazione di iptables:

    gcloud compute ssh INSTANCE_NAME \
    --zone=ZONE \
    sudo iptables -L -t nat

    Esamina la catena SERVICE_PROXY_INBOUND per SERVICE_PROXY_IN_REDIRECT voci come queste:

    Chain SERVICE_PROXY_INBOUND (1 references)
target                      prot opt source       destination ...
SERVICE_PROXY_IN_REDIRECT   tcp  --  anywhere     anywhere  tcp dpt:mysql

    Per ogni porta definita in service-proxy:serving-ports, deve essere presente una porta corrispondente nella colonna destination. Se non viene inserita la porta, tutto il traffico in entrata viene indirizzato direttamente a questa porta, bypassando il proxy Envoy.

    Verifica che non esistano altre regole che rilasciano il traffico su questa porta o su tutte le porte tranne una specifica.

  3. I proxy Envoy non hanno ancora ricevuto la configurazione per la porta in entrata da Cloud Service Mesh. Accedi alla VM per verificare la configurazione del proxy Envoy:

    gcloud compute ssh INSTANCE_NAME \
    --zone=ZONE \
    sudo curl localhost:15000/config_dump

    Cerca la configurazione del listener inbound ricevuta da Cloud Service Mesh:

    "dynamic_active_listeners": [
  ...
  "filter_chains": [{
    "filter_chain_match": {
      "prefix_ranges": [{
        "address_prefix": "10.0.0.1",
        "prefix_len": 32
      }],
      "destination_port": 80
    },
  ...
    "route_config_name": "inbound|default_inbound_config-80"
  ...
]

    route_config_name, che inizia con inbound, indica un servizio speciale creato per scopi di intercettazione del traffico in entrata. Verifica se la porta a cui vuoi connetterti è già inclusa nella configurazione del listener in destination_port.

Problemi quando le connessioni utilizzano protocolli server-first

Alcune applicazioni, come MySQL, utilizzano protocolli a cui il server invia il primo pacchetto. Ciò significa che, alla connessione iniziale, il server invia i primi byte. Questi protocolli e applicazioni non sono supportati da Cloud Service Mesh.

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