Anthos Service Mesh in GKE installieren

In dieser Anleitung wird erläutert, wie Sie die Anthos Service Mesh-Version 1.7.8 für ein Mesh-Netzwerk installieren, migrieren oder ein Upgrade machen, das einen oder mehrere GKE-Cluster im selben Projekt enthält. 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 und das Skript für die folgenden Anwendungsfälle verwenden:

  • Neue Installationen von Anthos Service Mesh

  • Upgrade von Anthos Service Mesh 1.6 oder die Patchversion 1.7. Upgrades von früheren Versionen werden nicht unterstützt.

  • Migration vom Open-Source-Framework Istio 1.6 oder 1.7 zu Anthos Service Mesh. Die Migration von einer früheren Version von Istio wird nicht unterstützt.

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

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.

Hinweise

In diesem Leitfaden wird davon ausgegangen, dass Sie bereits Folgendes haben:

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.

Das Skript aktiviert alle anderen erforderlichen Google APIs für Sie.

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.7.8. 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 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 sich der Root of Trust von Citadel zu Mesh CA ändert. Sie müssen alle Pods in allen Namespaces neu starten, um die Migration zum Mesh-CA Root of Trust abzuschließen. Während dieses Vorgangs können die alten Pods keine mTLS-Verbindungen zu den neuen Pods herstellen.

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

Eine Migration oder ein Upgrade vorbereiten

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

Wenn Sie die vorherige Installation angepasst haben, müssen Sie bei der Migration oder beim Upgrade auf Anthos Service Mesh dieselben Anpassungen vornehmen. Wenn Sie die Installation durch Anfügen des Flags --set values angepasst haben, empfehlen wir, dass Sie diese Einstellungen einer IstioOperator-Konfigurationsdatei hinzufügen. Sie geben die Konfigurationsdatei an, indem Sie beim Ausführen des Skripts --custom_overlay mit der Konfigurationsdatei verwenden.

Erforderliche Tools installieren

Sie können das Skript in Cloud Shell oder auf Ihrem lokalen Computer ausführen, auf dem Linux ausgeführt wird.

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.

  5. Laden Sie die erforderliche Version von kpt herunter.

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 die Version des Skripts herunter, mit der Anthos Service Mesh 1.7.8 in das aktuelle Arbeitsverzeichnis installiert wird:

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

    Sie laden das Skript zwar von einem sicheren Cloud Source Repositories-Speicherort herunter, es ist aber auch auf GitHub im Repository anthos-service-mesh-packages verfügbar. Somit können Sie nachvollziehen, was das Skript tut, bevor Sie es herunterladen. Mit der Version des Skripts install_asm im Zweig release-1.7-asm wird Anthos Service Mesh 1.7.8 installiert.

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

    curl https://storage.googleapis.com/csm-artifacts/asm/install_asm_1.7.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, migrate oder upgrade.
    • 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. 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
re-run the script with the '--enable_apis' flag to allow the script to enable
them on your behalf.

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

Installation mit Citadel als CA

In diesem Abschnitt wird Folgendes erläutert:

  • Zertifikate und Schlüssel generieren, mit denen Anthos Service Mesh Ihre Arbeitslasten signiert
  • Das Skript für eine Installation ausführen und Citadel als CA aktivieren.

Sie sollten Citadel nur als Zertifizierungsstelle verwenden, wenn Sie eine benutzerdefinierte Zertifizierungsstelle benötigen.

Für eine optimale Sicherheit empfehlen wir dringend, eine Offline-Stamm-CA zu behalten und die untergeordneten Zertifizierungsstellen einzusetzen, um für jeden Cluster CAs auszugeben. Weitere Informationen finden Sie unter CA-Zertifikate anschließen. In dieser Konfiguration verwenden alle Arbeitslasten im Service Mesh dieselbe Stamm-CA. Jede Anthos Service Mesh CA verwendet einen Zwischen-CA-Signierschlüssel und ein Zertifikat, das von der Stamm-CA signiert wird. Wenn es in einem Mesh mehrere CAs gibt, wird eine Hierarchie des Vertrauens zwischen den CAs eingerichtet. Sie können diese Schritte wiederholen, um Zertifikate und Schlüssel für eine beliebige Anzahl von Zertifizierungsstellen bereitzustellen.

  1. Erstellen Sie ein Verzeichnis für die Zertifikate und Schlüssel:

    mkdir -p certs && \
pushd certs

  2. Generieren Sie ein Root-Zertifikat und einen Root-Schlüssel:

    make -f ../tools/certs/Makefile.selfsigned.mk root-ca

    Dadurch werden diese Dateien generiert:

    • root-cert.pem: Root-Zertifikat
    • root-key.pem: Root-Schlüssel
    • root-ca.conf: Konfiguration für openssl, um das Root-Zertifikat zu generieren
    • root-cert.csr: CSR für das Root-Zertifikat

  3. Generieren Sie ein Zwischenzertifikat und einen Zwischenschlüssel:

    make -f ../tools/certs/Makefile.selfsigned.mk cluster1-cacerts

    Dadurch werden diese Dateien in einem Verzeichnis namens cluster1 generiert:

    • ca-cert.pem: Zwischenzertifikate
    • ca-key.pem: Zwischenschlüssel
    • cert-chain.pem: Die von Istiod verwendete Zertifikatskette
    • root-cert.pem: Root-Zertifikat

    Wenn Sie diese Schritte mit einem Offline-Computer ausführen, kopieren Sie das generierte Verzeichnis auf den Computer, auf dem Sie das Skript ausführen.

  4. Führen Sie das Skript aus und fügen Sie die Dateien hinzu, die Sie zuvor für die Zertifikate und den Schlüssel generiert haben.

    ./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --ca citadel \
  --ca_cert FILE_PATH \
  --ca_key FILE_PATH \
  --root_cert FILE_PATH \
  --cert_chain FILE_PATH \
  --enable_all

Installation 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 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_apis \
  --custom_overlay OVERLAY_FILE

Installation mit einer Option

Im folgenden Beispiel wird eine Installation durchgeführt und die Datei egressgateways.yaml aus dem Paket asm eingebunden. Dies aktiviert ein Gateway für ausgehenden Traffic. 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 \
  --enable_apis \
  --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.7-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.

Migration von Istio

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 \
  -p PROJECT_ID \
  -n CLUSTER_NAME \
  -l CLUSTER_LOCATION \
  -m migrate \
  -c citadel \
  --enable_apis

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 \
  --custom_overlay OVERLAY_FILE

Upgrade ausführen

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

./install_asm \
  -p PROJECT_ID \
  -n CLUSTER_NAME \
  -l CLUSTER_LOCATION \
  -m upgrade \
  --enable_apis

Upgrade mit einer Overlay-Datei ausführen

Eine Overlay-Datei ist eine YAML-Datei mit einer benutzerdefinierten IstioOperator-Ressource, die Sie an install_asm übergeben, um die Steuerungsebene zu konfigurieren. Sie können die Standardkonfiguration der Steuerungsebene überschreiben und eine optionale Funktion aktivieren, indem Sie die YAML-Datei an install_asm übergeben. Sie können mehr Overlays übereinander legen. Jede Overlay-Datei überschreibt die Konfiguration auf den vorherigen Ebenen.

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

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

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

Optionen und Flags

In diesem Abschnitt werden die verfügbaren Argumente für das Skript beschrieben.

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|upgrade}
Geben Sie install ein, wenn Sie Anthos Service Mesh installieren. Geben Sie migrate ein, wenn Sie von Istio migrieren. Geben Sie upgrade ein, um eine vorhandene Anthos Service Mesh-Installation auf eine neue Version zu aktualisieren.
-c|--ca {mesh_ca|citadel}
Bei Installationen müssen Sie diese Option nicht auswählen, wenn Sie Mesh-CA verwenden möchten, da das Skript standardmäßig Mesh CA verwendet. Bei Upgrades muss diese Option nicht angegeben werden, da das Skript die Änderung der Zertifizierungsstelle nicht zulässt. Für Migrationen geben Sie citadel oder mesh_ca an. Wenn Sie Ausfallzeiten für die Migration einplanen können, empfehlen wir die Verwendung von mesh_ca. Weitere Informationen dazu, welche CA verwendet werden soll, finden Sie unter Zertifizierungsstelle auswählen. Weitere Optionen, die Sie bei der Verwendung von Citadel angeben müssen, finden Sie unter Optionen für ein benutzerdefiniertes Zertifikat für Citadel.
--co|--custom_overlay YAML_FILE
Der Name der YAML-Datei für die benutzerdefinierte Ressource IstioOperator, um eine Funktion zu aktivieren, die nicht standardmäßig aktiviert ist. Das Skript muss die YAML-Datei finden können, sodass sich die Datei im selben Verzeichnis wie das Skript befindet. Sie können aber auch einen relativen Pfad angeben. Wenn Sie mehrere Dateien hinzufügen möchten, geben Sie --co|--custom_overlay und den Dateinamen ein. Beispiel: --co overlay_file1.yaml --co overlay_file2.yaml --co overlay_file3.yaml
-o|--option OPTION_FILE
Der Name einer YAML-Datei aus dem Paket anthos-service-mesh, die die CR IstioOperator enthält, um eine optionale Funktion zu aktivieren. Wenn Sie eine dieser Dateien einschließen, müssen Sie das Paket anthos-service-mesh nicht zuerst herunterladen und die Erweiterung .yaml nicht angeben. Wenn Sie eine der Dateien ändern müssen, laden Sie das Paket anthos-service-mesh herunter, nehmen Sie die Änderungen vor und verwenden Sie die Option --custom_overlay. Wenn Sie mehrere Dateien hinzufügen möchten, geben Sie -o|--option und den Dateinamen ein. Beispiel: -o option_file1 -o option_file2 -o option_file3
-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.7.8-asm.10. Das Verzeichnis asm enthält die Konfiguration für die Installation. Das Verzeichnis istio-1.7.8-asm.10 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.
--print_config
Anstatt die Anthos Service Mesh zu installieren, drucken Sie die gesamte kompilierte YAML als Standardausgabe (stdout). Alle anderen Ausgaben werden in Standardfehler (stderr) geschrieben, auch wenn sie normalerweise an stdout gesendet würden. Das Skript überspringt alle Validierungen und die Einrichtung, wenn Sie dieses Flag angeben.
--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.
--version
Gibt die Version von install_asm aus und beendet den Vorgang. Wenn der Befehl keine Version ausgibt, laden Sie die neueste Version von install_asm_1.7 herunter.

Optionen für ein benutzerdefiniertes Zertifikat für Citadel

Wenn Sie citadel angegeben haben und eine benutzerdefinierte Zertifizierungsstelle nutzen, verwenden Sie die folgenden Optionen:

  • --ca_cert FILE_PATH: Zwischenzertifikat
  • --ca_key FILE_PATH: Schlüssel für das Zwischenzertifikat
  • --root_cert FILE_PATH: Root-Zertifikat
  • --cert_chain FILE_PATH: Zertifikatskette

Weitere Informationen finden Sie unter Vorhandene CA-Zertifikate einbinden.

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 und Upgrades 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-178-10 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: Die Ausgabe für neue Installationen, Migrationen und Upgrades unterscheidet sich geringfügig. Die folgende Beispielausgabe stammt von einer Migration.

    NAME                                READY   STATUS    RESTARTS   AGE   LABELS
istiod-7744bc8dd7-qhlss             1/1     Running   0          49m   app=istiod,istio.io/rev=default,istio=pilot,pod-template-hash=7744bc8dd7
istiod-asm-178-10-85d86774f7-flrt2   1/1     Running   0          26m   app=istiod,istio.io/rev=asm-178-10,istio=istiod,pod-template-hash=85d86774f7
istiod-asm-178-10-85d86774f7-tcwtn   1/1     Running   0          26m   app=istiod,istio.io/rev=asm-178-10,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-178-10. Ihr Wert kann aber auch ein anderer sein.

    Notieren Sie sich bei Upgrades und Migrationen auch den Wert aus dem Überarbeitungslabel für die alte istiod-Version. Sie benötigen diesen, um die alte Version von istiod zu löschen, wenn die Migration oder das Upgrade abgeschlossen ist. 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.

Automatische Injektion aktivieren

Führen Sie diese Schritte für neue Installationen, Migrationen und Upgrades 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 Migration und Upgrades:

  • Wenn Ihre Anwendung wie erwartet funktioniert, fahren Sie mit dem nächsten Abschnitt fort, um die Umstellung auf die neue Version von istiod abzuschließen.

  • Wenn ein Problem mit Ihrer Anwendung vorliegt, folgen Sie den Schritten unter Rollback zur vorherigen Version.

Umstellung vornehmen

Für Migrationen und Upgrades 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 im Zuge einer Migration oder eines Upgrades beim Testen der Anwendung mit der neuen Version von istiod ein Problem auftritt, führen Sie die folgenden Schritte aus, um ein Rollback auf die vorherige Version durchzuführen:

  1. Benennen Sie Ihren Namespace um, um die automatische Injektion mit der vorherigen Version von istiod zu aktivieren. Der zu verwendende Befehl hängt davon ab, ob Sie ein Überarbeitungslabel oder istio-injection=enabled mit der vorherigen Version verwendet haben.

    • Wenn Sie ein Überarbeitungslabel für die automatische Injektion verwendet haben, führen Sie Folgendes aus:

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

    • Wenn Sie istio-injection=enabled verwendet haben, führen Sie Folgendes aus:

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

  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.

Gleiche Version neu installieren

Das Skript install_asm ruft istioctl install auf, um die Komponenten der Anthos Service Mesh-Steuerungsebene (istiod und istio-ingressgateway) für Installationen, Upgrades und Istio-Migrationen bereitzustellen. Da das Skript istioctl install verwendet, müssen Sie die Steuerungsebene mit der neuen Konfiguration neu installieren, wenn Sie Anthos Service Mesh für das Aktivieren einer optionalen Funktion konfigurieren möchten.

Es wurde eine Änderung am Skript install_asm vorgenommen, damit Sie dieselbe Version von Anthos Service Mesh neu installieren können. Wenn Sie dieselbe Version neu installieren, um eine optionale Funktion zu aktivieren, wird die vorhandene Konfiguration der Steuerungsebene überschrieben. Wenn Sie die vorhandene Installation anpassen, müssen Sie dieselben Optionen --option und/oder --custom_overlay aus der vorherigen Installation und die Optionen --option und/oder --custom_overlay für die Funktionen, die Sie aktivieren möchten, einschließen.

Wenn Sie Cloud Trace aktivieren oder eine Tracing-Einstellung ändern, müssen Sie auch Arbeitslasten neu bereitstellen, damit die Sidecar-Proxys wieder mit der aktualisierten Konfiguration der Steuerungsebene eingefügt werden.

Wenn Sie dieselbe Version neu installieren, geben Sie wie bei Installationen --mode install an. Informationen zur Installation mithilfe des Skripts finden Sie unter Anthos Service Mesh installieren.

Wenn Sie in einer YAML-Datei mehr als eine einzige benutzerdefinierte IstioOperator-Ressource angeben, teilt install_asm die Datei in mehrere temporäre YAML-Dateien auf – eine für jede benutzerdefinierte Ressource. Das Skript teilt die benutzerdefinierten Ressourcen in separate Dateien auf, da istioctl install nur die erste benutzerdefinierte Ressource in einer YAML-Datei anwendet, die mehr als eine benutzerdefinierte Ressource enthält.

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.

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

Mit Anthos Service Mesh 1.7.8 verwenden Sie die Version des install_asm-Skripts aus dem Zweig release-1.7-asm. Eine Erklärung zur Versionsverwaltung und zum Releaseprozess finden Sie unter Versionsverwaltung/Release.

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
  if [[ "${PRINT_CONFIG}" -eq 1 ]]; then
    return 0
  fi

  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_k8s
  validate_expected_control_plane

  if [[ "${MODE}" = "migrate" ]]; then
    validate_istio_version
  elif [[ "${MODE}" = "upgrade" ]]; then
    validate_asm_version
    validate_ca_consistency
  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
stackdriver.googleapis.com
EOF
}

set_up_cluster

set_up_cluster(){
  if [[ "${PRINT_CONFIG}" -eq 1 ]]; then
    return 0
  fi
  add_cluster_labels
  enable_workload_identity

  init_meshconfig

  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-178-10 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 PARAMS
  PARAMS="-f ${OPERATOR_MANIFEST} -f ${MULTICLUSTER_MANIFEST}"
  while read -d ',' -r yaml_file; do
    PARAMS="${PARAMS} -f ${yaml_file}"
  done <<EOF

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.

Nächste Schritte