Questa sezione illustra i problemi comuni di Anthos Service Mesh e come risolverli. Se hai bisogno di ulteriore aiuto, vedi Ricevere assistenza.
Errori di connessione al server API nei log Istiod
Istiod non può contattare apiserver se riscontri 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.
In genere questo errore è temporaneo e se hai raggiunto i log del proxy utilizzando kubectl, il problema potrebbe essere già stato risolto. Questo errore è generalmente causato da eventi che rendono il server API temporaneamente non disponibile, ad esempio quando un server API non incluso in una configurazione ad alta disponibilità viene riavviato per un upgrade o una modifica alla scalabilità automatica.
Il container istio-init si arresta in modo anomalo
Questo problema può verificarsi quando le regole iptables dei pod non vengono applicate allo spazio dei nomi di rete dei pod. Ciò può essere dovuto a:
- Un criterio di sicurezza dei pod (PSP) eccessivamente restrittivo
- Un'installazione istio-cni incompleta
- Autorizzazioni pod del carico di lavoro insufficienti (autorizzazione
CAP_NET_ADMINmancante)
Se utilizzi un criterio di sicurezza dei pod che limita l'autorizzazione CAP_NET_ADMIN, passa all'utilizzo del plug-in CNI di 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, stabilisci una shell sicura (SSH) nel nodo host, cerca i comandi nsenter nei log dei nodi 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 connection refused tenta di connettersi a un endpoint, il problema potrebbe essere che il container dell'applicazione sia 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 dell'applicazione per effettuare richieste continue all'endpoint di integrità
istio-proxyfinché l'applicazione non riceve un codice 200. L'endpoint di integritàistio-proxyè:http://localhost:15020/healthz/readyAggiungi un meccanismo di richiesta di nuovo tentativo al carico di lavoro dell'applicazione.
Resi dei gateway della scheda vuoti
Sintomo: quando elenchi i gateway che utilizzano kubectl get gateway --all-namespaces
dopo aver creato correttamente un gateway mesh di servizi Anthos, 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:
Verifica se nel cluster sono presenti più risorse personalizzate del gateway:
kubectl api-resources | grep gatewayOutput 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
networking.istio.io/v1beta1apiVersion, utilizza il nome completo della risorsa o i nomi brevi distinguibili nel comandokubectl. Ad esempio, eseguikubectl get gwokubectl get gateways.networking.istio.ioanzichékubectl get gatewayper assicurarti che i gateway istio siano elencati.
Per ulteriori informazioni su questo problema, consulta Gateway e gateway Istio di Kubernetes.