Wdrażanie AlloyDB Omni w Kubernetes (GKE lub własny klaster) i zarządzanie nim

1. Wprowadzenie

Z tego ćwiczenia praktycznego dowiesz się, jak zainstalować operatora AlloyDB Omni Kubernetes (orkiestrator kontenerów) w klastrze Autopilota Google Kubernetes Engine (GKE) lub we własnym klastrze Kubernetes oraz jak zarządzać pełnymi przepływami pracy cyklu życia bazy danych i głównymi ścieżkami użytkownika.

AlloyDB Omni to dostępna do pobrania wersja AlloyDB, którą można uruchomić w dowolnym miejscu – od środowisk lokalnych po Google Cloud lub obliczenia brzegowe. Dzięki aranżerowi kontenerów AlloyDB Omni automatyzuje wysoką dostępność, automatyczne przełączanie awaryjne, samonaprawianie, konserwację kroczącą przy minimalnym czasie przestoju, pule połączeń, automatyczne kopie zapasowe i odzyskiwanie do określonego momentu.

Wybieranie ścieżki środowiska

Możesz ukończyć to ćwiczenie na 2 sposoby:

  1. Ścieżka 1. Masz konto Google Cloud (Autopilot w GKE) – udostępnij klaster Autopilota w GKE jako usługę w pełni zarządzaną za pomocą Google Cloud Shell lub konsoli Google Cloud.
  2. Ścieżka 2. Nie masz konta Google Cloud (użyj własnego klastra Kubernetes) – użyj istniejącego klastra Kubernetes (w wersji 1.21 lub nowszej) z narzędziami kubectl i helm skonfigurowanymi na stacji roboczej. Nie jest wymagane konto Google Cloud ani interfejs wiersza poleceń gcloud.

Wymagania wstępne

  • Podstawowa znajomość pojęć związanych z Kubernetes (kubectl, Helm, definicje zasobów niestandardowych).
  • Ścieżka 1 (Google Cloud / GKE Autopilot):
    • projekt Google Cloud z włączonymi płatnościami,
    • Dostęp do Google Cloud Shell lub stacji roboczej skonfigurowanej za pomocą gcloud, kubectl i helm.
  • Ścieżka 2 (użycie własnego klastra Kubernetes):
    • Klaster Kubernetes w wersji 1.21 lub nowszej z domyślną klasą StorageClass do dynamicznego udostępniania PersistentVolume.
    • Węzły robocze z jądrem Linuksa w wersji 4.18 lub nowszej z włączoną grupą cgroup v2 (x86-64/AMD64) oraz co najmniej 8 procesorami wirtualnymi i 24 GiB pamięci RAM do przydzielenia w klastrze.
    • stację roboczą skonfigurowaną z kubectl i helm połączoną z klastrem,

Czego się nauczysz

  • Jak udostępnić klaster GKE z Autopilotem (ścieżka 1) lub sprawdzić istniejący klaster Kubernetes (ścieżka 2).
  • jak zainstalować cert-manager i operatora AlloyDB Omni Kubernetes za pomocą Helma,
  • Jak wdrożyć jednoinstancyjną bazę danych AlloyDB Omni DBCluster.
  • Jak skalować do wysokiej dostępności (HA) z synchronicznymi instancjami rezerwowymi i włączyć funkcję rezerwowej instancji tylko do odczytu.
  • Jak skonfigurować zaplanowane automatyczne kopie zapasowe w lokalnym repozytorium (i opcjonalnie w Google Cloud Storage na ścieżce 1).
  • Jak tworzyć kopie zapasowe na żądanie i sprawdzać przywracanie danych do poprzedniego stanu.
  • jak przeprowadzić odzyskiwanie do określonego momentu (PITR) w nowym sklonowanym klastrze bazy danych.
  • Jak wdrożyć pulę połączeń PgBouncer na potrzeby skalowania połączeń klientów.
  • jak wdrożyć pgAdmin4, aby wizualnie zarządzać bazą danych i wysyłać do niej zapytania.
  • Jak przeprowadzić konserwację z krótką przerwą w działaniu (LDTM) na potrzeby skalowania zasobów procesora i pamięci.

Czego potrzebujesz

  • Ścieżka 1: Google Cloud Shell z fabrycznie zainstalowanymi narzędziami gcloud, kubectl i helm.
  • Ścieżka 2. Terminal z kubectl i helm połączony z klastrem Kubernetes.
  • Dokumentację znajdziesz w oficjalnym przewodniku wdrażania AlloyDB Omni.

2. Konfiguracja i wymagania

Wybierz Ścieżkę 1, jeśli używasz konta Google Cloud do utworzenia klastra GKE Autopilot, lub Ścieżkę 2, jeśli używasz własnego klastra Kubernetes bez konta Google Cloud.

Ścieżka 1. Konfiguracja projektu w chmurze Google (GKE Autopilot)

  1. W konsoli Google Cloud wybierz lub utwórz projekt w chmurze Google Cloud.
  2. Sprawdź, czy w projekcie są włączone płatności. Dowiedz się, jak sprawdzić stan płatności.
  3. Otwórz Google Cloud Shell, klikając ikonę Aktywuj Cloud Shell w prawym górnym rogu konsoli Google Cloud lub odwiedzając stronę shell.cloud.google.com. Cloud Shell udostępnia środowisko obliczeniowe z zainstalowanymi narzędziami gcloud, kubectl i helm.
  4. Ustaw identyfikator projektu jako zmienną środowiskową i skonfiguruj 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. Włącz wymagane interfejsy Google Cloud APIs dla GKE i Cloud Storage:
gcloud services enable container.googleapis.com \
    storage.googleapis.com \
    cloudresourcemanager.googleapis.com

Ścieżka 2. Konfiguracja klastra Bring-Your-Own (bez konta Google Cloud)

Jeśli nie masz konta Google Cloud i używasz własnego klastra Kubernetes, przed kontynuowaniem sprawdź w terminalu te wymagania wstępne:

  1. Sprawdź, czy kubectl i helm mogą połączyć się z klastrem i czy węzły są Ready:
kubectl get nodes
helm version
  1. Sprawdź, czy klaster ma domyślnyStorageClass oznaczony jako (default). Pliki manifestu DBCluster i BackupPlan dynamicznie udostępniają zasoby PersistentVolumeClaim przy użyciu domyślnego zasobu StorageClass klastra:
kubectl get storageclass

Jeśli żadna StorageClass nie jest oznaczona jako (default), przed przejściem dalej oznacz jedną z nich jako domyślną:

kubectl patch storageclass <YOUR_STORAGE_CLASS_NAME> \
  -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
  1. Sprawdź, czy węzły robocze spełniają wymagania operatora dotyczące sprzętu i systemu operacyjnego:
    • System operacyjny i jądro: jądro Linux w wersji 4.18 lub nowszej z włączoną funkcją cgroup v2 na węzłach x86-64/AMD64.
    • Pojemność klastra: co najmniej 8 procesorów wirtualnych i 24 GiB pamięci możliwej do przydzielenia w węzłach roboczych, aby jednocześnie uruchamiać instancje bazy danych o wysokiej dostępności (skalowane do 2 procesorów wirtualnych i 8 GiB każda w kroku 12), sklonowaną instancję odzyskiwania do określonego momentu, PgBouncer i pgAdmin4.
    • Dostęp do sieci: wychodzący dostęp do internetu umożliwiający pobieranie obrazów kontenerów z gcr.io/alloydb-omni, quay.io/jetstack i docker.io.

3. Zapewnianie dostępu do klastra Kubernetes lub łączenie się z nim

Jeśli wybierzesz ścieżkę 1 (konto Google Cloud), Autopilot GKE zapewni automatyczny, w pełni zarządzany tryb Kubernetes, w którym Google zarządza infrastrukturą klastra, obsługą administracyjną węzłów i autoskalowaniem. Klaster GKE Autopilot możesz utworzyć za pomocą Google Cloud CLI lub konsoli Google Cloud.

Opcja A. Utworzenie klastra GKE Autopilot za pomocą interfejsu wiersza poleceń (ścieżka 1)

W Cloud Shell uruchom to polecenie gcloud:

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

Opcja B: utworzenie klastra GKE Autopilot za pomocą konsoli (ścieżka 1)

  1. Otwórz Kubernetes Engine w konsoli Google Cloud.
  2. W panelu nawigacyjnym po lewej stronie kliknij Klastry.
  3. Kliknij Utwórz.
  4. W sekcji Autopilot w GKE kliknij Skonfiguruj.
  5. Podaj nazwę klastra (np. omni-autopilot-cluster) i wybierz preferowany region (us-central1).
  6. Kliknij Utwórz.

Weryfikacja połączenia klastra (ścieżka 1 i ścieżka 2)

Jeśli klaster GKE w trybie Autopilota został utworzony w ramach ścieżki 1, skonfiguruj dane logowania kubectl:

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

W przypadku ścieżki 1 i ścieżki 2 sprawdź połączenie z klastrem Kubernetes:

kubectl get nodes

4. Instalowanie wymagań wstępnych operatora i operatora

Operator AlloyDB Omni Kubernetes wymaga cert-manager do zarządzania certyfikatami TLS webhooka ruchu przychodzącego.

1. Zainstaluj cert-manager

Zainstaluj cert-manager za pomocą oficjalnej karty Helm:

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

Sprawdź, czy pody cert-manager są uruchomione:

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

2. Zainstaluj operatora AlloyDB Omni

Wdróż operator AlloyDB Omni Kubernetes w przestrzeni nazw alloydb-omni-system za pomocą Helma:

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

Sprawdź, czy pody operatora są w dobrym stanie i działają:

kubectl get pods -n alloydb-omni-system

5. Tworzenie klastra bazy danych z jedną instancją

W tym kroku utworzysz dedykowaną przestrzeń nazw aplikacji i wdrożysz AlloyDB Omni z jedną instancją DBCluster.

1. Tworzenie przestrzeni nazw i obiektu tajnego z danymi logowania administratora

Utwórz przestrzeń nazw omni-demo dla zbiorów zadań bazy danych:

kubectl create namespace omni-demo

Utwórz obiekt Kubernetes Secret, w którym będzie przechowywane hasło domyślnego administratora bazy danych postgres:

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. Wdrażanie klastra bazy danych z jedną instancją

Utwórz plik manifestu DBCluster z jedną instancją:

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. Sprawdzanie gotowości klastra

Monitoruj stan klastra, aż DBCLUSTERPHASE osiągnie wartość DBClusterReady. Początkowa obsługa administracyjna może potrwać kilka minut: operator musi utworzyć wolumin stały i pobrać obraz bazy danych, a w GKE Autopilot może być konieczne najpierw udostępnienie nowego węzła.

kubectl get dbcluster -n omni-demo -w

Naciśnij Ctrl+C, aby wyjść z trybu oglądania, gdy DBCLUSTERPHASE osiągnie DBClusterReady.

Przykładowe dane wyjściowe:

NAME   PRIMARYENDPOINT   PRIMARYPHASE   DBCLUSTERPHASE   HAREADYSTATUS   HAREADYREASON
adbo   10.128.0.45       Ready          DBClusterReady

Zanotuj adres IP PRIMARYENDPOINT, który jest adresem ClusterIP usługi Kubernetes al-adbo-rw-ilb z uprawnieniami do odczytu i zapisu. AlloyDB Omni nasłuchuje na domyślnym porcie PostgreSQL 5432.

Sprawdź zasoby, które operator uzgodnił z pojedynczego pliku manifestu DBCluster – poda bazy danych, żądania PersistentVolumeClaim DataDisk i usługi al-adbo-rw-ilb:

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

6. Przejście na wysoką dostępność i włączenie trybu gotowości tylko do odczytu

AlloyDB Omni zapewnia wbudowaną wysoką dostępność z replikacją strumieniową, automatycznym monitorowaniem stanu, automatycznym przełączaniem awaryjnym i obsługą replik do odczytu.

1. Włącz wysoką dostępność i możliwość repliki do odczytu

Zaktualizuj specyfikację DBCluster, aby skonfigurować 1 instancję w stanie gotowości i włączyć routing do instancji w stanie gotowości tylko do odczytu:

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

2. Sprawdzanie stabilizacji wysokiej dostępności

Poczekaj, aż instancja w stanie gotowości zostanie udostępniona i osiągnie prawidłową replikację strumieniową (HAREADYSTATUS osiągnie True, a HAREADYREASON osiągnie Ready), a następnie naciśnij Ctrl+C, aby wyjść z trybu obserwowania:

kubectl get dbcluster adbo -n omni-demo -w

Sprawdź stan HAReady:

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

Sprawdź, czy opublikowane są punkty końcowe do odczytu i zapisu oraz tylko do odczytu:

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

Przykładowe dane wyjściowe:

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

Punkt końcowy odczytu i zapisu (usługa al-adbo-rw-ilb) kieruje do głównej bazy danych, a punkt końcowy tylko do odczytu (usługa al-adbo-ro-ilb) rozdziela zapytania odczytu między instancje rezerwowe.

7. Konfigurowanie automatycznych planów tworzenia kopii zapasowych (lokalnych i GCS)

AlloyDB Omni zapewnia fizyczne kopie zapasowe i archiwizację WAL za pomocą zasobu niestandardowego BackupPlan. Możesz skonfigurować przechowywanie kopii zapasowych, automatyczne harmonogramy cron i miejsca docelowe kopii zapasowych (lokalne woluminy trwałe lub Google Cloud Storage).

1. Utwórz lokalny plan tworzenia kopii zapasowych

Utwórz zasób BackupPlan, który zapisuje kopie zapasowe w lokalnym miejscu na dane Kubernetes podłączonym do instancji bazy danych:

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

Sprawdź, czy lokalny plan tworzenia kopii zapasowych jest gotowy:

kubectl get backupplan backupplan-local -n omni-demo

Poczekaj, aż PHASE zgłosi Ready i zaplanowane zostanie NEXTBACKUPTIME.

2. Utworzenie planu kopii zapasowej GCS (ścieżka 1: tylko Google Cloud – opcjonalnie)

Aby przechowywać kopie zapasowe zewnętrznie w zasobniku Google Cloud Storage, utwórz zasobnik GCS, skonfiguruj obiekt tajny klucza konta usługi i zastosuj zasób niestandardowy BackupPlan.

  1. Utwórz zasobnik Cloud Storage:
export BUCKET_NAME="${PROJECT_ID}-omni-backups"
gcloud storage buckets create gs://${BUCKET_NAME} --location=${REGION}
  1. Utwórz konto usługi z uprawnieniami administratora obiektów Cloud Storage i utwórz dla niego klucz:

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. Utwórz obiekt tajny w przestrzeni nazw 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. Zastosuj plik manifestu GCS BackupPlan. Pole key to folder w zasobniku, w którym operator zapisuje kopie zapasowe. Musi zaczynać się od /.
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

Sprawdź stan GCS BackupPlan:

kubectl get backupplan backupplan-gcs -n omni-demo

Poczekaj, aż PHASE zgłosi Ready i zaplanowane zostanie NEXTBACKUPTIME.

8. Wstawianie danych, aktywowanie kopii zapasowej i testowanie przywracania

W tym kroku wypełnisz główną bazę danych początkowymi danymi, uruchomisz ręczne tworzenie kopii zapasowej na żądanie, dodasz kolejne dane i przywrócisz dane z kopii zapasowej, aby potwierdzić przywrócenie danych.

1. Wypełnianie danych początkowych

Uruchom tymczasowy pod klienta PostgreSQL, aby połączyć się z bazą danych za pomocą usługi odczytu i zapisu al-adbo-rw-ilb jako użytkownik 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;
  "

Gdy pojawi się prośba o podanie hasła, wpisz ChangeMe123. To jest hasło zakodowane w formacie base64 w obiekcie tajnym db-pw-adbo w kroku 5.

2. Aktywowanie kopii zapasowej na żądanie

Utwórz ręcznie zasób niestandardowy Backup odwołujący się do lokalnego zasobu BackupPlan:

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

Monitorowanie postępu tworzenia kopii zapasowej:

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

Poczekaj, aż stan PHASE zmieni się na Succeeded.

3. Mutate Data (Add New Records)

Wstaw dodatkowe rekordy po utworzeniu kopii zapasowej:

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

Baza danych zawiera teraz 4 wiersze.

4. Przywróć z kopii zapasowej

Aktywuj przywracanie do stanu zapisanego w 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

Monitoruj operację przywracania:

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

Poczekaj, aż PHASE osiągnie wartość ProvisionSucceeded, i sprawdź, czy DBCluster wraca do DBClusterReady:

kubectl get dbcluster adbo -n omni-demo -w

5. Sprawdzanie stanu przywróconych danych

Utwórz zapytanie do tabeli customers, aby sprawdzić, czy istnieją tylko rekordy sprzed utworzenia kopii zapasowej:

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

Dane wyjściowe potwierdzają, że obecne są tylko 2 wiersze (Alpha Co i Beta LLC), co oznacza, że baza danych została przywrócona do stanu z kopii zapasowej.

9. Odzyskiwanie do określonego momentu (PITR) w sklonowanej bazie danych

Odzyskiwanie do określonego momentu (PITR) umożliwia przywrócenie bazy danych do dowolnej sekundy w oknie odzyskiwania za pomocą podstawowych kopii zapasowych i logów strumienia WAL, co pozwala na udostępnienie przywróconych danych w nowym sklonowanym klastrze bazy danych.

Ponieważ operator stale archiwizuje log zapisywany z wyprzedzeniem (WAL), PITR umożliwia odzyskiwanie danych po przypadkowych błędach ludzkich lub błędach aplikacji, takich jak niezamierzone polecenie DELETE lub DROP TABLE o godzinie 14:15:00. W tym celu klonuje bazę danych do stanu z sekundy przed wystąpieniem błędu (14:14:59) bez wpływu na pierwotny klaster.

1. Zapisywanie bieżącej sygnatury czasowej i modyfikowanie danych

Pobierz bieżącą sygnaturę czasową UTC:

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

Wstaw rekord testowy, który reprezentuje niechcianą modyfikację po tej sygnaturze czasowej:

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. Przeprowadź odzyskiwanie do określonego momentu

Zastosuj zasób niestandardowy Restore, który konfiguruje pointInTime i 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

Monitoruj operację przywracania, aż PHASE osiągnie wartość ProvisionSucceeded:

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

3. Weryfikowanie sklonowanej bazy danych

Po zakończeniu przywracania zaczekaj, aż nowa sklonowana instancja DBCluster osiągnie stan DBClusterReady (naciśnij Ctrl+C, aby wyjść z trybu obserwowania):

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

Wyślij zapytanie do sklonowanej bazy danych adbo-cloned za pomocą usługi odczytu i zapisu 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;
  "

Zauważ, że w sklonowanym klastrze nie ma tabeli Unwanted Record Post-Timestamp, co oznacza, że odzyskiwanie do określonego momentu przebiegło prawidłowo.

10. Wdrażanie puli połączeń PgBouncer

Agregacja połączeń zmniejsza narzut pamięci bazy danych i opóźnienie połączenia. Operator zarządza instancjami PgBouncer natywnie za pomocą zasobu niestandardowego PgBouncer.

PostgreSQL tworzy osobny proces systemu operacyjnego dla każdego połączenia klienta, więc setki jednoczesnych połączeń z usług internetowych, mikroserwisów lub agentów AI mogą wyczerpać pamięć bazy danych. PgBouncer znajduje się przed bazą danych i multipleksuje wiele krótkotrwałych połączeń klienta (do max_client_conn) w małą pulę długotrwałych połączeń z serwerem PostgreSQL (default_pool_size na parę użytkownik/baza danych, ograniczone do max_db_connections).

1. Wdrażanie PgBouncera

Wdróż pulę PgBouncer z 2 replikami połączoną z klastrem 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. Sprawdzanie stanu PgBouncer

Obserwuj stan PgBouncer, aż PHASE będzie Ready:

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

Sprawdź działające pody i usługę PgBouncer:

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

3. Połącz przez PgBouncer

Połącz klienta przez usługę PgBouncer na porcie 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 bezproblemowo przekazuje zapytanie do głównej bazy danych AlloyDB Omni.

11. Wdrażanie pgAdmin4 w celu uzyskania dostępu do bazy danych

Możesz uruchomić pgAdmin4 bezpośrednio w klastrze Kubernetes, aby udostępnić internetową konsolę administracyjną do wysyłania zapytań, zarządzania i sprawdzania AlloyDB Omni.

1. Instalowanie pgAdmin4 za pomocą Helma

thought Zainstaluj pgadmin4 w przestrzeni nazw 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"

Ten wykres nazywa zasoby Kubernetes pgadmin4 (wdrożenie, usługa, PersistentVolumeClaim) i oznacza pody etykietą app=pgadmin4, niezależnie od nazwy wersji Helm (my-pgadmin).

Sprawdź, czy pod pgAdmin4 jest uruchomiony:

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

2. Przekierowanie portu i dostęp do internetowego interfejsu użytkownika

Przekieruj port pgAdmin4 do środowiska lokalnego lub Cloud Shell:

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

kubectl port-forward działa na pierwszym planie, dopóki korzystasz z interfejsu internetowego pgAdmin4. Otwórz drugi terminal (lub nową kartę Cloud Shell) na potrzeby innych poleceń i naciśnij Ctrl+C w tym terminalu, gdy będziesz gotowy(-a) do przejścia do następnego kroku.

Otwórz interfejs internetowy pgAdmin4:

  • Ścieżka 1 (Google Cloud Shell): kliknij przycisk Podgląd w przeglądarce w prawym górnym menu, wybierz Zmień port, wpisz 5050 i kliknij Zmień i wyświetl podgląd.
  • Ścieżka 2 (lokalna stacja robocza): otwórz http://localhost:5050 w przeglądarce, gdy polecenie kubectl port-forward jest uruchomione.

Zaloguj się, używając:

  • E-mail: admin@example.com
  • Hasło: AdminPassword123

3. Rejestrowanie AlloyDB Omni w pgAdmin4

  1. W pgAdmin4 kliknij prawym przyciskiem myszy Servers (Serwery) > Register (Zarejestruj) > Server... (Serwer…).
  2. Na karcie Ogólne:
    • Nazwa: AlloyDB Omni Primary
  3. Na karcie Połączenie:
    • Host name/address (Nazwa/adres hosta): al-adbo-rw-ilb.omni-demo.svc.cluster.local (lub al-omni-pgbouncer-pgb-svc.omni-demo.svc.cluster.local w przypadku PgBouncer)
    • Port: 5432 (lub 6432 w przypadku PgBouncer)
    • Konserwacyjna baza danych: postgres
    • Nazwa użytkownika: postgres
    • Hasło: ChangeMe123
  4. Kliknij Zapisz i sprawdź aktywną sesję bazy danych oraz tabele.

12. Skalowanie procesora i pamięci przy użyciu konserwacji z krótkim czasem przestoju (LDTM)

Podczas skalowania pionowego mocy obliczeniowej i pamięci w produkcyjnej bazie danych tradycyjne aktualizacje powodują zakłócenia związane z ponownym uruchomieniem bazy danych. AlloyDB Omni udostępnia funkcję konserwacji z krótkim czasem przestoju (LDTM), która umożliwia wdrażanie aktualizacji kroczących w replikach przy minimalnych zakłóceniach działania aplikacji.

1. Włącz adnotacje LDTM

Dodaj adnotację do DBCluster, aby włączyć LDTM na potrzeby aktualizacji:

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

2. Skalowanie zasobów procesora i pamięci

Zaktualizuj zasoby podstawowe z cpu: 1, memory: 4Gi na cpu: 2, memory: 8Gi:

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

3. Monitorowanie postępów skalowania LDTM

Monitoruj aktualizację kroczącą i warunki przełączenia z trybu gotowości na tryb podstawowy:

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

Obserwuj, jak pody są płynnie aktualizowane:

kubectl get pods -n omni-demo -w

LDTM najpierw przygotowuje zaktualizowaną instancję rezerwową, weryfikuje replikację strumieniową, wykonuje szybkie przełączenie i aktualizuje pozostałą instancję bez przerw w działaniu usługi.

Sprawdź zaktualizowaną alokację zasobów:

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

13. Czyszczenie zasobów

Aby zwolnić miejsce w klastrze i uniknąć niepotrzebnych opłat na koncie Google Cloud, wyczyść zasoby udostępnione podczas tego ćwiczenia w programowaniu.

Jeśli przeprowadzasz czyszczenie w nowej sesji terminala (ścieżka 1), zmienne środowiskowe z wcześniejszych kroków nie są już ustawione. Wyeksportuj je ponownie z tymi samymi wartościami, które były używane wcześniej:

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. Usuwanie zbiorów zadań bazy danych (ścieżka 1 i ścieżka 2)

Oznacz oba klastry jako usunięte, aby przejść testy webhooka dopuszczającego, poczekaj, aż operator usunie zasoby DBCluster, a następnie usuń przestrzeń nazw:

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

Jeśli używasz własnego klastra Kubernetes (ścieżka 2) i chcesz też usunąć operatora AlloyDB Omni oraz 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. Usuwanie zasobnika GCS i konta usługi uprawnień (tylko ścieżka 1)

Jeśli zasobnik Cloud Storage i konto usługi Google Cloud Storage zostały utworzone w ramach ścieżki 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. Usuwanie klastra GKE (tylko ścieżka 1)

Jeśli klaster GKE Autopilot został udostępniony w ramach ścieżki 1:

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

14. Gratulacje

Gratulacje! Udało Ci się ukończyć ćwiczenie dotyczące AlloyDB Omni w Kubernetes.

Omówione zagadnienia

  • udostępniony klaster GKE w trybie Autopilota (ścieżka 1) lub przygotowany istniejący klaster Kubernetes (ścieżka 2);
  • Wdrożono cert-manager i operator AlloyDB Omni Kubernetes za pomocą Helma.
  • Wdrożono instancję AlloyDB Omni DBCluster.
  • Uaktualniono klaster do wysokiej dostępności z synchronicznymi instancjami rezerwowymi i włączono routing instancji rezerwowych tylko do odczytu.
  • Utworzono automatyczne zasoby BackupPlan zarówno dla lokalnej pamięci trwałej, jak i Google Cloud Storage (GCS).
  • Tworzenie kopii zapasowych na żądanie i sprawdzanie przywracania bazy danych.
  • Wykonano odzyskiwanie do określonego momentu (PITR) do nowego sklonowanego klastra bazy danych.
  • Wdrożono pulę połączeń PgBouncer na potrzeby skalowalnych połączeń klientów.
  • Wdrożono i połączono pgAdmin4 na potrzeby zarządzania bazą danych.
  • wykonano konserwację z krótkim czasem przestoju (LDTM), aby dynamicznie skalować zasoby obliczeniowe i pamięci.

Następne kroki

15. Ankieta

Jak będziesz korzystać z tego samouczka?

Tylko przeczytać Przeczytać i wykonać ćwiczenia