Risolvere i problemi proxy sidecar/webhook in Anthos Service Mesh

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

Anthos Service Mesh contiene due webhook:

Il webhook di convalida garantisce che la configurazione Istio applicata sia valida.
Il webhook mutante imposta l'iniezione automatica di sidecar su nuovi pod.

Un problema di configurazione in uno di questi webhook potrebbe causare il mancato avvio dei nuovi pod o la generazione di messaggi di errore da parte di kubectl apply.

Problemi di iniezione di sidecar

L'iniezione di sidecar non funziona correttamente se visualizzi uno dei seguenti sintomi:

pod che vengono pianificati senza sidecar
i pod che devono avere un sidecar inserito non vengono mai visualizzati quando viene utilizzato l'elemento kubectl get pods, ma esiste il set di repliche corrispondente di kubectl get replicaset.

Per risolvere i problemi di iniezione di sidecar, procedi nel seguente modo.

Verifica che lo spazio dei nomi o il pod abbia l'etichetta di iniezione corretta.

Se esegui Istio a revisione singola (impostazione predefinita), verifica che lo spazio dei nomi o le specifiche del pod abbiano l'etichetta istio-injection=enabled.

Se esegui Istio a più istanze (per migrazioni senza tempo di inattività, più piani di controllo e così via), verifica che lo spazio dei nomi o la specifica pod abbia l'etichetta istio.io/rev=REVISION appropriata, dove REVISION è il numero di revisione di Anthos Service Mesh su istiod che corrisponde alla versione di Anthos Service Mesh selezionata. Per ulteriori informazioni sulle etichette di revisione, consulta la sezione Inserimento di proxy sidecar.
Verifica che il webhook di iniezione sidecar istio sia presente e abbia un bundle CA.

Il webhook iniettore sidecar (utilizzato per l'iniezione automatica di sidecar) richiede un bundle CA per stabilire connessioni sicure con il server API e istiod. La configurazione di questo bundle CA viene eseguita da istiod, ma a volte può essere sovrascritta (ad esempio, se applichi di nuovo la configurazione del webhook).

Puoi verificare la presenza del bundle CA utilizzando il seguente comando. Il comando include istio-sidecar-injector-asm-1182-4, che è specifico per questa versione di Anthos Service Mesh. Assicurati di utilizzare la revisione effettiva, se è diversa.
```
kubectl get mutatingwebhookconfigurations.admissionregistration.k8s.io istio-sidecar-injector-asm-1182-4 -o=jsonpath='{.webhooks[0].clientConfig.caBundle}'
```
Se l'output non è vuoto, viene configurato il bundle CA. Se il bundle CA non è presente, riavvia istiod per farlo ripetere la scansione del webhook e reinstallare il bundle CA.
Verifica la presenza di errori di iniezione di sidecar.

Se hai abilitato l'inserimento, ma non vedi la pianificazione dei pod, controlla lo stato del livello di astrazione successivo. Ad esempio, se stai eseguendo un deployment ma non stanno pianificando pod, controlla lo stato dei set di repliche corrispondenti utilizzando il seguente comando:
```
kubectl -n my-namespace describe replicaset your-deployment-name
```
Se il set di repliche è presente, controlla la presenza di errori nel log eventi nella parte inferiore della descrizione. Se l'errore riguarda l'iniezione di sidecar, controlla i log istiod per un'indicazione della causa dell'errore.
Se il problema persiste, la causa potrebbe essere una delle seguenti:
- Configurazione errata inviata all'iniettore
- Problemi di configurazione del firewall
- Un problema nel codice Istio stesso
Consulta la procedura per la risoluzione dei problemi di Istio per ulteriori passaggi di diagnostica.

I proxy Envoy non ricevono la configurazione da `istiod`

Esistono diversi problemi che possono impedire al proxy di ricevere la configurazione da istiod.

istiod non eseguirà il push della configurazione ai proxy inviati se presenta problemi, ad esempio un problema RBAC che ne impedisce la lettura nella risorsa di configurazione.
L'indirizzo di rilevamento non è corretto (errore "non integro a monte")
L'indirizzo di rilevamento fornito all'iniettore del sidecar non era corretto. Se vedi log che menzionano gRPC config stream closed, no healthy upstream, verifica che l'indirizzo di rilevamento nel mesh ProxyConfig sia corretto e che indirizzi al servizio istiod.
Push della configurazione al proxy non valido. In questo caso, la configurazione viene trasferita correttamente al proxy, ma la configurazione non è valida. Vedrai messaggi ricorrenti simili ai seguenti:
```
Envoy proxy is NOT ready: config not received from Pilot (is Pilot running?): cds updates: 1 successful, 0 rejected; lds updates: 0 successful, 1 rejected
```
In questo esempio, cds è il servizio di rilevamento cluster (che segnala 1 aggiornamento inviato da istiod) e lds è il servizio di rilevamento listener (che segnala 1 aggiornamento rifiutato da istiod). Spesso viene visualizzato un messaggio di errore precedente che spiega il motivo del rifiuto, che di solito inizia con un avviso sulla configurazione del mittente o simile.

Per risolvere il problema, verifica la causa della configurazione rifiutata. Una causa comune sono risorse EnvoyFilter non valide. Se nessun motivo è evidente, invia una segnalazione di bug con un dump di configurazione del proxy.

Creazione pod non riuscita

Se noti che i pod non vengono creati correttamente, cerca i messaggi di errore che potrebbero indicare la presenza del problema root, utilizzando il seguente comando:

kubectl describe replicaset YOUR_REPLICA_SET

Messaggi di errore relativi ai webhook comuni

I messaggi di errore generati dal comando kubectl apply possono fornire un suggerimento sulla causa principale. Consulta la seguente tabella per conoscere i messaggi di errore comuni, le loro cause e le possibili risoluzioni.

Messaggio di errore	Causa	Risoluzione
`net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)`	Potrebbe trattarsi di un problema di connettività di rete.	Assicurati che le regole firewall forniscano connettività a "istiod" sulla porta 15017.
`no endpoints available for service 'istiod'`	Questo può accadere se il pod "istiod" non è disponibile o non è pronto.	Controlla i pod "istiod" per assicurarti che siano in esecuzione e pronti.
`Service "istiod" not found`	Questo può accadere se il servizio "istiod" non esiste.	Verifica che l'installazione di Istio sia avvenuta correttamente e corretta.
`x509: certificate signed by unknown authority`	Potrebbe trattarsi di un problema relativo al certificato webhook.	Verifica che `caBundle` sia impostato correttamente sul webhook.
`Failed to update validatingwebhookconfiguration istio-validator-asm-[version-n]-istio-system (failurePolicy=Fail, resourceVersion=[version]): Operation cannot be fulfilled on validatingwebhookconfigurations.admissionregistration.k8s.io "istio-validator-asm-[version-n]-istio-system": the object has been modified; please apply your changes to the latest version and try again.`	Un webhook di convalida di una versione precedente di Istio o Anthos Service Mesh che è stato disinstallato potrebbe interferire con un upgrade o un'installazione.	Verifica che tutti i webhook ancora nel cluster e rimuovi quelli che fanno riferimento a versioni non più installate.
`Error from server (InternalError): Internal error occurred: failed calling webhook "rev.namespace.sidecar-injector.istio.io": Post "https://istiod-asm-1122-0.istio-system.svc:443/inject?timeout=10s": context deadline exceeded`	Per i cluster privati, la porta 15017 deve essere aperta. Questo messaggio di errore indica che la porta 15017 potrebbe non essere aperta.	Assicurati che le regole firewall forniscano la connettività a Istiod sulla porta 15017. Per maggiori informazioni, consulta la pagina relativa all'apertura di una porta su un cluster privato.