Risoluzione dei problemi di deployment di Envoy

Questa guida fornisce informazioni per aiutarti a risolvere i problemi di configurazione 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 esaminare i problemi relativi a Cloud Service Mesh, consultare Informazioni sullo stato del client di 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 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 dai dettagli dell'istanza VM Pagina di logging 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 come la 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 controllare 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 l'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 di log di Envoy

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

Puoi utilizzare SSH per connetterti all'istanza VM e ottenere il file di log. Il percorso è che potrebbero essere le seguenti.

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

I proxy non si connettono a Cloud Service Mesh

Se i proxy non si connettono a Cloud Service Mesh, segui questi passaggi:

  • Controlla i log del proxy Envoy per verificare che non ci siano errori di connessione a trafficdirector.googleapis.com.

  • Se configuri netfilter (utilizzando iptables) per reindirizzare tutto il traffico a il proxy Envoy, accertati che l'utente (UID) con cui esegui il proxy è escluso dal reindirizzamento. In caso contrario, il traffico continua a tornare al proxy.

  • Assicurati di aver abilitato Cloud Service Mesh API per il progetto. Nella sezione API e per il tuo progetto, cerca per l'API Cloud Service Mesh.

  • Verifica che l'ambito di accesso API della VM sia impostato per consentire l'accesso completo 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 le informazioni, vedi Abilitare l'account di servizio per accedere all'API Traffic Director.

  • Conferma di poter accedere a trafficdirector.googleapis.com:443 dal VM. Se si verificano problemi con questo accesso, i possibili motivi potrebbero essere la presenza di 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.

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

Il servizio configurato con Cloud Service Mesh non è raggiungibile

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

Se utilizzi Envoy come proxy sidecar, puoi confermarlo eseguendo il comando seguenti comandi:

  1. Dalla riga di comando, verifica 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 di risorse dinamiche configurate. Per visualizzare la 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 e 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 la indirizzo IP virtuale (VIP) 10.0.0.1/32 e inoltrarlo 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 mediante la console Google Cloud, alcuni aggiornamenti e non sono installati e disponibili prima di un riavvio. Questo fa sì che iptables a causa di dipendenze mancanti. In questo caso, riavvia la VM ed eseguila di nuovo il processo di configurazione, che dovrebbe risolvere il problema. Si tratta di una VM creato utilizzando Google Cloud CLI non dovrebbe avere questo problema.

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

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

Se non fornisci le autorizzazioni necessarie, i listener non vengono sono programmati sul proxy e possono essere rilevati controllando la presenza dell'errore seguente 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 l'accesso affinché l'utente Envoy possa scrivere in scrittura.

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.

Se hai difficoltà 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 in genere che Envoy richiede la configurazione Cloud Service Mesh, ma non è stata trovata nessuna configurazione corrispondente. Quando Envoy si connette a Cloud Service Mesh, presenta un nome di rete VPC (ad es. my-network). Cloud Service Mesh cerca quindi le regole di forwarding che hanno lo schema di bilanciamento del carico INTERNAL_SELF_MANAGED e fanno riferimento con lo stesso nome di rete VPC.

Per correggere questo errore:

  1. Assicurati che nella tua rete sia presente una regola di forwarding con schema di bilanciamento del carico INTERNAL_SELF_MANAGED. Tieni presente che la regola di forwarding Nome della rete VPC.

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

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

    1. Assicurati che il valore dell'attributo La variabile TRAFFICDIRECTOR_NETWORK_NAME corrisponde alla nome della rete VPC della regola di forwarding.
    2. Assicurati che il numero del progetto sia impostato nel Variabile TRAFFICDIRECTOR_GCP_PROJECT_NUMBER.

  4. Se esegui il deployment su GKE e utilizzi l'iniettore automatico, assicura che il numero di progetto e il nome della rete VPC configurato correttamente, in base alle istruzioni Configurazione di Cloud Service Mesh per pod GKE con inserimento Envoy automatico.

Risoluzione dei problemi per Compute Engine

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

Processi di bootstrap delle VM e Envoy e ulteriore gestione del ciclo di vita operazioni possono non riuscire per molti motivi, tra cui problemi di connettività temporanei repository non funzionanti, bug negli script di bootstrap e negli agenti on-VM azioni impreviste dell'utente.

Canali di comunicazione per la risoluzione dei problemi

Google Cloud fornisce canali di comunicazione che puoi usare per aiutarti il processo di bootstrap e lo stato attuale dei componenti che risiedono sulle tue VM.

Logging degli output delle porte seriali virtuali

In genere, il sistema operativo, il BIOS e altre entità a livello di sistema di una VM l'output in scrittura sulle porte seriali. Questo output è utile per la risoluzione dei problemi arresti anomali del sistema, avvii non riusciti, problemi di avvio e chiusura.

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

Gli agenti on-VM registrano lo stato di integrità del processo Envoy, appena rilevato sui servizi Cloud Service Mesh e qualsiasi altra informazione che potrebbe è utile quando analizzi i problemi con le 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 log è a livello di istanza, potresti trovare i log del proxy nella stessa pagina degli altri log dell'istanza.

Attributi guest VM

Attributi ospite sono un tipo specifico di metadati personalizzati su cui le applicazioni possono scrivere durante l'esecuzione sulla tua istanza. Qualsiasi applicazione o utente delle istanze può leggono e scrivono dati in questi valori di metadati degli attributi guest.

Gli script di bootstrap e gli agenti on-VM di Compute Engine Envoy 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

Se riscontri problemi, ti consigliamo di controllare il valore dell'ospite bootstrap-status e bootstrap-last-failure. Qualsiasi Il valore bootstrap-status diverso da FINISHED indica che Envoy non è ancora stato 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 proxy di servizio

Per correggere questo problema, procedi nel seguente modo:

  1. L'installazione dei componenti del proxy di servizio sulla VM potrebbe non essere è stato completato o potrebbe non essere riuscito. Utilizza 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 è ancora in fase di avvio. Controlla di nuovo lo stato tra qualche minuto.
    • IN PROGRESS indica che l'installazione e la configurazione i componenti proxy di servizio non sono ancora completati. Ripeti il controllo dello stato. per aggiornamenti sulla procedura.
    • FAILED indica che l'installazione o la configurazione di un componente non riuscito. Controlla il messaggio di errore eseguendo una query sul Attributo gce-service-proxy/bootstrap-last-failure1.
    • FINISHED indica che i processi di installazione e configurazione completato senza errori. Segui queste istruzioni per effettuare la verifica che l'intercettazione del traffico e il proxy Envoy siano configurati correttamente.

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

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

    Esamina la catena SERVICE_PROXY_SERVICE_CIDRS per SERVICE_PROXY_REDIRECT come le seguenti:

    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 esserci un indirizzo IP o CIDR corrispondente nella Colonna destination. Se non è presente una voce per l'indirizzo IP virtuale (VIP), c'è un problema con il completamento della configurazione proxy Envoy da Errore del mesh di servizi Cloud o dell'agente on-VM.

  3. I proxy Envoy non hanno ricevuto la loro 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. Per 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 Cloud Service Mesh completamente gestito di Google Cloud. Indirizza alla mappa URL denominata td-routing-rule-1. Controlla se il servizio a cui vuoi connetterti è già incluso nel listener configurazione.

  4. L'agente on-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 va direttamente VIP, bypass del proxy Envoy e timeout.

    1. Verifica lo stato dell'agente on-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 del parametro L'attributo agent-heartbeat indica la data e l'ora in cui l'agente ha eseguito l'ultima volta un'azione o un controllo. Se il valore risale a più di cinque minuti prima della data corrente, l'agente viene è bloccato e dovresti ricreare la VM utilizzando questo comando:

      gcloud compute instance-groups managed recreate-instance

    3. L'attributo agent-last-failure mostra l'ultimo errore che si è verificato in l'agente. Potrebbe trattarsi di un problema temporaneo che si risolve entro la prossima volta l'agente controlla, ad esempio se l'errore è Cannot reach the Cloud Service Mesh API server, oppure potrebbe trattarsi di un errore permanente. Attendi qualche minuto e controlla di nuovo 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 correggere questo problema, procedi nel seguente modo:

  1. L'installazione dei componenti del proxy di servizio sulla VM potrebbe non essere è stato completato o potrebbe non essere riuscito. Utilizza 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 è ancora in fase di avvio. Controlla di nuovo lo stato tra qualche minuto.
    • IN PROGRESS indica che l'installazione e la configurazione i componenti proxy di servizio non sono ancora completati. Ripeti il controllo dello stato. per aggiornamenti sulla procedura.
    • FAILED indica che l'installazione o la configurazione di un componente non riuscito. Controlla il messaggio di errore eseguendo una query sul Attributo gce-service-proxy/bootstrap-last-failure1.
    • FINISHED indica che i processi di installazione e configurazione completato senza errori. Segui queste istruzioni per effettuare la verifica che l'intercettazione del traffico e il proxy Envoy siano configurati correttamente.

  2. L'intercettazione del traffico sulla VM non è configurata correttamente per e 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 come le seguenti:

    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, è necessario essere una porta corrispondente nella colonna destination. Se non è presente una voce per porta, tutto il traffico in entrata va direttamente a questa porta, bypassando la porta proxy.

    Verifica che non esistano altre regole che rimandano il traffico a questa porta o a tutto diverse porte, ad eccezione di una porta specifica.

  3. I proxy Envoy non hanno ricevuto la loro configurazione per la porta in entrata da Cloud Service Mesh. Accedi alla VM per controllare il proxy Envoy configurazione:

    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'offerta speciale creato ai fini dell'intercettazione del traffico in entrata. Controlla se la porta a cui vuoi connetterti è già inclusa nel listener configurazione in destination_port.

Problemi quando le connessioni utilizzano protocolli server-first

Alcune applicazioni, come MySQL, utilizzano protocolli in cui il server invia il primo un pacchetto. Ciò significa che, durante la connessione iniziale, il server invia il primo byte. Questi protocolli e applicazioni non sono supportati da Cloud Service Mesh.

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