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.
Aktivieren Sie die folgenden Google Cloud APIs:
container.googleapis.com
meshca.googleapis.com
meshconfig.googleapis.com
gkehub.googleapis.com
stackdriver.googleapis.com
Aktivieren Sie Workload Identity und Stackdriver für Ihren GKE-Cluster.
Versehen Sie Ihren Cluster mit einem Label, um die Benutzeroberfläche von Service zu aktivieren.
Erhalten Sie Administratorberechtigungen für den Kubernetes-Cluster.
Registrieren Sie den Cluster auf einer Flotte.
Aktivieren Sie das Feature
servicemesh
in der Flotte.
Umgebung einrichten
So richten Sie Ihre Umgebung ein:
Aktivieren Sie Cloud Shell in der Google Cloud Console.
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.
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
Erstellen Sie einen
WORKDIR
-Ordner.mkdir -p migrate-to-asm-working-dir && cd migrate-to-asm-working-dir && export WORKDIR=`pwd`
Erstellen Sie eine
KUBECONFIG
-Datei für diese Anleitung:touch asm-kubeconfig && export KUBECONFIG=`pwd`/asm-kubeconfig
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}
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:
- 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
- Anthos Service Mesh als Canary-Steuerungsebene neben einer vorhandenen Istio-Steuerungsebene installieren und Arbeitslasten vorbereiten
- Arbeitslasten auf Anthos Service Mesh testen und Namespaces für die Sidecar-Injektion von Anthos Service Mesh umbenennen
- Anthos Service Mesh-Dashboards aufrufen und prüfen
- 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 einerIstioOperator
-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äßigeistio-ingressgateway
aktualisiert.Option 2: Mit der Option
--no-gateways
. Wenn Sie Anthos Service Mesh ohne benutzerdefinierteIstioOperator
-Ressource installieren, können Sie auch die Option--no-gateways
verwenden, um das standardmäßigeistio-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 benutzerdefiniertenIstioOperator
-Ressource installieren. Wenn Sie Istio mit einer benutzerdefiniertenIstioOperator
-Ressource bereitgestellt haben, sollten Sie beim Installieren von Anthos Service Mesh dieselbeIstioOperator
-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:
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!
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)
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.
Rufen Sie in der Google Cloud Console die Seite Anthos Service Mesh auf.
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
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
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.
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
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
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
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.
Istio herunterladen:
curl -L https://istio.io/downloadIstio | ISTIO_VERSION=${ISTIO_VERSION} TARGET_ARCH=x86_64 sh -
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
- Option 1: ohne benutzerdefinierte Ressource
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.
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
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
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
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"
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
- 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.