Cloud Spanner mit GKE Autopilot verbinden

1. Einführung

Cloud Spanner ist ein vollständig verwalteter, horizontal skalierbarer, global verteilter relationaler Datenbankdienst, der ACID-Transaktionen und SQL-Semantik bietet, ohne auf Leistung und Hochverfügbarkeit zu verzichten.

GKE Autopilot ist ein Betriebsmodus in GKE, in dem Google Ihre Clusterkonfiguration verwaltet, einschließlich der Knoten, Skalierung, Sicherheit und anderer vorkonfigurierter Einstellungen gemäß Best Practices. GKE Autopilot aktiviert beispielsweise Workload Identity, um Dienstberechtigungen zu verwalten.

In diesem Lab erfahren Sie, wie Sie mehrere Back-End-Dienste, die in GKE Autopilot ausgeführt werden, mit einer Cloud Spanner-Datenbank verbinden.

In diesem Lab richten Sie zuerst ein Projekt ein und starten Cloud Shell. Anschließend stellen Sie die Infrastruktur mithilfe von Terraform bereit.

Anschließend interagieren Sie mit Cloud Build und Cloud Deploy, um eine erste Schemamigration für die Games-Datenbank durchzuführen, die Back-End-Dienste und dann die Arbeitslasten bereitzustellen.

Die Dienste in diesem Codelab sind mit denen im Codelab Cloud Spanner – Erste Schritte bei der Spieleentwicklung identisch. Dieses Codelab ist nicht zwingend erforderlich, um die Dienste in GKE auszuführen und eine Verbindung zu Spanner herzustellen. Wenn Sie jedoch mehr über die Besonderheiten der Dienste erfahren möchten, die auf Spanner funktionieren, lesen Sie sie.

Wenn die Arbeitslasten und Back-End-Dienste ausgeführt werden, können Sie mit der Lastgenerierung beginnen und beobachten, wie die Dienste zusammenwirken.

Zum Schluss bereinigen Sie die in diesem Lab erstellten Ressourcen.

Aufgaben

Aufgaben in diesem Lab:

• Infrastruktur mit Terraform bereitstellen
• Datenbankschema mithilfe einer Schemamigration in Cloud Build erstellen
• Die vier Golang-Back-End-Dienste bereitstellen, die Workload Identity für die Verbindung mit Cloud Spanner nutzen
• Stellen Sie die vier Arbeitslastdienste bereit, mit denen die Last für die Back-End-Dienste simuliert wird.

Lerninhalte

• GKE Autopilot-, Cloud Spanner- und Cloud Deploy-Pipelines mit Terraform bereitstellen
• Wie Workload Identity Diensten in GKE ermöglicht, die Identität von Dienstkonten zu übernehmen, um auf die IAM-Berechtigungen für die Arbeit mit Cloud Spanner zuzugreifen
• Mit Locust.io produktionsähnliche Last in GKE und Cloud Spanner generieren

Voraussetzungen

• Ein Google Cloud-Projekt, das mit einem Rechnungskonto verbunden ist.
• Ein Webbrowser wie Chrome oder Firefox

2. Einrichtung und Anforderungen

Projekt erstellen

Warnung:In diesem Codelab werden Änderungen an Ihrem Projekt vorgenommen. Es wird dringend empfohlen, ein eigenes Projekt für dieses Codelab einzurichten.

Wenn Sie noch kein Google-Konto (Gmail oder Google Apps) haben, müssen Sie eines erstellen. Melden Sie sich in der Google Cloud Platform Console ( console.cloud.google.com) an und erstellen Sie ein neues Projekt.

Wenn Sie bereits ein Projekt haben, klicken Sie auf das Drop-down-Menü für die Projektauswahl oben links in der Konsole:

und klicken Sie auf NEUES PROJEKT. Schaltfläche zum Erstellen eines neuen Projekts:

Wenn Sie noch kein Projekt haben, sollten Sie ein Dialogfeld wie dieses sehen, um Ihr erstes zu erstellen:

Im nachfolgenden Dialog zur Projekterstellung können Sie die Details Ihres neuen Projekts eingeben:

Denken Sie an die Projekt-ID. Dies ist ein eindeutiger Name für alle Google Cloud-Projekte. Der oben angegebene Name ist bereits vergeben und funktioniert leider nicht für Sie. Sie wird in diesem Codelab später als PROJECT_ID bezeichnet.

Falls noch nicht geschehen, müssen Sie als Nächstes in der Developers Console die Abrechnung aktivieren, um Google Cloud-Ressourcen nutzen und die Cloud Spanner API aktivieren zu können.

Dieses Codelab sollte nicht mehr als ein paar Euro kosten. Wenn Sie sich jedoch dazu entschließen, mehr Ressourcen zu verwenden oder diese weiter auszuführen (siehe Abschnitt „Bereinigen“ am Ende dieses Dokuments), Die Preise für Google Cloud Spanner sind hier aufgeführt, die Preise für GKE Autopilot sind hier aufgeführt.

Neue Google Cloud Platform-Nutzer haben Anspruch auf eine kostenlose Testversion mit 300$Guthaben, wodurch das Codelab in der Regel kostenlos sein sollte.

Cloud Shell-Einrichtung

Sie können Google Cloud und Spanner über Ihren Laptop aus der Ferne bedienen. In diesem Codelab verwenden wir jedoch Google Cloud Shell, eine Befehlszeilenumgebung, die in der Cloud ausgeführt wird.

Diese Debian-basierte virtuelle Maschine verfügt über alle erforderlichen Entwicklungstools. Es bietet ein Basisverzeichnis mit 5 GB nichtflüchtigem Speicher und wird in Google Cloud ausgeführt. Dadurch werden die Netzwerkleistung und die Authentifizierung erheblich verbessert. Für dieses Codelab benötigen Sie also nur einen Browser – ja, er funktioniert auf Chromebooks.

1. Klicken Sie einfach auf „Cloud Shell aktivieren“ , um Cloud Shell über die Cloud Console zu aktivieren. Es dauert nur einen Moment, bis die Umgebung bereitgestellt und eine Verbindung hergestellt werden kann.

Sobald Sie mit Cloud Shell verbunden sind, sollten Sie sehen, dass Sie bereits authentifiziert sind und dass das Projekt bereits auf Ihre PROJECT_ID eingestellt ist.

gcloud auth list

Befehlsausgabe

Credentialed accounts:
 - <myaccount>@<mydomain>.com (active)

Hinweis:Das gcloud-Befehlszeilentool ist in Cloud Shell vorinstalliert. Weitere Informationen finden Sie in der Übersicht zum gcloud-Befehlszeilentool.

gcloud config list project

Befehlsausgabe

[core]
project = <PROJECT_ID>

Sollte das Projekt aus irgendeinem Grund nicht eingerichtet sein, geben Sie einfach den folgenden Befehl ein:

gcloud config set project <PROJECT_ID>

Du suchst dein Gerät (PROJECT_ID)? Sehen Sie nach, welche ID Sie bei den Einrichtungsschritten verwendet haben, oder rufen Sie sie im Dashboard der Cloud Console auf:

Cloud Shell legt außerdem standardmäßig einige Umgebungsvariablen fest, die bei der Ausführung zukünftiger Befehle nützlich sein können.

echo $GOOGLE_CLOUD_PROJECT

Befehlsausgabe

<PROJECT_ID>

Hinweis:Wenn Sie gcloud auf Ihrem eigenen Computer ausführen, wurden die Konfigurationseinstellungen sitzungsübergreifend beibehalten. In Cloud Shell müssen Sie dies jedoch für jede neue Sitzung oder erneute Verbindung festlegen.

Code herunterladen

Sie können den Code für dieses Lab in Cloud Shell herunterladen:

git clone https://github.com/cloudspannerecosystem/spanner-gaming-sample.git

Befehlsausgabe

Cloning into 'spanner-gaming-sample'...
*snip*

Dieses Codelab basiert auf der Version v0.1.3 – sehen Sie sich das folgende Tag an:

cd spanner-gaming-sample
git fetch --all --tags

# Check out v0.1.3 release
git checkout tags/v0.1.3 -b v0.1.3-branch

Befehlsausgabe

Switched to a new branch 'v0.1.3-branch'

Legen Sie nun das aktuelle Arbeitsverzeichnis als Umgebungsvariable DEMO_HOME fest. Dies erleichtert die Navigation, während Sie die verschiedenen Teile des Codelabs durcharbeiten.

export DEMO_HOME=$(pwd)

Zusammenfassung

In diesem Schritt haben Sie ein neues Projekt eingerichtet, Cloud Shell aktiviert und den Code für dieses Lab heruntergeladen.

Nächstes Video

Als Nächstes stellen Sie die Infrastruktur mit Terraform bereit.

3. Infrastruktur bereitstellen

Übersicht

Wenn Ihr Projekt fertig ist, ist es an der Zeit, die Infrastruktur in Betrieb zu nehmen. Dazu gehören VPC-Netzwerke, Cloud Spanner, GKE Autopilot, Artifact Registry zum Speichern der in GKE ausgeführten Images, die Cloud Deploy-Pipelines für die Back-End-Dienste und -Arbeitslasten sowie die Dienstkonten und IAM-Berechtigungen, um diese Dienste verwenden zu können.

Das ist eine Menge. Zum Glück kann Terraform die Einrichtung vereinfachen. Terraform ist eine „Infrastruktur als Code“, mit dem wir angeben können, was wir für dieses Projekt benötigen. -Dateien. Dies vereinfacht die Bereitstellung von Infrastruktur.

Für dieses Codelab müssen Sie nicht mit Terraform vertraut sein. Wenn Sie wissen möchten, was die nächsten Schritte bewirken, können Sie sich ansehen, was in diesen Dateien im Verzeichnis Infrastructure (Infrastruktur) alles erstellt wird:

• vpc.tf
• backend_gke.tf
• spanner.tf
• artifact_registry.tf
• pipelines.tf
• iam.tf

Terraform konfigurieren

Wechseln Sie in Cloud Shell zum Verzeichnis infrastructure und initialisieren Sie Terraform:

cd $DEMO_HOME/infrastructure
terraform init

Befehlsausgabe

Initializing the backend...

Initializing provider plugins...
*snip*
Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

Konfigurieren Sie als Nächstes Terraform, indem Sie terraform.tfvars.sample kopieren und den Projektwert ändern. Die anderen Variablen können ebenfalls geändert werden, aber nur das Projekt muss geändert werden, damit es mit Ihrer Umgebung funktioniert.

cp  terraform.tfvars.sample terraform.tfvars
# edit gcp_project using the project environment variable
sed -i "s/PROJECT/$GOOGLE_CLOUD_PROJECT/" terraform.tfvars

Hinweis:Mit den Standardvariablen wird die Infrastruktur in der Region us-central1 bereitgestellt.

Infrastruktur bereitstellen

Warnung: Durch diesen Schritt werden Änderungen an Ihrem Projekt vorgenommen. Wenn Sie ein bereits bestehendes Projekt verwenden, kann dies unbeabsichtigte Folgen haben. Es wird dringend empfohlen, ein eigenes Projekt für dieses Codelab einzurichten.

Jetzt ist es an der Zeit, die Infrastruktur bereitzustellen.

terraform apply
# review the list of things to be created
# type 'yes' when asked

Befehlsausgabe

Plan: 46 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

google_project_service.project["container.googleapis.com"]: Creating...
*snip*
Apply complete! Resources: 46 added, 0 changed, 0 destroyed.

Hinweis:Die vollständige Einrichtung der Infrastruktur dauert einige Minuten.

Hinweis: Möglicherweise werden Sie darauf hingewiesen, dass Kubernetes default_secret_name verworfen wird. Dies kann ignoriert werden.

Prüfen, was erstellt wurde

Wenn Sie wissen möchten, was erstellt wurde, sehen Sie sich die Produkte in der Cloud Console an.

Hinweis: Die folgenden Ressourcen werden möglicherweise erst angezeigt, wenn der Schritt terraform apply abgeschlossen ist.

Cloud Spanner

Prüfen Sie zuerst Cloud Spanner, indem Sie im Dreistrich-Menü auf Spanner klicken. Möglicherweise müssen Sie auf „Weitere Produkte anzeigen“ klicken um sie in der Liste zu finden.

Dadurch gelangen Sie zur Liste der Spanner-Instanzen. Klicken Sie auf die Instanz, um die Datenbanken zu sehen. Die Ausgabe sollte ungefähr so aussehen:

Hinweis:Sie sehen, dass es sich um eine detaillierte Instanz handelt, die auf 100 Verarbeitungseinheiten (100 Verarbeitungseinheiten) mit der regionalen Konfiguration „us-central“ ausgeführt wird.

GKE Autopilot

Als Nächstes sehen Sie sich GKE an. Klicken Sie dazu im Dreistrich-Menü auf Kubernetes Engine => Clusters. Hier sehen Sie den Cluster sample-games-gke, der im Autopilot-Modus ausgeführt wird.

Hinweis: Beachten Sie, dass sich der GKE-Cluster auch in der Region us-central befindet. Es ist wichtig, dass sich Anwendungen in der Nähe der Datenbank befinden, um die Latenz von Anfragen zu reduzieren.

Artifact Registry

Jetzt möchten Sie wissen, wo die Bilder gespeichert werden. Klicken Sie also auf das Dreistrich-Menü und suchen Sie Artifact Registry=>Repositories. Artifact Registry befindet sich im Abschnitt „CI/CD“ des Menüs.

Hier wird eine Docker-Registry mit dem Namen spanner-game-images angezeigt. Dieses Feld ist vorerst leer.

Cloud Deploy

In Cloud Deploy werden die Pipelines erstellt, damit Cloud Build Schritte zum Erstellen der Images und zum Bereitstellen der Images im GKE-Cluster bereitstellen kann.

Gehen Sie zum Dreistrich-Menü und suchen Sie nach Cloud Deploy, das sich ebenfalls im Abschnitt „CI/CD“ des Menüs befindet.

Hier sehen Sie zwei Pipelines: eine für Back-End-Dienste und eine für Arbeitslasten. Beide stellen die Images im selben GKE-Cluster bereit, was aber eine Trennung unserer Bereitstellungen ermöglicht.

IAM

Rufen Sie schließlich in der Cloud Console die Seite „IAM“ auf, um die erstellten Dienstkonten zu prüfen. Gehen Sie zum Dreistrich-Menü und suchen Sie nach IAM and Admin=>Service accounts. Die Ausgabe sollte ungefähr so aussehen:

Insgesamt gibt es sechs Dienstkonten, die von Terraform erstellt werden:

• Das Standarddienstkonto für den Computer. Er wird in diesem Codelab nicht verwendet.
• Das Konto „cloudbuild-cicd“ wird für die Schritte von Cloud Build und Cloud Deploy verwendet.
• Vier „App“ Konten, die von unseren Back-End-Diensten für die Interaktion mit Cloud Spanner verwendet werden.

Als Nächstes konfigurieren Sie kubectl für die Interaktion mit dem GKE-Cluster.

kubectl konfigurieren

# Name of GKE cluster from terraform.tfvars file
export GKE_CLUSTER=sample-game-gke 

# get GKE credentials
gcloud container clusters get-credentials $GKE_CLUSTER --region us-central1

# Check that no errors occur
kubectl get serviceaccounts

Befehlsausgabe

#export GKE_CLUSTER=sample-game-gke

# gcloud container clusters get-credentials $GKE_CLUSTER --region us-central1
Fetching cluster endpoint and auth data.
kubeconfig entry generated for sample-game-gke.

# kubectl get serviceaccounts
NAME              SECRETS   AGE
default           0         37m
item-app          0         35m
matchmaking-app   0         35m
profile-app       0         35m
tradepost-app     0         35m

Hinweis:Wichtig ist, dass kubectl keine Authentifizierungsfehler ausgeben sollte.

Zusammenfassung

Sehr gut! Sie konnten eine Cloud Spanner-Instanz, einen GKE Autopilot-Cluster, in einer VPC für ein privates Netzwerk bereitstellen.

Außerdem wurden zwei Cloud Deploy-Pipelines für die Back-End-Dienste und die Arbeitslasten sowie ein Artifact Registry-Repository zum Speichern der erstellten Images erstellt.

Und schließlich wurden die Dienstkonten für die Arbeit mit Workload Identity erstellt und konfiguriert, damit die Back-End-Dienste Cloud Spanner verwenden können.

Außerdem haben Sie kubectl für die Interaktion mit dem GKE-Cluster in Cloud Shell konfiguriert, nachdem Sie die Back-End-Dienste und -Arbeitslasten bereitgestellt haben.

Nächstes Video

Bevor Sie die Dienste verwenden können, muss das Datenbankschema definiert werden. Dies richten Sie als Nächstes ein.

4. Datenbankschema erstellen

Übersicht

Bevor Sie die Back-End-Dienste ausführen können, müssen Sie sicherstellen, dass das Datenbankschema vorhanden ist.

Wenn Sie sich die Dateien im Verzeichnis $DEMO_HOME/schema/migrations aus dem Demo-Repository ansehen, finden Sie eine Reihe von .sql-Dateien, die unser Schema definieren. Dies ahmt einen Entwicklungszyklus nach, in dem Schemaänderungen im Repository selbst verfolgt werden und an bestimmte Funktionen der Anwendungen gebunden werden können.

In dieser Beispielumgebung wendet Schraubenschlüssel die Schemamigrationen mit Cloud Build an.

Cloud Build

In der Datei $DEMO_HOME/schema/cloudbuild.yaml sind die erforderlichen Schritte beschrieben:

serviceAccount: projects/${PROJECT_ID}/serviceAccounts/cloudbuild-cicd@${PROJECT_ID}.iam.gserviceaccount.com
steps:
- name: gcr.io/cloud-builders/curl
 id: fetch-wrench
 args: ['-Lo', '/workspace/wrench.tar.gz', 'https://github.com/cloudspannerecosystem/wrench/releases/download/v1.4.1/wrench-1.4.1-linux-amd64.tar.gz' ]

- name: gcr.io/cloud-builders/gcloud
 id: migrate-spanner-schema
 entrypoint: sh
 args:
 - '-xe'
 - '-c'
 - |
   tar -xzvf wrench.tar.gz

   chmod +x /workspace/wrench

   # Assumes only a single spanner instance and database. Fine for this demo in a dedicated project
   export SPANNER_PROJECT_ID=${PROJECT_ID}
   export SPANNER_INSTANCE_ID=$(gcloud spanner instances list | tail -n1 | awk '{print $1}')
   export SPANNER_DATABASE_ID=$(gcloud spanner databases list --instance=$$SPANNER_INSTANCE_ID | tail -n1 | awk '{print $1}')

   if [ -d ./migrations ]; then
     /workspace/wrench migrate up --directory .
   else
     echo "[Error] Missing migrations directory"
   fi
timeout: 600s

Grundsätzlich gibt es zwei Schritte:

• Schraubenschlüssel in den Cloud Build-Arbeitsbereich herunterladen
• Schraubenschlüssel-Migration ausführen

Damit Schraubenschlüssel eine Verbindung zum Schreibendpunkt herstellen kann, werden die Umgebungsvariablen des Spanner-Projekts, der Instanz und der Datenbank benötigt.

Cloud Build kann diese Änderungen vornehmen, da es als cloudbuild-cicd@${PROJECT_ID}.iam.gserviceaccount.com-Dienstkonto ausgeführt wird:

serviceAccount: projects/${PROJECT_ID}/serviceAccounts/cloudbuild-cicd@${PROJECT_ID}.iam.gserviceaccount.com

Dieses Dienstkonto hat die von Terraform hinzugefügte spanner.databaseUser-Rolle, die es dem Dienstkonto ermöglicht, DDL zu aktualisieren.

Schemamigrationen

Basierend auf den Dateien im Verzeichnis $DEMO_HOME/schema/migrations werden fünf Migrationsschritte ausgeführt. Hier sehen Sie ein Beispiel für die Datei 000001.sql, mit der eine Tabelle und Indexe players erstellt werden:

CREATE TABLE players (
   playerUUID STRING(36) NOT NULL,
   player_name STRING(64) NOT NULL,
   email STRING(MAX) NOT NULL,
   password_hash BYTES(60) NOT NULL,
   created TIMESTAMP,
   updated TIMESTAMP,
   stats JSON,
   account_balance NUMERIC NOT NULL DEFAULT (0.00),
   is_logged_in BOOL,
   last_login TIMESTAMP,
   valid_email BOOL,
   current_game STRING(36)
) PRIMARY KEY (playerUUID);

CREATE UNIQUE INDEX PlayerAuthentication ON players(email) STORING(password_hash);
CREATE UNIQUE INDEX PlayerName ON players(player_name);
CREATE INDEX PlayerGame ON players(current_game);

Schemamigration senden

Wechseln Sie zum Verzeichnis schema und führen Sie den folgenden gcloud-Befehl aus, um den Build für die Schemamigration zu senden:

cd $DEMO_HOME/schema
gcloud builds submit --config=cloudbuild.yaml

Befehlsausgabe

Creating temporary tarball archive of 8 file(s) totalling 11.2 KiB before compression.
Uploading tarball of [.] to [gs://(project)_cloudbuild/source/(snip).tgz]
Created [https://cloudbuild.googleapis.com/v1/projects/(project)/locations/global/builds/7defe982-(snip)].
Logs are available at [ https://console.cloud.google.com/cloud-build/builds/7defe982-(snip)?project=(snip) ].

gcloud builds submit only displays logs from Cloud Storage. To view logs from Cloud Logging, run:
gcloud beta builds submit

ID: 7defe982-(snip)
CREATE_TIME: (created time)
DURATION: 3M11S
SOURCE: gs://(project)_cloudbuild/source/(snip).tgz
IMAGES: -
STATUS: SUCCESS

Hinweis:Das Bereitstellen der Schemamigration kann einige Minuten dauern.

In der obigen Ausgabe finden Sie einen Link zum Cloud-Build-Prozess Created. Wenn Sie darauf klicken, gelangen Sie zum Build in der Cloud Console, sodass Sie den Fortschritt des Builds überwachen und sehen können, was er gerade tut.

Hinweis: Die Schritte für die Migration entsprechen der Anzahl der Dateien im Verzeichnis $DEMO_HOME/schema/migrations.

Zusammenfassung

In diesem Schritt haben Sie mit Cloud Build die erste Schemamigration gesendet, bei der fünf verschiedene DDL-Vorgänge angewendet wurden. Diese Vorgänge stellen dar, wann Features hinzugefügt wurden, für die Änderungen am Datenbankschema erforderlich waren.

In einem normalen Entwicklungsszenario würden Sie Schemaänderungen abwärtskompatibel mit der aktuellen Anwendung vornehmen, um Ausfälle zu vermeiden.

Bei Änderungen, die nicht abwärtskompatibel sind, sollten Sie Änderungen an Anwendung und Schema schrittweise bereitstellen, um Ausfälle zu vermeiden.

Nächstes Video

Nachdem das Schema eingerichtet ist, besteht der nächste Schritt darin, die Back-End-Dienste bereitzustellen.

5. Back-End-Dienste bereitstellen

Übersicht

Die Back-End-Dienste für dieses Codelab sind Golang-REST APIs, die vier verschiedene Dienste darstellen:

• Profil:Spieler können sich bei unserem Beispiel-"Spiel" anmelden und sich authentifizieren.
• Spielen: Interagieren Sie mit Spielerdaten, um eine Partnerzuordnungsfunktion zu unterstützen, Informationen zu erstellten Spielen zu verfolgen und die Spielerstatistiken zu aktualisieren, wenn Spiele geschlossen werden.
• Artikel:Spieler erhalten die Möglichkeit, im Laufe des Spiels In-Game-Artikel und Geld zu erhalten.
• Tradepost::Spieler können Artikel auf einem Handelsposten kaufen und verkaufen.

Weitere Informationen zu diesen Diensten finden Sie im Codelab Cloud Spanner – Erste Schritte bei der Spieleentwicklung. Für unsere Zwecke sollen diese Dienste in unserem GKE Autopilot-Cluster ausgeführt werden.

Diese Dienste müssen Spanner-Daten ändern können. Dazu wird für jeden Dienst ein Dienstkonto erstellt, das dem Dienst den Datenbanknutzer (databaseUser) zuweist. Rolle.

Mit Workload Identity kann ein Kubernetes-Dienstkonto die Identität der Dienste übernehmen Google Cloud-Dienstkonto durch die folgenden Schritte in unserem Terraform:

• Google Cloud-Dienstkontoressource (GSA) des Dienstes erstellen
• Weisen Sie diesem Dienstkonto die Rolle databaseUser zu.
• Weisen Sie diesem Dienstkonto die Rolle workloadIdentityUser zu.
• Kubernetes-Dienstkonto (KSA) erstellen, das auf die GSA verweist

Ein grobes Diagramm würde so aussehen:

Hinweis:Jeder Dienst hat ein eigenes GSA und ein eigenes KSA, mit dem sich Berechtigungen trennen und das Prinzip der geringsten Berechtigung anwenden lassen.

Die Dienstkonten und Kubernetes-Dienstkonten wurden von Terraform für Sie erstellt. Außerdem können Sie die Kubernetes-Dienstkonten mit kubectl prüfen:

# kubectl get serviceaccounts
NAME              SECRETS   AGE
default           0         37m
item-app          0         35m
matchmaking-app   0         35m
profile-app       0         35m
tradepost-app     0         35m

Der Build funktioniert folgendermaßen:

• Terraform hat eine $DEMO_HOME/backend_services/cloudbuild.yaml-Datei generiert, die ungefähr so aussieht:

serviceAccount: projects/${PROJECT_ID}/serviceAccounts/cloudbuild-cicd@${PROJECT_ID}.iam.gserviceaccount.com
steps:

#
# Building of images
#
 - name: gcr.io/cloud-builders/docker
   id: profile
   args: ["build", ".", "-t", "${_PROFILE_IMAGE}"]
   dir: profile
   waitFor: ['-']
 - name: gcr.io/cloud-builders/docker
   id: matchmaking
   args: ["build", ".", "-t", "${_MATCHMAKING_IMAGE}"]
   dir: matchmaking
   waitFor: ['-']
 - name: gcr.io/cloud-builders/docker
   id: item
   args: ["build", ".", "-t", "${_ITEM_IMAGE}"]
   dir: item
   waitFor: ['-']
 - name: gcr.io/cloud-builders/docker
   id: tradepost
   args: ["build", ".", "-t", "${_TRADEPOST_IMAGE}"]
   dir: tradepost
   waitFor: ['-']

#
# Deployment
#
 - name: gcr.io/google.com/cloudsdktool/cloud-sdk
   id: cloud-deploy-release
   entrypoint: gcloud
   args:
     [
       "deploy", "releases", "create", "${_REL_NAME}",
       "--delivery-pipeline", "sample-game-services",
       "--skaffold-file", "skaffold.yaml",
       "--skaffold-version", "1.39",
       "--images", "profile=${_PROFILE_IMAGE},matchmaking=${_MATCHMAKING_IMAGE},item=${_ITEM_IMAGE},tradepost=${_TRADEPOST_IMAGE}",
       "--region", "us-central1"
     ]

artifacts:
 images:
   - ${_REGISTRY}/profile
   - ${_REGISTRY}/matchmaking
   - ${_REGISTRY}/item
   - ${_REGISTRY}/tradepost

substitutions:
 _PROFILE_IMAGE: ${_REGISTRY}/profile:${BUILD_ID}
 _MATCHMAKING_IMAGE: ${_REGISTRY}/matchmaking:${BUILD_ID}
 _ITEM_IMAGE: ${_REGISTRY}/item:${BUILD_ID}
 _TRADEPOST_IMAGE: ${_REGISTRY}/tradepost:${BUILD_ID}
 _REGISTRY: us-docker.pkg.dev/${PROJECT_ID}/spanner-game-images
 _REL_NAME: rel-${BUILD_ID:0:8}
options:
 dynamic_substitutions: true
 machineType: E2_HIGHCPU_8
 logging: CLOUD_LOGGING_ONLY

• Der Cloud Build-Befehl liest diese Datei und führt die aufgeführten Schritte aus. Zuerst werden die Dienst-Images erstellt. Dann wird der Befehl gcloud deploy create ausgeführt. Dadurch wird die Datei $DEMO_HOME/backend_services/skaffold.yaml gelesen, mit der definiert wird, wo sich die einzelnen Bereitstellungsdateien befinden:

apiVersion: skaffold/v2beta29
kind: Config
deploy:
 kubectl:
   manifests:
     - spanner_config.yaml
     - profile/deployment.yaml
     - matchmaking/deployment.yaml
     - item/deployment.yaml
     - tradepost/deployment.yaml

• Cloud Deploy folgt den Definitionen der deployment.yaml-Datei jedes Dienstes. Die Bereitstellungsdatei des Dienstes enthält die Informationen zum Erstellen eines Dienstes. In diesem Fall ist dies eine ClusterIP, die auf Port 80 ausgeführt wird.

Die " Der Typ ClusterIP verhindert, dass die Back-End-Dienst-Pods eine externe IP-Adresse haben, sodass nur Entitäten, die eine Verbindung zum internen GKE-Netzwerk herstellen können, auf die Back-End-Dienste zugreifen können. Diese Dienste sollten für Spieler nicht direkt zugänglich sein, da sie auf die Spanner-Daten zugreifen und diese ändern.

apiVersion: v1
kind: Service
metadata:
 name: profile
spec:
 type: ClusterIP
 selector:
   app: profile
 ports:
 - port: 80
   targetPort: 80

Beispiel: $DEMO_HOME/backend_services/profile/deployment.yaml

Cloud Deploy erstellt nicht nur einen Kubernetes-Dienst, sondern auch ein Kubernetes-Deployment. Sehen wir uns den Bereitstellungsabschnitt des profile-Dienstes an:

---
apiVersion: apps/v1
kind: Deployment
metadata:
 name: profile
spec:
 replicas: 2 # EDIT: Number of instances of deployment
 selector:
   matchLabels:
     app: profile
 template:
   metadata:
     labels:
       app: profile
   spec:
     serviceAccountName: profile-app
     containers:
     - name: profile-service
       image: profile
       ports:
         - containerPort: 80
       envFrom:
         - configMapRef:
             name: spanner-config
       env:
         - name: SERVICE_HOST
           value: "0.0.0.0"
         - name: SERVICE_PORT
           value: "80"
       resources:
         requests:
           cpu: "1"
           memory: "1Gi"
           ephemeral-storage: "100Mi"
         limits:
           cpu: "1"
           memory: "1Gi"
           ephemeral-storage: "100Mi"

Der obere Teil enthält einige Metadaten zum Dienst. Entscheidend ist dabei, festzulegen, wie viele Replikate von dieser Bereitstellung erstellt werden.

replicas: 2 # EDIT: Number of instances of deployment

Als Nächstes sehen wir uns an, über welches Dienstkonto die Anwendung ausgeführt werden soll und welches Image verwendet werden soll. Diese stimmen mit dem Kubernetes-Dienstkonto überein, das von Terraform erstellt wurde, und mit dem Image, das im Cloud Build-Schritt erstellt wurde.

spec:
  serviceAccountName: profile-app
  containers:
    - name: profile-service
      image: profile

Danach geben wir einige Informationen zu Netzwerk- und Umgebungsvariablen an.

spanner_config ist eine Kubernetes-ConfigMap, die die Projekt-, Instanz- und Datenbankinformationen angibt, die die Anwendung für die Verbindung mit Spanner benötigt.

apiVersion: v1
kind: ConfigMap
metadata:
  name: spanner-config
data:
  SPANNER_PROJECT_ID: ${project_id}
  SPANNER_INSTANCE_ID: ${instance_id}
  SPANNER_DATABASE_ID: ${database_id}

Hinweis: Die Datei spanner_config.yaml wird von Terraform basierend auf files/backend_services/spanner-config.yaml.tpl generiert.

ports:
  - containerPort: 80
envFrom:
  - configMapRef:
    name: spanner-config
env:
  - name: SERVICE_HOST
    value: "0.0.0.0"
  - name: SERVICE_PORT
    value: "80"

SERVICE_HOST und SERVICE_PORT sind zusätzliche Umgebungsvariablen, die vom Dienst benötigt werden, um zu erkennen, wo die Bindung erfolgen soll.

Im letzten Abschnitt wird GKE festgelegt, wie viele Ressourcen für jedes Replikat in diesem Deployment zulässig sind. Dies wird auch von GKE Autopilot verwendet, um den Cluster nach Bedarf zu skalieren.

resources:
  requests:
    cpu: "1"
    memory: "1Gi"
    ephemeral-storage: "100Mi"
  limits:
    cpu: "1"
    memory: "1Gi"
    ephemeral-storage: "100Mi"

Mit diesen Informationen können Sie nun die Back-End-Dienste bereitstellen.

Back-End-Dienste bereitstellen

Wie bereits erwähnt, wird für die Bereitstellung der Back-End-Dienste Cloud Build verwendet. Genau wie bei der Schemamigration können Sie die Build-Anfrage über die gcloud-Befehlszeile senden:

cd $DEMO_HOME/backend_services
gcloud builds submit --config=cloudbuild.yaml

Befehlsausgabe

Creating temporary tarball archive of 66 file(s) totalling 864.6 KiB before compression.
Uploading tarball of [.] to [gs://(project)_cloudbuild/source/(snip).tgz]
Created [https://cloudbuild.googleapis.com/v1/projects/(project)/locations/global/builds/30207dd1-(snip)].
Logs are available at [ https://console.cloud.google.com/cloud-build/builds/30207dd1-(snip)?project=(snip) ].

gcloud builds submit only displays logs from Cloud Storage. To view logs from Cloud Logging, run:
gcloud beta builds submit

ID: 30207dd1-(snip)
CREATE_TIME: (created time)
DURATION: 3M17S
SOURCE: gs://(project)_cloudbuild/source/(snip).tgz
IMAGES: us-docker.pkg.dev/(project)/spanner-game-images/profile:30207dd1-(snip) (+3 more)
STATUS: SUCCESS

Hinweis: Es kann einige Minuten dauern, bis der Build und die Bereitstellung abgeschlossen sind.

Im Gegensatz zur Ausgabe des Schritts schema migration gibt die Ausgabe dieses Builds an, dass einige Images erstellt wurden. Diese werden in Ihrem Artifact Registry-Repository gespeichert.

Die Ausgabe des Schritts gcloud build enthält einen Link zur Cloud Console. Sehen Sie sich diese an.

Hinweis: Auch wenn Sie eine SUCCESS-Meldung von Cloud Build erhalten, ist das Deployment erst abgeschlossen, wenn die Pods ausgeführt werden.

Wenn Sie die Erfolgsbenachrichtigung von Cloud Build erhalten haben, rufen Sie Cloud Deploy und dann die Pipeline sample-game-services auf, um den Fortschritt der Bereitstellung zu überwachen.

Sobald die Dienste bereitgestellt sind, können Sie mit kubectl die Leistung der Pods Status:

kubectl get pods

Befehlsausgabe

NAME                           READY   STATUS    RESTARTS   AGE
item-6b9d5f678c-4tbk2          1/1     Running   0          83m
matchmaking-5bcf799b76-lg8zf   1/1     Running   0          80m
profile-565bbf4c65-kphdl       1/1     Running   0          83m
profile-565bbf4c65-xw74j       1/1     Running   0          83m
tradepost-68b87ccd44-gw55r     1/1     Running   0          79m

Prüfen Sie dann die Dienste, um ClusterIP in Aktion zu sehen:

kubectl get services

Befehlsausgabe

NAME          TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
item          ClusterIP   10.172.XXX.XXX   <none>        80/TCP    84m
kubernetes    ClusterIP   10.172.XXX.XXX   <none>        443/TCP   137m
matchmaking   ClusterIP   10.172.XXX.XXX   <none>        80/TCP    84m
profile       ClusterIP   10.172.XXX.XXX   <none>        80/TCP    84m
tradepost     ClusterIP   10.172.XXX.XXX   <none>        80/TCP    84m

Hinweis: Den Back-End-Diensten ist keine externe IP-Adresse zugewiesen, um den externen Zugriff auf die APIs zu verhindern.

Sie können auch die GKE-UI in der Cloud Console aufrufen, um Workloads, Services und ConfigMaps zu sehen.

Arbeitslasten

Dienste

ConfigMaps

Zusammenfassung

In diesem Schritt haben Sie die vier Back-End-Dienste für GKE Autopilot bereitgestellt. Sie konnten den Cloud Build-Schritt ausführen und den Fortschritt in Cloud Deploy und Kubernetes in der Cloud Console prüfen.

Sie haben außerdem gelernt, wie diese Dienste Workload Identity verwenden, um die Identität eines Dienstkontos zu übernehmen, das die erforderlichen Berechtigungen zum Lesen und Schreiben von Daten in der Spanner-Datenbank hat.

Nächste Schritte

Im nächsten Abschnitt stellen Sie die Arbeitslasten bereit.

6. Arbeitslasten bereitstellen

Übersicht

Nachdem nun die Back-End-Dienste im Cluster ausgeführt werden, stellen Sie die Arbeitslasten bereit.

Auf die Arbeitslasten kann extern zugegriffen werden. In diesem Codelab gibt es für jeden Back-End-Dienst eine.

Bei diesen Arbeitslasten handelt es sich um Locust, die die realen Zugriffsmuster nachahmen, die von diesen Beispieldiensten erwartet werden.

Es gibt Dateien für den Cloud Build-Prozess:

• $DEMO_HOME/workloads/cloudbuild.yaml (von Terraform generiert)
• $DEMO_HOME/workloads/skaffold.yaml
• eine deployment.yaml-Datei für jede Arbeitslast

Sie können sich auch die Dateien cloudbuild.yaml und skaffold.yaml ansehen. Sie sind fast genau mit den Back-End-Diensten identisch, mit der Ausnahme, dass sich die Image-Namen und Verzeichnisse unterscheiden.

Die deployment.yaml-Dateien der Arbeitslast unterscheiden sich geringfügig von den Bereitstellungsdateien des Back-End-Dienstes.

Hier ein Beispiel aus matchmaking-workload:

apiVersion: v1
kind: Service
metadata:
 name: matchmaking-workload
spec:
 type: LoadBalancer
 selector:
   app: matchmaking-workload
 ports:
 - port: 8089
   targetPort: 8089
---
apiVersion: apps/v1
kind: Deployment
metadata:
 name: matchmaking-workload
spec:
 replicas: 1 # EDIT: Number of instances of deployment
 selector:
   matchLabels:
     app: matchmaking-workload
 template:
   metadata:
     labels:
       app: matchmaking-workload
   spec:
     serviceAccountName: default
     containers:
     - name: matchmaking-workload
       image: matchmaking-workload
       ports:
         - containerPort: 8089
       resources:
         requests:
           cpu: "500m"
           memory: "512Mi"
           ephemeral-storage: "100Mi"
         limits:
           cpu: "500m"
           memory: "512Mi"
           ephemeral-storage: "100Mi"

Im oberen Teil der Datei wird der Dienst definiert. In diesem Fall wird ein LoadBalancer erstellt und die Arbeitslast wird auf Port 8089 ausgeführt.

Der LoadBalancer stellt eine externe IP-Adresse bereit, mit der eine Verbindung zur Arbeitslast hergestellt werden kann.

apiVersion: v1
kind: Service
metadata:
 name: matchmaking-workload
spec:
 type: LoadBalancer
 selector:
   app: matchmaking-workload
 ports:
 - port: 8089
   targetPort: 8089

Oben im Bereich „Bereitstellung“ finden Sie die Metadaten zur Arbeitslast. In diesem Fall wird nur ein Replikat bereitgestellt:

replicas: 1 

Die Containerspezifikation ist jedoch anders. Zum einen verwenden wir ein default-Kubernetes-Dienstkonto. Dieses Konto hat keine besonderen Berechtigungen, da die Arbeitslast keine Verbindung zu Google Cloud-Ressourcen herstellen muss, mit Ausnahme der Back-End-Dienste, die im GKE-Cluster ausgeführt werden.

Der andere Unterschied besteht darin, dass für diese Arbeitslasten keine Umgebungsvariablen erforderlich sind. Das Ergebnis ist eine kürzere Bereitstellungsspezifikation.

spec:
  serviceAccountName: default
  containers:
    - name: matchmaking-workload
      image: matchmaking-workload
  ports:
    - containerPort: 8089

Die Ressourceneinstellungen ähneln den Back-End-Diensten. Denken Sie daran, dass GKE Autopilot so weiß, wie viele Ressourcen erforderlich sind, um die Anfragen aller im Cluster ausgeführten Pods zu erfüllen.

Stellen Sie jetzt die Arbeitslasten bereit.

Arbeitslasten bereitstellen

Wie zuvor können Sie die Build-Anfrage über die gcloud-Befehlszeile senden:

cd $DEMO_HOME/workloads
gcloud builds submit --config=cloudbuild.yaml

Befehlsausgabe

Creating temporary tarball archive of 18 file(s) totalling 26.2 KiB before compression.
Some files were not included in the source upload.

Check the gcloud log [/tmp/tmp.4Z9EqdPo6d/logs/(snip).log] to see which files and the contents of the
default gcloudignore file used (see `$ gcloud topic gcloudignore` to learn
more).

Uploading tarball of [.] to [gs://(project)_cloudbuild/source/(snip).tgz]
Created [https://cloudbuild.googleapis.com/v1/projects/(project)/locations/global/builds/(snip)].
Logs are available at [ https://console.cloud.google.com/cloud-build/builds/0daf20f6-(snip)?project=(snip) ].

gcloud builds submit only displays logs from Cloud Storage. To view logs from Cloud Logging, run:
gcloud beta builds submit

ID: 0daf20f6-(snip)
CREATE_TIME: (created_time)
DURATION: 1M41S
SOURCE: gs://(project)_cloudbuild/source/(snip).tgz
IMAGES: us-docker.pkg.dev/(project)/spanner-game-images/profile-workload:0daf20f6-(snip) (+4 more)
STATUS: SUCCESS

Hinweis: Es kann einige Minuten dauern, bis der Build und die Bereitstellung abgeschlossen sind.

Prüfen Sie unbedingt die Cloud Build-Logs und die Cloud Deploy-Pipeline in der Cloud Console, um den Status zu prüfen. Für die Arbeitslasten ist die Cloud Deploy-Pipeline sample-game-workloads:

Prüfen Sie nach Abschluss der Bereitstellung mit kubectl den Status in Cloud Shell:

kubectl get pods

Befehlsausgabe

NAME                                    READY   STATUS    RESTARTS   AGE
game-workload-7ff44cb657-pxxq2          1/1     Running   0          12m
item-6b9d5f678c-cr29w                   1/1     Running   0          9m6s
item-generator-7bb4f57cf8-5r85b         1/1     Running   0          12m
matchmaking-5bcf799b76-lg8zf            1/1     Running   0          117m
matchmaking-workload-76df69dbdf-jds9z   1/1     Running   0          12m
profile-565bbf4c65-kphdl                1/1     Running   0          121m
profile-565bbf4c65-xw74j                1/1     Running   0          121m
profile-workload-76d6db675b-kzwng       1/1     Running   0          12m
tradepost-68b87ccd44-gw55r              1/1     Running   0          116m
tradepost-workload-56c55445b5-b5822     1/1     Running   0          12m

Prüfen Sie dann die Arbeitslastdienste, um LoadBalancer in Aktion zu sehen:

kubectl get services 

Befehlsausgabe

NAME                   TYPE          CLUSTER-IP  EXTERNAL-IP     PORT(S)        AGE
game-workload          LoadBalancer  *snip*      35.XX.XX.XX   8089:32483/TCP   12m
item                   ClusterIP     *snip*      <none>         80/TCP          121m
item-generator         LoadBalancer  *snip*      34.XX.XX.XX   8089:32581/TCP   12m
kubernetes             ClusterIP     *snip*      <none>          443/TCP        174m
matchmaking            ClusterIP     *snip*      <none>          80/TCP         121m
matchmaking-workload   LoadBalancer  *snip*      34.XX.XX.XX   8089:31735/TCP   12m
profile                ClusterIP     *snip*      <none>          80/TCP         121m
profile-workload       LoadBalancer  *snip*      34.XX.XX.XX   8089:32532/TCP   12m
tradepost              ClusterIP     *snip*      <none>          80/TCP         121m
tradepost-workload     LoadBalancer  *snip*      34.XX.XX.XX   8089:30002/TCP   12m

Hinweis: Im Gegensatz zu den Back-End-Diensten sind den Arbeitslasten externe IP-Adressen zugewiesen.

Zusammenfassung

Sie haben jetzt die Arbeitslasten im GKE-Cluster bereitgestellt. Diese Arbeitslasten erfordern keine zusätzlichen IAM-Berechtigungen und sind über den LoadBalancer-Dienst über Port 8089 extern zugänglich.

Nächste Schritte

Da die Back-End-Dienste und Arbeitslasten ausgeführt werden, ist es an der Zeit, zu spielen. das Spiel!

7. Spiel starten

Übersicht

Die Back-End-Dienste für Ihr Beispiel-"Spiel" jetzt ausgeführt werden, und Sie haben auch die Möglichkeit, "Spieler" zu generieren, die Interaktion mit diesen Diensten über die Arbeitslasten.

Jede Arbeitslast verwendet Locust, um die tatsächliche Last für unsere Dienst-APIs zu simulieren. In diesem Schritt führen Sie mehrere der Arbeitslasten aus, um eine Last im GKE-Cluster und in Spanner zu generieren, und speichern Daten in Spanner.

Hier finden Sie eine Beschreibung der einzelnen Arbeitslasten:

• Die Arbeitslast item-generator ist eine schnelle Arbeitslast zum Generieren einer Liste von game_items, die Spieler im Laufe des „Spielens“ erwerben können. für das Spiel.
• profile-workload simuliert, wie Spieler sich registrieren und anmelden.
• matchmaking-workload simuliert Spieler, die sich in die Warteschlange stellen und einem Spiel zugewiesen werden.
• game-workload simuliert, wie Spieler im Laufe des Spiels Spielelemente und Geld erwerben.
• tradepost-workload simuliert, wie Spieler auf dem Handelsposten Artikel verkaufen und kaufen können.

Hinweis:Weitere Informationen zur Funktionsweise dieser Locust-Generatoren finden Sie im Codelab Cloud Spanner – Erste Schritte mit der Spieleentwicklung.

In diesem Codelab erfahren Sie, wie Sie item-generator und profile-workload ausführen.

Artikelgenerator ausführen

item-generator verwendet den Back-End-Dienst-Endpunkt item, um game_items zu Spanner hinzuzufügen. Diese Elemente sind erforderlich, damit game-workload und tradepost-workload ordnungsgemäß funktionieren.

Der erste Schritt besteht darin, die externe IP-Adresse des item-generator-Dienstes abzurufen. Führen Sie in Cloud Shell folgenden Befehl aus:

# The external IP is the 4th column of the output
kubectl get services | grep item-generator | awk '{print $4}'

Befehlsausgabe

{ITEMGENERATOR_EXTERNAL_IP}

Öffnen Sie nun einen neuen Browsertab und bewegen Sie den Mauszeiger auf http://{ITEMGENERATOR_EXTERNAL_IP}:8089. Sie sollten eine Seite wie die folgende erhalten:

Belassen Sie users und spawn auf der Standardeinstellung 1. Geben Sie für host, http://item ein. Klicken Sie auf die erweiterten Optionen und geben Sie 10s für die Laufzeit ein.

Die Konfiguration sollte so aussehen:

Hinweis: Da sich die Arbeitslasten und Back-End-Dienste im selben GKE-Cluster befinden, können sie sich gegenseitig mithilfe der DNS-Auflösung als Dienstnamen erkennen. Deshalb können Sie auf den Hostnamen http://item verweisen.

Klicken Sie auf „Start swarming“ (Swarm starten!)

Es werden Statistiken für Anfragen angezeigt, die am POST /items-Endpunkt gesendet werden. Nach 10 Sekunden wird der Ladevorgang beendet.

Wenn Sie auf Charts klicken, sehen Sie einige Diagramme zur Leistung dieser Anfragen.

Jetzt möchten Sie prüfen, ob die Daten in die Spanner-Datenbank eingegeben werden.

Klicken Sie dazu auf das Dreistrich-Menü und navigieren Sie zu „Spanner“. Gehen Sie von dieser Seite aus zu sample-instance und sample-database. Klicken Sie dann auf „Query“.

Wir möchten die Anzahl von game_items auswählen:

SELECT COUNT(*) FROM game_items;

Unten sehen Sie das Ergebnis.

Hinweis:Die Anzahl der Spielelemente stimmt möglicherweise nicht genau überein. Kein Problem.

Wir brauchen nicht viel game_items-Seeded. Aber jetzt können sie von Spielern erworben werden.

Profilarbeitslast ausführen

Wenn du „game_items“ gesetzt hast, musst du dich im nächsten Schritt dafür registrieren, Spiele zu spielen.

Die profile-workload nutzt Locust, um zu simulieren, wie Spieler Konten erstellen, sich anmelden, Profilinformationen abrufen und sich abmelden. Mit all diesen Tests werden die Endpunkte des Back-End-Dienstes profile in einer typischen produktionsähnlichen Arbeitslast getestet.

Rufen Sie zum Ausführen die externe IP-Adresse profile-workload ab:

# The external IP is the 4th column of the output
kubectl get services | grep profile-workload | awk '{print $4}'

Befehlsausgabe

{PROFILEWORKLOAD_EXTERNAL_IP}

Öffnen Sie nun einen neuen Browsertab und bewegen Sie den Mauszeiger auf http://{PROFILEWORKLOAD_EXTERNAL_IP}:8089. Sie sollten eine Locust-Seite erhalten, die der vorherigen ähnelt.

In diesem Fall verwenden Sie http://profile als Host. Außerdem geben Sie in den erweiterten Optionen keine Laufzeit an. Legen Sie außerdem für users den Wert 4 fest, damit vier Nutzeranfragen gleichzeitig simuliert werden.

Der profile-workload-Test sollte so aussehen:

Klicken Sie auf „Start swarming“ (Swarm starten!)

Wie zuvor werden die Statistiken für die verschiedenen profile-REST-Endpunkte angezeigt. Klicken Sie auf die Diagramme, um zu sehen, wie gut die Leistung insgesamt ist.

Hinweis: Lassen Sie profile-workload ausgeführt. Im nächsten Abschnitt können Sie die Leistung von GKE und Cloud Spanner überprüfen.

Zusammenfassung

In diesem Schritt haben Sie game_items generiert und dann die Tabelle game_items über die Spanner-Abfrage-UI in der Cloud Console abgefragt.

Außerdem haben Sie es Spielern ermöglicht, sich für Ihr Spiel zu registrieren, und gesehen, wie Locust produktionsähnliche Arbeitslasten für Ihre Backend-Dienste erstellen kann.

Nächste Schritte

Nachdem Sie die Arbeitslasten ausgeführt haben, möchten Sie prüfen, wie sich der GKE-Cluster und die Spanner-Instanz verhalten.

8. GKE- und Spanner-Nutzung prüfen

Während der Profildienst ausgeführt wird, können Sie jetzt sehen, wie sich Ihr GKE Autopilot-Cluster und Cloud Spanner verhalten.

GKE-Cluster prüfen

Rufen Sie den Kubernetes-Cluster auf. Da Sie die Arbeitslasten und Dienste bereitgestellt haben, enthält der Cluster jetzt einige Details zu den vCPUs und dem Arbeitsspeicher insgesamt. Diese Informationen waren nicht verfügbar, wenn im Cluster keine Arbeitslasten vorhanden waren.

Klicken Sie jetzt auf den Cluster sample-game-gke und wechseln Sie zum Tab „Beobachtbarkeit“:

Der Kubernetes-Namespace default sollte für die CPU-Auslastung den Namespace kube-system überschritten haben, da unsere Arbeitslasten und Backend-Dienste unter default ausgeführt werden. Ist dies nicht der Fall, prüfen Sie, ob profile workload noch ausgeführt wird, und warten Sie ein paar Minuten, bis die Diagramme aktualisiert wurden.

Im Workloads-Dashboard können Sie sehen, welche Arbeitslasten die meisten Ressourcen beanspruchen.

Anstatt jede Arbeitslast einzeln aufzurufen, gehen Sie im Dashboard direkt zum Tab „Beobachtbarkeit“. Sie sollten sehen, dass die CPU-Leistung bei profile und profile-workload gestiegen ist.

Sehen Sie sich nun Cloud Spanner an.

Cloud Spanner-Instanz prüfen

Rufen Sie Spanner auf und klicken Sie auf die Instanz sample-instance und die Datenbank sample-game, um die Leistung von Cloud Spanner zu prüfen.

Sie sehen dort im Menü auf der linken Seite den Tab Systemstatistiken:

Es gibt viele Diagramme, mit denen Sie die allgemeine Leistung Ihrer Spanner-Instanz besser nachvollziehen können, darunter CPU utilization, transaction latency and locking und query throughput.

Zusätzlich zu Systemstatistiken erhalten Sie detaillierte Informationen zur Abfragearbeitslast, indem Sie die anderen Links im Abschnitt „Beobachtbarkeit“ aufrufen:

• Mit Abfragestatistiken können Sie die Top-N-Abfragen ermitteln, die Ressourcen in Spanner verwenden.
• Mit den Statistiken zu Transaktionen und Sperren können Sie Transaktionen mit hohen Latenzen identifizieren.
• Key Visualizer unterstützt die Visualisierung von Zugriffsmustern und die Verfolgung von Hotspots in den Daten.

Zusammenfassung

In diesem Schritt haben Sie erfahren, wie Sie einige grundlegende Leistungsmesswerte für GKE Autopilot und Spanner prüfen.

Fragen Sie beispielsweise die Tabelle players ab, wenn Ihre Profilarbeitslast ausgeführt wird, um weitere Informationen zu den dort gespeicherten Daten zu erhalten.

Bevor Sie fortfahren, sollten Sie sich die verfügbaren Informationen zu GKE und Spanner ansehen, um sich mit den Diensten vertraut zu machen.

Nächste Schritte

Als Nächstes ist es Zeit, aufzuräumen!

9. Bereinigen

Vor der Bereinigung können Sie sich auch die anderen Arbeitslasten ansehen, die nicht abgedeckt wurden. Konkret handelt es sich um matchmaking-workload, game-workload und tradepost-workload.

Wenn du fertig bist könnt ihr euren Spielplatz aufräumen. Zum Glück ist das ziemlich einfach.

Wird profile-workload noch immer im Browser ausgeführt, beende dies zuerst:

Wiederholen Sie diese Schritte für jede Arbeitslast, die Sie möglicherweise getestet haben.

Öffnen Sie dann in Cloud Shell den Infrastrukturordner. Sie führen die destroy-Infrastruktur mithilfe von Terraform durch:

cd $DEMO_HOME/infrastructure
terraform destroy
# type 'yes' when asked

Befehlsausgabe

Plan: 0 to add, 0 to change, 46 to destroy.

Do you really want to destroy all resources?
  Terraform will destroy all your managed infrastructure, as shown above.
  There is no undo. Only 'yes' will be accepted to confirm.

  Enter a value: yes

*snip*

Destroy complete! Resources: 46 destroyed.

Hinweis:Es dauert einige Minuten, bis die Infrastruktur vollständig entfernt ist.

Gehen Sie in der Cloud Console zu Spanner, Kubernetes Cluster, Artifact Registry, Cloud Deploy und IAM, um zu prüfen, ob alle Ressourcen entfernt wurden.

10. Glückwunsch!

Glückwunsch! Sie haben Golang-Beispielanwendungen erfolgreich in GKE Autopilot bereitgestellt und mithilfe von Workload Identity mit Cloud Spanner verbunden.

Außerdem lässt sich die Infrastruktur mit Terraform leicht einrichten und wiederholbar entfernen.

In diesem Codelab erfahren Sie mehr über die Google Cloud-Dienste, mit denen Sie interagiert haben:

• GKE Autopilot und Workload Identity
• Cloud Spanner
• Artifact Registry
• Cloud Build und Cloud Deploy

Nächste Schritte

Sie haben nun ein grundlegendes Verständnis dafür, wie GKE Autopilot und Cloud Spanner zusammenarbeiten können. Als Nächstes erstellen Sie jetzt eine eigene Anwendung für diese Dienste.