Migration mit Istio-Mesh-Netzwerkerweiterung bereitstellen

Last reviewed 2023-11-02 UTC

In diesem Dokument wird beschrieben, wie Sie ein Service Mesh initialisieren und konfigurieren, um eine Feature-für-Feature-Migration von einem lokalen Rechenzentrum zu Google Cloud zu unterstützen. Dabei wird davon ausgegangen, dass Sie mit der zugehörigen Referenzarchitektur vertraut sind. Sie richtet sich an Administratoren,und Entwickler, die ein Service Mesh verwenden möchten, das den Traffic dynamisch an die Quellumgebung oder an Google Cloud weiterleitet.

Dieser Bereitstellungsleitfaden soll Ihnen bei der Migration von einer Nicht-Google Cloud-Umgebung zu Google Cloud helfen (z. B. von einer lokalen Umgebung oder einem anderen Cloud-Anbieter). Solche Migrationen sind komplex, da Sie einen sicheren Kommunikationskanal zwischen der Nicht-Google Cloud-Umgebung und der Google Cloud-Umgebung einrichten müssen.

Architektur

Das folgende Diagramm zeigt, wie Sie ein Service Mesh verwenden können, um Traffic entweder an Mikrodienste in der Quellumgebung oder an Google Cloud weiterzuleiten:

Im Diagramm stellt Istio Gateway ein Service Mesh bereit, das die Mikrodienste einer Anwendung verknüpft. Google Kubernetes Engine (GKE) fungiert als Container, um die Grenzen der einzelnen Mikrodienste zu definieren. Weitere Informationen finden Sie unter Migration mit Istio-Mesh-Erweiterung erleichtern.

In dieser Bereitstellung verwenden Sie folgende Software:

• Ubuntu Server und Container-Optimized OS: In dieser Bereitstellung verwendete Betriebssysteme.
• Docker Engine: Plattform zum Ausführen von Containerarbeitslasten.
• Docker Compose: Ein Tool, um Docker-Anwendungen zu definieren und auszuführen.
• Istio: Ein Open-Source-Service-Mesh.
• Kiali: Ein Tool, um Service Meshes von Istio zu visualisieren.
• Envoy: Ein von Istio verwendeter Sidecar-Proxy, mit dem Dienste in das Mesh-Netzwerk eingebunden werden.

Beispielarbeitslast

In dieser Bereitstellung verwenden Sie die Anwendung Bookinfo. Sie ist eine 4-stufige, mehrsprachige Anwendung für Mikrodienste, die Informationen über Bücher anzeigt. Diese Anwendung ist für die Ausführung auf Kubernetes vorgesehen. Sie stellen sie jedoch mit Docker und Docker Compose auf einer Compute Engine-Instanz bereit. Mit Docker Compose beschreiben Sie Anwendungen in mehreren Containern mithilfe von YAML-Deskriptoren. Sie können die Anwendung dann starten, indem Sie einen einzelnen Befehl ausführen.

Obwohl diese Beispielarbeitslast bereits containerisiert ist, gilt dieser Ansatz auch für nicht-containerisierte Dienste. In solchen Fällen können Sie eine Modernisierungsphase hinzufügen, in der Sie Dienste containerisieren, die Sie migrieren möchten.

Die Anwendung Bookinfo verfügt über vier Mikrodienstkomponenten:

• productpage: Ruft die Mikrodienste details, ratings und reviews auf, um die Informationsseite zum Buch zu füllen
• details: Liefert Informationen zu Büchern
• reviews: Enthält Buchrezensionen
• ratings: Gibt Informationen zum Buchranking zurück, die einer Buchrezension beigefügt sind

Die Autoren und Betreuer der Bookinfo-Anwendung haben mehrere Versionen einiger dieser Komponenten implementiert, um Istio und seine Features vorzustellen. In dieser Bereitstellung stellen Sie nur eine einzige Version jeder Komponente zur Verfügung.

Lernziele

• Umgebung initialisieren, die das lokale Rechenzentrum simuliert.
• Beispielarbeitslasten im lokalen Rechenzentrum bereitstellen und testen.
• Zielumgebung in Google Cloud konfigurieren.
• Arbeitslast vom lokalen Rechenzentrum zur Zielumgebung migrieren.
• In der Zielumgebung ausgeführte Arbeitslasten testen.
• Das lokale Rechenzentrum deaktivieren.

Kosten

In diesem Dokument verwenden Sie die folgenden kostenpflichtigen Komponenten von Google Cloud:

• Compute Engine
• Google Kubernetes Engine (GKE)
• Persistent Disk
• Netzwerk

Mit dem Preisrechner können Sie eine Kostenschätzung für Ihre voraussichtliche Nutzung vornehmen. Neuen Google Cloud-Nutzern steht möglicherweise eine kostenlose Testversion zur Verfügung.

Umgebung vorbereiten

Die meisten Schritte in dieser Bereitstellung werden in Cloud Shell ausgeführt.

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 der das 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. Prüfen Sie in Cloud Shell den verfügbaren freien Speicherplatz:

   df -h
   

   Um diese Bereitstellung abzuschließen, benötigen Sie etwa 200 MB freien Speicherplatz.

3. Wechseln Sie vom Arbeitsverzeichnis in das Verzeichnis ${HOME}:

   cd "${HOME}"
   

4. Klonen Sie das Git-Repository, das die Skripts und Manifestdateien enthält, um die Beispielarbeitslast bereitzustellen und zu konfigurieren:

   git clone https://github.com/GoogleCloudPlatform/solutions-istio-mesh-expansion-migration
   

5. Authentifizieren Sie sich mit Standardanmeldedaten für Anwendungen (Application Default Credentials, ADC):

   gcloud auth application-default login
   

   Die Ausgabe zeigt den Pfad zur Datei Application Default Credentials:

   Credentials saved to file:
   [/tmp/tmp.T5Qae7XwAO/application_default_credentials.json]
   

   Notieren Sie sich den Pfad zur Datei Application Default Credentials. Diese Anmeldedaten werden von jeder Bibliothek verwendet, die ADC anfordert.

6. Initialisieren Sie die Umgebungsvariablen:

   APPLICATION_DEFAULT_CREDENTIALS_PATH=APPLICATION_DEFAULT_CREDENTIALS_PATH
   BILLING_ACCOUNT_ID=BILLING_ACCOUNT_ID
   DEFAULT_FOLDER=DEFAULT_FOLDER
   DEFAULT_PROJECT=DEFAULT_PROJECT
   DEFAULT_REGION=DEFAULT_REGION
   DEFAULT_ZONE=DEFAULT_ZONE
   GKE_CLUSTER_NAME=istio-migration
   DEPLOYMENT_DIRECTORY_PATH="$(pwd)"/solutions-istio-mesh-expansion-migration
   ORGANIZATION_ID=ORGANIZATION_ID
   

   Ersetzen Sie Folgendes:

   • APPLICATION_DEFAULT_CREDENTIALS_PATH ist der Pfad zur ADC-Datei aus dem vorherigen Schritt.
   • BILLING_ACCOUNT_ID ist die ID des zu verwendenden Rechnungskontos.
   • DEFAULT_FOLDER ist die ID des Google Cloud-Ordners, in dem das Google Cloud-Projekt erstellt werden soll. Wenn Terraform das Google Cloud-Projekt direkt unter der Google Cloud-Organisation erstellen soll, lassen Sie diesen String leer.
   • DEFAULT_PROJECT ist die ID des Google Cloud-Projekts, das die Ressourcen für diese Bereitstellung zur Verfügung stellen soll. Terraform erstellt dieses Projekt für Sie, wenn es die Umgebung bereitstellt.
   • DEFAULT_REGION ist die Standardregion, in der Ressourcen bereitgestellt werden.
   • DEFAULT_ZONE ist die Standardzone, in der Ressourcen bereitgestellt werden.
   • ORGANIZATION_ID ist die ID Ihrer Google Cloud-Organisation.

Umgebungen bereitstellen

In diesem Abschnitt stellen Sie die folgenden Umgebungen für diese Bereitstellung bereit:

• Eine Umgebung, die das lokale Quellrechenzentrum simuliert.
• Eine Umgebung, die das Migrationsziel simuliert.

In dieser Bereitstellung werden beide Umgebungen in Google Cloud ausgeführt. Dieser Ansatz vereinfacht die Einrichtung, da es nur eine Bootstrapping-Phase gibt. Die Quell- und die Zielumgebung werden automatisch mit Terraform bereitgestellt.

1. Legen Sie in Cloud Shell das Repository-Verzeichnis als Arbeitsverzeichnis fest:

   cd "${DEPLOYMENT_DIRECTORY_PATH}"
   

2. Initialisieren Sie die Back-End-Konfiguration von Terraform:

   scripts/init.sh \
   --application-credentials "${APPLICATION_DEFAULT_CREDENTIALS_PATH}" \
   --billing-account-id "${BILLING_ACCOUNT_ID}" \
   --default-folder "${DEFAULT_FOLDER}" \
   --default-project "${DEFAULT_PROJECT}" \
   --default-region "${DEFAULT_REGION}" \
   --default-zone "${DEFAULT_ZONE}" \
   --organization-id "${ORGANIZATION_ID}"
   

   Das Skript init.sh tut Folgendes:

   • Generiert die Deskriptoren zum Konfigurieren des Terraform-Back-Ends.
   • Initialisiert das Terraform-Arbeitsverzeichnis.

3. Wechseln Sie vom Arbeitsverzeichnis in das Verzeichnis terraform:

   cd "${DEPLOYMENT_DIRECTORY_PATH}"/terraform
   

4. Wenden Sie die Änderungen mit Terraform an:

   terraform apply
   

5. Wenn Sie dazu aufgefordert werden, prüfen Sie die vorgeschlagenen Änderungen und bestätigen Sie durch Eingabe von yes.

   Die Ausgabe sieht in etwa so aus:

   Apply complete! Resources: 27 added, 0 changed, 0 destroyed
   

Durch Anwenden der vorgeschlagenen Änderungen mit Terraform automatisieren Sie die folgenden Aufgaben:

• Firewallregeln erstellen, um externen Zugriff auf die Mikrodienste und die Datenbank und die Kommunikation zwischen Knoten zu ermöglichen.
• Dienstkonto für die zu verwendenden Compute Engine-Instanzen erstellen und aktivieren. Wir empfehlen, das Dienstkonto auf die Rollen und Zugriffsberechtigungen zu beschränken, die zur Ausführung der Anwendung erforderlich sind. Für diese Bereitstellung benötigt das Dienstkonto für Compute Engine-Instanzen nur die Rolle „Compute Viewer“ (roles/compute.viewer). Diese Rolle bietet schreibgeschützten Zugriff auf Compute Engine-Ressourcen.
• Compute Engine-Instanz zum Hosten der zu migrierenden Arbeitslasten als Quellumgebung bereitstellen und konfigurieren. Wenn Sie die Compute Engine-Instanz konfigurieren, geben Sie ein Startscript an, das Docker, Docker Compose und Dnsmasq installiert.
• Dienstkonto für den GKE-Cluster zum Hosten der Arbeitslasten als Zielumgebung erstellen und aktivieren. In dieser Bereitstellung erstellen Sie ein Dienstkonto, das von den GKE-Clusterknoten verwendet wird. Wir empfehlen, das Dienstkonto auf die Rollen und Zugriffsberechtigungen zu beschränken, die zur Ausführung der Anwendung erforderlich sind. In dieser Bereitstellung werden folgende Rollen für das Dienstkonto von GKE-Clusterknoten benötigt:
  • Monitoring-Betrachter (roles/monitoring.viewer)
  • Monitoring-Messwert-Autor (roles/monitoring.metricWriter)
  • Log-Autor (roles/logging.logWriter), wie unter Sicherheit des Clusters erhöhen beschrieben.
• GKE-Cluster zum Hosten der Arbeitslasten als Zielumgebung bereitstellen und konfigurieren. Zur Bereitstellung der GKE-Cluster verwendet Terraform das Terraform-Modul „kubernetes-engine“.

Arbeitslast in der Quell-Umgebung bereitstellen

In dieser Bereitstellung stellen Sie die Istio-Bookinfo-Anwendung als Arbeitslast für die Migration bereit. Das folgende Diagramm zeigt die Architektur der Quellumgebung:

Im Diagramm greifen Clients auf die in Compute Engine ausgeführte Beispielarbeitslast zu. Zur Vereinfachung dieses Beispiels stellen Clients eine direkte Verbindung zu einer einzelnen Compute Engine-Instanz her. In einer Produktionsumgebung ist diese direkte Verbindung unwahrscheinlich, da Sie eine Load-Balancing-Ebene benötigen, um mehrere Instanzen einer Arbeitslast auszuführen.

1. Legen Sie in Cloud Shell das Repository-Verzeichnis als Arbeitsverzeichnis fest:

   cd "${DEPLOYMENT_DIRECTORY_PATH}"
   

2. Stellen Sie die Arbeitslasten in den Compute Engine-Instanzen bereit:

   scripts/workloads.sh \
   --deploy-with "COMPOSE" \
   --default-project "${DEFAULT_PROJECT}" \
   --default-region "${DEFAULT_REGION}" \
   --default-zone "${DEFAULT_ZONE}"
   

   Das Skript workloads.sh tut Folgendes:

   • Konfiguriert das Standardprojekt, die -Region und die -Zone.
   • Kopiert die Docker Compose-Deskriptoren in die Compute Engine-Instanzen.
   • Stellt die Beispielarbeitslast mit Docker Compose bereit.

   Wenn Sie noch keine SSH-Schlüsseldatei zur Authentifizierung bei Compute Engine-Instanzen erstellt haben, werden Sie von der gcloud CLI aufgefordert, eine zu generieren.

   In der Ausgabe wird eine Bestätigung der Bereitstellung angezeigt und wie Sie darauf zugreifen können. Die Ausgabe sieht in etwa so aus:

   You can access the workload by loading http://COMPUTE_ENGINE_PRODUCTPAGE_EXTERNAL_IP:9080/productpage
   

   In der Ausgabe ist COMPUTE_ENGINE_PRODUCTPAGE_EXTERNAL_IP die IP-Adresse, unter der die Arbeitslast bereitgestellt wird. Notieren Sie sich die IP-Adresse. Sie benötigen sie in einem späteren Schritt.

Bereitstellung in der Quell-Umgebung testen

• Öffnen Sie einen Browser und rufen Sie die folgende URL auf, wobei COMPUTE_ENGINE_PRODUCTPAGE_EXTERNAL_IP die IP-Adresse aus dem vorherigen Schritt ist:

  http://COMPUTE_ENGINE_PRODUCTPAGE_EXTERNAL_IP:9080/productpage
  

Es wird eine Bookinfo-Seite mit Details zu Büchern und relevanten Bewertungen angezeigt:

Istio konfigurieren:

In diesem Abschnitt konfigurieren Sie die Zielumgebung in Google Cloud, indem Sie Istio installieren, und verwenden dann Istio, um die Beispielarbeitslast verfügbar zu machen. Das folgende Diagramm zeigt die Architektur der Zielumgebung:

Im Diagramm stellt Istio die in Compute Engine ausgeführte Arbeitslast bereit.

Istio installieren

1. Legen Sie in Cloud Shell das Repository-Verzeichnis als Arbeitsverzeichnis fest:

   cd "${DEPLOYMENT_DIRECTORY_PATH}"
   

2. Installieren Sie Istio:

   scripts/install-istio.sh \
   --cluster-name "${GKE_CLUSTER_NAME}" \
   --google-cloud-project "${DEFAULT_PROJECT}" \
   --cluster-region "${DEFAULT_REGION}"
   

   Das Skript install-istio.sh tut Folgendes:

   • Die Istio-Distribution wird heruntergeladen.
   • Istio wird im Zielumgebungs-GKE-Cluster installiert.
   • Es wird ein Gateway bereitgestellt, um die Dienste im Service Mesh verfügbar zu machen.
   • Istio wird konfiguriert, um die Erweiterung des Service Mesh auf die Compute Engine-Instanzen zuzulassen, die die Quellumgebung simulieren.
   • Installiert Monitoring- und Visualisierungstools für Service Mesh wie Kiali

   Wenn dieser Befehl ausgeführt wurde, zeigt die Konsole eine Bestätigung der Installation an. Die Ausgabe sieht in etwa so aus:

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

Mesh-Netzwerkerweiterung von Istio konfigurieren

In diesem Abschnitt verbinden Sie die Compute Engine-Instanz, die die Quellumgebung simuliert, mit dem Service Mesh. Das Service Mesh übernimmt das Verbinden der Mikrodienste der Legacy-Umgebung, die in die Zielumgebung migriert werden. Das Service Mesh ist in dieser Phase leer und wartet auf die Registrierung der Dienste. Es empfängt noch keinen Produktions-Traffic.

1. Legen Sie in Cloud Shell das Repository-Verzeichnis als Arbeitsverzeichnis fest:

   cd "${DEPLOYMENT_DIRECTORY_PATH}"
   

2. Installieren und konfigurieren Sie Istio auf der Compute Engine-Instanz:

   scripts/compute-engine-mesh-expansion-setup.sh \
   --default-project "${DEFAULT_PROJECT}" \
   --default-region "${DEFAULT_REGION}" \
   --default-zone "${DEFAULT_ZONE}"
   

   Das Skript compute-engine-mesh-expansion-setup.sh tut Folgendes:

   • Istio wird in den Compute Engine-Instanzen der Quellumgebung installiert.
   • Der Istio-Dienst wird auf den Compute Engine-Instanzen gestartet.

Arbeitslast freigeben

In diesem Abschnitt registrieren Sie die Arbeitslasten, die in der Compute Engine-Instanz ausgeführt werden und die die Quellumgebung simulieren, beim Istio-Service-Mesh.

Das Script workloads.sh, das Sie in diesem Abschnitt ausführen, richtet Weiterleitungsregeln ein, um den Produktions-Traffic mithilfe des Service Mesh auf die Dienste in der Legacy-Umgebung und die Dienste in der Zielumgebung aufzuteilen. Da die Traffic-Weiterleitung innerhalb des Service Mesh für Clients transparent ist, wissen diese nicht, dass sich die Weiterleitungskonfiguration geändert hat.

1. Legen Sie in Cloud Shell das Repository-Verzeichnis als Arbeitsverzeichnis fest:

   cd "${DEPLOYMENT_DIRECTORY_PATH}"
   

2. Geben Sie die Arbeitslasten frei:

   scripts/workloads.sh \
   --default-project "${DEFAULT_PROJECT}" \
   --default-region "${DEFAULT_REGION}" \
   --default-zone "${DEFAULT_ZONE}" \
   --expose-with "ISTIO_COMPUTE_ENGINE"
   

3. Das Skript workloads.sh tut Folgendes:

   • Konfiguriert das Standardprojekt, die -Region und die -Zone.
   • Aktiviert die automatische Sidecar-Injektion, um manuelle Änderungen an Ihren Bereitstellungsdeskriptoren zu vermeiden.
   • Registriert die auf der Compute Engine-Instanz ausgeführten Arbeitslasten im Mesh-Netzwerk, indem die WorkloadEntry-Endpunkte und die entsprechenden Dienste konfiguriert werden.
   • Stellt ServiceEntries bereit, um Traffic zum Compute Engine-Metadatenserver und zu Cloud APIs zu ermöglichen
   • Stellt Virtual Services bereit, um Traffic vom Istio-Gateway zur Instanz productpage weiterzuleiten, die in der Compute Engine-Instanz ausgeführt wird.

   In der Ausgabe wird eine Bestätigung der Bereitstellung angezeigt und wie Sie darauf zugreifen können. Die Ausgabe sieht in etwa so aus:

   You can access the workload by loading http://ISTIO_INGRESS_GATEWAY_EXTERNAL_IP/productpage
   

   In der Ausgabe ist ISTIO_INGRESS_GATEWAY_EXTERNAL_IP die IP-Adresse, unter der die Arbeitslast bereitgestellt wird. Notieren Sie sich die IP-Adresse. Sie benötigen sie in einem späteren Schritt.

Mesh-Erweiterung von Istio testen

In diesem Abschnitt testen Sie die Beispielarbeitslast, die auf der Compute Engine-Instanz ausgeführt wird, die Sie mit Istio verfügbar gemacht haben.

• Öffnen Sie einen Browser und rufen Sie die folgende URL auf, wobei ISTIO_INGRESS_GATEWAY_EXTERNAL_IP die IP-Adresse aus dem vorherigen Schritt ist:

  http://ISTIO_INGRESS_GATEWAY_EXTERNAL_IP/productpage
  

Der Einstiegspunkt der Quellumgebung (der eine Verbindung zur Compute Engine-Instanz herstellt) ist zu diesem Zeitpunkt noch verfügbar. Wenn Sie eine Produktionsumgebung migrieren, empfehlen wir, den Traffic schrittweise in die Zielumgebung umzuleiten, indem Sie die Konfiguration der Load-Balancing-Ebene aktualisieren.

Service Mesh visualisieren

In diesem Abschnitt verwenden Sie Kiali, um eine visuelle Darstellung des Service Mesh anzuzeigen.

1. Öffnen Sie einen Browser und rufen Sie die folgende URL auf, wobei ISTIO_INGRESS_GATEWAY_EXTERNAL_IP die IP-Adresse aus dem vorherigen Schritt ist:

   http://ISTIO_INGRESS_GATEWAY_EXTERNAL_IP/kiali/console/graph/namespaces/?edges=requestDistribution&graphType=versionedApp&namespaces=default%2Cistio-system&idleNodes=false&duration=60&refresh=15000&operationNodes=false&idleEdges=false&injectServiceNodes=true&layout=dagre
   

   Das Dienst-Dashboard von Kiali wird angezeigt.

2. Führen Sie in Cloud Shell mehrmals eine Anfrage für die Hauptseite der Beispielarbeitslast aus:

   ISTIO_INGRESS_GATEWAY_EXTERNAL_IP="$(kubectl get svc istio-ingressgateway -n istio-system -o jsonpath='{.status.loadBalancer.ingress[0].ip}')"
   
   for i in {1..10000}; do curl -s -o /dev/null -w "$(date --iso-8601=ns) - %{http_code}\n"  http://"${ISTIO_INGRESS_GATEWAY_EXTERNAL_IP}"/productpage; done
   

   Die Anfrage generiert Traffic zur Bookinfo-Anwendung. Die Ausgabe zeigt eine Liste der Zeitstempel für jede HTTP-Anfrage an den productpage-Dienst sowie den HTTP-Rückgabecode der einzelnen Anfragen (in diesem Fall 200).

   Die Ausgabe sieht in etwa so aus:

   2021-06-09T10:16:15,355323181+00:00 - 200
   2021-06-09T10:16:15,355323182+00:00 - 200
   2021-06-09T10:16:15,355323183+00:00 - 200
   [...]
   

   Die Anfrage kann etwas zeitaufwendig sein. Sie können sie einfach weiter ausführen und mit dem nächsten Schritt fortfahren.

3. Im Kiali-Dienst-Dashboard sehen Sie ein Diagramm des aktuellen Mesh-Netzwerks mit Traffic, der an Dienste weitergeleitet wird, die in Compute Engine ausgeführt werden. Der gesamte Traffic wird vom istio-ingressgateway zum productpage-Mikrodienst, der auf der Compute Engine-Instanz mit dem compute-engine-Versionslabel ausgeführt wird, sowie zum kiali-Dienst zur Visualisierung des Service Mesh weitergeleitet.

   Die anderen Dienste (details, reviews und ratings) werden nicht angezeigt, da der in Compute Engine ausgeführte Mikrodienst productpage direkt eine Verbindung zu den anderen in Compute Engine ausgeführten Mikrodiensten herstellt. Der productpage-Mikrodienst durchläuft nicht das Service Mesh.

   Wenn der gesamte Traffic über das Service Mesh geleitet werden soll, müssen Sie die in Compute Engine ausgeführten Arbeitslasten neu konfigurieren, sodass sie auf die Dienste im Service Mesh verweisen, statt direkt eine Verbindung zu ihnen herzustellen.

   Wenn das folgende Diagramm auf dem Kiali-Dashboard nicht angezeigt wird, aktualisieren Sie die Seite.

   

   Das Diagramm im Kiali-Dashboard zeigt, dass der Traffic an Dienste weitergeleitet wird, die in Compute Engine ausgeführt werden.

4. Drücken Sie in Cloud Shell Control+C, um den Befehl zum Generieren von Traffic zu beenden.

Arbeitslast migrieren

In diesem Abschnitt migrieren Sie die Komponenten der Beispielarbeitslast von der Compute Engine-Instanz in den GKE-Cluster. Gehen Sie bei jedem Mikrodienst der Beispielarbeitslast so vor:

• Stellen Sie eine Instanz des Mikrodienstes im GKE-Cluster bereit.
• Leiten Sie Traffic an die Mikrodienstinstanzen weiter, die in Compute Engine ausgeführt werden und die in GKE ausgeführt werden.

Das folgende Diagramm zeigt die Architektur des Systems für diesen Abschnitt:

Im Diagramm leitet Cloud Load Balancing den Traffic an Istio Gateway weiter und Istio leitet den Traffic dann entweder an Dienste weiter, die in Compute Engine oder in GKE ausgeführt werden.

So migrieren Sie die Komponenten der Beispielarbeitslast:

1. Legen Sie in Cloud Shell das Repository-Verzeichnis als Arbeitsverzeichnis fest:

   cd "${DEPLOYMENT_DIRECTORY_PATH}"
   

2. Arbeitslasten in der Zielumgebung bereitstellen

   scripts/workloads.sh \
   --default-project "${DEFAULT_PROJECT}" \
   --default-region "${DEFAULT_REGION}" \
   --default-zone "${DEFAULT_ZONE}" \
   --deploy-with "GKE"
   

   Das Skript workloads.sh tut Folgendes:

   • Aktiviert die automatische Sidecar-Injektion, um manuelle Änderungen an Ihren Bereitstellungsdeskriptoren zu vermeiden.
   • Stellt die ServiceAccounts und Deployments bereit, um die Beispielarbeitslasten im GKE-Cluster auszuführen.

   Sie sehen eine Bestätigung der Bereitstellung und wie Sie darauf zugreifen können. Die entsprechende Ausgabe sieht etwa so aus:

   You can access the workload by loading http://ISTIO_INGRESS_GATEWAY_EXTERNAL_IP/productpage
   

Das Service Mesh leitet den Traffic sowohl an die in den Compute Engine-Instanzen ausgeführten Beispielarbeitslasten als auch an die im GKE-Cluster ausgeführten Arbeitslasten weiter.

In Compute Engine und GKE ausgeführte Arbeitslast testen

In diesem Abschnitt testen Sie die Beispielarbeitslast, die Sie in Compute Engine und GKE bereitgestellt haben.

• Öffnen Sie einen Browser und rufen Sie die folgende URL auf, wobei ISTIO_INGRESS_GATEWAY_EXTERNAL_IP die IP-Adresse aus dem vorherigen Schritt ist:

  http://ISTIO_INGRESS_GATEWAY_EXTERNAL_IP/productpage
  

  Es wird eine Bookinfo-Seite mit Informationen zu Büchern und relevanten Bewertungen angezeigt.

Da Sie dieselbe Version der Beispielarbeitslast in Compute Engine und dem GKE-Cluster bereitgestellt haben, entspricht die Ausgabe dem vorherigen Test.

Service Mesh visualisieren

In diesem Abschnitt verwenden Sie Kiali, um eine visuelle Darstellung des Service Mesh anzuzeigen.

1. Öffnen Sie einen Browser und rufen Sie die folgende URL auf, wobei ISTIO_INGRESS_GATEWAY_EXTERNAL_IP die IP-Adresse aus dem vorherigen Schritt ist:

   http://ISTIO_INGRESS_GATEWAY_EXTERNAL_IP/kiali/console/graph/namespaces/?edges=requestDistribution&graphType=versionedApp&namespaces=default%2Cistio-system&idleNodes=false&duration=60&refresh=15000&operationNodes=false&idleEdges=false&injectServiceNodes=true&layout=dagre
   

2. Führen Sie in Cloud Shell mehrmals eine Anfrage für die Hauptseite der Beispielarbeitslast aus:

   ISTIO_INGRESS_GATEWAY_EXTERNAL_IP="$(kubectl get svc istio-ingressgateway -n istio-system -o jsonpath='{.status.loadBalancer.ingress[0].ip}')"
   for i in {1..10000}; do curl -s -o /dev/null -w "$(date --iso-8601=ns) - %{http_code}\n"  http://"${ISTIO_INGRESS_GATEWAY_EXTERNAL_IP}"/productpage; done
   

   Der Befehl generiert Traffic zur Bookinfo-Anwendung. Die erwartete Ausgabe ist eine Liste des Datums der HTTP-Anfragen an den Dienst productpage und des HTTP-Rückgabecodes der einzelnen Anfragen (in diesem Fall 200 OK). Die Ausgabe sieht etwa so aus:

   2021-06-09T10:16:15,355323181+00:00 - 200
   2021-06-09T10:16:15,355323182+00:00 - 200
   2021-06-09T10:16:15,355323183+00:00 - 200
   [...]
   

3. Im Kiali-Dienst-Dashboard sehen Sie ein Diagramm des aktuellen Mesh-Netzwerks mit Traffic, der an Dienste weitergeleitet wird, die in Compute Engine und GKE ausgeführt werden.

   Jede Instanz eines Mikrodienstes hat ein Label, um seine Überarbeitung zu erklären:

   • Instanzen, die in Compute Engine ausgeführt werden, haben das Label compute-engine.
   • Instanzen, die in GKE ausgeführt werden, haben einen zusätzlichen String, z. B. v1 oder v3.

   Instanzen, die in Compute Engine ausgeführt werden, sind direkt mit den anderen Instanzen in Compute Engine verbunden, ohne das Service Mesh zu durchlaufen. Daher können Sie den Traffic von den in Compute Engine ausgeführten Instanzen zu anderen Instanzen nicht sehen.

   Wenn das folgende Diagramm auf dem Kiali-Dashboard nicht angezeigt wird, aktualisieren Sie die Seite.

   

   Das Diagramm im Kiali-Dashboard zeigt den Traffic, der an Dienste weitergeleitet wird, die in Compute Engine und in GKE ausgeführt werden.

4. Drücken Sie in Cloud Shell Control+C, um den Befehl zum Generieren von Traffic zu beenden.

Traffic nur an GKE-Cluster weiterleiten

In diesem Abschnitt leiten Sie Traffic an die Arbeitslast-Dienstinstanzen weiter, die nur im GKE-Cluster ausgeführt werden. Für jeden Dienst der Beispielarbeitslast löschen Sie die WorkloadEntry-Referenz, die auf den Dienst verweist, der in Compute Engine ausgeführt wird. Dadurch werden vom Dienst nur die Mikrodienstinstanzen ausgewählt, die im GKE-Cluster ausgeführt werden. Der Traffic wird nur an den GKE-Cluster weitergeleitet. Das folgende Diagramm zeigt die Architektur des Systems für diesen Abschnitt:

1. Legen Sie in Cloud Shell das Repository-Verzeichnis als Arbeitsverzeichnis fest:

   cd "${DEPLOYMENT_DIRECTORY_PATH}"
   

2. Machen Sie die Arbeitslasten nur in der Zielumgebung verfügbar:

   scripts/workloads.sh \
   --default-project "${DEFAULT_PROJECT}" \
   --default-region "${DEFAULT_REGION}" \
   --default-zone "${DEFAULT_ZONE}" \
   --expose-with "GKE_ONLY"
   

   Das Script workloads.sh löscht die WorkloadEntry-Referenzen, die auf die in Compute Engine ausgeführten Mikrodienstinstanzen verweisen, aus dem GKE-Cluster.

   Sie sehen eine Bestätigung der Bereitstellung und wie Sie darauf zugreifen können. Die entsprechende Ausgabe sieht etwa so aus:

   You can access the workload by loading http://ISTIO_INGRESS_GATEWAY_EXTERNAL_IP/productpage
   

Der Diensteintrag verwendet workloadSelector, um automatisch die Beispielarbeitslast auszuwählen, die im GKE-Cluster ausgeführt wird.

In GKE ausgeführte Arbeitslast testen

• Öffnen Sie einen Browser und rufen Sie die folgende URL auf, wobei ISTIO_INGRESS_GATEWAY_EXTERNAL_IP die IP-Adresse aus dem vorherigen Schritt ist:

  http://ISTIO_INGRESS_GATEWAY_EXTERNAL_IP/productpage
  

  Es wird eine Bookinfo-Seite mit Informationen zu Büchern und relevanten Bewertungen angezeigt.

Service Mesh visualisieren

In diesem Abschnitt verwenden Sie Kiali, um eine visuelle Darstellung des Service Mesh anzuzeigen.

1. Öffnen Sie einen Browser und rufen Sie die folgende URL auf, wobei ISTIO_INGRESS_GATEWAY_EXTERNAL_IP die IP-Adresse aus dem vorherigen Schritt ist:

   http://ISTIO_INGRESS_GATEWAY_EXTERNAL_IP/kiali/console/graph/namespaces/?edges=requestDistribution&graphType=versionedApp&namespaces=default%2Cistio-system&idleNodes=false&duration=60&refresh=15000&operationNodes=false&idleEdges=false&injectServiceNodes=true&layout=dagre
   

2. Führen Sie in Cloud Shell mehrmals eine Anfrage für die Hauptseite der Beispielarbeitslast aus:

   ISTIO_INGRESS_GATEWAY_EXTERNAL_IP="$(kubectl get svc istio-ingressgateway -n istio-system -o jsonpath='{.status.loadBalancer.ingress[0].ip}')"
   for i in {1..10000}; do curl -s -o /dev/null -w "$(date --iso-8601=ns) - %{http_code}\n"  http://"${ISTIO_INGRESS_GATEWAY_EXTERNAL_IP}"/productpage; done
   

   Dieser Befehl generiert Traffic zur Bookinfo-Anwendung. Die erwartete Ausgabe ist eine Liste des Datums der HTTP-Anfragen an den Dienst productpage und des HTTP-Rückgabecodes der einzelnen Anfragen (in diesem Fall 200 OK). Die Ausgabe sieht etwa so aus:

   2021-06-09T10:16:15,355323181+00:00 - 200
   2021-06-09T10:16:15,355323182+00:00 - 200
   2021-06-09T10:16:15,355323183+00:00 - 200
   [...]
   

3. Das Kiali-Dienst-Dashboard zeigt ein Diagramm des aktuellen Mesh-Netzwerks mit Traffic an Dienste, die in GKE ausgeführt werden. Sie haben zwei Instanzen jedes Mikrodienstes bereitgestellt: Eine wird auf der Compute Engine-Instanz und die andere im GKE-Cluster ausgeführt. Da Sie jedoch die WorkloadEntry-Referenzen entfernt haben, die auf die in Compute Engine ausgeführten Mikrodienstinstanzen verweisen, wählen die Dienste nur die Mikrodienstinstanzen aus, die im GKE-Cluster ausgeführt werden.

   Wenn das folgende Diagramm nicht im Kiali-Dashboard angezeigt wird, aktualisieren Sie die Seite:

   

   Das Diagramm im Kiali-Dashboard zeigt den Traffic, der an Dienste weitergeleitet wird, die in GKE ausgeführt werden.

4. Drücken Sie in Cloud Shell Control+C, um den Befehl zum Generieren von Traffic zu beenden.

Quellumgebung deaktivieren

Da der gesamte Traffic jetzt an den GKE-Cluster weitergeleitet wird, können Sie die Instanzen der Arbeitslast beenden, die in Compute Engine ausgeführt werden.

Halten Sie während einer Produktionsmigration das Quellrechenzentrum für Ihre Rollback-Strategie bereit. Es wird empfohlen, das Quellrechenzentrum erst dann außer Betrieb zu nehmen, wenn Sie sich sicher sind, dass die neue Lösung wie erwartet funktioniert und alle Sicherungs- und Fehlertoleranzmechanismen verfügbar sind.

Das folgende Diagramm zeigt die Architektur des Systems für diesen Abschnitt:

Im Diagramm leitet Istio den Traffic nur an Dienste weiter, die in GKE ausgeführt werden, und die in Compute Engine ausgeführten Arbeitslasten werden deaktiviert.

So deaktivieren Sie die Quellumgebung:

1. Legen Sie in Cloud Shell das Repository-Verzeichnis als Arbeitsverzeichnis fest:

   cd "${DEPLOYMENT_DIRECTORY_PATH}"
   

2. Machen Sie die Arbeitslasten nur in der Zielumgebung verfügbar:

   scripts/workloads.sh \
   --default-project "${DEFAULT_PROJECT}" \
   --default-region "${DEFAULT_REGION}" \
   --default-zone "${DEFAULT_ZONE}" \
   --deploy-with "GKE_ONLY"
   

   Das Script workloads.sh stoppt die Container, die auf den Compute Engine-Instanzen ausgeführt werden.

Bereinigen

Damit Ihrem Google Cloud-Konto die in dieser Bereitstellung verwendeten Ressourcen nicht in Rechnung gestellt werden, löschen Sie entweder das Projekt, das die Ressourcen enthält, oder behalten Sie das Projekt bei und löschen Sie die einzelnen Ressourcen.

Projekt löschen

Achtung: Das Löschen von Projekten hat folgende Auswirkungen:

• Alle Inhalte des Projekts werden gelöscht. Wenn Sie für die Aufgaben in diesem Dokument ein bereits bestehendes Projekt verwendet haben und dieses löschen, werden auch alle anderen im Rahmen des Projekts erstellten Daten gelöscht.
• Benutzerdefinierte Projekt-IDs gehen verloren. Beim Erstellen dieses Projekts haben Sie möglicherweise eine benutzerdefinierte Projekt-ID erstellt, die Sie weiterhin verwenden möchten. Damit die URLs, die die Projekt-ID nutzen, z. B. eine appspot.com-URL, erhalten bleiben, sollten Sie ausgewählte Ressourcen innerhalb des Projekts löschen, statt das gesamte Projekt.

Wenn Sie mehrere Architekturen, Anleitungen und Kurzanleitungen durcharbeiten möchten, können Sie die Überschreitung von Projektkontingenten verhindern, indem Sie Projekte wiederverwenden.

1. Wechseln Sie in der Google Cloud Console zur Seite Ressourcen verwalten.

   Zur Seite „Ressourcen verwalten“

2. Wählen Sie in der Projektliste das Projekt aus, das Sie löschen möchten, und klicken Sie dann auf Löschen.
3. Geben Sie im Dialogfeld die Projekt-ID ein und klicken Sie auf Shut down (Beenden), um das Projekt zu löschen.

Einzelne Ressourcen löschen

1. Legen Sie in Cloud Shell das Repository-Verzeichnis als Arbeitsverzeichnis fest:

   cd "${DEPLOYMENT_DIRECTORY_PATH}"/terraform
   

2. Löschen Sie die von Ihnen bereitgestellten Ressourcen:

   terraform destroy -auto-approve
   

Nächste Schritte

• Informationen über GKE
• Mehr über Istio erfahren
• Weitere Referenzarchitekturen, Diagramme und Best Practices finden Sie im Cloud-Architekturcenter.