Sdílet prostřednictvím


Upgrade doplňku Istio service mesh pro Azure Kubernetes Service

Tento článek se zabývá možnostmi upgradu doplňku Istio service mesh pro Službu Azure Kubernetes Service (AKS).

Oznámení o vydání nových dílčích revizí nebo oprav doplňku Istio service mesh se publikují v poznámkách k verzi AKS. Další informace o plánu vydávání verzí a podpoře revizí doplňků služby Mesh najdete v zásadách podpory.

Upgrade podverze

Doplněk Istio umožňuje upgrade dílčí revize pomocí kanárského procesu upgradu. Při zahájení upgradu se řídicí rovina nové (kanárové) revize nasadí spolu s řídicí rovinou počáteční (stabilní) revizní roviny revize. Úlohy roviny dat pak můžete ručně převést pomocí monitorovacích nástrojů ke sledování stavu úloh během tohoto procesu. Pokud se nezobrazí žádné problémy se stavem úloh, můžete upgrade dokončit, aby v clusteru zůstala jenom nová revize. Jinak se můžete vrátit k předchozí revizi Istio.

Pokud cluster aktuálně používá podporovanou dílčí revizi Istio, upgrady jsou povoleny pouze jednu dílčí revizi najednou. Pokud cluster používá nepodporovanou revizi Istio, musíte upgradovat na nejnižší podporovanou dílčí revizi Istio pro tuto verzi Kubernetes. Potom je možné upgrady znovu provést jednu dílčí revizi najednou.

Následující příklad ukazuje, jak upgradovat z revize asm-1-22 na asm-1-23 všechny úlohy v default oboru názvů. Postup je stejný pro všechny dílčí upgrady a může se použít pro libovolný počet oborů názvů.

  1. Pomocí příkazu az aks mesh get-upgrades zkontrolujte, které revize jsou pro cluster k dispozici jako cíle upgradu:

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

    Pokud očekáváte, že se v tomto příkazu nezobrazí novější revize, možná budete muset nejprve upgradovat cluster AKS tak, aby byl kompatibilní s nejnovější revizí.

  2. Pokud jste nastavili konfiguraci sítě pro existující revizi sítě v clusteru, musíte před zahájením kanárového upgradu v dalším kroku vytvořit samostatnou mapu ConfigMap odpovídající nové revizi v aks-istio-system oboru názvů. Tato konfigurace platí v okamžiku, kdy se v clusteru nasadí řídicí rovina nové revize. Další podrobnosti najdete tady.

  3. Zahájení kanárného upgradu z revize asm-1-22 na asm-1-23 spuštění upgradu az aks mesh:

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

    Kanárový upgrade znamená, že řídicí rovina 1.23 je nasazena spolu s řídicí rovinou 1.22. Budou dál existovat, dokud upgrade nedokončíte nebo nevrátíte zpět.

  4. Volitelně můžete značky revizí použít k vrácení roviny dat do nové revize, aniž by bylo nutné ručně ručně oznamovat jednotlivé obory názvů. Ruční opětovné označování oborů názvů při jejich přesunutí na novou revizi může být zdlouhavé a náchylné k chybám. Značky revizí tento problém řeší tím, že slouží jako stabilní identifikátory, které odkazují na revize.

    Místo opětovného označení každého oboru názvů může operátor clusteru změnit značku tak, aby odkazovat na novou revizi. Všechny obory názvů označené danou značkou se aktualizují současně. Přesto ale potřebujete restartovat úlohy, abyste měli jistotu, že se vloží správná verze istio-proxy sajdkár.

    Použití značek revizí během upgradu:

    1. Instalace rozhraní příkazového řádku istioctl

    2. Vytvořte značku revize pro počáteční revizi. V tomto příkladu ji prod-stablepojmenujeme:

      istioctl tag set prod-stable --revision asm-1-22 --istioNamespace aks-istio-system
      
    3. Vytvořte značku revize pro revizi nainstalovanou během upgradu. V tomto příkladu ji prod-canarypojmenujeme:

      istioctl tag set prod-canary --revision asm-1-23 --istioNamespace aks-istio-system
      
    4. Popisky oborů názvů aplikací pro mapování na značky revizí:

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

      Obory istio.io/rev=prod-canary názvů můžete také označovat pro novější revizi. Úlohy v těchto oborech názvů se ale neaktualizují na nový sajdkár, dokud se nerestartují.

      Pokud se po označení vytvoří nová aplikace v oboru názvů, vloží se sajdkárna odpovídající značce revize v daném oboru názvů.

  5. Ověřte pody řídicí roviny odpovídající oběma asm-1-22 a asm-1-23 existují:

    1. Ověření istiod podů:

      kubectl get pods -n aks-istio-system
      

      Příklad výstupu:

      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. Pokud je povolený příchozí přenos dat, ověřte pody příchozího přenosu dat:

      kubectl get pods -n aks-istio-ingress
      

      Příklad výstupu:

      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
      

      Všimněte si, že pody brány příchozího přenosu dat obou revizí se nasazují souběžně. Služba a její IP adresa ale zůstávají neměnné.

  6. Znovu oznamte obor názvů tak, aby se všechny nové pody mapovaly na sajdkára Istio přidružená k nové revizi a jeho řídicí rovině:

    1. Pokud používáte prod-stable značky revizí, přepište samotnou značku a změňte jeho mapování:

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

      Ověřte mapování značek na revizi:

      istioctl tag list
      

      Obě značky by měly odkazovat na nově nainstalovanou revizi:

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

      V takovém případě nemusíte jednotlivé obory názvů znovu oznamovat.

    2. Pokud nepoužíváte značky revizí, musí být obory názvů roviny dat znovu označeny, aby odkazovaly na novou revizi:

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

    Opětovné označování nemá vliv na vaše úlohy, dokud se nerestartují.

  7. Jednotlivé úlohy aplikace se převrácejí jednotlivě tak, že je restartuje. Příklad:

    kubectl rollout restart deployment <deployment name> -n <deployment namespace>
    
  8. Zkontrolujte monitorovací nástroje a řídicí panely a zjistěte, jestli jsou vaše úlohy spuštěné v dobrém stavu po restartování. Na základě výsledku máte dvě možnosti:

    1. Dokončete kanárný upgrade: Pokud jste spokojeni s tím, že všechny úlohy běží v dobrém stavu podle očekávání, můžete dokončit kanárný upgrade. Dokončení upgradu odebere řídicí rovinu předchozí revize a ponechá řídicí rovinu nové revize v clusteru. Spuštěním následujícího příkazu dokončete kanárný upgrade:

      az aks mesh upgrade complete --resource-group $RESOURCE_GROUP --name $CLUSTER
      
    2. Vrácení zpět kanárného upgradu: V případě, že zaznamenáte problémy se stavem úloh, můžete se vrátit k předchozí revizi Istio:

    • Znovu označte obor názvů k předchozí revizi: Pokud používáte značky revizí:

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

      Nebo pokud nepoužíváte značky revizí:

      kubectl label namespace default istio.io/rev=asm-1-22 --overwrite
      
    • Vrácením úloh zpět použijte sajdkár odpovídající předchozí revizi Istio opětovným restartováním těchto úloh:

      kubectl rollout restart deployment <deployment name> -n <deployment namespace>
      
    • Vrácení řídicí roviny zpět na předchozí revizi:

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

    Značku prod-canary revize je možné odebrat:

    istioctl tag remove prod-canary --istioNamespace aks-istio-system 
    
  9. Pokud byla konfigurace sítě dříve nastavená pro revize, můžete nyní odstranit objekt ConfigMap pro revizi, která byla odebrána z clusteru během dokončení nebo vrácení zpět.

Menší upgrady revizí s bránou příchozího přenosu dat

Pokud aktuálně používáte brány příchozího přenosu dat Istio a provádíte menší upgrade revizí, mějte na paměti, že pody nebo nasazení brány příchozího přenosu dat Istio se nasazují podle revize. Poskytujeme ale jednu službu LoadBalancer napříč všemi pody brány příchozího přenosu dat v rámci několika revizí, takže externí/interní IP adresa bran příchozího přenosu dat se během upgradu nezmění.

Při kanárním upgradu tedy v případě, že v clusteru existují dvě revize současně, pody příchozí brány obou revizí obsluhují příchozí provoz.

Menší upgrady revizí s horizontálním automatickým škálováním podů

Pokud jste přizpůsobili nastavení horizontálního automatického škálování podů (HPA) pro istiod nebo brány příchozího přenosu dat, mějte na paměti následující chování, jak se nastavení HPA používá v obou revizích, aby se zachovala konzistence během kanárného upgradu:

  • Pokud před zahájením upgradu aktualizujete specifikaci HPA, použijí se nastavení z existující (stabilní) revize pro hpa kanárské revize při instalaci nové řídicí roviny.
  • Pokud aktualizujete specifikaci HPA v době, kdy probíhá kanárný upgrade, bude mít přednost specifikace HPA stabilní revize a použije se pro hpa kanárské revize.
    • Pokud aktualizujete HPA stabilní revize během upgradu, aktualizuje se specifikace HPA kanárské revize tak, aby odrážela nová nastavení použitá pro stabilní revizi.
    • Pokud aktualizujete hpA kanárské revize během upgradu, specifikace HPA kanárské revize se vrátí ke specifikaci HPA stabilní revize.

Upgrade verze opravy

  • Informace o dostupnosti verze doplňku Istio se publikuje ve zprávě k vydání verze AKS.
  • Opravy se automaticky nasadí pro pody istiod a ingress v rámci těchto verzí AKS, které respektují default časové období plánované údržby nastavené pro cluster.
  • Uživatel musí ve svých úlohách inicializovat opravy proxy serveru Istio restartováním podů pro opětovnou instalaci:
    • Zkontrolujte verzi proxy serveru Istio určeného pro nové nebo restartované pody. Tato verze je stejná jako verze podů istiod a Istio ingress po jejich opravě:

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

      Příklad výstupu:

      "image": "mcr.microsoft.com/oss/istio/proxyv2:1.22.0-distroless",
      "image": "mcr.microsoft.com/oss/istio/proxyv2:1.22.0-distroless"
      
    • Zkontrolujte verzi image proxy istio pro všechny pody v oboru názvů:

      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"
      

      Příklad výstupu:

      productpage-v1-979d4d9fc-p4764:	docker.io/istio/examples-bookinfo-productpage-v1:1.22.0, mcr.microsoft.com/oss/istio/proxyv2:1.22.0-distroless
      
    • Pokud chcete aktivovat opětovné spuštění, restartujte úlohy. Příklad:

      kubectl rollout restart deployments/productpage-v1 -n default
      
    • Pokud chcete ověřit, že jsou teď v novějších verzích, zkontrolujte znovu verzi image proxy istio pro všechny pody v oboru názvů:

      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"
      

      Příklad výstupu:

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

Poznámka:

V případě jakýchkoli problémů, ke kterým došlo během upgradů, najdete v článku o řešení potíží s upgrady revizí sítě.