Upgrade rozšíření Istio síťové služby 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.

Dílčí revize upgrade

Doplněk Istio umožňuje upgrade dílčí revize pomocí procesu kanárského upgradu. Při zahájení upgradu se řídicí rovina nové (kanárové) revize nasadí spolu s řídicí rovinou počáteční (stabilní) revize. Poté můžete ručně převádět úlohy v datové rovině a současně používat monitorovací nástroje ke sledování jejich stavu 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.

Dostupné upgrady závisí na tom, jestli se podporuje aktuální revize Istio a verze clusteru AKS:

  • Můžete upgradovat na další podporovanou revizi (n+1) nebo přeskočit jednu a upgradovat na n+2, pokud jsou obě podporované a kompatibilní s verzí clusteru.
  • Pokud vaše aktuální revize () i další revize (nn+1) nejsou podporovány, můžete upgradovat pouze na nejbližší podporovanou revizi (n+2nebo vyšší), ale ne nad ní.
  • Pokud verze clusteru i revize Istio nejsou podporovány, musí být verze clusteru upgradována před zahájením upgradu Istio.

Poznámka:

Jakmile revize verze nebo sítě AKS spadá mimo okno podpory, upgrade obou verzí se stane náchylným k chybám. I když se tyto upgrady mohou aktualizovat na podporovanou verzi, Microsoft nepodporuje ani proces upgradu, ani samotné verze, které nejsou podporovány. Důrazně doporučujeme udržovat verzi AKS a revizi sítě aktuální, aby nedocházelo k nepodporovaným scénářům. V kalendáři podpory doplňků Istio najdete předpokládaná data vydání a ukončení podpory a upstream oznámení k nové verzi Istio naznačující významné změny.

Následující příklad ukazuje, jak upgradovat z revize asm-1-23 na asm-1-24 se všemi pracovními zátěžemi v oboru názvů default. Postup je stejný pro všechny dílčí upgrady a lze použít pro libovolný počet jmenných prostorů.

  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ájit kanárský upgrade z revize asm-1-23 na asm-1-24 použitím příkazu az aks mesh upgrade start:

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

    Kanárový upgrade znamená, že řídicí rovina 1.24 je nasazena paralelně s řídicí rovinou 1.23. Budou nadále koexistovat, dokud upgrade nedokončíte nebo nevrátíte zpět.

    I když probíhá kanárný upgrade, vyšší revize se považuje za výchozí revizi použitou k ověření prostředků Istio.

  4. Volitelně můžete revizní značky použít k přepnutí datové roviny do nové revize, aniž byste museli ručně přeznačit jednotlivé jmenné prostory. Ruční přejmenovává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 odkazovala na novou revizi. Všechny obory názvů označené danou značkou se aktualizují současně. Přesto musíte restartovat úlohy, abyste měli jistotu, že se injektuje správná verze istio-proxy postranních modulů.

    Jak použít značky revizí během upgradu:

    1. Nainstalujte příkazové rozhraní 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-23 --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-24 --istioNamespace aks-istio-system

    4. Popište jmenné prostory aplikací k mapování na revizní značky.

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

      Jmenné prostory můžete také označit s istio.io/rev=prod-canary pro novější revizi. Úlohy v těchto oborech názvů nejsou však aktualizovány na nový sidecar, dokud nejsou restartovány.

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

  5. Ověřte, že pody řídicí roviny pro asm-1-23 a asm-1-24 existují.

    1. Ověřit istiod pody

      kubectl get pods -n aks-istio-system

      Příklad výstupu:

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

    2. Pokud je povolený Ingress, ověřte Ingress pody.

      kubectl get pods -n aks-istio-ingress

      Příklad výstupu:

      NAME                                                          READY   STATUS    RESTARTS   AGE
aks-istio-ingressgateway-external-asm-1-23-58f889f99d-qkvq2   1/1     Running   0          59m
aks-istio-ingressgateway-external-asm-1-23-58f889f99d-vhtd5   1/1     Running   0          58m
aks-istio-ingressgateway-external-asm-1-24-7466f77bb9-ft9c8   1/1     Running   0          51m
aks-istio-ingressgateway-external-asm-1-24-7466f77bb9-wcb6s   1/1     Running   0          51m
aks-istio-ingressgateway-internal-asm-1-23-579c5d8d4b-4cc2l   1/1     Running   0          58m
aks-istio-ingressgateway-internal-asm-1-23-579c5d8d4b-jjc7m   1/1     Running   0          59m
aks-istio-ingressgateway-internal-asm-1-24-757d9b5545-g89s4   1/1     Running   0          51m
aks-istio-ingressgateway-internal-asm-1-24-757d9b5545-krq9w   1/1     Running   0          51m

      Sledujte, že pody vstupní brány pro obě revize jsou nasazeny vedle sebe. Služba a její IP adresa ale zůstávají neměnné.

  6. Přejmenujte obor názvů tak, aby se všechny nové pody mapovaly na Istio sidecar přidružený k nové revizi a její řídicí rovině.

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

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

      Ověřte mapování značek a revizí:

      istioctl tag list

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

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

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

    Přejmenování nemá vliv na vaše pracovní zátěže, dokud se nerestartují.

  7. Individuálně restartujte každou z úloh vaší aplikace. Příklad:

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

  8. Zkontrolujte monitorovací nástroje a ovládací panely a zjistěte, zda vaše úlohy běží v pořádku po restartu. Na základě výsledku máte dvě možnosti:

    1. Dokončete testovací upgrady: Pokud jste spokojeni s tím, že všechna zatížení běží tak zdravě, jak se očekává, můžete dokončit testovací upgrady. 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átit kanárkovou aktualizaci zpět: Pokud zaznamenáte jakékoli problémy se stavem vašich pracovních úloh, můžete se vrátit k předchozí verzi Istio.

    • Přejmenujte jmenný prostor na předchozí revizi: Pokud používáte revizní značky:

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

      Nebo, pokud nepoužíváte značky revize,

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

    • Vrátit úlohy zpět, aby používaly sidecar 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átit řídicí rovinu na předchozí verzi revize:

      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 mesh dříve nastavená pro revize, můžete nyní odstranit objekt ConfigMap pro revizi, která byla odebrána z clusteru během dokončení nebo zpětného přechodu.

Menší upgrady revize s vstupními a výstupními bránami

Pokud aktuálně používáte příchozí brány Istio nebo výstupní brány Istio a provádíte menší upgrade revize, mějte na paměti, že pody a nasazení příchozích a výstupních bran Istio se nasazují dle revize, ale služba je sdílena napříč oběma revizemi.

Poskytujeme jednu LoadBalancer službu 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, když v clusteru existují současně dvě revize, pody ingress gateway obou jednotlivých revizí zpracovávají příchozí síťový provoz.

Stejně tak během pokusného (kanárového) upgradu bude všechny pody pro výstupní bránu napříč oběma verzemi obsluhovat jedna ClusterIP služba.

Menší revize s automatickým horizontální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 vstupní brány, 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árského upgradu.

  • Pokud před zahájením upgradu aktualizujete specifikaci HPA, budou nastavení z existující (stabilní) revize použita pro HPA kanárové verze při instalaci nové řídicí roviny.
  • Pokud aktualizujete specifikaci HPA při probíhajícím kanárském upgradu, 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 během upgradu aktualizujete HPA kanárské revize, nastavení HPA kanárské revize bude vráceno na nastavení HPA stabilní revize.

Aktualizace verze opravy

  • Informace o dostupnosti verze doplňku Istio je publikována v poznámkách k vydání AKS.
  • Záplaty jsou automaticky nasazovány na istiod a ingressové pody jako součást těchto vydání AKS, které respektují defaultplánované údržbové okno 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.23.0-distroless",
"image": "mcr.microsoft.com/oss/istio/proxyv2:1.23.0-distroless"

    • Zkontrolujte verzi obrazu proxy Istio pro všechny pody v namespace:

      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.23.0, mcr.microsoft.com/oss/istio/proxyv2:1.23.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ď na novějších verzích, zkontrolujte znovu verzi image Istio proxy pro všechny pody v rámci 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.24.0-distroless

Poznámka:

V případě jakýchkoli problémů během aktualizací podívejte se na článek o řešení potíží s aktualizacemi revizí sítě.

  • Last updated on