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

Risolvere i problemi dei deployment Envoy

Questa guida fornisce informazioni utili per risolvere i problemi di configurazione di Traffic Director. Per informazioni su come utilizzare l'API Client Status Discovery Service (CSDS) al fine di indagare i problemi con Traffic Director, consulta la pagina Comprendere lo stato del client Traffic Director.

Determinazione della versione di Envoy installata su una VM

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

Determina la versione con il deployment automatico di Envoy

Per verificare o verificare la versione di Envoy con deployment automatico, puoi effettuare quanto segue:

  • 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 dalla pagina dei dettagli dell'istanza VM Logging nella console Google Cloud con una query come questa:

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

    Ricevi 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"
}

  • Utilizza 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 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",
...
}

Determina la versione con il deployment manuale di Envoy

Per verificare o verificare la versione di Envoy con un deployment manuale, puoi procedere come segue:

  • Utilizza 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 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",
...
}

Località dei log Envoy

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

In Google Kubernetes Engine (GKE), i proxy Envoy vengono eseguiti con i pod dell'applicazione. Vedrai eventuali errori nei log del pod dell'applicazione filtrati dal container envoy.

  • Se nel cluster è abilitato il logging dei carichi di lavoro, puoi visualizzare gli errori in Cloud Logging. Di seguito è riportato un possibile filtro:

    resource.type="K8S_CONTAINER"
resource.labels.project_id="PROJECT_NAME"
resource.labels.location="CLUSTER_ZONE"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.namespace_name="WORKLOAD_NAMESPACE"
labels.k8s-pod/app="WORKLOAD_NAME"
resource.labels.container_name="envoy"

  • Se il logging dei carichi di lavoro non è abilitato sul cluster, puoi visualizzare gli errori utilizzando un comando come questo:

    kubectl logs $(kubectl get po -l app=WORKLOAD_NAME -o=jsonpath='{.items[0].metadata.name}') -c envoy --tail 50 #NOTE: This assumes the default namespace.

  • Puoi anche visualizzare i log per tutti i Envoy in esecuzione in tutti i cluster e per qualsiasi carico di lavoro utilizzando il seguente filtro:

    resource.type="K8S_CONTAINER"
resource.labels.container_name="envoy"

Con Compute Engine e il deployment manuale, definisci LOG_DIR prima di eseguire lo script run.sh nella guida alla configurazione.

  • Ad esempio:

    LOG_DIR='/var/log/envoy/'

  • Per impostazione predefinita, gli errori vengono visualizzati nel seguente log:

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

Se l'utente non ha eseguito alcuna configurazione aggiuntiva per esportarlo in Logging, gli errori sono visibili solo se utilizzi SSH per connetterti all'istanza e ottenere questo file.

Se usi il deployment automatico di Envoy, puoi utilizzare SSH per connetterti all'istanza per ottenere il file di log. È probabile che il percorso corrisponda al percorso menzionato in precedenza.

I proxy non si connettono a Traffic Director

Se i tuoi proxy non si connettono a Traffic Director, procedi nel seguente modo:

  • Controlla i log del proxy Envoy per verificare la presenza di eventuali errori di connessione a trafficdirector.googleapis.com.

  • Se configuri netfilter (utilizzando iptables) per reindirizzare tutto il traffico al proxy Envoy, assicurati che l'utente (UID) con cui esegui il proxy sia escluso dal reindirizzamento. In caso contrario, il traffico torna continuamente al proxy.

  • Assicurati di aver abilitato l'API Traffic Director per il progetto. Nella sezione API e servizi del progetto, cerca gli errori per l'API Traffic Director.

  • Conferma che l'ambito di accesso della VM sia impostato per consentire l'accesso completo alle API di 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 Consentire all'account di servizio di accedere all'API Traffic Director.

  • Verifica di poter accedere a trafficdirector.googleapis.com:443 dalla VM. In caso di problemi con questo accesso, i possibili motivi potrebbero essere un firewall che impedisce l'accesso a trafficdirector.googleapis.com sulla porta TCP 443 o i 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 la versione 1.9.1 o successive.

Il servizio configurato con Traffic Director non è raggiungibile

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

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

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

    ps aux | grep envoy

  2. Ispezionare la configurazione di runtime di Envoy per confermare che le risorse dinamiche siano state configurate da Traffic Director. Per vedere 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 di reindirizzamento con iptables, esegui il comando iptables e poi grep l'output per assicurarti che le regole siano lì:

    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 correlati a IPv6 non sono installati e disponibili prima di un riavvio. Di conseguenza, iptables non andrà a buon fine a causa delle dipendenze mancanti. In questo caso, riavvia la VM ed esegui di nuovo il processo di configurazione, che dovrebbe risolvere il problema. Una VM di Compute Engine creata utilizzando Google Cloud CLI non dovrebbe causare questo problema.

Il servizio smette di essere raggiungibile quando è configurato il logging degli accessi a Envoy

Se hai utilizzato TRAFFICDIRECTOR_ACCESS_LOG_PATH per configurare un log di accesso Envoy come descritto in Configurare gli attributi bootstrap di Envoy per Traffic Director, assicurati che l'utente del sistema che esegue il proxy Envoy abbia le autorizzazioni per scrivere nella località del log di accesso 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 selezionato affinché il log di accesso possa essere scritto dall'utente Envoy.

Le applicazioni non possono connettersi ai servizi non configurati in Traffic Director

Assicurati di impostare l'intercettazione del traffico solo per gli indirizzi IP dei servizi configurati in Traffic Director. Se tutto il traffico viene intercettato, il proxy sidecar elimina automaticamente le connessioni ai servizi non configurati in Traffic Director.

Il traffico è in loop all'interno di un nodo o si verifica un arresto anomalo di un nodo

Se netfilter (iptables) è configurato per intercettare tutto il traffico, assicurati che l'utente (UID) utilizzato per eseguire il proxy sidecar sia escluso dall'intercettazione del traffico. In caso contrario, il traffico inviato dal proxy collaterale viene riportato al proxy a tempo indeterminato. Di conseguenza, il processo del proxy sidecar potrebbe arrestarsi in modo anomalo. Nella configurazione di riferimento, le regole netfilter non intercettano il traffico dell'utente proxy.

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

Se hai difficoltà con la configurazione di Traffic Director, potresti visualizzare uno dei seguenti messaggi di errore nei log Envoy:

  • warning envoy config    StreamAggregatedResources gRPC config stream closed:
5, Traffic Director configuration was not found for network "VPC_NAME" in
project "PROJECT_NUMBER".
  • warning envoy upstream  StreamLoadStats gRPC config stream closed:
5, Traffic Director 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.
  • Traffic Director configuration was not found.

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

Per correggere questo errore, procedi nel seguente modo:

  1. Assicurati che nella tua 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 Traffic Director con i deployment automatici di Envoy su Compute Engine, assicurati che il valore fornito per il flag --service-proxy:network corrisponda al nome della rete VPC della regola di forwarding.

  3. Se utilizzi Traffic Director con i deployment manuali di Envoy su Compute Engine, controlla il file di bootstrap di Envoy per quanto segue:

    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 del progetto sia impostato nella variabile TRAFFICDIRECTOR_GCP_PROJECT_NUMBER.

  4. Se stai eseguendo il deployment su GKE e utilizzi l'iniettore automatico, assicurati che il numero di progetto e il nome della rete VPC siano configurati correttamente, secondo le istruzioni riportate in Gestione del traffico per i pod GKE con iniezione automatica di Envoy.

Risoluzione dei problemi relativi ai deployment automatici per Compute Engine

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

I processi di bootstrap e di VM e ulteriori operazioni di gestione del ciclo di vita possono non riuscire per molti motivi, tra cui problemi di connettività temporanea, repository non funzionanti, bug negli script di bootstrap e agenti 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 sulle tue VM.

Logging dell'output della porta seriale virtuale

Il sistema operativo, il BIOS e altre entità a livello di sistema di una VM generalmente scrivono l'output nelle porte seriali. Questo output è utile per la risoluzione dei 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 del pacchetto fino al recupero dei dati dal server di metadati di un'istanza, dalla configurazione di iptables e dallo stato di installazione di Envoy.

Gli agenti on-VM registrano lo stato di integrità di Envoy, identificano i servizi di Traffic Director appena rilevati e qualsiasi altra informazione che potrebbe essere utile quando analizzi i problemi delle VM.

Logging di Cloud Monitoring

I dati esposti nell'output della porta seriale vengono inoltre registrati 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 log di servizio proxy nella stessa pagina degli altri log di istanza.

Attributi ospite della VM

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

Gli script di bootstrap e gli agenti on-VM di Compute Engine espongono gli attributi con informazioni sul processo di bootstrap e sullo stato attuale di Envoy. Tutti gli attributi relativi agli invitati 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 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 Traffic Director da una VM creata utilizzando un modello di istanza abilitato per proxy di servizio

Per risolvere il problema, procedi nel seguente modo:

  1. L'installazione dei componenti proxy di servizio sulla VM potrebbe non essere stata completata o non essere riuscita. 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 essere ancora in fase di avvio. Controlla nuovamente lo stato tra qualche minuto.
    • IN PROGRESS indica che l'installazione e la configurazione dei componenti proxy di servizio non sono ancora complete. Ripeti il controllo di stato per verificare la presenza di aggiornamenti sulla procedura.
    • FAILED indica che l'installazione o la configurazione di un componente non sono andate a buon fine. 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 istruzioni seguenti 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 Traffic Director. Accedi alla VM e controlla la configurazione iptables:

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

    Esamina la catena SERVICE_PROXY_SERVICE_CIDRS per le voci SERVICE_PROXY_REDIRECT, ad esempio:

    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, dovrebbe essere presente un indirizzo IP o CIDR corrispondente nella colonna destination. Se non è presente una voce per l'indirizzo IP virtuale (VIP), si è verificato un problema con il completamento della configurazione del proxy Envoy da Traffic Director o l'agente on-VM non è riuscito.

  3. I proxy Envoy non hanno ancora ricevuto la configurazione da Traffic Director. Accedi alla VM per controllare la configurazione del proxy Envoy:

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

    Esaminare la configurazione del listener ricevuta da Traffic Director. 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 Traffic Director. Rimanda alla mappa URL chiamata td-routing-rule-1. Verifica se il servizio a cui vuoi connetterti è già incluso nella configurazione listener.

  4. L'agente VM non è in esecuzione. L'agente su VM configura automaticamente l'intercettazione del traffico quando vengono creati nuovi servizi Traffic Director. Se l'agente non è in esecuzione, tutto il traffico verso nuovi servizi viene indirizzato direttamente ai VIP, ignorando il proxy Envoy e scade.

    1. Verifica lo stato dell'agente on-VM eseguendo il comando seguente:

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

    2. Esamina gli attributi dell'agente VM. Il valore dell'attributo agent-heartbeat indica il tempo in cui l'agente ha eseguito l'ultima azione o un controllo. Se il valore risale a più di cinque minuti prima, 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 espone l'ultimo errore che si è verificato nell'agente. Potrebbe trattarsi di un problema temporaneo che viene risolto entro il momento in cui l'agente controlla, ad esempio, se l'errore è Cannot reach the Traffic Director API server, oppure potrebbe trattarsi di 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, procedi nel seguente modo:

  1. L'installazione dei componenti proxy di servizio sulla VM potrebbe non essere stata completata o non essere riuscita. 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 essere ancora in fase di avvio. Controlla nuovamente lo stato tra qualche minuto.
    • IN PROGRESS indica che l'installazione e la configurazione dei componenti proxy di servizio non sono ancora complete. Ripeti il controllo di stato per verificare la presenza di aggiornamenti sulla procedura.
    • FAILED indica che l'installazione o la configurazione di un componente non sono andate a buon fine. 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 istruzioni seguenti 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 iptables:

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

    Esamina la catena SERVICE_PROXY_INBOUND per le voci SERVICE_PROXY_IN_REDIRECT, ad esempio:

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

    Verifica che non ci siano altre regole che trascinano il traffico verso questa porta o in tutte le porte, ad eccezione di una porta specifica.

  3. I proxy Envoy non hanno ancora ricevuto la configurazione per la porta in entrata da Traffic Director. Accedi alla VM per controllare la configurazione del proxy Envoy:

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

    Cerca la configurazione del listener in entrata ricevuta da Traffic Director:

    "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, a partire da inbound, indica un servizio speciale creato per l'intercettazione del traffico in entrata. Verifica se la porta a cui vuoi connetterti è già inclusa nella configurazione del listener in destination_port.

Risoluzione dei problemi relativi ai deployment automatici per i pod GKE

Questa sezione fornisce istruzioni per la risoluzione dei problemi dei deployment automatici di Envoy per i pod GKE.

I pod non vengono avviati dopo l'abilitazione dell'inserimento automatico di Envoy

In alcuni casi, i pod dell'applicazione potrebbero non avviarsi correttamente. Questo può verificarsi quando utilizzi un cluster GKE privato con regole del firewall restrittive.

Se vuoi utilizzare Traffic Director con un cluster GKE privato, devi creare una regola firewall aggiuntiva per il webhook iniettore sidecar. Per creare una regola firewall che consenta al piano di controllo GKE di raggiungere i pod sulla porta TCP 9443, consulta la sezione Aggiunta di regole firewall per casi d'uso specifici.

Potresti riscontrare questo problema durante la creazione di un pod autonomo o quando un deployment prova a creare pod.

Quando crei un pod autonomo (ad esempio, utilizzando kubectl apply o kubectl run), la riga di comando kubectl potrebbe restituire un messaggio di errore simile al seguente:

Error from server (InternalError): Internal error occurred: failed calling webhook "sidecar-injector.istio.io": Post https://istio-sidecar-injector.istio-control.svc:443/inject?timeout=30s: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

Quando crei pod da un deployment, potresti riscontrare i seguenti sintomi:

  • kubectl get pods non mostra alcun pod associato al deployment.

  • kubectl get events --all-namespaces mostra un messaggio di errore simile al seguente:

    Warning  FailedCreate  15s   replicaset-controller  Error creating: Internal error occurred: failed calling webhook "sidecar-injector.istio.io": Post https://istio-sidecar-injector.istio-control.svc:443/inject?timeout=30s: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

Se segui la guida alla configurazione, potresti prima riscontrare questo problema durante la fase di deployment di un client di esempio e verifica dell'inserimento. Dopo aver eseguito kubectl create -f demo/client_sample.yaml, esegui kubectl get deploy busybox per visualizzare 0/1 pod READY. Puoi anche trovare l'errore descrivendo il replicaset associato al deployment eseguendo il comando kubectl describe rs -l run=client.

Connessione rifiutata dopo la verifica della configurazione

Quando configuri Traffic Director con l'iniezione automatica di Envoy, potresti ricevere un errore di connessione rifiutata quando tenti di verificare la configurazione. La causa potrebbe essere una delle seguenti:

  • Il valore di discoveryAddress nel file specs/01-configmap.yaml non è corretto. Il valore deve essere trafficdirector.googleapis.com:443.
  • Il valore della rete VPC nel file specs/01-configmap.yaml non è corretto.
  • Il valore del progetto Traffic Director nel file specs/01-configmap.yaml non è corretto.
  • Il valore di discoveryAddress non è corretto nel pod.
  • L'iniettore sidecar Istio è in esecuzione al posto dell'iniettore sidecar Traffic Director.

Puoi vedere un esempio del file specs/01-configmap.yaml in Configurazione dell'iniettore sidecar. Se il file specs/01-configmap.yaml non contiene valori corretti, Envoy non può ottenere la configurazione di correzione da Traffic Director. Per risolvere il problema, esamina il file specs/01-configmap.yaml e assicurati che i valori siano corretti, quindi ricrea l'iniettore automatico.

Assicurati di controllare il valore di discoveryAddress nel file specs/01-configmap.yaml e nel pod. Nel pod, l'iniettore sidecar imposta il valore. Per controllare il valore di discoveryAddress nel pod, esegui questo comando:

kubectl get po $BUSYBOX_POD -o yaml|grep -Po '\"discoveryAddress\":\"[^,]*\"'

Dovresti vedere un output simile al seguente:

"discoveryAddress":"trafficdirector.googleapis.com:443"

Connessione rifiutata con l'iniezione manuale di Envoy e i pod GKE

Se ricevi un messaggio relativo a una connessione rifiutata, consulta i log del serviziooccupato per informazioni sull'abilitazione dell'API Traffic Director o sulle autorizzazioni errate nei log Envoy.

Timeout della connessione con l'inserimento manuale di Envoy e i pod GKE

Se ricevi un messaggio di timeout della connessione, è molto probabile che la configurazione della mappa URL, delle regole di forwarding o del servizio di backend nel deployment sia errata. Controlla queste risorse per verificare che siano configurate correttamente.

Problemi quando le connessioni usano 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 Traffic Director.

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 non è in stato integro

Per una maggiore affidabilità, quando il 99% degli endpoint non è integro, Traffic Director configura il piano dati in modo da ignorare lo stato di integrità degli endpoint. Il piano dati bilancia invece 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 distribuzione non ottimale. Ad esempio, il traffico potrebbe fluire in una regione in cui sono ancora presenti backend integri, ma che è molto più lontano dal client, introducendo latenza. Per identificare e monitorare lo stato di integrità dei backend, prova a seguire questi passaggi:

  • Verifica lo stato di integrità del servizio di backend nella console Google Cloud.
    Vai ai servizi Traffic Director
  • Assicurati che il logging sia abilitato per la risorsa HealthCheck.
  • Se i controlli di integrità hanno iniziato a generare errori di recente, controlla gli audit log di Cloud per determinare se la configurazione di HealthCheck è stata modificata di recente.

I backend rifiutano inaspettatamente il traffico

Se hai configurato la sicurezza del servizio Traffic Director, stai utilizzando la risorsa EndpointPolicy per applicare i criteri di sicurezza ai backend. Una configurazione errata di EndpointPolicy potrebbe causare il rifiuto del traffico da parte del backend. Utilizza i seguenti log per risolvere il problema:

  • Controlla la presenza di eventuali conflitti di criteri endpoint segnalati da Traffic Director.
  • Controlla Cloud Audit Logs per verificare se la configurazione dell'utente (in particolare EndpointPolicy, ServerTlsPolicy o AuthorizationPolicy) è stata modificata di recente.

Passaggi successivi