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 anlamları 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 bir işlem modudur. Bu modda Google, en iyi uygulamaları takip etmek için düğümleriniz, ölçeklendirme, güvenlik ve önceden yapılandırılmış diğer ayarlar dahil olmak üzere küme yapılandırmanızı yönetir. Örneğin, GKE Autopilot, hizmet izinlerini yönetmek için Workload Identity'yi 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şlem tamamlandığında, Games veritabanı için ilk şema taşıma işlemini gerçekleştirmek, arka uç hizmetlerini dağıtmak ve ardından iş yüklerini dağıtmak üzere Cloud Build ve Cloud Deploy ile etkileşimde bulunacaksınız.

Bu codelab'deki hizmetler, Cloud Spanner ile Oyun Geliştirmeye Başlama codelab'indeki hizmetlerle aynıdır. Bu codelab'i tamamlamak, hizmetlerin GKE'de çalıştırılması ve Spanner'a bağlanması için gerekli değildir. Ancak Spanner'da çalışan bu hizmetlerin ayrıntıları hakkında daha fazla bilgi edinmek istiyorsanız inceleyebilirsiniz.

İş 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.

Ne oluşturacaksınız?

Bu laboratuvar kapsamında şunları yapacaksınız:

• Terraform kullanarak altyapıyı sağlama
• 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ğıtın.
• Arka uç hizmetleri için yükü simüle etmek amacıyla 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üzenlerini sağlama
• Workload Identity, GKE'deki hizmetlerin Cloud Spanner ile çalışmak için IAM izinlerine erişmek üzere hizmet hesaplarını taklit etmesine nasıl olanak tanır?
• Locust.io kullanarak GKE ve Cloud Spanner'da üretime benzer yük oluşturma

İhtiyacınız olanlar

• Bir faturalandırma hesabına bağlı olan 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şiklik yapar. Bu codelab için özel bir proje oluşturmanız önemle tavsiye edilir.

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

Önceden oluşturduğunuz bir projeniz varsa konsolun sol üst kısmındaki proje seçimi açılır menüsünü tıklayın:

ve yeni bir proje oluşturmak için açılan iletişim kutusunda "YENİ PROJE" düğmesini tıklayın:

Henüz bir projeniz yoksa ilk projenizi oluşturmak için aşağıdaki gibi bir iletişim kutusu görürsünüz:

Sonraki proje oluşturma iletişim kutusunda yeni projenizin ayrıntılarını girebilirsiniz:

Tüm Google Cloud projelerinde benzersiz bir ad olan proje kimliğini unutmayın (Yukarıdaki ad zaten alınmış olduğundan sizin için çalışmayacaktır). Bu codelab'in ilerleyen kısımlarında PROJECT_ID olarak adlandırılacaktır.

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

Bu codelab'i tamamlamak size birkaç dolardan fazla maliyet getirmemelidir. Ancak daha fazla kaynak kullanmaya veya kaynakları çalışır durumda bırakmaya karar verirseniz maliyet artabilir (bu belgenin sonundaki "temizleme" bölümüne bakın). Google Cloud Spanner fiyatlandırması burada, GKE Autopilot ise burada belgelenmiştir.

Google Cloud Platform'un yeni kullanıcıları, bu codelab'i tamamen ücretsiz hale getirecek 300 ABD doları değerinde ücretsiz deneme sürümünden yararlanabilir.

Cloud Shell kurulumu

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

Bu Debian tabanlı sanal makine, ihtiyaç duyacağınız tüm geliştirme araçlarını içerir. 5 GB boyutunda kalıcı bir ana dizin bulunur ve Google Cloud'da çalışır. Bu sayede ağ performansı ve kimlik doğrulama önemli ölçüde güçlenir. Bu nedenle, bu codelab için ihtiyacınız olan tek şey bir tarayıcıdır (Chromebook'ta da çalışır).

1. Cloud Shell'i Cloud Console'dan etkinleştirmek için Cloud Shell'i Etkinleştir'i tıklamanız yeterlidir (ortamın sağlanması ve bağlantının kurulması yalnızca birkaç saniye sürer).

Cloud Shell'e bağlandıktan sonra kimliğinizin doğrulandığını ve projenin, PROJECT_ID'nize ayarlandığını görürsünüz.

gcloud auth list

Komut çıkışı

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

Not: gcloud komut satırı aracı, Cloud Shell'de önceden yüklenmiş 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 verin:

gcloud config set project <PROJECT_ID>

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

Cloud Shell, gelecekteki komutları çalıştırırken faydalı olabilecek bazı ortam değişkenlerini de varsayılan olarak ayarlar.

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üne dayanmaktadı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ıyı sağlayacaksınız.

3. Altyapı sağlama

Genel Bakış

Projeniz hazır olduğunda altyapıyı çalıştırma zamanı gelir. Buna VPC ağı, Cloud Spanner, GKE Autopilot, GKE'de çalışacak görüntüleri depolamak için Artifact Registry, arka uç hizmetleri ve iş yükleri için Cloud Deploy işlem hatları ve son olarak bu hizmetleri kullanabilmek için hizmet hesapları ve IAM ayrıcalıkları dahildir.

Çok fazla. Ancak neyse ki Terraform bu kurulumu kolaylaştırabilir. Terraform, bu proje için neye ihtiyacımız olduğunu bir dizi ".tf" dosyasında belirtmemize olanak tanıyan bir "Kod Olarak Altyapı" aracıdır. Bu sayede altyapı sağlama işlemi kolaylaşır.

Bu codelab'i tamamlamak için Terraform'a aşina olmanız gerekmez. Ancak sonraki birkaç adımda neler yapıldığını görmek isterseniz infrastructure dizininde bulunan bu dosyalarda neler oluşturulduğuna bakabilirsiniz:

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

Terraform'u yapılandırma

Cloud Shell'de infrastructure dizinine geçip Terraform'u başlatacaksı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ızda çalışması için yalnızca projenin 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: Varsayılan değişkenler kullanıldığında altyapı, us-central1 bölgesinde dağıtılır.

Altyapıyı sağlama

Uyarı: Bu adım, projenizde değişiklikler yapar. Önceden oluşturulmuş bir projeyi kullanıyorsanız bu durum istenmeyen sonuçlara yol açabilir. Bu codelab için özel bir proje oluşturmanız önemle tavsiye edilir.

Artık altyapıyı sağlama zamanı!

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 ayarlanması birkaç dakika sürer.

Not: Kubernetes default_secret_name'in desteğinin sonlandırıldığına dair bir not alabilirsiniz. Bu uyarıyı yoksayabilirsiniz.

Oluşturulan içeriği kontrol etme

Oluşturulanları doğrulamak için Cloud Console'daki ürünleri kontrol etmeniz gerekir.

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

Cloud Spanner

Öncelikle hamburger menüsüne gidip Spanner simgesini tıklayarak Cloud Spanner'ı kontrol edin. Listede bulmak için "Daha fazla ürün göster"i tıklamanız gerekebilir.

Bu işlem sizi Spanner örneklerinin listesine yönlendirir. Örneği tıkladığınızda veritabanlarını görürsünüz. Şuna benzer bir görünümde olacaktır:

Not: Bunun, ABD-merkez bölgesel yapılandırmasıyla 100 işleme biriminde (100 PU) çalışan ayrıntılı bir örnek olduğunu görürsünüz.

GKE Autopilot

Ardından, hamburger menüye gidip Kubernetes Engine => Clusters simgesini tıklayarak GKE'yi inceleyin. Burada, Autopilot modunda çalışan sample-games-gke kümesini görürsünüz.

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

Artifact Registry

Şimdi de resimlerin nerede saklanacağını görmek isteyeceksiniz. Bu nedenle, hamburger menüyü tıklayıp Artifact Registry=>Repositories simgesini bulun. Artifact Registry, menünün CI/CD bölümünde yer alır.

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

Cloud Deploy

Cloud Deploy, Cloud Build'in görüntüleri oluşturmak için adımlar sağlayıp bunları GKE kümemize dağıtabilmesi amacıyla işlem hatlarının oluşturulduğu yerdir.

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

Burada iki işlem hattı görürsünüz: biri arka uç hizmetleri, diğeri ise iş yükleri için. Her ikisi de görüntüleri aynı GKE kümesine dağıtır ancak bu, dağıtımlarımızı ayırmamıza olanak tanır.

IAM ile yönetin.

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 simgesini bulun. Şuna benzer bir görünümde olacaktır:

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

• Varsayılan Compute hizmet hesabı. Bu codelab'de kullanılmamaktadır.
• cloudbuild-cicd hesabı, Cloud Build ve Cloud Deploy adımları için kullanılır.
• Arka uç hizmetlerimizin Cloud Spanner ile etkileşim kurmak için kullandığı dört "uygulama" hesabı.

Ardından, kubectl'yı GKE kümesiyle etkileşimde bulunacak şekilde yapılandırmanız gerekir.

kubectl'ı 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: Önemli olan, kubectl'ın kimlik doğrulama hakkında herhangi bir hata vermemesidir.

Özet

Mükemmel! Özel ağ için bir VPC'de Cloud Spanner örneği ve GKE Autopilot kümesi sağlayabildiniz.

Ayrıca, arka uç hizmetleri ve iş yükleri için iki Cloud Deploy işlem hattı ile derlenen görüntüleri depolamak üzere bir Artifact Registry deposu oluşturuldu.

Son olarak, arka uç hizmetlerinin Cloud Spanner'ı kullanabilmesi için hizmet hesapları oluşturuldu ve 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 kurmak için kubectl'yi yapılandırmış olmanız gerekir.

Sıradaki

Hizmetleri kullanabilmek için veritabanı şemasının tanımlanması gerekir. Bunu bir sonraki adımda ayarlayacaksınız.

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

Genel Bakış

Arka uç hizmetlerini çalıştırabilmek için veritabanı şemasının mevcut 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 doğrudan depoda izlendiği ve uygulamaların belirli özellikleriyle ilişkilendirilebildiği bir geliştirme döngüsünü taklit eder.

Bu örnek ortamda, Cloud Build'i kullanarak şema taşıma işlemlerimizi uygulayacak araç wrench'tir.

Cloud Build

$DEMO_HOME/schema/cloudbuild.yaml dosyası, hangi adımların atılacağını açıklar:

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

Temel olarak iki adım vardır:

• anahtarı Cloud Build çalışma alanına indirme
• Anahtar taşıma işlemini çalıştırma

Anahtarın yazma uç noktasına bağlanması için Spanner projesi, örneği ve veritabanı ortam değişkenleri gerekir.

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

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

Bu hizmet hesabına, Terraform tarafından spanner.databaseUser rolü eklenmiştir. Bu rol, hizmet hesabının DDL'yi güncellemesine olanak tanır.

Şema taşıma işlemleri

$DEMO_HOME/schema/migrations dizinindeki dosyalara göre beş taşıma adımı gerçekleştirilir. Aşağıda, players tablosu ve dizinleri oluşturan 000001.sql dosyası örneği verilmiştir:

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önderin

Şema taşıma işlemini gerçekleştirmek için derlemeyi göndermek üzere 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 çıktıda Created Cloud Build sürecine ait bir bağlantı olduğunu göreceksiniz. Bunu tıkladığınızda, derlemenin ilerleme durumunu izleyebilmeniz ve ne yaptığını görebilmeniz için Cloud Console'daki derlemeye yönlendirilirsiniz.

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

Özet

Bu adımda, 5 farklı DDL işlemini uygulayan ilk şema taşıma işlemini göndermek için Cloud Build'ü kullandınız. Bu işlemler, veritabanı şema değişiklikleri gerektiren özelliklerin eklendiği zamanları gösterir.

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

Geriye dönük uyumlu olmayan değişiklikler için kesinti olmaması amacıyla uygulama ve şemadaki değişiklikleri aşamalı olarak dağıtmanız gerekir.

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'deki arka uç hizmetleri, dört farklı hizmeti temsil eden golang REST API'leridir:

• Profil: Oyunculara örnek "oyunumuza" kaydolma ve kimlik doğrulama olanağı sunun.
• Maç eşleştirme: Maç eşleştirme işlevine yardımcı olmak, oluşturulan oyunlarla ilgili bilgileri izlemek ve oyunlar kapatıldığında oyuncu istatistiklerini güncellemek için oyuncu verileriyle etkileşimde bulunma.
• Öğe: Oyuncuların oyun oynarken oyun öğeleri ve para kazanmasını sağlar.
• Ticaret merkezi: Oyuncuların ticaret merkezinde öğe satın alıp satmasına olanak tanıyın.

Bu hizmetler hakkında daha fazla bilgiyi Cloud Spanner ile Oyun Geliştirmeye Başlama codelab'inde bulabilirsiniz. Bu hizmetlerin GKE Autopilot kümemizde çalışmasını istiyoruz.

Bu hizmetler, Spanner verilerini değiştirebilmelidir. Bunu yapmak için her hizmete "databaseUser" rolünü veren bir hizmet hesabı oluşturulur.

Workload Identity, Kubernetes hizmet hesabının Terraform'daki aşağıdaki adımları uygulayarak hizmetlerin Google Cloud hizmet hesabını taklit etmesine olanak tanır:

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

Kaba bir diyagram şu şekilde görünür:

Not: Her hizmetin, izinleri ayırmak ve en az ayrıcalık ilkesine uymak için kendi GSA'sı 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

Derleme şu şekilde çalışır:

• Terraform, aşağıdaki gibi 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 resimlerini oluşturur. Ardından gcloud deploy create komutunu yürütür. Bu, her dağıtım dosyasının nerede bulunduğunu 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 hizmetin deployment.yaml dosyasındaki tanımları izler. Hizmetin dağıtım dosyası, hizmet oluşturma bilgilerini içerir. Bu durumda, hizmet 80 numaralı bağlantı noktasında çalışan bir clusterIP'dir.

" ClusterIP" türü, arka uç hizmeti kapsüllerinin harici bir IP'ye sahip olmasını engeller. Bu nedenle, yalnızca dahili GKE ağına bağlanabilen öğeler arka uç hizmetlerine erişebilir. Bu hizmetler, Spanner verilerine erişip bunları değiştirdikleri için oyunculara doğrudan erişilebilir olmamalıdır.

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 kısımda hizmetle ilgili bazı meta veriler yer alır. Bu dağıtımın kaç kopya oluşturacağını tanımlamak, bu adımdaki en önemli kısımdır.

replicas: 2 # EDIT: Number of instances of deployment

Ardından, uygulamayı hangi hizmet hesabının çalıştıracağını ve hangi görüntünün kullanılacağını görüyoruz. Bunlar, Terraform'dan oluşturulan Kubernetes hizmet hesabıyla ve Cloud Build adımı sırasında oluşturulan resimle eşleşir.

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

Ardından, ağ iletişimi ve ortam değişkenleri hakkında bazı bilgiler belirtiriz.

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

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ı bilmesi için gereken ek ortam değişkenleridir.

Son bölüm, GKE'ye bu Dağıtımdaki her replika için kaç kaynağa izin verileceğini bildirir. GKE Autopilot da kümeyi gerektiği gibi ölçeklendirmek için bu metrikleri kullanır.

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

Bu bilgilerle birlikte arka uç hizmetlerini dağıtma zamanı geldi.

Arka uç hizmetlerini dağıtma

Belirtildiği gibi, arka uç hizmetlerinin dağıtımı için Cloud Build kullanılır. Şema taşımalarında olduğu gibi, gcloud komut satırını kullanarak derleme isteğini 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 çıktısının aksine, bu derlemenin çıktısı bazı resimlerin oluşturulduğunu gösteriyor. Bu öğeler, Artifact Registry deponuzda saklanır.

gcloud build adımının çıkışında Cloud Console'a giden bir bağlantı bulunur. Bunlara göz atın.

Not: Cloud Build'den BAŞARILI mesajı alsanız bile, pod'lar çalışana kadar dağıtım tamamlanmaz.

Cloud Build'den başarı bildirimi aldıktan sonra Cloud Deploy'e ve ardından dağıtımın ilerleme durumunu izlemek için sample-game-services işlem hattına gidin.

Hizmetler dağıtıldıktan sonra pod'ların durumunu görmek için kubectl bölümünü kontrol edebilirsiniz:

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 simgesinin nasıl kullanıldığı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: API'lere dışarıdan erişimi engellemek için arka uç hizmetlerine harici IP atanmaz.

Ayrıca Workloads, Services ve ConfigMaps değerlerini görmek için Cloud Console'daki GKE kullanıcı arayüzüne de gidebilirsiniz.

İş 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ırabildiniz ve Cloud Console'da Cloud Deploy ile Kubernetes'teki ilerleme durumunu kontrol edebildiniz.

Ayrıca bu hizmetlerin, Spanner veritabanına veri okuma ve yazma için doğru izinlere sahip bir hizmet hesabının kimliğine bürünmek üzere Workload Identity'yi nasıl kullandığını da öğrendiniz.

Sonraki Adımlar

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

6. İş yüklerini dağıtma

Genel Bakış

Arka uç hizmetleri kümede çalışmaya başladığına göre iş yüklerini dağıtabilirsiniz.

İş yüklerine harici olarak erişilebilir ve bu codelab için her arka uç hizmeti için bir iş yükü vardır.

Bu iş yükleri, örnek hizmetler tarafından beklenen gerçek erişim kalıplarını taklit eden Locust tabanlı yük oluşturma komut dosyalarıdır.

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

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

cloudbuild.yaml ve skaffold.yaml dosyalarına göz atabilirsiniz. Resim adları ve dizinleri farklı olsa da neredeyse arka uç hizmetleriyle aynıdır.

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

matchmaking-workload ile ilgili bir örneği aşağıda görebilirsiniz:

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 bir harici 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 yer alır. Bu durumda yalnızca bir replika dağıtılır:

replicas: 1 

Ancak kapsayıcı spesifikasyonu farklıdır. Örneğin, default Kubernetes hizmet hesabı kullanıyoruz. İş yükünün GKE kümesinde çalışan arka uç hizmetleri dışında herhangi bir Google Cloud kaynağına bağlanması gerekmediğinden bu hesabın özel ayrıcalıkları yoktur.

Diğer bir fark ise bu iş yükleri için herhangi bir ortam değişkeninin gerekmemesidir. 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'un, kümede çalışan tüm kapsüllerin isteklerini karşılamak için kaç kaynak gerektiğini bu şekilde bildiğini unutmayın.

İş yüklerini dağıtmaya başlayın.

İş yüklerini dağıtma

Daha önce olduğu gibi, gcloud komut satırını kullanarak derleme isteğini 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'da Cloud Build günlüklerini ve Cloud Deploy işlem hattını kontrol ettiğinizden emin olun. İş yükleri için Cloud Deploy ardışık düzeni sample-game-workloads:

Dağıtım tamamlandıktan sonra Cloud Shell'de kubectl ile durumu 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 iş başında 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: İş yüklerinin arka uç hizmetlerinden farklı olarak atanmış harici IP adresleri vardır.

Özet

Artık iş 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ından harici olarak erişilebilir.

Sonraki Adımlar

Arka uç hizmetleri ve iş yükleri çalışırken oyunu "oynama" zamanı geldi!

7. Oyunu oynamaya başlama

Genel Bakış

Örnek "oyununuzun" arka uç hizmetleri artık çalışıyor ve iş yüklerini kullanarak bu hizmetlerle etkileşim kuran "oyuncular" oluşturma olanağına da sahipsiniz.

Her iş yükü, hizmet API'lerimize karşı gerçek yükü simüle etmek için Locust'u kullanır. Bu adımda, GKE kümesinde ve Spanner'da yük oluşturmak için iş yüklerinin bir kısmını çalıştıracak ve Spanner'da veri depolayacaksınız.

Her iş yükünün açıklaması aşağıda verilmiştir:

• item-generator iş yükü, oyuncuların oyunu "oynarken" elde edebileceği game_items listesi oluşturmak için kullanılan hızlı bir iş yüküdür.
• profile-workload, oyuncuların kaydolmasını ve giriş yapmasını simüle eder.
• matchmaking-workload, oyuncuların oyunlara atanmak için sıraya girmesini simüle eder.
• game-workload, oyuncuların oyunu oynarken game_item ve para kazanmasını simüle eder.
• tradepost-workload, oyuncuların ticaret merkezinde öğe satıp satın alabilmesini simüle eder.

Not: Bu Locust oluşturucuların nasıl çalıştığı hakkında daha fazla bilgi edinmek istiyorsanız Cloud Spanner ile Oyun Geliştirmeye Başlama başlıklı codelab'i inceleyin.

Bu codelab'de özellikle item-generator ve profile-workload çalıştırma vurgulanacaktı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 doğru ç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 http://{ITEMGENERATOR_EXTERNAL_IP}:8089adresine gidin. Şuna benzer bir sayfa görürsünüz:

users ve spawn değerlerini varsayılan 1 olarak bırakın. host için http://item değerini girin. Gelişmiş seçenekleri tıklayın ve çalışma süresi için 10s girin.

Yapılandırma şu şekilde olmalıdır:

Not: İş yükleri ve arka uç hizmetleri aynı GKE kümesinde olduğundan, hizmet adı için DNS çözümlemesi kullanarak birbirlerini bulabilirler. Bu nedenle http://item ana makine adına başvurabilirsiniz.

"Start swarming"i (Toplu saldırıyı başlat) tıklayın.

İstatistikler, POST /items uç noktasında verilen istekler için gösterilmeye başlar. 10 saniye sonra yükleme durur.

Charts simgesini tıkladığınızda bu isteklerin performansıyla ilgili bazı grafikler görürsünüz.

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

Bunu yapmak için hamburger menüyü tıklayın ve "İngiliz anahtarı"na gidin. Bu sayfadan sample-instance ve sample-database bölümlerine gidin. Ardından "Query" simgesini tıklayın.

game_itemssayısını seçmek istiyoruz:

SELECT COUNT(*) FROM game_items;

En altta sonucunuzu görürsünüz.

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

Çok fazla game_items ekmemiz gerekmez. Ancak artık oyuncular bu kartları edinebilir.

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

game_items oluşturulduktan sonraki adım, oyuncuların oyun oynayabilmesi için kaydolmalarını sağlamaktır.

profile-workload, oyuncuların hesap oluşturma, giriş yapma, profil bilgilerini alma ve çıkış yapma işlemlerini simüle etmek için Locust'u kullanır. Bu testlerin tümü, tipik bir üretime benzer 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 http://{PROFILEWORKLOAD_EXTERNAL_IP}:8089adresine gidin. Öncekine benzer bir Locust sayfası görmeniz gerekir.

Bu durumda, ana makine için http://profile kullanırsınız. Ayrıca, gelişmiş seçeneklerde bir çalışma süresi belirtmezsiniz. Ayrıca, aynı anda 4 kullanıcı isteğini simüle edecek şekilde users değerini 4 olarak belirtin.

profile-workload testi şu şekilde görünmelidir:

"Start swarming"i (Toplu saldırıyı başlat) 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 çalışmaya devam etsin. Bir sonraki bölümde hem GKE hem de Cloud Spanner'ın performansını kontrol edebilirsiniz.

Özet

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

Ayrıca oyuncuların oyununuza kaydolmasına izin verdiniz ve Locust'un arka uç hizmetlerinize karşı üretime benzer iş yükleri 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 davrandığını kontrol etmek isteyeceksiniz.

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

Profil hizmeti çalışırken GKE Autopilot kümenizin ve Cloud Spanner'ın nasıl davrandığını görme fırsatını değerlendirmenin zamanı geldi.

GKE kümesini kontrol etme

Kubernetes kümesine gidin. İş yüklerini ve hizmetleri dağıttığınızdan beri kümeye toplam vCPU ve bellek hakkında bazı ayrıntılar eklendiğini unutmayın. Bu bilgiler, kümede iş yükü yokken 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ığından, default Kubernetes ad alanı, CPU kullanımı açısından kube-system ad alanını aşmış olmalıdır. Güncellenmediyse profile workload simgesinin çalışmaya devam ettiğinden emin olun ve grafiklerin güncellenmesi için birkaç dakika bekleyin.

En çok kaynağı hangi iş yüklerinin kullandığını görmek için Workloads kontrol paneline gidin.

Her iş yüküne ayrı ayrı gitmek yerine doğrudan kontrol panelinin Gözlemlenebilirlik sekmesine gidin. profile ve profile-workload CPU'nun arttığını görürsünüz.

Şimdi Cloud Spanner'ı kontrol edin.

Cloud Spanner örneğini kontrol etme

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

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

Burada, 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 bulunur.

Sistem Analizleri'ne ek olarak, 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'daki kaynakları kullanan ilk N sorguyu belirlemeye yardımcı olur.
• İşlem ve kilit analizleri, yüksek gecikme süresine sahip işlemleri belirlemeye yardımcı olur.
• Key Visualizer, erişim kalıplarını görselleştirmeye ve verilerdeki etkin noktaları bulmaya 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, profil iş yükünüz çalışırken players tablosunu sorgulayarak orada depolanan veriler hakkında daha fazla bilgi edinin.

Devam etmeden önce hizmetlere alışmak için hem GKE hem de Spanner ile ilgili mevcut bilgilere göz atın.

Sonraki Adımlar

Şimdi de temizleme işlemini yapın.

9. Temizleme

Temizliğe başlamadan önce, ele alınmayan diğer iş yüklerini inceleyebilirsiniz. Özellikle matchmaking-workload, game-workload ve tradepost-workload.

Oyunu "oynamayı" bitirdiğinizde oyun alanınızı temizleyebilirsiniz. Neyse ki bu işlem oldukça kolaydır.

Öncelikle, profile-workload tarayıcıda çalışıyorsa üzerine gelip durdurun:

Test etmiş olabileceğiniz her iş yükü için aynı işlemi yapın.

Ardından Cloud Shell'de altyapı klasörüne gidin. Terraform'u 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 Spanner, Kubernetes Cluster, Artifact Registry, Cloud Deploy ve IAM'e giderek tüm kaynakların kaldırıldığını doğrulayın.

10. Tebrikler!

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

Ayrıca bu altyapı, Terraform kullanılarak tekrarlanabilir bir şekilde kolayca kurulup kaldırıldı.

Bu codelab'de etkileşimde bulunduğunuz Google Cloud hizmetleri hakkında daha fazla bilgi edinebilirsiniz:

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

Sırada ne var?

GKE Autopilot ve Cloud Spanner'ın birlikte nasıl çalışabileceği hakkında temel bilgilere sahip olduğunuza göre, neden bir sonraki adıma geçip bu hizmetlerle çalışacak kendi uygulamanızı oluşturmaya başlamıyorsunuz?