Cloud Spanner'ı GKE Autopilot'a bağlama

1. Giriş

Cloud Spanner, performanstan ve yüksek kullanılabilirlikten ödün vermeden ACID işlemleri ve SQL semantiği sağlayan, tümüyle yönetilen, yatay olarak ölçeklenebilir, küresel olarak dağıtılmış bir ilişkisel veritabanı hizmetidir.

GKE Autopilot, GKE'de Google'ın düğümleriniz, ölçeklendirme, güvenlik ve en iyi uygulamaları izlemek için önceden yapılandırılmış diğer ayarlar dahil olmak üzere küme yapılandırmanızı yönettiği bir çalışma modudur. Örneğin GKE Autopilot, hizmet izinlerini yönetmek için İş Yükü Kimliği'ni etkinleştirir.

Bu laboratuvarın amacı, GKE Autopilot'ta çalışan çeşitli arka uç hizmetlerini Cloud Spanner veritabanına bağlama sürecinde size yol göstermektir.

Bu laboratuvarda önce bir proje oluşturacak ve Cloud Shell'i başlatacaksınız. Ardından Terraform kullanarak altyapıyı dağıtacaksınız.

Bu işlemler tamamlandığında Cloud Build ve Cloud Deploy ile etkileşime geçerek Games veritabanında ilk şema taşıma işlemini gerçekleştirecek, arka uç hizmetlerini dağıtacak ve ardından iş yüklerini dağıtacaksınız.

Bu codelab'deki hizmetler, Cloud Spanner Oyun Geliştirmeye Başlama codelab'indeki hizmetlerle aynıdır. Hizmetlerin GKE'de çalışmasını ve Spanner'a bağlanmasını sağlamak için codelab'den geçmek gerekli değildir. Ancak, Spanner'da çalışan bu hizmetlerin özellikleriyle ilgili daha ayrıntılı bilgi edinmek isterseniz, incelemenizi öneririz.

İş yükleri ve arka uç hizmetleri çalışırken yük oluşturmaya başlayabilir ve hizmetlerin birlikte nasıl çalıştığını gözlemleyebilirsiniz.

Son olarak, bu laboratuvarda oluşturulan kaynakları temizleyeceksiniz.

Neler oluşturacaksınız?

Bu laboratuvar kapsamında:

• Terraform kullanarak altyapının temel hazırlığını yapın
• Cloud Build'de Şema Taşıma işlemi kullanarak veritabanı şeması oluşturma
• Cloud Spanner'a bağlanmak için Workload Identity'den yararlanan dört Golang arka uç hizmetini dağıtma
• Arka uç hizmetlerinin yükünü simüle etmek için kullanılan dört iş yükü hizmetini dağıtın.

Neler öğreneceksiniz?

• Terraform kullanarak GKE Autopilot, Cloud Spanner ve Cloud Deploy ardışık düzenlerinin temel hazırlığını yapma
• Workload Identity, GKE'deki hizmetlerin Cloud Spanner ile birlikte çalışmak için IAM izinlerine erişmek amacıyla hizmet hesaplarının kimliğine bürünmesine nasıl izin verir?
• Locust.io kullanarak GKE ve Cloud Spanner'da üretim benzeri yük oluşturma

İhtiyacınız olanlar

• Faturalandırma hesabına bağlı bir Google Cloud projesi.
• Chrome veya Firefox gibi bir web tarayıcısı.

2. Kurulum ve şartlar

Proje oluşturma

Uyarı: Bu codelab, projenizde değişiklikler yapar. Bu codelab için özel bir proje oluşturmanız önemle tavsiye edilir.

Google Hesabınız (Gmail veya Google Apps) yoksa bir hesap oluşturmanız gerekir. Google Cloud Platform konsolunda ( console.cloud.google.com) oturum açın ve yeni bir proje oluşturun.

Zaten bir projeniz varsa konsolun sol üst köşesindeki proje seçimi açılan menüsünü tıklayın:

ve "YENİ PROJE"yi tıklayın. düğmesini tıklayın:

Henüz projeniz yoksa ilk projenizi oluşturmak için şuna benzer bir iletişim kutusu görmeniz gerekir:

Sonraki proje oluşturma iletişim kutusu yeni projenizin ayrıntılarını girmenize olanak tanır:

Tüm Google Cloud projeleri için benzersiz bir ad olan proje kimliğini unutmayın (yukarıdaki ad daha önce alınmış ve size uygun olmayacaktır!). Bu kod laboratuvarın ilerleyen bölümlerinde PROJECT_ID olarak adlandırılacaktır.

Ardından, henüz yapmadıysanız Developers Console'da faturalandırmayı etkinleştirmeniz ve Google Cloud kaynaklarını kullanmanız ve Cloud Spanner API'yi etkinleştirmeniz gerekir.

Bu codelab'i çalıştırmanın maliyeti birkaç dolardan fazla değildir. Ancak daha fazla kaynak kullanmaya karar verirseniz veya bu kaynakları çalışır durumda bırakırsanız daha yüksek ücret ödemeniz gerekebilir (bu belgenin sonundaki "temizlik" bölümüne bakın). Google Cloud Spanner fiyatlandırması burada, GKE Autopilot fiyatlandırması burada açıklanmıştır.

Yeni Google Cloud Platform kullanıcıları, bu codelab'i tamamen ücretsiz hale getirecek 300 ABD doları değerindeki ücretsiz denemeden yararlanabilir.

Cloud Shell kurulumu

Google Cloud ve Spanner, dizüstü bilgisayarınızdan uzaktan çalıştırılabilse de bu codelab'de, Cloud'da çalışan bir komut satırı ortamı olan Google Cloud Shell'i kullanacağız.

Bu Debian tabanlı sanal makine, ihtiyacınız olan tüm geliştirme araçlarıyla yüklüdür. 5 GB boyutunda kalıcı bir ana dizin sunar ve Google Cloud'da çalışarak ağ performansını ve kimlik doğrulamasını büyük ölçüde iyileştirir. Yani bu codelab'de ihtiyacınız olan tek şey bir tarayıcıdır (evet, Chromebook'ta çalışır).

1. Cloud Console'dan Cloud Shell'i etkinleştirmek için Cloud Shell'i Etkinleştir'i tıklamanız yeterlidir (sağlanması ve ortama bağlanması birkaç dakika sürer).

Cloud Shell'e bağlandıktan sonra kimliğinizin doğrulandığını ve projenin PROJECT_ID olarak ayarlanmış olduğunu göreceksiniz.

gcloud auth list

Komut çıkışı

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

Not: gcloud komut satırı aracı, Cloud Shell'de önceden yüklü olarak gelir. Daha fazla bilgi için gcloud komut satırı aracına genel bakış başlıklı makaleyi inceleyin.

gcloud config list project

Komut çıkışı

[core]
project = <PROJECT_ID>

Herhangi bir nedenle proje ayarlanmamışsa şu komutu vermeniz yeterlidir:

gcloud config set project <PROJECT_ID>

PROJECT_ID cihazınızı mı arıyorsunuz? Kurulum adımlarında kullandığınız kimliği kontrol edin veya Cloud Console kontrol panelinden arayın:

Cloud Shell bazı ortam değişkenlerini de varsayılan olarak ayarlar. Bu değişkenler, gelecekte komut çalıştırdığınızda işinize yarayabilir.

echo $GOOGLE_CLOUD_PROJECT

Komut çıkışı

<PROJECT_ID>

Not: gcloud'u kendi makinenizde çalıştırdığınızda yapılandırma ayarları oturumlar genelinde kalıcı olur. Ancak Cloud Shell'de bu ayarları her yeni oturum veya yeniden bağlanma için tekrar belirlemeniz gerekir.

Kodu indirme

Cloud Shell'de bu laboratuvarın kodunu indirebilirsiniz:

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

Komut çıkışı

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

Bu codelab, v0.1.3 sürümünü temel almaktadır. Bu nedenle etiketi kontrol edin:

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

Komut çıkışı

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

Şimdi, mevcut çalışma dizinini DEMO_HOME ortam değişkeni olarak ayarlayın. Bu sayede, codelab'in farklı bölümlerinde çalışırken daha kolay gezinebilirsiniz.

export DEMO_HOME=$(pwd)

Özet

Bu adımda yeni bir proje oluşturdunuz, Cloud Shell'i etkinleştirdiniz ve bu laboratuvarın kodunu indirdiniz.

Sıradaki

Ardından, Terraform kullanarak altyapının temel hazırlığını yapacaksınız.

3. Altyapıyı sağlayın

Genel Bakış

Projeniz hazır olduğuna göre sıra altyapıyı çalıştırmaya geldi. Buna VPC ağ iletişimi, Cloud Spanner, GKE Autopilot, GKE'de çalışacak görüntüleri depolayan Artifact Registry, arka uç hizmetleri ve iş yükleri için Cloud Deploy ardışık düzenleri ve son olarak bu hizmetleri kullanabilmek için hizmet hesapları ve IAM ayrıcalıkları dahildir.

Büyük başarı! Ancak neyse ki Terraform bu kurulumu daha kolay hale getirebilir. Terraform bir "Kod Olarak Altyapı"dır bu proje için ihtiyacımız olanları bir dizi ".tf" dosyasında dosyası olarak da kaydedebilir. Bu sayede, altyapının temel hazırlığı daha basit hale gelir.

Bu codelab'i tamamlamak için Terraform'a aşina olmanız gerekmez. Ancak bundan sonra atılacak birkaç adımın ne olacağını görmek isterseniz infrastructure dizininde bulunan bu dosyalarda nelerin oluşturulduğuna göz atabilirsiniz:

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

Terraform'u yapılandırın

Cloud Shell'de infrastructure dizinine geçiş yapacak ve Terraform'u ilk kullanıma hazırlayacaksınız:

cd $DEMO_HOME/infrastructure
terraform init

Komut çıkışı

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.

Ardından, terraform.tfvars.sample dosyasını kopyalayıp proje değerini değiştirerek Terraform'u yapılandırın. Diğer değişkenler de değiştirilebilir, ancak ortamınızla uyumlu olması için yalnızca projede değiştirilmesi gerekir.

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

Not: Altyapı, varsayılan değişkenler kullanılarak us-central1 bölgesinde dağıtılır.

Altyapıyı sağlama

Uyarı: Bu adım, projenizde değişiklikler yapar. Önceden var olan bir projeyi kullanıyorsanız bu durum istenmeyen sonuçlar doğurabilir. Bu codelab için özel bir proje oluşturmanız önemle tavsiye edilir.

Şimdi sıra altyapıyı sağlamaya geldi.

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

Komut çıkışı

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.

Not: Altyapının tamamen kurulması birkaç dakika sürer.

Not: Kubernetes default_secret_name ürününün kullanımdan kaldırıldığına dair bir not alabilirsiniz. Bunu göz ardı edebilirsiniz.

Nelerin oluşturulduğunu kontrol etme

Neyin oluşturulduğunu doğrulamak için Cloud Console'da ürünleri kontrol etmek istiyorsunuz.

Not: terraform apply adımı tamamlanana kadar aşağıdaki kaynaklar görünmeyebilir.

Cloud Spanner

İlk olarak, hamburger menüsüne gidip Spanner simgesini tıklayarak Cloud Spanner'ı kontrol edin. "Daha fazla ürün göster"i tıklamanız gerekebilir listeden çıkarabilirsiniz.

Bunu yaptığınızda Spanner örnekleri listesine yönlendirilirsiniz. Örneği tıkladığınızda veritabanlarını görürsünüz. Şuna benzer bir görünümde olacaktır:

Not: Bunun, us-central bölgesel yapılandırmasıyla 100 işleme biriminde (100 PU) çalışan ayrıntılı bir örnek olduğunu göreceksiniz.

GKE Autopilot

Ardından, hamburger menüye gidip Kubernetes Engine => Clusters simgesini tıklayarak GKE'ye göz atın. Burada sample-games-gke kümesini Autopilot modunda göreceksiniz.

Not: GKE kümesinin us-central bölgesinde de bulunduğuna dikkat edin. İsteklerin gecikmesini azaltmak için uygulamaların veritabanına yakın olması önemlidir.

Artifact Registry

Şimdi resimlerin nerede depolanacağını göreceksiniz. Hamburger menüyü tıklayıp Artifact Registry=>Repositories bulun. Artifact Registry, menünün CI/CD bölümündedir.

Burada spanner-game-images adlı Docker kaydını göreceksiniz. Bu alan şimdilik boş olacaktır.

Cloud Deploy

Cloud Deploy, ardışık düzenlerin oluşturulduğu yerdir. Cloud Build, görüntülerin derlenmesi için gereken adımları sunabilir ve ardından bunları GKE kümemize dağıtabilir.

Hamburger menüsüne gidin ve menünün CI/CD bölümünde de bulunan Cloud Deploy öğesini bulun.

Burada biri arka uç hizmetleri, diğeri iş yükleri için olmak üzere iki ardışık düzen görürsünüz. İkisi de görüntüleri aynı GKE kümesine dağıtıyor ancak bu durum dağıtımlarımızı ayırmamızı sağlıyor.

IAM

Son olarak, oluşturulan hizmet hesaplarını doğrulamak için Cloud Console'daki IAM sayfasına göz atın. Hamburger menüsüne gidin ve IAM and Admin=>Service accounts öğesini bulun. Şuna benzer bir görünümde olacaktır:

Terraform tarafından oluşturulan toplam altı hizmet hesabı vardır:

• Varsayılan bilgisayar hizmeti hesabı. Bu kod, bu codelab'de kullanılmamaktadır.
• Cloudbuild-cicd hesabı, Cloud Build ve Cloud Deploy adımları için kullanılır.
• Dört "uygulama" arka uç hizmetlerimiz tarafından Cloud Spanner ile etkileşim kurmak için kullanılan hesaplar.

Bir sonraki adımda, GKE kümesiyle etkileşim kurmak için kubectl eklentisini yapılandıracaksınız.

kubectl'i yapılandırma

# 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

Komut çıkışı

#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

Not: kubectl işlevinin kimlik doğrulama ile ilgili herhangi bir hata vermemesi gerekir. Bu önemli denetimdir.

Özet

Çok güzel! Tamamı özel ağ iletişimi için VPC'de bulunan Cloud Spanner örneği (GKE Autopilot kümesi) sağladınız.

Ayrıca arka uç hizmetleri ve iş yükleri için iki Cloud Deploy ardışık düzeninin yanı sıra derlenen görüntüleri depolamak için bir Artifact Registry deposu oluşturuldu.

Son olarak, hizmet hesapları oluşturuldu ve arka uç hizmetlerinin Cloud Spanner'ı kullanabilmesi için Workload Identity ile çalışacak şekilde yapılandırıldı.

Ayrıca, arka uç hizmetlerini ve iş yüklerini dağıttıktan sonra Cloud Shell'de GKE kümesiyle etkileşim kuracak şekilde yapılandırılmış kubectl var.

Sıradaki

Hizmetleri kullanabilmeniz için veritabanı şemasının tanımlanması gerekir. İlgili hesabı bir sonraki adımda ayarlayacaksınız.

4. Veritabanı şemasını oluşturma

Genel Bakış

Arka uç hizmetlerini çalıştırmadan önce veritabanı şemasının yerinde olduğundan emin olmanız gerekir.

Demo deposundaki $DEMO_HOME/schema/migrations dizinindeki dosyalara bakarsanız şemamızı tanımlayan bir dizi .sql dosyası görürsünüz. Bu, şema değişikliklerinin deponun kendisinde izlendiği ve uygulamaların belirli özellikleriyle ilişkilendirilebildiği bir geliştirme döngüsünü taklit eder.

Bu örnek ortamda İngiliz anahtarı, Cloud Build'i kullanarak şema taşıma işlemlerimizi uygulayacak araçtır.

Cloud Build

$DEMO_HOME/schema/cloudbuild.yaml dosyasında hangi adımların uygulanacağı açıklanmaktadır:

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

Temelde iki adım vardır:

• Cloud Build çalışma alanına İngiliz anahtarı indirin
• ingiliz anahtarı taşıma işlemini çalıştırma

İngiliz anahtarının yazma uç noktasına bağlanması için Spanner projesi, örnek ve veritabanı ortamı değişkenleri gereklidir.

Cloud Build, cloudbuild-cicd@${PROJECT_ID}.iam.gserviceaccount.com hizmet hesabı olarak çalıştığı için şu değişiklikleri yapabilir:

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

Ayrıca bu hizmet hesabına Terraform tarafından eklenen spanner.databaseUser rolü bulunmaktadır. Bu rol, hizmet hesabının güncelleme DDL'sini güncellemesine olanak tanır.

Şema taşıma işlemleri

$DEMO_HOME/schema/migrations dizinindeki dosyalar temel alınarak gerçekleştirilen beş taşıma adımı vardır. players tablosu oluşturan ve dizine ekleyen 000001.sql dosyasının bir örneğini aşağıda bulabilirsiniz:

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);

Şema taşıma işlemini gönderme

Şema taşıma işlemini gerçekleştirmek üzere derlemeyi göndermek için schema dizinine geçin ve aşağıdaki gcloud komutunu çalıştırın:

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

Komut çıkışı

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

Not: Şema taşıma işleminin dağıtılması birkaç dakika sürer

Yukarıdaki çıkışta Created bulut derleme işleminin bağlantısı gösterilir. Bu düğmeyi tıklarsanız derlemenin ilerleme durumunu izleyebilmeniz ve ne yaptığını görebilmeniz için Cloud Console'da derlemeye yönlendirilirsiniz.

Not: Taşıma işlemi adımları, $DEMO_HOME/schema/migrations dizinindeki dosya sayısıyla eşleşmektedir.

Özet

Bu adımda, 5 farklı DDL işlemi uygulayan ilk şema taşıma işlemini göndermek için Cloud Build'i kullandınız. Bu işlemler, veritabanı şemasında değişiklik gerektiren özelliklerin ne zaman eklendiğini gösterir.

Normal bir geliştirme senaryosunda, kesintileri önlemek için şema değişikliklerini mevcut uygulamayla geriye dönük uyumlu hale getirmek istersiniz.

Geriye dönük uyumlu olmayan değişikliklerde, kesinti olmaması için değişiklikleri uygulama ve şemaya aşamalı olarak dağıtmanız önerilir.

Sıradaki

Şema hazır olduğunda bir sonraki adım arka uç hizmetlerini dağıtmaktır.

5. Arka uç hizmetlerini dağıtma

Genel Bakış

Bu codelab için arka uç hizmetleri, dört farklı hizmeti temsil eden golang REST API'leridir:

• Profil: Oyunculara örnek "oyunumuz"a kaydolma ve kimlik doğrulama imkanı sunar.
• Eşleştirme: Eşleştirme işlevine yardımcı olmak için oyuncu verileriyle etkileşimde bulunabilir, oluşturulan oyunlarla ilgili bilgileri takip edebilir ve maçlar kapatıldığında oyuncu istatistiklerini güncelleyebilirsiniz.
• Öğe: Oyuncuların bir oyun oynayarak oyun öğeleri ve para kazanmalarını sağlar.
• Tradepost: Oyuncuların belirli bir mağazada ürün alıp satmasını sağlar.

Cloud Spanner Oyun Geliştirmeye Başlama codelab'inde bu hizmetler hakkında daha fazla bilgi edinebilirsiniz. Amaçlarımız doğrultusunda bu hizmetlerin GKE Autopilot kümemizde çalışmasını istiyoruz.

Bu hizmetler Spanner verilerini değiştirebilmelidir. Bunun için her hizmetin, kendisine "databaseUser" (veritabanı Kullanıcısı) izni veren bir hizmet hesabı olur çok önemlidir.

Workload Identity, bir Kubernetes hizmet hesabının hizmetlerin kimliğine bürünmesine olanak tanır google cloud hizmet hesabı için aşağıdaki adımları uygulayın:

• Hizmetin Google Cloud hizmet hesabı (GSA) kaynağını oluşturma
• Bu hizmet hesabına databaseUser rolünü atayın
• Bu hizmet hesabına workloadIdentityUser rolünü atayın.
• GSA'ya referans veren bir Kubernetes hizmet hesabı (KSA) oluşturun

Kaba bir diyagram şöyle görünür:

Not: İzinleri ayırmak ve En Az Ayrıcalık İlkesini uygulamak için her hizmetin kendi GSA ve KSA'sı vardır.

Terraform, hizmet hesaplarını ve Kubernetes hizmet hesaplarını sizin için oluşturdu. Ayrıca, kubectl kullanarak Kubernetes hizmet hesaplarını kontrol edebilirsiniz:

# 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

Derlemenin çalışma şekli şöyledir:

• Terraform, şuna benzer bir $DEMO_HOME/backend_services/cloudbuild.yaml dosyası oluşturdu:

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

• Cloud Build komutu bu dosyayı okur ve listelenen adımları uygular. İlk olarak hizmet görüntülerini oluşturur. Ardından bir gcloud deploy create komutu yürütür. Bu komut, her bir dağıtım dosyasının bulunduğu yeri tanımlayan $DEMO_HOME/backend_services/skaffold.yaml dosyasını okur:

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, her bir hizmetin deployment.yaml dosyasının tanımlarını izler. Hizmetin dağıtım dosyası, hizmet (bu örnekte 80 numaralı bağlantı noktasında çalışan bir kümeIP) oluşturma bilgilerini içerir.

" ClusterIP" türü, arka uç hizmet kapsüllerinin harici IP'ye sahip olmasını engeller. Böylece, yalnızca dahili GKE ağına bağlanabilen varlıklar arka uç hizmetlerine erişebilir. Bu hizmetler, Spanner verilerine erişip bunları değiştirdikleri için oyuncular tarafından doğrudan erişilememelidir.

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

Örnek: $DEMO_HOME/backend_services/profile/deployment.yaml

Cloud Deploy, Kubernetes hizmeti oluşturmanın yanı sıra Kubernetes dağıtımı da oluşturur. profile hizmetinin dağıtım bölümünü inceleyelim:

---
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"

Üst bölümde, hizmetle ilgili bazı meta veriler yer alır. Bu sürecin en önemli adımı, bu dağıtımın kaç replika oluşturacağını belirlemektir.

replicas: 2 # EDIT: Number of instances of deployment

Ardından, uygulamayı hangi hizmet hesabının çalıştırması ve hangi görüntüyü kullanması gerektiğini belirleriz. Bunlar, Terraform'dan oluşturulan Kubernetes hizmet hesabı ve Cloud Build adımında oluşturulan görüntü ile eşleşir.

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

Ardından, ağ iletişimi ve ortam değişkenleriyle ilgili bazı bilgileri belirtiriz.

spanner_config, uygulamanın Spanner'a bağlanması için gereken proje, örnek ve veritabanı bilgilerini belirten bir Kubernetes ConfigMap'tir.

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

Not: spanner_config.yaml dosyası, Terraform tarafından files/backend_services/spanner-config.yaml.tpl temel alınarak oluşturulur.

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

SERVICE_HOST ve SERVICE_PORT, hizmetin nereye bağlanacağını bilmek için ihtiyaç duyduğu ek ortam değişkenleridir.

Son bölümde, GKE'ye bu dağıtımdaki her bir replika için kaç kaynağa izin verileceği belirtilir. GKE Autopilot de kümeyi ihtiyaca göre ölçeklendirmek için bu yöntemi kullanır.

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

Bu bilgiler ışığında, arka uç hizmetlerini dağıtma zamanı gelmiş demektir.

Arka uç hizmetlerini dağıtma

Bahsedildiği gibi, arka uç hizmetlerinin dağıtımı Cloud Build'den yararlanır. Şema taşıma işlemlerinde olduğu gibi, derleme isteğini gcloud komut satırını kullanarak gönderebilirsiniz:

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

Komut çıkışı

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

Not: Derleme ve dağıtımın tamamlanması birkaç dakika sürer.

schema migration adımının çıkışının aksine, bu derlemenin çıkışı bazı görüntülerin oluşturulduğunu gösterir. Bu mesajlar Artifact Registry deponuzda saklanır.

gcloud build adımının sonucunda Cloud Console'a bağlantı yer alır. Bunlara bir göz atın.

Not: Cloud Build'den BAŞARILI mesajı alsanız bile kapsüller çalıştırılana kadar dağıtım tamamlanmaz.

Cloud Build'den başarı bildirimini aldıktan sonra Cloud Deploy'a ve ardından sample-game-services ardışık düzenine giderek dağıtımın ilerleme durumunu izleyin.

Hizmetler dağıtıldıktan sonra kubectl adresini kontrol ederek kapsüllerin durum:

kubectl get pods

Komut çıkışı

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

Ardından, ClusterIP hizmetinin nasıl çalıştığını görmek için hizmetleri kontrol edin:

kubectl get services

Komut çıkışı

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

Not: Arka uç hizmetlerine API'lere dışarıdan erişimi önlemek için atanmış bir Harici IP yoktur.

Ayrıca Cloud Console'da GKE kullanıcı arayüzüne giderek Workloads, Services ve ConfigMaps verilerini görebilirsiniz.

İş Yükleri

Hizmetler

ConfigMaps

Özet

Bu adımda dört arka uç hizmetini GKE Autopilot'a dağıttınız. Cloud Build adımını çalıştırdınız ve Cloud Deploy ile Kubernetes'teki ilerleme durumunu Cloud Console'da kontrol ettiniz.

Ayrıca bu hizmetlerin, Spanner veritabanında veri okumak ve yazmak için doğru izinlere sahip bir hizmet hesabının kimliğine bürünmek amacıyla Workload Identity'yi nasıl kullandığını öğrendiniz.

Sonraki Adımlar

Bir sonraki bölümde iş yüklerini dağıtacaksınız.

6. İş yüklerini dağıtma

Genel Bakış

Artık arka uç hizmetleri kümede çalıştığına göre iş yüklerini dağıtabilirsiniz.

İş yüklerine harici olarak erişilebilir. Bu codelab'in amacına uygun olarak her arka uç hizmeti için bir iş yükü bulunmaktadır.

Bu iş yükleri, bu örnek hizmetlerin beklediği gerçek erişim kalıplarını taklit eden Locust tabanlı yük oluşturma komut dosyalarıdır.

Cloud Build işlemi için bazı dosyalar vardır:

• $DEMO_HOME/workloads/cloudbuild.yaml (Terraform tarafından oluşturuldu)
• $DEMO_HOME/workloads/skaffold.yaml
• Her iş yükü için bir deployment.yaml dosyası

cloudbuild.yaml ve skaffold.yaml dosyasını inceleyebilirsiniz. Görüntü adları ve dizinler farklı olsa da arka uç hizmetleriyle hemen hemen aynıdır.

İş yükü deployment.yaml dosyaları, arka uç hizmeti dağıtım dosyalarından biraz farklı görünür.

matchmaking-workload alanından bir örnek aşağıda verilmiştir:

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"

Dosyanın üst kısmı hizmeti tanımlar. Bu durumda, bir LoadBalancer oluşturulur ve iş yükü 8089 bağlantı noktasında çalışır.

LoadBalancer, iş yüküne bağlanmak için kullanılabilecek harici bir IP sağlar.

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

Dağıtım bölümünün en üstünde iş yüküyle ilgili meta veriler bulunur. Bu durumda yalnızca bir replika dağıtılmaktadır:

replicas: 1 

Ancak container spesifikasyonları farklıdır. Öncelikle default Kubernetes hizmet hesabı kullanıyoruz. İş yükünün GKE kümesinde çalışan arka uç hizmetleri hariç herhangi bir Google Cloud kaynağına bağlanması gerekmediği için bu hesap özel bir ayrıcalığa sahip değil.

Diğer fark ise bu iş yükleri için gereken ortam değişkeni bulunmamasıdır. Sonuç olarak daha kısa bir dağıtım spesifikasyonu elde edilir.

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

Kaynak ayarları arka uç hizmetlerine benzer. GKE Autopilot'ın, kümede çalışan tüm kapsüllerin isteklerini karşılamak için kaç kaynak gerektiğini bu şekilde bildiğini unutmayın.

Devam edin ve iş yüklerini dağıtın.

İş yüklerini dağıtma

Daha önce olduğu gibi, derleme isteğini gcloud komut satırını kullanarak gönderebilirsiniz:

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

Komut çıkışı

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

Not: Derleme ve dağıtımın tamamlanması birkaç dakika sürer.

Durumu kontrol etmek için Cloud Console'daki Cloud Build günlüklerini ve Cloud Deploy ardışık düzenini kontrol etmeyi unutmayın. İş yükleri için Cloud Deploy ardışık düzeni sample-game-workloads şeklindedir:

Dağıtım tamamlandıktan sonra Cloud Shell'de durumu kubectl ile kontrol edin:

kubectl get pods

Komut çıkışı

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

Ardından, LoadBalancer öğesinin nasıl çalıştığını görmek için iş yükü hizmetlerini kontrol edin:

kubectl get services 

Komut çıkışı

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

Not: Arka uç hizmetlerinden farklı olarak iş yüklerine harici IP adresleri atanmıştır.

Özet

İş yüklerini GKE kümesine dağıttınız. Bu iş yükleri için ek IAM izni gerekmez ve LoadBalancer hizmeti kullanılarak 8089 numaralı bağlantı noktasında harici olarak erişilebilir.

Sonraki Adımlar

Arka uç hizmetleri ve iş yükleri çalışırken "oynatma" zamanı geldi bir yarışmamız var!

7. Oyunu oynamaya başlayın

Genel Bakış

Örnek "oyununuz" için arka uç hizmetleri ve aynı zamanda kullanıcılar "oyuncu" oluşturmak için bu hizmetlerle nasıl etkileşime geçeceğini açıklayacağım.

Her bir iş yükü, hizmet API'lerimize göre gerçek yükü simüle etmek için Locust aracını kullanır. Bu adımda, GKE kümesinde ve Spanner'da yük oluşturmak ve Spanner'da veri depolamak için iş yüklerinden birkaçını çalıştıracaksınız.

Her bir iş yükünün açıklamasını aşağıda bulabilirsiniz:

• item-generator iş yükü, oyuncuların "playing" (oyun) aracılığıyla edinebileceği game_items öğelerinin listesini oluşturan hızlı bir iş yüküdür. sorumluluklar var.
• profile-workload, kaydolup giriş yapan oyuncuları simüle eder.
• matchmaking-workload, oyunlara atanmak için sıraya giren oyuncuları simüle eder.
• game-workload, oyunu oynarken game_items ve para kazanan oyuncuları simüle eder.
• tradepost-workload, oyuncuların takas yayınında ürün satıp satın alabileceğini simüle eder.

Not: Bu Locust oluşturma araçlarının işleyiş şekli hakkında daha fazla bilgi edinmek istiyorsanız Cloud Spanner Oyun Geliştirmeye Başlama codelab'ine göz atabilirsiniz.

Bu codelab'de özellikle item-generator ve profile-workload çalıştırılması vurgulanır.

Öğe oluşturucuyu çalıştırma

item-generator, Spanner'a game_items eklemek için item arka uç hizmeti uç noktasını kullanır. Bu öğeler, game-workload ve tradepost-workload özelliklerinin düzgün çalışması için gereklidir.

İlk adım, item-generator hizmetinin harici IP'sini almaktır. Cloud Shell'de aşağıdaki komutu çalıştırın:

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

Komut çıkışı

{ITEMGENERATOR_EXTERNAL_IP}

Şimdi yeni bir tarayıcı sekmesi açın ve sekmeyi http://{ITEMGENERATOR_EXTERNAL_IP}:8089 adresine yönlendirin. Şuna benzer bir sayfa alırsınız:

users ve spawn öğelerini varsayılan 1 değerinde bırakacaksınız. host, için http://item girin. Gelişmiş seçenekleri tıklayın ve çalışma süresi için 10s girin.

Yapılandırma aşağıdaki gibi görünür:

Not: İş yükleri ve arka uç hizmetleri aynı GKE kümesinde yer aldığından, hizmet adı için DNS çözümlemesini kullanarak birbirlerini keşfedebilirler. Bu nedenle http://item ana makine adına başvurabilirsiniz.

"Yararlanmaya başla"yı tıklayın.

POST /items uç noktasında yayınlanan isteklerle ilgili istatistikler gösterilmeye başlar. 10 saniye sonra yükleme durdurulur.

Charts simgesini tıkladığınızda bu isteklerin performansına ilişkin bazı grafikler görürsünüz.

Şimdi, verilerin Spanner veritabanına girilip girilmediğini kontrol etmek istiyorsunuz.

Bunun için hamburger menüyü tıklayın ve "Spanner"a gidin. Bu sayfadan sample-instance ve sample-database'ne gidin. Ardından "Query" seçeneğini tıklayın.

game_items sayısını seçmek istiyoruz:

game_items öğesinden COUNT(*) SELECT;

Alt kısımda sonucu görürsünüz.

Not: game_items öğelerinin tam sayısı eşleşmeyebilir. Sorun değil.

Çok fazla game_items başlangıç noktası gerekmiyor. Ama artık oyuncular da bunları edinebilir.

Profil iş yükünü çalıştırma

game_items başlangıç noktanızla bir sonraki adım oyuncularınızın oyun oynayabilmeleri için kaydolmalarını sağlamaktır.

profile-workload; hesap oluşturan, giriş yapan, profil bilgilerini alan ve çıkış yapan oyuncuları simüle etmek için Locust'u kullanacaktır. Bunların tümü, üretim benzeri tipik bir iş yükünde profile arka uç hizmetinin uç noktalarını test eder.

Bunu çalıştırmak için profile-workload harici IP'sini alın:

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

Komut çıkışı

{PROFILEWORKLOAD_EXTERNAL_IP}

Şimdi yeni bir tarayıcı sekmesi açın ve sekmeyi http://{PROFILEWORKLOAD_EXTERNAL_IP}:8089 adresine yönlendirin. Öncekine benzer bir Locust sayfası elde edersiniz.

Bu durumda, ana makine için http://profile kullanacaksınız. Ayrıca gelişmiş seçeneklerde bir çalışma zamanı belirtmezsiniz. Ayrıca, users değerini 4 olarak belirtin. Bu değer, tek seferde 4 kullanıcı isteğini simüle eder.

profile-workload testi aşağıdaki gibi görünecektir:

"Yararlanmaya başla"yı tıklayın.

Daha önce olduğu gibi, çeşitli profile REST uç noktalarının istatistikleri gösterilmeye başlar. Her şeyin ne kadar iyi performans gösterdiğini görmek için grafikleri tıklayın.

Not: profile-workload uygulamasını çalışır durumda bırakın. Bir sonraki bölümde GKE ve Cloud Spanner'ın performansını kontrol edebileceksiniz.

Özet

Bu adımda bazı game_items oluşturdunuz ve ardından Cloud Console'da Spanner Sorgu kullanıcı arayüzünü kullanarak game_items tablosunu sorguladınız.

Ayrıca oyuncuların oyununuza kaydolmalarına izin verdiniz ve Locust'un arka uç hizmetlerinizde üretime benzer iş yükleri nasıl oluşturabildiğini gördünüz.

Sonraki Adımlar

İş yüklerini çalıştırdıktan sonra GKE kümesinin ve Spanner örneğinin nasıl çalıştığını kontrol etmeniz gerekir.

8. GKE ve Spanner kullanımını inceleme

Profil hizmeti çalışırken GKE Autopilot kümenizin ve Cloud Spanner'ın nasıl işlediğini incelemenin zamanı geldi.

GKE kümesini kontrol etme

Kubernetes kümesine gidin. İş yüklerini ve hizmetleri dağıttığınız için kümeye toplam vCPU ve bellek hakkında bazı ayrıntılar eklendiğini görürsünüz. Kümede herhangi bir iş yükü olmadığında bu bilgiler kullanılamıyordu.

Şimdi sample-game-gke kümesini tıklayın ve gözlemlenebilirlik sekmesine geçin:

İş yüklerimiz ve arka uç hizmetlerimiz default üzerinde çalıştığı için default Kubernetes ad alanı, CPU kullanımı için kube-system ad alanını aşmalıydı. Başlamadıysa profile workload öğesinin hâlâ çalıştığından emin olun ve grafiklerin güncellenmesi için birkaç dakika bekleyin.

Hangi iş yüklerinin en çok kaynak kullandığını görmek için Workloads kontrol paneline gidin.

Her iş yüküne ayrı ayrı girmek yerine doğrudan kontrol panelindeki Gözlemlenebilirlik sekmesine gidin. profile ve profile-workload CPU'nun arttığını göreceksiniz.

Şimdi Cloud Spanner'ı kontrol edin.

Cloud Spanner örneğini kontrol etme

Cloud Spanner'ın performansını kontrol etmek için Spanner'a gidip sample-instance örneği ve sample-game veritabanını tıklayın.

Buradan, soldaki menüde Sistem Analizleri sekmesini görürsünüz:

CPU utilization, transaction latency and locking ve query throughput dahil olmak üzere Spanner örneğinizin genel performansını anlamanıza yardımcı olacak birçok grafik vardır.

Sistem Analizleri'nin yanı sıra, Gözlemlenebilirlik bölümündeki diğer bağlantılara göz atarak sorgu iş yükü hakkında daha ayrıntılı bilgi edinebilirsiniz:

• Sorgu analizleri, Spanner'da kaynakları kullanan en iyi N sorguyu belirlemeye yardımcı olur.
• İşlem ve Kilit analizleri, yüksek gecikmeli işlemleri tespit etmenize yardımcı olur.
• Key Visualizer, erişim kalıplarının görselleştirilmesine ve verilerdeki hotspot'ların tespit edilmesine yardımcı olur.

Özet

Bu adımda hem GKE Autopilot hem de Spanner için bazı temel performans metriklerini nasıl kontrol edeceğinizi öğrendiniz.

Örneğin, profilinizdeki iş yükü çalışırken oynatıcılar tablosunu sorgulayarak orada depolanan veriler hakkında daha fazla bilgi edinebilirsiniz.

Devam etmeden önce hizmetleri tanımak için hem GKE hem de Spanner'da mevcut olan bilgileri inceleyin.

Sonraki Adımlar

Şimdi de temizlik zamanı.

9. Temizleme

Temizlemeden önce kapsama dahil olmayan diğer iş yüklerini inceleyebilirsiniz. Özellikle matchmaking-workload, game-workload ve tradepost-workload.

"Çalmayı" bitirdiğinizde oyun parkını düzenleyebilirsiniz. Neyse ki bu oldukça kolay.

İlk olarak, profile-workload cihazınız tarayıcınızda hâlâ çalışıyorsa kontrol edin ve durdurun:

Test ettiğiniz her iş yükü için aynı adımları uygulayın.

Ardından Cloud Shell'de altyapı klasörüne gidin. Terraform kullanarak altyapıyı destroy:

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

Komut çıkışı

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.

Not: Altyapının tamamen kaldırılması birkaç dakika sürer.

Cloud Console'da tüm kaynakların kaldırıldığını doğrulamak için Spanner, Kubernetes Cluster, Artifact Registry, Cloud Deploy ve IAM sürümlerine gidin.

10. Tebrikler!

Tebrikler, örnek golang uygulamalarını GKE Autopilot'ta başarıyla dağıttınız ve Workload Identity kullanarak Cloud Spanner'a bağladınız.

Bunun yanı sıra bu altyapı, Terraform kullanılarak tekrarlanabilir bir şekilde kolayca kurup kaldırıldı.

Etkileşim kurduğunuz Google Cloud hizmetleri hakkında daha fazla bilgiyi bu codelab'de bulabilirsiniz:

• GKE Autopilot ve İş Yükü Kimliği
• Cloud Spanner
• Artifact Registry
• Cloud Build ve Cloud Deploy

Sırada ne var?

Artık GKE Autopilot ve Cloud Spanner'ın nasıl birlikte çalışabileceğine dair temel bilgilere sahip olduğunuza göre bir sonraki adımı atıp bu hizmetlerle çalışmak için kendi uygulamanızı derlemeye ne dersiniz?