Risoluzione dei problemi di gestione del traffico in Cloud Service Mesh

Questa sezione descrive i problemi più comuni di Cloud Service Mesh e spiega come risolverli. Se hai bisogno di ulteriore assistenza, consulta Richiedi assistenza.

Errori di connessione al server API nei log di istiod

Istiod non può contattare apiserver se visualizzi errori simili ai seguenti:

error k8s.io/client-go@v0.18.0/tools/cache/reflector.go:125: Failed to watch *crd.IstioSomeCustomResource`…dial tcp 10.43.240.1:443: connect: connection refused

Puoi utilizzare la stringa dell'espressione regolare /error.*cannot list resource/ per trovare questo errore nei log.

Questo errore è in genere temporaneo e, se hai raggiunto i log proxy utilizzando kubectl, il problema potrebbe essere già risolto. Questo errore è in genere causato da eventi che rendono temporaneamente non disponibile il server API, ad esempio quando un server API che non si trova in una configurazione ad alta affidabilità viene riavviato per un upgrade o una modifica di scalabilità automatica.

Il container istio-init si arresta in modo anomalo

Questo problema può verificarsi quando le regole iptables del pod non vengono applicate allo spazio dei nomi di rete del pod. Le cause possono essere:

  • Un'installazione incompleta di istio-cni
  • Autorizzazioni pod del workload insufficienti (autorizzazione CAP_NET_ADMIN mancante)

Se utilizzi il plug-in CNI Istio, verifica di aver seguito completamente le istruzioni. Verifica che il container istio-cni-node sia pronto e controlla i log. Se il problema persiste, stabilisci una connessione SSH (Secure Shell) al nodo host e cerca nei log del nodo i comandi nsenter per verificare la presenza di errori.

Se non utilizzi il plug-in CNI Istio, verifica che il pod del carico di lavoro disponga dell'autorizzazione CAP_NET_ADMIN, che viene impostata automaticamente dall'iniettore sidecar.

Connessione rifiutata dopo l'avvio del pod

Quando un pod viene avviato e riceve connection refused durante il tentativo di connessione a un endpoint, il problema potrebbe essere che il container dell'applicazione è stato avviato prima del container isto-proxy. In questo caso, il contenitore dell'applicazione invia la richiesta a istio-proxy, ma la connessione viene rifiutata perché istio-proxy non è ancora in ascolto sulla porta.

In questo caso, puoi:

  • Modifica il codice di avvio dell'applicazione per effettuare richieste continue all'endpoint di stato istio-proxy finché l'applicazione non riceve un codice 200. L'endpoint di integrità istio-proxy è:

    http://localhost:15020/healthz/ready

  • Aggiungi un meccanismo di richiesta di nuovi tentativi al carico di lavoro dell'applicazione.

L'elenco dei gateway restituisce un valore vuoto

Sintomo: quando elenchi i gateway utilizzando kubectl get gateway --all-namespaces dopo aver creato correttamente un gateway Cloud Service Mesh, il comando restituisce No resources found.

Questo problema può verificarsi su GKE 1.20 e versioni successive perché il controller GKE Gateway installa automaticamente la risorsa Gateway.networking.x-k8s.io/v1alpha1 di GKE nei cluster. Per risolvere il problema:

  1. Controlla se nel cluster sono presenti più risorse personalizzate del gateway:

    kubectl api-resources | grep gateway

    Output di esempio: 

    gateways                          gw           networking.istio.io/v1beta1            true         Gateway
gatewayclasses                    gc           networking.x-k8s.io/v1alpha1           false        GatewayClass
gateways                          gtw          networking.x-k8s.io/v1alpha1           true         Gateway

  2. Se l'elenco mostra voci diverse dai gateway con apiVersion networking.istio.io/v1beta1, utilizza il nome completo della risorsa o i nomi brevi distinguibili nel comando kubectl. Ad esempio, esegui kubectl get gw o kubectl get gateways.networking.istio.io anziché kubectl get gateway per assicurarti che i gateway Istio siano elencati.

Per ulteriori informazioni su questo problema, consulta Gateway Kubernetes e gateway Istio.

Il proxy Envoy si blocca durante l'inizializzazione

Se i log di debug indicano che il proxy Envoy è bloccato durante l'inizializzazione, puoi utilizzare il seguente comando per identificare cosa blocca il processo:

kubectl -n <ns> -c istio-proxy exec -it POD_NAME -- /usr/local/bin/pilot-agent request POST /init_dump

Risoluzione dei problemi relativi agli errori di risposta HTTP 5xx

Potresti riscontrare errori di risposta HTTP 5xx quando accedi alle applicazioni tramite Istio Ingress Gateway. Segui questi passaggi per diagnosticare e risolvere il problema.

  1. Identifica il control plane
  2. Verificare potenziali errori di configurazione
  3. Verifica l'individuazione del pod
  4. Analizzare i log di accesso

Identifica il control plane

Determina la versione e la configurazione del control plane perché versioni diverse possono influire sui processi di diagnostica. Per verificare lo stato del control plane gestito, esegui il seguente comando:

gcloud container fleet mesh describe --project PROJECT_ID

Lo stato ACTIVE indica che il control plane gestito funziona normalmente.

Verifica potenziali errori di configurazione

Errori di configurazione comuni possono causare errori di routing:

  • Mancata corrispondenza dello spazio dei nomi: VirtualService deve trovarsi nello stesso spazio dei nomi del servizio GKE di backend.
  • Mancata corrispondenza del riferimento gateway: VirtualService deve fare riferimento esplicitamente al Gateway corretto. Ad esempio, se VirtualService fa riferimento a istio-system/istio-ingressgateway, ma il gateway si trova nello spazio dei nomi default, il traffico non verrà instradato correttamente.

Verifica il rilevamento del pod

Assicurati che il pod dell'applicazione venga rilevato correttamente dalla mesh:

istioctl proxy-config endpoints POD_NAME

Analizzare i log degli accessi

Attiva i log degli accessi per determinare se gli errori hanno origine dall'applicazione di backend o dal proxy. I campi chiave includono RESPONSE_FLAGS, UPSTREAM_LOCAL_ADDRESS e RESPONSE_CODE.

Se i log indicano errori upstream, esegui un test curl diretto sul servizio GKE da un pod nello stesso spazio dei nomi. Se la richiesta curl restituisce lo stesso errore 5xx, il problema ha origine dall'applicazione di backend stessa.

Risoluzione dei problemi relativi ai certificati SSL

Gli errori del certificato SSL in Istio Ingress Gateway possono essere causati da certificati scaduti, mancata corrispondenza dei protocolli o configurazioni dei secret errate.

Identificare gli errori SSL

Esamina i log del pod Istio Ingress Gateway:

kubectl logs -l app=istio-ingressgateway -n GATEWAY_NAMESPACE

Verifica di certificati e chiavi

Assicurati che il certificato e la chiave privata siano validi e corrispondano utilizzando gli hash MD5:

openssl x509 -noout -modulus -in CERTIFICATE.CRT | openssl md5
openssl rsa -noout -modulus -in PRIVATE_KEY | openssl md5

Verifica che il certificato non sia scaduto e che il nome comune (CN) o il nome alternativo del soggetto (SAN) corrisponda al dominio.

Controlla la configurazione del protocollo TLS e del secret

Verifica la versione TLS e le suite di crittografia nel CRD Gateway. Assicurati che il secret Kubernetes contenente il certificato e la chiave si trovi nello stesso spazio dei nomi di Ingress Gateway e che credentialName corrisponda al nome del secret.

Risoluzione dei problemi relativi ai timeout intermittenti per gli endpoint esterni

Potrebbero verificarsi timeout intermittenti quando vengono effettuate richieste a endpoint esterni (come il bilanciamento del carico di rete di terze parti) che vengono risolti in più indirizzi IP.

Potenziale causa: risoluzione di ServiceEntry

Se spec.resolution è impostato su DNS, Istio utilizza "DNS rigoroso", che bilancia il carico su tutti gli indirizzi IP risolti. Alcuni NLB non lo supportano.

Risoluzione

Per risolvere il problema, imposta la risoluzione su DNS_ROUND_ROBIN in ServiceEntry.

Risoluzione dei problemi di distribuzione del traffico non uniforme

Se il traffico non è distribuito in modo uniforme tra i pod dell'applicazione, controlla quanto segue:

  • Integrità pod: assicurati che tutti i pod dell'applicazione fossero integri durante lo squilibrio.
  • Algoritmo di bilanciamento del carico: rivedi la configurazione di DestinationRule per l'impostazione loadBalancer (ad es. consistentHash o ROUND_ROBIN).
  • Bilanciamento del carico locale: verifica se localityLbSetting è abilitato. Tieni presente che questa operazione non è supportata con il control plane TRAFFIC_DIRECTOR.

Risoluzione dei problemi relativi alla propagazione dei servizi e alle quote

Se i nuovi servizi o le nuove configurazioni di rete non vengono visualizzati nel mesh, potrebbe essere dovuto al raggiungimento delle quote di risorse nel progetto fleet.

Sintomi

  • Le configurazioni di Networking (come VirtualService o DestinationRule) non vengono inviate ai proxy sidecar.
  • I nuovi servizi appaiono "invisibili" al mesh nonostante siano definiti correttamente.

Procedura per l'identificazione e la risoluzione

  1. Controlla le quote delle risorse: verifica se il progetto fleet ha raggiunto la quota per le risorse BackendService controllando la quota Servizi di backend del director del traffico interno globale nel progetto fleet. Cloud Service Mesh in genere crea un BackendService per ogni porta di servizio Kubernetes.
  2. Esamina i limiti di scalabilità: assicurati che la tua configurazione rimanga entro i limiti di scalabilità supportati per Cloud Service Mesh.
  3. Aumenta le quote: se le quote sono state raggiunte, richiedi un aumento per la risorsa interessata nel progetto fleet per ripristinare la normale propagazione del servizio.

Risoluzione dei problemi di valutazione di VirtualService

Se un VirtualService non si comporta come previsto, ricorda che le route vengono valutate nell'ordine in cui sono elencate. Quando hai più servizi virtuali per lo stesso host, le relative route vengono unite. Le route dei servizi virtuali "meno recenti" hanno la priorità, quindi vengono posizionate prima delle route di quelli "più recenti" nell'elenco unito. Ciò rafforza la regola della "prima corrispondenza".

Risoluzione dei problemi di bilanciamento del carico per le località

Per impostazione predefinita, il bilanciamento del carico locale indirizza il traffico client agli endpoint nella stessa zona (la zona principale o priorità 0). Envoy instrada il traffico verso le zone di failover (priorità 1 o superiore) solo quando gli endpoint nella zona principale non sono integri o non sono disponibili.

Se non esegui lo scale degli endpoint per gestire l'intero carico zonale o se preferisci dividere il traffico tra le zone, esegui una delle seguenti operazioni:

  • Scala i pod nelle rispettive zone per gestire il carico di traffico locale.
  • Disabilita l'impostazione di bilanciamento del carico per le località.

Identifica le impostazioni di bilanciamento del carico per le località

Il bilanciamento del carico locale si basa sulle etichette di topologia dei nodi per raggruppare gli endpoint. Per verificare le etichette dei nodi e controllare le impostazioni, utilizza i seguenti comandi:

  • Verifica le etichette della topologia dei nodi:

    kubectl get nodes -o custom-columns=NAME:.metadata.name,\
    REGION:.metadata.labels."topology\\.kubernetes\\.io/region",\
    ZONE:.metadata.labels."topology\\.kubernetes\\.io/zone"

  • Per le DestinationRule di GKE, esamina le impostazioni di località:

    kubectl get destinationrule DESTINATION_RULE_NAME -o yaml

    Cerca localityLbSetting: enabled: true nell'output.

  • Per controllare gli endpoint, le priorità e l'integrità del proxy Envoy:

    istioctl proxy-config endpoints POD_NAME.NAMESPACE \
    --cluster "outbound|PORT||SERVICE_FQDN" -o json

    Cerca il campo priority nella configurazione dell'endpoint.

  • Per visualizzare la configurazione dettagliata dei cluster attivi:

    istioctl proxy-config cluster POD_NAME.NAMESPACE \
    --fqdn SERVICE_FQDN -o json