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 Mikrodienstedetails
,ratings
undreviews
auf, um die Informationsseite zum Buch zu füllendetails
: Liefert Informationen zu Büchernreviews
: Enthält Buchrezensionenratings
: 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:
Mit dem Preisrechner können Sie eine Kostenschätzung für Ihre voraussichtliche Nutzung vornehmen.
Umgebung vorbereiten
Die meisten Schritte in dieser Bereitstellung werden in Cloud Shell ausgeführt.
-
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 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.
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.
Wechseln Sie vom Arbeitsverzeichnis in das Verzeichnis
${HOME}
:cd "${HOME}"
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
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.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.
Legen Sie in Cloud Shell das Repository-Verzeichnis als Arbeitsverzeichnis fest:
cd "${DEPLOYMENT_DIRECTORY_PATH}"
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.
Wechseln Sie vom Arbeitsverzeichnis in das Verzeichnis
terraform
:cd "${DEPLOYMENT_DIRECTORY_PATH}"/terraform
Wenden Sie die Änderungen mit Terraform an:
terraform apply
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.
- Monitoring-Betrachter (
- 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.
Legen Sie in Cloud Shell das Repository-Verzeichnis als Arbeitsverzeichnis fest:
cd "${DEPLOYMENT_DIRECTORY_PATH}"
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
Legen Sie in Cloud Shell das Repository-Verzeichnis als Arbeitsverzeichnis fest:
cd "${DEPLOYMENT_DIRECTORY_PATH}"
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.
Legen Sie in Cloud Shell das Repository-Verzeichnis als Arbeitsverzeichnis fest:
cd "${DEPLOYMENT_DIRECTORY_PATH}"
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.
Legen Sie in Cloud Shell das Repository-Verzeichnis als Arbeitsverzeichnis fest:
cd "${DEPLOYMENT_DIRECTORY_PATH}"
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"
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.
Ö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.
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 Fall200
).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.
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
zumproductpage
-Mikrodienst, der auf der Compute Engine-Instanz mit demcompute-engine
-Versionslabel ausgeführt wird, sowie zumkiali
-Dienst zur Visualisierung des Service Mesh weitergeleitet.Die anderen Dienste (
details
,reviews
undratings
) werden nicht angezeigt, da der in Compute Engine ausgeführte Mikrodienstproductpage
direkt eine Verbindung zu den anderen in Compute Engine ausgeführten Mikrodiensten herstellt. Derproductpage
-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.
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:
Legen Sie in Cloud Shell das Repository-Verzeichnis als Arbeitsverzeichnis fest:
cd "${DEPLOYMENT_DIRECTORY_PATH}"
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.
Ö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
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 Fall200 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 [...]
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
oderv3
.
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.
- Instanzen, die in Compute Engine ausgeführt werden, haben das Label
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:
Legen Sie in Cloud Shell das Repository-Verzeichnis als Arbeitsverzeichnis fest:
cd "${DEPLOYMENT_DIRECTORY_PATH}"
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 dieWorkloadEntry
-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.
Ö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
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 Fall200 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 [...]
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.
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:
Legen Sie in Cloud Shell das Repository-Verzeichnis als Arbeitsverzeichnis fest:
cd "${DEPLOYMENT_DIRECTORY_PATH}"
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
- Wechseln Sie in der Google Cloud Console zur Seite Ressourcen verwalten.
- Wählen Sie in der Projektliste das Projekt aus, das Sie löschen möchten, und klicken Sie dann auf Löschen.
- 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
Legen Sie in Cloud Shell das Repository-Verzeichnis als Arbeitsverzeichnis fest:
cd "${DEPLOYMENT_DIRECTORY_PATH}"/terraform
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.