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, consulta la sezione 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 errori nei nuovi pod all'avvio o kubectl apply che genera messaggi di errore.

Problemi di inserimento di sidecar

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

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

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

  1. 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 il tuo la specifica dello spazio dei nomi o del pod ha 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 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 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 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-1167-22, che è specifico per 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-1167-22 -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 è 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'inserimento di file collaterali, controlla istiod per 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 Istio

    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 configurazione da istiod.

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

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

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

  4. Push di configurazione non valida al proxy in corso. In questo caso, la configurazione è stato inviato correttamente al proxy, ma la configurazione 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 è Cluster Discovery Service (che riporta 1 aggiornamento inviato da istiod) e lds è il servizio di rilevamento listener (indica che 1 aggiornamento è stato rifiutato da istiod). Spesso vedrai un modello in cui viene spiegato il motivo del rifiuto, solitamente inizia con un avviso sulla configurazione di envoy o un avviso simile.

    Per risolvere il problema, verifica la causa della configurazione rifiutata. Uno. la causa comune è l'inattività 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 un errore messaggi che potrebbero fornire indizi per il problema di base, 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.

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 Questo può verificarsi se il servizio "istiod" non esiste. Verifica che l'installazione di Istio sia stata eseguita correttamente.
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 di una versione precedente di Istio o Cloud Service Mesh che è stato disinstallato potrebbe interferire con un upgrade o un'installazione. Controlla tutti i webhook 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 ulteriori informazioni, vedi Apertura di una porta su un cluster privato