Anthos Service Mesh lokal aktualisieren

Warnung: install_asm- und istioctl install-Befehle werden mit dem Release von Anthos Service Mesh 1.11 verworfen und mit dem 1.12-Release nicht mehr unterstützt. Aktualisieren Sie Ihre Skripts und Tools für die Verwendung von asmcli. Weitere Informationen finden Sie unter Umstellung auf asmcli.

Upgrade vorbereiten

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 beabsichtigt, da die ausgelassenen Werte auf die Standardeinstellungen zurückgesetzt werden, wenn die Steuerungsebene und das Ingress-Gateway neu bereitgestellt werden.

Hinweis: Ein direktes Upgrade mit istioctl upgrade wird für Anthos Service Mesh nicht unterstützt.

Das Skript folgt dem Upgradeprozess Überarbeitung (in der Istio-Dokumentation als „Canary-Upgrade“ bezeichnet). Mit einem Überarbeitungsupgrade installiert das Skript zusätzlich zur vorhandenen Steuerungsebene eine neue Überarbeitung der Steuerungsebene. Bei der Installation der neuen Version enthält das Skript das Label revision, mit dem die neue Steuerungsebene identifiziert wird.

Anschließend migrieren Sie zur neuen Version. Legen Sie dazu für Ihre Arbeitslasten dasselbe revision-Label fest und führen Sie einen rollierenden Neustart durch, um die Proxys noch einmal einzufügen, damit sie die neue Anthos Service Mesh-Version und -Konfiguration verwenden. Bei diesem Ansatz können Sie die Auswirkungen des Upgrades auf einen kleinen Prozentsatz Ihrer Arbeitslasten überwachen. Nachdem Sie Ihre Anwendung getestet haben, können Sie den gesamten Traffic zur neuen Version migrieren. Dieser Ansatz ist viel sicherer als ein direktes Upgrade, bei dem neue Komponenten der Steuerungsebene die vorherige Version ersetzen.

Umgebung einrichten

Sie benötigen die folgenden Tools auf dem Computer, von dem Sie Anthos Service Mesh installieren möchten. Sie können Anthos Service Mesh nur auf einem Nutzercluster und nicht auf einem Administratorcluster installieren.

• curl-Befehlszeilentool
• Google Cloud CLI

Nach der Installation des Google Cloud CLI:

1. Authentifizieren Sie sich mit dem Google Cloud CLI:

   gcloud auth login
   

2. Aktualisieren Sie die Komponenten:

   gcloud components update
   

3. Installieren Sie kubectl:

   gcloud components install kubectl
   

4. Installieren Sie die erforderliche Version von kpt:

      curl -L https://github.com/GoogleContainerTools/kpt/releases/download/v0.39.2/kpt_linux_amd64 > kpt_0_39_2
      chmod +x kpt_0_39_2
      alias kpt="$(readlink -f kpt_0_39_2)"
   

   Hinweis: Verwenden Sie gcloud nicht zum Installieren und Aktualisieren von kpt. Laden Sie die erforderliche Version von kpt herunter.

5. Wechseln Sie den Kontext zu Ihrem Nutzercluster:

   kubectl config use-context CLUSTER_NAME

6. Gewähren Sie dem Nutzerkonto Administratorberechtigungen (Ihre E-Mail-Adresse für die Anmeldung in Google Cloud). 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=USER_ACCOUNT

Installationsdatei herunterladen

Linux

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

   curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.11.8-asm.4-linux-amd64.tar.gz

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

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

   Folgende Ausgabe wird erwartet: Verified OK

3. 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.11.8-asm.4-linux-amd64.tar.gz

   Mit diesem Befehl wird in Ihrem aktuellen Arbeitsverzeichnis istio-1.11.8-asm.4 ein Installationsverzeichnis erstellt, das Folgendes enthält:

   • Beispielanwendungen im Verzeichnis samples.
   • Das istioctl-Befehlszeilentool, mit dem Sie Anthos Service Mesh installieren, befindet sich im Verzeichnis bin.
   • Die Anthos Service Mesh-Konfigurationsprofile befinden sich im Verzeichnis manifests/profiles.

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

   cd istio-1.11.8-asm.4

macOS

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

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

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

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

   Folgende Ausgabe wird erwartet: Verified OK

3. 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.11.8-asm.4-osx.tar.gz

   Mit diesem Befehl wird in Ihrem aktuellen Arbeitsverzeichnis istio-1.11.8-asm.4 ein Installationsverzeichnis erstellt, das Folgendes enthält:

   • Beispielanwendungen im Verzeichnis samples.
   • Das istioctl-Befehlszeilentool, mit dem Sie Anthos Service Mesh installieren, befindet sich im Verzeichnis bin.
   • Die Anthos Service Mesh-Konfigurationsprofile befinden sich im Verzeichnis manifests/profiles.

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

   cd istio-1.11.8-asm.4

Windows

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

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

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

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

   Folgende Ausgabe wird erwartet: Verified OK

3. 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.11.8-asm.4-win.zip

   Mit diesem Befehl wird in Ihrem aktuellen Arbeitsverzeichnis istio-1.11.8-asm.4 ein Installationsverzeichnis erstellt, das Folgendes enthält:

   • Beispielanwendungen im Verzeichnis samples.
   • Das istioctl-Befehlszeilentool, mit dem Sie Anthos Service Mesh installieren, befindet sich im Verzeichnis bin.
   • Die Anthos Service Mesh-Konfigurationsprofile befinden sich im Verzeichnis manifests/profiles.

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

   cd istio-1.11.8-asm.4

Ressourcenkonfigurationsdateien vorbereiten

Wenn Sie den Befehl istioctl install ausführen, fügen Sie die Datei revisioned-custom-ingressgateway.yaml in die Befehlszeile ein. Mit dieser Datei können Sie steuern, wann Sie nach dem Upgrade zur neuen Version von istio-ingressgateway wechseln. Führen Sie die folgenden Schritte aus, um diese Datei herunterzuladen und zu konfigurieren:

1. Wechseln Sie in das Verzeichnis, in das Sie das Paket anthos-service-mesh herunterladen möchten.

2. Laden Sie das Paket herunter:

   kpt pkg get \
   https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages.git/asm@release-1.11 asm
   

3. Setzen Sie das Tag auf die Version des Anthos Service Mesh, das Sie installieren:

   kpt cfg set asm anthos.servicemesh.tag 1.11.8-asm.4
   

4. Legen Sie den Validierungs-Webhook so fest, dass er ein Überarbeitungslabel verwendet:

   kpt cfg set asm anthos.servicemesh.rev asm-1118-4
   

   Wenn Sie Anthos Service Mesh installieren, legen Sie ein Überarbeitungslabel auf istiod fest. Sie müssen für den Validierten Webhook dieselbe Überarbeitung festlegen.

Upgrade von Anthos Service Mesh durchführen

Für die Installation einer neuen Version von Anthos Service Mesh empfehlen wir den revisionsbasierten Upgradeprozess (auch als „Canary Upgrade“ bezeichnet). Mit einem revisionsbasierten Upgrade installieren Sie eine neue Version der Steuerungsebene zusammen mit der vorhandenen Steuerungsebene. Fügen Sie bei der Installation der neuen Version das Label revision ein, das die Version der neuen Steuerungsebene angibt. Jede Überarbeitung ist eine vollständige Implementierung der Anthos Service Mesh-Steuerungsebene mit eigenem Deployment und Dienst.

Anschließend migrieren Sie zur neuen Version. Legen Sie dazu für Ihre Arbeitslasten dasselbe revision-Label fest, das auf die neue Steuerungsebene verweist, und führen Sie einen rollierenden Neustart durch, um die neue Anthos Service Mesh-Version in die Proxys einzufügen. Bei diesem Ansatz können Sie die Auswirkungen des Upgrades auf einen kleinen Prozentsatz Ihrer Arbeitslasten überwachen. Nachdem Sie Ihre Anwendung getestet haben, können Sie den gesamten Traffic zur neuen Version migrieren. Dieser Ansatz ist wesentlich sicherer als ein direktes Upgrade, bei dem eine neue Steuerungsebene die vorherige Version der Steuerungsebene ersetzt.

Steuerungsebene aktualisieren

1. Wechseln Sie gegebenenfalls zum Verzeichnis istio-1.11.8-asm.4. Der istioctl-Client ist versionsabhängig. Sie müssen die Version im Verzeichnis istio-1.11.8-asm.4/bin verwenden.

2. Führen Sie den folgenden Befehl aus, um die neue Steuerungsebene bereitzustellen. Wenn Sie ein unterstütztes optionales Feature aktivieren möchten, fügen Sie in der folgenden Befehlszeile -f und den YAML-Dateinamen ein. Weitere Informationen finden Sie unter Optionale Features aktivieren.

   bin/istioctl install \
     --set profile=asm-multicloud \
     --set revision=asm-1118-4

Mit dem Argument --set revision wird das Label istio.io/rev zu istiod hinzugefügt. Nach der Ausführung des Befehls haben Sie für die Steuerungsebene zwei Deployments und Dienste, die nebeneinander ausgeführt werden:

kubectl get pods -n istio-system

Arbeitslasten bereitstellen und neu bereitstellen

1. Rufen Sie das Revisionslabel ab, das sich auf istiod und dem istio-ingressgateway befindet.

   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
   istio-ingressgateway-65d884685d-6hrdk            1/1     Running   0          67m
   istio-ingressgateway-65d884685d-94wgz            1/1     Running   0          67m
   istio-ingressgateway-asm-182-2-8b5fc8767-gk6hb   1/1     Running   0          5s    asm-1118-4
   istio-ingressgateway-asm-182-2-8b5fc8767-hn4w2   1/1     Running   0          20s   asm-1118-4
   istiod-asm-176-1-67998f4b55-lrzpz                1/1     Running   0          68m   asm-1107-1
   istiod-asm-176-1-67998f4b55-r76kr                1/1     Running   0          68m   asm-1107-1
   istiod-asm-182-2-5cd96f88f6-n7tj9                1/1     Running   0          27s   asm-1118-4
   istiod-asm-182-2-5cd96f88f6-wm68b                1/1     Running   0          27s   asm-1118-4

   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-1118-4.

   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-1107-1.

2. Fügen Sie das Überarbeitungslabel einem Namespace hinzu und entfernen Sie das istio-injection-Label (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. Testen Sie die Anwendung, um zu prüfen, ob die Arbeitslasten ordnungsgemäß funktionieren.

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

6. 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 das alte istio-ingressgateway-Deployment. Der Befehl, den Sie ausführen, hängt davon ab, ob Sie von Istio migrieren oder ein Upgrade von einer vorherigen Version von Anthos Service Mesh durchführen:

      Migrieren

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

      kubectl delete deploy/istio-ingressgateway -n istio-system
      

      Upgrade

      Wenn Sie ein Upgrade von einer früheren Anthos Service Mesh-Version durchgeführt haben, ersetzen Sie im folgenden Befehl OLD_REVISION durch das Überarbeitungslabel für die vorherige Version von istio-ingressgateway.

      kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=OLD_REVISION -n istio-system --ignore-not-found=true
      

   4. 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
      

   5. 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. Wechseln Sie zurück zur alten Version von istio-ingressgateway. Ersetzen Sie im folgenden Befehl OLD_REVISION durch die vorherige Version.

      kubectl patch service -n istio-system istio-ingressgateway --type='json' -p='[{"op": "replace", "path": "/spec/selector/service.istio.io~1canonical-revision", "value": "OLD_REVISION"}]'
      

   2. 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

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

      kubectl get ns NAMESPACE --show-labels
      

   4. 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
      

   5. Entfernen Sie das neue istio-ingressgateway-Deployment. Achten Sie darauf, dass der Wert von REVISION im folgenden Befehl korrekt ist.

      kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=REVISION -n istio-system --ignore-not-found=true
      

   6. 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
      

   7. 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

   8. 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.

Nächste Schritte

• Cluster zu Anthos Service Mesh lokal hinzufügen
• Einbindung von Drittanbieter-Add-ons