Läs på engelska

Dela via


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

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. Om du vill veta mer om versionsschemat och stödet för tilläggsrevisioner för Service Mesh läser du supportprincipen.

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 inledande (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-22 till asm-1-23 med alla arbetsbelastningar i default namnområdet. Stegen är desamma för alla mindre uppgraderingar och kan användas för valfritt antal namnområden.

  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 konfigurerar 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-22 till att använda az aks mesh upgrade startasm-1-23:

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

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

  4. Alternativt kan revisionstaggar användas för att rulla över dataplanet till den nya revisionen utan att behöva ange varje namnområde manuellt. 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 genom att fungera som stabila identifierare som pekar på revisioner.

    I stället för att märka om varje namnområde kan en klusteroperator ändra taggen så att den pekar på en ny revision. Alla namnområden som är märkta med taggen uppdateras samtidigt. Du måste dock fortfarande starta om arbetsbelastningarna för att se till att rätt version av istio-proxy sidovagnar matas in.

    Så här använder du revisionstaggar under en uppgradering:

    1. Installera istioctl CLI

    2. Skapa en revisionstagg för den första revisionen. I det här exemplet namnger vi det prod-stable:

      istioctl tag set prod-stable --revision asm-1-22 --istioNamespace aks-istio-system
      
    3. Skapa en revisionstagg för revisionen som installerades under uppgraderingen. I det här exemplet namnger vi det prod-canary:

      istioctl tag set prod-canary --revision asm-1-23 --istioNamespace aks-istio-system
      
    4. Etikettera programnamnområden som ska mappas till revisionstaggar:

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

      Du kan också märka namnområden med istio.io/rev=prod-canary för den nyare revisionen. Arbetsbelastningarna i dessa namnområden uppdateras dock inte till en ny sidovagn förrän de startas om.

      Om ett nytt program skapas i ett namnområde efter att det har etiketterats matas en sidovagn in som motsvarar revisionstaggen i namnområdet.

  5. Verifiera kontrollplanspoddar som motsvarar båda asm-1-22 och asm-1-23 finns:

    1. Verifiera istiod poddar:

      kubectl get pods -n aks-istio-system
      

      Exempel på utdata>

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

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

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

    1. Om du använder revisionstaggar skriver du över själva taggen prod-stable för att ändra dess mappning:

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

      Kontrollera tagg-till-revision-mappningarna:

      istioctl tag list
      

      Båda taggarna bör peka på den nyligen installerade revisionen:

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

      I det här fallet behöver du inte ange varje namnområde individuellt.

    2. Om du inte använder revisionstaggar måste dataplanets namnområden märkas om för att peka på den nya revisionen:

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

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

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

    1. 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
      
    2. Å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: Om du använder revisionstaggar:

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

      Eller om du inte använder revisionstaggar:

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

    Revisionstaggen prod-canary kan tas bort:

    istioctl tag remove prod-canary --istioNamespace aks-istio-system 
    
  9. 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.

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 förblir oförändrad under en uppgradering.

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

Mindre revisionsuppgraderingar med horisontella anpassningar av automatisk skalning av poddar

Om du har anpassade hpa-inställningar (horizontal pod autoscaling) för Istiod eller ingressgatewayerna bör du tänka på följande beteende för hur HPA-inställningar tillämpas i båda revisionerna för att upprätthålla konsekvens under en kanarieuppgradering:

  • Om du uppdaterar HPA-specifikationen innan du påbörjar en uppgradering tillämpas inställningarna från den befintliga (stabila) revisionen på HPA:erna för kanarierevisionen när det nya kontrollplanet installeras.
  • Om du uppdaterar HPA-specifikationen medan en kanarieuppgradering pågår har HPA-specifikationen för den stabila revisionen företräde och tillämpas på HPA för kanarierevisionen.
    • Om du uppdaterar HPA för den stabila revisionen under en uppgradering uppdateras HPA-specifikationen för kanarierevisionen för att återspegla de nya inställningarna som tillämpas på den stabila revisionen.
    • Om du uppdaterar HPA för kanarierevisionen under en uppgradering återställs HPA-specifikationen för kanarierevisionen till HPA-specifikationen för den stabila revisionen.

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

Anteckning

Om det uppstår problem under uppgraderingar kan du läsa artikeln om felsökning av mesh-revisionsuppgraderingar