Problembehandlung für das Istio-Dienstnetz-Add-On für kleinere Revisionsupgrades

Artikel
04/30/2024

In diesem Artikel werden Szenarien zur Problembehandlung und Einschränkungen bei den Prozessen für kleinere Revisionsupgrades und Rollbackvorgänge für das Istio Service Mesh-Add-On in Microsoft Azure Kubernetes Service (AKS) erläutert.

Hinweis

Istio verwendet den Begriff "Revisionen", um den Canary-Upgradeprozess zu implementieren und zwischen Versionen zu unterscheiden. Jede Revisionsbezeichnung (geschrieben als x-y) entspricht einer Haupt-/Nebenversionsbezeichnung (x.y). Sie können die Revision der Steuerungsebene steuern, aber sie können die spezifische Patchversion nicht innerhalb eines Revisionsbereichs steuern.

Voraussetzungen

Azure CLI.
Das Kubernetes kubectl-Tool oder ein ähnliches Tool zum Herstellen einer Verbindung mit dem Cluster. Um kubectl mithilfe der Azure CLI zu installieren, führen Sie den Befehl az aks install-cli aus.

Problembehandlungsmatrix

In der folgenden Tabelle sind verschiedene Probleme sowie die verschiedenen Szenarien und Lösungen für diese Probleme aufgeführt.

Szenario	Problem	Lösung
Datenebenenworkloads werden aus dem Gitter entfernt.	Die Überarbeitungen der Daten- und Steuerungsebene entsprachen nicht, bevor Sie ein Upgrade abgeschlossen oder zurückgesetzt haben.	Gehen Sie folgendermaßen vor: Bezeichnen Sie Namespaces, die Workloads enthalten, neu, indem Sie die Revision angeben, die nach Abschluss des Upgrades oder Rollbacks voraussichtlich vorhanden ist. Führen Sie hierzu den Befehl kubectl label aus: kubectl label namespace default istio.io/rev=asm-x-y --overwrite Starten Sie die entsprechenden Workloadbereitstellungen neu, um die Sidecar-Wiederherstellung der richtigen Revision auszulösen. Führen Sie hierzu den Befehl kubectl rollout restart aus : kubectl rollout restart deployment <deployment name> Vergewissern Sie sich, dass die Sidecar-Images vorhanden sind. Führen Sie hierzu den Befehl kubectl get aus: kubectl get pods --namespace <namespace> --output yaml \| grep mcr.microsoft.com/oss/istio/proxyv2:
Pods auf Steuerungsebene befinden sich im Status "Ausstehend".	Den Pods fehlt die Kapazität.	Überprüfen Sie den Zustand der Pods, indem Sie den Befehl kubectl describe ausführen. Wenn die Kapazität das Problem ist, können Sie Ihren Cluster hochskalieren, um einen weiteren Knoten hinzuzufügen. Weitere Informationen finden Sie unter Manuelles Skalieren der Knotenanzahl in einem AKS-Cluster (Azure Kubernetes Service).
Der Befehl az aks mesh get-upgrades gibt keine verfügbaren Upgrades zurück.	Die neueste Istio-Revision ist möglicherweise nicht mit der aktuellen AKS-Clusterversion kompatibel.	Sie können den Befehl az aks mesh get-revisions verwenden, um zu ermitteln, ob neuere Istio-Revisionen vorhanden sind. Die Ausgabe enthält eine Liste kompatibler Clusterversionen für jede Istio-Revision. Daher können Sie bestimmen, ob ein Clusterupgrade erforderlich ist.

Szenario

Problem

Lösung

Datenebenenworkloads werden aus dem Gitter entfernt.

Die Überarbeitungen der Daten- und Steuerungsebene entsprachen nicht, bevor Sie ein Upgrade abgeschlossen oder zurückgesetzt haben.

Gehen Sie folgendermaßen vor:

Bezeichnen Sie Namespaces, die Workloads enthalten, neu, indem Sie die Revision angeben, die nach Abschluss des Upgrades oder Rollbacks voraussichtlich vorhanden ist. Führen Sie hierzu den Befehl kubectl label aus:
```
kubectl label namespace default istio.io/rev=asm-x-y --overwrite
```
Starten Sie die entsprechenden Workloadbereitstellungen neu, um die Sidecar-Wiederherstellung der richtigen Revision auszulösen. Führen Sie hierzu den Befehl kubectl rollout restart aus :
```
kubectl rollout restart deployment <deployment name>
```
Vergewissern Sie sich, dass die Sidecar-Images vorhanden sind. Führen Sie hierzu den Befehl kubectl get aus:
```
kubectl get pods --namespace <namespace> --output yaml | grep mcr.microsoft.com/oss/istio/proxyv2:
```

Pods auf Steuerungsebene befinden sich im Status "Ausstehend".

Den Pods fehlt die Kapazität.

Überprüfen Sie den Zustand der Pods, indem Sie den Befehl kubectl describe ausführen. Wenn die Kapazität das Problem ist, können Sie Ihren Cluster hochskalieren, um einen weiteren Knoten hinzuzufügen. Weitere Informationen finden Sie unter Manuelles Skalieren der Knotenanzahl in einem AKS-Cluster (Azure Kubernetes Service).

Der Befehl az aks mesh get-upgrades gibt keine verfügbaren Upgrades zurück.

Die neueste Istio-Revision ist möglicherweise nicht mit der aktuellen AKS-Clusterversion kompatibel.

Sie können den Befehl az aks mesh get-revisions verwenden, um zu ermitteln, ob neuere Istio-Revisionen vorhanden sind. Die Ausgabe enthält eine Liste kompatibler Clusterversionen für jede Istio-Revision. Daher können Sie bestimmen, ob ein Clusterupgrade erforderlich ist.

Hinweis

Um unbeabsichtigtes Verhalten und fehlerhafte Funktionen zu vermeiden und sicherzustellen, dass Sie Updates für Sicherheitsrisiken erhalten, wird dringend empfohlen, ein Upgrade auf eine unterstützte und aktuelle AKS-Version und istio-Add-On-Revision durchzuführen. Denken Sie daran, dass sich die Add-On-Revision auch innerhalb des unterstützten Kubernetes-Versionsbereichs für den angegebenen AKS-Cluster befinden sollte. Wie im Abschnitt Upgrade für kleinere Revisionen des Istio-Upgrades hervorgehoben, können Sie die az aks mesh get-revisions Befehle und az aks mesh get-upgrades ausführen, um informationen zu verfügbaren Add-On-Revisionen, Upgrades und Kompatibilitätsinformationen zu erhalten.

Einschränkungen

Ein Downgrade auf eine ältere Revision (außerhalb des Canary-Rollbackprozesses) ist nicht zulässig.
Das Überspringen von einer Revision zu einer nicht zusammenhängenden Revision ist nur zulässig, wenn AKS nicht mehr sowohl die aktuelle Revision als auch die nächste Upgraderevision unterstützt. An diesem Punkt ist das einzige Upgrade, das Ihnen zur Verfügung steht, die niedrigste unterstützte Revision.
Die Bezeichnung Istio sidecar.istio.io/inject aktiviert keine Seitenwageneinschleusung für das Istio-Add-On. Sie müssen die istio.io/rev Bezeichnung verwenden, wenn Sie Ihre Namespaces während des Canary-Upgrades beschriften und neu bezeichnen.
Die Bezeichnung muss auf Namespaceebene statt auf bereitstellungsspezifischer Ebene erfolgen. Wenn Sie pods einzeln ausführen möchten, können Sie einzelne Bereitstellungen neu starten, anstatt Podbezeichnungen zu verwenden.
Wenn Sie das Istio-Add-On Shared MeshConfig verwenden, müssen Sie MeshConfig-Einstellungen kopieren oder in die neue ConfigMap übertragen, bevor Sie ein Canary-Upgrade durchführen. Weitere Informationen finden Sie unter Gitterkonfiguration und -upgrades.
Das Istio-Add-On stellt Istio-Eingangsgatewaypods und -Bereitstellungen pro Revision bereit. Wenn Sie ein Canary-Upgrade durchführen und zwei Revisionen auf Steuerungsebene in Ihrem Cluster installiert haben, müssen Sie möglicherweise probleme mit mehreren Eingangsgatewaypods in beiden Revisionen beheben.

References

Informationen zum Haftungsausschluss von Drittanbietern

Die in diesem Artikel genannten Drittanbieterprodukte stammen von Herstellern, die von Microsoft unabhängig sind. Microsoft gewährt keine implizite oder sonstige Garantie in Bezug auf die Leistung oder Zuverlässigkeit dieser Produkte.

Haftungsausschluss für Kontaktinformationen von Drittanbietern

Die Kontaktinformationen zu den in diesem Artikel erwähnten Drittanbietern sollen Ihnen helfen, zusätzliche Informationen zu diesem Thema zu finden. Diese Kontaktinformationen können ohne vorherige Ankündigung geändert werden. Sie werden von Microsoft ohne jede Gewähr weitergegeben.

Kontaktieren Sie uns für Hilfe

Wenn Sie Fragen haben oder Hilfe mit Ihren Azure-Gutschriften benötigen, dann erstellen Sie beim Azure-Support eine Support-Anforderung oder fragen Sie den Azure Community-Support. Sie können auch Produktfeedback an die Azure Feedback Community senden.

Freigeben über