Share via

Uppgradera Istio-baserat service mesh-tillägg för Azure Kubernetes Service

  • Artikel

Den här artikeln beskriver uppgraderingsupplevelser för Istio-baserat service mesh-tillägg för Azure Kubernetes Service (AKS).

Meddelanden om versioner av nya mindre revisioner eller korrigeringar av det Istio-baserade service mesh-tillägget publiceras i AKS-viktig information.

Mindre revisionsuppgradering

Med Istio-tillägget kan du uppgradera den mindre revisionen med hjälp av en kanarieuppgraderingsprocess. När en uppgradering initieras distribueras kontrollplanet för den nya (kanarie) revisionen tillsammans med den gamla (stabila) revisionens kontrollplan. Du kan sedan manuellt rulla över dataplansarbetsbelastningar när du använder övervakningsverktyg för att spåra hälsotillståndet för arbetsbelastningar under den här processen. Om du inte ser några problem med hälsotillståndet för dina arbetsbelastningar kan du slutföra uppgraderingen så att endast den nya revisionen finns kvar i klustret. Annars kan du återställa till den tidigare revisionen av Istio.

Om klustret för närvarande använder en mindre version som stöds av Istio tillåts uppgraderingar endast en mindre revision i taget. Om klustret använder en revision som inte stöds av Istio måste du uppgradera till den lägsta mindre versionen av Istio som stöds för kubernetes-versionen. Därefter kan uppgraderingar återigen göras en mindre revision i taget.

I följande exempel visas hur du uppgraderar från revision asm-1-18 till asm-1-19. Stegen är desamma för alla mindre uppgraderingar.

  1. Använd kommandot az aks mesh get-upgrades för att kontrollera vilka revisioner som är tillgängliga för klustret som uppgraderingsmål:

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

    Om du förväntar dig att en nyare revision inte returneras av det här kommandot kan du behöva uppgradera AKS-klustret först så att det är kompatibelt med den senaste revisionen.

  2. Om du har konfigurerat mesh-konfiguration för den befintliga mesh-revisionen i klustret måste du skapa en separat ConfigMap som motsvarar den nya revisionen aks-istio-system i namnområdet innan du påbörjar kanarieuppgraderingen i nästa steg. Den här konfigurationen gäller när den nya revisionens kontrollplan distribueras i klustret. Mer information finns här.

  3. Starta en kanarieuppgradering från revision asm-1-18 till att använda az aks mesh upgrade startasm-1-19:

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

    En kanarieuppgradering innebär att kontrollplanet 1.18 distribueras tillsammans med kontrollplanet 1.17. De fortsätter att samexistera tills du antingen slutför eller återställer uppgraderingen.

  4. Verifiera kontrollplanspoddar som motsvarar båda asm-1-18 och asm-1-19 finns:

    • Verifiera istiod poddar:

      kubectl get pods -n aks-istio-system

      Exempel på utdata>

      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

    • Om ingress är aktiverat kontrollerar du inkommande poddar:

      kubectl get pods -n aks-istio-ingress

      Exempel på utdata>

      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

      Observera att ingressgatewaypoddar för båda revisionerna distribueras sida vid sida. Tjänsten och dess IP-adress är dock oföränderliga.

  5. Ange namnområdet igen så att alla nya poddar får den Istio-sidovagn som är associerad med den nya revisionen och dess kontrollplan:

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

    Ommärkning påverkar inte dina arbetsbelastningar förrän de startas om.

  6. Rulla över var och en av dina programarbetsbelastningar individuellt genom att starta om dem. Till exempel:

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

  7. Kontrollera dina övervakningsverktyg och instrumentpaneler för att avgöra om alla dina arbetsbelastningar körs i felfritt tillstånd efter omstarten. Baserat på resultatet har du två alternativ:

    • Slutför canary-uppgraderingen: Om du är nöjd med att alla arbetsbelastningar körs i felfritt tillstånd som förväntat kan du slutföra canary-uppgraderingen. Slutförandet av uppgraderingen tar bort den tidigare revisionens kontrollplan och lämnar kvar den nya revisionens kontrollplan i klustret. Kör följande kommando för att slutföra canary-uppgraderingen:

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

    • Återställ canary-uppgraderingen: Om du upptäcker några problem med hälsotillståndet för dina arbetsbelastningar kan du återställa till den tidigare revisionen av Istio:

      • Ange namnområdet på nytt till föregående revision:

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

      • Återställ arbetsbelastningarna för att använda sidovagnen som motsvarar föregående Istio-revision genom att starta om dessa arbetsbelastningar igen:

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

      • Återställ kontrollplanet till föregående revision:

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

  8. Om mesh-konfigurationen tidigare har konfigurerats för revisionerna kan du nu ta bort ConfigMap för revisionen som togs bort från klustret under fullständig/återställning.

Kommentar

Manuellt ommärkning av namnområden när du flyttar dem till en ny revision kan vara omständligt och felbenäget. Revisionstaggar löser det här problemet. Revisionstaggar är stabila identifierare som pekar på revisioner och kan användas för att undvika ommärkning av namnområden. I stället för att märka om namnområdet kan en nätoperator helt enkelt ändra taggen så att den pekar på en ny revision. Alla namnområden som är märkta med taggen uppdateras samtidigt. Observera dock att du fortfarande måste starta om arbetsbelastningarna för att se till att rätt version av istio-proxy sidovagnar matas in.

Mindre revisionsuppgraderingar med ingressgatewayen

Om du för närvarande använder Istio-ingressgatewayer och utför en mindre revisionsuppgradering bör du tänka på att Istio-ingressgatewaypoddar/-distributioner distribueras per revision. Vi tillhandahåller dock en enda LoadBalancer-tjänst för alla ingressgatewaypoddar över flera revisioner, så den externa/interna IP-adressen för ingressgatewayerna ändras inte under en uppgradering.

Under canary-uppgraderingen, när två revisioner finns samtidigt i klustret, hanteras inkommande trafik av ingressgatewaypoddarna för båda revisionerna.

Uppdateringsversionsuppgradering

  • Information om tillgänglighet för Istio-tilläggsversionen publiceras i AKS-viktig information.
  • Korrigeringar distribueras automatiskt för istiod- och ingresspoddar som en del av dessa AKS-versioner, som respekterar det defaultplanerade underhållsfönstret som har konfigurerats för klustret.
  • Användaren måste initiera korrigeringar till Istio-proxyn i sina arbetsbelastningar genom att starta om poddarna för omjektion:

    • Kontrollera versionen av Istio-proxyn som är avsedd för nya eller omstartade poddar. Den här versionen är samma som versionen av istiod- och Istio-ingresspoddarna efter att de har korrigerats:

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

      Exempel på utdata>

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

    • Kontrollera avbildningsversionen av Istio-proxyn för alla poddar i ett namnområde:

      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"

      Exempel på utdata>

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

    • Starta om arbetsbelastningarna för att utlösa omjektion. Till exempel:

      kubectl rollout restart deployments/productpage-v1 -n default

    • Kontrollera att de nu finns i de nyare versionerna genom att kontrollera istio proxy-avbildningsversionen igen för alla poddar i namnområdet:

      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"

      Exempel på utdata:

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