Kubernetes'te (GKE veya kendi kümenizi getirme) AlloyDB Omni'yi dağıtma ve yönetme

1. Giriş

Bu codelab'de, AlloyDB Omni Kubernetes operatörünü (kapsayıcı düzenleyici) Google Kubernetes Engine (GKE) Autopilot kümesine veya kendi Kubernetes kümenize nasıl yükleyeceğinizi ve uçtan uca veritabanı yaşam döngüsü iş akışlarını ve kritik kullanıcı yolculuklarını (CUJ) nasıl yöneteceğinizi öğreneceksiniz.

AlloyDB Omni, şirket içi ortamlardan Google Cloud'a veya sınır bilişime kadar her yerde çalışacak şekilde tasarlanmış, indirilebilir bir AlloyDB sürümüdür. AlloyDB Omni, kapsayıcı düzenleyici sayesinde yüksek kullanılabilirlik, otomatik yük devretme, kendi kendini onarma, minimum kesinti süresiyle sıralı bakım, bağlantı havuzu oluşturma, otomatik yedekleme ve belirli bir noktadan önceyi kurtarma işlemlerini otomatikleştirir.

Ortam yolunuzu seçme

Bu codelab'i aşağıdaki iki yöntemden birini kullanarak tamamlayabilirsiniz:

  1. 1. yol: Google Cloud Hesabınız varsa (GKE Autopilot): Google Cloud Shell veya Google Cloud Console'u kullanarak tam olarak yönetilen bir GKE Autopilot kümesi sağlayın.
  2. 2. Yol: Google Cloud Hesabınız Yoksa (Kendi Kubernetes Kümenizi Getirin): İş istasyonunuzda kubectl ve helm yapılandırılmış mevcut bir Kubernetes kümesini (v1.21 veya sonraki sürümler) kullanın. Google Cloud hesabı veya gcloud CLI gerekmez.

Ön koşullar

  • Kubernetes kavramları (kubectl, Helm, Özel Kaynak Tanımları) hakkında temel bilgi
  • 1. yol için (Google Cloud / GKE Autopilot):
    • Faturalandırmanın etkin olduğu bir Google Cloud projesi.
    • Google Cloud Shell'e veya gcloud, kubectl ve helm ile yapılandırılmış bir iş istasyonuna erişim.
  • 2. yol için (Kendi Kubernetes kümenizi getirin):
    • Dinamik PersistentVolume temel hazırlığı için varsayılan StorageClass ile 1.21 veya sonraki sürümleri çalıştıran bir Kubernetes kümesi.
    • Cgroup v2 etkin (x86-64/AMD64) ve küme genelinde en az 8 vCPU ve 24 GiB ayrılabilir RAM'e sahip Linux çekirdeği 4.18+ çalıştıran çalışan düğümleri.
    • Kümenize bağlı kubectl ve helm ile yapılandırılmış bir iş istasyonu.

Neler öğreneceksiniz?

  • GKE Autopilot kümesi temel hazırlığı yapma (1. yol) veya mevcut bir Kubernetes kümesini doğrulama (2. yol)
  • Helm aracılığıyla cert-manager ve AlloyDB Omni Kubernetes operatörünü yükleme
  • Tek örnekli AlloyDB Omni'yi dağıtma DBCluster
  • Eşzamanlı bekleme sunucularıyla yüksek kullanılabilirlik (HA) için ölçeklendirme ve salt okuma bekleme özelliğini etkinleştirme
  • Yerel depo depolama alanına (ve isteğe bağlı olarak 1. yoldaki Google Cloud Storage'a) planlanmış otomatik yedeklemeleri yapılandırma
  • İsteğe bağlı yedeklemelerin nasıl yapılacağı ve verilerin önceki bir duruma geri yüklenmesinin nasıl doğrulanacağı
  • Yeni bir klonlanmış veritabanı kümesine belirli bir noktadan önceyi kurtarma (PITR) işlemi gerçekleştirme
  • İstemci bağlantısı ölçeklendirmesi için PgBouncer bağlantı havuzu oluşturma
  • Veritabanını görsel olarak yönetmek ve sorgulamak için pgAdmin4'ü dağıtma
  • CPU ve bellek kaynağı ölçeklendirmesi için Düşük Kesinti Süreli Bakım'ı (LDTM) yürütme

Gerekenler

  • 1. yol: gcloud, kubectl ve helm yardımcı programlarının önceden yüklendiği Google Cloud Shell.
  • 2. yol: Kubernetes kümenize bağlı kubectl ve helm içeren bir terminal.
  • Referans belgeleri için resmi AlloyDB Omni dağıtım kılavuzuna bakın.

2. Kurulum ve Gereksinimler

GKE Autopilot kümesi oluşturmak için Google Cloud hesabı kullanıyorsanız 1. yol'u, Google Cloud hesabı olmadan kendi Kubernetes kümenizi kullanıyorsanız 2. yol'u seçin.

1. yol: Google Cloud projesi kurulumu (GKE Autopilot)

  1. Google Cloud Console'da bir Google Cloud projesi seçin veya oluşturun.
  2. Projeniz için faturalandırmanın etkinleştirildiğini onaylayın. Faturalandırma durumunu nasıl doğrulayacağınızı öğrenin.
  3. Google Cloud Console'un sağ üst köşesindeki Cloud Shell'i etkinleştir simgesini tıklayarak veya shell.cloud.google.com adresini ziyaret ederek Google Cloud Shell'i açın. Cloud Shell; gcloud, kubectl ve helm yüklü bir işlem ortamı sağlar.
  4. Proje kimliğinizi ortam değişkeni olarak ayarlayın ve gcloud aracını yapılandırın:
export PROJECT_ID="<YOUR_PROJECT_ID>"
export REGION="us-central1"
export CLUSTER_NAME="omni-autopilot-cluster"

gcloud config set project ${PROJECT_ID}
gcloud config set compute/region ${REGION}
  1. GKE ve Cloud Storage için gerekli Google Cloud API'lerini etkinleştirin:
gcloud services enable container.googleapis.com \
    storage.googleapis.com \
    cloudresourcemanager.googleapis.com

2. Yol: Kendi Kümenizi Getirme Kurulumu (Google Cloud Hesabı Olmadan)

Google Cloud hesabınız yoksa ve kendi Kubernetes kümenizi kullanıyorsanız devam etmeden önce terminalinizden aşağıdaki ön koşulları doğrulayın:

  1. kubectl ve helm'nin kümenize erişebildiğini ve düğümlerinizin Ready olduğunu doğrulayın:
kubectl get nodes
helm version
  1. Kümenizde (default) olarak işaretlenmiş varsayılan StorageClass bulunduğunu doğrulayın. DBCluster ve BackupPlan manifestleri, kümenin varsayılan StorageClass değerini kullanarak PersistentVolumeClaims'i dinamik olarak sağlar:
kubectl get storageclass

(default) olarak işaretlenmiş bir StorageClass yoksa devam etmeden önce birini varsayılan olarak belirleyin:

kubectl patch storageclass <YOUR_STORAGE_CLASS_NAME> \
  -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
  1. Çalışan düğümlerinizin, operatörün donanım ve işletim sistemi gereksinimlerini karşıladığını doğrulayın:
    • İşletim sistemi ve çekirdek: x86-64/AMD64 düğümlerinde cgroup v2 etkinleştirilmiş Linux çekirdeği 4.18 veya sonraki sürümler.
    • Küme Kapasitesi: HA veritabanı örneklerini (12. adımda her biri 2 vCPU ve 8 GiB'ye ölçeklendirilir), PITR klonlanmış örneğini, PgBouncer'ı ve pgAdmin4'ü eşzamanlı olarak çalıştırmak için çalışan düğümlerinizde en az 8 vCPU ve 24 GiB ayrılabilir bellek gerekir.
    • Ağ Erişimi: gcr.io/alloydb-omni, quay.io/jetstack ve docker.io adreslerinden container görüntülerini almak için giden internet erişimi.

3. Kubernetes kümenizi temel hazırlama veya kümenize bağlanma

1. yolu (Google Cloud Hesabı) izliyorsanız GKE Autopilot, Google'ın küme altyapısını, düğüm temel hazırlığını ve otomatik ölçeklendirmeyi yönettiği, müdahale gerektirmeyen ve tümüyle yönetilen bir Kubernetes modu sunar. GKE Autopilot kümenizi Google Cloud CLI veya Google Cloud Console'u kullanarak oluşturabilirsiniz.

A seçeneği: CLI aracılığıyla GKE Autopilot kümesi oluşturma (1. yol)

Cloud Shell'de aşağıdaki gcloud komutunu çalıştırın:

gcloud container clusters create-auto ${CLUSTER_NAME} \
    --region=${REGION} \
    --project=${PROJECT_ID}

B seçeneği: Console üzerinden GKE Autopilot kümesi oluşturma (1. yol)

  1. Google Cloud Console'da Kubernetes Engine'ı açın.
  2. Sol gezinme bölmesinde Kümeler'i tıklayın.
  3. Oluştur'u tıklayın.
  4. GKE Autopilot bölümünde Configure'u (Yapılandır) tıklayın.
  5. Kümenizin adını (ör. omni-autopilot-cluster) belirtin ve tercih ettiğiniz bölgeyi (us-central1) seçin.
  6. Oluştur'u tıklayın.

Küme bağlantısını doğrulama (1. ve 2. yol)

1. yol'da bir GKE Autopilot kümesi oluşturduysanız kubectl kimlik bilgilerinizi yapılandırın:

gcloud container clusters get-credentials ${CLUSTER_NAME} --region=${REGION} --project=${PROJECT_ID}

Hem Yol 1 hem de Yol 2 için Kubernetes kümenize bağlantıyı doğrulayın:

kubectl get nodes

4. Operatör Ön Koşullarını ve Operatörü Yükleme

AlloyDB Omni Kubernetes Operatörü, kabul webhook'u TLS sertifikalarını yönetmek için cert-manager gerektirir.

1. cert-manager'ı yükleme

Resmi Helm grafiğini kullanarak cert-manager uygulamasını yükleyin:

helm install \
  cert-manager oci://quay.io/jetstack/charts/cert-manager \
  --version v1.21.2 \
  --namespace cert-manager \
  --create-namespace \
  --set crds.enabled=true \
  --set global.leaderElection.namespace=cert-manager

cert-manager kapsüllerinin çalıştığını doğrulayın:

kubectl wait --namespace cert-manager \
  --for=condition=ready pod \
  --selector=app.kubernetes.io/instance=cert-manager \
  --timeout=120s

2. AlloyDB Omni Operatörü'nü yükleme

Helm'i kullanarak AlloyDB Omni Kubernetes operatörünü alloydb-omni-system ad alanına dağıtın:

helm install alloydbomni-operator oci://gcr.io/alloydb-omni/alloydbomni-operator \
  --version 1.8.2 \
  --create-namespace \
  --namespace alloydb-omni-system \
  $(helm install --help | grep -q -- '--rollback-on-failure' && echo '--rollback-on-failure' || echo '--atomic') \
  --timeout 5m

Operatör kapsüllerinin sorunsuz ve çalışır durumda olduğunu doğrulayın:

kubectl get pods -n alloydb-omni-system

5. Tek örnekli veritabanı kümesi oluşturma

Bu adımda, özel bir uygulama ad alanı oluşturacak ve tek örnekli bir AlloyDB Omni DBCluster dağıtacaksınız.

1. Ad alanı ve yönetici kimlik bilgileri gizli anahtarı oluşturma

Veritabanı iş yükleri için bir ad alanı omni-demo oluşturun:

kubectl create namespace omni-demo

Varsayılan postgres veritabanı yöneticisi kullanıcısının şifresini depolayan bir Kubernetes Secret oluşturun:

kubectl apply -n omni-demo -f - <<EOF
apiVersion: v1
kind: Secret
metadata:
  name: db-pw-adbo
type: Opaque
data:
  adbo: "Q2hhbmdlTWUxMjM=" # Base64 for "ChangeMe123"
EOF

2. Tek Örnekli DBCluster Dağıtma

Tek örnekli bir DBCluster manifest dosyası oluşturun:

kubectl apply -n omni-demo -f - <<EOF
apiVersion: alloydbomni.dbadmin.goog/v1
kind: DBCluster
metadata:
  name: adbo
spec:
  databaseVersion: "18.3.0"
  primarySpec:
    adminUser:
      passwordRef:
        name: db-pw-adbo
    resources:
      cpu: 1
      memory: 4Gi
      disks:
      - name: DataDisk
        size: 10Gi
EOF

3. Kümenin hazırlık durumunu doğrulama

DBCLUSTERPHASE, DBClusterReady değerine ulaşana kadar küme durumunu izleyin. İlk temel hazırlık birkaç dakika sürebilir: Operatörün kalıcı birimi oluşturması ve veritabanı görüntüsünü alması gerekir. GKE Autopilot'ta ise önce yeni bir düğümün temel hazırlığının yapılması gerekebilir.

kubectl get dbcluster -n omni-demo -w

DBCLUSTERPHASE, DBClusterReady değerine ulaştığında izleme modundan çıkmak için Ctrl+C tuşuna basın.

Örnek çıkış:

NAME   PRIMARYENDPOINT   PRIMARYPHASE   DBCLUSTERPHASE   HAREADYSTATUS   HAREADYREASON
adbo   10.128.0.45       Ready          DBClusterReady

PRIMARYENDPOINT IP adresini not edin. Bu adres, okuma-yazma Kubernetes hizmetinin (al-adbo-rw-ilb) ClusterIP'sidir. AlloyDB Omni, varsayılan PostgreSQL bağlantı noktası 5432 üzerinden dinleme yapar.

Operatörün tek bir DBCluster manifestinden mutabakat sağladığı kaynakları (veritabanı kapsülü, DataDisk PersistentVolumeClaim ve al-adbo-rw-ilb hizmeti) inceleyin:

kubectl get pods,svc,pvc -n omni-demo

6. Yüksek Kullanılabilirlik'e (HA) yükseltme ve salt okuma bekleme modunu etkinleştirme

AlloyDB Omni; akış replikasyonu, otomatik durum izleme, otomatik yük devretme ve okuma replikası sunma özellikleriyle yerleşik yüksek kullanılabilirlik sağlar.

1. Yüksek Erişilebilirlik ve Okuma Replika Özelliğini Etkinleştirme

1 yedek örnek yapılandırmak ve salt okunur yedek yönlendirmeyi etkinleştirmek için DBCluster spesifikasyonunu güncelleyin:

kubectl patch dbcluster adbo -n omni-demo --type=merge -p '{
  "spec": {
    "availability": {
      "numberOfStandbys": 1,
      "enableStandbyAsReadReplica": true
    }
  }
}'

2. Yüksek Kullanılabilirlik Stabilizasyonunu Doğrulama

Yedek örneğin temel hazırlığının tamamlanmasını ve sağlıklı akış replikasyonuna ulaşmasını (HAREADYSTATUS, True değerine ve HAREADYREASON, Ready değerine ulaşır) bekleyin, ardından izleme modundan çıkmak için Ctrl+C tuşuna basın:

kubectl get dbcluster adbo -n omni-demo -w

HAReady durum koşulunu kontrol edin:

kubectl get dbcluster.alloydbomni.dbadmin.goog adbo -n omni-demo -o jsonpath='{.status.conditions[?(@.type == "HAReady")]}'

Hem okuma-yazma hem de salt okunur uç noktaların yayınlandığını doğrulayın:

kubectl describe dbcluster adbo -n omni-demo | grep -A 8 "Endpoints:"

Örnek çıkış:

Endpoints:
  Name: Read-Write
  Value: 10.128.0.45:5432
  Name: Read-Only
  Value: 10.128.0.46:5432

Okuma-yazma uç noktası (al-adbo-rw-ilb hizmeti) birincil veritabanına yönlendirilirken salt okunur uç nokta (al-adbo-ro-ilb hizmeti), okuma sorgularını yedek örnekler arasında dağıtır.

7. Otomatik BackupPlan'leri yapılandırma (yerel ve GCS)

AlloyDB Omni, BackupPlan özel kaynağı aracılığıyla fiziksel yedeklemeler ve WAL arşivleme sağlar. Yedekleme saklama, otomatik cron programları ve yedekleme hedeflerini (yerel kalıcı birimler veya Google Cloud Storage) yapılandırabilirsiniz.

1. Yerel BackupPlan oluşturma

Yedekleri veritabanı örneklerine bağlı yerel Kubernetes depolama alanına yazan bir BackupPlan oluşturun:

kubectl apply -n omni-demo -f - <<EOF
apiVersion: alloydbomni.dbadmin.goog/v1
kind: BackupPlan
metadata:
  name: backupplan-local
spec:
  dbclusterRef: adbo
  backupSchedules:
    full: "0 2 * * *" # Daily at 02:00 UTC
    incremental: "0 */4 * * *" # Every 4 hours
  backupRetainDays: 7
EOF

Yerel BackupPlan'ın hazır olduğunu doğrulayın:

kubectl get backupplan backupplan-local -n omni-demo

PHASE, Ready ve NEXTBACKUPTIME raporları planlanana kadar bekleyin.

2. GCS BackupPlan oluşturma (1. yol: Yalnızca Google Cloud - İsteğe bağlı)

Yedekleri harici olarak bir Google Cloud Storage paketinde depolamak için GCS paketi oluşturun, hizmet hesabı anahtarı gizli anahtarı yapılandırın ve bulut BackupPlan uygulayın.

  1. Cloud Storage paketi oluşturun:
export BUCKET_NAME="${PROJECT_ID}-omni-backups"
gcloud storage buckets create gs://${BUCKET_NAME} --location=${REGION}
  1. Depolama Alanı Nesnesi Yöneticisi izinlerine sahip bir hizmet hesabı ve bu hesap için bir anahtar oluşturun:

export SA_NAME="omni-backup-sa"
gcloud iam service-accounts create ${SA_NAME} --display-name="AlloyDB Omni Backup SA"

gcloud projects add-iam-policy-binding ${PROJECT_ID} \
  --member="serviceAccount:${SA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com" \
  --role="roles/storage.objectAdmin"

gcloud iam service-accounts keys create /tmp/gcs-key.json \
  --iam-account="${SA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com"
  1. Kubernetes ad alanınızda gizli anahtarı oluşturun:
kubectl create secret generic gcs-backup-secret \
  --from-file=key.json=/tmp/gcs-key.json \
  -n omni-demo
rm /tmp/gcs-key.json
  1. GCS BackupPlan manifestini uygulayın. key alanı, operatörün yedekleri yazdığı paketteki klasördür. / ile başlamalıdır.
kubectl apply -n omni-demo -f - <<EOF
apiVersion: alloydbomni.dbadmin.goog/v1
kind: BackupPlan
metadata:
  name: backupplan-gcs
spec:
  dbclusterRef: adbo
  backupSchedules:
    full: "0 1 * * *"
    incremental: "0 */6 * * *"
  backupRetainDays: 14
  backupLocation:
    type: GCS
    gcsOptions:
      bucket: ${BUCKET_NAME}
      key: /omni-backups/adbo
      secretRef:
        name: gcs-backup-secret
        namespace: omni-demo
EOF

GCS BackupPlan durumunu doğrulayın:

kubectl get backupplan backupplan-gcs -n omni-demo

PHASE, Ready ve NEXTBACKUPTIME raporları planlanana kadar bekleyin.

8. Veri ekleme, yedeklemeyi tetikleme ve geri yüklemeyi test etme

Bu adımda, birincil veritabanına ilk verileri dolduracak, isteğe bağlı manuel yedeklemeyi tetikleyecek, sonraki verileri ekleyecek ve verilerin geri alındığını kanıtlamak için yedeklemeden geri yükleme yapacaksınız.

1. İlk Verileri Doldurma

postgres kullanıcısı olarak okuma-yazma hizmeti al-adbo-rw-ilb üzerinden veritabanına bağlanmak için geçici bir PostgreSQL istemci kapsülü çalıştırın:

kubectl run pg-client --rm -i --tty --image=postgres:16 --restart=Never -n omni-demo -- \
  psql -h al-adbo-rw-ilb -U postgres -d postgres -c "
    CREATE TABLE customers (id SERIAL PRIMARY KEY, name TEXT, created_at TIMESTAMPTZ DEFAULT pg_catalog.now());
    INSERT INTO customers (name) VALUES ('Alpha Co'), ('Beta LLC');
    SELECT * FROM customers;
  "

Şifre istendiğinde ChangeMe123 girin. Bu, 5. adımda db-pw-adbo Secret'ta base64 ile kodladığınız şifredir.

2. İsteğe bağlı yedekleme tetikleme

Yerel BackupPlan öğenize referans veren manuel bir Backup özel kaynağı oluşturun:

kubectl apply -n omni-demo -f - <<EOF
apiVersion: alloydbomni.dbadmin.goog/v1
kind: Backup
metadata:
  name: initial-customer-backup
spec:
  dbclusterRef: adbo
  backupPlanRef: backupplan-local
  manual: true
EOF

Yedekleme işleminin ilerleme durumunu izleme:

kubectl get backup initial-customer-backup -n omni-demo -w

PHASE, Succeeded durumuna geçene kadar bekleyin.

3. Verileri Değiştirme (Yeni Kayıt Ekleme)

Yedeklemeden sonra ek kayıtlar ekleyin:

kubectl run pg-client --rm -i --tty --image=postgres:16 --restart=Never -n omni-demo \
  --env="PGPASSWORD=ChangeMe123" -- \
  psql -h al-adbo-rw-ilb -U postgres -d postgres -c "
    INSERT INTO customers (name) VALUES ('Gamma Inc'), ('Delta Corp');
    SELECT * FROM customers;
  "

Veritabanında artık 4 satır var.

4. Yedekten geri yükle

initial-customer-backup içinde yakalanan duruma geri yükleme işlemini tetikleyin:

kubectl apply -n omni-demo -f - <<EOF
apiVersion: alloydbomni.dbadmin.goog/v1
kind: Restore
metadata:
  name: restore-to-initial
spec:
  sourceDBCluster: adbo
  backup: initial-customer-backup
EOF

Geri yükleme işlemini izleyin:

kubectl get restore restore-to-initial -n omni-demo -w

PHASE, ProvisionSucceeded değerine ulaşana kadar bekleyin ve DBCluster değerinin DBClusterReady değerine döndüğünü doğrulayın:

kubectl get dbcluster adbo -n omni-demo -w

5. Geri yüklenen verilerin durumunu doğrulama

Yalnızca yedekleme öncesi kayıtların mevcut olduğunu doğrulamak için customers tablosunu sorgulayın:

kubectl run pg-client --rm -i --tty --image=postgres:16 --restart=Never -n omni-demo \
  --env="PGPASSWORD=ChangeMe123" -- \
  psql -h al-adbo-rw-ilb -U postgres -d postgres -c "
    SELECT * FROM customers;
  "

Çıkış, yalnızca 2 satırın (Alpha Co ve Beta LLC) mevcut olduğunu onaylayarak veritabanının tam yedekleme durumuna geri yüklendiğini doğrular.

9. Klonlanmış bir veritabanında belirli bir noktadan önceyi kurtarma (PITR)

Belirli bir noktadan önceyi kurtarma (PITR), temel yedeklemeleri ve WAL akış günlüklerini kullanarak bir veritabanını kurtarma penceresindeki herhangi bir saniyeye geri yüklemenize olanak tanır. Geri yüklenen veriler, yeni bir klonlanmış veritabanı kümesine sağlanır.

Operatör, Write-Ahead Log'u (WAL) sürekli olarak arşivlediğinden PITR, veritabanını hatanın gerçekleştiği saniyeden tam bir saniye öncesine (14:14:59) klonlayarak orijinal kümeye dokunmadan, yanlışlıkla yapılan insan veya uygulama hatalarını (örneğin, 14:15:00'te istenmeyen bir DELETE veya DROP TABLE) düzeltmenize olanak tanır.

1. Geçerli Zaman Damgasını Kaydetme ve Verileri Değiştirme

Geçerli UTC zaman damgasını alın:

export PITR_TIMESTAMP=$(date -u +"%Y-%m-%dT%H:%M:%SZ")
echo "PITR Target Timestamp: ${PITR_TIMESTAMP}"

Bu zaman damgasından sonra istenmeyen bir değişikliği temsil eden bir test kaydı ekleyin:

kubectl run pg-client --rm -i --tty --image=postgres:16 --restart=Never -n omni-demo \
  --env="PGPASSWORD=ChangeMe123" -- \
  psql -h al-adbo-rw-ilb -U postgres -d postgres -c "
    INSERT INTO customers (name) VALUES ('Unwanted Record Post-Timestamp');
    SELECT * FROM customers;
  "

2. Belirli Bir Zamana Geri Yükleme İşlemi Gerçekleştirme

pointInTime ve clonedDBClusterConfig'yi yapılandıran Restore özel kaynağını uygulayın:

kubectl apply -n omni-demo -f - <<EOF
apiVersion: alloydbomni.dbadmin.goog/v1
kind: Restore
metadata:
  name: restore-pitr-clone
spec:
  sourceDBCluster: adbo
  pointInTime: "${PITR_TIMESTAMP}"
  clonedDBClusterConfig:
    dbclusterName: adbo-cloned
EOF

PHASE, ProvisionSucceeded değerine ulaşana kadar geri yükleme işlemini izleyin:

kubectl get restore restore-pitr-clone -n omni-demo -w

3. Klonlanmış veritabanını doğrulama

Geri yükleme tamamlandıktan sonra, yeni klonlanmış DBCluster öğesinin DBClusterReady durumuna ulaşmasını bekleyin (izleme modundan çıkmak için Ctrl+C tuşuna basın):

kubectl get dbcluster adbo-cloned -n omni-demo -w

Okuma-yazma hizmeti al-adbo-cloned-rw-ilb üzerinden klonlanmış veritabanını adbo-cloned sorgulayın:

kubectl run pg-client --rm -i --tty --image=postgres:16 --restart=Never -n omni-demo \
  --env="PGPASSWORD=ChangeMe123" -- \
  psql -h al-adbo-cloned-rw-ilb -U postgres -d postgres -c "
    SELECT * FROM customers;
  "

Klonlanan kümede Unwanted Record Post-Timestamp öğesinin bulunmadığını göreceksiniz. Bu, tam olarak hedef noktaya doğru kurtarma işleminin yapıldığını gösterir.

10. PgBouncer bağlantı havuzu oluşturucuyu dağıtma

Bağlantı havuzu, veritabanı bellek yükünü ve bağlantı gecikmesini azaltır. Operatör, PgBouncer örneklerini PgBouncer özel kaynağı aracılığıyla yerel olarak yönetir.

PostgreSQL, her istemci bağlantısı için ayrı bir işletim sistemi işlemi oluşturur. Bu nedenle, web hizmetlerinden, mikro hizmetlerden veya yapay zeka aracılarından gelen yüzlerce eşzamanlı bağlantı, veritabanı belleğini tüketebilir. PgBouncer, veritabanının önünde yer alır ve birçok kısa süreli istemci bağlantısını (max_client_conn adede kadar) uzun süreli PostgreSQL sunucu bağlantılarından oluşan küçük bir havuzda (kullanıcı/veritabanı çifti başına default_pool_size, max_db_connections ile sınırlı) birleştirir.

1. PgBouncer'ı dağıtma

adbo kümesine bağlı 2 replikalı bir PgBouncer havuzlayıcı dağıtın:

kubectl apply -n omni-demo -f - <<EOF
apiVersion: alloydbomni.dbadmin.goog/v1
kind: PgBouncer
metadata:
  name: omni-pgbouncer
spec:
  dbclusterRef: adbo
  allowSuperUserAccess: true
  replicaCount: 2
  parameters:
    pool_mode: transaction
    default_pool_size: "20"
    max_client_conn: "500"
    max_db_connections: "100"
  podSpec:
    resources:
      cpu: 1
      memory: 1Gi
    image: "gcr.io/alloydb-omni/operator/g-pgbouncer:1.4.0"
  serviceOptions:
    type: ClusterIP
EOF

2. PgBouncer durumunu doğrulama

PHASE, Ready olana kadar PgBouncer durumunu izleyin:

kubectl get pgbouncer omni-pgbouncer -n omni-demo -w

Çalışan PgBouncer kapsüllerini ve hizmetini kontrol edin:

kubectl get pods -n omni-demo
kubectl get svc al-omni-pgbouncer-pgb-svc -n omni-demo

3. PgBouncer üzerinden bağlanma

6432 bağlantı noktasındaki PgBouncer hizmeti aracılığıyla bir istemci bağlayın:

kubectl run pg-client --rm -i --tty --image=postgres:16 --restart=Never -n omni-demo \
  --env="PGPASSWORD=ChangeMe123" -- \
  psql -h al-omni-pgbouncer-pgb-svc -p 6432 -U postgres -d postgres -c "
    SELECT pg_catalog.version();
    SELECT * FROM customers;
  "

PgBouncer, sorguyu birincil AlloyDB Omni veritabanına sorunsuz bir şekilde yönlendirir.

11. Veritabanına erişmek için pgAdmin4'ü dağıtma

AlloyDB Omni'yi sorgulamak, yönetmek ve incelemek için web tabanlı bir yönetim konsolu sağlamak üzere pgAdmin4'ü doğrudan Kubernetes kümesinde çalıştırabilirsiniz.

1. Helm aracılığıyla pgAdmin4'ü yükleme

pgadmin4 uygulamasını omni-demo ad alanına yükleyin:

helm install my-pgadmin oci://docker.io/dpage/pgadmin4-helm \
  --namespace omni-demo \
  --set ingress.enabled=false \
  --set image.tag=latest \
  --set auth.email="admin@example.com" \
  --set auth.password="AdminPassword123"

Bu grafik, Helm sürüm adından (my-pgadmin) bağımsız olarak Kubernetes kaynaklarını pgadmin4 (Dağıtım, Hizmet, PersistentVolumeClaim) olarak adlandırır ve kapsüllerini app=pgadmin4 ile etiketler.

pgAdmin4 kapsülünün çalıştığını doğrulayın:

kubectl wait --namespace omni-demo \
  --for=condition=ready pod \
  --selector=app=pgadmin4 \
  --timeout=300s

2. Bağlantı noktasını yönlendirme ve web kullanıcı arayüzüne erişme

pgAdmin4'ü yerel ortamınıza veya Cloud Shell'e yönlendirin:

kubectl port-forward service/pgadmin4 5050:80 -n omni-demo

kubectl port-forward, pgAdmin4 web kullanıcı arayüzünü kullandığınız sürece ön planda çalışmaya devam eder. Diğer komutlar için ikinci bir terminal (veya yeni bir Cloud Shell sekmesi) açın ve sonraki adıma geçmeye hazır olduğunuzda bu terminalde Ctrl+C tuşuna basın.

pgAdmin4 web arayüzünü açın:

  • 1. yol (Google Cloud Shell): Sağ üstteki menüden Web Preview (Web Önizlemesi) düğmesini tıklayın, Change port'u (Bağlantı noktasını değiştir) seçin, 5050 değerini girin ve Change and Preview'u (Değiştir ve Önizle) tıklayın.
  • 2. yol (Yerel İş İstasyonu): kubectl port-forward komutu çalışırken tarayıcınızda http://localhost:5050 adresini açın.

Şu yöntemle giriş yapın:

  • E-posta: admin@example.com
  • Şifre: AdminPassword123

3. AlloyDB Omni'yi pgAdmin4'e kaydetme

  1. pgAdmin4'te Servers (Sunucular) > Register (Kaydet) > Server... (Sunucu...) seçeneğini sağ tıklayın.
  2. Genel sekmesinde:
    • Ad: AlloyDB Omni Primary
  3. Bağlantı sekmesinde:
    • Ana makine adı/adresi: al-adbo-rw-ilb.omni-demo.svc.cluster.local (veya PgBouncer için al-omni-pgbouncer-pgb-svc.omni-demo.svc.cluster.local)
    • Bağlantı noktası: 5432 (veya PgBouncer için 6432)
    • Bakım veritabanı: postgres
    • Kullanıcı adı: postgres
    • Şifre: ChangeMe123
  4. Save'i (Kaydet) tıklayın ve etkin veritabanı oturumunu ve tabloları doğrulayın.

12. Düşük Kesinti Süreli Bakım (LDTM) ile CPU ve Belleği Ölçeklendirme

Üretim veritabanında işlem ve bellek dikey olarak ölçeklendirilirken geleneksel güncellemeler, veritabanının yeniden başlatılmasına neden olur. AlloyDB Omni, güncellemeleri replikalar üzerinden minimum uygulama kesintisiyle dağıtmak için Kısa Kesinti Süreli Bakım (LDTM) sağlar.

1. LDTM Ek Açıklamasını Etkinleştir

Güncellemeler için LDTM'yi etkinleştirmek üzere DBCluster öğesine ek açıklama ekleyin:

kubectl annotate dbclusters.alloydbomni.dbadmin.goog adbo -n omni-demo dbcluster.dbadmin.goog/enableLDTM=true --overwrite

2. CPU ve bellek kaynaklarını ölçeklendirme

Birincil kaynakları cpu: 1, memory: 4Gi yerine cpu: 2, memory: 8Gi olarak güncelleyin:

kubectl patch dbcluster adbo -n omni-demo --type=merge -p '{
  "spec": {
    "primarySpec": {
      "resources": {
        "cpu": 2,
        "memory": "8Gi"
      }
    }
  }
}'

3. LDTM ölçeklendirme ilerleme durumunu izleme

Periyodik güncellemeyi ve yedekten birincile geçiş koşullarını izleyin:

kubectl get dbcluster adbo -n omni-demo -o yaml | grep -A 5 -B 2 "LDTMScalingInProgress"

Kapsüllerin sorunsuz bir şekilde güncellendiğini gözlemleyin:

kubectl get pods -n omni-demo -w

LDTM, önce güncellenmiş bekleme modunu hazırlar, akış replikasyonunu doğrular, hızlı bir geçiş gerçekleştirir ve kalan örneği hizmet kesintisi olmadan günceller.

Güncellenen kaynak tahsisini doğrulayın:

kubectl get dbcluster adbo -n omni-demo -o jsonpath='{.spec.primarySpec.resources}'

13. Kaynakları temizleme

Küme kapasitesini boşaltmak ve Google Cloud hesabınızda gereksiz ücretlendirmeleri önlemek için bu codelab sırasında temel hazırlığı yapılan kaynakları temizleyin.

Temizleme işlemini yeni bir terminal oturumunda (1. yol) çalıştırıyorsanız önceki adımlardaki ortam değişkenleri artık ayarlanmaz. Bunları daha önce kullandığınız değerlerle yeniden dışa aktarın:

export PROJECT_ID="<YOUR_PROJECT_ID>"
export REGION="us-central1"
export CLUSTER_NAME="omni-autopilot-cluster"
export BUCKET_NAME="${PROJECT_ID}-omni-backups"
export SA_NAME="omni-backup-sa"
gcloud config set project ${PROJECT_ID}

1. Veritabanı İş Yüklerini Silme (1. ve 2. Yol)

Kabul webhook'u kontrollerini geçmek için her iki kümeyi de silindi olarak işaretleyin, operatörün DBCluster kaynaklarını kaldırmasını bekleyin ve ardından ad alanını silin:

kubectl patch dbcluster adbo -n omni-demo --type=merge -p '{"spec":{"isDeleted":true}}'
kubectl patch dbcluster adbo-cloned -n omni-demo --type=merge -p '{"spec":{"isDeleted":true}}'
kubectl wait --for=delete dbcluster/adbo dbcluster/adbo-cloned -n omni-demo --timeout=300s
kubectl delete namespace omni-demo

Kendi Kubernetes kümenizi kullandıysanız (2. yol) ve AlloyDB Omni Operatörü ile cert-manager'yi de kaldırmak istiyorsanız:

helm uninstall alloydbomni-operator -n alloydb-omni-system
kubectl delete namespace alloydb-omni-system
helm uninstall cert-manager -n cert-manager
kubectl delete namespace cert-manager

2. GCS paketini ve IAM hizmet hesabını silme (yalnızca 1. yol)

Google Cloud Storage paketini ve hizmet hesabını 1. yol'da oluşturduysanız:

gcloud storage rm --recursive gs://${BUCKET_NAME}
gcloud projects remove-iam-policy-binding ${PROJECT_ID} \
  --member="serviceAccount:${SA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com" \
  --role="roles/storage.objectAdmin"
gcloud iam service-accounts delete ${SA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com --quiet

3. GKE kümesini silme (Yalnızca 1. yol)

1. yolda bir GKE Autopilot kümesinin temel hazırlığını yaptıysanız:

gcloud container clusters delete ${CLUSTER_NAME} --region=${REGION} --quiet

14. Tebrikler

Tebrikler! Kubernetes'te AlloyDB Omni codelab'ini tamamladınız.

İşlediklerimiz

  • GKE Autopilot kümesi temel hazırlığı yaptınız (1. yol) veya mevcut bir Kubernetes kümesini hazırladınız (2. yol).
  • cert-manager ve AlloyDB Omni Kubernetes operatörünü Helm aracılığıyla dağıttınız.
  • Tek örnekli bir AlloyDB Omni DBCluster dağıttınız.
  • Kümeyi, eşzamanlı bekleme modlarıyla yüksek kullanılabilirliğe (HA) yükseltti ve salt okunur bekleme yönlendirmesini etkinleştirdi.
  • Hem yerel kalıcı depolama alanı hem de Google Cloud Storage (GCS) için otomatik BackupPlan kaynakları oluşturuldu.
  • İsteğe bağlı yedeklemeler gerçekleştirdi ve veritabanı geri yüklemelerini doğruladı.
  • Yeni bir klonlanmış veritabanı kümesine belirli bir noktadan önceyi kurtarma (PITR) işlemi uygulandı.
  • Ölçeklenebilir istemci bağlantıları için PgBouncer bağlantı havuzu oluşturucu dağıtıldı.
  • Veritabanı yönetimi için pgAdmin4 dağıtıldı ve bağlandı.
  • İşlem ve bellek kaynaklarını dinamik olarak ölçeklendirmek için Düşük Kesinti Süreli Bakım (LDTM) uygulandı.

Sonraki Adımlar

15. Anket

Bu eğitimden nasıl yararlanacaksınız?

Yalnızca okuyun Okuyun ve alıştırmaları tamamlayın