Upgrade des Istio-basierten Service-Mesh-Add-Ons für Azure Kubernetes Service
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.
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 alten (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-20 auf asm-1-21 abläuft. Die Schritte sind für alle kleineren Upgrades identisch.
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 $CLUSTERWenn 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.
Wenn Sie eine Gitterkonfiguration für die vorhandene Gitterrevision in Ihrem Cluster eingerichtet haben, müssen Sie eine separate ConfigMap-Instanz für die neue Revision im Namespace
aks-istio-systemerstellen, 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.Initiieren Sie ein Canaryupgrade von der Revision
asm-1-20aufasm-1-21unter Verwendung des Befehls az aks mesh upgrade start:az aks mesh upgrade start --resource-group $RESOURCE_GROUP --name $CLUSTER --revision asm-1-21Ein Canaryupgrade bedeutet, dass die Steuerungsebene 1.20 neben der Steuerungsebene 1.21 bereitgestellt wird. Sie sind weiterhin vorhanden, bis Sie das Upgrade abgeschlossen oder einen Rollback ausgeführt haben.
Überprüfen Sie, ob Steuerungsebenenpods vorhanden sind, die
asm-1-20undasm-1-21entsprechen:Überprüfen von
istiod-Pods:kubectl get pods -n aks-istio-systemBeispielausgabe:
NAME READY STATUS RESTARTS AGE istiod-asm-1-20-55fccf84c8-dbzlt 1/1 Running 0 58m istiod-asm-1-20-55fccf84c8-fg8zh 1/1 Running 0 58m istiod-asm-1-21-f85f46bf5-7rwg4 1/1 Running 0 51m istiod-asm-1-21-f85f46bf5-8p9qx 1/1 Running 0 51mWenn der Eingang aktiviert ist, überprüfen Sie die Eingangspods:
kubectl get pods -n aks-istio-ingressBeispielausgabe:
NAME READY STATUS RESTARTS AGE aks-istio-ingressgateway-external-asm-1-20-58f889f99d-qkvq2 1/1 Running 0 59m aks-istio-ingressgateway-external-asm-1-20-58f889f99d-vhtd5 1/1 Running 0 58m aks-istio-ingressgateway-external-asm-1-21-7466f77bb9-ft9c8 1/1 Running 0 51m aks-istio-ingressgateway-external-asm-1-21-7466f77bb9-wcb6s 1/1 Running 0 51m aks-istio-ingressgateway-internal-asm-1-20-579c5d8d4b-4cc2l 1/1 Running 0 58m aks-istio-ingressgateway-internal-asm-1-20-579c5d8d4b-jjc7m 1/1 Running 0 59m aks-istio-ingressgateway-internal-asm-1-21-757d9b5545-g89s4 1/1 Running 0 51m aks-istio-ingressgateway-internal-asm-1-21-757d9b5545-krq9w 1/1 Running 0 51mBeachten Sie, dass Eingangsgatewaypods beider Revisionen parallel bereitgestellt werden. Der Dienst und seine IP bleiben jedoch unveränderlich.
Bezeichnen Sie den Namespace neu, sodass alle neuen Pods das Istio-Sidecarelement erhalten, das der neuen Revision und der zugehörigen Steuerungsebene zugeordnet ist:
kubectl label namespace default istio.io/rev=asm-1-21 --overwriteDie Neubezeichnung wirkt sich erst auf Ihre Workloads aus, wenn diese neu gestartet werden.
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>Ü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:
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 $CLUSTERDurchfü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:
Bezeichnen Sie den Namespace gemäß der vorherigen Revision neu:
kubectl label namespace default istio.io/rev=asm-1-20 --overwriteFü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
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.
Hinweis
Das manuelle Neubezeichnen von Namespaces beim Verschieben in eine neue Revision kann mühsam und fehleranfällig sein. Revisionstags lösen dieses Problem. Revisionstags sind stabile Bezeichner, die auf Revisionen verweisen und verwendet werden können, um die Neubezeichnung von Namespaces zu vermeiden. Anstatt den Namespace neu zu bezeichnen, kann ein Meshoperator einfach das Tag ändern, um auf eine neue Revision zu verweisen. Alle Namespaces, die mit diesem Tag bezeichnet sind, werden gleichzeitig upgedated. Beachten Sie jedoch, dass Sie die Workloads weiterhin neu starten müssen, um sicherzustellen, dass die richtige Version von istio-proxy-Sidecarelementen eingefügt wird.
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 einen einzelnen LoadBalancer-Dienst über mehrere Revisionen hinweg für alle Eingangsgateway-Pods bereit, sodass sich die externe/interne IP-Adresse der Eingangsgateways während eines Upgrades nicht ändert.
Daher wird während des Canary-Upgrades, wenn zwei Revisionen gleichzeitig auf dem Cluster vorhanden sind, eingehender Datenverkehr von den Eingangsgateway-Pods beider Revisionen bereitgestellt.
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
defaultgeplante 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.20.6-distroless", "image": "mcr.microsoft.com/oss/istio/proxyv2:1.20.6-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.20.0, mcr.microsoft.com/oss/istio/proxyv2:1.20.6-distrolessStarten Sie die Workloads neu, um die Reinjektion auszulösen. Beispiel:
kubectl rollout restart deployments/productpage-v1 -n defaultUm 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.20.0, mcr.microsoft.com/oss/istio/proxyv2:1.20.7-distroless
Hinweis
Wenn bei Upgrades Probleme auftreten, lesen Sie den Artikel zur Problembehandlung von Gitterrevisionsupgrades
Azure Kubernetes Service
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für