Risolvere i problemi di gestione del traffico in Cloud Service Mesh

Questa sezione illustra i problemi comuni di Cloud Service Mesh e come risolverli. Se hai bisogno di ulteriore assistenza, consulta la sezione Ricevere assistenza.

Errori di connessione al server API nei log di Istiod

Istiod non riesce a 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 di espressione regolare /error.*cannot list resource/ per trovare questo errore nei log.

Questo errore è in genere temporaneo e, se hai raggiunto i log del proxy utilizzando kubectl, il problema potrebbe essere già stato risolto. Questo errore è in genere causato da eventi che rendono temporaneamente non disponibile il server API, ad esempio quando un server API che non è in una configurazione di alta disponibilità si riavvia per un upgrade o una modifica dell'autoscaling.

Il contenitore 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. Questo può essere causato da:

  • Un'installazione istio-cni incompleta
  • Autorizzazioni del pod del carico di lavoro insufficienti (manca l'autorizzazione CAP_NET_ADMIN)

Se utilizzi il plug-in CNI Istio, verifica di aver seguito completamente le istruzioni. Verifica che il contenitore istio-cni-node sia pronto e controlla i log. Se il problema persiste, stabilisci una shell sicura (SSH) nel nodo host e cerca i comandi nsenter nei log del nodo per verificare se sono presenti errori.

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

Connessione rifiutata dopo l'avvio del pod

Quando un pod si avvia e connection refused tenta di connettersi a un endpoint, il problema potrebbe essere che il contenitore dell'applicazione è stato avviato prima del contenitore 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 in modo che invii richieste continue all'endpoint di statoistio-proxy finché l'applicazione non riceve un codice 200. L'endpoint di salute istio-proxy è:

    http://localhost:15020/healthz/ready

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

I gateway delle schede restituiscono 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 in GKE 1.20 e versioni successive perché il controller di gateway GKE installa automaticamente la risorsa Gateway.networking.x-k8s.io/v1alpha1 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 nell'elenco sono presenti voci diverse da 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.