Upgrade für Anthos Service Mesh durchführen

Vorschau — asmcli

Diese Funktion unterliegt den „Nutzungsbedingungen für Pre-GA-Angebote“ im Abschnitt „Allgemeine Nutzungsbedingungen“ der dienstspezifischen Nutzungsbedingungen. Pre-GA-Funktionen sind „wie besehen“ verfügbar und werden möglicherweise nur eingeschränkt unterstützt. Weitere Informationen finden Sie in den Beschreibungen der Startphase.

Auf dieser Seite erfahren Sie, wie Sie:

• asmcli ausführen, um ein Upgrade von Anthos Service Mesh oder dem Open-Source-Framework Istio 1.9 or a 1.10 patch release auf Anthos Service Mesh 1.10.6 durchzuführen. Upgrades von früheren Versionen werden nicht unterstützt.

• Canary-Upgrade durchführen, um Ihre Arbeitslasten auf die neue Steuerungsebene zu migrieren.

Hinweis: Das Hinzufügen virtueller Compute Engine-Maschinen zum Service Mesh erfordert bestimmte Optionen, wenn Sie Anthos Service Mesh installieren. Eine ausführliche Anleitung finden Sie unter Virtuelle Compute Engine-Maschinen zu Anthos Service Mesh hinzufügen.

Hinweise

Folgende Voraussetzungen müssen Sie erfüllt haben:

• Prüfen Sie die Voraussetzungen. asmcli unterstützt derzeit keine Upgrades von Anthos Service Mesh auf GKE-Clustern in einem Multi-Cluster-Mesh in verschiedenen Projekten, es sei denn, Sie haben Anthos Service Mesh ursprünglich mit asmcli installiert.
• Lesen Sie die Informationen unter Installation planen.
• Installieren Sie die erforderlichen Tools.
• Laden Sie asmcli herunter.
• Erteilen Sie Clusteradministratorberechtigungen.
• Validieren Sie Projekt und Cluster.

Anpassungen der Steuerungsebene

Wenn Sie die vorherige Installation angepasst haben, benötigen Sie dieselben Anpassungen, wenn Sie ein Upgrade auf eine neue Anthos Service Mesh-Version durchführen oder von Istio migrieren. Wenn Sie die Installation angepasst haben, indem Sie istioctl install das Flag --set values hinzugefügt haben, müssen Sie diese Einstellungen in einer YAML-Datei vom Typ IstioOperator hinzufügen, die als Overlay-Datei bezeichnet wird. Sie geben die Overlay-Datei an, indem Sie beim Ausführen des Skripts die Option --custom_overlay mit dem Dateinamen verwenden. Das Skript übergibt die Overlay-Datei an istioctl install.

Achtung: Wird die Overlay-Datei weggelassen, führt dies trotzdem zu einer erfolgreichen Installation. Ihr Service Mesh hat jedoch eine andere Konfiguration, als Sie beabsichtigt haben, da die ausgelassenen Werte auf die Standardeinstellungen zurückgesetzt werden, wenn die Steuerungsebene und das Ingress-Gateway neu bereitgestellt werden.

Zertifizierungsstelle

Das Ändern der Zertifizierungsstelle während eines Upgrades führt zu Ausfallzeiten. Während des Upgrades wird mTLS-Traffic unterbrochen, bis alle Arbeitslasten auf die neue Steuerungsebene mit der neuen Zertifizierungsstelle übertragen wurden.

Upgrade für Anthos Service Mesh durchführen

Im Folgenden wird beschrieben, wie Sie ein Upgrade für Anthos Service Mesh durchführen:

1. Führen Sie asmcli install aus, um Anthos Service Mesh auf einem einzelnen Cluster zu installieren. In den folgenden Abschnitten finden Sie Beispiele für Befehlszeilen. Die Beispiele enthalten sowohl erforderliche Argumente als auch optionale Argumente, die für Sie nützlich sein könnten. Wir empfehlen, immer das Argument output_dir anzugeben, damit Sie Beispielgateways und Tools wie istioctl leicht finden können. In der Navigationsleiste auf der rechten Seite finden Sie eine Liste der Beispiele.

2. Optional können Sie ein Ingress-Gateway installieren oder aktualisieren.

3. Damit die Einrichtung von Anthos Service Mesh abgeschlossen werden kann, müssen Sie die automatische Sidecar-Injektion aktivieren und die Arbeitslasten (noch einmal) bereitstellen.

Upgrade mit Standardfeatures und Mesh CA durchführen

In diesem Abschnitt wird gezeigt, wie Sie asmcli ausführen, um Anthos Service Mesh mit den unterstützten Standardfeatures für Ihre Plattform zu aktualisieren und die Anthos Service Mesh-Zertifizierungsstelle (Mesh CA) als die Zertifizierungsstelle aktivieren.

GKE

Führen Sie den folgenden Befehl aus, um die neue Steuerungsebene mit Standardfeatures zu installieren. Geben Sie Ihre Werte in die angegebenen Platzhalter ein.

./asmcli install \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --fleet_id FLEET_PROJECT_ID \
  --output_dir DIR_PATH \
  --enable_all \
  --ca mesh_ca

• --project_id, --cluster_name und --cluster_location geben die Projekt-ID an, in der sich der Cluster befindet, den Clusternamen und entweder die Clusterzone oder -region.
• --fleet_id: Projekt-ID des Hostprojekts der Flotte. Wenn Sie diese Option nicht angeben, verwendet asmcli das Projekt, in dem der Cluster bei der Registrierung erstellt wurde.
• --output_dir: Fügen Sie diese Option hinzu, um ein Verzeichnis anzugeben, in das asmcli das Paket anthos-service-mesh herunterlädt und in dem die Installationsdatei extrahiert wird, die istioctl, Beispiele und Manifeste enthält. Andernfalls lädt asmcli die Dateien in ein tmp-Verzeichnis herunter. Sie können entweder einen relativen Pfad oder einen vollständigen Pfad angeben. Die Umgebungsvariable $PWD funktioniert hier nicht.
• --enable_all: Ermöglicht dem Skript Folgendes:
  • Erforderliche IAM-Berechtigungen gewähren.
  • Erforderliche Google APIs aktivieren.
  • Im Cluster ein Label festlegen, das das Mesh-Netzwerk identifiziert.
  • Cluster bei der Flotte registrieren, falls noch nicht geschehen.
• --ca mesh_ca Verwendet Mesh CA als Zertifizierungsstelle. Das Ändern der Zertifizierungsstellen während eines Upgrades führt zu Ausfallzeiten. asmcli konfiguriert Mesh CA für die Verwendung der Workload Identity der Flotte.

Lokal

1. Legen Sie Ihren Nutzercluster als aktuellen Kontext fest:

   kubectl config use-context CLUSTER_NAME
   

2. Führen Sie den folgenden Befehl aus, um die neue Steuerungsebene mit Standardfeatures zu installieren. Geben Sie Ihre Werte in die angegebenen Platzhalter ein.

   ./asmcli install \
     --fleet_id FLEET_PROJECT_ID \
     --kubeconfig KUBECONFIG_FILE \
     --output_dir DIR_PATH \
     --platform multicloud \
     --enable_all \
     --ca mesh_ca
   

   • --fleet_id: Projekt-ID des Hostprojekts der Flotte.
   • --kubeconfig Der Pfad zur kubeconfig-Datei. Sie können entweder einen relativen Pfad oder einen vollständigen Pfad angeben. Die Umgebungsvariable $PWD funktioniert hier nicht.
   • --output_dir: Fügen Sie diese Option hinzu, um ein Verzeichnis anzugeben, in das asmcli das Paket anthos-service-mesh herunterlädt und in dem die Installationsdatei extrahiert wird, die istioctl, Beispiele und Manifeste enthält. Andernfalls lädt asmcli die Dateien in ein tmp-Verzeichnis herunter. Sie können entweder einen relativen Pfad oder einen vollständigen Pfad angeben. Die Umgebungsvariable $PWD funktioniert hier nicht.
   • --platform multicloud: Gibt an, dass die Plattform lokal ist.
   • --enable_all: Ermöglicht dem Skript Folgendes:
     • Erforderliche IAM-Berechtigungen gewähren.
     • Erforderliche Google APIs aktivieren.
     • Im Cluster ein Label festlegen, das das Mesh-Netzwerk identifiziert.
     • Cluster bei der Flotte registrieren, falls noch nicht geschehen.
   • --ca mesh_ca Verwendet Mesh CA als Zertifizierungsstelle. Das Ändern von Zertifizierungsstellen während eines Upgrades führt zu Ausfallzeiten. asmclikonfiguriert Mesh CA, um die Flotten-Workload-Identität zu verwenden

Upgrade für Standardfeatures mit Istio CA durchführen

In diesem Abschnitt wird gezeigt, wie Sie asmcli ausführen, um Anthos Service Mesh mit den unterstützten Standardfeatures für Ihre Plattform zu aktualisieren und Istio CA zu aktivieren.

GKE

./asmcli install \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --fleet_id FLEET_PROJECT_ID \
  --output_dir DIR_PATH \
  --enable_all \
  --ca citadel

• --project_id, --cluster_name und --cluster_location geben die Projekt-ID an, in der sich der Cluster befindet, den Clusternamen und entweder die Clusterzone oder -region.
• --fleet_id: Projekt-ID des Hostprojekts der Flotte. Wenn Sie diese Option nicht angeben, verwendet asmcli das Projekt, in dem der Cluster bei der Registrierung erstellt wurde.
• --output_dir: Fügen Sie diese Option hinzu, um ein Verzeichnis anzugeben, in das asmcli das Paket anthos-service-mesh herunterlädt und in dem die Installationsdatei extrahiert wird, die istioctl, Beispiele und Manifeste enthält. Andernfalls lädt asmcli die Dateien in ein tmp-Verzeichnis herunter. Sie können entweder einen relativen Pfad oder einen vollständigen Pfad angeben. Die Umgebungsvariable $PWD funktioniert hier nicht.
• --enable_all: Ermöglicht dem Skript Folgendes:
  • Erforderliche IAM-Berechtigungen gewähren.
  • Erforderliche Google APIs aktivieren.
  • Im Cluster ein Label festlegen, das das Mesh-Netzwerk identifiziert.
  • Den Cluster bei der Flotte registrieren, falls noch nicht geschehen.
• -ca citadel: Istio-Zertifizierungsstelle verwenden. Das Ändern der Zertifizierungsstellen während eines Upgrades führt zu Ausfallzeiten.

Lokal

1. Legen Sie Ihren Nutzercluster als aktuellen Kontext fest:

    kubectl config use-context CLUSTER_NAME
   

2. Führen Sie den folgenden Befehl aus, um Anthos Service Mesh mit Standardfeatures und Istio CA zu installieren:

    ./asmcli install \
      --fleet_id FLEET_PROJECT_ID \
      --kubeconfig KUBECONFIG_FILE \
      --output_dir DIR_PATH \
      --platform multicloud \
      --enable_all \
      --ca citadel \
   

   • --fleet_id: Projekt-ID des Hostprojekts der Flotte.
   • --kubeconfig Der Pfad zur kubeconfig-Datei. Sie können entweder einen relativen Pfad oder einen vollständigen Pfad angeben. Die Umgebungsvariable $PWD funktioniert hier nicht.
   • --output_dir: Fügen Sie diese Option hinzu, um ein Verzeichnis anzugeben, in das asmcli das Paket anthos-service-mesh herunterlädt und in dem die Installationsdatei extrahiert wird, die istioctl, Beispiele und Manifeste enthält. Andernfalls lädt asmcli die Dateien in ein tmp-Verzeichnis herunter. Sie können entweder einen relativen Pfad oder einen vollständigen Pfad angeben. Die Umgebungsvariable $PWD funktioniert hier nicht.
   • --platform multicloud: Gibt an, dass die Plattform lokal ist.
   • --enable_all: Ermöglicht dem Skript Folgendes:
     • Erforderliche IAM-Berechtigungen gewähren.
     • Erforderliche Google APIs aktivieren.
     • Im Cluster ein Label festlegen, das das Mesh-Netzwerk identifiziert.
     • Den Cluster bei der Flotte registrieren, falls noch nicht geschehen.

   • -ca citadel: Istio-Zertifizierungsstelle verwenden. Das Ändern der Zertifizierungsstelle während eines Upgrades führt zu Ausfallzeiten.

Upgrade mit optionalen Features durchführen

Eine Overlay-Datei ist eine YAML-Datei mit einer benutzerdefinierten IstioOperator-Ressource, die Sie an asmcli übergeben, um die Steuerungsebene zu konfigurieren. Sie können die Standardkonfiguration der Steuerungsebene überschreiben und eine optionale Funktion aktivieren, indem Sie die YAML-Datei an asmcli übergeben. Sie können mehr Overlays übereinander legen. Jede Overlay-Datei überschreibt die Konfiguration auf den vorherigen Ebenen.

GKE

Führen Sie den folgenden Befehl aus, um die neue Steuerungsebene mit Standardfeatures zu installieren. Geben Sie Ihre Werte in die angegebenen Platzhalter ein.

./asmcli install \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --fleet_id FLEET_PROJECT_ID \
  --output_dir DIR_PATH \
  --enable_all \
  --ca mesh_ca \
  --custom_overlay OVERLAY_FILE

• --project_id, --cluster_name und --cluster_location geben die Projekt-ID an, in der sich der Cluster befindet, den Clusternamen und entweder die Clusterzone oder -region.
• --fleet_id: Projekt-ID des Hostprojekts der Flotte. Wenn Sie diese Option nicht angeben, verwendet asmcli das Projekt, in dem der Cluster bei der Registrierung erstellt wurde.
• --output_dir: Fügen Sie diese Option hinzu, um ein Verzeichnis anzugeben, in das asmcli das Paket anthos-service-mesh herunterlädt und in dem die Installationsdatei extrahiert wird, die istioctl, Beispiele und Manifeste enthält. Andernfalls lädt asmcli die Dateien in ein tmp-Verzeichnis herunter. Sie können entweder einen relativen Pfad oder einen vollständigen Pfad angeben. Die Umgebungsvariable $PWD funktioniert hier nicht.
• --enable_all: Ermöglicht dem Skript Folgendes:
  • Erforderliche IAM-Berechtigungen gewähren.
  • Erforderliche Google APIs aktivieren.
  • Im Cluster ein Label festlegen, das das Mesh-Netzwerk identifiziert.
  • Cluster bei der Flotte registrieren, falls noch nicht geschehen.
• --ca mesh_ca Verwendet Mesh CA als Zertifizierungsstelle. Das Ändern der Zertifizierungsstellen während eines Upgrades führt zu Ausfallzeiten. asmcli konfiguriert Mesh CA für die Verwendung der Workload Identity der Flotte.
• --custom_overlay: Den Namen der Overlay-Datei angeben.

Lokal

1. Legen Sie Ihren Nutzercluster als aktuellen Kontext fest:

   kubectl config use-context CLUSTER_NAME
   

2. Führen Sie den folgenden Befehl aus, um die neue Steuerungsebene mit Standardfeatures zu installieren. Geben Sie Ihre Werte in die angegebenen Platzhalter ein.

   ./asmcli install \
     --fleet_id FLEET_PROJECT_ID \
     --kubeconfig KUBECONFIG_FILE \
     --output_dir DIR_PATH \
     --platform multicloud \
     --enable_all \
     --ca mesh_ca \
     --custom_overlay OVERLAY_FILE
   

   • --fleet_id: Projekt-ID des Hostprojekts der Flotte.
   • --kubeconfig Der Pfad zur kubeconfig-Datei. Sie können entweder einen relativen Pfad oder einen vollständigen Pfad angeben. Die Umgebungsvariable $PWD funktioniert hier nicht.
   • --output_dir: Fügen Sie diese Option hinzu, um ein Verzeichnis anzugeben, in das asmcli das Paket anthos-service-mesh herunterlädt und in dem die Installationsdatei extrahiert wird, die istioctl, Beispiele und Manifeste enthält. Andernfalls lädt asmcli die Dateien in ein tmp-Verzeichnis herunter. Sie können entweder einen relativen Pfad oder einen vollständigen Pfad angeben. Die Umgebungsvariable $PWD funktioniert hier nicht.
   • --platform multicloud: Gibt an, dass die Plattform lokal ist.
   • --enable_all: Ermöglicht dem Skript Folgendes:
     • Erforderliche IAM-Berechtigungen gewähren.
     • Erforderliche Google APIs aktivieren.
     • Im Cluster ein Label festlegen, das das Mesh-Netzwerk identifiziert.
     • Cluster bei der Flotte registrieren, falls noch nicht geschehen.
   • --ca mesh_ca Verwendet Mesh CA als Zertifizierungsstelle. Das Ändern der Zertifizierungsstellen während eines Upgrades führt zu Ausfallzeiten. asmcli konfiguriert Mesh CA für die Verwendung der Workload Identity der Flotte.
   • --custom_overlay: Den Namen der Overlay-Datei angeben.

Upgrade für Gateways durchführen

Wenn Sie Gateways bereitgestellt haben, müssen Sie diese ebenfalls aktualisieren. Wenn Sie ein einfaches Upgrade vornehmen möchten, lesen Sie den Abschnitt "Direkte Upgrades" im Leitfaden Gateways installieren und aktualisieren.

Warnung: Wenn Sie Anthos Service Mesh mit einer anderen Methode als asmcli installiert haben, wird das standardmäßige installierte Ingress-Gateway entfernt, es sei denn, Sie übergeben die --option legacy-default-ingressgateway-Argument.

Zur neuen Steuerungsebene wechseln

1. Rufen Sie das Überarbeitungslabel auf istiod ab.

   kubectl get pod -n istio-system -L istio.io/rev
   

   Die Ausgabe des Befehls sieht in etwa so aus:

   NAME                                             READY   STATUS    RESTARTS   AGE   REV
   istiod-asm-176-1-67998f4b55-lrzpz                1/1     Running   0          68m   asm-198-3
   istiod-asm-176-1-67998f4b55-r76kr                1/1     Running   0          68m   asm-198-3
   istiod-asm-182-2-5cd96f88f6-n7tj9                1/1     Running   0          27s   asm-1106-2
   istiod-asm-182-2-5cd96f88f6-wm68b                1/1     Running   0          27s   asm-1106-2

   1. Notieren Sie sich in der Ausgabe unter der Spalte REV den Wert des Überarbeitungslabels für die neue Version. In diesem Beispiel ist der Wert asm-1106-2.

   2. Notieren Sie sich außerdem den Wert im Überarbeitungslabel der alten istiod-Version. Diesen Wert benötigen Sie, um die alte Version von istiod zu löschen, wenn Sie die Arbeitslasten in die neue Version verschoben haben. In der Beispielausgabe lautet der Wert für das Überarbeitungslabel der alten Version asm-198-3.

2. Fügen Sie das Überarbeitungslabel zu einem Anwendungs-Namespace hinzu und entfernen Sie das Label istio-injection (falls vorhanden). Geben Sie im folgenden Befehl für REVISION den Wert an, der der neuen Überarbeitung von istiod entspricht.

   kubectl label namespace NAMESPACE istio.io/rev=REVISION istio-injection- --overwrite

   Wenn in der Ausgabe "istio-injection not found" angezeigt wird, können Sie dies ignorieren. Das bedeutet, dass der Namespace bisher nicht das Label istio-injection hatte. Da die automatische Injektion fehlschlägt, wenn ein Namespace sowohl das istio-injection als auch das Überarbeitungslabel enthält, enthalten alle kubectl label-Befehle in der Anthos Service Mesh-Dokumentation das Label istio-injection.

3. Starten Sie die Pods neu, um die erneute Injektion auszulösen.

   kubectl rollout restart deployment -n NAMESPACE

4. Überprüfen Sie, ob Ihre Pods so konfiguriert sind, dass sie auf die neue Version von istiod verweisen.

   kubectl get pods -n NAMESPACE -l istio.io/rev=REVISION

5. Testen Sie die Anwendung, um zu prüfen, ob die Arbeitslasten ordnungsgemäß funktionieren.

6. Wenn Sie Arbeitslasten in anderen Namespaces haben, wiederholen Sie die Schritte, um den Namespace mit einem Label zu versehen und Pods neu zu starten.

7. Wenn Sie sicher sind, dass Ihre Anwendung wie erwartet funktioniert, fahren Sie mit den Schritten für die Umstellung auf die neue Version von istiod fort. Wenn ein Problem mit Ihrer Anwendung auftritt, führen Sie die Schritte zum Rollback aus.

   Umstellung vornehmen

   Wenn Sie sicher sind, dass Ihre Anwendung wie erwartet funktioniert, entfernen Sie die alte Steuerungsebene, um die Umstellung auf die neue Version abzuschließen.

   1. Wechseln Sie in das Verzeichnis, in dem sich die Dateien aus dem GitHub-Repository anthos-service-mesh befinden.

   2. Konfigurieren Sie den validierten Webhook so, dass er die neue Steuerungsebene verwendet.

      kubectl apply -f asm/istio/istiod-service.yaml
      

   3. Löschen Sie die alte Version von istiod. Der verwendete Befehl hängt davon ab, ob Sie von Istio migrieren oder ein Upgrade von einer früheren Version von Anthos Service Mesh durchführen.

      Migrieren

      Wenn Sie von Istio migriert haben, hat die alte istio-ingressgateway-Datei kein Überarbeitungslabel.

      kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod -n istio-system --ignore-not-found=true
      

      Upgrade

      Wenn Sie ein Upgrade von einer früheren Anthos Service Mesh-Version durchgeführt haben, achten Sie im folgenden Befehl darauf, dass OLD_REVISION mit dem Überarbeitungslabel für die vorherige Version von istiod übereinstimmt.

      kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-OLD_REVISION -n istio-system --ignore-not-found=true
      

   4. Entfernen Sie die alte Version der IstioOperator-Konfiguration.

      kubectl delete IstioOperator installed-state-OLD_REVISION -n istio-system
      

      Die erwartete Ausgabe sieht in etwa so aus:

      istiooperator.install.istio.io "installed-state-OLD_REVISION" deleted

   Rollback

   Wenn beim Testen der Anwendung mit der neuen istiod-Version ein Problem auftritt, gehen Sie so vor, um ein Rollback auf die vorherige Version auszuführen:

   1. Benennen Sie Ihren Namespace um, um die automatische Injektion mit der vorherigen Version von istiod zu aktivieren. Der zu verwendende Befehl hängt davon ab, ob Sie ein Überarbeitungslabel oder istio-injection=enabled mit der vorherigen Version verwendet haben.

      • Wenn Sie ein Überarbeitungslabel für die automatische Injektion verwendet haben, führen Sie Folgendes aus:

        kubectl label namespace NAMESPACE istio.io/rev=OLD_REVISION --overwrite
        

      • Wenn Sie istio-injection=enabled verwendet haben, führen Sie Folgendes aus:

        kubectl label namespace NAMESPACE istio.io/rev- istio-injection=enabled --overwrite
        

      Erwartete Ausgabe:

      namespace/NAMESPACE labeled

   2. Prüfen Sie, ob das Überarbeitungslabel im Namespace mit dem Überarbeitungslabel in der vorherigen Version von istiod übereinstimmt:

      kubectl get ns NAMESPACE --show-labels
      

   3. Starten Sie die Pods neu, um die erneute Einfügung auszulösen, damit die Proxys die Istio-Version erhalten:

      kubectl rollout restart deployment -n NAMESPACE
      

   4. Entfernen Sie die neue Version von istiod. Achten Sie darauf, dass der Wert von REVISION im folgenden Befehl korrekt ist.

      kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-REVISION -n istio-system --ignore-not-found=true
      

   5. Entfernen Sie die neue Version der IstioOperator-Konfiguration.

      kubectl delete IstioOperator installed-state-REVISION -n istio-system
      

      Die erwartete Ausgabe sieht in etwa so aus:

      istiooperator.install.istio.io "installed-state-REVISION" deleted

   6. Wenn Sie das Flag --disable_canonical_service nicht angegeben haben, hat das Skript den Canonical Service-Controller aktiviert. Wir empfehlen, ihn aktiviert zu lassen. Falls Sie ihn jedoch deaktivieren müssen, finden Sie weitere Informationen unter Canonical Service-Controller aktivieren und deaktivieren.

   7. Wenn Sie Gateways bereitgestellt haben, ändern Sie das Überarbeitungslabel für den Namespace oder die Bereitstellung entsprechend der vorherigen Version von istiod. Führen Sie den gleichen Vorgang aus, der im Abschnitt "Direkte Upgrades" des Leitfadens Gateways installieren und aktualisieren beschrieben ist.