Freigeben über

Upgrade des Istio-basierten Service-Mesh-Add-Ons für Azure Kubernetes Service

  • Artikel

Dieser Artikel befasst sich mit Upgradefunktionen für das Istio-basierte Servicenetz-Add-On für Azure Kubernetes Service (AKS).

Ankündigungen zu den Veröffentlichungen neuer Nebenrevisionen oder Patches für das Istio-basierte Service Mesh-Add-on werden in den AKS-Versionshinweisen veröffentlicht. Weitere Informationen zum Releasezeitplan und zur Unterstützung von Revisionen von Service-Mesh-Add-Ons finden Sie im Artikel zur Unterstützungsrichtlinie.

Nebenrevisions-Upgrade

Das Istio-Add-On ermöglicht das Upgrade der Nebenrevision mithilfe des Canary-Upgradeprozesses. Wenn ein Upgrade initiiert wird, wird die Steuerungsebene der neuen Revision (Canary) zusammen mit der ursprünglichen (stabilen) Steuerungsebene der Revision bereitgestellt. Anschließend können Sie manuell einen Rollover für die Datenebenenworkloads durchführen, während Sie Überwachungstools verwenden, um die Integrität von Workloads während dieses Prozesses nachzuverfolgen. Wenn Sie keine Probleme mit der Integrität Ihrer Workloads ermitteln können, können Sie das Upgrade abschließen, sodass nur die neue Revision im Cluster verbleibt. Andernfalls können Sie einen Rollback zur vorherigen Revision von Istio ausführen.

Wenn der Cluster derzeit eine unterstützte Nebenrevision von Istio verwendet, sind nur Upgrades für jeweils eine Nebenrevision zulässig. Wenn der Cluster eine nicht unterstützte Revision von Istio verwendet, müssen Sie für diese Kubernetes-Version auf die niedrigste unterstützte Nebenrevision von Istio upgraden. Danach können Upgrades für jeweils eine Nebenrevision erneut durchgeführt werden.

Das folgende Beispiel veranschaulicht, wie ein Upgrade von Revision asm-1-22 auf asm-1-23 mit allen Workloads im Namespace default abläuft. Die Schritte sind für alle kleineren Upgrades identisch und können für eine beliebige Anzahl von Namespaces verwendet werden.

  1. Verwenden Sie den Befehl az aks mesh get-upgrades, um zu überprüfen, welche Revisionen für den Cluster als Upgradeziele verfügbar sind:

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

    Wenn Sie erwarten, dass eine neuere Revision nicht von diesem Befehl zurückgegeben wird, müssen Sie möglicherweise zuerst Ihren AKS-Cluster upgraden, damit er mit der neuesten Revision kompatibel ist.

  2. Wenn Sie eine Mesh-Konfiguration für die vorhandene Mesh-Revision in Ihrem Cluster einrichten, müssen Sie eine separate ConfigMap-Instanz für die neue Revision im Namespace aks-istio-system erstellen, bevor Sie im nächsten Schritt das Canary-Upgrade initiieren. Diese Konfiguration gilt ab dem Zeitpunkt, zu dem die Steuerungsebene der neuen Revision im Cluster bereitgestellt wird. Weitere Informationen finden Sie hier.

  3. Initiieren Sie ein Canaryupgrade von der Revision asm-1-22 auf asm-1-23 unter Verwendung des Befehls az aks mesh upgrade start:

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

    Ein Canaryupgrade bedeutet, dass die Steuerungsebene 1.23 neben der Steuerungsebene 1.22 bereitgestellt wird. Sie sind weiterhin vorhanden, bis Sie das Upgrade abgeschlossen oder einen Rollback ausgeführt haben.

  4. Optional können Überarbeitungstags verwendet werden, um die Datenebene in die neue Revision zu übertragen, ohne jeden Namespace manuell neu zu bezeichnen. Das manuelle Neubezeichnen von Namespaces beim Verschieben in eine neue Revision kann mühsam und fehleranfällig sein. Revisionstags lösen dieses Problem, indem sie als stabile Bezeichner dienen, die auf Überarbeitungen verweisen.

    Anstatt jeden Namespace neu zu bezeichnen, kann ein Clusteroperator das Tag ändern, um auf eine neue Revision zu verweisen. Alle Namespaces, die mit diesem Tag bezeichnet sind, werden gleichzeitig upgedated. Sie müssen die Workloads jedoch weiterhin neu starten, um sicherzustellen, dass die richtige Version von istio-proxy-Sidecarelementen eingefügt wird.

    So verwenden Sie Überarbeitungstags während eines Upgrades:

    1. Installieren von istioctl CLI

    2. Erstellen Sie ein Revisionstag für die ursprüngliche Überarbeitung. In diesem Beispiel nennen wir es prod-stable:

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

    3. Erstellen Sie ein Revisionstag für die während des Upgrades installierte Revision. In diesem Beispiel nennen wir es prod-canary:

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

    4. Bezeichnungsanwendungsnamespaces, um Überarbeitungstags zuzuordnen:

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

      Sie können auch Namespaces mit istio.io/rev=prod-canary für die neuere Überarbeitung bezeichnen. Die Workloads in diesen Namespaces werden jedoch erst auf ein neues Sidecar aktualisiert, wenn sie neu gestartet werden.

      Wenn eine neue Anwendung nach der Bezeichnung in einem Namespace erstellt wird, wird ein Sidecar entsprechend dem Revisionstag in diesem Namespace eingefügt.

  5. Überprüfen Sie, ob Steuerungsebenenpods vorhanden sind, die asm-1-22 und asm-1-23 entsprechen:

    1. Überprüfen von istiod-Pods:

      kubectl get pods -n aks-istio-system

      Beispielausgabe:

      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. Wenn der Eingang aktiviert ist, überprüfen Sie die Eingangspods:

      kubectl get pods -n aks-istio-ingress

      Beispielausgabe:

      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

      Beachten Sie, dass Eingangsgatewaypods beider Revisionen parallel bereitgestellt werden. Der Dienst und seine IP bleiben jedoch unveränderlich.

  6. Bezeichnen Sie den Namespace neu, sodass alle neuen Pods dem Istio-Sidecarelement zugeordnet werden, das der neuen Revision und der zugehörigen Steuerungsebene zugeordnet ist:

    1. Wenn Sie Überarbeitungstags verwenden, überschreiben Sie das prod-stable-Tag selbst, um die Zuordnung zu ändern:

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

      Überprüfen Sie die Zuordnungen von Tag-zu-Überarbeitungen:

      istioctl tag list

      Beide Tags sollten auf die neu installierte Revision verweisen:

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

      In diesem Fall müssen Sie die einzelnen Namespaces nicht einzeln neu bezeichnen.

    2. Wenn Keine Überarbeitungstags verwendet werden, müssen Namespaces der Datenebene neu bezeichnet werden, um auf die neue Revision zu verweisen:

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

    Die Neubezeichnung wirkt sich erst auf Ihre Workloads aus, wenn diese neu gestartet werden.

  7. Führen Sie für jede Ihrer Anwendungsworkloads einen einzelnen Rollover durch, indem Sie sie neu starten. Beispiel:

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

  8. Überprüfen Sie Ihre Überwachungstools und Dashboards, um zu ermitteln, ob Ihre Workloads nach dem Neustart in einem fehlerfreien Zustand ausgeführt werden. Basierend auf dem Ergebnis haben Sie zwei Optionen:

    1. Abschließen des Canaryupgrades: Wenn die Workloads alle erwartungsgemäß in einem fehlerfreien Zustand ausgeführt werden, können Sie das Canaryupgrade abschließen. Durch den Abschluss des Upgrades wird die Steuerungsebene der vorherigen Revision entfernt und durch die Steuerungsebene der neuen Revision im Cluster ersetzt. Führen Sie den folgenden Befehl aus, um das Canaryupgrade abzuschließen:

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

    2. Durchführen eines Rollbacks für das Canaryupgrade: Wenn Sie Probleme mit der Integrität Ihrer Workloads beobachten, können Sie einen Rollback auf die vorherige Revision von Istio ausführen:

    • Beschriften Sie den Namespace in die vorherige Revision: Wenn Überarbeitungstags verwendet werden:

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

      Oder, wenn keine Überarbeitungstags verwendet werden:

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

    • Führen Sie einen Rollback für die Workloads aus, um das Sidecarelement zu verwenden, das der vorherigen Istio-Revision entspricht, indem Sie diese Workloads noch mal neu starten:

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

    • Führen Sie einen Rollback für die Steuerungsebene auf die vorherige Revision aus:

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

    Das prod-canary-Revisionstag kann entfernt werden:

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

  9. Wenn Gitterkonfiguration zuvor für die Überarbeitungen eingerichtet wurde, können Sie die ConfigMap für die Überarbeitung löschen, die während des Vollständigen/Rollbacks aus dem Cluster entfernt wurde.

Nebenrevisions-Upgrades mit dem Eingangsgateway

Wenn Sie derzeit Istio-Eingangsgateways verwenden und ein kleineres Revisionsupgrade durchführen, denken Sie daran, dass Istio-Eingangsgateway-Pods/-Bereitstellungen pro Revision bereitgestellt werden. Wir stellen jedoch revisionsübergreifend einen einzelnen LoadBalancer-Dienst für alle eingehenden Gatewaypods bereit, sodass die externe bzw. interne IP-Adresse der Eingangsgateways während eines Upgrades unverändert bleibt.

Daher verarbeiten die Eingangsgatewaypods beider Revisionen während des Canary-Upgrades den eingehenden Datenverkehr, wenn zwei Revisionen gleichzeitig auf dem Cluster vorhanden sind.

Kleinere Revisionsupgrades mit Anpassungen für die automatische horizontale Skalierung von Pods

Wenn Sie die Einstellungen für die automatische horizontale Skalierung von Pods (Horizontal Pod Autoscaling, HPA) für Istiod oder die Eingangsgateways angepasst haben, beachten Sie das folgende Verhalten für die Anwendung von HPA-Einstellungen für beide Revisionen, um die Konsistenz während eines Canary-Upgrades aufrechtzuerhalten:

  • Wenn Sie die HPA-Spezifikation vor dem Initiieren eines Upgrades updaten, werden die Einstellungen der vorhandenen (stabilen) Revision auf die HPAs der Canary-Revision angewendet, wenn die neue Steuerungsebene installiert wird.
  • Wenn Sie die HPA-Spezifikation während ein Canary-Upgrades updaten, hat die HPA-Spezifikation der stabilen Revision Vorrang und wird auf die HPA der Canary-Revision angewendet.
    • Wenn Sie die HPA der stabilen Revision während eines Upgrades updaten, wird die HPA-Spezifikation der Canary-Revision upgedatet, um die neuen Einstellungen widerzuspiegeln, die auf die stabile Revision angewendet werden.
    • Wenn Sie die HPA der Canary-Revision während eines Upgrades updaten, wird die HPA-Spezifikation der Canary-Revision auf die HPA-Spezifikation der stabilen Revision zurückgesetzt.

Patchversionsupgrade

  • Informationen zur Verfügbarkeit der Istio Add-On-Patchversion werden in AKS-Versionshinweisen veröffentlicht.
  • Patches werden automatisch für istiod-Pods und Eingangspods im Rahmen dieser AKS-Releases bereitgestellt, die das für den Cluster eingerichtete default geplante Wartungsfenster berücksichtigen.
  • Der Benutzer muss Patches für den Istio-Proxy in seinen Workloads initiieren, indem er die Pods für die Reinjektion neu startet:

    • Überprüfen Sie die Version des Istio-Proxys, die für neue oder neu gestartete Pods vorgesehen ist. Diese Version entspricht der Version der Istiod- und Istio-Eingangspods, nachdem sie gepatcht wurden:

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

      Beispielausgabe:

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

    • Überprüfen Sie die Version des Istio-Proxy-Images für alle Pods in einem 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"

      Beispielausgabe:

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

    • Starten Sie die Workloads neu, um die Reinjektion auszulösen. Beispiel:

      kubectl rollout restart deployments/productpage-v1 -n default

    • Um zu überprüfen, ob sie über die neueren Versionen verfügen, prüfen Sie die Version des Istio-Proxy-Images für alle Pods im Namespace erneut:

      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"

      Beispielausgabe:

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

Hinweis

Wenn bei Upgrades Probleme auftreten, lesen Sie den Artikel zur Problembehandlung von Gitterrevisionsupgrades