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.
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.
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.
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.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.
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:
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
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
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.
Verifiera kontrollplanspoddar som motsvarar båda
asm-1-22
ochasm-1-23
finns: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
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.
Ange namnområdet igen så att alla nya poddar mappas till Den Istio-sidovagn som är associerad med den nya revisionen och dess kontrollplan:
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.
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.
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>
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: 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
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.
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.
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.
- 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
Feedback om Azure Kubernetes Service
Azure Kubernetes Service är ett öppen källkod projekt. Välj en länk för att ge feedback: