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ů.
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í.
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.Zahájení kanárného upgradu z revize
asm-1-22
naasm-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.
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:
Vytvořte značku revize pro počáteční revizi. V tomto příkladu ji
prod-stable
pojmenujeme:istioctl tag set prod-stable --revision asm-1-22 --istioNamespace aks-istio-system
Vytvořte značku revize pro revizi nainstalovanou během upgradu. V tomto příkladu ji
prod-canary
pojmenujeme:istioctl tag set prod-canary --revision asm-1-23 --istioNamespace aks-istio-system
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ů.
Ověřte pody řídicí roviny odpovídající oběma
asm-1-22
aasm-1-23
existují: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
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é.
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ě:
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.
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í.
Jednotlivé úlohy aplikace se převrácejí jednotlivě tak, že je restartuje. Příklad:
kubectl rollout restart deployment <deployment name> -n <deployment namespace>
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:
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
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
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ě.
Azure Kubernetes Service