Kubernetes (GKE या Bring-Your-Own क्लस्टर) पर AlloyDB Omni को डिप्लॉय और मैनेज करना

1. परिचय

इस कोडलैब में, आपको Google Kubernetes Engine (GKE) ऑटोपायलट क्लस्टर या अपने Kubernetes क्लस्टर पर, AlloyDB Omni Kubernetes ऑपरेटर (कंटेनर ऑर्केस्ट्रेटर) को इंस्टॉल करने का तरीका बताया जाएगा. साथ ही, आपको एंड-टू-एंड डेटाबेस लाइफ़साइकल वर्कफ़्लो और क्रिटिकल यूज़र जर्नी (सीयूजे) को मैनेज करने का तरीका भी बताया जाएगा.

AlloyDB Omni, AlloyDB का डाउनलोड किया जा सकने वाला वर्शन है. इसे कहीं भी चलाया जा सकता है. जैसे, कंपनी की इमारत में मौजूद एनवायरमेंट, Google Cloud या एज कंप्यूटिंग. कंटेनर ऑर्केस्ट्रेटर की मदद से, AlloyDB Omni कई सुविधाओं को ऑटोमेट करता है. जैसे, ज़्यादा अपटाइम, अपने-आप होने वाले फ़ेलओवर, गड़बड़ियों को अपने-आप ठीक करना, कम से कम डाउनटाइम के साथ रोलिंग मेंटेनेंस, कनेक्शन पूलिंग, अपने-आप होने वाले बैकअप, और पिछले समय की रिकवरी.

अपने एनवायरमेंट का पाथ चुनना

इस कोडलैब को पूरा करने के लिए, इनमें से किसी एक तरीके का इस्तेमाल किया जा सकता है:

  1. पहला तरीका: Google Cloud खाता (GKE Autopilot) होना — Google Cloud Shell या Google Cloud Console का इस्तेमाल करके, पूरी तरह से मैनेज किया गया GKE Autopilot क्लस्टर बनाएं.
  2. दूसरा तरीका: Google Cloud खाता न होने पर (अपना Kubernetes क्लस्टर इस्तेमाल करें) — अपने वर्कस्टेशन पर कॉन्फ़िगर किए गए kubectl और helm के साथ, किसी मौजूदा Kubernetes क्लस्टर (v1.21 या इसके बाद के वर्शन) का इस्तेमाल करें. इसके लिए, Google Cloud खाते या gcloud सीएलआई की ज़रूरत नहीं है.

ज़रूरी शर्तें

  • Kubernetes के सिद्धांतों (kubectl, Helm, कस्टम रिसॉर्स डेफ़िनिशन) के बारे में बुनियादी जानकारी.
  • पहले तरीके (Google Cloud / GKE Autopilot) के लिए:
    • बिलिंग की सुविधा वाला Google क्लाउड प्रोजेक्ट.
    • Google Cloud Shell या gcloud, kubectl, और helm के साथ कॉन्फ़िगर किए गए वर्कस्टेशन का ऐक्सेस.
  • दूसरे तरीके (Bring Your Own Kubernetes Cluster) के लिए:
    • Kubernetes क्लस्टर का वर्शन 1.21 या इसके बाद का वर्शन होना चाहिए. साथ ही, डाइनैमिक PersistentVolume प्रोविज़निंग के लिए, डिफ़ॉल्ट StorageClass होना चाहिए.
    • Linux kernel 4.18+ पर चलने वाले वर्कर नोड, जिनमें cgroup v2 चालू हो (x86-64/AMD64). साथ ही, पूरे क्लस्टर में कम से कम आठ वीसीपीयू और 24 जीबी रैम उपलब्ध हो.
    • आपके क्लस्टर से कनेक्ट किया गया वर्कस्टेशन, जिसमें kubectl और helm कॉन्फ़िगर किया गया हो.

आपको क्या सीखने को मिलेगा

  • GKE Autopilot क्लस्टर को कैसे प्रावधान करें (पहला तरीका) या किसी मौजूदा Kubernetes क्लस्टर की पुष्टि कैसे करें (दूसरा तरीका).
  • Helm की मदद से, cert-manager और AlloyDB Omni Kubernetes ऑपरेटर को इंस्टॉल करने का तरीका.
  • सिंगल-इंस्टेंस AlloyDB Omni DBCluster को डिप्लॉय करने का तरीका.
  • सिंक्रोनस स्टैंडबाय के साथ, ज़्यादा अपटाइम (एचए) को कैसे बढ़ाया जाए और रीड-ओनली स्टैंडबाय की सुविधा को कैसे चालू किया जाए.
  • लोकल रिपॉज़िटरी स्टोरेज में, शेड्यूल किए गए ऑटोमेटेड बैकअप को कॉन्फ़िगर करने का तरीका. इसके अलावा, पाथ 1 पर Google Cloud Storage को कॉन्फ़िगर करने का तरीका भी बताया गया है.
  • मांग पर बैकअप लेने और डेटा को पहले की स्थिति में वापस लाने की पुष्टि करने का तरीका.
  • क्लोन किए गए नए डेटाबेस क्लस्टर में, पिछले समय की रिकवरी (पीआईटीआर) करने का तरीका.
  • क्लाइंट कनेक्शन को स्केल करने के लिए, PgBouncer कनेक्शन पूलिंग को डिप्लॉय करने का तरीका.
  • डेटाबेस को विज़ुअल तौर पर मैनेज करने और क्वेरी करने के लिए, pgAdmin4 को डिप्लॉय करने का तरीका.
  • सीपीयू और मेमोरी रिसॉर्स को स्केल करने के लिए, लो डाउनटाइम मेंटेनेंस (एलडीटीएम) को कैसे लागू करें.

आपको इन चीज़ों की ज़रूरत होगी

  • पहला तरीका: Google Cloud Shell, जिसमें gcloud, kubectl, और helm यूटिलिटी पहले से इंस्टॉल होती हैं.
  • दूसरा तरीका: आपके Kubernetes क्लस्टर से कनेक्ट किया गया kubectl और helm वाला टर्मिनल.
  • रेफ़रंस दस्तावेज़ के लिए, AlloyDB Omni को डिप्लॉय करने की आधिकारिक गाइड देखें.

2. सेटअप और ज़रूरी शर्तें

अगर GKE Autopilot क्लस्टर बनाने के लिए Google Cloud खाते का इस्तेमाल किया जा रहा है, तो पहला तरीका चुनें. अगर Google Cloud खाते के बिना अपने Kubernetes क्लस्टर का इस्तेमाल किया जा रहा है, तो दूसरा तरीका चुनें.

पहला तरीका: Google Cloud प्रोजेक्ट सेटअप (GKE Autopilot)

  1. Google Cloud console में, कोई Google Cloud प्रोजेक्ट चुनें या नया बनाएं.
  2. पुष्टि करें कि आपके प्रोजेक्ट के लिए बिलिंग की सुविधा चालू है. बिलिंग की स्थिति की पुष्टि करने का तरीका जानें.
  3. Google Cloud Console के सबसे ऊपर दाएं कोने में मौजूद, Cloud Shell चालू करें आइकॉन पर क्लिक करके या shell.cloud.google.com पर जाकर, Google Cloud Shell खोलें. Cloud Shell, gcloud, kubectl, और helm के साथ लोड किया गया कंप्यूट एनवायरमेंट उपलब्ध कराता है.
  4. अपने प्रोजेक्ट आईडी को एनवायरमेंट वैरिएबल के तौर पर सेट करें और 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. GKE और Cloud Storage के लिए, ज़रूरी Google Cloud API चालू करें:
gcloud services enable container.googleapis.com \
    storage.googleapis.com \
    cloudresourcemanager.googleapis.com

दूसरा तरीका: Bring-Your-Own Cluster सेटअप (Google Cloud खाता न होने पर)

अगर आपके पास Google Cloud खाता नहीं है और अपने Kubernetes क्लस्टर का इस्तेमाल किया जा रहा है, तो आगे बढ़ने से पहले अपने टर्मिनल से इन ज़रूरी शर्तों की पुष्टि करें:

  1. पुष्टि करें कि kubectl और helm आपके क्लस्टर तक पहुंच सकते हैं और आपके नोड Ready हैं:
kubectl get nodes
helm version
  1. पुष्टि करें कि आपके क्लस्टर में डिफ़ॉल्ट StorageClass को (default) के तौर पर मार्क किया गया हो. DBCluster और BackupPlan मेनिफ़ेस्ट, क्लस्टर के डिफ़ॉल्ट StorageClass का इस्तेमाल करके, PersistentVolumeClaims को डाइनैमिक तौर पर उपलब्ध कराते हैं:
kubectl get storageclass

अगर किसी भी StorageClass को (default) के तौर पर मार्क नहीं किया गया है, तो आगे बढ़ने से पहले किसी एक को डिफ़ॉल्ट के तौर पर सेट करें:

kubectl patch storageclass <YOUR_STORAGE_CLASS_NAME> \
  -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
  1. पुष्टि करें कि आपके वर्कर नोड, ऑपरेटर के हार्डवेयर और ओएस से जुड़ी ज़रूरी शर्तें पूरी करते हों:
    • ओएस और कर्नेल: Linux kernel 4.18 या इसके बाद का वर्शन. साथ ही, x86-64/AMD64 नोड पर cgroup v2 चालू होना चाहिए.
    • क्लस्टर की क्षमता: आपके वर्कर नोड में कम से कम आठ वीसीपीयू और 24 जीबी की ऐलोकेट की जा सकने वाली मेमोरी होनी चाहिए. इससे, एचए डेटाबेस इंस्टेंस (12वें चरण में, हर इंस्टेंस को दो वीसीपीयू और आठ जीबी तक बढ़ाया गया है), पीआईटीआर क्लोन किया गया इंस्टेंस, PgBouncer, और pgAdmin4 को एक साथ चलाया जा सकता है.
    • नेटवर्क ऐक्सेस: gcr.io/alloydb-omni, quay.io/jetstack, और docker.io से कंटेनर इमेज को पुल करने के लिए, आउटबाउंड इंटरनेट ऐक्सेस.

3. अपने Kubernetes क्लस्टर का प्रावधान करना या उससे कनेक्ट करना

अगर आपने पहला तरीका (Google Cloud खाता) चुना है, तो GKE Autopilot आपको पूरी तरह से मैनेज किया गया Kubernetes मोड उपलब्ध कराता है. इसमें Google, क्लस्टर इन्फ़्रास्ट्रक्चर, नोड प्रोविज़निंग, और ऑटोस्केलिंग को मैनेज करता है. Google Cloud CLI या Google Cloud Console का इस्तेमाल करके, GKE Autopilot क्लस्टर बनाया जा सकता है.

पहला विकल्प: सीएलआई (पाथ 1) की मदद से GKE Autopilot क्लस्टर बनाना

Cloud Shell में यह gcloud कमांड चलाएं:

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

दूसरा विकल्प: Console की मदद से GKE Autopilot क्लस्टर बनाना (पहला तरीका)

  1. Google Cloud Console में Kubernetes Engine खोलें.
  2. बाईं ओर मौजूद नेविगेशन पैनल में, क्लस्टर पर क्लिक करें.
  3. बनाएं पर क्लिक करें.
  4. GKE Autopilot सेक्शन में, कॉन्फ़िगर करें पर क्लिक करें.
  5. अपने क्लस्टर का नाम बताएं (उदाहरण के लिए, omni-autopilot-cluster) और अपनी पसंद का क्षेत्र (us-central1) चुनें.
  6. बनाएं पर क्लिक करें.

क्लस्टर कनेक्टिविटी की पुष्टि करना (पाथ 1 और पाथ 2)

अगर आपने पहले तरीके में GKE Autopilot क्लस्टर बनाया है, तो अपने kubectl क्रेडेंशियल कॉन्फ़िगर करें:

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

पाथ 1 और पाथ 2, दोनों के लिए अपने Kubernetes क्लस्टर से कनेक्टिविटी की पुष्टि करें:

kubectl get nodes

4. ऑपरेटर की ज़रूरी शर्तें और ऑपरेटर इंस्टॉल करना

AlloyDB Omni Kubernetes ऑपरेटर को एडमिशन वेबहुक टीएलएस सर्टिफ़िकेट मैनेज करने के लिए, cert-manager की ज़रूरत होती है.

1. cert-manager इंस्टॉल करना

इसके आधिकारिक Helm चार्ट का इस्तेमाल करके, cert-manager इंस्टॉल करें:

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 पॉड चल रहे हैं:

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

2. AlloyDB Omni ऑपरेटर इंस्टॉल करना

Helm का इस्तेमाल करके, AlloyDB Omni Kubernetes ऑपरेटर को alloydb-omni-system नेमस्पेस में डिप्लॉय करें:

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

पुष्टि करें कि ऑपरेटर पॉड सही तरीके से काम कर रहे हैं और चालू हैं:

kubectl get pods -n alloydb-omni-system

5. सिंगल-इंस्टेंस डेटाबेस क्लस्टर बनाना

इस चरण में, आपको एक खास ऐप्लिकेशन नेमस्पेस बनाना होगा और AlloyDB Omni DBCluster का सिंगल-इंस्टेंस डिप्लॉय करना होगा.

1. नेमस्पेस और एडमिन क्रेडेंशियल सीक्रेट बनाना

डेटाबेस वर्कलोड के लिए, नेमस्पेस omni-demo बनाएं:

kubectl create namespace omni-demo

डिफ़ॉल्ट postgres डेटाबेस एडमिन उपयोगकर्ता के लिए पासवर्ड सेव करने वाला Kubernetes सीक्रेट बनाएं:

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. सिंगल-इंस्टेंस DBCluster डिप्लॉय करें

सिंगल-इंस्टेंस DBCluster मेनिफ़ेस्ट बनाएं:

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. क्लस्टर के तैयार होने की पुष्टि करना

क्लस्टर की स्थिति पर तब तक नज़र रखें, जब तक DBCLUSTERPHASE की वैल्यू DBClusterReady न हो जाए. शुरुआती प्रावधान में कुछ मिनट लग सकते हैं: ऑपरेटर को पर्सिस्टेंट वॉल्यूम बनाना होगा और डेटाबेस इमेज को पुल करना होगा. साथ ही, GKE Autopilot पर पहले एक नए नोड का प्रावधान करना पड़ सकता है.

kubectl get dbcluster -n omni-demo -w

DBCLUSTERPHASE के DBClusterReady पर पहुंचने के बाद, वॉच मोड से बाहर निकलने के लिए Ctrl+C दबाएं.

आउटपुट का सैंपल:

NAME   PRIMARYENDPOINT   PRIMARYPHASE   DBCLUSTERPHASE   HAREADYSTATUS   HAREADYREASON
adbo   10.128.0.45       Ready          DBClusterReady

PRIMARYENDPOINT आईपी पते को नोट करें. यह रीड-राइट Kubernetes सेवा al-adbo-rw-ilb का ClusterIP है. AlloyDB Omni, डिफ़ॉल्ट PostgreSQL पोर्ट 5432 पर सिग्नल पाने के लिए कॉन्फ़िगर किया गया है.

उन संसाधनों की जांच करें जिन्हें ऑपरेटर ने एक ही DBCluster मेनिफ़ेस्ट से रीकंसाइल किया है. जैसे, डेटाबेस पॉड, DataDisk PersistentVolumeClaim, और al-adbo-rw-ilb सेवा:

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

6. ज़्यादा अपटाइम (एचए) पर अपग्रेड करना और रीड-ओनली स्टैंडबाय को चालू करना

AlloyDB Omni में, ज़्यादा अपटाइम (एचए) की सुविधा पहले से मौजूद होती है. इसमें स्ट्रीमिंग रेप्लिकेशन, अपने-आप हेल्थ मॉनिटरिंग, अपने-आप फ़ेलओवर, और रीड-रेप्लिका सर्विंग की सुविधा शामिल है.

1. एचए और रीड रेप्लिका की सुविधा चालू करना

एक स्टैंडबाय इंस्टेंस को कॉन्फ़िगर करने और रीड-ओनली स्टैंडबाय रूटिंग को चालू करने के लिए, DBCluster की जानकारी अपडेट करें:

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

2. एचए स्टेबलाइज़ेशन की पुष्टि करना

स्टैंडबाय इंस्टेंस के प्रावधान होने और स्ट्रीमिंग रेप्लिकेशन के सही तरीके से काम करने का इंतज़ार करें (HAREADYSTATUS, True तक पहुंचता है और HAREADYREASON, Ready तक पहुंचता है). इसके बाद, वॉच मोड से बाहर निकलने के लिए Ctrl+C दबाएं:

kubectl get dbcluster adbo -n omni-demo -w

HAReady की स्थिति देखें:

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

पुष्टि करें कि रीड-राइट और रीड-ओनली, दोनों एंडपॉइंट पब्लिश किए गए हैं:

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

आउटपुट का सैंपल:

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

रीड-राइट एंडपॉइंट (al-adbo-rw-ilb सेवा), प्राइमरी डेटाबेस पर रूट करता है. वहीं, रीड-ओनली एंडपॉइंट (al-adbo-ro-ilb सेवा), रीड क्वेरी को स्टैंडबाय इंस्टेंस में डिस्ट्रिब्यूट करता है.

7. अपने-आप बैकअप लेने की सुविधा के प्लान कॉन्फ़िगर करना (लोकल और GCS)

AlloyDB Omni, BackupPlan कस्टम रिसॉर्स की मदद से फ़िज़िकल बैकअप और WAL संग्रह करने की सुविधा देता है. बैकअप को सेव रखने की अवधि, अपने-आप होने वाले क्रॉन शेड्यूल, और बैकअप टारगेट (लोकल परसिस्टेंट वॉल्यूम या Google Cloud Storage) को कॉन्फ़िगर किया जा सकता है.

1. लोकल BackupPlan बनाना

एक BackupPlan बनाएं, जो डेटाबेस इंस्टेंस से जुड़े लोकल Kubernetes स्टोरेज में बैकअप सेव करे:

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

पुष्टि करें कि लोकल BackupPlan तैयार है:

kubectl get backupplan backupplan-local -n omni-demo

PHASE रिपोर्ट Ready और NEXTBACKUPTIME शेड्यूल होने तक इंतज़ार करें.

2. GCS BackupPlan बनाएं (पहला तरीका: सिर्फ़ Google Cloud — ज़रूरी नहीं)

Google Cloud Storage बकेट में बैकअप को बाहरी तौर पर सेव करने के लिए, एक GCS बकेट बनाएं. इसके बाद, सेवा खाते की कुंजी का सीक्रेट कॉन्फ़िगर करें और क्लाउड BackupPlan लागू करें.

  1. Cloud Storage बकेट बनाएं:
export BUCKET_NAME="${PROJECT_ID}-omni-backups"
gcloud storage buckets create gs://${BUCKET_NAME} --location=${REGION}
  1. स्टोरेज ऑब्जेक्ट एडमिन की अनुमतियों वाला सेवा खाता बनाएं और उसके लिए एक कुंजी बनाएं:

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 नेमस्पेस में सीक्रेट बनाएं:
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 मेनिफ़ेस्ट लागू करें. key फ़ील्ड, बकेट में मौजूद वह फ़ोल्डर होता है जिसमें ऑपरेटर बैकअप सेव करता है. यह / से शुरू होना चाहिए.
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 की स्थिति की पुष्टि करें:

kubectl get backupplan backupplan-gcs -n omni-demo

PHASE रिपोर्ट Ready और NEXTBACKUPTIME शेड्यूल होने तक इंतज़ार करें.

8. डेटा डालना, बैकअप ट्रिगर करना, और डेटा वापस पाने की सुविधा को टेस्ट करना

इस चरण में, आपको प्राइमरी डेटाबेस में शुरुआती डेटा भरना होगा. साथ ही, मांग पर मैन्युअल बैकअप को ट्रिगर करना होगा, बाद का डेटा जोड़ना होगा, और डेटा रोलबैक को साबित करने के लिए बैकअप से डेटा वापस लाना होगा.

1. शुरुआती डेटा भरना

postgres उपयोगकर्ता के तौर पर, रीड-राइट सेवा al-adbo-rw-ilb के ज़रिए डेटाबेस से कनेक्ट करने के लिए, कुछ समय के लिए PostgreSQL क्लाइंट पॉड चलाएं:

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

पासवर्ड मांगे जाने पर, ChangeMe123 डालें. यह वह पासवर्ड है जिसे आपने पांचवें चरण में, db-pw-adbo सीक्रेट में base64-कोड में बदला था.

2. मांग पर बैकअप ट्रिगर करना

अपने स्थानीय BackupPlan का रेफ़रंस देने वाला, मैन्युअल Backup कस्टम रिसॉर्स बनाएं:

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

बैकअप की प्रोग्रेस को मॉनिटर करें:

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

PHASE के Succeeded में बदलने तक इंतज़ार करें.

3. डेटा में बदलाव करना (नए रिकॉर्ड जोड़ना)

बैकअप लेने के बाद, अतिरिक्त रिकॉर्ड जोड़ें:

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

डेटाबेस में अब चार लाइनें हैं.

4. बैकअप से डेटा वापस लाएं

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

डेटा वापस पाने की प्रोसेस को मॉनिटर करें:

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

PHASE के ProvisionSucceeded तक पहुंचने का इंतज़ार करें. साथ ही, पुष्टि करें कि DBCluster, DBClusterReady पर वापस आ गया है:

kubectl get dbcluster adbo -n omni-demo -w

5. रीस्टोर किए गए डेटा की स्थिति की पुष्टि करना

customers टेबल को क्वेरी करें, ताकि यह पुष्टि की जा सके कि सिर्फ़ बैकअप लेने से पहले के रिकॉर्ड मौजूद हैं:

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

आउटपुट से पुष्टि होती है कि सिर्फ़ दो लाइनें (Alpha Co और Beta LLC) मौजूद हैं. इससे यह पुष्टि होती है कि डेटाबेस को बैकअप की सटीक स्थिति में वापस लाया गया है.

9. क्लोन किए गए डेटाबेस में, पिछले समय की रिकवरी (पीआईटीआर)

पिछले समय की रिकवरी (पीआईटीआर) की सुविधा से, डेटाबेस को रिकवरी विंडो में किसी भी समय पर वापस लाया जा सकता है. इसके लिए, बेस बैकअप और डब्ल्यूएएल स्ट्रीम लॉग का इस्तेमाल किया जाता है. साथ ही, वापस लाए गए डेटा को नए क्लोन किए गए डेटाबेस क्लस्टर में उपलब्ध कराया जाता है.

ऑपरेटर, राइट-अहेड लॉग (डब्ल्यूएएल) को लगातार संग्रहित करता है. इसलिए, पीआईटीआर की मदद से, अनजाने में हुई मानवीय या ऐप्लिकेशन की गड़बड़ियों से बचा जा सकता है. उदाहरण के लिए, दोपहर 2:15:00 बजे अनजाने में हुई DELETE या DROP TABLE गड़बड़ी से बचने के लिए, गड़बड़ी होने से ठीक एक सेकंड पहले (दोपहर 2:14:59 बजे) डेटाबेस को क्लोन किया जा सकता है. इसके लिए, ओरिजनल क्लस्टर में कोई बदलाव नहीं करना पड़ता.

1. मौजूदा टाइमस्टैंप रिकॉर्ड करें और डेटा बदलें

मौजूदा यूटीसी टाइमस्टैंप को वापस पाने के लिए:

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

इस टाइमस्टैंप के बाद, ऐसा टेस्ट रिकॉर्ड डालें जो अनचाहे बदलाव को दिखाता हो:

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. पॉइंट-इन-टाइम रीस्टोर की सुविधा इस्तेमाल करना

pointInTime और clonedDBClusterConfig को कॉन्फ़िगर करने वाला Restore कस्टम रिसॉर्स लागू करें:

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 तक न पहुंच जाए:

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

3. क्लोन किए गए डेटाबेस की पुष्टि करना

रीस्टोर होने के बाद, क्लोन किए गए नए DBCluster के DBClusterReady तक पहुंचने का इंतज़ार करें. वॉच मोड से बाहर निकलने के लिए, Ctrl+C दबाएं:

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

क्लोन किए गए डेटाबेस adbo-cloned को उसकी रीड-राइट सेवा 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;
  "

ध्यान दें कि क्लोन किए गए क्लस्टर में Unwanted Record Post-Timestamp मौजूद नहीं है. इससे पता चलता है कि डेटा को टारगेट किए गए समय के हिसाब से सटीक तरीके से वापस लाया गया है.

10. PgBouncer कनेक्शन पूलर को डिप्लॉय करना

कनेक्शन पूलिंग से, डेटाबेस मेमोरी ओवरहेड और कनेक्शन लेटेंसी कम हो जाती है. ऑपरेटर, PgBouncer कस्टम रिसॉर्स के ज़रिए PgBouncer इंस्टेंस को नेटिव तौर पर मैनेज करता है.

PostgreSQL, हर क्लाइंट कनेक्शन के लिए एक अलग ऑपरेटिंग सिस्टम प्रोसेस फ़ोर्क करता है. इसलिए, वेब सेवाओं, माइक्रोसर्विस या एआई एजेंट से एक साथ सैकड़ों कनेक्शन होने पर, डेटाबेस की मेमोरी खत्म हो सकती है. PgBouncer, डेटाबेस के सामने मौजूद होता है. यह कम समय तक चलने वाले कई क्लाइंट कनेक्शन (max_client_conn तक) को, लंबे समय तक चलने वाले PostgreSQL सर्वर कनेक्शन (हर उपयोगकर्ता/डेटाबेस पेयर के लिए default_pool_size, जिसकी सीमा max_db_connections है) के छोटे पूल में मल्टीप्लेक्स करता है.

1. PgBouncer को डिप्लॉय करना

क्लस्टर adbo से लिंक किया गया दो-रेप्लिका वाला PgBouncer पूल डिप्लॉय करें:

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 के स्टेटस की पुष्टि करना

PgBouncer का स्टेटस तब तक देखें, जब तक PHASE की वैल्यू Ready न हो जाए:

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

चल रहे PgBouncer पॉड और सेवा की जांच करें:

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

3. PgBouncer के ज़रिए कनेक्ट करना

पोर्ट 6432 पर PgBouncer सेवा के ज़रिए किसी क्लाइंट को कनेक्ट करें:

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, क्वेरी को प्राइमरी AlloyDB Omni डेटाबेस पर आसानी से प्रॉक्सी करता है.

11. डेटाबेस को ऐक्सेस करने के लिए, pgAdmin4 को डिप्लॉय करना

AlloyDB Omni के बारे में क्वेरी करने, उसे मैनेज करने, और उसकी जांच करने के लिए, वेब पर आधारित एडमिन कंसोल उपलब्ध कराया जा सकता है. इसके लिए, Kubernetes क्लस्टर में सीधे pgAdmin4 को चलाया जा सकता है.

1. Helm की मदद से pgAdmin4 इंस्टॉल करना

omni-demo नेमस्पेस में pgadmin4 इंस्टॉल करें:

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"

यह चार्ट, अपने Kubernetes संसाधनों को pgadmin4 (डिप्लॉयमेंट, सर्विस, PersistentVolumeClaim) नाम देता है. साथ ही, अपने पॉड को app=pgadmin4 के साथ लेबल करता है. भले ही, Helm रिलीज़ का नाम (my-pgadmin) कुछ भी हो.

पुष्टि करें कि pgAdmin4 पॉड चल रहा है:

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

2. पोर्ट फ़ॉरवर्ड करना और वेब यूज़र इंटरफ़ेस (यूआई) को ऐक्सेस करना

pgAdmin4 को अपने लोकल एनवायरमेंट या Cloud Shell पर पोर्ट-फ़ॉरवर्ड करें:

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

जब तक pgAdmin4 वेब यूज़र इंटरफ़ेस (यूआई) का इस्तेमाल किया जाता है, तब तक kubectl port-forward फ़ोरग्राउंड में चलता रहता है. अन्य निर्देशों के लिए, दूसरा टर्मिनल (या नया Cloud Shell टैब) खोलें. इसके बाद, जब आप अगले चरण पर जाने के लिए तैयार हों, तो इस टर्मिनल में Ctrl+C दबाएं.

pgAdmin4 वेब इंटरफ़ेस खोलें:

  • पहला तरीका (Google Cloud Shell): सबसे ऊपर दाएं मेन्यू में मौजूद, वेब की झलक बटन पर क्लिक करें. इसके बाद, पोर्ट बदलें को चुनें, 5050 डालें, और बदलें और झलक देखें पर क्लिक करें.
  • दूसरा तरीका (लोकल वर्कस्टेशन): kubectl port-forward कमांड के चलने के दौरान, अपने ब्राउज़र में http://localhost:5050 खोलें.

इनका इस्तेमाल करके लॉग इन करें:

  • ईमेल: admin@example.com
  • पासवर्ड: AdminPassword123

3. AlloyDB Omni को pgAdmin4 में रजिस्टर करना

  1. pgAdmin4 में, Servers > Register > Server... पर राइट क्लिक करें.
  2. सामान्य टैब में जाकर:
    • नाम: AlloyDB Omni Primary
  3. कनेक्शन टैब में जाकर:
    • होस्ट का नाम/पता: al-adbo-rw-ilb.omni-demo.svc.cluster.local (या PgBouncer के लिए al-omni-pgbouncer-pgb-svc.omni-demo.svc.cluster.local)
    • पोर्ट: 5432 (या PgBouncer के लिए 6432)
    • मेंटेनेंस डेटाबेस: postgres
    • उपयोगकर्ता नाम: postgres
    • पासवर्ड: ChangeMe123
  4. सेव करें पर क्लिक करें. इसके बाद, चालू डेटाबेस सेशन और टेबल की पुष्टि करें.

12. लो डाउनटाइम मेंटेनेंस (एलडीटीएम) की मदद से, सीपीयू और मेमोरी को स्केल करना

प्रोडक्शन डेटाबेस पर कंप्यूट और मेमोरी को वर्टिकल तौर पर स्केल करने पर, पारंपरिक अपडेट की वजह से डेटाबेस को रीस्टार्ट करने में रुकावटें आती हैं. AlloyDB Omni, लो डाउनटाइम मेंटेनेंस (एलडीटीएम) की सुविधा देता है. इससे ऐप्लिकेशन में कम से कम रुकावट के साथ, रेप्लिका के ज़रिए अपडेट रोल आउट किए जा सकते हैं.

1. एलडीटीएम एनोटेशन की सुविधा चालू करें

अपडेट के लिए एलडीटीएम चालू करने के लिए, DBCluster को एनोटेट करें:

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

2. सीपीयू और मेमोरी के संसाधनों को बढ़ाना

प्राइमरी रिसॉर्स को cpu: 1, memory: 4Gi से cpu: 2, memory: 8Gi पर अपडेट करें:

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

3. एलडीटीएम स्केलिंग की प्रोग्रेस को मॉनिटर करना

रोलिंग अपडेट और स्टैंडबाय-टू-प्राइमरी स्विचओवर की स्थितियों पर नज़र रखें:

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

पॉड को शानदार तरीके से रोल होते हुए देखें:

kubectl get pods -n omni-demo -w

एलडीटीएम, सबसे पहले अपडेट किए गए स्टैंडबाय को तैयार करता है. इसके बाद, स्ट्रीमिंग रेप्लिकेशन की पुष्टि करता है और तेज़ी से स्विचओवर करता है. साथ ही, सेवा में रुकावट डाले बिना बाकी इंस्टेंस को अपडेट करता है.

अपडेट किए गए संसाधन के बंटवारे की पुष्टि करें:

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

13. संसाधन हटाएं

क्लस्टर की क्षमता को खाली करने और अपने Google Cloud खाते पर बेवजह लगने वाले शुल्क से बचने के लिए, इस कोडलैब के दौरान उपलब्ध कराए गए संसाधनों को हटा दें.

अगर क्लीनअप की प्रोसेस को नए टर्मिनल सेशन (पाथ 1) में चलाया जा रहा है, तो पिछले चरणों के एनवायरमेंट वैरिएबल अब सेट नहीं होंगे. उन्हें फिर से एक्सपोर्ट करें. इसके लिए, पहले इस्तेमाल की गई वैल्यू का ही इस्तेमाल करें:

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. डेटाबेस वर्कलोड मिटाना (पहला और दूसरा तरीका)

एडमिशन वेबहुक की जांच पास करने के लिए, दोनों क्लस्टर को 'मिटाए गए' के तौर पर मार्क करें. इसके बाद, ऑपरेटर के DBCluster संसाधनों को हटाने का इंतज़ार करें और फिर नेमस्पेस को मिटाएं:

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

अगर आपने अपने Kubernetes क्लस्टर (पाथ 2) का इस्तेमाल किया है और आपको AlloyDB Omni ऑपरेटर और 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. GCS बकेट और आईएएम सेवा खाता मिटाना (सिर्फ़ पाथ 1)

अगर आपने पहले तरीके से Google Cloud Storage बकेट और सेवा खाता बनाया है, तो:

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 क्लस्टर मिटाना (सिर्फ़ पाथ 1)

अगर आपने पहले तरीके में GKE Autopilot क्लस्टर को प्रोविज़न किया है, तो:

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

14. बधाई हो

बधाई हो! आपने Kubernetes पर AlloyDB Omni का कोडलैब पूरा कर लिया है.

हमने क्या-क्या कवर किया

  • GKE Autopilot क्लस्टर (पाथ 1) को प्रावधान किया हो या किसी मौजूदा Kubernetes क्लस्टर (पाथ 2) को तैयार किया हो.
  • Helm की मदद से, cert-manager और AlloyDB Omni Kubernetes ऑपरेटर को डिप्लॉय किया गया.
  • सिंगल-इंस्टेंस AlloyDB Omni DBCluster डिप्लॉय किया गया.
  • क्लस्टर को ज़्यादा अपटाइम (एचए) पर अपग्रेड किया गया. इसके लिए, सिंक्रोनस स्टैंडबाय का इस्तेमाल किया गया और रीड-ओनली स्टैंडबाय रूटिंग को चालू किया गया.
  • लोकल परसिस्टेंट स्टोरेज और Google Cloud Storage (GCS), दोनों के लिए ऑटोमेटेड BackupPlan रिसॉर्स बनाए गए.
  • मांग पर बैकअप लिए और डेटाबेस को वापस लाने की पुष्टि की.
  • क्लोन किए गए नए डेटाबेस क्लस्टर में, पिछले समय की रिकवरी (पीआईटीआर) की सुविधा को लागू किया गया.
  • स्केलेबल क्लाइंट कनेक्शन के लिए, PgBouncer कनेक्शन पूलर को डिप्लॉय किया गया.
  • डेटाबेस मैनेजमेंट के लिए, pgAdmin4 को डिप्लॉय और कनेक्ट किया गया.
  • कंप्यूट और मेमोरी से जुड़े संसाधनों को डाइनैमिक तरीके से स्केल करने के लिए, लो डाउनटाइम मेंटेनेंस (एलडीटीएम) को लागू किया गया.

अगले चरण

15. सर्वे

इस ट्यूटोरियल का इस्तेमाल कैसे किया जाएगा?

सिर्फ़ इसे पढ़ें इसे पढ़ें और एक्सरसाइज़ पूरी करें