Risolvere i problemi dei deployment Envoy
Questa guida fornisce informazioni per aiutarti a risolvere i problemi di configurazione di Traffic Director. Per informazioni su come utilizzare l'API Client Status Discovery Service (CSDS) per analizzare i problemi relativi a Traffic Director, consulta Informazioni sullo stato del client Traffic Director.
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).
Determina la versione con il deployment di Envoy automatico
Per verificare o controllare la versione di Envoy con deployment automatico, puoi:
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 ZONE --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", ... }
Determinare la versione con il deployment manuale di Envoy
Per verificare o controllare la versione di Envoy con il deployment manuale, puoi:
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.
In Google Kubernetes Engine (GKE), i proxy Envoy vengono eseguiti con i pod dell'applicazione.
Vedrai eventuali errori nei log dei pod di 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 nel cluster, puoi visualizzare gli errori utilizzando un comando come il seguente:
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 gli Envoy in esecuzione in tutti i cluster e 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 esportarla in Logging, gli errori saranno visibili solo se utilizzi SSH per connetterti all'istanza e ottenere questo file.
Se utilizzi il deployment automatico di Envoy, puoi utilizzare SSH per connetterti all'istanza e ottenere il file di log. È probabile che il percorso sia lo stesso indicato in precedenza.
I proxy non si connettono a Traffic Director
Se i tuoi proxy non si connettono a Traffic Director:
Verifica la presenza di errori di connessione a
trafficdirector.googleapis.com
nei log del proxy Envoy.Se configuri
netfilter
(utilizzandoiptables
) 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 Traffic Director per il progetto. Nella sezione API e servizi del tuo progetto, cerca gli errori relativi all'API Traffic Director.
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 atrafficdirector.googleapis.com
sulla porta TCP443
o problemi di risoluzione DNS per il nome hosttrafficdirector.googleapis.com
.Se utilizzi Envoy per il proxy sidecar, verifica che la versione di Envoy sia 1.9.1 o successiva.
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:
Dalla riga di comando, conferma che il processo Envoy sia in esecuzione:
ps aux | grep envoy
Ispeziona la configurazione di runtime di Envoy per verificare che Traffic Director abbia configurato le risorse dinamiche. Per visualizzare il file di configurazione, esegui questo comando:
curl http://localhost:15000/config_dump
Assicurati che l'intercettazione del traffico per il proxy sidecar sia configurata correttamente. Per la configurazione del reindirizzamento con
iptables
, esegui il comandoiptables
, quindigrep
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 porta15001
come UID1006
:-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 Traffic Director,
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.
Le applicazioni non riescono a connettersi a servizi non configurati in Traffic Director
Assicurati di configurare l'intercettazione del traffico solo per gli indirizzi IP dei servizi configurati in Traffic Director. Se tutto il traffico viene intercettato, il proxy sidecar ignora automaticamente le connessioni ai servizi non configurati in Traffic Director.
Il traffico è in loop all'interno di un nodo o un nodo si arresta in modo anomalo
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 sidecar viene reindirizzato al proxy per un tempo indeterminato. Di conseguenza, il processo proxy sidecar potrebbe arrestarsi in modo anomalo. Nella configurazione di riferimento, le regole netfilter
non intercettano il traffico proveniente dall'utente proxy.
I messaggi di errore nei log di Envoy indicano un problema di configurazione
In caso di problemi con la configurazione di Traffic Director, è possibile che venga visualizzato uno dei seguenti messaggi di errore nei log di 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 a Traffic Director, ma non è stata trovata una configurazione corrispondente. Quando Envoy si connette a Traffic Director, presenta un nome di rete VPC (ad esempio, my-network
). Traffic Director quindi cerca 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:
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.Se utilizzi Traffic Director 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.Se utilizzi Traffic Director con deployment manuali di Envoy su Compute Engine, verifica se nel file di bootstrap di Envoy è presente quanto segue:
- Assicurati che il valore della variabile
TRAFFICDIRECTOR_NETWORK_NAME
corrisponda al nome della rete VPC della regola di forwarding. - Assicurati che il numero di progetto sia impostato nella variabile
TRAFFICDIRECTOR_GCP_PROJECT_NUMBER
.
- Assicurati che il valore della variabile
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 Traffic Director per i pod GKE con inserimento di Envoy automatico.
Risoluzione dei problemi di deployment automatici per Compute Engine
Questa sezione fornisce istruzioni per la risoluzione dei problemi relativi ai deployment automatici 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 Traffic Director 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 Traffic Director da una VM creata utilizzando un modello di istanza abilitato per il servizio proxy
Per risolvere il problema:
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'attributogce-service-proxy/bootstrap-last-failure
.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.
L'intercettazione del traffico sulla VM non è configurata correttamente per i servizi basati su Traffic Director. 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
perSERVICE_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 alcuna voce per l'indirizzo IP virtuale (VIP), si è verificato un problema con il completamento della configurazione proxy Envoy da Traffic Director oppure l'agente su VM non è riuscito.I proxy Envoy non hanno ancora ricevuto la propria configurazione da Traffic Director. 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 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. Indirizza alla mappa degli URL chiamatatd-routing-rule-1
. Verifica se il servizio a cui vuoi connetterti è già incluso nella configurazione del listener.L'agente su 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 i nuovi servizi passa direttamente ai VIP, ignorando il proxy Envoy e si verifica un timeout.
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
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
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 Traffic Director 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:
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'attributogce-service-proxy/bootstrap-last-failure
.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.
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
perSERVICE_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 colonnadestination
. 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.
I proxy Envoy non hanno ancora ricevuto la configurazione per la porta in entrata da Traffic Director. 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 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
, che inizia coninbound
, 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 indestination_port
.
Risoluzione dei problemi di deployment automatici per i pod GKE
Questa sezione fornisce istruzioni per la risoluzione dei problemi relativi ai deployment automatici di Envoy per i pod GKE.
I pod non si avviano dopo che hai abilitato l'inserimento automatico di Envoy
In alcuni casi, i pod dell'applicazione potrebbero non essere avviati correttamente. Questo potrebbe verificarsi quando utilizzi un cluster GKE privato con regole firewall restrittive.
Se vuoi utilizzare Traffic Director con un cluster GKE privato, devi creare una regola firewall aggiuntiva per il webhook dell'iniettore sidecar. Per creare una regola firewall che consenta al piano di controllo GKE di raggiungere i pod sulla porta TCP 9443
, consulta
Aggiungere regole firewall per casi d'uso specifici.
Potresti osservare 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)
Quando segui la guida alla configurazione, potresti riscontrare questo problema per la prima volta durante il passaggio 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 PRONTO. Puoi trovare l'errore anche descrivendo replicaset
associato al deployment inviando il comando kubectl describe rs -l run=client
.
Connessione rifiutata dopo la verifica della configurazione
Quando configuri Traffic Director con inserimento Envoy automatico, potresti ricevere un errore di connessione rifiutata quando provi a verificare la configurazione. La causa potrebbe essere una delle seguenti:
- Il valore di
discoveryAddress
nel filespecs/01-configmap.yaml
non è corretto. Il valore deve esseretrafficdirector.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
è errato nel pod. - L'iniettore collaterale Istio è in esecuzione anziché l'iniettore collaterale Traffic Director.
Puoi vedere un esempio del file specs/01-configmap.yaml
in
Configurare l'iniettore collaterale.
Se il file specs/01-configmap.yaml
non contiene valori corretti, Envoy non riesce a 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'inserimento automatico.
Assicurati di controllare il valore di discoveryAddress
nel
file specs/01-configmap.yaml
e nel pod. Nel pod, l'iniettore collaterale
imposta il valore. Per verificare 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'inserimento manuale di Envoy e i pod GKE
Se ricevi un messaggio che indica che la connessione è stata rifiutata, consulta i log occupati per sapere se l'API Traffic Director è abilitata o se le autorizzazioni sono errate nei log Envoy.
Timeout della connessione con inserimento Envoy manuale e pod GKE
Se ricevi un messaggio di timeout della connessione, è molto probabile che il problema sia la configurazione non corretta della mappa URL, delle regole di forwarding o del servizio di backend nel deployment. Controlla le risorse per verificare che siano configurate correttamente.
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 Traffic Director.
Risolvi i problemi relativi all'integrità del mesh di servizi
Questa guida fornisce informazioni per aiutarti a risolvere i problemi di configurazione di Traffic Director.
Comportamento di Traffic Director quando la maggior parte degli endpoint non è 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. 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
Traffic Director utilizza le informazioni nella risorsa HealthCheck
associata a un servizio di backend per valutare l'integrità dei backend.
Traffic Director 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 Traffic Director - Assicurati che il logging sia abilitato per la risorsa
HealthCheck
. - Se i controlli di integrità hanno iniziato a non funzionare di recente, controlla Cloud Audit Logs 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 criteri di sicurezza ai backend.
La configurazione errata di EndpointPolicy
potrebbe comportare il rifiuto del traffico da parte del backend.
Per risolvere questo scenario, utilizza i log seguenti:
- Controlla la presenza di eventuali conflitti dei criteri degli endpoint segnalati da Traffic Director.
- Esamina Cloud Audit Logs per verificare se la configurazione utente
(nello specifico,
EndpointPolicy
,ServerTlsPolicy
oAuthorizationPolicy
) è cambiata di recente.
Passaggi successivi
- Per scoprire come funziona Traffic Director, consulta la panoramica di Traffic Director.
- Per risolvere i problemi di configurazione quando esegui il deployment di servizi gRPC senza proxy, consulta Risoluzione dei problemi di deployment che utilizzano gRPC senza proxy.
- Per ulteriore assistenza per l'utilizzo di Traffic Director, consulta Ricevere assistenza.