Risoluzione dei problemi relativi a proxy sidecar/webhook in Cloud Service Mesh

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

Cloud Service Mesh contiene due webhook:

La convalida del webhook garantisce che la configurazione Istio applicata sia valida.
Il webhook mutante imposta l'inserimento automatico del sidecar sui 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 Sidecar non funziona correttamente se si verifica uno dei seguenti problemi:

pod che pianificano senza file collaterali
i pod che dovrebbero avere sidecar inseriti non vengono mai visualizzati quando si utilizza kubectl get pods, ma il set di repliche corrispondente da kubectl get replicaset esiste.

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

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

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

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

Il webhook di inserimento del file collaterale (utilizzato per l'inserimento automatico del sidecar) richiede un bundle CA per stabilire connessioni sicure con il server API e istiod. A questo bundle di CA è stata applicata la patch alla configurazione da istiod, ma a volte può essere sovrascritto (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-1187-26, che è specifico di questa versione di Cloud Service Mesh. Assicurati di usare la revisione effettiva se differisce.
```
kubectl get mutatingwebhookconfigurations.admissionregistration.k8s.io istio-sidecar-injector-asm-1187-26 -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 consentire una nuova scansione del webhook e reinstallare il bundle CA.
Verifica la presenza di errori di inserimento del file collaterale.

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 stai pianificando nessun 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 se sono presenti errori nel log eventi in fondo alla descrizione. Se l'errore riguarda l'inserimento di file collaterali, controlla i log istiod per capire la causa dell'errore.
Se il problema persiste, potrebbe essere uno dei seguenti:
- Configurazione errata passata all'iniettore
- Problemi di configurazione del firewall
- Un problema nel codice Istio
Consulta 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 ai proxy di ricevere la configurazione da istiod.

istiod non eseguirà il push della configurazione ai proxy Envoy se ha problemi, ad esempio un problema RBAC che gli impedisce di leggere la sua risorsa di configurazione.
L'indirizzo di rilevamento non è corretto (errori "upstream non integro")
L'indirizzo di rilevamento fornito all'iniettore collaterale non è 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 rimandi al tuo servizio istiod.
Push di configurazione non valida al proxy in corso. In questo caso, il push della configurazione al proxy viene inviato correttamente, ma non è valida. Visualizzerai messaggi ripetuti 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 ascoltatori (che segnala 1 aggiornamento rifiutato da istiod). Spesso viene visualizzato un messaggio di errore precedente che spiega il motivo del rifiuto, che in genere inizia con un avviso relativo alla configurazione di Envoy o simili.

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

Creazione del pod non riuscita

Se noti che i pod non vengono creati correttamente, cerca i messaggi di errore che potrebbero fornire indizi sul problema principale utilizzando il seguente comando:

kubectl describe replicaset YOUR_REPLICA_SET

Messaggi di errore comuni relativi al webhook

I messaggi di errore generati dal comando kubectl apply possono fornire un indizio sulla causa principale. Consulta la tabella seguente per conoscere i messaggi di errore comuni, le relative cause e le potenziali 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 la connettività a "istiod" sulla porta 15017.
`no endpoints available for service 'istiod'`	Ciò può verificarsi 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`	Ciò può verificarsi se il servizio "istiod" non esiste.	Verifica che l'installazione di Istio sia riuscita 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 da una versione precedente di Istio o Cloud Service Mesh che è stato disinstallato potrebbe interferire con un upgrade o un'installazione.	Verifica che tutti i webhook siano ancora presenti nel cluster e rimuovi tutti i webhook 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 connettività a Istiod sulla porta 15017. Per maggiori informazioni, consulta Apertura di una porta in un cluster privato.