Risolvere i problemi relativi a proxy/webhook sidecar in Cloud Service Mesh

Questa sezione illustra i problemi comuni di Cloud Service Mesh e come risolverli. Per ulteriore assistenza, consulta Assistenza.

Cloud Service Mesh contiene due webhook:

La convalida del webhook garantisce che la configurazione Istio applicata sia valida.
Il webhook con mutazioni imposta l'iniezione automatica di sidecar nei nuovi pod.

Un problema di configurazione in uno di questi webhook potrebbe causare errori nei nuovi pod all'avvio o kubectl apply che genera messaggi di errore.

Problemi di iniezione di sidecar

Se hai eseguito il provisioning di Cloud Service Mesh gestito, contatta l'assistenza.

L'iniezione Sidecar non funziona correttamente se si verifica uno dei seguenti problemi:

pod pianificati senza sidecar
I pod in cui devono essere iniettati i sidecar non vengono mai visualizzati quando si utilizza kubectl get pods, ma il set di replica corrispondente di kubectl get replicaset esiste.

Per risolvere i problemi di inserimento di sidecar, segui i passaggi riportati di seguito.

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

Se utilizzi Istio con una revisione singola (valore predefinito), verifica che lo schema del tuo ambito o pod contenga l'etichetta istio-injection=enabled.

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

Il webhook di inserimento del sidecar (utilizzato per l'inserimento automatico del sidecar) richiede un bundle CA per stabilire connessioni sicure con il server API e istiod. Questo bundle CA viene applicato alla configurazione da istiod, ma talvolta può essere sovrascritto (ad esempio, se si applica di nuovo la configurazione del webhook).

Puoi verificare la presenza del bundle CA utilizzando il seguente comando. La include istio-sidecar-injector-asm-1225-1, ovvero specifiche di questa versione di Cloud Service Mesh. Assicurati di utilizzare i valori effettivi revisione se differisce.
```
kubectl get mutatingwebhookconfigurations.admissionregistration.k8s.io istio-sidecar-injector-asm-1225-1 -o=jsonpath='{.webhooks[0].clientConfig.caBundle}'
```
Se l'output non è vuoto, viene configurato il bundle CA. Se il pacchetto CA è mancante, riavvia istiod per eseguire nuovamente la scansione dell'webhook e reinstallare il pacchetto CA.
Verifica la presenza di errori di inserimento del file collaterale.

Se hai abilitato l'inserimento, ma non vedi la pianificazione dei pod, controlla al livello di astrazione successivo. Ad esempio, se è in esecuzione un deployment, ma non ci sono pod in fase di pianificazione, controlla lo stato set di repliche corrispondenti usando il comando seguente:
```
kubectl -n my-namespace describe replicaset your-deployment-name
```
Se il set di repliche è presente, controlla il log eventi nella parte inferiore della descrizione degli errori. Se l'errore riguarda l'iniezione di sidecar, controlla i log di istiod per avere un'indicazione della 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 di Istio stesso
Vedi Risoluzione dei problemi di Istio per ulteriori passaggi diagnostici.

I proxy Envoy non ricevono la configurazione da `istiod`

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

istiod non invierà la configurazione ai proxy Envoy in caso di problemi, come un problema di RBAC che impedisce la lettura della risorsa di configurazione.
L'indirizzo di rilevamento non è corretto (errori "upstream non integro")
L'indirizzo di rilevamento fornito all'iniettore collaterale non è corretto. Se vedrai i log che menzionano gRPC config stream closed, no healthy upstream, verifica che l'indirizzo di rilevamento nel mesh ProxyConfig è corretta e rimanda al tuo servizio istiod.
Configurazione non valida inviata al proxy. In questo caso, la configurazione è stato inviato correttamente al proxy, ma la configurazione non è valida. Potrai vedi 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 Cluster Discovery Service (che segnala 1 update inviato da istiod) e lds è il servizio Listener Discovery Service (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 sulla configurazione di Envoy o simile.

Per risolvere il problema, esamina la causa della configurazione rifiutata. Una causa comune è la scarsa qualità delle risorse EnvoyFilter. Se non è evidente il motivo, 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 di fondo 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 suggerimento la causa principale. Consulta la tabella seguente per conoscere i messaggi di errore comuni, cause e 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 con il 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 Cloud Service Mesh che è stato disinstallato potrebbe interferire con un eseguire l'upgrade o l'installazione.	Verifica che tutti i webhook siano ancora nel cluster e rimuovi eventuali 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 del firewall forniscano connettività a Istiod sulla porta 15017. Per saperne di più, consulta Apertura di una porta su un cluster privato.