Auf dieser Seite wird erläutert, wie Sie das Skript für die Migration von Istio 1.7 or 1.8 zu Anthos Service Mesh 1.8.6 in einem GKE-Cluster für ein Mesh-Netzwerk mit einem oder mehreren Clustern ausführen, die sich im selben Google Cloud-Projekt befinden.
Informationen zu einem Multi-Cluster-Mesh, bei dem sich die Cluster in verschiedenen Projekten befinden, finden Sie unter Multi-Cluster-/Multi-Projekt-Installation und -Migration für GKE.
Auf dieser Seite wird die Migration von Istio zu Anthos Service Mesh beschrieben. Informationen zum Ausführen des Skripts für neue Installationen und Upgrades finden Sie hier:
Hinweise
Bevor Sie mit der Installation beginnen, müssen Sie folgende Schritte ausgeführt haben:
- Sie haben die Anforderungen geprüft.
- Zertifizierungsstelle auswählen
- 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.
Migration vorbereiten
Weitere Informationen finden Sie unter Migration von Istio 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
.
Das Skript folgt dem Überarbeitungs-Upgradeprozess (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.
Zu Anthos Service Mesh migrieren
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
undmode
.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.
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 für die Ausführung des Skripts für eine neue Installation mit einigen zusätzlichen Argumenten, 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 migrate \ --ca citadel \ --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.
Migration von Istio mit Citadel
Wenn Sie von Istio mit Citade als Zertifizierungsstelle migrieren, können Sie nach der Migration zu Anthos Service Mesh weiterhin Citadel verwenden. Mit dem folgenden Befehl wird das Skript für eine Migration ausgeführt und Citadel als Zertifizierungsstelle aktiviert: Bei dieser Migration wird nur die Steuerungsebene bereitgestellt. Die Stammzertifizierungsstelle ändert sich nicht und wirkt sich nicht auf Ihre vorhandenen Arbeitslasten aus.
./install_asm \ --project_id PROJECT_ID \ --cluster_name CLUSTER_NAME \ --cluster_location CLUSTER_LOCATION \ --mode migrate \ --ca citadel \ --option revisioned-istio-ingressgateway \ --enable_all
Migration mit einer Overlay-Datei
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 eine Migration durch und enthält eine Overlay-Datei, 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 migrate \ --ca citadel \ --enable_all \ --option revisioned-istio-ingressgateway \ --custom_overlay OVERLAY_FILE
Migration mit einer Option
Im folgenden Beispiel wird eine Migration durchgeführt und die Datei egressgateways.yaml
aus dem Paket asm
eingebunden. Dadurch wird ein Ausgangsgateway aktiviert. Beachten Sie, dass die Erweiterung .yaml
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 migrate \ --ca citadel \ --enable_all \ --option revisioned-istio-ingressgateway \ --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 Überarbeitungsupgrade wird die neue Version der Steuerungsebene zusammen mit der vorhandenen Steuerungsebene 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.
Das Skript legt ein Überarbeitungslabel im Format istio.io/rev=asm-186-8
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.
Das Skript erstellt auch ein überarbeitetes istio-ingressgateway
-Deployment. So können Sie steuern, wann Sie zur neuen Version wechseln.
Rufen Sie das Revisionslabel ab, das sich auf
istiod
und demistio-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-186-8 istio-ingressgateway-asm-182-2-8b5fc8767-hn4w2 1/1 Running 0 20s asm-186-8 istiod-asm-176-1-67998f4b55-lrzpz 1/1 Running 0 68m asm-178-10 istiod-asm-176-1-67998f4b55-r76kr 1/1 Running 0 68m asm-178-10 istiod-asm-182-2-5cd96f88f6-n7tj9 1/1 Running 0 27s asm-186-8 istiod-asm-182-2-5cd96f88f6-wm68b 1/1 Running 0 27s asm-186-8
Prüfen Sie, ob Sie sowohl die alte als auch die neue Version von
istio-ingressgateway
haben.Wenn Sie beim Upgrade die Option
revisioned-istio-ingressgateway
angegeben haben, wurde ein Canary-Upgrade vonistio-ingressgateway
durchgeführt. In diesem Fall zeigt die Ausgabe sowohl die alte als auch die neue Version vonistio-ingressgateway
an.Wenn Sie beim Upgrade
revisioned-istio-ingressgateway
nicht angegeben haben, wurde ein direktes Upgrade vonistio-ingressgateway
durchgeführt. In diesem Fall enthält Ihre Ausgabe nur die neue Version.
Notieren Sie sich in der Ausgabe unter der Spalte
REV
den Wert des Überarbeitungslabels für die neue Version. In diesem Beispiel ist der Wertasm-186-8
.Notieren Sie sich außerdem den Wert im Überarbeitungslabel der alten
istiod
-Version. Diesen Wert benötigen Sie, um die alte Version vonistiod
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 Versionasm-178-10
.
Wenn Sie sowohl die alte als auch die neue Version von
istio-ingressgateway
haben, wechseln Sieistio-ingressgateway
zur neuen Überarbeitung. Ändern Sie im folgenden BefehlREVISION
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
Fügen Sie das Überarbeitungslabel einem Namespace hinzu und entfernen Sie das
istio-injection
-Label (falls vorhanden). Geben Sie im folgenden Befehl fürREVISION
den Wert an, der der neuen Überarbeitung vonistiod
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 Labelistio-injection
hatte. Da die automatische Injektion fehlschlägt, wenn ein Namespace sowohl dasistio-injection
als auch das Überarbeitungslabel enthält, enthalten allekubectl label
-Befehle in der Anthos Service Mesh-Dokumentation das Labelistio-injection
.Starten Sie die Pods neu, um die erneute Injektion auszulösen.
kubectl rollout restart deployment -n NAMESPACE
Ü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
Testen Sie die Anwendung, um zu prüfen, ob die Arbeitslasten ordnungsgemäß funktionieren.
Wenn Sie Arbeitslasten in anderen Namespaces haben, wiederholen Sie die Schritte, um den Namespace mit einem Label zu versehen und Pods neu zu starten.
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.Führen Sie folgenden Befehl noch einmal aus, um zu prüfen, ob Sie sowohl die alte als auch die neue Version von
istio-ingressgateway
oder nur die neue Version haben. Dies bestimmt, wie mit der Umstellung auf die neue Version vonistio-ingressgateway
oder einem Rollback auf die alte Version umgegangen wird.kubectl get pod -n istio-system -L istio.io/rev
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.
Wechseln Sie in das Verzeichnis, in dem sich die Dateien aus dem GitHub-Repository
anthos-service-mesh
befinden.Konfigurieren Sie den validierten Webhook so, dass er die neue Steuerungsebene verwendet.
kubectl apply -f asm/istio/istiod-service.yaml
Wenn Sie sowohl die alte als auch die neue Version von
istio-ingressgateway
nutzen, löschen Sie das alteistio-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 machen: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 vonistio-ingressgateway
.kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=OLD_REVISION -n istio-system --ignore-not-found=true
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
istiod
-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 vonistiod
übereinstimmt.kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-OLD_REVISION -n istio-system --ignore-not-found=true
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:Wechseln Sie zurück zur alten Version von
istio-ingressgateway
. Der verwendete Befehl hängt davon ab, ob Sie die alte und die neue Version vonistio-ingressgateway
oder nur die neue Version haben.Wenn Sie sowohl die alte als auch die neue Version von
istio-ingressgateway
verwenden, führen Sie denkubectl patch service
-Befehl aus und ersetzenOLD_REVISION
durch die alte Überarbeitung.kubectl patch service -n istio-system istio-ingressgateway --type='json' -p='[{"op": "replace", "path": "/spec/selector/service.istio.io~1canonical-revision", "value": "OLD_REVISION"}]'
Wenn Sie nur die neue Version von
istio-ingressgateway
haben, führen Sie denkubectl rollout undo
-Befehl aus.kubectl -n istio-system rollout undo deploy istio-ingressgateway
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 oderistio-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
Prüfen Sie, ob das Überarbeitungslabel im Namespace mit dem Überarbeitungslabel in der vorherigen Version von
istiod
übereinstimmt:kubectl get ns NAMESPACE --show-labels
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
Wenn Sie sowohl die alte als auch die neue Version von
istio-ingressgateway
verwenden, entfernen Sie das neueistio-ingressgateway
-Deployment. Achten Sie darauf, dass der Wert vonREVISION
im folgenden Befehl korrekt ist.kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=REVISION -n istio-system --ignore-not-found=true
Entfernen Sie die neue Version von
istiod
. Achten Sie darauf, dass der Wert vonREVISION
im folgenden Befehl korrekt ist.kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-REVISION -n istio-system --ignore-not-found=true
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
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 Google 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 Google Cloud Console angezeigt werden.
In der Cloud Console wird der Zugriff auf Anthos Service Mesh durch die Identitäts- und Zugriffsverwaltung (Identity and Access Management, 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 Google Cloud Console steuern beschriebenen restriktiveren Rollen gewähren.
Wechseln Sie in der Google Cloud Console zu Anthos Service Mesh.
Wählen Sie das Google Cloud-Projekt aus der Drop-down-Liste in der Menüleiste aus.
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 Google 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:
Rufen Sie in der Google Cloud Console die Seite Monitoring auf:
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
- Cluster zu einem Anthos Service Mesh hinzufügen