Downgrade von Anthos Service Mesh lokal ausführen

In dieser Anleitung wird beschrieben, wie Sie ein Downgrade von Anthos Service Mesh von 1.5.10 auf 1.4.10 in GKE on VMware ausführen.

Achtung: Ein Downgrade ist eine Unterbrechung des Clusters und Sie müssen dies entsprechend planen.

Es dauert fünf bis zehn Minuten, um die Komponenten der Anthos Service Mesh-Steuerungsebene noch einmal bereitzustellen. Außerdem müssen Sie in allen Arbeitslasten neue Sidecar-Proxys einfügen, damit sie mit der aktuellen Anthos Service Mesh-Version aktualisiert werden. Wie lange es dauert, die Sidecar-Proxys zu aktualisieren, hängt von vielen Faktoren ab, z. B. von der Anzahl der Pods, der Anzahl der Knoten, den Skalierungseinstellungen der Bereitstellung, den Budget für Pod-Störungen und anderen Konfigurationseinstellungen. Grob geschätzt dauert die Aktualisierung der Sidecar-Proxys 100 Pods pro Minute.

Übersicht über das Downgrade

In diesem Abschnitt werden die Schritte zum Downgrade von Anthos Service Mesh beschrieben.

1. Prüfen Sie die Unterstützten Features und diese Anleitung, um sich mit den Features und dem Downgradeprozess vertraut zu machen.

2. Wenn Sie bei der Installation der vorherigen Version von Anthos Service Mesh optionale Features aktiviert haben, müssen Sie dieselben Features beim Downgrade aktivieren. Sie aktivieren optionale Features, indem Sie --set values-Flags hinzufügen oder das Flag -f mit einer YAML-Datei angeben, wenn Sie den Befehl istioctl apply ausführen.

   Achtung: Wenn Sie die Flags --set values oder -f in der YAML-Datei weglassen, führt dies zu einer erfolgreichen Installation. Allerdings ist die Konfiguration anders als beabsichtigt, da die ausgelassenen Werte auf die Standardwerte zurückgesetzt werden, wenn Anthos Service Mesh noch einmal bereitgestellt wird. Sie müssen dieselben Flags verwenden, wenn Sie istioctl apply ausführen, um ein Downgrade auf 1.5.10 durchzuführen.

   Wenn Sie von Anthos Service Mesh 1.5.10 aus ein Downgrade zu 1.4.10 ausführen und in einer YAML-Datei optionale Features aktiviert haben, müssen Sie die YAML-Datei der IstioOperator API in die der IstioControlPlane API konvertieren.

3. Planen Sie eine Ausfallzeit. Das Downgrade kann je nach Größe des Clusters bis zu einer Stunde dauern. Beachten Sie, dass hier nicht die Zeit inkludiert ist, die Sie zum erneuten Bereitstellen von Arbeitslasten zum Aktualisieren von Sidecar-Proxys benötigen.

Umgebung einrichten

Installieren und initialisieren Sie Google Cloud CLI auf Ihrem lokalen Computer.

Hinweis: Das Aktualisieren und Entfernen von Komponenten mithilfe von gcloud components ist deaktiviert, wenn Sie die gcloud CLI mit apt-get oder yum installieren. Zum Verwalten der gcloud CLI müssen Sie in diesem Fall weiterhin das Paketverwaltungstool verwenden, das Sie bei der Installation verwendet haben, um Komponenten zu aktualisieren oder zu entfernen.

Wenn die gcloud CLI bereits installiert ist:

1. Authentifizieren Sie sich über die gcloud CLI:

   gcloud auth login
   

2. Aktualisieren Sie die Komponenten:

   gcloud components update
   

3. Installieren Sie kubectl:

   gcloud components install kubectl
   

4. Rufen Sie die Projekt-ID des Projekts ab, in dem der Cluster erstellt wurde:

   gcloud

   gcloud projects list

   Console

   1. Öffnen Sie in der Google Cloud Console die Seite Dashboard:

      Zur Seite "Dashboard"

   2. Klicken Sie oben auf der Seite auf das Drop-down Auswählen aus. Wählen Sie im angezeigten Fenster Auswählen aus Ihr Projekt aus. Die Projekt-ID wird auf der Dashboard-Karte Projektinformationen des Projekts angezeigt.

5. Legen Sie das Standardprojekt-ID für das Google Cloud CLI fest:

   gcloud config set project PROJECT_ID

Anmeldedaten und Berechtigungen festlegen

1. Prüfen Sie, ob kubectl für den Nutzercluster von GKE on VMware vorhanden ist, in dem Sie Anthos Service Mesh installieren möchten. Sie können Anthos Service Mesh nur auf einem Nutzercluster und nicht auf einem Administratorcluster installieren.
2. Gewähren Sie dem aktuellen Nutzer Cluster-Administratorberechtigungen. Sie benötigen diese Berechtigungen, um die erforderlichen Regeln für die rollenbasierte Zugriffssteuerung (Role Based Access Control, RBAC) für Anthos Service Mesh zu erstellen:

   kubectl create clusterrolebinding cluster-admin-binding \
     --clusterrole=cluster-admin \
     --user="$(gcloud config get-value core/account)"

   Wenn der Fehler "cluster-admin-binding" already exists angezeigt wird, können Sie ihn ignorieren und mit der vorhandenen Cluster-Administratorbindung fortfahren.

Installationsdatei herunterladen

Linux

Laden Sie die Anthos Service Mesh-Installationsdatei in Ihr aktuelles Arbeitsverzeichnis herunter:

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.4.10-asm.18-linux.tar.gz

Laden Sie die Signaturdatei herunter und bestätigen Sie die Signatur mit openssl:

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.4.10-asm.18-linux.tar.gz.1.sig
openssl dgst -verify - -signature istio-1.4.10-asm.18-linux.tar.gz.1.sig istio-1.4.10-asm.18-linux.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

Die erwartete Ausgabe ist Verified OK.

Entpacken Sie die Inhalte der Datei in einem Verzeichnis Ihres Dateisystems. So extrahieren Sie beispielsweise den Inhalt in das aktuelle Arbeitsverzeichnis:

tar xzf istio-1.4.10-asm.18-linux.tar.gz

Mit dem Befehl wird in Ihrem aktuellen Arbeitsverzeichnis istio-1.4.10-asm.18 ein Installationsverzeichnis erstellt, das Folgendes enthält:

• Beispielanwendungen in samples
• Die folgenden Tools im Verzeichnis bin:
  • istioctl: Sie verwenden istioctl, um Anthos Service Mesh zu installieren.
  • asmctl: Sie verwenden asmctl, um Ihre Sicherheitskonfiguration nach der Installation von Anthos Service Mesh zu validieren. (Derzeit wird asmctl in GKE on VMware nicht unterstützt.)

macOS

Laden Sie die Anthos Service Mesh-Installationsdatei in Ihr aktuelles Arbeitsverzeichnis herunter:

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.4.10-asm.18-osx.tar.gz

Laden Sie die Signaturdatei herunter und bestätigen Sie die Signatur mit openssl:

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.4.10-asm.18-osx.tar.gz.1.sig
openssl dgst -sha256 -verify /dev/stdin -signature istio-1.4.10-asm.18-osx.tar.gz.1.sig istio-1.4.10-asm.18-osx.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

Die erwartete Ausgabe ist Verified OK.

Entpacken Sie die Inhalte der Datei in einem Verzeichnis Ihres Dateisystems. So extrahieren Sie beispielsweise den Inhalt in das aktuelle Arbeitsverzeichnis:

tar xzf istio-1.4.10-asm.18-osx.tar.gz

Mit dem Befehl wird in Ihrem aktuellen Arbeitsverzeichnis istio-1.4.10-asm.18 ein Installationsverzeichnis erstellt, das Folgendes enthält:

• Beispielanwendungen in samples
• Die folgenden Tools im Verzeichnis bin:
  • istioctl: Sie verwenden istioctl, um Anthos Service Mesh zu installieren.
  • asmctl: Sie verwenden asmctl, um Ihre Sicherheitskonfiguration nach der Installation von Anthos Service Mesh zu validieren. (Derzeit wird asmctl in GKE on VMware nicht unterstützt.)

Windows

Laden Sie die Anthos Service Mesh-Installationsdatei in Ihr aktuelles Arbeitsverzeichnis herunter:

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.4.10-asm.18-win.zip

Laden Sie die Signaturdatei herunter und bestätigen Sie die Signatur mit openssl:

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.4.10-asm.18-win.zip.1.sig
openssl dgst -verify - -signature istio-1.4.10-asm.18-win.zip.1.sig istio-1.4.10-asm.18-win.zip <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

Die erwartete Ausgabe ist Verified OK.

Entpacken Sie die Inhalte der Datei in einem Verzeichnis Ihres Dateisystems. So extrahieren Sie beispielsweise den Inhalt in das aktuelle Arbeitsverzeichnis:

tar xzf istio-1.4.10-asm.18-win.zip

Mit dem Befehl wird in Ihrem aktuellen Arbeitsverzeichnis istio-1.4.10-asm.18 ein Installationsverzeichnis erstellt, das Folgendes enthält:

• Beispielanwendungen in samples
• Die folgenden Tools im Verzeichnis bin:
  • istioctl: Sie verwenden istioctl, um Anthos Service Mesh zu installieren.
  • asmctl: Sie verwenden asmctl, um Ihre Sicherheitskonfiguration nach der Installation von Anthos Service Mesh zu validieren. (Derzeit wird asmctl in GKE on VMware nicht unterstützt.)

1. Prüfen Sie, ob Sie sich im Stammverzeichnis der Anthos Service Mesh-Installation befinden.

   cd istio-1.4.10-asm.18

2. Fügen Sie die Tools der Einfachheit halber im Verzeichnis /bin Ihrem PATH hinzu.

   export PATH=$PWD/bin:$PATH

Downgrade von Anthos Service Mesh durchführen

In diesem Abschnitt wird erläutert, wie Sie ein Downgrade für Anthos Service Mesh durchführen und die unterstützten Standardfeatures aktivieren, die auf der Seite Unterstützte Features aufgeführt sind. Informationen zum Aktivieren der unterstützten optionalen Features finden Sie unter Optionale Features aktivieren.

So installieren Sie Anthos Service Mesh:

Wählen Sie einen der folgenden Befehle aus, um Anthos Service Mesh im mTLS-Authentifizierungsmodus (mutual TLS, gegenseitiges TLS) PERMISSIVE oder im mTLS-Modus STRICT zu konfigurieren.

PERMISSIVE-mTLS

istioctl manifest apply --set profile=asm-onprem

Achtung: Dienste können im Modus PERMISSIVE gleichzeitig Klartext-Traffic und mTLS-Traffic akzeptieren und standardmäßig Klartext-Traffic innerhalb von Mesh-Netzwerken senden. Um Ihr Service Mesh nach dem Downgrade zu sichern, migrieren Sie die Dienste in den gegenseitigen TLS-Modus STRICT, wie unter mTLS-Migration beschrieben.

STRICT-mTLS

istioctl manifest apply --set profile=asm-onprem \
  --set values.global.mtls.enabled=true

Komponenten der Steuerungsebene prüfen

Beim Downgrade müssen die Komponenten der Steuerungsebene neu installiert werden. Das dauert etwa fünf bis zehn Minuten. Die alten Komponenten der Steuerungsebene werden beendet und bei der Installation der neuen Komponenten gelöscht. Sie können den Fortschritt mithilfe des Werts in der Spalte AGE der Arbeitslasten prüfen.

kubectl get pod -n istio-system

Beispielausgabe

NAME                                      READY   STATUS       RESTARTS   AGE
istio-citadel-64f6d7c7c7-jtmw7            1/1     Running      0          38s
istio-galley-6b4878d445-c4rtt             1/2     Running      0          37s
istio-ingressgateway-7866c5c88f-llp28     0/1     Running      0          37s
istio-ingressgateway-7866c5c88f-m9sck     1/1     Terminating  0          25m
istio-pilot-7f4fdcb89c-r98jl              1/2     Running      0          37s
istio-sidecar-injector-65cbd565b9-q4wm9   1/1     Running      0          37s
promsd-78dfdf7c7d-2bhr6                   2/2     Running      1          37s

In diesem Beispiel gibt es zwei Instanzen von istio-ingressgateway. Die Instanz mit 25m in der Spalte AGE wird beendet. Alle anderen Komponenten werden neu installiert.

Sidecar-Proxys aktualisieren

Alle Arbeitslasten, die vor dem Downgrade von Anthos Service Mesh auf Ihrem Cluster ausgeführt wurden, müssen den Sidecar-Proxy enthalten oder er muss für sie aktualisiert worden sein, damit sie die aktuelle Anthos Service Mesh-Version haben.

Achtung: Sofern Sie keinen Load-Balancer oder Router für Blau/Grün-Bereitstellungen eingerichtet haben, sollten Sie den Neustart von Pods in einer Staging-Umgebung testen, um zu prüfen, ob Ihre Dienste eine potenzielle Traffic-Unterbrechung verarbeiten können.

Mit der automatischen Sidecar-Einfügung können Sie die Sidecar-Dateien für vorhandene Pods mit einem Pod-Neustart aktualisieren. Wie Sie Pods neu starten, hängt davon ab, ob sie als Teil einer Bereitstellung erstellt wurden.

1. Starten Sie die Bereitstellung neu, wenn Sie eine Bereitstellung verwendet haben. Dadurch werden alle Pods mit Sidecar-Dateien neu gestartet:

   kubectl rollout restart YOUR_DEPLOYMENT -n YOUR_NAMESPACE

   Wenn Sie keine Bereitstellung verwendet haben, löschen Sie die Pods, und sie werden automatisch mit Sidecar-Dateien neu erstellt:

   kubectl delete pod -n YOUR_NAMESPACE --all

2. Prüfen Sie, ob alle Pods im Namespace Sidecar-Dateien eingefügt haben:

   kubectl get pod -n YOUR_NAMESPACE --all

   In der folgenden Beispielausgabe des vorherigen Befehls sehen Sie, dass die Spalte READY zwei Container für jede Ihrer Arbeitslasten enthält: den primären Container und den Container für den Sidecar-Proxy.

   NAME                    READY   STATUS    RESTARTS   AGE
   YOUR_WORKLOAD           2/2     Running   0          20s
   ...