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. Se hai bisogno di ulteriore assistenza, consulta la sezione Ricevere assistenza.

Cloud Service Mesh contiene due webhooks:

• Il webhook di convalida garantisce che la configurazione di 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 l'interruzione dell'avvio dei nuovi pod o la generazione di messaggi di errore.kubectl apply

Problemi di inserimento di sidecar

L'iniezione Sidecar non funziona correttamente se vedi una delle seguenti condizioni:

• 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.

1. 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 tempi di riposo, 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 che corrisponde alla versione di Cloud Service Mesh selezionata. Per ulteriori informazioni sulle etichette di revisione, consulta Eseguire l'iniezione di proxy sidecar.

2. Verifica che l'webhook di inserimento del sidecar Istio sia presente e che abbia un bundle CA.

   Il webhook di iniezione di sidecar (utilizzato per l'iniezione automatica di 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 a volte 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. Il comando include istio-sidecar-injector-asm-1233-2, che è specifico per questa versione di Cloud Service Mesh. Assicurati di utilizzare la revisione effettiva se è diversa.

   kubectl get mutatingwebhookconfigurations.admissionregistration.k8s.io istio-sidecar-injector-asm-1233-2 -o=jsonpath='{.webhooks[0].clientConfig.caBundle}'

   Se l'output non è vuoto, il bundle CA è configurato. Se il pacchetto CA è mancante, riavvia istiod per eseguire nuovamente la scansione dell'webhook e reinstallare il pacchetto CA.

3. Controlla la presenza di errori di inserimento di sidecar.

   Se hai attivato l'iniezione, ma non visualizzi la pianificazione dei pod, controlla lo stato del livello di astrazione successivo. Ad esempio, se stai eseguendo un deployment, ma non è pianificato alcun pod, controlla lo stato degli set di replica corrispondenti utilizzando il seguente comando:

   kubectl -n my-namespace describe replicaset your-deployment-name

   Se il set di replica è presente, controlla la presenza di errori nel log degli eventi nella parte inferiore della descrizione. Se l'errore riguarda l'iniezione di sidecar, controlla i log di istiod per avere un'indicazione della causa dell'errore.

4. 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

   Per ulteriori passaggi di diagnostica, consulta la sezione Risoluzione dei problemi di Istio.

I proxy Envoy non ricevono la configurazione da istiod

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

1. istiod non invierà la configurazione ai proxy Envoy se si verificano problemi, ad esempio un problema di RBAC che impedisce la lettura della risorsa di configurazione.

2. L'indirizzo discovery non è corretto (errori "no upstream healthy")

3. L'indirizzo discovery fornito all'iniettore sidecar non è corretto. Se visualizzate log che menzionano gRPC config stream closed, no healthy upstream, verificate che l'indirizzo di rilevamento nella mesh ProxyConfig sia corretto e indichi il servizio istiod.

4. Configurazione non valida inviata al proxy. In questo caso, la configurazione viene inviata correttamente al proxy, ma non è valida. Vedrai messaggi ripetuti simili al seguente:

   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.

La creazione del pod non riesce

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 dei webhook

I messaggi di errore generati dal comando kubectl apply possono fornire un suggerimento sulla loro causa principale. Consulta la tabella seguente per i messaggi di errore più comuni, le relative cause e le potenziali soluzioni.