Déployer et gérer AlloyDB Omni sur Kubernetes (GKE ou votre propre cluster)

1. Introduction

Dans cet atelier de programmation, vous allez apprendre à installer l'opérateur Kubernetes AlloyDB Omni (l'orchestrateur de conteneurs) sur un cluster Google Kubernetes Engine (GKE) Autopilot ou sur votre propre cluster Kubernetes, et à gérer les workflows complets du cycle de vie des bases de données et les parcours utilisateur critiques (CUJ).

AlloyDB Omni est une édition téléchargeable d'AlloyDB conçue pour s'exécuter n'importe où, des environnements sur site à Google Cloud ou à l'edge computing. Avec l'outil d'orchestration de conteneurs, AlloyDB Omni automatise la haute disponibilité, les basculements automatiques, l'autoréparation, la maintenance progressive avec un temps d'arrêt minimal, le regroupement de connexions, les sauvegardes automatiques et la récupération à un moment précis.

Choisir votre parcours d'environnement

Vous pouvez suivre cet atelier de programmation de deux manières :

  1. Option 1 : Vous disposez d'un compte Google Cloud (GKE Autopilot) : provisionnez un cluster GKE Autopilot entièrement géré à l'aide de Google Cloud Shell ou de la console Google Cloud.
  2. Parcours 2 : Vous n'avez pas de compte Google Cloud (apportez votre propre cluster Kubernetes) : utilisez un cluster Kubernetes existant (v1.21 ou ultérieure) avec kubectl et helm configurés sur votre poste de travail. Aucun compte Google Cloud ni aucune CLI gcloud ne sont requis.

Prérequis

  • Connaissances de base des concepts Kubernetes (kubectl, Helm, définitions de ressources personnalisées).
  • Pour le parcours 1 (Google Cloud / GKE Autopilot) :
    • Un projet Google Cloud avec facturation activée.
    • Accès à Google Cloud Shell ou à un poste de travail configuré avec gcloud, kubectl et helm.
  • Pour le parcours 2 (Utiliser votre propre cluster Kubernetes) :
    • Un cluster Kubernetes exécutant la version 1.21 ou une version ultérieure avec un StorageClass par défaut pour le provisionnement dynamique de PersistentVolume.
    • Nœuds de calcul exécutant le noyau Linux 4.18 ou version ultérieure avec cgroup v2 activé (x86-64/AMD64) et au moins 8 vCPU et 24 Gio de RAM allouable sur le cluster.
    • Une station de travail configurée avec kubectl et helm connectée à votre cluster.

Points abordés

  • Comment provisionner un cluster GKE Autopilot (parcours 1) ou valider un cluster Kubernetes existant (parcours 2).
  • Comment installer cert-manager et l'opérateur Kubernetes AlloyDB Omni via Helm.
  • Déployer un DBCluster AlloyDB Omni à instance unique.
  • Comment passer à la haute disponibilité avec des instances de secours synchrones et activer la fonctionnalité d'instance de secours en lecture seule.
  • Configurer des sauvegardes automatiques planifiées dans un espace de stockage de dépôt local (et éventuellement dans Google Cloud Storage sur le chemin 1).
  • Comment effectuer des sauvegardes à la demande et vérifier la restauration des données à un état antérieur.
  • Effectuer une récupération à un moment précis (PITR) sur un nouveau cluster de base de données cloné
  • Déployer le pooling de connexions PgBouncer pour le scaling des connexions client.
  • Déployer pgAdmin4 pour gérer et interroger visuellement la base de données
  • Exécuter une maintenance à faible temps d'arrêt (LDTM) pour le scaling des ressources de processeur et de mémoire

Prérequis

  • Option 1 : Google Cloud Shell avec les utilitaires gcloud, kubectl et helm préinstallés.
  • Option 2 : un terminal avec kubectl et helm connecté à votre cluster Kubernetes.
  • Pour obtenir de la documentation de référence, consultez le guide de déploiement officiel d'AlloyDB Omni.

2. Préparation

Choisissez le parcours 1 si vous utilisez un compte Google Cloud pour créer un cluster GKE Autopilot, ou le parcours 2 si vous utilisez votre propre cluster Kubernetes sans compte Google Cloud.

Parcours 1 : Configuration d'un projet Google Cloud (GKE Autopilot)

  1. Dans la console Google Cloud, sélectionnez ou créez un projet Google Cloud.
  2. Vérifiez que la facturation est activée sur votre projet. Découvrez comment vérifier l'état de la facturation.
  3. Ouvrez Google Cloud Shell en cliquant sur l'icône Activer Cloud Shell en haut à droite de la console Google Cloud ou en accédant à shell.cloud.google.com. Cloud Shell provisionne un environnement de calcul chargé avec gcloud, kubectl et helm.
  4. Définissez l'ID de votre projet en tant que variable d'environnement et configurez 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. Activez les API Google Cloud requises pour GKE et Cloud Storage :
gcloud services enable container.googleapis.com \
    storage.googleapis.com \
    cloudresourcemanager.googleapis.com

Parcours 2 : Configuration d'un cluster BYOC (sans compte Google Cloud)

Si vous n'avez pas de compte Google Cloud et que vous utilisez votre propre cluster Kubernetes, vérifiez les conditions préalables suivantes depuis votre terminal avant de continuer :

  1. Vérifiez que kubectl et helm peuvent atteindre votre cluster et que vos nœuds sont Ready :
kubectl get nodes
helm version
  1. Vérifiez que votre cluster dispose d'un StorageClass par défaut marqué (default). Les fichiers manifestes DBCluster et BackupPlan provisionnent de manière dynamique les PersistentVolumeClaims à l'aide de la StorageClass par défaut du cluster :
kubectl get storageclass

Si aucun StorageClass n'est marqué comme (default), désignez-en un par défaut avant de continuer :

kubectl patch storageclass <YOUR_STORAGE_CLASS_NAME> \
  -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
  1. Vérifiez que vos nœuds de calcul répondent aux exigences matérielles et d'OS de l'opérateur :
    • OS et noyau : noyau Linux 4.18 ou version ultérieure avec cgroup v2 activé sur les nœuds x86-64/AMD64.
    • Capacité du cluster : au moins 8 vCPU et 24 Gio de mémoire allouable sur vos nœuds de calcul pour exécuter simultanément les instances de base de données à haute disponibilité (ajustées à 2 vCPU et 8 Gio chacune à l'étape 12), l'instance clonée PITR, PgBouncer et pgAdmin4.
    • Accès réseau : accès à Internet sortant pour extraire des images de conteneurs depuis gcr.io/alloydb-omni, quay.io/jetstack et docker.io.

3. Provisionner votre cluster Kubernetes ou s'y connecter

Si vous suivez le parcours 1 (compte Google Cloud), GKE Autopilot fournit un mode Kubernetes entièrement géré et sans intervention, dans lequel Google gère l'infrastructure du cluster, le provisionnement des nœuds et l'autoscaling. Vous pouvez créer votre cluster GKE Autopilot à l'aide de la Google Cloud CLI ou de la console Google Cloud.

Option A : Créer un cluster GKE Autopilot via la CLI (chemin 1)

Exécutez la commande gcloud suivante dans Cloud Shell :

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

Option B : Créer un cluster GKE Autopilot via la console (chemin 1)

  1. Ouvrez Kubernetes Engine dans la console Google Cloud.
  2. Dans le volet de navigation de gauche, cliquez sur Clusters.
  3. Cliquez sur Créer.
  4. Dans la section GKE Autopilot, cliquez sur Configurer.
  5. Spécifiez le nom de votre cluster (par exemple, omni-autopilot-cluster) et sélectionnez la région de votre choix (us-central1).
  6. Cliquez sur Créer.

Vérifier la connectivité du cluster (chemin 1 et chemin 2)

Si vous avez créé un cluster GKE Autopilot dans le parcours 1, configurez vos identifiants kubectl :

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

Pour le chemin 1 et le chemin 2, vérifiez la connectivité à votre cluster Kubernetes :

kubectl get nodes

4. Installer les prérequis de l'opérateur et l'opérateur

L'opérateur Kubernetes AlloyDB Omni nécessite cert-manager pour gérer les certificats TLS des webhooks d'admission.

1. Installer cert-manager

Installez cert-manager à l'aide de son chart Helm officiel :

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

Vérifiez que les pods cert-manager sont en cours d'exécution :

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

2. Installer l'opérateur AlloyDB Omni

Déployez l'opérateur Kubernetes AlloyDB Omni dans l'espace de noms alloydb-omni-system à l'aide de 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

Vérifiez que les pods de l'opérateur sont opérationnels et en cours d'exécution :

kubectl get pods -n alloydb-omni-system

5. Créer un cluster de bases de données à instance unique

Dans cette étape, vous allez créer un espace de noms d'application dédié et déployer une instance unique AlloyDB Omni DBCluster.

1. Créer un espace de noms et un secret d'identifiants d'administrateur

Créez un espace de noms omni-demo pour les charges de travail de base de données :

kubectl create namespace omni-demo

Créez un secret Kubernetes stockant le mot de passe de l'utilisateur administrateur de base de données postgres par défaut :

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. Déployer un DBCluster à instance unique

Créez un fichier manifeste DBCluster à instance unique :

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. Vérifier l'aptitude du cluster

Surveillez l'état du cluster jusqu'à ce que DBCLUSTERPHASE atteigne DBClusterReady. Le provisionnement initial peut prendre plusieurs minutes : l'opérateur doit créer le volume persistant et extraire l'image de la base de données. Sur GKE Autopilot, un nouveau nœud peut devoir être provisionné au préalable.

kubectl get dbcluster -n omni-demo -w

Appuyez sur Ctrl+C pour quitter le mode de surveillance une fois que DBCLUSTERPHASE atteint DBClusterReady.

Exemple de résultat :

NAME   PRIMARYENDPOINT   PRIMARYPHASE   DBCLUSTERPHASE   HAREADYSTATUS   HAREADYREASON
adbo   10.128.0.45       Ready          DBClusterReady

Notez l'adresse IP PRIMARYENDPOINT, qui est l'adresse ClusterIP du service Kubernetes en lecture-écriture al-adbo-rw-ilb. AlloyDB Omni écoute sur le port PostgreSQL par défaut 5432.

Inspectez les ressources que l'opérateur a rapprochées à partir du fichier manifeste DBCluster unique : le pod de base de données, le PersistentVolumeClaim DataDisk et le service al-adbo-rw-ilb :

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

6. Passer à la haute disponibilité (HA) et activer la mise en veille en lecture seule

AlloyDB Omni offre une haute disponibilité intégrée avec réplication en streaming, surveillance automatique de l'état, basculement automatique et diffusion d'instances répliquées avec accès en lecture.

1. Activer la haute disponibilité et la capacité d'instance répliquée avec accès en lecture

Mettez à jour la spécification DBCluster pour configurer une instance de secours et activer le routage de secours en lecture seule :

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

2. Vérifier la stabilisation de la haute disponibilité

Attendez que l'instance de secours soit provisionnée et que la réplication en flux continu soit opérationnelle (HAREADYSTATUS atteint True et HAREADYREASON atteint Ready), puis appuyez sur Ctrl+C pour quitter le mode d'observation :

kubectl get dbcluster adbo -n omni-demo -w

Vérifiez la condition d'état HAReady :

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

Vérifiez que les points de terminaison en lecture-écriture et en lecture seule sont publiés :

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

Exemple de résultat :

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

Le point de terminaison en lecture-écriture (service al-adbo-rw-ilb) redirige vers la base de données principale, tandis que le point de terminaison en lecture seule (service al-adbo-ro-ilb) distribue les requêtes de lecture entre les instances de secours.

7. Configurer des plans de sauvegarde automatisés (locaux et GCS)

AlloyDB Omni fournit des sauvegardes physiques et l'archivage WAL via la ressource personnalisée BackupPlan. Vous pouvez configurer la conservation des sauvegardes, les planifications cron automatisées et les cibles de sauvegarde (volumes persistants locaux ou Google Cloud Storage).

1. Créer un BackupPlan local

Créez un BackupPlan qui écrit les sauvegardes dans l'espace de stockage Kubernetes local associé aux instances de base de données :

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

Vérifiez que le BackupPlan local est prêt :

kubectl get backupplan backupplan-local -n omni-demo

Attendez que PHASE indique Ready et que NEXTBACKUPTIME soit planifié.

2. Créer un plan de sauvegarde GCS (chemin 1 : Google Cloud uniquement, facultatif)

Pour stocker des sauvegardes en externe dans un bucket Google Cloud Storage, créez un bucket GCS, configurez un secret de clé de compte de service et appliquez un BackupPlan cloud.

  1. Créez un bucket Cloud Storage :
export BUCKET_NAME="${PROJECT_ID}-omni-backups"
gcloud storage buckets create gs://${BUCKET_NAME} --location=${REGION}
  1. Créez un compte de service avec les autorisations d'administrateur des objets Storage, puis créez une clé pour ce compte :

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. Créez le secret dans votre espace de noms 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. Appliquez le fichier manifeste GCS BackupPlan. Le champ key est le dossier du bucket dans lequel l'opérateur écrit les sauvegardes. Il doit commencer par /.
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

Vérifiez l'état du plan de sauvegarde GCS :

kubectl get backupplan backupplan-gcs -n omni-demo

Attendez que PHASE indique Ready et que NEXTBACKUPTIME soit planifié.

8. Insérer des données, déclencher la sauvegarde et tester la restauration

Dans cette étape, vous allez insérer des données initiales dans la base de données principale, déclencher une sauvegarde manuelle à la demande, ajouter des données supplémentaires et restaurer la sauvegarde pour prouver le rollback des données.

1. Insérer les données initiales

Exécutez un pod client PostgreSQL temporaire pour vous connecter à la base de données via son service de lecture/écriture al-adbo-rw-ilb en tant qu'utilisateur 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;
  "

Lorsque vous êtes invité à saisir le mot de passe, indiquez ChangeMe123. Il s'agit du mot de passe que vous avez encodé en base64 dans le secret db-pw-adbo à l'étape 5.

2. Déclencher une sauvegarde à la demande

Créez une ressource personnalisée Backup manuelle faisant référence à votre BackupPlan local :

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

Surveillez la progression de la sauvegarde :

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

Attendez que PHASE passe à Succeeded.

3. Modifier des données (ajouter des enregistrements)

Insérez des enregistrements supplémentaires après la sauvegarde :

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

La base de données contient désormais quatre lignes.

4. Restaurer à partir d'une sauvegarde

Déclenchez une restauration de l'état capturé dans 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

Surveillez l'opération de restauration :

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

Attendez que PHASE atteigne ProvisionSucceeded, puis vérifiez que DBCluster revient à DBClusterReady :

kubectl get dbcluster adbo -n omni-demo -w

5. Vérifier l'état des données restaurées

Interrogez la table customers pour vérifier que seuls les enregistrements antérieurs à la sauvegarde existent :

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

Le résultat confirme que seules deux lignes (Alpha Co et Beta LLC) sont présentes, ce qui prouve que la base de données a été restaurée à l'état exact de la sauvegarde.

9. Récupération à un moment précis (PITR) vers une base de données clonée

La récupération à un moment précis (PITR) permet de restaurer une base de données à n'importe quelle seconde de la fenêtre de récupération à l'aide de sauvegardes de base et de journaux de flux WAL, en provisionnant les données restaurées dans un nouveau cluster de bases de données cloné.

Comme l'opérateur archive en continu le journal WAL (Write-Ahead Log), la récupération PITR vous permet de récupérer des données après des erreurs humaines ou d'application accidentelles (par exemple, une commande DELETE ou DROP TABLE involontaire à 14h15) en clonant la base de données à la seconde exacte avant l'erreur (14h14m59s), sans toucher au cluster d'origine.

1. Enregistrer le code temporel actuel et modifier les données

Récupérez le code temporel UTC actuel :

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

Insérez un enregistrement de test représentant une modification indésirable après ce code temporel :

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. Effectuer une restauration à un moment précis

Appliquez la ressource personnalisée Restore en configurant pointInTime et 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

Surveillez l'opération de restauration jusqu'à ce que PHASE atteigne ProvisionSucceeded :

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

3. Vérifier la base de données clonée

Une fois la restauration terminée, attendez que le nouveau DBCluster cloné atteigne l'état DBClusterReady (appuyez sur Ctrl+C pour quitter le mode d'observation) :

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

Interrogez la base de données clonée adbo-cloned via son service de lecture/écriture 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;
  "

Notez que Unwanted Record Post-Timestamp est absent du cluster cloné, ce qui démontre une récupération précise au moment cible exact.

10. Déployer le pooler de connexions PgBouncer

Le regroupement de connexions réduit la surcharge de mémoire de la base de données et la latence de connexion. L'opérateur gère les instances PgBouncer de manière native via la ressource personnalisée PgBouncer.

PostgreSQL crée un processus de système d'exploitation distinct pour chaque connexion client. Par conséquent, des centaines de connexions simultanées provenant de services Web, de microservices ou d'agents IA peuvent épuiser la mémoire de la base de données. PgBouncer se trouve devant la base de données et multiplexe de nombreuses connexions client de courte durée (jusqu'à max_client_conn) sur un petit pool de connexions de serveur PostgreSQL de longue durée (default_pool_size par paire utilisateur/base de données, plafonné à max_db_connections).

1. Déployer PgBouncer

Déployez un pooler PgBouncer à deux instances répliquées associé au 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. Vérifier l'état de PgBouncer

Surveillez l'état de PgBouncer jusqu'à ce que PHASE soit Ready :

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

Vérifiez les pods et le service PgBouncer en cours d'exécution :

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

3. Se connecter via PgBouncer

Connectez un client via le service PgBouncer sur le 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 transmet la requête de manière transparente à la base de données AlloyDB Omni principale.

11. Déployer pgAdmin4 pour accéder à la base de données

Vous pouvez exécuter pgAdmin4 directement dans le cluster Kubernetes pour fournir une console d'administration Web permettant d'interroger, de gérer et d'inspecter AlloyDB Omni.

1. Installer pgAdmin4 via Helm

Installez pgadmin4 dans l'espace de noms 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"

Ce chart nomme ses ressources Kubernetes pgadmin4 (Deployment, Service, PersistentVolumeClaim) et ajoute l'étiquette app=pgadmin4 à ses pods, quel que soit le nom de la version Helm (my-pgadmin).

Vérifiez que le pod pgAdmin4 est en cours d'exécution :

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

2. Transférer le port et accéder à l'UI Web

Transférez pgAdmin4 vers votre environnement local ou Cloud Shell :

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

kubectl port-forward continue de s'exécuter au premier plan tant que vous utilisez l'UI Web pgAdmin4. Ouvrez un deuxième terminal (ou un nouvel onglet Cloud Shell) pour les autres commandes, puis appuyez sur Ctrl+C dans ce terminal lorsque vous êtes prêt à passer à l'étape suivante.

Ouvrez l'interface Web pgAdmin4 :

  • Option 1 (Google Cloud Shell) : cliquez sur le bouton Aperçu sur le Web dans le menu en haut à droite, sélectionnez Modifier le port, saisissez 5050, puis cliquez sur Modifier et prévisualiser.
  • Option 2 (station de travail locale) : ouvrez http://localhost:5050 dans votre navigateur pendant que la commande kubectl port-forward est en cours d'exécution.

Se connecter avec :

  • Adresse e-mail : admin@example.com
  • Mot de passe : AdminPassword123

3. Enregistrer AlloyDB Omni dans pgAdmin4

  1. Dans pgAdmin4, effectuez un clic droit sur Servers > Register > Server... (Serveurs > Enregistrer > Serveur...).
  2. Sous l'onglet Général :
    • Nom : AlloyDB Omni Primary
  3. Sous l'onglet Connexion :
    • Nom d'hôte/adresse : al-adbo-rw-ilb.omni-demo.svc.cluster.local (ou al-omni-pgbouncer-pgb-svc.omni-demo.svc.cluster.local pour PgBouncer)
    • Port : 5432 (ou 6432 pour PgBouncer)
    • Base de données de maintenance : postgres
    • Nom d'utilisateur : postgres
    • Mot de passe : ChangeMe123
  4. Cliquez sur Enregistrer, puis vérifiez la session de base de données et les tables actives.

12. Procéder au scaling du processeur et de la mémoire avec la maintenance à faible temps d'arrêt (LDTM)

Lorsque vous effectuez un scaling vertical du calcul et de la mémoire sur une base de données de production, les mises à jour traditionnelles entraînent des interruptions de redémarrage de la base de données. AlloyDB Omni propose la maintenance à faible temps d'arrêt (LDTM) pour déployer les mises à jour progressives sur les instances répliquées avec un minimum d'interruption de l'application.

1. Activer l'annotation LDTM

Annotez le DBCluster pour activer le LDTM pour les mises à jour :

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

2. Procéder au scaling des ressources de processeur et de mémoire

Mettez à jour les ressources principales de cpu: 1, memory: 4Gi vers cpu: 2, memory: 8Gi :

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

3. Surveiller la progression du scaling de LDTM

Surveillez la mise à jour progressive et les conditions de basculement de l'instance de secours vers l'instance principale :

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

Observez le déploiement progressif des pods :

kubectl get pods -n omni-demo -w

Le LDTM prépare d'abord l'instance de secours mise à jour, vérifie la réplication en flux continu, exécute un basculement rapide et met à jour l'instance restante sans interruption de service.

Vérifiez l'allocation des ressources mise à jour :

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

13. Nettoyer les ressources

Pour libérer de la capacité de cluster et éviter des frais inutiles sur votre compte Google Cloud, nettoyez les ressources provisionnées lors de cet atelier de programmation.

Si vous effectuez le nettoyage dans une nouvelle session de terminal (chemin 1), les variables d'environnement des étapes précédentes ne sont plus définies. Réexportez-les avec les mêmes valeurs que celles que vous avez utilisées précédemment :

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. Supprimer les charges de travail de base de données (parcours 1 et parcours 2)

Marquez les deux clusters comme supprimés pour passer les vérifications du webhook d'admission, attendez que l'opérateur supprime les ressources DBCluster, puis supprimez l'espace de noms :

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

Si vous avez utilisé votre propre cluster Kubernetes (chemin 2) et que vous souhaitez également supprimer l'opérateur AlloyDB Omni et 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. Supprimer le bucket GCS et le compte de service IAM (parcours 1 uniquement)

Si vous avez créé le bucket Google Cloud Storage et le compte de service dans le Parcours 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. Supprimer le cluster GKE (chemin 1 uniquement)

Si vous avez provisionné un cluster GKE Autopilot dans le parcours 1 :

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

14. Félicitations

Félicitations ! Vous avez terminé l'atelier de programmation AlloyDB Omni sur Kubernetes.

Points abordés

  • Vous avez provisionné un cluster GKE Autopilot (parcours 1) ou préparé un cluster Kubernetes existant (parcours 2).
  • Déploiement de cert-manager et de l'opérateur Kubernetes AlloyDB Omni via Helm.
  • Déployé une instance unique AlloyDB Omni DBCluster.
  • Mise à niveau du cluster vers la haute disponibilité (HA) avec des instances de secours synchrones et activation du routage de secours en lecture seule.
  • Création de ressources BackupPlan automatisées pour le stockage persistant local et Google Cloud Storage (GCS).
  • Effectuer des sauvegardes à la demande et valider les restaurations de bases de données.
  • Exécution d'une récupération à un moment précis (PITR) sur un nouveau cluster de bases de données cloné.
  • Déploiement d'un pooler de connexions PgBouncer pour les connexions client évolutives.
  • Déploiement et connexion de pgAdmin4 pour la gestion des bases de données.
  • Exécution d'une maintenance à faible temps d'arrêt (LDTM) pour faire évoluer dynamiquement les ressources de calcul et de mémoire.

Étapes suivantes

15. Enquête

Comment allez-vous utiliser ce tutoriel ?

Je vais le lire uniquement Je vais le lire et effectuer les exercices