Share via

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 Mesh di servizi basato su Istio per servizio Azure Kubernetes (servizio Azure Kubernetes).

Gli annunci sulle versioni delle nuove revisioni secondarie o delle patch per il componente aggiuntivo Mesh di servizi basati su Istio vengono pubblicati nelle note sulla versione del servizio Azure Kubernetes.

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 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 questo processo. Se non si osservano problemi con l'integrità dei carichi di lavoro, è possibile completare l'aggiornamento in modo che solo la nuova revisione rimanga nel cluster. 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, gli aggiornamenti possono essere eseguiti di nuovo una revisione secondaria alla volta.

Nell'esempio seguente viene illustrato come eseguire l'aggiornamento da revisione asm-1-18 a asm-1-19. 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 per il cluster come destinazioni di aggiornamento:

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

    Se si prevede di visualizzare una revisione più recente non 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 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 è applicabile 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-18 all'uso asm-1-19 di az aks mesh upgrade start:

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

    Un aggiornamento canary indica che il piano di controllo 1.18 viene distribuito insieme al piano di controllo 1.17. Continuano a coesistere finché non si completa o si esegue il rollback dell'aggiornamento.

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

    • Verificare istiod i pod:

      kubectl get pods -n aks-istio-system

      Output di esempio:

      NAME                                        READY   STATUS    RESTARTS   AGE
istiod-asm-1-18-55fccf84c8-dbzlt            1/1     Running   0          58m
istiod-asm-1-18-55fccf84c8-fg8zh            1/1     Running   0          58m
istiod-asm-1-19-f85f46bf5-7rwg4             1/1     Running   0          51m
istiod-asm-1-19-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-18-58f889f99d-qkvq2   1/1     Running   0          59m
aks-istio-ingressgateway-external-asm-1-18-58f889f99d-vhtd5   1/1     Running   0          58m
aks-istio-ingressgateway-external-asm-1-19-7466f77bb9-ft9c8   1/1     Running   0          51m
aks-istio-ingressgateway-external-asm-1-19-7466f77bb9-wcb6s   1/1     Running   0          51m
aks-istio-ingressgateway-internal-asm-1-18-579c5d8d4b-4cc2l   1/1     Running   0          58m
aks-istio-ingressgateway-internal-asm-1-18-579c5d8d4b-jjc7m   1/1     Running   0          59m
aks-istio-ingressgateway-internal-asm-1-19-757d9b5545-g89s4   1/1     Running   0          51m
aks-istio-ingressgateway-internal-asm-1-19-757d9b5545-krq9w   1/1     Running   0          51m

      Si noti che i pod del gateway in ingresso di entrambe le revisioni vengono distribuiti side-by-side. Tuttavia, il servizio e il relativo INDIRIZZO IP rimangono non modificabili.

  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-19 --overwrite

    La rilabazione non influisce sui carichi di lavoro fino al 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: se si è soddisfatti che i carichi di lavoro siano 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 dietro 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 osservino problemi relativi all'integrità dei carichi di lavoro, è possibile eseguire il rollback alla revisione precedente di Istio:

      • Etichettare nuovamente lo spazio dei nomi con la revisione precedente:

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

      • Eseguire il rollback dei carichi di lavoro per usare il sidecar corrispondente alla revisione Istio precedente riavviando di nuovo questi 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/rollback.

Nota

La rilabazione manuale degli spazi dei nomi quando vengono spostati in una nuova revisione può essere noiosa e soggetta a errori. I tag di revisione risolveranno questo problema. I tag di revisione sono identificatori stabili che puntano alle revisioni e possono essere usati per evitare la rilabazione degli spazi dei nomi. Invece di rilabare lo spazio dei nomi, un operatore mesh può semplicemente modificare il tag in modo che punti a una nuova revisione. Tutti gli spazi dei nomi etichettati con tale tag verranno aggiornati contemporaneamente. Si noti tuttavia che è comunque necessario riavviare i carichi di lavoro per assicurarsi che venga inserita la versione corretta dei istio-proxy sidecar.

Aggiornamenti di revisione secondari 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/distribuzioni del gateway in ingresso Istio vengono distribuiti per 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 non cambierà durante il 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 del componente aggiuntivo Istio patch vengono 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 defaultfinestra di manutenzione pianificata configurata per il cluster.
  • L'utente deve avviare patch al proxy Istio nei carichi di lavoro riavviando i pod per la reiniiezione:

    • 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.18.2-distroless",
"image": "mcr.microsoft.com/oss/istio/proxyv2:1.18.2-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.18.0, mcr.microsoft.com/oss/istio/proxyv2:1.18.1-distroless

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

      kubectl rollout restart deployments/productpage-v1 -n default

    • Per verificare che siano ora disponibili nelle 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.18.0, mcr.microsoft.com/oss/istio/proxyv2:1.18.2-distroless