Aggiornare il componente aggiuntivo mesh di servizi basato su Istio per servizio Azure Kubernetes

Questo articolo illustra le esperienze di aggiornamento per il componente aggiuntivo Service Mesh basato su Istio per il servizio Azure Kubernetes.

Gli annunci sulle versioni delle nuove revisioni secondarie o delle patch per il componente aggiuntivo Mesh di servizi basato su Istio vengono pubblicati nelle note sulla versione del servizio Azure Kubernetes. Per altre informazioni sul supporto per il controllo delle versioni e gli aggiornamenti del componente aggiuntivo mesh del servizio, leggere i criteri di supporto.

Aggiornamento di revisione secondario

Il componente aggiuntivo Istio consente di aggiornare la revisione secondaria usando il processo di aggiornamento canary. Quando si avvia un aggiornamento, il piano di controllo della nuova revisione (canary) viene distribuito insieme al piano di controllo della revisione precedente (stabile). È quindi possibile eseguire manualmente il rollover dei carichi di lavoro del piano dati usando gli strumenti di monitoraggio per tenere traccia dell'integrità dei carichi di lavoro durante il processo. Se non si riscontrano problemi con l'integrità dei carichi di lavoro, è possibile completare l'aggiornamento in modo che nel cluster venga mantenuta solo la nuova revisione. In caso contrario, è possibile eseguire il rollback alla revisione precedente di Istio.

Se il cluster usa attualmente una revisione secondaria supportata di Istio, gli aggiornamenti sono consentiti solo una revisione secondaria alla volta. Se il cluster usa una revisione non supportata di Istio, è necessario eseguire l'aggiornamento alla revisione secondaria supportata più bassa di Istio per tale versione di Kubernetes. Successivamente, è possibile eseguire nuovamente gli aggiornamenti una revisione secondaria alla volta.

Nell'esempio seguente viene illustrato come eseguire l'aggiornamento dalla revisione asm-1-20 alla asm-1-21. I passaggi sono gli stessi per tutti gli aggiornamenti secondari.

1. Usare il comando az aks mesh get-upgrades per verificare quali revisioni sono disponibili come destinazioni di aggiornamento per il cluster:

   az aks mesh get-upgrades --resource-group $RESOURCE_GROUP --name $CLUSTER
   

   Se si ritiene che la revisione visualizzata debba essere più recente di quella restituita da questo comando, potrebbe essere necessario aggiornare prima il cluster del servizio Azure Kubernetes in modo che sia compatibile con la revisione più recente.

2. Se è stata configurata laconfigurazione mesh per la revisione mesh esistente nel cluster, è necessario creare un ConfigMap separato corrispondente alla nuova revisione nello aks-istio-system spazio dei nomi prima di avviare l'aggiornamento canary nel passaggio successivo. Questa configurazione viene applicata al momento della distribuzione del piano di controllo della nuova revisione nel cluster. Per informazioni dettagliate, vedere questo articolo.

3. Avviare un aggiornamento canary dalla revisione asm-1-20 alla asm-1-21 usando az aks mesh upgrade start:

   az aks mesh upgrade start --resource-group $RESOURCE_GROUP --name $CLUSTER --revision asm-1-21
   

   Un aggiornamento canary indica che il piano di controllo 1.20 viene distribuito insieme al piano di controllo 1.21. I due piani di controllo continuano a coesistere finché non si completa l’aggiornamento o si esegue il rollback dell'aggiornamento.

4. Verificare che i pod del piano di controllo corrispondenti a asm-1-20 e asm-1-21 esistano:

   • Verificare i pod istiod:

     kubectl get pods -n aks-istio-system
     

     Output di esempio:

     NAME                                        READY   STATUS    RESTARTS   AGE
     istiod-asm-1-20-55fccf84c8-dbzlt            1/1     Running   0          58m
     istiod-asm-1-20-55fccf84c8-fg8zh            1/1     Running   0          58m
     istiod-asm-1-21-f85f46bf5-7rwg4             1/1     Running   0          51m
     istiod-asm-1-21-f85f46bf5-8p9qx             1/1     Running   0          51m
     

   • Se l'ingresso è abilitato, verificare i pod in ingresso:

     kubectl get pods -n aks-istio-ingress
     

     Output di esempio:

     NAME                                                          READY   STATUS    RESTARTS   AGE
     aks-istio-ingressgateway-external-asm-1-20-58f889f99d-qkvq2   1/1     Running   0          59m
     aks-istio-ingressgateway-external-asm-1-20-58f889f99d-vhtd5   1/1     Running   0          58m
     aks-istio-ingressgateway-external-asm-1-21-7466f77bb9-ft9c8   1/1     Running   0          51m
     aks-istio-ingressgateway-external-asm-1-21-7466f77bb9-wcb6s   1/1     Running   0          51m
     aks-istio-ingressgateway-internal-asm-1-20-579c5d8d4b-4cc2l   1/1     Running   0          58m
     aks-istio-ingressgateway-internal-asm-1-20-579c5d8d4b-jjc7m   1/1     Running   0          59m
     aks-istio-ingressgateway-internal-asm-1-21-757d9b5545-g89s4   1/1     Running   0          51m
     aks-istio-ingressgateway-internal-asm-1-21-757d9b5545-krq9w   1/1     Running   0          51m
     

     Si noti che i pod del gateway in ingresso di entrambe le revisioni vengono distribuiti in modalità affiancata. Tuttavia, il servizio e il relativo indirizzo IP rimangono invariati.

5. Etichettare nuovamente lo spazio dei nomi in modo che tutti i nuovi pod ottengano il sidecar Istio associato alla nuova revisione e al relativo piano di controllo:

   kubectl label namespace default istio.io/rev=asm-1-21 --overwrite
   

   L’applicazione di nuove etichette ha effetto sui carichi di lavoro solo dopo il riavvio.

6. Eseguire singolarmente il rollover di ognuno dei carichi di lavoro dell'applicazione riavviandoli. Ad esempio:

   kubectl rollout restart deployment <deployment name> -n <deployment namespace>
   

7. Controllare gli strumenti di monitoraggio e i dashboard per determinare se i carichi di lavoro sono tutti in esecuzione in uno stato integro dopo il riavvio. In base al risultato, sono disponibili due opzioni:

   • Completare l'aggiornamento canary: dopo essersi accertati che i carichi di lavoro sono tutti in esecuzione in uno stato integro, come previsto, è possibile completare l'aggiornamento canary. Il completamento dell'aggiornamento rimuove il piano di controllo della revisione precedente e lascia il piano di controllo della nuova revisione nel cluster. Eseguire il comando seguente per completare l'aggiornamento canary:

     az aks mesh upgrade complete --resource-group $RESOURCE_GROUP --name $CLUSTER
     

   • Eseguire il rollback dell'aggiornamento canary: nel caso in cui si riscontrino problemi relativi all'integrità dei carichi di lavoro, è possibile eseguire il rollback alla revisione precedente di Istio:

     • Etichettare nuovamente lo spazio dei nomi in base alla revisione precedente:

       kubectl label namespace default istio.io/rev=asm-1-20 --overwrite
       

     • Eseguire il rollback dei carichi di lavoro per usare il sidecar corrispondente alla revisione Istio precedente riavviando nuovamente i carichi di lavoro:

       kubectl rollout restart deployment <deployment name> -n <deployment namespace>
       

     • Eseguire il rollback del piano di controllo alla revisione precedente:

       az aks mesh upgrade rollback --resource-group $RESOURCE_GROUP --name $CLUSTER
       

8. Se la configurazione Mesh è stata configurata in precedenza per le revisioni, è ora possibile eliminare ConfigMap per la revisione che è stata rimossa dal cluster durante il completamento/ripristino dello stato precedente.

Aggiornamenti di revisioni secondarie con il gateway di ingresso

Se attualmente si usano gateway di ingresso Istio e si esegue un aggiornamento di revisione secondario, tenere presente che i pod/le distribuzioni del gateway in ingresso Istio vengono distribuiti per ogni revisione. Tuttavia, viene fornito un solo servizio LoadBalancer in tutti i pod del gateway in ingresso su più revisioni, quindi l'indirizzo IP esterno/interno dei gateway in ingresso non cambierà nel corso di un aggiornamento.

Pertanto, durante l'aggiornamento canary, quando due revisioni esistono contemporaneamente nel cluster, il traffico in ingresso verrà gestito dai pod del gateway in ingresso di entrambe le revisioni.

Aggiornamento della versione patch

• Le informazioni sulla disponibilità della versione patch del componente aggiuntivo Istio sono pubblicate nelle note sulla versione del servizio Azure Kubernetes.
• Le patch vengono implementate automaticamente per i pod istiod e in ingresso come parte di queste versioni del servizio Azure Kubernetes, che rispettano la finestra di manutenzione pianificata default configurata per il cluster.
• L'utente deve avviare le patch nei carichi di lavoro del proxy Istio riavviando i pod per la reiniezione:

  • Controllare la versione del proxy Istio destinata ai pod nuovi o riavviati. Questa versione è identica alla versione dei pod istiod e Istio in ingresso dopo l'applicazione di patch:

    kubectl get cm -n aks-istio-system -o yaml | grep "mcr.microsoft.com\/oss\/istio\/proxyv2"
    

    Output di esempio:

    "image": "mcr.microsoft.com/oss/istio/proxyv2:1.20.6-distroless",
    "image": "mcr.microsoft.com/oss/istio/proxyv2:1.20.6-distroless"
    

  • Controllare la versione dell'immagine proxy Istio per tutti i pod in uno spazio dei nomi:

    kubectl get pods --all-namespaces -o jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\
    sort |\
    grep "mcr.microsoft.com\/oss\/istio\/proxyv2"
    

    Output di esempio:

    productpage-v1-979d4d9fc-p4764:	docker.io/istio/examples-bookinfo-productpage-v1:1.20.0, mcr.microsoft.com/oss/istio/proxyv2:1.20.6-distroless
    

  • Per attivare la reiniezione, riavviare i carichi di lavoro. Ad esempio:

    kubectl rollout restart deployments/productpage-v1 -n default
    

  • Per verificare che siano ora installate le versioni più recenti, controllare di nuovo la versione dell'immagine proxy Istio per tutti i pod nello spazio dei nomi:

    kubectl get pods --all-namespaces -o jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\
    sort |\
    grep "mcr.microsoft.com\/oss\/istio\/proxyv2"
    

    Output di esempio:

    productpage-v1-979d4d9fc-p4764:	docker.io/istio/examples-bookinfo-productpage-v1:1.20.0, mcr.microsoft.com/oss/istio/proxyv2:1.20.7-distroless