Von Istio 1.7 oder höher zu Anthos Service Mesh und Mesh CA migrieren

In diesem Dokument wird beschrieben, wie Administratoren von Google Kubernetes Engine (GKE) Anthos Service Mesh installieren und Arbeitslasten migrieren können, die derzeit mit einem Istio Service Mesh ausgeführt werden. Die bereitgestellte Anthos Service Mesh-Konfiguration enthält Cloud Monitoring für Telemetrie und die Anthos Service Mesh-Zertifizierungsstelle (Mesh CA) für die verwaltete Mesh-Zertifikatsverwaltung mit Hochverfügbarkeit. Gateways, virtuelle Dienste und andere Mesh-Konfigurationen, die Ihre Mesh-Topologie definieren, bleiben bei der Migration erhalten.

Dieser Vorgang umfasst eine Installation mit einem einzelnen Cluster. Informationen zur Installation eines Multi-Cluster-Meshes finden Sie unter Multi-Cluster-Mesh in GKE einrichten. Darin sind die Schritte zum Hinzufügen von Clustern zum Anthos Service Mesh nach der Installation enthalten.

Sie können die Schritte in diesem Dokument nur ausführen, wenn Sie Istio 1.7 oder höher mit einem GKE-Cluster verwenden. Anthos Service Mesh unterstützt Helm nicht für die Installation oder Konfiguration. Wir empfehlen Mesh-Administratoren, die API IstioOperator für Mesh-Konfigurationen zu verwenden. Dieser Vorgang kann Ausfallzeiten für Ihre Anwendung verursachen, während Sie Zertifizierungsstellen wechseln. Wir empfehlen daher, diesen Vorgang während eines geplanten Wartungsfensters auszuführen.

Anthos Service Mesh verwendet dieselben Istio und Envoy APIs, um Ihr Mesh zu konfigurieren, sodass keine Änderung an vorhandenen Ressourcen erforderlich ist.

Im Folgenden sind einige Implementierungsunterschiede nach der Migration aufgeführt:

  • Die Istio-Steuerungsebene wird durch eine Anthos Service Mesh-Steuerungsebene ersetzt.

  • Die Citadel-Zertifizierungsstelle wird entfernt und Zertifikate werden von einem Mesh CA-Dienst von Google Cloud verwaltet.

  • Telemetrie wird an Cloud Logging und Cloud Monitoring gesendet. Dashboards und die SLO-Verwaltung sind in der Google Cloud Console verfügbar.

  • Wenn Sie eine benutzerdefinierte IstioOperator-Ressource haben, kann das Skript diese als Eingabe verwenden.

  • Ihre Open Source-Installation von Istio (Version 1.7 oder höher) wird zu Anthos Service Mesh Version 1.10 mit Mesh CA migriert. Wenn Sie eine andere Version von Istio haben oder eine andere Version von Anthos Service Mesh benötigen oder Anthos Service Mesh mit einer von Google verwalteten Steuerungsebene bereitstellen möchten, lesen Sie den Abschnitt Migration von Istio vorbereiten.

Vorbereitung

Für diese Anleitung sind die folgenden Voraussetzungen erforderlich:

  • Sie haben einen GKE-Cluster mit installierter Istio-Version 1.7 oder höher. Wenn Sie noch keinen GKE-Cluster haben oder diese Anleitung zuerst auf einem neuen (Test-)Cluster testen möchten, führen Sie die im Anhang beschriebenen Schritte aus, um einen neuen GKE-Cluster mit Istio Version 1.7 oder höher zu erstellen, der mit einer Testanwendung bereitgestellt wird.

  • Sie verwenden Cloud Shell, um die Schritte in dieser Anleitung auszuführen, da diese Anleitung in Cloud Shell getestet wird.

Lernziele

In dieser Anleitung wählen Sie einen Migrationspfad aus. Sie können zwischen einer skriptgesteuerten Migration in einem Schritt oder einer schrittweisen skriptgesteuerten Migration wählen.

Weitere Informationen finden Sie unter Migrationspfad auswählen.

Antworten auf häufig gestellte Fragen zu dieser Migration finden Sie in den FAQ zur Migration von Istio 1.7 oder höher zu Anthos Service Mesh und Mesh-CA.

Hinweise

Für diese Anleitung benötigen Sie Administratorzugriff auf einen GKE-Cluster, auf dem Istio installiert ist. Es empfiehlt sich, diesen Vorgang zuerst mit einem Cluster in einer Entwicklungs- oder Staging-Umgebung auszuführen, um das Verhalten Ihrer Anwendung während des Migrationsprozesses zu beobachten.

Anthos Service Mesh hat die folgenden Anforderungen. Sie können diese manuell selbst ausführen oder zulassen, dass die bereitgestellten Tools Abhängigkeiten während der Vorabinstallation für Sie aktivieren.

  1. Aktivieren Sie die folgenden Google Cloud APIs:

    • container.googleapis.com
    • meshca.googleapis.com
    • meshconfig.googleapis.com
    • gkehub.googleapis.com
    • stackdriver.googleapis.com

  2. Aktivieren Sie Workload Identity und Stackdriver für Ihren GKE-Cluster.

  3. Versehen Sie Ihren Cluster mit einem Label, um die Benutzeroberfläche von Service zu aktivieren.

  4. Erhalten Sie Administratorberechtigungen für den Kubernetes-Cluster.

  5. Registrieren Sie den Cluster auf einer Flotte.

  6. Aktivieren Sie das Feature servicemesh in der Flotte.

Umgebung einrichten

So richten Sie Ihre Umgebung ein:

  1. Aktivieren Sie Cloud Shell in der Google Cloud Console.

    Cloud Shell aktivieren

    Unten in der Google Cloud Console wird eine Cloud Shell-Sitzung gestartet und eine Eingabeaufforderung angezeigt. Cloud Shell ist eine Shell-Umgebung, in Google Cloud CLI bereits installiert ist und Werte für Ihr aktuelles Projekt bereits festgelegt sind. Das Initialisieren der Sitzung kann einige Sekunden dauern.

  2. Erstellen Sie die Umgebungsvariablen, die in dieser Anleitung verwendet werden:

    export PROJECT_ID=PROJECT_ID
gcloud config set project ${PROJECT_ID}
export PROJECT_NUM=$(gcloud projects describe ${PROJECT_ID} --format='value(projectNumber)')
export CLUSTER_NAME=GKE_CLUSTER_NAME
export CLUSTER_LOCATION=GKE_CLUSTER_REGION_OR_ZONE

  3. Erstellen Sie einen WORKDIR-Ordner.

    mkdir -p migrate-to-asm-working-dir && cd migrate-to-asm-working-dir && export WORKDIR=`pwd`

  4. Erstellen Sie eine KUBECONFIG-Datei für diese Anleitung:

    touch asm-kubeconfig && export KUBECONFIG=`pwd`/asm-kubeconfig

  5. Stellen Sie eine Verbindung zu Ihrem GKE-Cluster her:

    Zonale Cluster

    gcloud container clusters get-credentials ${CLUSTER_NAME} \
   --zone ${CLUSTER_LOCATION}

    Regionale Cluster

    gcloud container clusters get-credentials ${CLUSTER_NAME} \
   --region ${CLUSTER_LOCATION}

  6. Laden Sie das Migrationsskript herunter:

    curl -LO https://storage.googleapis.com/csm-artifacts/asm/migrate-to-asm
chmod +x ./migrate-to-asm

Migrationspfad auswählen

Sie können einen von zwei Pfaden auswählen, um zu Anthos Service Mesh zu migrieren. Wählen Sie nur eine dieser beiden Strategien aus und fahren Sie mit diesem Abschnitt fort:

  • Migration mit nur einem Schritt zu Anthos Service Mesh Wie der Name schon sagt, können Sie alle erforderlichen Schritte für die Migration zu Anthos Service Mesh mit einem einzigen Befehl ausführen. Dies kann hilfreich sein, wenn Sie eine große Anzahl von Clustern haben und ein schnelles und einfaches Upgrade auf Anthos Service Mesh benötigen. Diese Methode kann jedoch zu Ausfallzeiten der Anwendung führen.

  • Schrittweise Migration zu Anthos Service Mesh: Diese Methode gibt Ihnen mehr Kontrolle über die einzelnen Schritte und hilft Ihnen genau zu verstehen, was für die Migration zu Anthos Service Mesh erforderlich ist.

Schrittweise Migration zu Anthos Service Mesh

In diesem Abschnitt migrieren Sie Ihre derzeitige Installation von Istio Version 1.7 (oder höher) zu Anthos Service Mesh Version 1.10. In diesem Abschnitt können Sie die Migration mit einem einzigen Schritt ausführen. Informationen zum Ausführen der Migration mithilfe einer Reihe von Schritten finden Sie im Abschnitt Schritt-für-Schritt-Migration zu Anthos Service Mesh.

Führen Sie den folgenden Befehl aus, um zu Anthos Service Mesh zu migrieren. Bei jedem Befehl können Sie das Flag --dry-run verwenden, um Befehle auszudrucken, anstatt sie auszuführen, oder das Flag --verbose verwenden, um Befehle beim Ausführen des Skripts auszugeben. Wenn Sie Abhängigkeiten bereits konfiguriert haben, wie im Abschnitt Hinweis erwähnt, können Sie das Flag --enable-dependencies weglassen.

Keine benutzerdefinierte Ressource

Verwenden Sie keine benutzerdefinierte IstioOperator-Ressource:

./migrate-to-asm migrate \
    --cluster_location $CLUSTER_LOCATION \
    --cluster-name $CLUSTER_NAME \
    --project-id $PROJECT_ID \
    --enable-dependencies \
    --verbose

Benutzerdefinierte Ressource verwenden

Verwenden Sie eine benutzerdefinierte IstioOperator-Ressource:

export ISTIO_OPERATOR_FILEPATH=PATH_OF_ISTIO_OPERATOR_YAML_FILE

./migrate-to-asm migrate \
    --cluster_location $CLUSTER_LOCATION \
    --cluster-name $CLUSTER_NAME \
    --project-id $PROJECT_ID \
    --enable-dependencies \
    --custom_overlay ${ISTIO_OPERATOR_FILEPATH} \
    --verbose

Dieser Befehl führt die folgenden Schritte aus:

  • Die Istio-Version ist 1.7 oder höher.
  • Aktiviert Workload Identity auf dem Cluster. Workload Identity ist für die Mesh-Zertifizierungsstelle erforderlich. Sie müssen den GKE-Metadatenserver nicht in vorhandenen Knotenpools aktivieren.
  • Aktiviert die erforderlichen APIs für Anthos Service Mesh.
  • Registriert den Cluster in einer Flotte.
  • Aktualisiert den Cluster mit den erforderlichen Labels.
  • Ermittelt, ob eine von Google verwaltete Steuerungsebene für den angegebenen Cluster besser geeignet ist.
  • Stellt Anthos Service Mesh mit der optimalen Konfiguration der Steuerungsebene bereit.
  • Benennt alle Istio-fähigen Namespaces mit dem erforderlichen Anthos Service Mesh-Label.
  • Die Arbeitslasten werden in allen Anthos Service Mesh-fähigen Namespaces neu gestartet, sodass Arbeitslasten die neuen Anthos Service Mesh-Proxys erhalten.
  • Entfernt die Istio-Steuerungsebene.

Schrittweise Migration zu Anthos Service Mesh

In diesem Abschnitt migrieren Sie Ihre Installation von Istio Version 1.7 (oder höher) zu Anthos Service Mesh Version 1.10. In diesem Abschnitt können Sie eine Reihe von Schritten ausführen, um die Migration durchzuführen. Wenn Sie die Migration in einem einzigen Schritt ausführen möchten, finden Sie weitere Informationen im Abschnitt Migration mit nur einem Schritt zu Anthos Service Mesh.

Die folgenden Schritte sind für die Migration zu Anthos Service Mesh erforderlich:

  1. Einen Schritt vor der Migration ausführen, um den Cluster und die Umgebung für die Migration zu Anthos Service Mesh zu validieren und vorzubereiten
  2. Anthos Service Mesh als Canary-Steuerungsebene neben einer vorhandenen Istio-Steuerungsebene installieren und Arbeitslasten vorbereiten
  3. Arbeitslasten auf Anthos Service Mesh testen und Namespaces für die Sidecar-Injektion von Anthos Service Mesh umbenennen
  4. Anthos Service Mesh-Dashboards aufrufen und prüfen
  5. Istio-Artefakte bereinigen oder ein Rollback zu einer vorhandenen Istio-Version durchführen

Schritt vor der Migration ausführen

Der Schritt vor der Migration führt die folgenden Aktionen aus:

  • Es wird geprüft, ob die Projekt- und Clusterinformationen korrekt sind und dass die installierte Istio-Version mit der Migration kompatibel ist.

  • Sie sichert die Konfiguration für das Standardgateway und die Labels für das aktuelle Istio-Service-Mesh.

  • Wenn das Flag --enable-dependencies verwendet wird, werden Abhängigkeiten in Ihrem Namen aktiviert. Andernfalls wird geprüft, ob die Abhängigkeiten aktiviert sind.

Das Skript zur Vormigration erstellt im aktuellen Verzeichnis einen neuen Ordner (oder überschreibt einen vorhandenen Ordner) mit dem Namen configuration_backup.

Führen Sie den folgenden Befehl aus, um den Schritt vor der Migration auszuführen:

Abhängigkeiten

Abhängigkeiten aktivieren:

./migrate-to-asm pre-migrate \
    --cluster_location $CLUSTER_LOCATION \
    --cluster-name $CLUSTER_NAME \
    --project-id $PROJECT_ID \
    --enable-dependencies

Keine Abhängigkeiten

Aktivieren Sie keine Abhängigkeiten:

./migrate-to-asm pre-migrate \
    --cluster_location $CLUSTER_LOCATION \
    --cluster-name $CLUSTER_NAME \
    --project-id $PROJECT_ID

Die Ausgabe sieht in etwa so aus:

    migrate-to-asm: Checking installation tool dependencies...
    migrate-to-asm: Checking for $PROJECT_ID...
    migrate-to-asm: Confirming cluster information for $PROJECT_ID/$LOCATION/$CLUSTER_NAME...
    migrate-to-asm: Confirming node pool requirements for $PROJECT_ID/$LOCATION/$CLUSTER_NAME...
    migrate-to-asm: Checking existing Istio version(s)...
    migrate-to-asm:   1.9.5
    migrate-to-asm: No version issues found.
    migrate-to-asm: Enabling required APIs...
    migrate-to-asm:
    migrate-to-asm: APIs enabled.
    migrate-to-asm: Enabling the service mesh feature...
    migrate-to-asm:
    migrate-to-asm: The service mesh feature is already enabled.
    migrate-to-asm: Enabling Stackdriver on $LOCATION/$CLUSTER_NAME...
    Updating $CLUSTER_NAME...
    .........................done.
    Updated [https://container.googleapis.com/v1/projects/$PROJECT_ID/zones/$LOCATION/clusters/$CLUSTER_NAME].
    To inspect the contents of your cluster, go to: https://console.cloud.google.com/kubernetes/workload_/gcloud/$LOCATION/$CLUSTER_NAME?project=$PROJECT_ID
    migrate-to-asm:
    migrate-to-asm: Stackdriver enabled.
    migrate-to-asm: Querying for core/account...
    migrate-to-asm: Binding user@example.com to cluster admin role...
    migrate-to-asm:
    migrate-to-asm:
    migrate-to-asm: Successfully bound to cluster admin role.
    migrate-to-asm: Initializing meshconfig API...
      % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                     Dload  Upload   Total   Spent    Left  Speed
    100     3    0     3    0     0      6      0 --:--:-- --:--:-- --:--:--     6
    migrate-to-asm:
    migrate-to-asm: Finished pre-migration!

Anthos Service Mesh installieren und Arbeitslasten vorbereiten

Mit diesem Schritt wird Folgendes ausgeführt:

  • Es wird geprüft, ob der Ordner configuration_backup vorhanden ist. Wenn dieser nicht vorhanden ist, wird der Vorgang abgebrochen, um sicherzustellen, dass das Tool vor der Migration erfolgreich ausgeführt wurde.
  • Eine Anthos Service Mesh-Steuerungsebene wird entsprechend der Analyse der Cluster- und Mesh-Konfiguration installiert.
  • Sie verwendet die benutzerdefinierte IstioOperator-Ressource, falls eine angegeben ist. Wenn Sie benutzerdefinierte Gateways oder mehrere Gateways haben, die Sie mit einer IstioOperator-Ressource konfiguriert haben, verwenden Sie dieselbe Ressource in diesem Schritt.

Wenn Sie die Analyse überspringen und mit dem Tool eine nicht verwaltete Steuerungsebene installieren möchten, die mit den Ressourcen Ihres Clusters ausgeführt wird, fügen Sie dem Befehl das Flag --no-mcp hinzu.

Sie können bei der Installation von Anthos Service Mesh einen von drei Pfaden auswählen:

  • Option 1: Ohne benutzerdefinierte IstioOperator-Ressource. Sie können Anthos Service Mesh ohne eine benutzerdefinierte Ressource installieren. Mit dieser Option wird die Standardkonfiguration von Istio installiert und der standardmäßige istio-ingressgateway aktualisiert.

  • Option 2: Mit der Option --no-gateways. Wenn Sie Anthos Service Mesh ohne benutzerdefinierte IstioOperator-Ressource installieren, können Sie auch die Option --no-gateways verwenden, um das standardmäßige istio-ingressgateway nicht zu aktualisieren. Wenn Sie diese Option verwenden, müssen Sie Gateways nach der Installation manuell aktualisieren.

  • Option 3: Mit einer benutzerdefinierten IstioOperator-Ressource. Sie können Anthos Service Mesh mit einer benutzerdefinierten IstioOperator-Ressource installieren. Wenn Sie Istio mit einer benutzerdefinierten IstioOperator-Ressource bereitgestellt haben, sollten Sie beim Installieren von Anthos Service Mesh dieselbe IstioOperator-Ressource verwenden.

Führen Sie einen der folgenden Befehle aus, um Anthos Service Mesh zu installieren:

Option 1

Führen Sie ein Upgrade für das standardmäßige istio-ingressgateway durch:

 ./migrate-to-asm install-asm \
     --cluster_location $CLUSTER_LOCATION \
     --cluster-name $CLUSTER_NAME \
     --project-id $PROJECT_ID

Option 2

Führen Sie kein Upgrade für das standardmäßige istio-ingressgateway durch:

 ./migrate-to-asm install-asm \
     --cluster_location $CLUSTER_LOCATION \
     --cluster-name $CLUSTER_NAME \
     --project-id $PROJECT_ID \
     --no-gateways

3. Option

Aktualisieren Sie vorhandene Gateways mit einer benutzerdefinierten IstioOperator-Ressource:

 export ISTIO_OPERATOR_FILEPATH=PATH_OF_ISTIO_OPERATOR_YAML_FILE

 ./migrate-to-asm install-asm \
     --cluster_location $CLUSTER_LOCATION \
     --cluster-name $CLUSTER_NAME \
     --project-id $PROJECT_ID \
     --custom-overlay ${ISTIO_OPERATOR_FILEPATH}

Die Ausgabe sieht in etwa so aus:

 migrate-to-asm: Checking installation tool dependencies...
 migrate-to-asm: Checking for $PROJECT_ID...
 migrate-to-asm: Fetching/writing Google Cloud credentials to kubeconfig file...
 Fetching cluster endpoint and auth data.
 kubeconfig entry generated for $CLUSTER_NAME.
 migrate-to-asm:
 migrate-to-asm: Verifying connectivity (20s)...
 migrate-to-asm: kubeconfig set to $PROJECT_ID/$LOCATION/$CLUSTER_NAME...
 migrate-to-asm: Configuring kpt package...
 asm/
 set 20 field(s) of setter "gcloud.container.cluster" to value "$CLUSTER_NAME"
 asm/
 set 28 field(s) of setter "gcloud.core.project" to value "$PROJECT_ID"
 asm/
 set 2 field(s) of setter "gcloud.project.projectNumber" to value "42"
 asm/
 set 5 field(s) of setter "gcloud.project.environProjectNumber" to value "42"
 asm/
 set 20 field(s) of setter "gcloud.compute.location" to value "$LOCATION"
 asm/
 set 1 field(s) of setter "gcloud.compute.network" to value "$PROJECT_ID-default"
 asm/
 set 6 field(s) of setter "anthos.servicemesh.rev" to value "asm-1102-2"
 asm/
 set 5 field(s) of setter "anthos.servicemesh.tag" to value "1.10.2-asm.2"
 asm/
 set 4 field(s) of setter "anthos.servicemesh.hubTrustDomain" to value "$PROJECT_ID.svc.id.goog"
 asm/
 set 2 field(s) of setter "anthos.servicemesh.hub-idp-url" to value "https://container.googleapis.com/v1/projects/$PROJECT_ID/locations/$LOCATION/clusters/$CLUSTER_NAME"
 asm/
 set 4 field(s) of setter "anthos.servicemesh.trustDomainAliases" to value "$PROJECT_ID.svc.id.goog"
 migrate-to-asm: Configured.
 migrate-to-asm: Installing Anthos Service Mesh control plane...
 migrate-to-asm:
 - Processing resources for Istio core.
 ✔ Istio core installed
 - Processing resources for Istiod.
 - Processing resources for Istiod. Waiting for Deployment/istio-system/istiod-asm-1102-2
 ✔ Istiod installed
 - Processing resources for CNI, Ingress gateways.
 - Processing resources for CNI, Ingress gateways. Waiting for Deployment/istio-system/istio-ingressgateway
 ✔ CNI installed
 - Processing resources for Ingress gateways. Waiting for Deployment/istio-system/istio-ingressgateway
 ✔ Ingress gateways installed
 - Pruning removed resources
 migrate-to-asm:
 migrate-to-asm:
 namespace/asm-system created
 customresourcedefinition.apiextensions.k8s.io/canonicalservices.anthos.cloud.google.com configured
 role.rbac.authorization.k8s.io/canonical-service-leader-election-role created
 clusterrole.rbac.authorization.k8s.io/canonical-service-manager-role configured
 clusterrole.rbac.authorization.k8s.io/canonical-service-metrics-reader unchanged
 serviceaccount/canonical-service-account created
 rolebinding.rbac.authorization.k8s.io/canonical-service-leader-election-rolebinding created
 clusterrolebinding.rbac.authorization.k8s.io/canonical-service-manager-rolebinding unchanged
 clusterrolebinding.rbac.authorization.k8s.io/canonical-service-proxy-rolebinding unchanged
 service/canonical-service-controller-manager-metrics-service created
 deployment.apps/canonical-service-controller-manager created
 deployment.apps/canonical-service-controller-manager condition met
 migrate-to-asm:
 migrate-to-asm:
 migrate-to-asm: *******
 migrate-to-asm: Control plane installation complete!

Arbeitslasten wieder einfügen und Anwendungsverhalten prüfen

Die Anthos Service Mesh-Steuerungsebene ist jetzt bereit, Arbeitslasten zu verarbeiten, aber die vorhandene Istio-Steuerungsebene verwaltet weiterhin vorhandene Arbeitslasten. Zum Migrieren dieser Arbeitslasten müssen Sie Kubernetes-Namespaces, die derzeit für die Istio-Einfügung gekennzeichnet sind, mit dem Anthos Service Mesh-Überarbeitungslabel neu kennzeichnen. Anschließend müssen Sie Arbeitslasten in diesen Namespaces neu starten. Sie können dies manuell tun (siehe Hinweis in Schritt 1) oder mit dem Tool in einem Schritt erledigen.

Der Schritt „Relabeling” führt Folgendes aus:

  • Es werden alle Namespaces gefunden, die derzeit ein Istio-Injektionslabel verwenden.
  • Diese Namespaces werden mit istio.io/rev=asm-1102-2 neu beschriftet.
  • Die Arbeitslasten im Namespace werden neu gestartet.

So fügen Sie die Arbeitslasten wieder ein:

  1. Benennen Sie alle Istio-fähigen Namespaces neu und führen Sie die Arbeitslasten mit dem folgenden Befehl neu aus:

     ./migrate-to-asm relabel \
     --cluster_location $CLUSTER_LOCATION \
     --cluster-name $CLUSTER_NAME \
     --project-id $PROJECT_ID

    Die Ausgabe sieht in etwa so aus:

    migrate-to-asm: Checking installation tool dependencies...
migrate-to-asm: Checking for $PROJECT_ID...
migrate-to-asm: Fetching/writing Google Cloud credentials to kubeconfig file...
Fetching cluster endpoint and auth data.
kubeconfig entry generated for $CLUSTER_NAME.
migrate-to-asm:
migrate-to-asm: Verifying connectivity (20s)...
migrate-to-asm: kubeconfig set to $PROJECT_ID/$LOCATION/$CLUSTER_NAME...
******
migrate-to-asm: Installation of Anthos Service Mesh has completed. Migration will continue
migrate-to-asm: by relabeling and restarting workloads in the following namespaces:
migrate-to-asm:     namespace/default
migrate-to-asm:
Continue with migration? (Y/n)Y
migrate-to-asm: Relabeling namespace/default...
namespace/default labeled
migrate-to-asm: Restarting workloads in namespace/default and waiting for them to become available (max 5 min)...
deployment.apps/frontend restarted
deployment.apps/backend restarted
deployment.apps/frontend condition met
deployment.apps/backend condition met
migrate-to-asm: *******
migrate-to-asm: Finished restarting workloads!

  2. Warten Sie, bis alle Deployments neu gestartet wurden, und prüfen Sie dann mit dem folgenden Befehl die Version der Datenebene:

    istioctl version

    Die Ausgabe sieht in etwa so aus:

    client version: 1.8.0
pilot version: 1.9.5
istiod version: 1.10.2-asm.2
data plane version: 1.10.2-asm.2 (14 proxies)

  3. Prüfen Sie, ob die Anwendungen nach dem Neustart ordnungsgemäß funktionieren.

Auf Anthos Service Mesh-Dashboards zugreifen

In diesem Abschnitt rufen Sie die Anthos Service Mesh-Dashboards auf. Achten Sie darauf, dass Sie die goldenen Signale für alle Dienste erhalten. Sie sollten außerdem in der Lage sein, Ihre Anwendungstopologie zu sehen.

  1. Rufen Sie in der Google Cloud Console die Seite Anthos Service Mesh auf.

    Zu Anthos Service Mesh

  2. Sie sollten nun die Messwerte und die Topologie für Ihre Dienste einsehen können.

Weitere Informationen zu Anthos Service Mesh-Dashboards finden Sie unter Anthos Service Mesh in der Google Cloud Console kennenlernen.

Migration abschließen

Prüfen Sie vor Abschluss der Migration, ob alle Anwendungen ordnungsgemäß funktionieren. Nach Abschluss der Migration können Sie kein Rollback zur vorhandenen Istio-Version mehr durchführen. Der Abschluss der Migration umfasst folgende Schritte:

  • Es wird geprüft, ob alle ausgeführten Proxys im Cluster Anthos Service Mesh verwenden.
  • Nicht verwendete Istio-Komponenten werden aus dem Cluster entfernt. Dieser Schritt kann nicht rückgängig gemacht werden.

Führen Sie den folgenden Befehl aus, um die Migration zu Anthos Service Mesh abzuschließen:

 ./migrate-to-asm finalize \
     --cluster_location $CLUSTER_LOCATION \
     --cluster-name $CLUSTER_NAME \
     --project-id $PROJECT_ID
Die Ausgabe sieht in etwa so aus: 
migrate-to-asm: Checking installation tool dependencies...
migrate-to-asm: Checking for asm-scriptaro-oss...
migrate-to-asm: All proxies running Anthos Service Mesh!
Remove previous control plane resources? (Y/n)
migrate-to-asm: ****
migrate-to-asm: Previous Istio control plane has been removed.

Rollback zu einer vorhandenen Istio-Version durchführen

Führen Sie den Rollback-Schritt aus, um Namespaces mit dem vorherigen Istio-Injektionslabel neu zu benennen, Arbeitslasten neu zu starten und Änderungen am Gateway rückgängig zu machen. Anschließend entfernt das Tool alle Anthos Service Mesh-Komponenten, die im Cluster bereitgestellt werden.

Sie müssen alle Abhängigkeiten, die durch den Schritt der Migration aktiviert wurden, manuell zurücksetzen.

Führen Sie den folgenden Befehl aus, um ein Rollback zu Istio durchzuführen:

 ./migrate-to-asm rollback \
     --cluster_location $CLUSTER_LOCATION \
     --cluster-name $CLUSTER_NAME \
     --project-id $PROJECT_ID
Die Ausgabe sieht in etwa so aus: 
migrate-to-asm: Checking installation tool dependencies...
migrate-to-asm: Checking for $PROJECT_ID...
******
migrate-to-asm: Rolling back migration by relabeling and restarting workloads
migrate-to-asm: in the following namespaces:
migrate-to-asm:     namespace/default
migrate-to-asm:
Continue with rollback? (Y/n)
migrate-to-asm: Relabeling namespace/default...
namespace/default labeled
migrate-to-asm: Restarting workloads in namespace/default and waiting for them to become available (max 5 min)...
deployment.apps/frontend restarted
deployment.apps/backend restarted
deployment.apps/frontend condition met
deployment.apps/backend condition met
migrate-to-asm: *******
migrate-to-asm: Finished restarting workloads!
service/istio-ingressgateway configured
deployment.apps/istio-ingressgateway configured
There are still 14 proxies pointing to the control plane revision asm-1102-2
istio-ingressgateway-66c85975d-2gt8c.istio-system
istio-ingressgateway-66c85975d-jdd96.istio-system
...
frontend-685dcb78d6-9l45j.default
If you proceed with the uninstall, these proxies will become detached from any control plane and will not function correctly.

Removed HorizontalPodAutoscaler:istio-system:istio-ingressgateway.
Removed HorizontalPodAutoscaler:istio-system:istiod-asm-1102-2.
...
Removed ClusterRoleBinding::mdp-controller.
✔ Uninstall complete
namespace "asm-system" deleted
migrate-to-asm: ****
migrate-to-asm: Anthos Service Mesh has been uninstalled from the cluster.

Anhang

GKE-Cluster mit installiertem Istio erstellen

In diesem Abschnitt stellen Sie einen GKE-Cluster mit aktiviertem Istio bereit. Sie können einen privaten oder einen nicht privaten GKE-Cluster verwenden. Private GKE-Cluster müssen einen öffentlichen GKE-Endpunkt haben. Prüfen Sie auch die Istio-Installation.

Wenn Sie bereits einen GKE-Cluster haben, können Sie den Schritt zum Erstellen überspringen und dafür sorgen, dass Sie Zugriff auf den Cluster haben, der die Datei KUBECONFIG verwendet. Der Kontext, den dieser Leitfaden verwendet, ist in der Variablen ${CLUSTER_1_CTX} definiert. Sie können den Kontext Ihres Clusters auf diese Variable festlegen.

  1. Erstellen Sie die Umgebungsvariablen, die in dieser Anleitung verwendet werden:

    # Enter your project ID
export PROJECT_ID=PROJECT_ID
gcloud config set project ${PROJECT_ID}
export PROJECT_NUM=$(gcloud projects describe ${PROJECT_ID} --format='value(projectNumber)')
export CLUSTER_NAME=GKE_CLUSTER_NAME
export CLUSTER_LOCATION=GKE_CLUSTER_REGION_OR_ZONE
export CLUSTER_CTX=gke_${PROJECT_ID}_${CLUSTER_LOCATION}_${CLUSTER_NAME}
export ISTIO_VERSION=ISTIO_VERSION # Must be versions 1.7 through 1.10 and must be of the form major.minor.patch, for example 1.7.4 or 1.9.5

  2. GKE-Cluster mit aktiviertem Istio erstellen (dies ist ein privater Cluster). Sie können diese Schritte auch mit einem nicht privaten GKE-Cluster ausführen.

    Zonale Cluster

    gcloud container clusters create ${CLUSTER_NAME} \
    --project ${PROJECT_ID} \
    --zone ${CLUSTER_LOCATION} \
    --machine-type "e2-standard-4" \
    --num-nodes "4" --min-nodes "2" --max-nodes "5" \
    --enable-ip-alias --enable-autoscaling

    Regionale Cluster

    gcloud container clusters create ${CLUSTER_NAME} \
    --project ${PROJECT_ID} \
    --region ${CLUSTER_LOCATION} \
    --machine-type "e2-standard-4" \
    --num-nodes "4" --min-nodes "2" --max-nodes "5" \
    --enable-ip-alias --enable-autoscaling

  3. Prüfen Sie, ob der Cluster RUNNING ist:

     gcloud container clusters list

    Die Ausgabe sieht in etwa so aus:

    NAME      LOCATION    MASTER_VERSION    MASTER_IP      MACHINE_TYPE   NODE_VERSION      NUM_NODES  STATUS
gke-east  us-east1-b  1.19.10-gke.1600  34.73.171.206  e2-standard-4  1.19.10-gke.1600  4          RUNNING

  4. Als Nächstes stellen Sie die Verbindung zum Cluster her:

    Zonale Cluster

    gcloud container clusters get-credentials ${CLUSTER_NAME} \
    --zone ${CLUSTER_LOCATION}

    Regionale Cluster

    gcloud container clusters get-credentials ${CLUSTER_NAME} \
    --region ${CLUSTER_LOCATION}

Denken Sie daran, die Festlegung der Variablen KUBECONFIG am Ende aufzuheben.

Istio installieren

In diesem Abschnitt stellen Sie im GKE-Cluster die Istio-Version 1.7 bereit.

  1. Istio herunterladen:

    curl -L https://istio.io/downloadIstio | ISTIO_VERSION=${ISTIO_VERSION} TARGET_ARCH=x86_64 sh -

  2. Installieren Sie Istio mit dem istioctl-Befehlszeilentool. Wählen Sie eine der folgenden Optionen aus:

    • Option 1: ohne benutzerdefinierte Ressource IstioOperator

    • Option 2: mit einer benutzerdefinierten IstioOperator-Ressource

    Option 1

    Ohne eine benutzerdefinierte IstioOperator-Ressource:

    ./istio-${ISTIO_VERSION}/bin/istioctl install --set profile=default -y

    Die Ausgabe sieht in etwa so aus:

    ✔ Istio core installed
✔ Istiod installed
✔ Ingress gateways installed
✔ Installation complete

    Option 2

    Mit einer benutzerdefinierten IstioOperator-Ressource:

    cat <<EOF > istio-operator.yaml
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
 name: istio-operator
spec:
 components:
   base:
     enabled: true
   ingressGateways:
   - enabled: true
     k8s:
       env:
       - name: TERMINATION_DRAIN_DURATION_SECONDS
         value: "10"
       hpaSpec:
         maxReplicas: 10
         metrics:
         - resource:
             name: cpu
             targetAverageUtilization: 80
           type: Resource
         minReplicas: 2
       resources:
         limits:
           cpu: "4"
           memory: 8Gi
         requests:
           cpu: "2"
           memory: 4Gi
       service:
         ports:
         - name: status-port
           port: 15021
           targetPort: 15021
         - name: http2
           port: 80
           targetPort: 8080
         - name: https
           port: 443
           targetPort: 8443
         - name: tls
           port: 15443
           targetPort: 15443
     name: istio-ingressgateway
   - enabled: true
     k8s:
       env:
       - name: TERMINATION_DRAIN_DURATION_SECONDS
         value: "10"
       hpaSpec:
         maxReplicas: 10
         minReplicas: 2
       resources:
         limits:
           cpu: "4"
           memory: 8Gi
         requests:
           cpu: "2"
           memory: 4Gi
       service:
         ports:
         - name: status-port
           port: 15021
           targetPort: 15021
         - name: http2
           port: 80
           targetPort: 8080
         - name: https
           port: 443
           targetPort: 8443
         - name: tls
           port: 15443
           targetPort: 15443
     label:
       istio: istio-api-ingressgateway
     name: istio-api-ingressgateway
 meshConfig:
   defaultConfig:
     tracing:
       sampling: 1
       zipkin:
         address: jaeger-collector.observability.svc.cluster.local:9411
   enableTracing: true
EOF

./istio-${ISTIO_VERSION}/bin/istioctl install -f istio-operator.yaml -y

    Die Ausgabe sieht in etwa so aus:

    ✔ Istio core installed
✔ Istiod installed
✔ Ingress gateways installed
✔ Installation complete

  3. Prüfen Sie, ob Istio-Services und -Pods bereitgestellt werden:

    kubectl --context=${CLUSTER_CTX} -n istio-system get services,pods

    Die Ausgabe sieht in etwa so aus:

    Option 1

    Ohne eine benutzerdefinierte IstioOperator-Ressource:

    NAME                           TYPE           CLUSTER-IP     EXTERNAL-IP         PORT(S)                                                      AGE
service/istio-ingressgateway   LoadBalancer   10.64.5.113    <pending>           15021:31285/TCP,80:31740/TCP,443:30753/TCP,15443:31246/TCP   33s
service/istiod                 ClusterIP      10.64.15.184   <none>              15010/TCP,15012/TCP,443/TCP,15014/TCP,853/TCP                45s

NAME                                        READY   STATUS    RESTARTS   AGE
pod/istio-ingressgateway-6f44d6745b-22q9h   1/1     Running   0          34s
pod/istiod-b89f5cc6-nhsrc                   1/1     Running   0          48s

    Option 2

    Mit einer benutzerdefinierten IstioOperator-Ressource:

    NAME                               TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)                                                      AGE
service/istio-api-ingressgateway   LoadBalancer   10.100.0.84    104.196.26.108   15021:32489/TCP,80:30083/TCP,443:30565/TCP,15443:30705/TCP   76s
service/istio-ingressgateway       LoadBalancer   10.100.3.221   34.139.111.125   15021:30966/TCP,80:31557/TCP,443:31016/TCP,15443:31574/TCP   75s
service/istiod                     ClusterIP      10.100.13.72   <none>           15010/TCP,15012/TCP,443/TCP,15014/TCP                        86s

NAME                                            READY   STATUS    RESTARTS   AGE
pod/istio-api-ingressgateway-79978ddc65-hslbv   1/1     Running   0          61s
pod/istio-api-ingressgateway-79978ddc65-z92w8   1/1     Running   0          77s
pod/istio-ingressgateway-fb47c4859-pkdn7        1/1     Running   0          60s
pod/istio-ingressgateway-fb47c4859-t2pfq        1/1     Running   0          77s
pod/istiod-9445656d7-fxk9j                      1/1     Running   0          89s

Online Boutique bereitstellen

In diesem Abschnitt stellen Sie eine auf Mikrodiensten basierende Beispielanwendung namens „Online Boutique” im GKE-Cluster bereit. Online Boutique wird in einem Istio-fähigen Namespace bereitgestellt. Prüfen Sie, ob die Anwendung funktioniert und dass Istio die Sidecar-Proxys in jeden Pod einfügt.

Wenn Sie bereits Cluster mit Anwendungen haben, können Sie einen neuen Namespace erstellen und Online Boutique bereitstellen. Sie können für alle Namespaces im Abschnitt Anthos Service Mesh installieren und Arbeitslasten vorbereiten denselben Prozess verwenden.

  1. Stellen Sie Online Boutique im GKE-Cluster bereit:

    kpt pkg get \
https://github.com/GoogleCloudPlatform/microservices-demo.git/release \
online-boutique

kubectl --context=${CLUSTER_CTX} create namespace online-boutique
kubectl --context=${CLUSTER_CTX} label namespace online-boutique istio-injection=enabled

kubectl --context=${CLUSTER_CTX} -n online-boutique apply -f online-boutique

  2. Warten Sie, bis alle Deployments bereit sind:

    kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment adservice
kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment checkoutservice
kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment currencyservice
kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment emailservice
kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment frontend
kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment paymentservice
kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment productcatalogservice
kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment shippingservice
kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment cartservice
kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment loadgenerator
kubectl --context=${CLUSTER_CTX} -n online-boutique wait --for=condition=available --timeout=5m deployment recommendationservice

  3. Prüfen Sie, ob pro Pod zwei Container vorhanden sind: der Anwendungscontainer und der Istio-Sidecar-Proxy, der Istio automatisch in den Pod einfügt:

    kubectl --context=${CLUSTER_CTX} -n online-boutique get pods

    Die Ausgabe sieht in etwa so aus:

    NAME                                     READY   STATUS    RESTARTS   AGE
adservice-7cbc9bd9-t92k4                 2/2     Running   0          3m21s
cartservice-d7db78c66-5qfmt              2/2     Running   1          3m23s
checkoutservice-784bfc794f-j8rl5         2/2     Running   0          3m26s
currencyservice-5898885559-lkwg4         2/2     Running   0          3m23s
emailservice-6bd8b47657-llvgv            2/2     Running   0          3m27s
frontend-764c5c755f-9wf97                2/2     Running   0          3m25s
loadgenerator-84cbcd768c-5pdbr           2/2     Running   3          3m23s
paymentservice-6c676df669-s779c          2/2     Running   0          3m25s
productcatalogservice-7fcf4f8cc-hvf5x    2/2     Running   0          3m24s
recommendationservice-79f5f4bbf5-6st24   2/2     Running   0          3m26s
redis-cart-74594bd569-pfhkz              2/2     Running   0          3m22s
shippingservice-b5879cdbf-5z7m5          2/2     Running   0          3m22s

  4. Sie können auch die Sidecar-Envoy-Proxy-Version von einem der Pods prüfen, um zu bestätigen, dass Sie Envoy-Proxys der Version 1.4 bereitgestellt haben:

    export FRONTEND_POD=$(kubectl get pod -n online-boutique -l app=frontend --context=${CLUSTER_CTX} -o jsonpath='{.items[0].metadata.name}')
kubectl --context=${CLUSTER_CTX} get pods ${FRONTEND_POD} -n online-boutique -o json | jq '.status.containerStatuses[].image'

    Die Ausgabe sieht in etwa so aus:

    "docker.io/istio/proxyv2:1.7.4"
"gcr.io/google-samples/microservices-demo/frontend:v0.3.4"

  5. Greifen Sie über die IP-Adresse der Dienst-IP-Adresse istio-ingressgateway auf die Anwendung zu:

    kubectl --context=${CLUSTER_CTX} -n istio-system get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}'

Nächste Schritte