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 diistio-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:
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
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 comandokubectl
. Ad esempio, eseguikubectl get gw
okubectl get gateways.networking.istio.io
invece dikubectl get gateway
per assicurarti che i gateway istio siano elencati.
Per ulteriori informazioni sul problema, vedi Gateway Kubernetes e gateway Istio.