Version 1.8

Anthos Service Mesh auf die neueste Version aktualisieren

Auf dieser Seite wird erläutert, wie Sie das Skript ausführen, mit dem Anthos Service Mesh von Version 1.7.3+ or a 1.8 patch release auf Version 1.8.3 in einem GKE-Cluster für ein Mesh-Netzwerk aktualisiert wird, das einen oder mehrere Cluster im selben Cloud-Projekt enthält.

Diese Seite behandelt das Upgrade von Anthos Service Mesh. Informationen zum Ausführen des Skripts für neue Installationen und für Migrationen von Istio finden Sie unter:

Hinweis

Damit Sie mit dem Upgrade beginnen können, muss Folgendes ausgeführt sein:

Für das Skript müssen entweder die erforderlichen Berechtigungen vorhanden sein oder Sie müssen das Flag --enable_all oder --enable_gcp_iam_roles hinzufügen, damit das Skript die Berechtigung für Sie aktivieren kann. Ebenso müssen Sie das Flag --enable_all oder die detaillierteren Aktivierungsflags angeben, damit das Skript die erforderlichen APIs aktivieren und Ihren Cluster aktualisieren kann.

Upgrade vorbereiten

Wenn Sie die vorherige Installation angepasst haben, müssen Sie diese Anpassung nach dem Upgrade auf Anthos Service Mesh übernehmen. Wenn Sie die Installation durch Hinzufügen des Flags --set values zu istioctl install angepasst haben, müssen Sie diese Einstellungen einer IstioOperator-Overlay-Datei hinzufügen. Sie geben die Overlay-Datei mit der Option --custom_overlay mit dem Dateinamen beim Ausführen des Skripts an.

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 Version der Steuerungsebene (istiod). Bei der Installation der neuen Version enthält das Skript das Label revision für die Version der neuen Steuerungsebene. Jede Überarbeitung ist eine vollständige Implementierung der Steuerungsebene mit einem eigenen 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.

Upgrade von Anthos Service Mesh durchführen

  1. Legen Sie die Optionen fest und geben Sie die Flags für die Ausführung des Skripts an. Sie verwenden immer folgende Optionen: project_id, cluster_name, cluster_location und mode.

    Der folgende Abschnitt enthält typische Beispiele für das Ausführen des Skripts. In der Navigationsleiste auf der rechten Seite finden Sie eine Liste der Beispiele. Eine vollständige Beschreibung der Argumente des Skripts erhalten Sie unter Option und Flags.

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

Beispiele

Dieser Abschnitt enthält Beispiele zur Ausführung des Skripts für Upgrades sowie einige zusätzliche Argumente, die für Sie hilfreich sein können. In der Navigationsleiste auf der rechten Seite finden Sie eine Liste der Beispiele.

Nur validieren

Das folgende Beispiel zeigt die Ausführung des Skripts mit der Option --only_validate. Mit dieser Option nimmt das Skript keine Änderungen an Ihrem Projekt oder Cluster vor und installiert Anthos Service Mesh nicht. Wenn Sie --only_validate angeben, schlägt das Skript fehl, wenn Sie eines der --enable_*-Flags verwenden.

Das Skript prüft, ob Folgendes gegeben ist:

  • Ihre Umgebung enthält die erforderlichen Tools.
  • Sie haben die erforderliche Berechtigung für das angegebene Projekt.
  • Der Cluster erfüllt die Mindestanforderungen.
  • Für das Projekt sind alle erforderlichen Google APIs aktiviert.

Standardmäßig lädt das Skript die Installationsdatei herunter und extrahiert sie. Außerdem lädt es das GitHub-Konfigurationspaket asm in ein temporäres Verzeichnis herunter. Vor dem Beenden gibt das Skript eine Nachricht mit dem Namen des temporären Verzeichnisses aus. Mit der Option --output_dir DIR_PATH können Sie ein vorhandenes Verzeichnis für die Downloads angeben. Die Option --output_dir gibt Ihnen die Möglichkeit, bei Bedarf auf einfache Weise das istioctl-Befehlszeilentool zu verwenden. Außerdem sind die Konfigurationsdateien zum Aktivieren optionaler Features im Verzeichnis asm/istio/options enthalten.

Führen Sie den folgenden Befehl aus, um Ihre Konfiguration zu validieren und um die Installationsdatei sowie das Paket asm in das Verzeichnis OUTPUT_DIR herunterzuladen:

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode upgrade \
  --output_dir DIR_PATH \
  --only_validate

Bei Erfolg gibt das Skript Folgendes aus:

./install_asm \
install_asm: Setting up necessary files...
install_asm: Creating temp directory...
install_asm: Generating a new kubeconfig...
install_asm: Checking installation tool dependencies...
install_asm: Downloading ASM..
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 57.0M  100 57.0M    0     0  30.6M      0  0:00:01  0:00:01 --:--:-- 30.6M
install_asm: Downloading ASM kpt package...
fetching package /asm from https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages to asm
install_asm: Checking for project PROJECT_ID...
install_asm: Confirming cluster information...
install_asm: Confirming node pool requirements...
install_asm: Fetching/writing GCP credentials to kubeconfig file...
Fetching cluster endpoint and auth data.
kubeconfig entry generated for cluster-1.
install_asm: Checking Istio installations...
install_asm: Checking required APIs...
install_asm: Successfully validated all requirements to install ASM from this computer.

Wenn einer der Tests die Validierung nicht besteht, gibt das Skript eine Fehlermeldung aus. Wenn bei Ihrem Projekt beispielsweise nicht alle erforderlichen Google APIs aktiviert sind, wird der folgende Fehler angezeigt:

ERROR: One or more APIs are not enabled. Please enable them and retry, or run
the script with the '--enable_gcp_apis' flag to allow the script to enable them
on your behalf.

Falls Sie eine Fehlermeldung erhalten haben, dass Sie das Skript mit einem Aktivierungsflag ausführen müssen, können Sie das spezifische Flag aus der Fehlermeldung oder das Flag --enable_all angeben, wenn das Skript ohne --only_validate ausgeführt wird. Sie können Ihr Projekt und Ihren Cluster auch selbst aktualisieren, bevor Sie das Skript ausführen, wie in den Abschnitten Projekt einrichten und Cluster einrichten der Anleitung für die Installation mehrerer Projekte beschrieben.

Upgrade ausführen

Mit dem folgenden Befehl wird das Skript für das Upgrade ausgeführt. Sie können die Zertifizierungsstelle bei diesem Skript nicht in eine andere Zertifizierungsstelle ändern. Deshalb ist die Option ca nicht erforderlich.

./install_asm \
  --project_id  PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode upgrade \
  --enable_all

Upgrade mit einer Overlay-Datei ausführen

Eine Overlay-Datei ist eine YAML-Datei mit einer benutzerdefinierten IstioOperator-Ressource, die Sie an install_asm ü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 install_asm übergeben. Sie können mehr Overlays übereinander legen. Jede Overlay-Datei überschreibt die Konfiguration auf den vorherigen Ebenen.

Wenn Sie mehr als eine Antwortvorlage in einer YAML-Datei angeben, teilt install_asm die Datei in mehrere temporäre YAML-Dateien auf, eine für jede Antwortvorlage. Das Skript teilt die CRs in separate Dateien auf, weil istioctl install nur die erste Antwortvorlage in einer YAML-Datei anwendet, die mehr als eine Antwortvorlage enthält.

Das folgende Beispiel führt ein Upgrade durch und fügt eine Overlay-Datei ein, um die Konfiguration der Steuerungsebene anzupassen. Mit dem folgenden Befehl ändern Sie OVERLAY_FILE in den Namen der YAML-Datei.

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode upgrade \
  --enable_all \
  --custom_overlay OVERLAY_FILE

Upgrade mit einer Option

Im folgenden Beispiel wird ein Upgrade ausgeführt und die Datei egressgateways.yaml aus dem Paket anthos-service-mesh eingebunden. Dies aktiviert ein Gateway für ausgehenden Traffic. Beachten Sie, dass die .yaml-Erweiterung nicht angegeben ist. Das Skript ruft die Datei für Sie ab, sodass Sie das Paket asm nicht zuvor herunterladen müssen.

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode upgrade \
  --enable_all \
  --option egressgateways

Mit --option können Sie ein optionales Feature aktivieren. Wenn Sie Änderungen an einer Datei im Verzeichnis asm/istio/options des Pakets asm vornehmen müssen, laden Sie das asm-Paket herunter, führen die gewünschten Änderungen aus und binden die Datei mit --custom_overlay ein.

So laden Sie das Paket asm in das aktuelle Arbeitsverzeichnis herunter, damit Sie Änderungen an den Dateien vornehmen können:

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

Wenn Sie das Beispiel Nur validieren ausgeführt und die Option --output_dir angegeben haben, befinden sich die Konfigurationsdateien im angegebenen Ausgabeverzeichnis unter asm/istio/options.

Arbeitslasten bereitstellen und neu bereitstellen

Die Installation ist erst abgeschlossen, wenn Sie die automatische Sidecar-Proxy-Injektion aktivieren (automatische Injektion). Migrationen von OSS Istio sowie Upgrades folgen einem revisionsbasierten Upgradevorgang. Dieser wird in der Istio-Dokumentation als „Canary-Upgrade“ bezeichnet. Bei einem revisionsbasierten Upgrade wird die neue Version von istiod zusammen mit der vorhandenen istiod-Version installiert. Anschließend verschieben Sie einige Ihrer Arbeitslasten auf die neue Version. Damit können Sie die Auswirkungen des Upgrades mit einem kleinen Prozentsatz der Arbeitslasten prüfen, bevor Sie den gesamten Traffic zur neuen Version migrieren.

Mit dem Skript wird ein Überarbeitungslabel im Format istio.io/rev=asm-183-2 zu istiod hinzugefügt. Zur Aktivierung der automatischen Injektion fügen Sie zu Ihren Namespaces ein entsprechendes Überarbeitungslabel hinzu. Das Überarbeitungslabel wird vom Sidecar-Injektor-Webhook verwendet, um eingefügte Sidecars mit einer bestimmten istiod-Überarbeitung zu verknüpfen. Nachdem Sie das Label hinzugefügt haben, starten Sie die Pods im Namespace neu, damit die Sidecars eingefügt werden.

Automatische Injektion aktivieren

So aktivieren Sie die automatische Injektion:

  1. Legen Sie den aktuellen Kontext für kubectl fest:

    gcloud container clusters get-credentials CLUSTER_NAME \
        --project=PROJECT_ID
    
  2. Verwenden Sie den folgenden Befehl, um das Überarbeitungslabel für istiod zu finden:

    kubectl -n istio-system get pods -l app=istiod --show-labels
    

    Die Ausgabe des Befehls sieht in etwa so aus: Beachten Sie, dass sich die Ausgabe für Migrationen geringfügig von der Ausgabe für Upgrades unterscheidet. Die folgende Beispielausgabe stammt von einer Migration.

    NAME                                READY   STATUS    RESTARTS   AGE   LABELS
    istiod-7744bc8dd7-qhlss             1/1     Running   0          49m   app=istiod,istio.io/rev=default,istio=pilot,pod-template-hash=7744bc8dd7
    istiod-asm-183-2-85d86774f7-flrt2   1/1     Running   0          26m   app=istiod,istio.io/rev=asm-183-2,istio=istiod,pod-template-hash=85d86774f7
    istiod-asm-183-2-85d86774f7-tcwtn   1/1     Running   0          26m   app=istiod,istio.io/rev=asm-183-2,istio=istiod,pod-template-hash=85d86774f7
    1. Notieren Sie sich aus der Ausgabe in der Spalte LABELS den Wert des istiod-Überarbeitungslabels für die neue Version, der auf das Präfix istio.io/rev= folgt. In diesem Beispiel lautet der Wert asm-183-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 im Überarbeitungslabel für die alte istiod-Version default.

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

Anthos Service Mesh-Dashboards aufrufen

Nachdem Sie Arbeitslasten mit den eingefügten Sidecar-Proxys auf Ihrem Cluster bereitgestellt haben, können Sie die Anthos Service Mesh-Seiten in der Cloud Console entdecken, um alle Beobachtbarkeitsfunktionen von Anthos Service Mesh zu sehen. Nach der Bereitstellung von Arbeitslasten dauert es etwa ein oder zwei Minuten, bis Telemetriedaten in der Cloud Console angezeigt werden.

Der Zugriff auf Anthos Service Mesh in der Cloud Console wird durch die Identitäts- und Zugriffsverwaltung (IAM) gesteuert. Für den Zugriff auf Anthos Service Mesh-Seiten muss ein Projektinhaber den Nutzern die Rolle "Projektbearbeiter" oder "Betrachter" oder die unter Zugriff auf Anthos Service Mesh in der Cloud Console steuern beschriebenen restriktiveren Rollen gewähren.

  1. Wechseln Sie in der Google Cloud Console zu Anthos Service Mesh.

    Zur Seite "Anthos Service Mesh"

  2. Wählen Sie das Cloud-Projekt aus der Drop-down-Liste in der Menüleiste aus.

  3. Wenn Sie mehr als ein Service Mesh haben, wählen Sie das Mesh aus der Drop-down-Liste Service Mesh aus.

Weitere Informationen finden Sie unter Mit Anthos Service Mesh in der Cloud Console vertraut machen.

Zusätzlich zu den Anthos Service Mesh-Seiten werden Messwerte, die sich auf Ihre Dienste beziehen (z. B. die Anzahl der Anfragen, die von einem bestimmten Dienst empfangen wurden), an Cloud Monitoring gesendet, wo sie im Metrics Explorer angezeigt werden.

So rufen Sie Messwerte auf:

  1. Rufen Sie in der Google Cloud Console die Seite Monitoring auf.

    Zu Monitoring

  2. Wählen Sie Ressourcen > Metrics Explorer.

Eine vollständige Liste der Messwerte finden Sie unter Istio-Messwerte in der Cloud Monitoring-Dokumentation.

Nächste Schritte