Von Istio migrieren

Auf dieser Seite wird erläutert, wie Sie das Skript für die Migration von Istio zu Anthos Service Mesh 1.10.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. Wenn Sie Istio 1.6 oder früher verwenden, müssen Sie zuerst ein Upgrade durchführen, bevor Sie zu Anthos Service Mesh migrieren. Wenn Sie Istio ab Version 1.7 verwenden, können Sie möglicherweise von Istio 1.7 oder höher zu Anthos Service Mesh und Mesh CA migrieren. Wenn Sie ein Upgrade ausführen müssen, rufen Sie die Seite Istio aktualisieren in der entsprechenden Version von Istio auf. Das Upgrade von Istio auf mehr als eine Nebenversion (z. B. 1.6.x auf 1.8.x) in einem Schritt wird nicht offiziell getestet oder empfohlen.

Hinweise

Bevor Sie mit der Installation beginnen, müssen Sie folgende Schritte ausgeführt haben:

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

  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, mode und ca. Für ca haben Sie die folgenden Optionen:

    • --ca mesh_ca: Geben Sie diese Option an, wenn Sie zur Anthos Service Mesh-Zertifizierungsstelle (Mesh CA) migrieren möchten.

    • --ca citadel: Geben Sie diese Option an, wenn Sie weiterhin die CA von Istio verwenden möchten.

    Weitere Informationen finden Sie unter Zertifizierungsstelle auswählen.

    Hinweis: Sie können --mode install für eine Migration von Istio verwenden. Wenn Sie --mode install anstelle von --mode migrate verwenden, lässt install_asm die Migration unabhängig von der Version der Steuerungsebene im Cluster zu. Das Flag migrate lässt nur eine Migration von der vorherigen Nebenversion oder einer früheren Patchversion zu.

    Der folgende Abschnitt enthält typische Beispiele für das Ausführen des Skripts. 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 für die Ausführung des Skripts für eine Migration von Istio 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 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 \
  --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.

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.

Zu Mesh CA mit Ausfallzeit migrieren

Die Migration zur Anthos Service Mesh-Zertifizierungsstelle (Mesh CA) von der Istio-CA erfordert die Migration des Root of Trust. Während der Migration verwenden einige Arbeitslasten das alte Root-Zertifikat, während andere das neue Mesh CA-Root-Zertifikat nutzen. Arbeitslasten, die Zertifikate verwenden, die von verschiedenen Root-Zertifikaten signiert wurden, können sich nicht gegenseitig authentifizieren. Der gesamte Cluster wird nur dann vollständig wiederhergestellt, wenn die Steuerungsebene und alle Arbeitslasten in allen Namespaces mit dem Zertifikat der neuen Stammzertifizierungsstelle neu bereitgestellt werden.

Wenn Sie Ausfallzeiten planen können, ist dies die einfachste Möglichkeit, zu Anthos Service Mesh mit Mesh CA zu migrieren. Das folgende Beispiel zeigt typische Befehlszeilenoptionen für die Migration zu Mesh CA.

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --ca mesh_ca \
  --output_dir OUTPUT_DIRECTORY
  --enable_all

Migration zu Mesh CA ohne oder mit nur geringen Ausfallzeiten

Wenn Sie keine Ausfallzeiten für die Migration zu Mesh CA planen können, gibt es weiterhin einen Migrationspfad zu Mesh CA, aber es sind zusätzliche Schritte erforderlich. Weitere Informationen finden Sie unter Zu Mesh CA migrieren.

Migrieren, aber weiterhin Istio-CA verwenden

Wenn Sie eine benutzerdefinierte Zertifizierungsstelle benötigen, können Sie die Zertifizierungsstelle von Istio nach der Migration zu Anthos Service Mesh weiterhin verwenden. Mit dem folgenden Befehl wird das Skript für eine Migration ausgeführt und die Zertifizierungsstelle von Istio aktiviert. Die Option --ca citadel wird als "citadel" bezeichnet, da dies der Name der CA-Komponente war, bevor alle Istio-Komponenten in istiod eingebunden wurden. Bei dieser Migration werden nur die Steuerungsebene und das Ingress-Gateway 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 install \
  --ca citadel \
  --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 install \
  --ca citadel \
  --enable_all \
  --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 install \
  --ca citadel \
  --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.10-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-1106-2 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-1106-2
istio-ingressgateway-asm-182-2-8b5fc8767-hn4w2   1/1     Running   0          20s   asm-1106-2
istiod-asm-176-1-67998f4b55-lrzpz                1/1     Running   0          68m   asm-198-3
istiod-asm-176-1-67998f4b55-r76kr                1/1     Running   0          68m   asm-198-3
istiod-asm-182-2-5cd96f88f6-n7tj9                1/1     Running   0          27s   asm-1106-2
istiod-asm-182-2-5cd96f88f6-wm68b                1/1     Running   0          27s   asm-1106-2

    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-1106-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 für das Überarbeitungslabel der alten Version asm-198-3.

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

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

    Zu Anthos Service Mesh

  2. Wählen Sie das Google 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 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:

  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