Anthos Service Mesh auf die neueste Version 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.

Auf dieser Seite wird erläutert, wie Sie das Skript ausführen, um ein Upgrade von einer beliebigen Version und Patchrelease 1.7.0 oder höher auf Anthos Service Mesh 1.11.8 in einem GKE-Cluster für ein Mesh-Netzwerk mit einem oder mehreren Clustern auszuführen, die sich im selben Cloud-Projekt befinden.

Informationen zum Upgrade wenn die Cluster in verschiedenen Projekten sind finden Sie in der Anleitung zu Multi-GKE-Projekt.

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:

• Anthos Service Mesh installieren
• Von Istio migrieren

Hinweis

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

• Sie haben die Anforderungen geprüft.
• Sie haben die Upgrade-Hinweise gelesen.
• Sie haben Ihren Cluster registriert.
• Sie haben die erforderlichen Tools installiert.
• Sie haben das Skript heruntergeladen.

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

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.

   Hinweis: Sie können --mode install für Upgrades verwenden. Wenn Sie --mode install anstelle von --mode upgrade verwenden, ermöglicht install_asm das Upgrade unabhängig von der Version der Steuerungsebene im Cluster. Das Flag upgrade lässt nur ein Upgrade von der vorherigen Nebenversion oder einer früheren Patchversion zu. Wenn Sie --mode install für ein Upgrade verwenden, müssen Sie dieselbe Zertifizierungsstelle (CA) angeben, die derzeit im Cluster aktiviert ist. Das Ändern der Zertifizierungsstelle führt zu Ausfallzeiten.

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

Wenn Sie eine Fehlermeldung erhalten, dass das Skript mit einem Aktivierungs-Flag ausgeführt werden muss, haben Sie die folgenden Optionen:

• Fügen Sie das spezifische Flag aus der Fehlermeldung oder das Flag --enable_all hinzu, wenn Sie das Skript ausführen, um die eigentliche Installation vorzunehmen (d. h. ohne --only_validate).

• Sie können Ihr Projekt und Ihren Cluster auch selbst aktualisieren, bevor Sie das Skript ausführen. Weitere Informationen dazu finden Sie unter Anthos Service Mesh in GKE zur Installation einrichten.

Beachten Sie, dass install_asm keine Aktivierungs-Flags mit --only_validate zulässt.

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.

Achtung: Wenn Sie die vorherige Installation angepasst haben, müssen Sie die IstioOperator-Konfigurationsdatei (oder Dateien) mit der Option --custom_overlay angeben. Wenn Sie die Konfigurationsdatei weglassen, wird Anthos Service Mesh auf die Standardwerte zurückgesetzt.

./install_asm \
  --project_id  PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --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 install \
  --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 install \
  --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.11 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 (oder das Upgrade) 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 der Steuerungsebene zusammen mit der vorhandenen Steuerungsebene installiert. Anschließend verschieben Sie einige Ihrer Arbeitslasten zur neuen 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.

Das Skript legt ein Überarbeitungslabel im Format istio.io/rev=asm-1118-4 für istiod fest. 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.

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

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

• Beispielanwendung Online Boutique auf Anthos Service Mesh bereitstellen
• Multi-Cluster-Mesh einrichten