Delen via

Service mesh-invoegtoepassing op basis van Istio upgraden voor Azure Kubernetes Service

  • Artikel

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-invoegtoepassing worden gepubliceerd in de opmerkingen bij de AKS-release. Lees het ondersteuningsbeleid voor meer informatie over het releaseschema en de ondersteuning voor service mesh-invoegtoepassingsrevisies.

Upgrade van secundaire revisie

Met de Istio-invoegtoepassing kan de secundaire revisie worden bijgewerkt 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 gegevensvlak handmatig overrollen terwijl u bewakingshulpprogramma's 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.

Als het cluster momenteel een ondersteunde secundaire revisie van Istio gebruikt, zijn upgrades slechts één secundaire revisie tegelijk toegestaan. Als het cluster gebruikmaakt van een niet-ondersteunde revisie van Istio, moet u een upgrade uitvoeren naar de laagste ondersteunde secundaire revisie van Istio voor die Kubernetes-versie. Daarna kunnen upgrades opnieuw één kleine revisie tegelijk worden uitgevoerd.

In het volgende voorbeeld ziet u hoe u een upgrade uitvoert van revisie asm-1-22 naar asm-1-23 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-22 naar asm-1-23 az aks mesh upgrade start:

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

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

  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. U moet de workloads echter nog steeds 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-22 --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-23 --istioNamespace aks-istio-system

    4. Label toepassingsnaamruimten die moeten worden toegewezen aan revisietags:

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

      U kunt ook naamruimten labelen voor istio.io/rev=prod-canary de nieuwere revisie. De workloads in deze naamruimten worden echter pas bijgewerkt 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 besturingsvlakpods overeenkomen met beide asm-1-22 en asm-1-23 bestaan:

    1. Pods verifiëren istiod :

      kubectl get pods -n aks-istio-system

      Voorbeelduitvoer:

      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. Als inkomend verkeer is ingeschakeld, controleert u de toegangsbeheerobjecten:

      kubectl get pods -n aks-istio-ingress

      Voorbeelduitvoer:

      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

      U ziet dat toegangsbeheergatewaypods van beide revisies naast elkaar worden geïmplementeerd. 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 zelf om de prod-stable toewijzing te wijzigen:

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

      Controleer de tag-naar-revisietoewijzingen:

      istioctl tag list

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

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

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

    Het opnieuw labelen heeft geen invloed op uw workloads totdat ze opnieuw worden opgestart.

  7. U kunt elk van uw toepassingsworkloads afzonderlijk implementeren 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. Terugdraaien van de canary-upgrade: als u problemen ondervindt met de status van uw workloads, kunt u terugkeren naar de vorige revisie van Istio:

    • Label de naamruimte opnieuw naar de vorige revisie: Als u revisietags gebruikt:

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

      Of, als u geen revisietags gebruikt:

      kubectl label namespace default istio.io/rev=asm-1-22 --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 besturingsvlak terug naar de vorige revisie:

      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.

Secundaire revisie-upgrades met de ingangsgateway

Als u momenteel istio-ingangsgateways gebruikt en een secundaire revisie-upgrade uitvoert, moet u er rekening mee houden dat Istio-gatewaypods/-implementaties per revisie worden geïmplementeerd. We bieden echter één LoadBalancer-service voor alle ingangsgatewaypods via meerdere revisies, zodat het externe/interne IP-adres van de ingangsgateways gedurende de loop van een upgrade ongewijzigd blijft.

Wanneer er tijdens de canaire upgrade dus twee revisies tegelijk op het cluster bestaan, dienen de ingangsgatewaypods van beide revisies inkomend verkeer.

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

Als u de instellingen voor automatische schaalaanpassing van horizontale pods (HPA) voor Istiod of de ingangsgateways hebt aangepast, moet u rekening houden met het volgende gedrag voor de wijze waarop HPA-instellingen worden toegepast in beide revisies om consistentie te behouden tijdens een canaire 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 patchversie

  • Beschikbaarheidsinformatie over de patchversie van Istio wordt gepubliceerd in de releaseopmerkingen van AKS.
  • Patches worden automatisch geïmplementeerd voor istiod- en inkomende pods als onderdeel van deze AKS-releases, die rekening houden met het default geplande onderhoudsvenster dat is ingesteld voor het cluster.
  • De gebruiker moet patches initiëren in de Istio-proxy in hun workloads door de pods opnieuw te starten voor opnieuw instellen:

    • 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-ingangspods 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.22.0-distroless",
"image": "mcr.microsoft.com/oss/istio/proxyv2:1.22.0-distroless"

    • Controleer de versie van de Istio-proxyinstallatiekopieën 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.22.0, mcr.microsoft.com/oss/istio/proxyv2:1.22.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.22.0-distroless

Notitie

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