Version 1.9

Anthos Service Mesh lokal aktualisieren

In dieser Anleitung wird erläutert, wie Sie Anthos Service Mesh von Version 1.8 or a 1.9 patch release auf Version 1.9.2 auf Anthos-Clustern auf VMware aktualisieren. Upgrades von früheren Versionen werden nicht unterstützt. Wenn Sie eine ältere Version haben und ein Upgrade durchführen müssen, lesen Sie Upgrade von früheren Versionen.

Es wird empfohlen, ein auf Überarbeitung basierendes Upgrade (auch als „Canary Upgrade“ bezeichnet) zu verwenden, bei dem sowohl die neue als auch die vorherige Version der Steuerungsebene ausgeführt wird, wenn Sie die neue Version mit einem kleinen Prozentsatz Ihrer Arbeitslasten testen. Dieser Ansatz ist sicherer als ein direktes Upgrade, bei dem die neue Version der Steuerungsebene die vorherige Version ersetzt. Beachten Sie, dass istio-ingressgateway direkt aktualisiert wird. Planen Sie deshalb für Ihren Cluster eine gewisse Unterbrechung ein.

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 Budgets für Pod-Unterbrechungen und anderen Konfigurationseinstellungen. Grob geschätzt dauert die Aktualisierung der Sidecar-Proxys 100 Pods pro Minute.

Upgrade vorbereiten

Wenn Sie die vorherige Installation angepasst haben, müssen Sie diese Anpassung nach dem Upgrade von Anthos Service Mesh übernehmen. Wenn Sie die Installation durch Hinzufügen des Flags --set values zu istioctl install angepasst haben, empfehlen wir, diese Einstellung in eine IstioOperator-YAML-Datei einzufügen. Sie können aber auch weiterhin das Flag --set_values verwenden. Zur Anpassung der Installation geben Sie das Flag -f mit einer YAML-Datei an, wenn Sie den Befehl istioctl install ausführen.

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
  • Das Cloud SDK (das gcloud-Befehlszeilentool)

Nach der Installation des Cloud SDK:

  1. Authentifizieren Sie sich beim Cloud SDK:

    gcloud auth login
    
  2. Aktualisieren Sie die Komponenten:

    gcloud components update
    
  3. Installieren Sie kubectl:

    gcloud components install kubectl
    
  4. Installieren Sie kpt:

    gcloud components install kpt
    
  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.9.2-asm.1-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.9.2-asm.1-linux-amd64.tar.gz.1.sig
    openssl dgst -verify /dev/stdin -signature istio-1.9.2-asm.1-linux-amd64.tar.gz.1.sig istio-1.9.2-asm.1-linux-amd64.tar.gz <<'EOF'
    -----BEGIN PUBLIC KEY-----
    MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
    wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
    -----END PUBLIC KEY-----
    EOF

    Die erwartete Ausgabe ist 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.9.2-asm.1-linux-amd64.tar.gz

    Mit diesem Befehl wird in Ihrem aktuellen Arbeitsverzeichnis istio-1.9.2-asm.1 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.9.2-asm.1
  5. macOS

  6. Laden Sie die Anthos Service Mesh-Installationsdatei in Ihr aktuelles Arbeitsverzeichnis herunter:
    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.9.2-asm.1-osx.tar.gz
  7. Laden Sie die Signaturdatei herunter und bestätigen Sie die Signatur mit openssl:
    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.9.2-asm.1-osx.tar.gz.1.sig
    openssl dgst -sha256 -verify /dev/stdin -signature istio-1.9.2-asm.1-osx.tar.gz.1.sig istio-1.9.2-asm.1-osx.tar.gz <<'EOF'
    -----BEGIN PUBLIC KEY-----
    MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
    wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
    -----END PUBLIC KEY-----
    EOF

    Die erwartete Ausgabe ist Verified OK.

  8. 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.9.2-asm.1-osx.tar.gz

    Mit diesem Befehl wird in Ihrem aktuellen Arbeitsverzeichnis istio-1.9.2-asm.1 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.

  9. Prüfen Sie, ob Sie sich im Stammverzeichnis der Anthos Service Mesh-Installation befinden.
    cd istio-1.9.2-asm.1
  10. Windows

  11. Laden Sie die Anthos Service Mesh-Installationsdatei in Ihr aktuelles Arbeitsverzeichnis herunter:
    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.9.2-asm.1-win.zip
  12. Laden Sie die Signaturdatei herunter und bestätigen Sie die Signatur mit openssl:
    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.9.2-asm.1-win.zip.1.sig
    openssl dgst -verify - -signature istio-1.9.2-asm.1-win.zip.1.sig istio-1.9.2-asm.1-win.zip <<'EOF'
    -----BEGIN PUBLIC KEY-----
    MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
    wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
    -----END PUBLIC KEY-----
    EOF

    Die erwartete Ausgabe ist Verified OK.

  13. 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.9.2-asm.1-win.zip

    Mit diesem Befehl wird in Ihrem aktuellen Arbeitsverzeichnis istio-1.9.2-asm.1 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.

  14. Prüfen Sie, ob Sie sich im Stammverzeichnis der Anthos Service Mesh-Installation befinden.
    cd istio-1.9.2-asm.1

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 auf die neue 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.9-asm asm
    
  3. Setzen Sie das Tag auf die Version des Anthos Service Mesh, das Sie installieren:

    kpt cfg set asm anthos.servicemesh.tag 1.9.2-asm.1
    
  4. Legen Sie den Validierungs-Webhook so fest, dass er ein Überarbeitungslabel verwendet:

    kpt cfg set asm anthos.servicemesh.rev asm-192-1
    

    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.9.2-asm.1. Der istioctl-Client hängt von der Version ab. Sie müssen die Version im Verzeichnis istio-1.9.2-asm.1/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 \
      -f asm/istio/options/revisioned-istio-ingressgateway.yaml \
      --set revision=asm-192-1

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-192-1
    istio-ingressgateway-asm-182-2-8b5fc8767-hn4w2   1/1     Running   0          20s   asm-192-1
    istiod-asm-176-1-67998f4b55-lrzpz                1/1     Running   0          68m   asm-183-2
    istiod-asm-176-1-67998f4b55-r76kr                1/1     Running   0          68m   asm-183-2
    istiod-asm-182-2-5cd96f88f6-n7tj9                1/1     Running   0          27s   asm-192-1
    istiod-asm-182-2-5cd96f88f6-wm68b                1/1     Running   0          27s   asm-192-1
    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-192-1.

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

  2. Legen Sie für istio-ingressgateway die neue Überarbeitung fest. Ändern Sie im folgenden Befehl REVISION in den Wert, der dem Überarbeitungslabel der neuen Version entspricht.

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

    Erwartete Ausgabe: service/istio-ingressgateway patched

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

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

    kubectl rollout restart deployment -n NAMESPACE
  5. Ü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
  6. Testen Sie die Anwendung, um zu prüfen, ob die Arbeitslasten ordnungsgemäß funktionieren.

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

  8. 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. 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. Ersetzen Sie im folgenden Befehl OLD_REVISION durch das Überarbeitungslabel für die vorherige Version von istiod.

      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-ingressgatewqy. 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. Stellen Sie die vorherige Version von istio-ingressgateway noch einmal bereit:

      kubectl -n istio-system rollout undo deploy istio-ingressgateway
      

      Erwartete Ausgabe bei erfolgreicher Ausführung:

      deployment.apps/istio-ingressgateway rolled back
    6. 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
      
    7. 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
      
    8. 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
    9. 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