Delen via

Istio-gebaseerde service mesh-uitbreiding voor Azure Kubernetes Service upgraden

In dit artikel vindt u informatie over upgrade-ervaringen voor de invoegtoepassing Service mesh op basis van Istio voor Azure Kubernetes Service (AKS).

Aankondigingen over de releases van nieuwe kleine revisies of patches voor de op Istio gebaseerde service mesh add-on worden gepubliceerd in de AKS-release-opmerkingen. Lees het ondersteuningsbeleid voor meer informatie over het releaseschema en de ondersteuning voor service mesh-invoegtoepassingsrevisies.

Kleine upgrade van revisie

Met de Istio-invoegtoepassing kunt u een kleine revisie upgraden met behulp van het canary-upgradeproces. Wanneer een upgrade wordt gestart, wordt het besturingsvlak van de nieuwe (canaire) revisie geïmplementeerd naast het besturingsvlak van de eerste (stabiele) revisie. Vervolgens kunt u workloads van het datavlak handmatig overdragen terwijl u monitoringstools gebruikt om de status van workloads tijdens dit proces bij te houden. Als u geen problemen met de status van uw workloads ziet, kunt u de upgrade voltooien zodat alleen de nieuwe revisie op het cluster blijft staan. Anders kunt u teruggaan naar de vorige revisie van Istio.

Beschikbare upgrades zijn afhankelijk van of de huidige Istio-revisie en AKS-clusterversie worden ondersteund:

  • U kunt een upgrade uitvoeren naar de volgende ondersteunde revisie (n+1) of een upgrade n+2naar overslaan, zolang beide worden ondersteund en compatibel zijn met de clusterversie.
  • Als zowel uw huidige revisie () als de volgende revisie (nn+1) niet worden ondersteund, kunt u alleen upgraden naar de dichtstbijzijnde ondersteunde revisie (n+2of hoger), maar niet verder.
  • Als de clusterversie en de Istio-revisie beide niet worden ondersteund, moet de clusterversie worden bijgewerkt voordat een Istio-upgrade kan worden gestart.

Notitie

Zodra een AKS-versie of mesh-revisie buiten het ondersteuningsvenster valt, wordt het upgraden van beide versies foutgevoelig. Hoewel dergelijke upgrades kunnen worden bijgewerkt naar een ondersteunde versie, worden zowel het upgradeproces als de out-of-support-versies zelf niet ondersteund door Microsoft. We raden sterk aan om de AKS-versie en mesh-revisie up-to-date te houden om te voorkomen dat u in niet-ondersteunde scenario's terechtkomt. Raadpleeg de ondersteuningskalender voor de Istio-invoegtoepassing voor geschatte release- en einddatums en de upstream Istio-releaseopmerkingen voor de nieuwe revisie met belangrijke wijzigingen.

In het volgende voorbeeld ziet u hoe u een upgrade uitvoert van revisie asm-1-23 naar asm-1-24 voor alle workloads in de default naamruimte. De stappen zijn hetzelfde voor alle kleine upgrades en kunnen worden gebruikt voor een willekeurig aantal naamruimten.

  1. Gebruik de opdracht az aks mesh get-upgrades om te controleren welke revisies beschikbaar zijn voor het cluster als upgradedoelen:

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

    Als u verwacht dat een nieuwere revisie niet wordt geretourneerd door deze opdracht, moet u mogelijk eerst uw AKS-cluster upgraden zodat het compatibel is met de nieuwste revisie.

  2. Als u een mesh-configuratie instelt voor de bestaande mesh-revisie in uw cluster, moet u een afzonderlijke ConfigMap maken die overeenkomt met de nieuwe revisie in de aks-istio-system naamruimte voordat u de canary-upgrade in de volgende stap start. Deze configuratie is van toepassing op het moment dat het besturingsvlak van de nieuwe revisie op het cluster wordt geïmplementeerd. Hier vindt u meer informatie.

  3. Start een canary-upgrade van revisie asm-1-23 naar asm-1-24 met behulp van de opdracht az aks mesh upgrade start.

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

    Een canary-upgrade betekent dat het controlevlak van versie 1.24 naast het controlevlak van versie 1.23 wordt geïmplementeerd. Ze blijven naast elkaar bestaan totdat u de upgrade voltooit of terugdraait.

    Hoewel er een canary-upgrade plaatsvindt, wordt de hogere revisie beschouwd als de standaardrevisie die wordt gebruikt voor de validatie van Istio-resources.

  4. Optioneel kunnen revisietags worden gebruikt om het gegevensvlak over te rollen naar de nieuwe revisie zonder dat u elke naamruimte handmatig opnieuw moet labelen. Het handmatig opnieuw labelen van naamruimten bij het verplaatsen naar een nieuwe revisie kan tijdrovend en foutgevoelig zijn. Revisietags lossen dit probleem op door te fungeren als stabiele id's die verwijzen naar revisies.

    In plaats van elke naamruimte opnieuw te labelen, kan een clusteroperator de tag wijzigen zodat deze verwijst naar een nieuwe revisie. Alle naamruimten die met die tag zijn gelabeld, worden tegelijkertijd bijgewerkt. Echter, u moet nog steeds de workloads opnieuw starten om ervoor te zorgen dat de juiste versie van istio-proxy sidecars wordt geïnjecteerd.

    Revisietags gebruiken tijdens een upgrade:

    1. Istioctl CLI installeren

    2. Maak een revisietag voor de eerste revisie. In dit voorbeeld noemen we het prod-stable:

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

    3. Maak een revisietag voor de revisie die tijdens de upgrade is geïnstalleerd. In dit voorbeeld noemen we het prod-canary:

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

    4. Label toepassingsnaamruimten die moeten worden toegewezen aan revisietags:

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

      U kunt ook naamruimten labelen met istio.io/rev=prod-canary voor de nieuwere revisie. De workloads in die naamruimten worden echter pas geüpdatet naar een nieuwe sidecar nadat ze opnieuw zijn opgestart.

      Als er een nieuwe toepassing wordt gemaakt in een naamruimte nadat deze is gelabeld, wordt er een sidecar geïnjecteerd die overeenkomt met de revisietag in die naamruimte.

  5. Controleer of de pods van het besturingsvlak bijbehorend aan zowel asm-1-23 als asm-1-24 bestaan.

    1. Verifieer istiod kapsels:

      kubectl get pods -n aks-istio-system

      Voorbeelduitvoer:

      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. Als ingress is ingeschakeld, controleert u de ingress-pods:

      kubectl get pods -n aks-istio-ingress

      Voorbeelduitvoer:

      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

      U ziet dat ingress-gatewaypods van beide revisies naast elkaar worden ingezet. De service en het IP-adres blijven echter onveranderbaar.

  6. Geef de naamruimte opnieuw een label zodat nieuwe pods worden toegewezen aan de Istio-sidecar die is gekoppeld aan de nieuwe revisie en het bijbehorende besturingsvlak:

    1. Als u revisietags gebruikt, overschrijft u de tag prod-stable zelf om de toewijzing ervan te wijzigen.

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

      Verifieer de toewijzingen van tags naar revisies.

      istioctl tag list

      Beide tags moeten verwijzen naar de zojuist geïnstalleerde revisie:

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

      In dit geval hoeft u elke naamruimte niet afzonderlijk opnieuw te labelen.

    2. Als u geen revisietags gebruikt, moeten naamruimten van het gegevensvlak opnieuw worden gelabeld om te verwijzen naar de nieuwe revisie:

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

    Het herlabelen heeft geen invloed op uw workloads totdat ze worden herstart.

  7. Zet elk van uw applicatiewerklasten afzonderlijk over door ze opnieuw op te starten. Voorbeeld:

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

  8. Controleer uw bewakingshulpprogramma's en dashboards om na het opnieuw opstarten te bepalen of uw workloads allemaal in orde zijn. Op basis van het resultaat hebt u twee opties:

    1. Voltooi de canary-upgrade: als u tevreden bent dat de workloads allemaal in orde zijn zoals verwacht, kunt u de canary-upgrade voltooien. Als de upgrade is voltooid, wordt het besturingsvlak van de vorige revisie verwijderd en blijft het besturingsvlak van de nieuwe revisie op het cluster achter. Voer de volgende opdracht uit om de canary-upgrade te voltooien:

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

    2. De canary-upgrade terugdraaien: als u problemen ondervindt met de gezondheid van uw workloads, kunt u terugkeren naar de vorige revisie van Istio:

    • Hernoem de naamruimte naar de vorige revisie: Als u revisielabels gebruikt:

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

      Of, als u geen revisietags gebruikt:

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

    • Draai de werkbelastingen terug om de sidecar te gebruiken die overeenkomt met de vorige Istio-revisie door deze workloads opnieuw te starten:

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

    • Draai het controlevlak terug naar de vorige versie.

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

    De prod-canary revisietag kan worden verwijderd:

    istioctl tag remove prod-canary --istioNamespace aks-istio-system

  9. Als de mesh-configuratie eerder is ingesteld voor de revisies, kunt u nu de ConfigMap verwijderen voor de revisie die tijdens het voltooien/terugdraaien van het cluster is verwijderd.

Kleine revisie-updates met inkomende en uitgaande gateways

Als u momenteel Istio-ingangsgateways of uitgaande gateways gebruikt en een kleine revisie-upgrade uitvoert, moet u er rekening mee houden dat Istio-ingangs- en uitgaande gateway-pods/-implementaties per revisie worden geïmplementeerd, maar de service wordt gedeeld tussen beide revisies.

We bieden één LoadBalancer service voor alle ingangsgateway-pods over meerdere revisies, zodat het externe/interne IP-adres van de ingangsgateways gedurende de loop van een upgrade ongewijzigd blijft. Tijdens de canary-upgrade, wanneer er twee revisies tegelijkertijd op het cluster aanwezig zijn, dienen de ingangsgateways van beide revisies het inkomende verkeer.

Eveneens worden tijdens een canary-upgrade alle pods voor een uitgaande gateway in beide revisies bediend door één ClusterIP service.

Kleine revisie-upgrades met aanpassingen voor horizontale automatische schaalaanpassing van pods.

Als u de instellingen voor automatische schaalaanpassing van horizontale pods (HPA) voor Istiod of de ingangsgateways hebt aangepast, houd dan rekening met het volgende gedrag van hoe HPA-instellingen in beide revisies worden toegepast om consistentie te behouden tijdens een canary upgrade:

  • Als u de HPA-specificatie bijwerkt voordat u een upgrade start, worden de instellingen van de bestaande (stabiele) revisie toegepast op de HPA's van de canary-revisie wanneer het nieuwe besturingsvlak wordt geïnstalleerd.
  • Als u de HPA-specificatie bijwerkt terwijl er een canary-upgrade wordt uitgevoerd, heeft de HPA-specificatie van de stabiele revisie voorrang en wordt deze toegepast op de HPA van de canary-revisie.
    • Als u de HPA van de stabiele revisie tijdens een upgrade bijwerkt, wordt de HPA-specificatie van de canary-revisie bijgewerkt om de nieuwe instellingen weer te geven die zijn toegepast op de stabiele revisie.
    • Als u de HPA van de canary-revisie bijwerkt tijdens een upgrade, wordt de HPA-specificatie van de canary-revisie teruggezet naar de HPA-specificatie van de stabiele revisie.

Upgrade van patch-versie

  • Informatie over de beschikbaarheid van de patchversie van Istio wordt gepubliceerd in de releaseopmerkingen van AKS.
  • Patches worden automatisch uitgerold voor istiod- en ingress-pods als onderdeel van deze AKS-releases, die rekening houden met het defaultgeplande onderhoudsvenster dat is ingesteld voor het cluster.
  • De gebruiker moet patches toepassen op de Istio-proxy in hun workloads door de pods opnieuw op te starten voor herinjectie.

    • Controleer de versie van de Istio-proxy die is bedoeld voor nieuwe of opnieuw gestarte pods. Deze versie is hetzelfde als de versie van de istiod en Istio-ingress pods nadat ze zijn gepatcht.

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

      Voorbeelduitvoer:

      "image": "mcr.microsoft.com/oss/istio/proxyv2:1.23.0-distroless",
"image": "mcr.microsoft.com/oss/istio/proxyv2:1.23.0-distroless"

    • Controleer de Istio-proxyafbeeldingsversie voor alle pods in een naamruimte.

      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"

      Voorbeelduitvoer:

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

    • Start de werkbelastingen opnieuw op om de herinjectie te activeren. Voorbeeld:

      kubectl rollout restart deployments/productpage-v1 -n default

    • Als u wilt controleren of deze zich nu in de nieuwere versies bevinden, controleert u de versie van de Istio-proxyinstallatiekopieën opnieuw voor alle pods in de naamruimte:

      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"

      Voorbeelduitvoer:

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

Notitie

Als er problemen zijn opgetreden tijdens upgrades, raadpleegt u het artikel over het oplossen van mesh-revisieupgrades

  • Last updated on