Men-deploy dan Mengelola AlloyDB Omni di Kubernetes (GKE atau Cluster Anda Sendiri)

1. Pengantar

Dalam codelab ini, Anda akan mempelajari cara menginstal operator AlloyDB Omni Kubernetes (orkestrator container) di cluster Google Kubernetes Engine (GKE) Autopilot atau cluster Kubernetes Anda sendiri, serta mengelola alur kerja siklus proses database end-to-end yang lengkap dan Perjalanan Penting Pengguna (CUJ).

AlloyDB Omni adalah edisi AlloyDB yang dapat didownload dan dirancang untuk berjalan di mana saja—mulai dari lingkungan lokal hingga Google Cloud atau edge computing. Dengan orchestrator container, AlloyDB Omni mengotomatiskan ketersediaan tinggi, failover otomatis, pemulihan mandiri, pemeliharaan berkelanjutan dengan periode nonaktif minimal, penggabungan koneksi, pencadangan otomatis, dan pemulihan point-in-time.

Memilih Jalur Lingkungan Anda

Anda dapat menyelesaikan codelab ini menggunakan salah satu dari dua jalur berikut:

  1. Jalur 1: Memiliki Akun Google Cloud (GKE Autopilot) — Sediakan cluster GKE Autopilot yang terkelola sepenuhnya menggunakan Google Cloud Shell atau Konsol Google Cloud.
  2. Jalur 2: Tidak Memiliki Akun Google Cloud (Bawa Cluster Kubernetes Anda Sendiri) — Gunakan cluster Kubernetes yang ada (v1.21 atau yang lebih baru) dengan kubectl dan helm yang dikonfigurasi di workstation Anda. Tidak memerlukan akun Google Cloud atau gcloud CLI.

Prasyarat

  • Pemahaman dasar tentang konsep Kubernetes (kubectl, Helm, Definisi Resource Kustom).
  • Untuk Jalur 1 (Google Cloud / GKE Autopilot):
    • Project Google Cloud yang mengaktifkan penagihan.
    • Akses ke Google Cloud Shell atau workstation yang dikonfigurasi dengan gcloud, kubectl, dan helm.
  • Untuk Jalur 2 (Bring Your Own Kubernetes Cluster):
    • Cluster Kubernetes yang menjalankan versi 1.21 atau yang lebih baru dengan StorageClass default untuk penyediaan PersistentVolume dinamis.
    • Worker node yang menjalankan kernel Linux 4.18+ dengan cgroup v2 diaktifkan (x86-64/AMD64) dan setidaknya 8 vCPU dan RAM yang dapat dialokasikan sebesar 24 GiB di seluruh cluster.
    • Workstation yang dikonfigurasi dengan kubectl dan helm yang terhubung ke cluster Anda.

Yang akan Anda pelajari

  • Cara menyediakan cluster GKE Autopilot (Jalur 1) atau memvalidasi cluster Kubernetes yang ada (Jalur 2).
  • Cara menginstal cert-manager dan operator AlloyDB Omni Kubernetes melalui Helm.
  • Cara men-deploy AlloyDB Omni DBCluster instance tunggal.
  • Cara menskalakan ke Ketersediaan Tinggi (HA) dengan standby sinkron dan mengaktifkan kemampuan standby hanya baca.
  • Cara mengonfigurasi pencadangan otomatis terjadwal ke penyimpanan repositori lokal (dan secara opsional Google Cloud Storage di Jalur 1).
  • Cara melakukan pencadangan on-demand dan memverifikasi pemulihan data ke status sebelumnya.
  • Cara melakukan Pemulihan Point-in-Time (PITR) ke cluster database baru yang di-clone.
  • Cara men-deploy penggabungan koneksi PgBouncer untuk penskalaan koneksi klien.
  • Cara men-deploy pgAdmin4 untuk mengelola dan mengkueri database secara visual.
  • Cara menjalankan Pemeliharaan Periode Nonaktif Rendah (LDTM) untuk penskalaan resource CPU dan memori.

Yang Anda butuhkan

  • Jalur 1: Google Cloud Shell dengan utilitas gcloud, kubectl, dan helm yang telah diinstal sebelumnya.
  • Jalur 2: Terminal dengan kubectl dan helm yang terhubung ke cluster Kubernetes Anda.
  • Untuk dokumentasi referensi, lihat panduan deployment AlloyDB Omni resmi.

2. Penyiapan dan Persyaratan

Pilih Jalur 1 jika Anda menggunakan akun Google Cloud untuk membuat cluster GKE Autopilot, atau Jalur 2 jika Anda menggunakan cluster Kubernetes Anda sendiri tanpa akun Google Cloud.

Jalur 1: Penyiapan Project Google Cloud (GKE Autopilot)

  1. Di Konsol Google Cloud, pilih atau buat project Google Cloud.
  2. Konfirmasi bahwa penagihan diaktifkan untuk project Anda. Pelajari cara memverifikasi status penagihan.
  3. Buka Google Cloud Shell dengan mengklik ikon Activate Cloud Shell di pojok kanan atas Konsol Google Cloud, atau dengan membuka shell.cloud.google.com. Cloud Shell menyediakan lingkungan komputasi yang dilengkapi dengan gcloud, kubectl, dan helm.
  4. Tetapkan project ID Anda sebagai variabel lingkungan dan konfigurasi gcloud:
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. Aktifkan Google Cloud API yang diperlukan untuk GKE dan Cloud Storage:
gcloud services enable container.googleapis.com \
    storage.googleapis.com \
    cloudresourcemanager.googleapis.com

Jalur 2: Penyiapan Cluster Bring-Your-Own (Tanpa Akun Google Cloud)

Jika Anda tidak memiliki akun Google Cloud dan menggunakan cluster Kubernetes Anda sendiri, verifikasi prasyarat berikut dari terminal Anda sebelum melanjutkan:

  1. Pastikan kubectl dan helm dapat menjangkau cluster Anda dan node Anda adalah Ready:
kubectl get nodes
helm version
  1. Pastikan cluster Anda memiliki StorageClass default yang ditandai (default). Manifes DBCluster dan BackupPlan menyediakan PersistentVolumeClaims secara dinamis menggunakan StorageClass default cluster:
kubectl get storageclass

Jika tidak ada StorageClass yang ditandai (default), tetapkan satu sebagai default sebelum melanjutkan:

kubectl patch storageclass <YOUR_STORAGE_CLASS_NAME> \
  -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
  1. Pastikan worker node Anda memenuhi persyaratan hardware dan OS operator:
    • OS dan Kernel: Linux kernel 4.18 atau yang lebih baru dengan cgroup v2 diaktifkan pada node x86-64/AMD64.
    • Kapasitas Cluster: Setidaknya 8 vCPU dan memori yang dapat dialokasikan sebesar 24 GiB di seluruh worker node Anda untuk menjalankan instance database HA (diskalakan menjadi 2 vCPU dan masing-masing 8 GiB di Langkah 12), instance yang di-clone PITR, PgBouncer, dan pgAdmin4 secara serentak.
    • Akses Jaringan: Akses internet keluar untuk mengambil image container dari gcr.io/alloydb-omni, quay.io/jetstack, dan docker.io.

3. Menyediakan atau Menghubungkan ke Cluster Kubernetes Anda

Jika Anda mengikuti Jalur 1 (Akun Google Cloud), GKE Autopilot menyediakan mode Kubernetes yang terkelola sepenuhnya dan lepas tangan, tempat Google mengelola infrastruktur cluster, penyediaan node, dan penskalaan otomatis. Anda dapat membuat cluster GKE Autopilot menggunakan Google Cloud CLI atau Konsol Google Cloud.

Opsi A: Membuat Cluster GKE Autopilot melalui CLI (Jalur 1)

Jalankan perintah gcloud berikut di Cloud Shell:

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

Opsi B: Membuat Cluster GKE Autopilot melalui Konsol (Jalur 1)

  1. Buka Kubernetes Engine di Konsol Google Cloud.
  2. Di panel navigasi kiri, klik Clusters.
  3. Klik Buat.
  4. Di bagian GKE Autopilot, klik Configure.
  5. Tentukan nama cluster Anda (misalnya, omni-autopilot-cluster) dan pilih region yang Anda inginkan (us-central1).
  6. Klik Buat.

Memverifikasi Konektivitas Cluster (Jalur 1 dan Jalur 2)

Jika Anda membuat cluster GKE Autopilot di Jalur 1, konfigurasikan kredensial kubectl Anda:

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

Untuk Jalur 1 dan Jalur 2, verifikasi konektivitas ke cluster Kubernetes Anda:

kubectl get nodes

4. Menginstal Prasyarat Operator dan Operator

Operator Kubernetes AlloyDB Omni memerlukan cert-manager untuk mengelola sertifikat TLS webhook penerimaan.

1. Menginstal cert-manager

Instal cert-manager menggunakan diagram Helm resminya:

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

Pastikan pod cert-manager sedang berjalan:

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

2. Menginstal Operator AlloyDB Omni

Deploy operator AlloyDB Omni Kubernetes ke dalam namespace alloydb-omni-system menggunakan Helm:

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

Pastikan pod operator responsif dan berjalan:

kubectl get pods -n alloydb-omni-system

5. Membuat Cluster Database Instance Tunggal

Pada langkah ini, Anda akan membuat namespace aplikasi khusus dan men-deploy DBCluster AlloyDB Omni instance tunggal.

1. Membuat Namespace dan Secret Kredensial Admin

Buat namespace omni-demo untuk workload database:

kubectl create namespace omni-demo

Buat Secret Kubernetes yang menyimpan sandi untuk pengguna administrator database postgres default:

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. Men-deploy DBCluster Instance Tunggal

Buat manifes DBCluster instance tunggal:

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. Memverifikasi Kesiapan Cluster

Pantau status cluster hingga DBCLUSTERPHASE mencapai DBClusterReady. Penyediaan awal dapat memerlukan waktu beberapa menit: operator harus membuat persistent volume dan mengambil image database, dan di GKE Autopilot, node baru mungkin perlu disediakan terlebih dahulu.

kubectl get dbcluster -n omni-demo -w

Tekan Ctrl+C untuk keluar dari mode watch setelah DBCLUSTERPHASE mencapai DBClusterReady.

Contoh output:

NAME   PRIMARYENDPOINT   PRIMARYPHASE   DBCLUSTERPHASE   HAREADYSTATUS   HAREADYREASON
adbo   10.128.0.45       Ready          DBClusterReady

Catat alamat IP PRIMARYENDPOINT, yang merupakan ClusterIP dari Service Kubernetes baca-tulis al-adbo-rw-ilb. AlloyDB Omni memproses port PostgreSQL default 5432.

Periksa resource yang direkonsiliasi operator dari manifes DBCluster tunggal—Pod database, PersistentVolumeClaim DataDisk, dan Service al-adbo-rw-ilb:

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

6. Mengupgrade ke Ketersediaan Tinggi (HA) dan Mengaktifkan Standby Hanya Baca

AlloyDB Omni menyediakan Ketersediaan Tinggi (HA) bawaan dengan replikasi streaming, pemantauan kondisi otomatis, failover otomatis, dan penyaluran replika baca.

1. Mengaktifkan Kemampuan HA dan Replika Baca

Perbarui spesifikasi DBCluster untuk mengonfigurasi 1 instance standby dan mengaktifkan pemilihan rute standby hanya baca:

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

2. Memverifikasi Stabilisasi HA

Tunggu hingga instance standby menyediakan dan mencapai replikasi streaming yang responsif (HAREADYSTATUS mencapai True dan HAREADYREASON mencapai Ready), lalu tekan Ctrl+C untuk keluar dari mode watch:

kubectl get dbcluster adbo -n omni-demo -w

Periksa kondisi status HAReady:

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

Pastikan endpoint baca-tulis dan hanya baca dipublikasikan:

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

Contoh output:

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

Endpoint Baca-Tulis (Layanan al-adbo-rw-ilb) mengarahkan ke database utama, sedangkan endpoint Hanya Baca (Layanan al-adbo-ro-ilb) mendistribusikan kueri baca di seluruh instance standby.

7. Mengonfigurasi Automated BackupPlans (Lokal dan GCS)

AlloyDB Omni menyediakan pencadangan fisik dan pengarsipan WAL melalui Resource Kustom BackupPlan. Anda dapat mengonfigurasi retensi cadangan, jadwal cron otomatis, dan target cadangan (volume persisten lokal atau Google Cloud Storage).

1. Membuat BackupPlan Lokal

Buat BackupPlan yang menulis cadangan ke penyimpanan Kubernetes lokal yang terpasang ke instance database:

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

Pastikan BackupPlan lokal sudah siap:

kubectl get backupplan backupplan-local -n omni-demo

Tunggu hingga PHASE melaporkan Ready dan NEXTBACKUPTIME dijadwalkan.

2. Membuat BackupPlan GCS (Jalur 1: Khusus Google Cloud — Opsional)

Untuk menyimpan cadangan secara eksternal di bucket Google Cloud Storage, buat bucket GCS, konfigurasikan secret kunci akun layanan, dan terapkan BackupPlan cloud.

  1. Membuat bucket Cloud Storage: 
export BUCKET_NAME="${PROJECT_ID}-omni-backups"
gcloud storage buckets create gs://${BUCKET_NAME} --location=${REGION}
  1. Buat akun layanan dengan izin Storage Object Admin, dan buat kunci untuk akun tersebut:

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. Buat secret di namespace Kubernetes Anda:
kubectl create secret generic gcs-backup-secret \
  --from-file=key.json=/tmp/gcs-key.json \
  -n omni-demo
rm /tmp/gcs-key.json
  1. Terapkan manifes BackupPlan GCS. Kolom key adalah folder di bucket tempat operator menulis cadangan. Nama ini harus diawali dengan /.
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

Verifikasi status BackupPlan GCS:

kubectl get backupplan backupplan-gcs -n omni-demo

Tunggu hingga PHASE melaporkan Ready dan NEXTBACKUPTIME dijadwalkan.

8. Menyisipkan Data, Memicu Pencadangan, dan Menguji Pemulihan

Pada langkah ini, Anda akan mengisi data awal ke database utama, memicu pencadangan manual on-demand, menambahkan data berikutnya, dan memulihkan dari cadangan untuk membuktikan rollback data.

1. Mengisi Data Awal

Jalankan pod klien PostgreSQL sementara untuk terhubung ke database melalui Service baca-tulis al-adbo-rw-ilb sebagai pengguna postgres:

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

Saat diminta memasukkan sandi, masukkan ChangeMe123. Ini adalah sandi yang Anda enkode dengan base64 di Secret db-pw-adbo pada Langkah 5.

2. Memicu Pencadangan Sesuai Permintaan

Buat resource kustom Backup manual yang merujuk ke BackupPlan lokal Anda:

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

Pantau progres pencadangan:

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

Tunggu hingga PHASE beralih ke Succeeded.

3. Mengubah Data (Menambahkan Data Baru)

Sisipkan data tambahan setelah pencadangan:

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

Database kini berisi 4 baris.

4. Pulihkan dari Cadangan

Picu pemulihan kembali ke status yang diambil di initial-customer-backup:

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

Pantau operasi pemulihan:

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

Tunggu hingga PHASE mencapai ProvisionSucceeded, dan pastikan DBCluster kembali ke DBClusterReady:

kubectl get dbcluster adbo -n omni-demo -w

5. Memverifikasi Status Data yang Dipulihkan

Buat kueri tabel customers untuk memverifikasi bahwa hanya data pra-pencadangan yang ada:

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

Output mengonfirmasi bahwa hanya ada 2 baris (Alpha Co dan Beta LLC), yang memverifikasi bahwa database telah dipulihkan ke status cadangan yang tepat.

9. Pemulihan Point-in-Time (PITR) ke Database yang Di-clone

Pemulihan Point-in-Time (PITR) memungkinkan pemulihan database ke detik arbitrer mana pun dalam periode pemulihan menggunakan cadangan dasar dan log aliran data WAL, yang menyediakan data yang dipulihkan ke dalam cluster database baru yang di-clone.

Karena operator terus mengarsipkan Write-Ahead Log (WAL), PITR memungkinkan Anda memulihkan dari kesalahan manusia atau aplikasi yang tidak disengaja—misalnya, DELETE atau DROP TABLE yang tidak disengaja pada pukul 14.15.00—dengan meng-clone database ke detik tepat sebelum kesalahan terjadi (14.14.59), tanpa menyentuh cluster asli.

1. Merekam Stempel Waktu Saat Ini dan Mengubah Data

Ambil stempel waktu UTC saat ini:

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

Sisipkan data pengujian yang mewakili modifikasi yang tidak diinginkan setelah stempel waktu ini:

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. Melakukan Pemulihan Point-in-Time

Terapkan Resource Kustom Restore yang mengonfigurasi pointInTime dan clonedDBClusterConfig:

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

Pantau operasi pemulihan hingga PHASE mencapai ProvisionSucceeded:

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

3. Memverifikasi Database yang Di-clone

Setelah pemulihan selesai, tunggu hingga DBCluster baru yang di-clone mencapai DBClusterReady (tekan Ctrl+C untuk keluar dari mode watch):

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

Buat kueri database yang di-clone adbo-cloned melalui Service baca-tulisnya al-adbo-cloned-rw-ilb:

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

Perhatikan bahwa Unwanted Record Post-Timestamp tidak ada dalam cluster yang di-clone, yang menunjukkan pemulihan yang akurat ke titik waktu target yang tepat.

10. Men-deploy Connection Pooler PgBouncer

Penggabungan koneksi mengurangi overhead memori database dan latensi koneksi. Operator mengelola instance PgBouncer secara native melalui Resource Kustom PgBouncer.

PostgreSQL melakukan fork pada proses sistem operasi terpisah untuk setiap koneksi klien, sehingga ratusan koneksi serentak dari layanan web, microservice, atau agen AI dapat menghabiskan memori database. PgBouncer berada di depan database dan melakukan multiplexing banyak koneksi klien berumur pendek (hingga max_client_conn) ke dalam kumpulan kecil koneksi server PostgreSQL berumur panjang (default_pool_size per pasangan pengguna/database, dibatasi oleh max_db_connections).

1. Men-deploy PgBouncer

Deploy pooler PgBouncer 2 replika yang ditautkan ke cluster adbo:

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. Memverifikasi Status PgBouncer

Pantau status PgBouncer hingga PHASE menjadi Ready:

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

Periksa pod dan layanan PgBouncer yang berjalan:

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

3. Terhubung melalui PgBouncer

Hubungkan klien melalui layanan PgBouncer di port 6432:

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 mem-proxy kueri dengan lancar ke database AlloyDB Omni utama.

11. Men-deploy pgAdmin4 untuk Mengakses Database

Anda dapat menjalankan pgAdmin4 langsung di dalam cluster Kubernetes untuk menyediakan konsol administrasi berbasis web untuk membuat kueri, mengelola, dan memeriksa AlloyDB Omni.

1. Menginstal pgAdmin4 melalui Helm

Instal pgadmin4 di namespace omni-demo:

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"

Chart ini memberi nama resource Kubernetes-nya pgadmin4 (Deployment, Service, PersistentVolumeClaim) dan memberi label pada Pod-nya dengan app=pgadmin4, terlepas dari nama rilis Helm (my-pgadmin).

Pastikan pod pgAdmin4 sedang berjalan:

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

2. Meneruskan Port dan Mengakses UI Web

Lakukan penerusan port pgAdmin4 ke lingkungan lokal atau Cloud Shell Anda:

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

kubectl port-forward terus berjalan di latar depan selama Anda menggunakan UI web pgAdmin4. Buka terminal kedua (atau tab Cloud Shell baru) untuk perintah lain, dan tekan Ctrl+C di terminal ini saat Anda siap melanjutkan ke langkah berikutnya.

Buka antarmuka web pgAdmin4:

  • Jalur 1 (Google Cloud Shell): Klik tombol Web Preview di menu kanan atas, pilih Change port, masukkan 5050, lalu klik Change and Preview.
  • Jalur 2 (Workstation Lokal): Buka http://localhost:5050 di browser Anda saat perintah kubectl port-forward sedang berjalan.

Login menggunakan:

  • Email: admin@example.com
  • Password: AdminPassword123

3. Mendaftarkan AlloyDB Omni di pgAdmin4

  1. Di pgAdmin4, klik kanan Servers > Register > Server....
  2. Di tab General:
    • Nama: AlloyDB Omni Primary
  3. Di tab Connection:
    • Nama/alamat host: al-adbo-rw-ilb.omni-demo.svc.cluster.local (atau al-omni-pgbouncer-pgb-svc.omni-demo.svc.cluster.local untuk PgBouncer)
    • Port: 5432 (atau 6432 untuk PgBouncer)
    • Database pemeliharaan: postgres
    • Username: postgres
    • Password: ChangeMe123
  4. Klik Save dan verifikasi sesi dan tabel database yang aktif.

12. Menskalakan CPU dan Memori dengan Low Downtime Maintenance (LDTM)

Saat menskalakan komputasi dan memori secara vertikal di database produksi, update tradisional menyebabkan gangguan mulai ulang database. AlloyDB Omni menyediakan Low Downtime Maintenance (LDTM) untuk meluncurkan update bertahap melalui replika dengan gangguan aplikasi minimal.

1. Mengaktifkan Anotasi LDTM

Beri anotasi pada DBCluster untuk mengaktifkan LDTM untuk update:

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

2. Menskalakan Resource CPU dan Memori

Perbarui resource utama dari cpu: 1, memory: 4Gi ke cpu: 2, memory: 8Gi:

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

3. Memantau Progres Penskalaan LDTM

Pantau update berkelanjutan dan kondisi pengalihan standby-ke-utama:

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

Amati pod yang di-rollout dengan lancar:

kubectl get pods -n omni-demo -w

LDTM menyiapkan standby yang diperbarui terlebih dahulu, memverifikasi replikasi streaming, menjalankan peralihan cepat, dan memperbarui instance yang tersisa tanpa gangguan layanan.

Verifikasi alokasi resource yang diperbarui:

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

13. Membersihkan Resource

Untuk mengosongkan kapasitas cluster dan mencegah tagihan yang tidak perlu pada akun Google Cloud Anda, bersihkan resource yang disediakan selama codelab ini.

Jika Anda menjalankan pembersihan di sesi terminal baru (Jalur 1), variabel lingkungan dari langkah sebelumnya tidak lagi ditetapkan. Ekspor ulang dengan nilai yang sama seperti yang Anda gunakan sebelumnya:

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. Menghapus Workload Database (Jalur 1 dan Jalur 2)

Tandai kedua cluster sebagai dihapus untuk lulus pemeriksaan webhook penerimaan, tunggu hingga operator menghapus resource DBCluster, lalu hapus namespace:

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

Jika Anda menggunakan cluster Kubernetes Anda sendiri (Jalur 2) dan juga ingin menghapus operator AlloyDB Omni dan cert-manager:

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. Menghapus Bucket GCS dan Akun Layanan IAM (Khusus Jalur 1)

Jika Anda membuat bucket Cloud Storage dan akun layanan Google Cloud Storage di Jalur 1:

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. Menghapus Cluster GKE (Khusus Jalur 1)

Jika Anda menyediakan cluster GKE Autopilot di Jalur 1:

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

14. Selamat

Selamat! Anda telah menyelesaikan codelab AlloyDB Omni di Kubernetes.

Yang telah kita bahas

  • Menyediakan cluster GKE Autopilot (Jalur 1) atau menyiapkan cluster Kubernetes yang ada (Jalur 2).
  • Men-deploy cert-manager dan operator AlloyDB Omni Kubernetes melalui Helm.
  • Men-deploy AlloyDB Omni DBCluster instance tunggal.
  • Mengupgrade cluster ke Ketersediaan Tinggi (HA) dengan standby sinkron dan mengaktifkan pemilihan rute standby hanya baca.
  • Membuat resource BackupPlan otomatis untuk penyimpanan persisten lokal dan Google Cloud Storage (GCS).
  • Melakukan pencadangan on-demand dan memvalidasi pemulihan database.
  • Menjalankan Pemulihan Point-in-Time (PITR) ke cluster database baru yang di-clone.
  • Men-deploy penggabung koneksi PgBouncer untuk koneksi klien yang skalabel.
  • Men-deploy dan menghubungkan pgAdmin4 untuk pengelolaan database.
  • Menjalankan Low Downtime Maintenance (LDTM) untuk menskalakan resource komputasi dan memori secara dinamis.

Langkah Berikutnya

15. Survei

Bagaimana Anda akan menggunakan tutorial ini?

Hanya membacanya Membaca dan menyelesaikan latihannya