Installation und Migration in GKE

In dieser Anleitung wird erläutert, wie Sie die Anthos Service Mesh-Version 1.6.14 für ein Mesh mit einem oder mehreren GKE-Clustern installieren, die sich im selben Projekt befinden. Sie verwenden ein von Google bereitgestelltes Skript, mit dem Ihr Projekt und Ihr Cluster konfiguriert werden und mit dem anschließend Anthos Service Mesh installiert wird.

Sie können diese Anleitung für folgende Anwendungsfälle verwenden:

  • Neue Installationen von Anthos Service Mesh Lesen Sie Upgrade von Anthos Service Mesh auf GKE ausführen, wenn Sie eine frühere Version von Anthos Service Mesh installiert haben. Die Version 1.6 des Skripts verarbeitet keine Aktualisierungen.

  • Migration von Open-Source-Istio 1.6 zu Anthos Service Mesh Die Migration von einer früheren Version von Istio wird nicht unterstützt. Die Version 1.7 des Skripts unterstützt die Migration von Istio 1.6 oder 1.7 zu Anthos Service Mesh 1.7. Da Sie migrieren möchten, ist die Migration zu Anthos Service Mesh 1.7 eine gute Lösung.

  • Migration von der Version 1.6 des Add-ons „Istio on GKE“ zu Anthos Service Mesh. Bevor Sie zu Anthos Service Mesh migrieren können, müssen Sie ein Upgrade auf Istio 1.6 mit Operator vornehmen. Vollständige Migrationsschritte vom Add-on finden Sie in der Dokumentation zu Istio on GKE unter Zu Anthos Service Mesh migrieren.

In den folgenden Anwendungsfällen müssen Sie die Anleitung Erweiterte Installation und Migration in GKE verwenden:

  • Wenn Sie die Installation anpassen müssen, um Einstellungen im Profil asm-gcp zu überschreiben, und Sie mehr als eine Overlay-IstioOperator-YAML-Datei haben. Mit dem Skript können Sie nur eine YAML-Datei angeben.

  • Bei einem Multi-Cluster-Mesh, in dem sich die Cluster in verschiedenen Projekten befinden.

Hinweise

In diesem Leitfaden wird Folgendes vorausgesetzt:

Wenn Sie von Istio migrieren, lesen Sie den Abschnitt Migration von Istio vorbereiten.

Unterschiede zwischen Anthos und Anthos Service Mesh

  • GKE Enterprise-Abonnenten müssen die GKE Enterprise API aktivieren.

    API aktivieren

  • Auch wenn Sie kein GKE Enterprise-Abonnent sind, können Sie Anthos Service Mesh installieren. Bestimmte UI-Elemente und Features in der Google Cloud Console sind jedoch nur für GKE Enterprise-Abonnenten verfügbar. Informationen dazu, was für Abonnenten und Nicht-Abonnenten verfügbar ist, finden Sie unter Unterschiede zwischen GKE Enterprise und Anthos Service Mesh in der UI. Informationen zu den Anthos Service Mesh-Preisen für Nicht-Abonnenten finden Sie unter Preise.

Voraussetzungen

  • Ihr GKE-Cluster muss die folgenden Anforderungen erfüllen:

    • Ein Maschinentyp mit mindestens vier vCPUs, z. B. e2-standard-4. Wenn der Maschinentyp für Ihren Cluster nicht mindestens vier vCPUs hat, ändern Sie den Maschinentyp, wie unter Arbeitslasten zu anderen Maschinentypen migrieren beschrieben.

    • Die Mindestanzahl an Knoten hängt vom Maschinentyp ab. Anthos Service Mesh erfordert mindestens acht vCPUs. Wenn der Maschinentyp vier vCPUs hat, muss der Cluster mindestens zwei Knoten haben. Wenn der Maschinentyp acht vCPUs umfasst, benötigt der Cluster nur einen Knoten. Informationen zum Hinzufügen von Knoten finden Sie unter Größe eines Clusters anpassen.

    • Das Skript aktiviert Workload Identity in Ihrem Cluster. Workload Identity ist die empfohlene Methode zum Aufrufen von Google APIs. Wenn Sie Workload Identity aktivieren, ändert sich die Art und Weise, wie Aufrufe Ihrer Arbeitslasten an Google APIs gesichert werden. Weitere Informationen hierzu finden Sie unter Einschränkungen bei Workload Identity.

    • Es wird empfohlen, den Cluster in einer Release-Version zu registrieren. Dies ist jedoch optional. Es wird empfohlen, sich für die Release-Version "Regular" zu registrieren, da andere Versionen möglicherweise auf einer GKE-Version basieren, die mit Anthos Service Mesh nicht unterstützt wird. 1.6.14. Weitere Informationen finden Sie unter Unterstützte Umgebungen. Folgen Sie der Anleitung unter Vorhandenen Cluster in einer Release-Version registrieren, wenn Sie eine statische GKE-Version haben.

  • Für die Aufnahme in das Service Mesh müssen Dienstports benannt werden und der Name muss das Protokoll des Ports in der folgenden Syntax enthalten: name: protocol[-suffix], wobei die eckigen Klammern ein optionales Suffix angeben, das mit einem Bindestrich beginnen muss. Weitere Informationen finden Sie unter Dienstports benennen.

  • Wenn Sie Anthos Service Mesh in einem privaten Cluster installieren, müssen Sie Port 15017 in der Firewall öffnen, damit der Webhook mit automatischer Sidecar-Einfügung ordnungsgemäß funktioniert. Weitere Informationen finden Sie unter Port auf einem privaten Cluster öffnen.

  • Wenn Sie in Ihrer Organisation einen Dienstperimeter erstellt haben, müssen Sie möglicherweise den Mesh CA-Dienst dem Perimeter hinzufügen. Weitere Informationen finden Sie unter Mesh CA einem Dienstperimeter hinzufügen.

  • Bei Migrationen muss istiod im Namespace istio-system installiert werden, was in der Regel der Fall ist.

Einschränkungen

Mit einem Google Cloud-Projekt kann nur ein Mesh-Netzwerk verknüpft sein.

Zertifizierungsstelle auswählen

Bei Neuinstallationen und Migrationen haben Sie die Option, die Anthos Service Mesh-Zertifizierungsstelle (Mesh CA) oder Citadel (jetzt in istiod eingebunden) als Zertifizierungsstelle für die Ausstellung gegenseitiger TLS-Zertifikate (mTLS-Zertifikate) zu verwenden.

Im Allgemeinen empfehlen wir, Mesh-CA zu verwenden, denn:

  • Mesh CA ist ein zuverlässiger und skalierbarer Dienst, der für dynamisch skalierte Arbeitslasten in Google Cloud optimiert ist.
  • Mit Mesh CA verwaltet Google die Sicherheit und Verfügbarkeit des CA-Back-Ends.
  • Mesh CA ermöglicht es Ihnen, sich für alle Cluster auf eine einzige Root of Trust zu verlassen.
Bei neuen Installationen von Anthos Service Mesh aktiviert das Skript standardmäßig Mesh CA.

In einigen Fällen ist es jedoch ratsam, Citadel zu verwenden. Hier einige Beispiele:

  • Mit einer benutzerdefinierten Zertifizierungsstelle.

  • Wenn Sie von Istio oder dem Add-on „Istio on GKE” migrieren.

    Wenn Sie Citadel auswählen, gibt es keine Ausfallzeiten, da der mTLS-Traffic während der Migration nicht unterbrochen wird. Wenn Sie Mesh-CA auswählen, müssen Sie die Ausfallzeit für die Migration planen, da der mTLS-Traffic fehlschlägt, bis Sie alle Pods in allen Namespaces neu starten.

Zertifikate der Mesh CA enthalten die folgenden Daten zu den Diensten Ihrer Anwendung:

  • Die Google Cloud-Projekt-ID
  • Der GKE-Namespace
  • Der Name des GKE-Dienstkontos

Erforderliche Tools installieren

Sie können das Skript in Cloud Shell oder auf einem lokalen Computer ausführen, auf dem Linux oder macOS ausgeführt wird. Cloud Shell installiert alle erforderlichen Tools vorab.

So führen Sie das Skript lokal aus:

  1. Die folgenden Tools müssen installiert sind:

  2. Authentifizieren Sie sich über die gcloud CLI:

    gcloud auth login

  3. Aktualisieren Sie die Komponenten:

    gcloud components update

  4. Prüfen Sie, ob sich git in Ihrem Pfad befindet, damit kpt es finden kann.

Das Skript ausführen

In diesem Abschnitt wird beschrieben, wie Sie das Skript herunterladen, die erforderlichen und optionalen Parameter festlegen und das Skript ausführen. Eine detaillierte Beschreibung der Funktionsweise des Skripts finden Sie unter Grundlegendes zum Skript.

  1. Laden Sie das Skript in das aktuelle Arbeitsverzeichnis herunter:

    curl https://storage.googleapis.com/csm-artifacts/asm/install_asm_1.6 > install_asm

  2. Laden Sie das SHA-256 der Datei in das aktuelle Arbeitsverzeichnis herunter:

    curl https://storage.googleapis.com/csm-artifacts/asm/install_asm_1.6.sha256 > install_asm.sha256

  3. Prüfen Sie den Download, wenn beide Dateien im selben Verzeichnis sind:

    sha256sum -c --ignore-missing install_asm.sha256

    Wenn die Prüfung erfolgreich ist, gibt der Befehl Folgendes aus: install_asm: OK

    Aus Kompatibilitätsgründen enthält die Datei install_asm.sha256 die Prüfsumme zweimal, damit jede Version des Skripts in install_asm umbenannt werden kann. Wenn Sie die Fehlermeldung erhalten, dass --ignore-missing nicht vorhanden ist, führen Sie den vorherigen Befehl ohne das Flag --ignore-missing noch einmal aus.

  4. Machen Sie das Skript ausführbar:

    chmod +x install_asm

  5. Legen Sie die Optionen fest und geben Sie die Flags für die Ausführung des Skripts an. Sie fügen immer die folgenden Optionen hinzu: project_id, cluster_name, cluster_location und mode. Je nach mode müssen Sie möglicherweise die Option ca einfügen.

    • Die Optionen project_id, cluster_name und cluster_location dienen zur Identifikation des Clusters, auf dem Anthos Service Mesh installiert werden soll.
    • mode ist entweder install oder migrate.
    • ca gibt die Zertifizierungsstelle entweder als mesh_ca oder citadel an.

    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.

  6. 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 in den einzelnen mode und einige zusätzliche Argumente, die für Sie nützlich sein könnten. 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 Cluster vor und installiert Anthos Service Mesh nicht. 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.

  1. Erstellen Sie ein Verzeichnis mit dem Namen asm-packages:

    mkdir asm-packages

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

    ./install_asm \
--project_id PROJECT_ID \
--cluster_name CLUSTER_NAME \
--cluster_location CLUSTER_LOCATION \
--mode install \
--output_dir ./asm-packages \
--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
re-run the script with the '--enable_apis' flag to allow the script to enable
them on your behalf.

Neue Installation

Mit dem folgenden Befehl wird das Skript für eine neue Installation ausgeführt, Mesh-CA (die Standardzertifizierungsstelle für neue Installationen; Sie benötigen in diesem Fall also nicht die Option ca) wird aktiviert und das Skript kann die erforderlichen Google APIs aktivieren.

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --enable_apis

Neuinstallation mit einer Overlay-Datei

Das folgende Beispiel führt eine neue Installation mit einer YAML-Datei aus, die ein optionales Feature aktiviert.

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --enable_apis \
  --operator_overlay egressgateways.yaml

Migration von Istio

Wenn Sie aus dem Open-Source-Framework Istio migrieren, verwenden Sie Citadel als CA. Der folgende Befehl führt das Skript für eine Migration zu Anthos Service Mesh aus und aktiviert Citadel als CA. Bei dieser Migration wird nur die Steuerungsebene bereitgestellt. Die Stamm-CA ändert sich nicht und die vorhandenen Arbeitslasten werden nicht unterbrochen.

./install_asm \
  -p PROJECT_ID \
  -n CLUSTER_NAME \
  -l CLUSTER_LOCATION \
  -m migrate \
  -c citadel \
  --enable_apis

Optionen und Flags

Optionen

-p|--project_id CLUSTER_PROJECT_ID
Die Projekt-ID, in der der Cluster erstellt wurde.
-n|--cluster_name CLUSTER_NAME
Der Name des Clusters.
-l|--cluster_location CLUSTER_LOCATION
Entweder die Zone (bei Einzelzonenclustern) oder die Region (bei regionalen Clustern), in der der Cluster erstellt wurde.
-m|--mode {install|migrate}
Geben Sie install ein, wenn Sie eine neue Installation von Anthos Service Mesh durchführen. Geben Sie migrate ein, wenn Sie von Istio oder dem Add-on „Istio on GKE“ zu Anthos Service Mesh migrieren.
-c|--ca {mesh_ca|citadel}
Bei einer Neuinstallation ist die Standardeinstellung für diesen Parameter Mesh CA und Sie müssen ihn nicht mit einbeziehen. Wenn Sie von Istio migrieren, müssen Sie citadel oder mesh_ca angeben. Wenn Sie Ausfallzeiten für die Migration einplanen können, empfehlen wir die Verwendung von mesh_ca. Wenn Sie keine Ausfallzeiten für die Migration einplanen können, verwenden Sie citadel.
-o|--operator_overlay YAML_FILE
Der Name der YAML-Datei zum Aktivieren eines Features, das im Profil asm-gcp nicht aktiviert ist. Das Skript muss die YAML-Datei finden können. Die Datei muss sich also im selben Verzeichnis wie das Skript befinden oder Sie können einen relativen Pfad angeben, z. B.: ../manifests/asm-features.yaml.
-s|--service_account ACCOUNT
Der Name eines Dienstkontos, das zum Installieren von Anthos Service Mesh verwendet wird. Wenn nicht angegeben, wird das aktive Nutzerkonto in der aktuellen gcloud-Konfiguration verwendet. Wenn Sie das aktive Nutzerkonto ändern müssen, führen Sie gcloud auth login aus.
-k|--key_file FILE PATH
Die Schlüsseldatei für ein Dienstkonto. Lassen Sie diese Option weg, wenn Sie kein Dienstkonto verwenden.
-D|--output_dir DIR_PATH
Wenn keine Angabe erfolgt, erstellt das Skript ein temporäres Verzeichnis, in das die Dateien und Konfigurationen für die Installation von Anthos Service Mesh heruntergeladen werden. Mit dem Flag --output-dir geben Sie stattdessen ein vorhandenes Verzeichnis an. Nach Abschluss enthält das angegebene Verzeichnis die Unterverzeichnisse asm und istio-1.6.14-asm.2. Das Verzeichnis asm enthält die Konfiguration für die Installation. Das Verzeichnis istio-1.6.14-asm.2 enthält den extrahierten Inhalt der Installationsdatei, die istioctl, Beispiele und Manifeste enthält.

Flags

-e|--enable_apis
Lassen Sie zu, dass das Skript die von Anthos Service Mesh erforderlichen Google APIs aktiviert. Ohne dieses Flag wird das Skript beendet, wenn die erforderlichen APIs noch nicht aktiviert sind. Für eine Liste der vom Skript aktivierten APIs set_up_project.
-v|--verbose
Befehle vor und nach der Ausführung drucken
--dry_run
Befehle drucken, aber nicht ausführen
--only_validate
Führen Sie eine Validierung aus, aber installieren Sie Anthos Service Mesh nicht.
--disable_canonical_service
Standardmäßig stellt das Skript den Canonical Service-Controller in Ihrem Cluster bereit. Wenn Sie nicht möchten, dass das Skript den Controller bereitstellt, geben Sie --disable_canonical_service an. Weitere Informationen finden Sie unter Canonical Service-Controller aktivieren und deaktivieren.
-h|--help
Eine Hilfemeldung mit den Optionen und Flags anzeigen und den Vorgang beenden.

Arbeitslasten bereitstellen und neu bereitstellen

Die Installation ist erst abgeschlossen, wenn Sie die automatische Sidecar-Proxy-Injektion aktivieren (automatische Injektion).

  • Bei neuen Installationen müssen Sie die automatische Injektion aktivieren und die Pods für alle auf Ihrem Cluster ausgeführten Arbeitslasten neu starten, bevor Anthos Service Mesh installiert wird.

  • Migrationen von Istio folgendem dem Upgradeprozess für die duale Steuerungsebene (in der Istio-Dokumentation als „Canary-Upgrade“ bezeichnet). Bei einem Upgrade der dualen Steuerungsebene installiert das Skript zusätzlich zur vorhandenen istiod eine neue Version von istiod. Anschließend verschieben Sie einige Ihrer Arbeitslasten in die neue Version. Auf diese Weise können Sie die Auswirkungen der neuen Version mit einem kleinen Prozentsatz der Arbeitslasten überwachen, bevor Sie den gesamten Traffic zur neuen Version migrieren.

  • Aktivieren Sie vor dem Bereitstellen neuer Arbeitslasten die automatische Injektion, damit der Traffic mit Anthos Service Mesh den Traffic überwacht und geschützt werden kann.

Zum Aktivieren der automatischen Injection erhalten Sie das Revisionslabel, das vom Skript auf istiod angewendet wurde, und Ihre Namespaces mit dem Revisionslabel. In den folgenden Abschnitten finden Sie weitere Details.

Revisionslabel abrufen

Mit dem Skript wird ein Überarbeitungslabel im Format istio.io/rev=asm-1614-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, müssen alle im Namespace vorhandenen Pods neu gestartet werden, damit die Sidecars eingefügt werden können.

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

    gcloud container clusters get-credentials CLUSTER_NAME \
    --project=PROJECT_ID

  2. Rufen Sie die Labels in istiod auf, um das vom Skript festgelegte Überarbeitungslabel abzurufen:

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

    Die Ausgabe des Befehls sieht in etwa so aus:

    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-1614-2-85d86774f7-flrt2   1/1     Running   0          26m   app=istiod,istio.io/rev=asm-1614-2,istio=istiod,pod-template-hash=85d86774f7
istiod-asm-1614-2-85d86774f7-tcwtn   1/1     Running   0          26m   app=istiod,istio.io/rev=asm-1614-2,istio=istiod,pod-template-hash=85d86774f7

    Notieren Sie sich den Wert des Überarbeitungslabels istiod aus der Ausgabe in der Spalte LABELS, das auf das Präfix istio.io/rev= folgt. In diesem Beispiel lautet der Wert asm-1614-2. Ihr Wert kann aber auch ein anderer sein.

    Bei Migrationen notieren Sie sich den Wert im Überarbeitungslabel für die alte istiod-Version. Sie benötigen diese Datei, um die alte Version von istiod zu löschen, wenn Sie die Migration abgeschlossen haben. In der Beispielausgabe lautet der Wert für die alten Version von istiod aus dem Überarbeitungslabel default. Ihr Wert kann aber auch ein anderer sein.

Automatisches Einfügen aktivieren

Führen Sie diese Schritte für neue Installationen und Migrationen aus, um die automatische Injektion zu aktivieren.

  1. Rufen Sie aus dem Überarbeitungslabel den Wert für istiod ab.

  2. Fügen Sie das Überarbeitungslabel einem Namespace hinzu und entfernen Sie das Label istio-injection. Ändern Sie im folgenden Befehl REVISION in den Wert, der der Überarbeitung auf istiod entspricht.

    kubectl label namespace NAMESPACE istio.io/rev=REVISION istio-injection- --overwrite

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

    kubectl rollout restart deployment -n NAMESPACE

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

  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.

Für die Migration:

Umstellung abschließen

Bei Migrationen müssen Sie die alte Version von istiod entfernen. 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. Rufen Sie aus dem Überarbeitungslabel den Wert für die alte Version von istiod ab.

  2. Löschen Sie die alte Version von istiod. Ersetzen Sie im folgenden Befehl OLD_REVISION durch die Überarbeitung aus dem vorherigen Schritt.

    kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-OLD_REVISION  -n istio-system --ignore-not-found=true

Rollback zur vorherigen Version

Wenn bei der Migration ein Problem beim Testen der Anwendung mit der neuen Version von istiod aufgetreten ist, gehen Sie folgendermaßen vor, um ein Rollback auf die vorherige Version durchzuführen:

  1. Aktualisieren Sie Arbeitslasten, damit die vorherige Version von istiod eingeschleust wird.

    kubectl label namespace NAMESPACE istio.io/rev- istio-injection=enabled --overwrite

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

  3. Stellen Sie die vorherige Version von istio-ingressgateway noch einmal bereit:

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

  4. Entfernen Sie die neue Version von istiod:

    kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-REVISION -n istio-system --ignore-not-found=true

  5. Wenn Sie das Flag --disable_canonical_service nicht angegeben haben, hat das Skript den Canonical Service-Controller aktiviert. Folgen Sie der Anleitung unter Canonical Service-Controller aktivieren und deaktivieren, um ihn zu deaktivieren.

Anthos Service Mesh-Dashboards aufrufen

Dieser Abschnitt ist nur relevant, wenn Sie Anthos Service Mesh mit dem Konfigurationsprofil asm-gcp installiert haben. Wenn Sie das Profil asm-gcp-multiproject verwendet haben, um Anthos Service Mesh zu installieren, sind Telemetriedaten in den Anthos Service Mesh-Dashboards in der Google Cloud Console nicht verfügbar.

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.

Cluster registrieren

Sie müssen den Cluster in der Flotte des Projekts registrieren, um Zugriff auf die einheitliche Benutzeroberfläche in der Google Cloud Console zu erhalten. Eine Flotte ermöglicht die einheitliche Anzeige und Verwaltung der Cluster und ihrer Arbeitslasten, einschließlich Clustern außerhalb von Google Cloud.

Informationen zum Registrieren Ihres Clusters finden Sie unter Cluster bei der Flotte registrieren.

Grundlegendes zum Skript

Obwohl Sie das Skript von einem sicheren Speicherort in Cloud Source Repositories herunterladen, steht das Skript auch auf GitHub zur Verfügung, damit Sie das Skript vor dem Download prüfen können. Das Skript überprüft, ob Ihr Cluster die Anforderungen erfüllt, und automatisiert alle Schritte, die Sie manuell ausführen würden, wenn Sie der Anleitung Anthos Service Mesh in GKE in Google Cloud installieren folgen.

validate_args und validate_dependencies

validate_args() {
  if [[ "${MODE}" == "install" && -z "${CA}" ]]; then
    CA="mesh_ca"
  fi

  local MISSING_ARGS=0
  while read -r REQUIRED_ARG; do
    if [[ -z "${!REQUIRED_ARG}" ]]; then
      MISSING_ARGS=1
      warn "Missing value for ${REQUIRED_ARG}"
    fi
    readonly "${REQUIRED_ARG}"
  done <<EOF
 
validate_dependencies() {
  validate_cli_dependencies

  validate_gcp_resources
  # configure kubectl does have side effects but we've generated a temprorary
  # kubeconfig so we're not breaking the promise that --only_validate gives
  configure_kubectl
  validate_expected_control_plane
  if [[ "${MODE}" = "migrate" ]]; then
    validate_istio_version
  fi
  if [[ "${ENABLE_APIS}" -eq 0 || "${ONLY_VALIDATE}" -eq 1 ]]; then
    exit_if_apis_not_enabled
  fi
}

Die Funktionen validate_args und validate_dependencies:

  • Prüfen Sie, ob alle erforderlichen Tools installiert sind.
  • Prüfen Sie, ob die Projekt-ID, der Clustername und der Clusterstandort, die Sie als Parameterwerte eingegeben haben, gültig sind.
  • Der Cluster muss den erforderlichen Mindestmaschinentyp und die erforderliche Mindestanzahl an Knoten aufweisen.

set_up_project

Wenn Sie das Flag --enable_apis angegeben haben, aktiviert die Funktion set_up_project die erforderlichen APIs:

required_apis() {
    cat << EOF
container.googleapis.com
compute.googleapis.com
monitoring.googleapis.com
logging.googleapis.com
cloudtrace.googleapis.com
meshca.googleapis.com
meshtelemetry.googleapis.com
meshconfig.googleapis.com
iamcredentials.googleapis.com
gkeconnect.googleapis.com
gkehub.googleapis.com
cloudresourcemanager.googleapis.com
EOF
}

set_up_cluster

set_up_cluster(){
  add_cluster_labels
  enable_workload_identity

  # this is project scope but requires workload identity
  if [[ "${CA}" = "mesh_ca" ]]; then
    init_meshca
  fi

  enable_stackdriver_kubernetes
  bind_user_to_cluster_admin
  ensure_istio_namespace_exists
}

Die Funktion set_up_cluster führt die folgenden Aktualisierungen Ihres Clusters durch:

  • Aktiviert Workload Identity. Dies ist die empfohlene Methode für den sicheren Zugriff auf Google Cloud-Dienste aus GKE-Anwendungen.

  • Aktiviert Cloud Monitoring und Cloud Logging in GKE.

  • Legt das mesh_id-Label auf dem Cluster fest. Dies ist erforderlich, damit Messwerte auf den Anthos Service Mesh-Seiten in der Cloud Console angezeigt werden.

  • Legt ein Label wie asmv=asm-1614-2 fest, damit Sie sehen können, dass der Cluster vom Skript geändert wurde.

  • Bindet den GCP-Nutzer oder das Dienstkonto, der/das das Skript ausführt, an die Clusteradministrator-Rolle für Ihr Cluster.

install_asm

install_asm(){

  local CA_OPT
  CA_OPT=""
  if [[ "${CA}" = "citadel" ]]; then
    CA_OPT="-citadel"
  fi

  info "Configuring kpt package..."
  run kpt cfg set asm gcloud.container.cluster "${CLUSTER_NAME}"
  run kpt cfg set asm gcloud.core.project "${PROJECT_ID}"
  run kpt cfg set asm gcloud.project.environProjectNumber "${PROJECT_NUMBER}"
  run kpt cfg set asm gcloud.compute.location "${CLUSTER_LOCATION}"
  run kpt cfg set asm anthos.servicemesh.rev "${REVISION_LABEL}"
  if [[ -n "${_CI_ASM_IMAGE_LOCATION}" ]]; then
    run kpt cfg set asm anthos.servicemesh.hub "${_CI_ASM_IMAGE_LOCATION}"
    run kpt cfg set asm anthos.servicemesh.tag "${RELEASE}"
  fi

  local PARAMS
  PARAMS="-f ${OPERATOR_MANIFEST}"
  if [[  -f "$CUSTOM_OVERLAY" ]]; then
    PARAMS="${PARAMS} -f ${CUSTOM_OVERLAY}"
  fi
  PARAMS="${PARAMS} --set revision=${REVISION_LABEL}"
  PARAMS="${PARAMS} -c ${KUBECONFIG}"

  info "Installing ASM control plane..."
  # shellcheck disable=SC2086
  retry 5 run ./"${ISTIOCTL_REL_PATH}" install $PARAMS

  # Prevent the stderr buffer from ^ messing up the terminal output below
  sleep 1
  info "...done!"

  if ! does_istiod_exist; then
    info "Installing validation webhook fix..."
    retry 3 run kubectl apply -f "${VALIDATION_FIX_SERVICE}"
  fi

  if [[ "$DISABLE_CANONICAL_SERVICE" -ne 1 ]]; then
    info "Installing ASM CanonicalService controller in asm-system namespace..."
    retry 3 run kubectl apply -f asm/canonical-service/controller.yaml
    info "Waiting for deployment..."
    retry 3 run kubectl wait --for=condition=available --timeout=600s \
        deployment/canonical-service-controller-manager -n asm-system
    info "...done!"
  fi

  outro
}

Die install_asm-Funktion:

  • Lädt das Paket kpt in ein temporäres Verzeichnis herunter.
  • Führt die kpt-Setter aus, um die istio-operator.yaml-Datei zu konfigurieren.
  • Installiert Anthos Service Mesh.

Unterschiede zum Skript 1.7

Skript 1.7 Skript 1.6
Unterstützt Upgrades. Es werden keine Upgrades ausgeführt.
Unterstützt Migrationen von Istio 1.6 und Istio 1.7. Unterstützt die Migration von Istio 1.6.
--print_config
Stellt die Konfiguration bereit, die Sie bei der Installation mit dem Skript install_asm verwendet haben. Dieses Flag erleichtert die nochmalige Installation derselben Anthos Service Meshversion (die im Skript nicht zulässig ist) mit derselben Konfiguration, die Sie bei der vorherigen Installation bereits verwendet haben.		 Nicht verfügbar
--custom_overlay
Erlaubt mehrere Overlay-Dateien.		 --custom_overlay
Erlaubt nur eine Overlay-Datei.
--option
Ruft Overlay-Dateien aus dem Paket asm auf GitHub ab. 		Nicht verfügbar.
Unterstützt benutzerdefinierte Zertifizierungsstellen mit den folgenden Optionen:

--ca_cert
--ca_key
--root_cert
--cert_chain

Nicht verfügbar.