Развертывание AlloyDB Omni в Kubernetes (GKE или собственный кластер) и управление ею

1. Введение

В этой практической работе вы узнаете, как установить оператор AlloyDB Omni Kubernetes (оркестратор контейнеров) в кластере Google Kubernetes Engine (GKE) Autopilot или собственном кластере Kubernetes, а также как управлять полными сквозными рабочими процессами жизненного цикла базы данных и алгоритмами достижения цели.

AlloyDB Omni – это скачиваемая версия AlloyDB, предназначенная для работы в любой среде: от локальной до Google Cloud или периферийных вычислений. С помощью оркестратора контейнеров AlloyDB Omni автоматизирует высокую доступность, автоматическую отработку отказа, самовосстановление, скользящее обслуживание с минимальным временем простоя, пулы подключений, автоматическое резервное копирование и восстановление на определенный момент времени.

Выберите путь к среде

Выполнить эту практическую работу можно двумя способами:

  1. Вариант 1. У вас есть аккаунт Google Cloud (GKE Autopilot). Создайте полностью управляемый кластер GKE Autopilot с помощью Google Cloud Shell или консоли Google Cloud.
  2. Вариант 2. У вас нет аккаунта Google Cloud (используйте собственный кластер Kubernetes). Используйте существующий кластер Kubernetes (версии 1.21 или более поздней) с kubectl и helm, настроенными на вашей рабочей станции. Аккаунт Google Cloud или CLI gcloud не требуются.

Требования

  • Базовые знания о концепциях Kubernetes (kubectl, Helm, Custom Resource Definitions).
  • Для пути 1 (Google Cloud / GKE Autopilot):
    • Проект Google Cloud с включенными платежными функциями.
    • Доступ к Google Cloud Shell или рабочей станции, на которой настроены gcloud, kubectl и helm.
  • Для варианта 2 (использование собственного кластера Kubernetes):
    • Кластер Kubernetes версии 1.21 или более поздней с StorageClass по умолчанию для динамической инициализации PersistentVolume.
    • Рабочие узлы с ядром Linux 4.18+ и включенной cgroup v2 (x86-64/AMD64), а также не менее 8 ВЦП и 24 ГиБ выделяемой ОЗУ в кластере.
    • Рабочая станция с настроенными инструментами kubectl и helm, подключенная к кластеру.

Что вы узнаете

  • Как подготовить кластер GKE Autopilot (путь 1) или проверить существующий кластер Kubernetes (путь 2).
  • Как установить cert-manager и оператор AlloyDB Omni Kubernetes с помощью Helm.
  • Как развернуть AlloyDB Omni с одним экземпляром DBCluster.
  • Как масштабировать до высокой доступности с синхронными резервными копиями и включить возможность резервного копирования только для чтения.
  • Как настроить автоматическое резервное копирование по расписанию в локальное хранилище репозитория (и, при необходимости, в Google Cloud Storage по пути 1).
  • Как выполнять резервное копирование по запросу и проверять восстановление данных до предыдущего состояния.
  • Как выполнить восстановление на определенный момент времени (PITR) в новом клонированном кластере базы данных.
  • Как развернуть пул подключений PgBouncer для масштабирования клиентских подключений.
  • Как развернуть pgAdmin4 для визуального управления базой данных и отправки запросов к ней.
  • Как выполнить обслуживание с минимальным временем простоя (LDTM) для масштабирования ресурсов ЦП и памяти.

Что вам понадобится

  • Вариант 1. Google Cloud Shell с предустановленными утилитами gcloud, kubectl и helm.
  • Способ 2. Терминал с kubectl и helm, подключенный к кластеру Kubernetes.
  • Дополнительную информацию можно найти в официальном руководстве по развертыванию AlloyDB Omni.

2. Настройка и требования

Выберите Путь 1, если вы используете аккаунт Google Cloud для создания кластера GKE Autopilot, или Путь 2, если вы используете собственный кластер Kubernetes без аккаунта Google Cloud.

Путь 1. Настройка проекта Google Cloud (GKE Autopilot)

  1. В консоли Google Cloud выберите или создайте проект Google Cloud.
  2. Убедитесь, что для проекта включены платежные функции. Подробнее о том, как проверить платежный статус…
  3. Откройте Google Cloud Shell, нажав на значок Активировать Cloud Shell в правом верхнем углу Google Cloud Console или перейдя по ссылке shell.cloud.google.com. Cloud Shell предоставляет вычислительную среду, в которой установлены gcloud, kubectl и helm.
  4. Задайте идентификатор проекта в качестве переменной среды и настройте gcloud:
export PROJECT_ID="<YOUR_PROJECT_ID>"
export REGION="us-central1"
export CLUSTER_NAME="omni-autopilot-cluster"

gcloud config set project ${PROJECT_ID}
gcloud config set compute/region ${REGION}
  1. Включите необходимые API Google Cloud для GKE и Cloud Storage:
gcloud services enable container.googleapis.com \
    storage.googleapis.com \
    cloudresourcemanager.googleapis.com

Вариант 2. Настройка собственного кластера (без аккаунта Google Cloud)

Если у вас нет аккаунта Google Cloud и вы используете собственный кластер Kubernetes, перед продолжением проверьте в терминале следующие предварительные требования:

  1. Убедитесь, что kubectl и helm могут подключиться к вашему кластеру, а узлы имеют статус Ready:
kubectl get nodes
helm version
  1. Убедитесь, что в кластере есть StorageClass по умолчанию с пометкой (default). Манифесты DBCluster и BackupPlan динамически предоставляют PersistentVolumeClaims, используя StorageClass кластера по умолчанию:
kubectl get storageclass

Если ни один из StorageClass не отмечен как (default), назначьте один из них по умолчанию, прежде чем продолжить:

kubectl patch storageclass <YOUR_STORAGE_CLASS_NAME> \
  -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
  1. Убедитесь, что рабочие узлы соответствуют требованиям оператора к оборудованию и ОС:
    • ОС и ядро. Ядро Linux 4.18 или более поздней версии с включенной функцией cgroup v2 на узлах x86-64/AMD64.
    • Емкость кластера. Не менее 8 виртуальных ЦП и 24 ГиБ выделяемой памяти на рабочих узлах для одновременного запуска экземпляров базы данных высокой доступности (масштабированных до 2 виртуальных ЦП и 8 ГиБ каждый на шаге 12), клонированного экземпляра PITR, PgBouncer и pgAdmin4.
    • Доступ к сети. Исходящий доступ к интернету для получения образов контейнеров из gcr.io/alloydb-omni, quay.io/jetstack и docker.io.

3. Как подготовить кластер Kubernetes или подключиться к нему

Если вы выбрали путь 1 (аккаунт Google Cloud), GKE Autopilot предоставит вам полностью управляемый режим Kubernetes, в котором Google управляет инфраструктурой кластера, инициализацией узлов и автомасштабированием. Вы можете создать кластер GKE Autopilot с помощью Google Cloud CLI или консоли Google Cloud.

Вариант А. Создание кластера GKE Autopilot с помощью CLI (путь 1)

Выполните в Cloud Shell следующую команду gcloud:

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

Вариант Б. Создание кластера GKE Autopilot в консоли (способ 1)

  1. Откройте Kubernetes Engine в Google Cloud Console.
  2. На панели навигации слева нажмите Кластеры.
  3. Нажмите Создать.
  4. В разделе GKE Autopilot нажмите Configure (Настроить).
  5. Укажите название кластера (например, omni-autopilot-cluster) и выберите предпочтительный регион (us-central1).
  6. Нажмите Создать.

Проверка подключения кластера (путь 1 и путь 2)

Если вы создали кластер GKE Autopilot в пути 1, настройте учетные данные kubectl:

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

Для Пути 1 и Пути 2 проверьте подключение к кластеру Kubernetes:

kubectl get nodes

4. Установка необходимых компонентов и оператора

Оператору AlloyDB Omni Kubernetes требуется cert-manager для управления TLS-сертификатами вебхука допуска.

1. Установите cert-manager

Установите cert-manager, используя официальную диаграмму 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

Убедитесь, что поды cert-manager запущены:

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

2. Установите AlloyDB Omni Operator

Разверните оператор AlloyDB Omni Kubernetes в пространстве имен alloydb-omni-system с помощью 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

Убедитесь, что поды оператора работают и исправны:

kubectl get pods -n alloydb-omni-system

5. Создание кластера базы данных с одним экземпляром

На этом шаге вы создадите выделенное пространство имен приложения и развернете AlloyDB Omni DBCluster с одним экземпляром.

1. Создайте пространство имен и секрет учетных данных администратора

Создайте пространство имен omni-demo для рабочих нагрузок базы данных:

kubectl create namespace omni-demo

Создайте секрет Kubernetes, в котором будет храниться пароль для пользователя-администратора базы данных 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. Deploy Single-Instance DBCluster

Создайте манифест DBCluster с одним экземпляром:

kubectl apply -n omni-demo -f - <<EOF
apiVersion: alloydbomni.dbadmin.goog/v1
kind: DBCluster
metadata:
  name: adbo
spec:
  databaseVersion: "18.3.0"
  primarySpec:
    adminUser:
      passwordRef:
        name: db-pw-adbo
    resources:
      cpu: 1
      memory: 4Gi
      disks:
      - name: DataDisk
        size: 10Gi
EOF

3. Проверка готовности кластера

Отслеживайте статус кластера, пока DBCLUSTERPHASE не достигнет DBClusterReady. Первоначальная инициализация может занять несколько минут: оператор должен создать постоянный том и извлечь образ базы данных, а в GKE Autopilot сначала может потребоваться инициализировать новый узел.

kubectl get dbcluster -n omni-demo -w

Нажмите Ctrl+C, чтобы выйти из режима просмотра, когда DBCLUSTERPHASE достигнет DBClusterReady.

Пример результата:

NAME   PRIMARYENDPOINT   PRIMARYPHASE   DBCLUSTERPHASE   HAREADYSTATUS   HAREADYREASON
adbo   10.128.0.45       Ready          DBClusterReady

Запишите IP-адрес PRIMARYENDPOINT, который является ClusterIP сервиса Kubernetes al-adbo-rw-ilb с правами на чтение и запись. AlloyDB Omni прослушивает порт PostgreSQL по умолчанию 5432.

Проверьте ресурсы, которые оператор согласовал из одного манифеста DBCluster: Pod базы данных, DataDisk PersistentVolumeClaim и al-adbo-rw-ilb Service.

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

6. Как перейти на высокую доступность и включить резервный экземпляр только для чтения

AlloyDB Omni обеспечивает высокую доступность благодаря потоковой репликации, автоматическому мониторингу работоспособности, автоматической отработке отказа и обслуживанию реплик чтения.

1. Включите высокую доступность и возможность чтения реплик

Обновите спецификацию DBCluster, чтобы настроить один резервный экземпляр и включить маршрутизацию резервного экземпляра только для чтения:

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

2. Проверка стабилизации HA

Дождитесь, пока резервный экземпляр будет подготовлен и достигнет состояния потоковой репликации (HAREADYSTATUS достигнет True, а HAREADYREASON – Ready), а затем нажмите Ctrl+C, чтобы выйти из режима просмотра:

kubectl get dbcluster adbo -n omni-demo -w

Проверьте статус HAReady:

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

Убедитесь, что опубликованы конечные точки как для чтения и записи, так и только для чтения.

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

Пример результата:

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

Конечная точка чтения и записи (сервис al-adbo-rw-ilb) направляет запросы в основную базу данных, а конечная точка только для чтения (сервис al-adbo-ro-ilb) распределяет запросы на чтение между резервными экземплярами.

7. Настройка автоматических планов резервного копирования (локальных и GCS)

AlloyDB Omni предоставляет физические резервные копии и архивирование WAL через настраиваемый ресурс BackupPlan. Вы можете настроить хранение резервных копий, автоматическое расписание cron и целевые объекты резервного копирования (локальные постоянные тома или Google Cloud Storage).

1. Создать локальный план резервного копирования

Создайте BackupPlan, который записывает резервные копии в локальное хранилище Kubernetes, подключенное к экземплярам базы данных:

kubectl apply -n omni-demo -f - <<EOF
apiVersion: alloydbomni.dbadmin.goog/v1
kind: BackupPlan
metadata:
  name: backupplan-local
spec:
  dbclusterRef: adbo
  backupSchedules:
    full: "0 2 * * *" # Daily at 02:00 UTC
    incremental: "0 */4 * * *" # Every 4 hours
  backupRetainDays: 7
EOF

Убедитесь, что локальный план резервного копирования готов:

kubectl get backupplan backupplan-local -n omni-demo

Дождитесь, пока PHASE сообщит о Ready и запланирует NEXTBACKUPTIME.

2. Создание плана резервного копирования GCS (путь 1: только Google Cloud, необязательно)

Чтобы хранить резервные копии во внешнем сегменте Google Cloud Storage, создайте сегмент GCS, настройте секрет ключа сервисного аккаунта и примените облачный BackupPlan.

  1. Создайте сегмент Cloud Storage:
export BUCKET_NAME="${PROJECT_ID}-omni-backups"
gcloud storage buckets create gs://${BUCKET_NAME} --location=${REGION}
  1. Создайте сервисный аккаунт с разрешениями администратора объектов хранилища и ключ для него:

export SA_NAME="omni-backup-sa"
gcloud iam service-accounts create ${SA_NAME} --display-name="AlloyDB Omni Backup SA"

gcloud projects add-iam-policy-binding ${PROJECT_ID} \
  --member="serviceAccount:${SA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com" \
  --role="roles/storage.objectAdmin"

gcloud iam service-accounts keys create /tmp/gcs-key.json \
  --iam-account="${SA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com"
  1. Создайте секрет в пространстве имен Kubernetes:
kubectl create secret generic gcs-backup-secret \
  --from-file=key.json=/tmp/gcs-key.json \
  -n omni-demo
rm /tmp/gcs-key.json
  1. Примените манифест GCS BackupPlan. Поле key – это папка в сегменте, в которую оператор записывает резервные копии. Оно должно начинаться с /.
kubectl apply -n omni-demo -f - <<EOF
apiVersion: alloydbomni.dbadmin.goog/v1
kind: BackupPlan
metadata:
  name: backupplan-gcs
spec:
  dbclusterRef: adbo
  backupSchedules:
    full: "0 1 * * *"
    incremental: "0 */6 * * *"
  backupRetainDays: 14
  backupLocation:
    type: GCS
    gcsOptions:
      bucket: ${BUCKET_NAME}
      key: /omni-backups/adbo
      secretRef:
        name: gcs-backup-secret
        namespace: omni-demo
EOF

Проверьте статус GCS BackupPlan:

kubectl get backupplan backupplan-gcs -n omni-demo

Дождитесь, пока PHASE сообщит о Ready и запланирует NEXTBACKUPTIME.

8. Вставка данных, запуск резервного копирования и тестовое восстановление

На этом шаге вы заполните основную базу данных начальными данными, запустите резервное копирование вручную по запросу, добавите последующие данные и восстановите их из резервной копии, чтобы подтвердить откат данных.

1. Заполнить исходные данные

Запустите временный под клиента PostgreSQL, чтобы подключиться к базе данных через ее сервис чтения и записи al-adbo-rw-ilb от имени пользователя 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;
  "

Когда появится запрос пароля, введите ChangeMe123. Это пароль, который вы закодировали в формате Base64 в секрете db-pw-adbo на шаге 5.

2. Как запустить резервное копирование по запросу

Создайте вручную настраиваемый ресурс Backup, ссылающийся на локальный 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

Отслеживайте ход резервного копирования:

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

Дождитесь, пока PHASE перейдет в Succeeded.

3. Изменение данных (добавление новых записей)

Добавьте дополнительные записи после резервной копии:

kubectl run pg-client --rm -i --tty --image=postgres:16 --restart=Never -n omni-demo \
  --env="PGPASSWORD=ChangeMe123" -- \
  psql -h al-adbo-rw-ilb -U postgres -d postgres -c "
    INSERT INTO customers (name) VALUES ('Gamma Inc'), ('Delta Corp');
    SELECT * FROM customers;
  "

Теперь в базе данных четыре строки.

4. Восстановить из резервной копии

Запустите восстановление до состояния, зафиксированного в initial-customer-backup:

kubectl apply -n omni-demo -f - <<EOF
apiVersion: alloydbomni.dbadmin.goog/v1
kind: Restore
metadata:
  name: restore-to-initial
spec:
  sourceDBCluster: adbo
  backup: initial-customer-backup
EOF

Отслеживайте процесс восстановления:

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

Дождитесь, пока PHASE достигнет ProvisionSucceeded, и убедитесь, что DBCluster возвращается к DBClusterReady:

kubectl get dbcluster adbo -n omni-demo -w

5. Проверьте состояние восстановленных данных

Выполните запрос к таблице customers, чтобы убедиться, что в ней есть только записи, созданные до резервного копирования:

kubectl run pg-client --rm -i --tty --image=postgres:16 --restart=Never -n omni-demo \
  --env="PGPASSWORD=ChangeMe123" -- \
  psql -h al-adbo-rw-ilb -U postgres -d postgres -c "
    SELECT * FROM customers;
  "

Выходные данные подтверждают, что присутствуют только две строки (Alpha Co и Beta LLC). Это означает, что база данных была восстановлена в точном соответствии с резервной копией.

9. Восстановление на определенный момент времени в клонированной базе данных

Восстановление на определенный момент времени (PITR) позволяет восстановить базу данных на любую секунду в пределах окна восстановления, используя базовые резервные копии и журналы потока WAL, а также перенести восстановленные данные в новый клонированный кластер базы данных.

Поскольку оператор непрерывно архивирует журнал упреждающей записи (WAL), PITR позволяет восстанавливать данные после случайных ошибок человека или приложения, например непреднамеренного выполнения команды DELETE или DROP TABLE в 14:15:00. Для этого база данных клонируется в состоянии, в котором она находилась за секунду до ошибки (в 14:14:59), без изменения исходного кластера.

1. Запись текущей временной метки и изменение данных

Получите текущую временную метку UTC:

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

Вставьте тестовую запись, которая представляет нежелательное изменение после этой временной метки:

kubectl run pg-client --rm -i --tty --image=postgres:16 --restart=Never -n omni-demo \
  --env="PGPASSWORD=ChangeMe123" -- \
  psql -h al-adbo-rw-ilb -U postgres -d postgres -c "
    INSERT INTO customers (name) VALUES ('Unwanted Record Post-Timestamp');
    SELECT * FROM customers;
  "

2. Восстановление на определенный момент времени

Примените настраиваемый ресурс Restore, настроив pointInTime и 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

Следите за процессом восстановления, пока значение PHASE не достигнет ProvisionSucceeded:

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

3. Проверьте клонированную базу данных

После завершения восстановления подождите, пока новый клонированный DBCluster не достигнет DBClusterReady (нажмите Ctrl+C, чтобы выйти из режима просмотра):

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

Запросите клонированную базу данных adbo-cloned через ее сервис чтения и записи al-adbo-cloned-rw-ilb:

kubectl run pg-client --rm -i --tty --image=postgres:16 --restart=Never -n omni-demo \
  --env="PGPASSWORD=ChangeMe123" -- \
  psql -h al-adbo-cloned-rw-ilb -U postgres -d postgres -c "
    SELECT * FROM customers;
  "

Обратите внимание, что в клонированном кластере нет таблицы Unwanted Record Post-Timestamp. Это подтверждает, что восстановление выполнено точно на указанный момент времени.

10. Развертывание пула подключений PgBouncer

Пул подключений снижает нагрузку на память базы данных и задержку подключения. Оператор управляет экземплярами PgBouncer нативно через настраиваемый ресурс PgBouncer.

PostgreSQL создает отдельный процесс операционной системы для каждого подключения клиента, поэтому сотни одновременных подключений от веб-сервисов, микросервисов или ИИ-агентов могут исчерпать память базы данных. PgBouncer находится перед базой данных и мультиплексирует множество кратковременных клиентских подключений (до max_client_conn) в небольшой пул долговременных подключений к серверу PostgreSQL (default_pool_size на пару пользователь/база данных, ограничено max_db_connections).

1. Развертывание PgBouncer

Разверните пул PgBouncer с двумя репликами, связанный с кластером 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. Проверьте статус PgBouncer

Следите за статусом PgBouncer, пока PHASE не станет Ready:

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

Проверьте работающие поды и сервис PgBouncer:

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

3. Подключение через PgBouncer

Подключите клиент через сервис PgBouncer на порту 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 без проблем перенаправляет запрос в основную базу данных AlloyDB Omni.

11. Развертывание pgAdmin4 для доступа к базе данных

Вы можете запустить pgAdmin4 непосредственно в кластере Kubernetes, чтобы получить веб-консоль администрирования для отправки запросов, управления и проверки AlloyDB Omni.

1. Установите pgAdmin4 с помощью Helm

Установите pgadmin4 в пространстве имен 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"

Эта диаграмма называет свои ресурсы Kubernetes pgadmin4 (Deployment, Service, PersistentVolumeClaim) и помечает свои Pods с помощью app=pgadmin4, независимо от имени выпуска Helm (my-pgadmin).

Убедитесь, что под pgAdmin4 запущен:

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

2. Перенаправление порта и доступ к веб-интерфейсу

Переадресуйте порт pgAdmin4 в локальную среду или Cloud Shell:

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

kubectl port-forward будет работать в активном режиме, пока вы используете веб-интерфейс pgAdmin4. Откройте второй терминал (или новую вкладку Cloud Shell) для других команд и нажмите Ctrl+C в этом терминале, когда будете готовы перейти к следующему шагу.

Откройте веб-интерфейс pgAdmin4:

  • Способ 1 (Google Cloud Shell). Нажмите кнопку Предварительный просмотр в меню справа вверху, выберите Изменить порт, введите 5050 и нажмите Изменить и посмотреть.
  • Вариант 2 (локальная рабочая станция). Откройте http://localhost:5050 в браузере, пока выполняется команда kubectl port-forward.

Войти с помощью:

  • Адрес электронной почты: admin@example.com.
  • Пароль: AdminPassword123

3. Зарегистрируйте AlloyDB Omni в pgAdmin4

  1. В pgAdmin4 нажмите правой кнопкой мыши Servers (Серверы) > Register (Зарегистрировать) > Server... (Сервер...).
  2. На вкладке Общие:
    • Название: AlloyDB Omni Primary.
  3. На вкладке Подключение:
    • Имя хоста/адрес: al-adbo-rw-ilb.omni-demo.svc.cluster.local (или al-omni-pgbouncer-pgb-svc.omni-demo.svc.cluster.local для PgBouncer).
    • Порт: 5432 (или 6432 для PgBouncer).
    • База данных обслуживания: postgres
    • Имя пользователя: postgres.
    • Пароль: ChangeMe123
  4. Нажмите Сохранить и проверьте активный сеанс базы данных и таблицы.

12. Масштабирование ЦП и памяти с помощью обслуживания с минимальным временем простоя (LDTM)

При вертикальном масштабировании вычислительных ресурсов и памяти в рабочей базе данных традиционные обновления вызывают сбои в работе базы данных из-за перезапуска. AlloyDB Omni поддерживает обслуживание с минимальным временем простоя (LDTM), что позволяет выполнять последовательное обновление реплик с минимальным прерыванием работы приложения.

1. Включить аннотацию LDTM

Добавьте аннотацию в DBCluster, чтобы включить LDTM для обновлений:

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

2. Масштабирование ресурсов ЦП и памяти

Обновите основные ресурсы с cpu: 1, memory: 4Gi на cpu: 2, memory: 8Gi:

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

3. Как отслеживать ход масштабирования LDTM

Отслеживайте последовательное обновление и условия переключения с резервного на основной экземпляр:

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

Посмотрите, как плавно перекатываются капсулы:

kubectl get pods -n omni-demo -w

LDTM сначала подготавливает обновленный резервный экземпляр, проверяет потоковую репликацию, выполняет быстрое переключение и обновляет оставшийся экземпляр без прерывания обслуживания.

Проверьте обновленное распределение ресурсов:

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

13. Ресурсы по очистке

Чтобы освободить ресурсы кластера и избежать лишних расходов в аккаунте Google Cloud, удалите ресурсы, созданные в ходе этой практической работы.

Если вы выполняете очистку в новом сеансе терминала (Путь 1), переменные среды из предыдущих шагов больше не заданы. Повторно экспортируйте их с теми же значениями, которые вы использовали ранее:

export PROJECT_ID="<YOUR_PROJECT_ID>"
export REGION="us-central1"
export CLUSTER_NAME="omni-autopilot-cluster"
export BUCKET_NAME="${PROJECT_ID}-omni-backups"
export SA_NAME="omni-backup-sa"
gcloud config set project ${PROJECT_ID}

1. Удаление рабочих нагрузок базы данных (путь 1 и путь 2)

Чтобы пройти проверки вебхука допуска, пометьте оба кластера как удаленные, дождитесь, пока оператор удалит ресурсы DBCluster, а затем удалите пространство имен:

kubectl patch dbcluster adbo -n omni-demo --type=merge -p '{"spec":{"isDeleted":true}}'
kubectl patch dbcluster adbo-cloned -n omni-demo --type=merge -p '{"spec":{"isDeleted":true}}'
kubectl wait --for=delete dbcluster/adbo dbcluster/adbo-cloned -n omni-demo --timeout=300s
kubectl delete namespace omni-demo

Если вы использовали собственный кластер Kubernetes (путь 2) и хотите удалить оператор AlloyDB Omni и cert-manager:

helm uninstall alloydbomni-operator -n alloydb-omni-system
kubectl delete namespace alloydb-omni-system
helm uninstall cert-manager -n cert-manager
kubectl delete namespace cert-manager

2. Удалите сегмент GCS и сервисный аккаунт IAM (только для способа 1)

Если вы создали сегмент Google Cloud Storage и сервисный аккаунт, следуя инструкциям из раздела Вариант 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. Удаление кластера GKE (только для пути 1)

Если вы подготовили кластер GKE Autopilot в пути 1:

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

14. Поздравляю!

Поздравляем! Вы завершили практическую работу по AlloyDB Omni в Kubernetes.

Что мы обсудили

  • Вы подготовили кластер GKE Autopilot (путь 1) или существующий кластер Kubernetes (путь 2).
  • Развернули cert-manager и оператор AlloyDB Omni Kubernetes с помощью Helm.
  • Развернут один экземпляр AlloyDB Omni DBCluster.
  • Кластер был обновлен до высокой доступности с синхронными резервными копиями и включенной маршрутизацией резервных копий только для чтения.
  • Созданы автоматизированные ресурсы BackupPlan для локального постоянного хранилища и Google Cloud Storage (GCS).
  • Выполнял резервное копирование по запросу и проверял восстановление баз данных.
  • Выполнено восстановление на определенный момент времени (PITR) в новом клонированном кластере базы данных.
  • Развернут пул подключений PgBouncer для масштабируемых клиентских подключений.
  • Развернут и подключен pgAdmin4 для управления базами данных.
  • Выполнили обслуживание с минимальным временем простоя (LDTM), чтобы динамически масштабировать вычислительные ресурсы и ресурсы памяти.

Дальнейшие действия

15. Опрос

Как вы будете использовать это руководство?

Только прочитал Прочитал и выполнил упражнения