AlloyDB Omni in Kubernetes (GKE oder Bring-Your-Own-Cluster) bereitstellen und verwalten

1. Einführung

In diesem Codelab erfahren Sie, wie Sie den AlloyDB Omni Kubernetes-Operator (den Container-Orchestrator) entweder in einem Google Kubernetes Engine (GKE) Autopilot-Cluster oder in Ihrem eigenen Kubernetes-Cluster installieren und vollständige End-to-End-Datenbanklebenszyklus-Workflows und Critical User Journeys (CUJs) verwalten.

AlloyDB Omni ist eine herunterladbare Version von AlloyDB, die überall ausgeführt werden kann – von lokalen Umgebungen bis hin zu Google Cloud oder Edge-Computing. Mit dem Container-Orchestrator automatisiert AlloyDB Omni Hochverfügbarkeit, automatische Failover, Selbstheilung, rollierende Wartung mit minimaler Ausfallzeit, Verbindungs-Pooling, automatisierte Sicherungen und Wiederherstellung zu einem bestimmten Zeitpunkt.

Umgebungspfad auswählen

Sie können dieses Codelab auf zwei Arten absolvieren:

  1. Pfad 1: Google Cloud-Konto (GKE Autopilot) – Stellen Sie einen vollständig verwalteten GKE Autopilot-Cluster mit Google Cloud Shell oder der Google Cloud Console bereit.
  2. Pfad 2: Sie haben kein Google Cloud-Konto (eigenen Kubernetes-Cluster verwenden) – Verwenden Sie einen vorhandenen Kubernetes-Cluster (v1.21 oder höher) mit kubectl und helm, die auf Ihrer Workstation konfiguriert sind. Es ist kein Google Cloud-Konto oder gcloud-CLI erforderlich.

Voraussetzungen

  • Grundlegende Kenntnisse der Kubernetes-Konzepte (kubectl, Helm, benutzerdefinierte Ressourcendefinitionen).
  • Für Pfad 1 (Google Cloud / GKE Autopilot):
    • Google Cloud-Projekt mit aktivierter Abrechnungsfunktion.
    • Zugriff auf Google Cloud Shell oder eine Workstation, die mit gcloud, kubectl und helm konfiguriert ist.
  • Für Pfad 2 (Bring Your Own Kubernetes Cluster):
    • Einen Kubernetes-Cluster mit Version 1.21 oder höher und einer Standard-StorageClass für die dynamische Bereitstellung von PersistentVolumes.
    • Worker-Knoten mit Linux-Kernel 4.18 oder höher mit aktivierter cgroup v2 (x86-64/AMD64) und mindestens 8 vCPUs und 24 GiB zuweisbarem RAM im gesamten Cluster.
    • Eine Workstation, die mit kubectl und helm konfiguriert und mit Ihrem Cluster verbunden ist.

Lerninhalte

  • GKE Autopilot-Cluster bereitstellen (Pfad 1) oder vorhandenen Kubernetes-Cluster validieren (Pfad 2)
  • So installieren Sie cert-manager und den AlloyDB Omni Kubernetes-Operator über Helm.
  • Wie Sie eine AlloyDB Omni-DBCluster mit einer einzelnen Instanz bereitstellen.
  • Anleitung zum Skalieren auf Hochverfügbarkeit (HA) mit synchronen Stand-by-Instanzen und Aktivieren der Lesezugriff-Stand-by-Funktion.
  • Konfiguration geplanter automatischer Sicherungen im lokalen Repository-Speicher (und optional in Google Cloud Storage auf Pfad 1)
  • On-Demand-Sicherungen durchführen und die Wiederherstellung von Daten in einem früheren Zustand überprüfen
  • Wiederherstellung zu einem bestimmten Zeitpunkt in einem neuen geklonten Datenbankcluster ausführen
  • PgBouncer-Verbindungspooling für die Skalierung von Clientverbindungen bereitstellen
  • pgAdmin4 bereitstellen, um die Datenbank visuell zu verwalten und abzufragen
  • Wie Sie eine Wartung mit geringer Ausfallzeit (Low Downtime Maintenance, LDTM) für die Skalierung von CPU- und Arbeitsspeicherressourcen ausführen.

Voraussetzungen

  • Pfad 1: Google Cloud Shell mit vorinstallierten gcloud-, kubectl- und helm-Dienstprogrammen.
  • Pfad 2: Ein Terminal mit kubectl und helm, das mit Ihrem Kubernetes-Cluster verbunden ist.
  • Referenzdokumentation finden Sie im offiziellen AlloyDB Omni-Bereitstellungsleitfaden.

2. Einrichtung und Anforderungen

Wählen Sie Pfad 1 aus, wenn Sie ein Google Cloud-Konto verwenden, um einen GKE Autopilot-Cluster zu erstellen, oder Pfad 2, wenn Sie Ihren eigenen Kubernetes-Cluster ohne Google Cloud-Konto verwenden.

Pfad 1: Google Cloud-Projekt einrichten (GKE Autopilot)

  1. Wählen Sie in der Google Cloud Console ein Google Cloud-Projekt aus oder erstellen Sie eines.
  2. Hier kannst du überprüfen, ob das der Fall ist. Informationen zum Bestätigen des Abrechnungsstatus
  3. Öffnen Sie die Google Cloud Shell, indem Sie oben rechts in der Google Cloud Console auf das Symbol Cloud Shell aktivieren klicken oder shell.cloud.google.com aufrufen. Cloud Shell stellt eine Compute-Umgebung mit gcloud, kubectl und helm bereit.
  4. Legen Sie Ihre Projekt-ID als Umgebungsvariable fest und konfigurieren Sie 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. Aktivieren Sie die erforderlichen Google Cloud APIs für GKE und Cloud Storage:
gcloud services enable container.googleapis.com \
    storage.googleapis.com \
    cloudresourcemanager.googleapis.com

Pfad 2: Einrichtung eines eigenen Clusters (ohne Google Cloud-Konto)

Wenn Sie kein Google Cloud-Konto haben und Ihren eigenen Kubernetes-Cluster verwenden, prüfen Sie die folgenden Voraussetzungen in Ihrem Terminal, bevor Sie fortfahren:

  1. Prüfen Sie, ob kubectl und helm Ihren Cluster erreichen können und ob Ihre Knoten Ready sind:
kubectl get nodes
helm version
  1. Prüfen Sie, ob Ihr Cluster eine Standard-StorageClass hat, die als (default) gekennzeichnet ist. Die Manifeste DBCluster und BackupPlan stellen PersistentVolumeClaims dynamisch über die Standard-StorageClass des Clusters bereit:
kubectl get storageclass

Wenn kein StorageClass als (default) markiert ist, legen Sie einen als Standard fest, bevor Sie fortfahren:

kubectl patch storageclass <YOUR_STORAGE_CLASS_NAME> \
  -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
  1. Prüfen Sie, ob Ihre Worker-Knoten die Hardware- und Betriebssystemanforderungen des Operators erfüllen:
    • Betriebssystem und Kernel: Linux-Kernel 4.18 oder höher mit aktiviertem cgroup v2 auf x86-64/AMD64-Knoten.
    • Clusterkapazität: Mindestens 8 vCPUs und 24 GiB zuweisbarer Arbeitsspeicher auf Ihren Worker-Knoten, um die HA-Datenbankinstanzen (in Schritt 12 auf jeweils 2 vCPUs und 8 GiB skaliert), die geklonte PITR-Instanz, PgBouncer und pgAdmin4 gleichzeitig auszuführen.
    • Netzwerkzugriff: Ausgehender Internetzugriff zum Abrufen von Container-Images aus gcr.io/alloydb-omni, quay.io/jetstack und docker.io.

3. Kubernetes-Cluster bereitstellen oder Verbindung herstellen

Wenn Sie Pfad 1 (Google Cloud-Konto) folgen, bietet GKE Autopilot einen vollständig verwalteten Kubernetes-Modus, in dem Google die Clusterinfrastruktur, die Knotenbereitstellung und das Autoscaling verwaltet. Sie können Ihren GKE Autopilot-Cluster mit der Google Cloud CLI oder der Google Cloud Console erstellen.

Option A: GKE Autopilot-Cluster über die Befehlszeile erstellen (Pfad 1)

Führen Sie in Cloud Shell den folgenden gcloud-Befehl aus:

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

Option B: GKE Autopilot-Cluster über die Console erstellen (Pfad 1)

  1. Öffnen Sie Kubernetes Engine in der Google Cloud Console.
  2. Klicken Sie im linken Navigationsbereich auf Cluster.
  3. Klicken Sie auf Erstellen.
  4. Klicken Sie im Bereich GKE-Autopilot auf Konfigurieren.
  5. Geben Sie den Clusternamen an (z. B. omni-autopilot-cluster) und wählen Sie die gewünschte Region (us-central1) aus.
  6. Klicken Sie auf Erstellen.

Clusterkonnektivität prüfen (Pfad 1 und Pfad 2)

Wenn Sie in Pfad 1 einen GKE Autopilot-Cluster erstellt haben, konfigurieren Sie Ihre kubectl-Anmeldedaten:

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

Prüfen Sie für Pfad 1 und Pfad 2 die Verbindung zu Ihrem Kubernetes-Cluster:

kubectl get nodes

4. Voraussetzungen für den Operator und den Operator installieren

Der AlloyDB Omni Kubernetes-Operator benötigt cert-manager, um TLS-Zertifikate für Admission-Webhooks zu verwalten.

1. Cert-Manager installieren

Installieren Sie cert-manager mit dem offiziellen Helm-Diagramm:

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

Prüfen Sie, ob die cert-manager-Pods ausgeführt werden:

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

2. AlloyDB Omni-Operator installieren

Stellen Sie den AlloyDB Omni Kubernetes-Operator mit Helm im Namespace alloydb-omni-system bereit:

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

Prüfen Sie, ob die Operator-Pods fehlerfrei sind und ausgeführt werden:

kubectl get pods -n alloydb-omni-system

5. Datenbankcluster mit einer einzelnen Instanz erstellen

In diesem Schritt erstellen Sie einen dedizierten Anwendungs-Namespace und stellen eine AlloyDB Omni-DBCluster mit einer einzelnen Instanz bereit.

1. Namespace und Secret für Administratoranmeldedaten erstellen

Erstellen Sie einen Namespace omni-demo für Datenbankarbeitslasten:

kubectl create namespace omni-demo

Erstellen Sie ein Kubernetes-Secret, in dem das Passwort für den Standard-postgres-Datenbankadministrator gespeichert wird:

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 mit einer einzelnen Instanz bereitstellen

Erstellen Sie ein DBCluster-Manifest mit einer einzelnen Instanz:

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. Clusterbereitschaft prüfen

Beobachten Sie den Clusterstatus, bis DBCLUSTERPHASE den Wert DBClusterReady erreicht. Die Ersteinrichtung kann einige Minuten dauern: Der Operator muss das nichtflüchtige Volume erstellen und das Datenbank-Image abrufen. In GKE Autopilot muss möglicherweise zuerst ein neuer Knoten bereitgestellt werden.

kubectl get dbcluster -n omni-demo -w

Drücken Sie Ctrl+C, um den Überwachungsmodus zu beenden, sobald DBCLUSTERPHASE den Wert DBClusterReady erreicht hat.

Beispielausgabe:

NAME   PRIMARYENDPOINT   PRIMARYPHASE   DBCLUSTERPHASE   HAREADYSTATUS   HAREADYREASON
adbo   10.128.0.45       Ready          DBClusterReady

Notieren Sie sich die IP-Adresse PRIMARYENDPOINT. Dies ist die ClusterIP des Kubernetes-Dienstes al-adbo-rw-ilb mit Lese-/Schreibzugriff. AlloyDB Omni überwacht den PostgreSQL-Standardport 5432.

Prüfen Sie die Ressourcen, die der Operator aus dem einzelnen DBCluster-Manifest abgeglichen hat: den Datenbank-Pod, den DataDisk-PersistentVolumeClaim und den al-adbo-rw-ilb-Dienst:

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

6. Upgrade auf Hochverfügbarkeit (HA) durchführen und schreibgeschützten Stand-by aktivieren

AlloyDB Omni bietet integrierte Hochverfügbarkeit mit Streaming-Replikation, automatischer Systemdiagnose, automatischem Failover und Bereitstellung von Lesereplikaten.

1. Hochverfügbarkeit und Lesereplikatfunktion aktivieren

Aktualisieren Sie die DBCluster-Spezifikation, um eine Stand‑by-Instanz zu konfigurieren und das Routing mit Lesezugriff für Stand-by-Instanzen zu aktivieren:

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

2. HA-Stabilisierung prüfen

Warten Sie, bis die Stand-by-Instanz bereitgestellt wurde und eine fehlerfreie Streaming-Replikation erreicht hat (HAREADYSTATUS erreicht True und HAREADYREASON erreicht Ready). Drücken Sie dann Ctrl+C, um den Beobachtungsmodus zu beenden:

kubectl get dbcluster adbo -n omni-demo -w

Prüfen Sie die Statusbedingung HAReady:

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

Prüfen Sie, ob sowohl Lese-/Schreib- als auch Lesezugriff-Endpunkte veröffentlicht wurden:

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

Beispielausgabe:

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

Der Lese-/Schreibendpunkt (al-adbo-rw-ilb-Dienst) leitet an die primäre Datenbank weiter, während der schreibgeschützte Endpunkt (al-adbo-ro-ilb-Dienst) Leseabfragen auf Stand-by-Instanzen verteilt.

7. Automatische Sicherungspläne konfigurieren (lokal und GCS)

AlloyDB Omni bietet physische Sicherungen und WAL-Archivierung über die benutzerdefinierte Ressource BackupPlan. Sie können die Aufbewahrung von Sicherungen, automatisierte Cron-Zeitpläne und Sicherungsziele (lokale nichtflüchtige Volumes oder Google Cloud Storage) konfigurieren.

1. Lokalen BackupPlan erstellen

Erstellen Sie einen BackupPlan, der Sicherungen in den lokalen Kubernetes-Speicher schreibt, der an die Datenbankinstanzen angehängt ist:

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

Prüfen Sie, ob der lokale BackupPlan bereit ist:

kubectl get backupplan backupplan-local -n omni-demo

Warten Sie, bis PHASE den Wert Ready meldet und NEXTBACKUPTIME geplant ist.

2. GCS-BackupPlan erstellen (Pfad 1: Nur Google Cloud – optional)

Wenn Sie Sicherungen extern in einem Google Cloud Storage-Bucket speichern möchten, erstellen Sie einen GCS-Bucket, konfigurieren Sie ein Dienstkontoschlüssel-Secret und wenden Sie eine Cloud-BackupPlan an.

  1. Erstellen Sie einen Cloud Storage-Bucket:
export BUCKET_NAME="${PROJECT_ID}-omni-backups"
gcloud storage buckets create gs://${BUCKET_NAME} --location=${REGION}
  1. Erstellen Sie ein Dienstkonto mit den Berechtigungen „Storage-Objekt-Administrator“ und einen Schlüssel dafür:

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. Erstellen Sie das Secret in Ihrem Kubernetes-Namespace:
kubectl create secret generic gcs-backup-secret \
  --from-file=key.json=/tmp/gcs-key.json \
  -n omni-demo
rm /tmp/gcs-key.json
  1. Wenden Sie das GCS-BackupPlan-Manifest an. Das Feld key ist der Ordner im Bucket, in den der Operator Sicherungen schreibt. Er muss mit / beginnen.
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

Prüfen Sie den Status des GCS-BackupPlan:

kubectl get backupplan backupplan-gcs -n omni-demo

Warten Sie, bis PHASE den Wert Ready meldet und NEXTBACKUPTIME geplant ist.

8. Daten einfügen, Sicherung auslösen und Wiederherstellung testen

In diesem Schritt füllen Sie die primäre Datenbank mit ersten Daten, lösen eine manuelle On-Demand-Sicherung aus, fügen weitere Daten hinzu und stellen die Daten aus der Sicherung wieder her, um den Daten-Rollback zu prüfen.

1. Populate Initial Data

Führen Sie einen temporären PostgreSQL-Client-Pod aus, um über den Lese-/Schreibdienst al-adbo-rw-ilb als Nutzer postgres eine Verbindung zur Datenbank herzustellen:

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

Wenn Sie zur Eingabe eines Passworts aufgefordert werden, geben Sie ChangeMe123 ein. Dies ist das Passwort, das Sie in Schritt 5 im Secret db-pw-adbo mit Base64 codiert haben.

2. On-Demand-Sicherung auslösen

Erstellen Sie eine manuelle benutzerdefinierte Backup-Ressource, die auf Ihre lokale BackupPlan verweist:

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

Beobachten Sie den Sicherungsfortschritt:

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

Warten Sie, bis PHASE zu Succeeded wechselt.

3. Daten ändern (neue Einträge hinzufügen)

Fügen Sie nach der Sicherung zusätzliche Datensätze ein:

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

Die Datenbank enthält jetzt vier Zeilen.

4. Aus einem Back-up wiederherstellen

Lösen Sie eine Wiederherstellung des in initial-customer-backup erfassten Status aus:

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

Überwachen Sie den Wiederherstellungsvorgang:

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

Warten Sie, bis PHASE den Wert ProvisionSucceeded erreicht, und prüfen Sie, ob DBCluster wieder DBClusterReady ist:

kubectl get dbcluster adbo -n omni-demo -w

5. Status der wiederhergestellten Daten prüfen

Fragen Sie die Tabelle customers ab, um zu prüfen, ob nur die Datensätze vor der Sicherung vorhanden sind:

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

Die Ausgabe bestätigt, dass nur zwei Zeilen (Alpha Co und Beta LLC) vorhanden sind. Das bedeutet, dass die Datenbank genau in den Zustand der Sicherung zurückversetzt wurde.

9. Wiederherstellung zu einem bestimmten Zeitpunkt (PITR) in einer geklonten Datenbank

Mit der Wiederherstellung zu einem bestimmten Zeitpunkt (Point-in-Time Recovery, PITR) kann eine Datenbank mithilfe von Basissicherungen und WAL-Stream-Logs auf eine beliebige Sekunde innerhalb des Wiederherstellungszeitraums wiederhergestellt werden. Die wiederhergestellten Daten werden in einem neuen geklonten Datenbankcluster bereitgestellt.

Da der Operator das Write-Ahead-Log (WAL) kontinuierlich archiviert, können Sie mit der Wiederherstellung zu einem bestimmten Zeitpunkt versehentliche menschliche oder Anwendungsfehler beheben, z. B. ein unbeabsichtigtes DELETE oder DROP TABLE um 14:15:00 Uhr. Dazu klonen Sie die Datenbank auf die genaue Sekunde vor dem Fehler (14:14:59 Uhr), ohne den ursprünglichen Cluster zu verändern.

1. Aktuellen Zeitstempel aufzeichnen und Daten mutieren

Rufen Sie den aktuellen UTC-Zeitstempel ab:

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

Fügen Sie einen Testdatensatz ein, der eine unerwünschte Änderung nach diesem Zeitstempel darstellt:

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. Wiederherstellung zu einem bestimmten Zeitpunkt ausführen

Wenden Sie die benutzerdefinierte Ressource Restore an, um pointInTime und clonedDBClusterConfig zu konfigurieren:

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

Überwachen Sie den Wiederherstellungsvorgang, bis PHASE den Wert ProvisionSucceeded erreicht:

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

3. Geklonte Datenbank prüfen

Warten Sie nach Abschluss der Wiederherstellung, bis die neue geklonte DBCluster den Status DBClusterReady erreicht hat. Drücken Sie Ctrl+C, um den Überwachungsmodus zu beenden:

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

Fragen Sie die geklonte Datenbank adbo-cloned über den Lese-/Schreibdienst al-adbo-cloned-rw-ilb ab:

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

Beachten Sie, dass Unwanted Record Post-Timestamp im geklonten Cluster nicht vorhanden ist. Dies zeigt, dass die Wiederherstellung zum genauen Zielzeitpunkt erfolgreich war.

10. PgBouncer-Verbindungspooler bereitstellen

Verbindungs-Pooling reduziert den Arbeitsspeicher-Overhead der Datenbank und die Verbindungslatenz. Der Operator verwaltet PgBouncer-Instanzen nativ über die benutzerdefinierte Ressource PgBouncer.

PostgreSQL erstellt für jede Clientverbindung einen separaten Betriebssystemprozess. Hunderte gleichzeitige Verbindungen von Webdiensten, Mikrodiensten oder KI-Agenten können daher den Datenbankspeicher erschöpfen. PgBouncer befindet sich vor der Datenbank und bündelt viele kurzlebige Clientverbindungen (bis zu max_client_conn) in einem kleinen Pool langlebiger PostgreSQL-Serververbindungen (default_pool_size pro Nutzer/Datenbank-Paar, begrenzt auf max_db_connections).

1. PgBouncer bereitstellen

Stellen Sie einen PgBouncer-Pooler mit zwei Replikaten bereit, der mit dem Cluster adbo verknüpft ist:

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-Status prüfen

Beobachten Sie den PgBouncer-Status, bis PHASE den Wert Ready hat:

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

Prüfen Sie die ausgeführten PgBouncer-Pods und den Dienst:

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

3. Über PgBouncer verbinden

Verbinden Sie einen Client über den PgBouncer-Dienst an 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 leitet die Abfrage nahtlos an die primäre AlloyDB Omni-Datenbank weiter.

11. pgAdmin4 für den Zugriff auf die Datenbank bereitstellen

Sie können pgAdmin4 direkt im Kubernetes-Cluster ausführen, um eine webbasierte Verwaltungskonsole zum Abfragen, Verwalten und Prüfen von AlloyDB Omni bereitzustellen.

1. pgAdmin4 über Helm installieren

Installieren Sie pgadmin4 im 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"

In diesem Diagramm werden die Kubernetes-Ressourcen pgadmin4 (Deployment, Service, PersistentVolumeClaim) genannt und die Pods mit app=pgadmin4 gekennzeichnet, unabhängig vom Namen des Helm-Release (my-pgadmin).

Prüfen Sie, ob der pgAdmin4-Pod ausgeführt wird:

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

2. Port weiterleiten und auf Web-UI zugreifen

Führen Sie eine Portweiterleitung von pgAdmin4 an Ihre lokale Umgebung oder Cloud Shell durch:

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

kubectl port-forward wird so lange im Vordergrund ausgeführt, wie Sie die pgAdmin4-Web-UI verwenden. Öffnen Sie ein zweites Terminal (oder einen neuen Cloud Shell-Tab) für andere Befehle und drücken Sie in diesem Terminal Ctrl+C, wenn Sie mit dem nächsten Schritt fortfahren möchten.

Öffnen Sie die pgAdmin4-Weboberfläche:

  • Pfad 1 (Google Cloud Shell): Klicken Sie im Menü oben rechts auf den Button Webvorschau, wählen Sie Port ändern aus, geben Sie 5050 ein und klicken Sie auf Ändern und Vorschau.
  • Pfad 2 (lokale Workstation): Öffnen Sie http://localhost:5050 in Ihrem Browser, während der Befehl kubectl port-forward ausgeführt wird.

Melden Sie sich an mit:

  • E‑Mail-Adresse: admin@example.com
  • Passwort: AdminPassword123

3. AlloyDB Omni in pgAdmin4 registrieren

  1. Klicken Sie in pgAdmin4 mit der rechten Maustaste auf Server > Registrieren > Server….
  2. Auf dem Tab Allgemein:
    • Name: AlloyDB Omni Primary
  3. Auf dem Tab Verbindung:
    • Hostname/Adresse: al-adbo-rw-ilb.omni-demo.svc.cluster.local (oder al-omni-pgbouncer-pgb-svc.omni-demo.svc.cluster.local für PgBouncer)
    • Port: 5432 (oder 6432 für PgBouncer)
    • Wartungsdatenbank: postgres
    • Nutzername: postgres
    • Passwort: ChangeMe123
  4. Klicken Sie auf Speichern und prüfen Sie die aktive Datenbanksitzung und die Tabellen.

12. CPU und Arbeitsspeicher mit Wartung mit geringer Ausfallzeit (Low Downtime Maintenance, LDTM) skalieren

Wenn Sie Rechenleistung und Arbeitsspeicher in einer Produktionsdatenbank vertikal skalieren, führen herkömmliche Updates zu Unterbrechungen durch Datenbankneustarts. AlloyDB Omni bietet Wartung mit geringer Ausfallzeit (Low Downtime Maintenance, LDTM), um Updates über Replikate mit minimaler Unterbrechung der Anwendung bereitzustellen.

1. LDTM-Annotation aktivieren

Fügen Sie der DBCluster eine Annotation hinzu, um LDTM für Updates zu aktivieren:

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

2. CPU- und Arbeitsspeicherressourcen skalieren

Aktualisieren Sie die primären Ressourcen von cpu: 1, memory: 4Gi auf cpu: 2, memory: 8Gi:

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

3. LDTM-Skalierungsfortschritt überwachen

Beobachten Sie das Rolling Update und die Bedingungen für den Wechsel von Stand-by zu primär:

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

Beobachten Sie, wie die Pods nacheinander aktualisiert werden:

kubectl get pods -n omni-demo -w

LDTM bereitet zuerst die aktualisierte Standby-Instanz vor, prüft die Streaming-Replikation, führt einen schnellen Wechsel durch und aktualisiert die verbleibende Instanz ohne Dienstunterbrechungen.

Prüfen Sie die aktualisierte Ressourcenzuweisung:

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

13. Ressourcen bereinigen

Bereinigen Sie die in diesem Codelab bereitgestellten Ressourcen, um Clusterkapazität freizugeben und unnötige Kosten für Ihr Google Cloud-Konto zu vermeiden.

Wenn Sie die Bereinigung in einer neuen Terminalsitzung (Pfad 1) ausführen, sind die Umgebungsvariablen aus den vorherigen Schritten nicht mehr festgelegt. Exportieren Sie sie noch einmal mit denselben Werten, die Sie zuvor verwendet haben:

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. Datenbankarbeitslasten löschen (Pfad 1 und Pfad 2)

Markieren Sie beide Cluster als gelöscht, um die Webhook-Prüfungen für die Zulassung zu bestehen. Warten Sie, bis der Operator die DBCluster-Ressourcen entfernt hat, und löschen Sie dann den 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

Wenn Sie Ihren eigenen Kubernetes-Cluster verwendet haben (Pfad 2) und auch den AlloyDB Omni-Operator und cert-manager entfernen möchten:

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-Bucket und IAM-Dienstkonto löschen (nur Pfad 1)

Wenn Sie den Google Cloud Storage-Bucket und das Dienstkonto in Pfad 1 erstellt haben:

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-Cluster löschen (nur Pfad 1)

Wenn Sie einen GKE Autopilot-Cluster in Pfad 1 bereitgestellt haben:

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

14. Glückwunsch

Glückwunsch! Sie haben das Codelab „AlloyDB Omni on Kubernetes“ abgeschlossen.

Behandelte Themen

  • Sie haben einen GKE Autopilot-Cluster bereitgestellt (Pfad 1) oder einen vorhandenen Kubernetes-Cluster vorbereitet (Pfad 2).
  • cert-manager und den AlloyDB Omni Kubernetes-Operator über Helm bereitgestellt.
  • Eine AlloyDB Omni-DBCluster mit einer einzelnen Instanz wurde bereitgestellt.
  • Der Cluster wurde auf Hochverfügbarkeit (HA) mit synchronen Standby-Instanzen aktualisiert und das schreibgeschützte Standby-Routing wurde aktiviert.
  • Automatisierte BackupPlan-Ressourcen für lokalen nichtflüchtigen Speicher und Google Cloud Storage (GCS) erstellt.
  • On-Demand-Sicherungen durchgeführt und Datenbankwiederherstellungen validiert.
  • Wiederherstellung zu einem bestimmten Zeitpunkt (Point-in-Time Recovery, PITR) in einem neuen geklonten Datenbankcluster ausgeführt.
  • PgBouncer-Verbindungspooler für skalierbare Clientverbindungen bereitgestellt.
  • pgAdmin4 für die Datenbankverwaltung bereitgestellt und verbunden.
  • Ausführung von Low Downtime Maintenance (LDTM) zur dynamischen Skalierung von Rechen- und Arbeitsspeicherressourcen.

Nächste Schritte

15. Umfrage

Wie werden Sie diese Anleitung verwenden?

Nur durchlesen Durchlesen und die Übungen machen