Risoluzione dei problemi relativi all'aggiornamento di revisione secondaria del componente aggiuntivo Istio Service Mesh

Questo articolo illustra gli scenari di risoluzione dei problemi e le restrizioni nei processi secondari di aggiornamento e rollback delle revisioni per il componente aggiuntivo Istio Service Mesh in Microsoft servizio Azure Kubernetes (AKS).

Nota

Istio usa il termine "revisioni" per implementare il processo di aggiornamento canary e distinguere tra le versioni. Ogni designazione di revisione (scritta come x-y) corrisponde a una designazione della versione major.minor (x.y). È possibile controllare la revisione del piano di controllo, ma non è possibile controllare la versione della patch specifica all'interno di una banda di revisione.

Prerequisiti

Matrice di risoluzione dei problemi

La tabella seguente elenca i vari problemi e i diversi scenari e soluzioni per tali problemi.

Scenario Problema Soluzione
I carichi di lavoro del piano dati vengono eliminati dalla mesh. Le revisioni del piano dati e del piano di controllo non corrispondevano prima del completamento o del rollback di un aggiornamento.

attenersi alla seguente procedura:

  1. Etichettare nuovamente gli spazi dei nomi che contengono carichi di lavoro specificando la revisione prevista dopo il completamento o il rollback dell'aggiornamento. A tale scopo, eseguire il comando kubectl label :

    kubectl label namespace default istio.io/rev=asm-x-y --overwrite
  2. Riavviare le distribuzioni del carico di lavoro corrispondenti per attivare la reiniezione sidecar della revisione corretta. A tale scopo, eseguire il comando kubectl rollout restart :

    kubectl rollout restart deployment <deployment name>
  3. Verificare che le immagini sidecar esistano. A tale scopo, eseguire il comando kubectl get :

    kubectl get pods --namespace <namespace> --output yaml | grep mcr.microsoft.com/oss/istio/proxyv2:
I pod del piano di controllo sono nello stato in sospeso. I pod non hanno capacità. Verificare lo stato dei pod eseguendo il comando kubectl describe . Se la capacità è il problema, è possibile aumentare il numero di istanze del cluster per aggiungere un altro nodo. Per altre informazioni, vedere Ridimensionare manualmente il numero di nodi in un cluster servizio Azure Kubernetes (servizio Azure Kubernetes).
Il comando az aks mesh get-upgrades non restituisce aggiornamenti disponibili. La revisione più recente di Istio potrebbe non essere compatibile con la versione corrente del cluster del servizio Azure Kubernetes. È possibile usare il comando az aks mesh get-revisions per scoprire se sono presenti revisioni Istio più recenti. L'output include un elenco di versioni del cluster compatibili per ogni revisione di Istio. È pertanto possibile determinare se è necessario un aggiornamento del cluster.

Nota

Per evitare comportamenti imprevisti e funzionalità interrotte e assicurarsi anche di ricevere aggiornamenti per le vulnerabilità di sicurezza, è consigliabile eseguire l'aggiornamento a una versione del servizio Azure Kubernetes supportata e aggiornata e a una revisione del componente aggiuntivo Istio. Tenere presente che la revisione del componente aggiuntivo deve essere inclusa anche nell'intervallo di versioni di Kubernetes supportato per il cluster del servizio Azure Kubernetes specificato. Come evidenziato nella sezione Aggiornamento di revisione secondaria dell'articolo Aggiornamento di Istio, è possibile eseguire i az aks mesh get-revisions comandi e az aks mesh get-upgrades per informazioni sulle revisioni, gli aggiornamenti e le informazioni sulla compatibilità dei componenti aggiuntivi disponibili.

Limitazioni

  • Un downgrade a una revisione precedente (al di fuori del processo di rollback canary) non è consentito.

  • Il passaggio da una revisione a una revisione nonconsecutiva è consentito solo se il servizio Azure Kubernetes non supporta più sia la revisione corrente che la revisione successiva dell'aggiornamento. A questo punto, l'unico aggiornamento disponibile è la revisione supportata più bassa.

  • L'etichetta Istio sidecar.istio.io/inject non abilita l'inserimento sidecar per il componente aggiuntivo Istio. È necessario usare l'etichetta istio.io/rev quando si etichettano ed etichettano nuovamente gli spazi dei nomi durante l'aggiornamento canary.

  • L'etichettatura deve essere eseguita a livello di spazio dei nomi anziché a livello di distribuzione. Se si vuole essere in grado di eseguire il rollover dei pod singolarmente, è possibile scegliere di riavviare le singole distribuzioni anziché usare l'etichettatura dei pod.

  • Se si usa il componente aggiuntivo Istio Shared MeshConfig, è necessario copiare o trasferire le impostazioni di MeshConfig nella nuova configmap prima di eseguire un aggiornamento canary. Per altre informazioni, vedere Configurazione e aggiornamenti della mesh.

  • Il componente aggiuntivo Istio distribuisce i pod del gateway di ingresso Istio e le distribuzioni per revisione. Se si esegue un aggiornamento canary e nel cluster sono installate due revisioni del piano di controllo, potrebbe essere necessario risolvere più pod gateway in ingresso in entrambe le revisioni.

Riferimenti

Dichiarazione di non responsabilità sulle informazioni di terze parti

I prodotti di terzi citati in questo articolo sono prodotti da società indipendenti da Microsoft. Microsoft non rilascia alcuna garanzia implicita o esplicita relativa alle prestazioni o all'affidabilità di tali prodotti

Dichiarazione di non responsabilità di contatti di terze parti

Microsoft fornisce informazioni di contatto di terze parti per aiutarti a trovare ulteriori informazioni su questo argomento. Queste informazioni di contatto sono soggette a modifica senza preavviso. Microsoft non garantisce l'accuratezza delle informazioni di contatto di terze parti.

Contattaci per ricevere assistenza

In caso di domande o bisogno di assistenza, creare una richiesta di supporto tecnico oppure formula una domanda nel Supporto della community di Azure. È possibile anche inviare un feedback sul prodotto al feedback della community di Azure.