Problembehandlung beim Problembehandlung beim Istio-Dienstgitter-Gitter-Add-On

Artikel
11/20/2024

In diesem Artikel werden Problembehandlungsszenarien und Einschränkungen in den kleineren Überarbeitungsupgrade- und Rollbackprozessen für das Istio-Dienstgitter-Add-On in Microsoft Azure Kubernetes Service (AKS) erläutert.

Notiz

Istio verwendet den Begriff "Revisionen", um den Canary-Upgradeprozess zu implementieren und zwischen Versionen zu unterscheiden. Jede Überarbeitungsbezeichnung (geschrieben als x-y) entspricht einer Hauptversionsbezeichnung (x).y). Sie können die Überarbeitung der Steuerungsebene steuern, aber Sie können die spezifische Patchversion innerhalb eines Überarbeitungsbereichs nicht steuern.

Voraussetzungen

Azure-Befehlszeilenschnittstelle.
Das Kubernetes-Kubectl-Tool oder ein ähnliches Tool zum Herstellen einer Verbindung mit dem Cluster. Führen Sie zum Installieren von Kubectl mithilfe der Azure CLI den Befehl "az aks install-cli " aus.

Problembehandlungsmatrix

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

Szenario	Problem	Lösung
Datenebenenworkloads werden aus dem Gitter gelöscht.	Überarbeitungen von Datenebenen und Kontrollebenen entsprechen nicht, bevor Sie ein Upgrade abgeschlossen oder zurückgesetzt haben.	Führen Sie folgende Schritte aus: Beschriften Sie Namespaces, die Workloads enthalten, indem Sie die Revision angeben, die nach Abschluss des Upgrades oder Rollbacks erwartet wird. Führen Sie dazu 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-Reinjektion der richtigen Revision auszulösen. Führen Sie dazu den Befehl für den Neustart des Kubectl-Rollouts aus: kubectl rollout restart deployment <deployment name> Stellen Sie sicher, dass die Seitenwagenbilder vorhanden sind. Führen Sie dazu den Befehl "kubectl get " aus: kubectl get pods --namespace <namespace> --output yaml \| grep mcr.microsoft.com/oss/istio/proxyv2:
Steuerebenen-Pods befinden sich im ausstehenden Zustand.	Die Pods haben keine Kapazität.	Überprüfen Sie den Status der Pods, indem Sie den Befehl "kubectl describe " ausführen. Wenn die Kapazität das Problem darstellt, können Sie den Cluster skalieren, um einen anderen Knoten hinzuzufügen. Weitere Informationen finden Sie unter Manuelles Skalieren der Knotenanzahl in einem Azure Kubernetes Service (AKS)-Cluster.
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.	Mit dem Befehl "az aks mesh get-revisions" können Sie ermitteln, ob neuere Istio-Revisionen vorhanden sind. Die Ausgabe enthält eine Liste kompatibler Clusterversionen für jede Istio-Revision. Daher können Sie ermitteln, ob ein Clusterupgrade erforderlich ist.

Szenario

Problem

Lösung

Datenebenenworkloads werden aus dem Gitter gelöscht.

Überarbeitungen von Datenebenen und Kontrollebenen entsprechen nicht, bevor Sie ein Upgrade abgeschlossen oder zurückgesetzt haben.

Führen Sie folgende Schritte aus:

Beschriften Sie Namespaces, die Workloads enthalten, indem Sie die Revision angeben, die nach Abschluss des Upgrades oder Rollbacks erwartet wird. Führen Sie dazu 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-Reinjektion der richtigen Revision auszulösen. Führen Sie dazu den Befehl für den Neustart des Kubectl-Rollouts aus:
```
kubectl rollout restart deployment <deployment name>
```
Stellen Sie sicher, dass die Seitenwagenbilder vorhanden sind. Führen Sie dazu den Befehl "kubectl get " aus:
```
kubectl get pods --namespace <namespace> --output yaml | grep mcr.microsoft.com/oss/istio/proxyv2:
```

Steuerebenen-Pods befinden sich im ausstehenden Zustand.

Die Pods haben keine Kapazität.

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

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.

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

Notiz

Um unbeabsichtigtes Verhalten und fehlerhafte Funktionen zu vermeiden, und stellen Sie außerdem sicher, dass Sie Updates für Sicherheitsrisiken erhalten, empfehlen wir dringend, ein Upgrade auf eine unterstützte und aktuelle AKS-Version und eine Aktuelle Version des Istio-Add-Ons durchzuführen. Denken Sie daran, dass die Add-On-Revision auch innerhalb des unterstützten Kubernetes-Versionsbereichs für den angegebenen AKS-Cluster liegen sollte. Wie im Abschnitt "Kleinere Überarbeitungsupgrade " des Istio-Upgradeartikels hervorgehoben, können Sie die az aks mesh get-revisions Und-Befehle az aks mesh get-upgrades ausführen, um mehr über verfügbare Add-On-Überarbeitungen, Upgrades und Kompatibilitätsinformationen zu erfahren.

Beschränkungen

Ein Downgrade auf eine ältere Revision (außerhalb des Canary-Rollbackprozesses) ist nicht zulässig.
Das Überspringen von einer Überarbeitung zu einer nicht zusammenhängenden Revision ist nur zulässig, wenn AKS sowohl die aktuelle Revision als auch die nächste Upgraderevision nicht mehr unterstützt. An diesem Punkt ist das einzige Upgrade, das Ihnen zur Verfügung steht, die niedrigste unterstützte Revision.
Die Istio-Bezeichnung sidecar.istio.io/inject aktiviert keine Sidecar-Injektion für das Istio-Add-On. Sie müssen die istio.io/rev Bezeichnung verwenden, wenn Sie ihre Namespaces während des Canaryupgrades beschriften und neu bezeichnen.
Bezeichnungen müssen auf Namespaceebene statt auf bereitstellungsspezifischer Ebene erfolgen. Wenn Sie in der Lage sein möchten, Pods einzeln zu übertragen, können Sie einzelne Bereitstellungen neu starten, anstatt die Podbezeichnung zu verwenden.
Wenn Sie das Istio-Add-On Shared MeshConfig verwenden, müssen Sie die MeshConfig-Einstellungen kopieren oder in das neue ConfigMap übertragen, bevor Sie ein Canary-Upgrade durchführen. Weitere Informationen finden Sie unter Mesh-Konfiguration und -Upgrades.
Das Istio-Add-On stellt Istio-Gateway-Pods und Bereitstellungen pro Revision bereit. Wenn Sie ein Canaryupgrade durchführen und zwei Überarbeitungen der Steuerebene in Ihrem Cluster installiert haben, müssen Sie möglicherweise mehrere Eingangsgateway-Pods in beiden Überarbeitungen behandeln.

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