Versione 1.14

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

Risolvere i problemi di gestione del traffico in Anthos Service Mesh

Questa sezione spiega i problemi comuni di Anthos Service Mesh e come risolverli. Se hai bisogno di ulteriore assistenza, vedi la sezione Richiedere assistenza.

Errori di connessione al server API nei log Istio

Istio non può contattare apiserver se rileva 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 di solito è temporaneo e se hai raggiunto i log del proxy utilizzando kubectl, il problema potrebbe essere già stato risolto. In genere questo errore è causato da eventi che rendono il server API temporaneamente non disponibile, ad esempio quando un server API non presente in una configurazione ad alta disponibilità si riavvia per una modifica o un upgrade della 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. Questo può essere dovuto a:

  • Un criterio di sicurezza dei pod eccessivamente restrittivo
  • Installazione istio-cni incompleta
  • Autorizzazioni pod del carico di lavoro insufficienti (mancata autorizzazione CAP_NET_ADMIN)

Se utilizzi un criterio di sicurezza dei pod che limita l'autorizzazione CAP_NET_ADMIN, passa al plug-in CNI Istio.

Se utilizzi il plug-in CNI di 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, crea una shell sicura (SSH) nel nodo host, cerca i comandi nsenter nei log del nodo e controlla se sono presenti errori.

Se non utilizzi il plug-in CNI di Istio o un criterio di sicurezza dei pod, 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 si avvia e riceve connection refused che tenta di connettersi a un endpoint, il problema potrebbe essere che il container dell'applicazione è stato avviato prima del container isto-proxy. In questo caso, il container 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 della tua applicazione per effettuare richieste continue all'endpoint di integrità di istio-proxy finché l'applicazione non riceve un codice 200. L'endpoint di stato di istio-proxy è:

    http://localhost:15020/healthz/ready
    
  • Aggiungi un meccanismo di richiesta di nuovo tentativo al carico di lavoro dell'applicazione.

Il gateway della scheda restituisce il campo vuoto

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

Questo problema può verificarsi in GKE 1.20 e versioni successive perché il controller GKE Gateway installa automaticamente la risorsa GKE Gateway.networking.x-k8s.io/v1alpha1 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 da Gateway con apiVersion networking.istio.io/v1beta1, utilizza il nome completo della risorsa o i nomi brevi indistinguibili nel comando kubectl. Ad esempio, esegui kubectl get gw o kubectl get gateways.networking.istio.io invece di kubectl get gateway per assicurarti che i gateway istio siano elencati.

Per ulteriori informazioni sul problema, vedi Gateway Kubernetes e gateway Istio.