Condividi tramite

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

  • Articolo

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 sulla pianificazione delle versioni e sul supporto per le revisioni dei componenti aggiuntivi mesh di servizi, 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 viene avviato un aggiornamento, il piano di controllo della nuova revisione (canary) viene distribuito insieme al piano di controllo iniziale (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-22 a asm-1-23 con tutti i carichi di lavoro nello spazio dei default nomi . I passaggi sono gli stessi per tutti gli aggiornamenti secondari e possono essere usati per un numero qualsiasi di spazi dei nomi.

  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 si configura la configurazione 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-22 alla asm-1-23 usando az aks mesh upgrade start:

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

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

  4. Facoltativamente, i tag di revisione possono essere usati per eseguire il rollover del piano dati alla nuova revisione senza dover riassegnare manualmente l'etichetta a ogni spazio dei nomi. La nuova etichettatura manuale degli spazi dei nomi al momento del loro spostamento in una revisione può essere noiosa e soggetta a errori. I tag di revisione risolveranno questo problema fungendo da identificatori stabili che puntano alle revisioni.

    Invece di rilabare ogni spazio dei nomi, un operatore del cluster può modificare il tag in modo che punti a una nuova revisione. Tutti gli spazi dei nomi etichettati con tale tag vengono aggiornati contemporaneamente. Tuttavia, è comunque necessario riavviare i carichi di lavoro per assicurarsi che venga inserita la versione corretta dei istio-proxy sidecar.

    Per usare i tag di revisione durante un aggiornamento:

    1. Installare l'interfaccia della riga di comando istioctl

    2. Creare un tag di revisione per la revisione iniziale. In questo esempio viene assegnato il prod-stablenome :

      istioctl tag set prod-stable --revision asm-1-22 --istioNamespace aks-istio-system

    3. Creare un tag di revisione per la revisione installata durante l'aggiornamento. In questo esempio viene assegnato il prod-canarynome :

      istioctl tag set prod-canary --revision asm-1-23 --istioNamespace aks-istio-system

    4. Etichettare gli spazi dei nomi dell'applicazione per eseguire il mapping ai tag di revisione:

      # label default namespace to map to asm-1-22
kubectl label ns default istio.io/rev=prod-stable --overwrite

      È anche possibile etichettare gli spazi dei nomi con istio.io/rev=prod-canary per la revisione più recente. Tuttavia, i carichi di lavoro in tali spazi dei nomi non vengono aggiornati a un nuovo sidecar fino a quando non vengono riavviati.

      Se una nuova applicazione viene creata in uno spazio dei nomi dopo l'etichetta, verrà inserito un sidecar corrispondente al tag di revisione nello spazio dei nomi.

  5. Verificare che i pod del piano di controllo corrispondenti a asm-1-22 e asm-1-23 esistano:

    1. Verificare i pod istiod:

      kubectl get pods -n aks-istio-system

      Output di esempio:

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

    2. 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-22-58f889f99d-qkvq2   1/1     Running   0          59m
aks-istio-ingressgateway-external-asm-1-22-58f889f99d-vhtd5   1/1     Running   0          58m
aks-istio-ingressgateway-external-asm-1-23-7466f77bb9-ft9c8   1/1     Running   0          51m
aks-istio-ingressgateway-external-asm-1-23-7466f77bb9-wcb6s   1/1     Running   0          51m
aks-istio-ingressgateway-internal-asm-1-22-579c5d8d4b-4cc2l   1/1     Running   0          58m
aks-istio-ingressgateway-internal-asm-1-22-579c5d8d4b-jjc7m   1/1     Running   0          59m
aks-istio-ingressgateway-internal-asm-1-23-757d9b5545-g89s4   1/1     Running   0          51m
aks-istio-ingressgateway-internal-asm-1-23-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.

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

    1. Se si usano tag di revisione, sovrascrivere il tag stesso per modificarne il prod-stable mapping:

      istioctl tag set prod-stable --revision asm-1-23 --istioNamespace aks-istio-system --overwrite

      Verificare i mapping da tag a revisione:

      istioctl tag list

      Entrambi i tag devono puntare alla revisione appena installata:

      TAG           REVISION   NAMESPACES
prod-canary   asm-1-23   default
prod-stable   asm-1-23   ...

      In questo caso, non è necessario etichettare di nuovo ogni spazio dei nomi singolarmente.

    2. Se non si usano tag di revisione, gli spazi dei nomi del piano dati devono essere etichettati per puntare alla nuova revisione:

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

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

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

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

  8. 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:

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

    2. 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 alla revisione precedente: se si usano tag di revisione:

      istioctl tag set prod-stable --revision asm-1-22 --istioNamespace aks-istio-system --overwrite

      In alternativa, se non si usano tag di revisione:

      kubectl label namespace default istio.io/rev=asm-1-22 --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

    Il prod-canary tag di revisione può essere rimosso:

    istioctl tag remove prod-canary --istioNamespace aks-istio-system

  9. 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 singolo servizio LoadBalancer in tutti i pod del gateway in ingresso su più revisioni, quindi l'indirizzo IP esterno/interno dei gateway di ingresso rimane invariato durante il corso di un aggiornamento.

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

Aggiornamenti di revisione secondari con personalizzazioni di scalabilità automatica orizzontale dei pod

Se sono state personalizzate le impostazioni di scalabilità automatica orizzontale dei pod per Istiod o i gateway di ingresso, tenere presente il comportamento seguente per l'applicazione delle impostazioni HPA in entrambe le revisioni per mantenere la coerenza durante un aggiornamento canary:

  • Se si aggiorna la specifica HPA prima di avviare un aggiornamento, le impostazioni della revisione esistente (stabile) verranno applicate agli HPA della revisione canary quando viene installato il nuovo piano di controllo.
  • Se si aggiorna la specifica HPA mentre è in corso un aggiornamento canary, la specifica HPA della revisione stabile avrà la precedenza e verrà applicata all'HPA della revisione canary.
    • Se si aggiorna l'HPA della revisione stabile durante un aggiornamento, la specifica HPA della revisione canary verrà aggiornata in modo da riflettere le nuove impostazioni applicate alla revisione stabile.
    • Se si aggiorna l'HPA della revisione canary durante un aggiornamento, la specifica HPA della revisione canary verrà ripristinata alla specifica HPA della revisione stabile.

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.22.0-distroless",
"image": "mcr.microsoft.com/oss/istio/proxyv2:1.22.0-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.22.0, mcr.microsoft.com/oss/istio/proxyv2:1.22.0-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.2.0, mcr.microsoft.com/oss/istio/proxyv2:1.22.0-distroless

Nota

In caso di problemi riscontrati durante gli aggiornamenti, vedere l'articolo sulla risoluzione dei problemi relativi agli aggiornamenti delle revisioni Mesh