Управляемый сервис PostgreSQL

PostgreSQL в настоящее время является лидирующим выбором среди реляционных баз данных и известен своей надёжной функциональностью и производительностью. Управляемый сервис PostgreSQL использует реализацию на стороне платформы для предоставления самовосстанавливающегося реплицируемого кластера. Этот кластер эффективно управляется с помощью широко признанного оператора CloudNativePG, получившего популярность в сообществе.

Детали развёртывания

Этот управляемый сервис контролируется оператором CloudNativePG, обеспечивающим эффективное управление и бесперебойную работу.

• Документация: https://cloudnative-pg.io/docs/
• Github: https://github.com/cloudnative-pg/cloudnative-pg

Операции

Резервное копирование PostgreSQL имеет два уровня, и в рекомендуемой конфигурации используются оба уровня вместе, а не один из них:

Канонический вариант настройки зависит от того, поставляется ли в кластере платформенный BackupClass cozy-default.

Платформенный поток (рекомендуется для новых кластеров) — включается через backup.useSystemBucket: true со ссылкой на cozy-default из BackupJob/Plan/RestoreJob. Чарт оставляет параметры доступа к S3 пустыми; драйвер CNPG применяет barmanObjectStore через SSA-патч, используя параметры платформенного bucket, в момент запуска первого BackupJob.

spec:
  backup:
    enabled: true
    useSystemBucket: true        # платформа проецирует cozy-backups-creds + драйвер применяет barmanObjectStore через SSA-патч

Устаревший поток, управляемый чартом — для кластеров, созданных до появления платформенного BackupClass, или использующих специально настроенный нестандартный bucket. Укажите все параметры доступа к S3 встроенно (или через s3CredentialsSecret.name); barmanObjectStore формируется начиная с момента установки через helm.

spec:
  backup:
    enabled: true                # архивировать WAL в объектное хранилище
    destinationPath: s3://my-bucket/pg-src/
    endpointURL: https://seaweedfs-s3.tenant-foo:8333
    s3CredentialsSecret:
      name: pg-src-cnpg-backup-creds
    endpointCA:
      name: pg-src-cnpg-backup-ca
    # backup.schedule намеренно оставлен пустым — BackupClass / Plan
    # ниже управляют повторяющимся резервным копированием; никакой
    # формируемый чартом ScheduledBackup не должен конкурировать с этим расписанием.

в сочетании с strategy.backups.cozystack.io/CNPG + BackupClass + Plan в том же тенанте. Сквозная (e2e) фикстура в examples/backups/postgres/ является каноническим примером (05-postgres-src.yaml показывает сторону чарта, 10-cnpg-strategy.yaml и 15-backupclass.yaml — сторону оркестрации, 25-backupjob-adhoc.yaml и 40-restorejob-to-copy.yaml — разовое резервное копирование и восстановление).

Почему оба уровня, а не один? Архивирование WAL — это настройка postmaster: CNPG может менять archive_command во время работы через SIGHUP, но любой WAL, закрытый до такой замены, был «заархивирован» командой archive_command=/bin/true и потерян безвозвратно. В резервной копии, снятой с такого кластера, отсутствует WAL, на который указывает её begin_wal, и последующее восстановление завершается ошибкой WAL not found. Если позволить чарту инициализировать archive_command с момента установки через helm, эта гонка устраняется.

Как включить резервное копирование (предпочтительно: BackupClass + Plan)

Сквозные манифесты находятся в examples/backups/postgres/. Вкратце, ключевые составные части:

1. strategy.backups.cozystack.io/CNPG, описывающий bucket назначения и формирующий по шаблону barmanObjectStore (включая ссылку на Secret с учётными данными S3 — учётные данные никогда не попадают в .spec ресурса Postgres CR; см. примечание о безопасности ниже).
2. backups.cozystack.io/BackupClass, который указывает стратегию и выбирается по applicationRef, соответствующему Kind/Name приложения Postgres.
3. backups.cozystack.io/Plan (повторяющееся) или BackupJob (разовое), ссылающийся на BackupClass. Контроллер материализует артефакт Backup по завершении Backup (cnpg.io); восстановления затем ссылаются на этот Backup через RestoreJob.

Поддерживаются как восстановление на месте (in-place, перезаписывает данные исходного приложения), так и восстановление в копию (to-copy, восстановление в отдельное целевое приложение Postgres в том же пространстве имён) — через поле RestoreJob.spec.targetApplicationRef.

Безопасность: При использовании BackupClass учётные данные S3 хранятся в Secret, доступном для чтения в рамках тенанта, на который ссылается шаблон стратегии. Драйвер CNPG передаёт эту ссылку на Secret в поле spec.backup.s3CredentialsSecret приложения Postgres при восстановлении, поэтому ключи доступа никогда не попадают в .spec ресурса Postgres CR, в объектное хранилище etcd или в вывод kubectl get -o yaml. По возможности предпочитайте этот способ способу, управляемому чартом.

Как включить плановое резервное копирование, управляемое чартом (устаревший способ)

Чарт также может напрямую формировать cnpg.io/ScheduledBackup без BackupClass. Заменён связкой BackupClass + Plan, описанной выше, и сохранён для кластеров, которые не были перенесены. По умолчанию не запускается — backup.schedule по умолчанию пуст, что отключает шаблон ScheduledBackup в чарте. Чтобы включить его, укажите cron-выражение CNPG из 6 полей:

## @param backup.enabled Включить archive_command + формировать управляемый чартом ScheduledBackup
## @param backup.schedule Расписание cron (CNPG, 6 полей). Пусто означает отсутствие управляемого чартом ScheduledBackup
## @param backup.retentionPolicy Политика хранения
## @param backup.destinationPath Путь для хранения резервной копии (например, s3://bucket/path/to/folder)
## @param backup.endpointURL Эндпоинт S3, используемый для загрузки данных в облако
## @param backup.s3AccessKey Ключ доступа к S3, используется для аутентификации
## @param backup.s3SecretKey Секретный ключ к S3, используется для аутентификации
backup:
  enabled: true
  retentionPolicy: 30d
  destinationPath: s3://bucket/path/to/folder/
  endpointURL: http://minio-gateway-service:9000
  schedule: "0 2 * * * *"  # включение — пусто (по умолчанию) означает отсутствие управляемого чартом расписания
  s3AccessKey: oobaiRus9pah8PhohL1ThaeTa4UVa7gu
  s3SecretKey: ju3eum4dekeich9ahM1te8waeGai0oog

Как восстановить из резервной копии (предпочтительно: RestoreJob)

Для резервных копий, управляемых через BackupClass, создайте backups.cozystack.io/RestoreJob, ссылающийся на нужный Backup. См. examples/backups/postgres/35-restorejob-in-place.yaml и examples/backups/postgres/40-restorejob-to-copy.yaml. При восстановлении в копию контроллер заменяет spec.databases и spec.users целевого приложения снимком спецификации источника, сохранённым в Backup.status.underlyingResources, поэтому post-install init-job чарта не удаляет восстановленные роли или базы данных.

Покрытие e2e: CI-тест e2e (hack/e2e-apps/backup-postgres.bats) проверяет восстановление в копию в пределах одного пространства имён (шаги 0–7), при котором источник остаётся работающим и поэтому даёт детерминированный сквозной сигнал. Межтенантный вариант (целевой Postgres в тенанте, отличном от тенанта seaweedfs источника) остаётся ручным сценарием / упражнением на dev-кластере — доступность блокируется политикой egress Cilium на уровне тенанта. Код восстановления на месте поставляется и покрыт на уровне модульных тестов: TestClusterHasRecoveryBootstrap_TerminatingCluster, TestCNPGBackupWALArchived, TestCNPGPurgeNeeded и остальной набор тестов internal/backupcontroller/cnpgstrategy_controller_test.go.

Как восстановить из резервной копии (загрузка, управляемая чартом)

CloudNativePG поддерживает восстановление на момент времени (point-in-time recovery). Восстановление резервной копии выполняется путём создания нового экземпляра базы данных и восстановления данных в нём.

Создайте новое приложение PostgreSQL с другим именем, но идентичной конфигурацией. Установите bootstrap.enabled в true и укажите имя экземпляра базы данных, из которого восстанавливаться, и время восстановления:

## @param bootstrap.enabled Восстановить кластер базы данных из резервной копии
## @param bootstrap.recoveryTime Метка времени (PITR), до которой будет выполнено восстановление, в формате RFC 3339. Если оставить пустым, будет восстановлена последняя
## @param bootstrap.oldName Имя кластера базы данных до удаления
##
bootstrap:
  enabled: false
  recoveryTime: ""  # оставьте пустым для последней или укажите точную метку времени; пример: 2020-11-26 15:22:00.00000+00
  oldName: "<previous-postgres-instance>"

Как переключить первичную/вторичную реплику

См.:

• https://cloudnative-pg.io/documentation/1.15/rolling_update/#manual-updates-supervised

storageClass помечен как неизменяемый (immutable) в схеме чарта — см. docs/storage-immutability.md, где описан этот контракт и какие потребители его обеспечивают.

TLS для серверных подключений

CNPG управляет цепочкой сертификатов сквозным образом. Оператор автоматически генерирует самоподписанный CA, подписывает им конечные (leaf) сертификаты сервера, клиента и репликации и ротирует их по мере необходимости. Чарт не формирует никаких объектов Issuer/Certificate cert-manager — этот путь взаимоисключающий с управляемой оператором цепочкой на admission webhook CNPG.

Что добавляет чарт: когда TLS включён и external: true, чарт устанавливает spec.certificates.serverAltDNSNames в ресурсе CNPG Cluster CR, чтобы внедрить внешнее имя хоста <release>.<_namespace.host> в список SAN автоматически сгенерированного серверного сертификата. Стандартное покрытие SAN в CNPG уже включает три встроенных сервиса ClusterIP (-rw, -r, -ro) во всех четырёх формах DNS (<svc>, <svc>.<ns>, <svc>.<ns>.svc, <svc>.<ns>.svc.<cluster-domain>); требуется добавить только внешнее имя хоста.

Трёхпозиционный параметр tls.enabled определяет, внедряет ли чарт serverAltDNSNames:

• tls.enabled: null (по умолчанию) — режим TLS наследуется от external. При external: true чарт внедряет внешнее имя хоста в управляемый оператором сертификат.
• tls.enabled: true при external: true — эффект тот же, что и по умолчанию.
• tls.enabled: true при external: false — внедрение serverAltDNSNames не требуется (внешнего имени хоста для добавления нет); автоматически сгенерированный сертификат CNPG покрывает внутренние сервисы.
• tls.enabled: false — чарт пропускает внедрение serverAltDNSNames. Примечание: CNPG сохраняет встроенный TLS на уровне соединения независимо от этого флага; данный переключатель управляет лишь тем, добавляется ли внешнее имя хоста в сертификат. Чтобы полностью отключить TLS в PostgreSQL, потребовалось бы установить postgresql.parameters.ssl = "off" на уровне CNPG, что выходит за рамки этого флага.

Получение CA-бандла для проверки на стороне клиента:

CNPG включает сертификат CA в каждый создаваемый им Secret с учётными данными пользователя под ключом ca.crt. Получите его из Secret <release>-credentials, который уже доступен тенантам через RBAC дашборда:

kubectl --context <ctx> --namespace <tenant> \
  get secret <release>-credentials \
  --output jsonpath='{.data.ca\.crt}' | base64 --decode

Подключение с полной проверкой (пример psql):

psql "host=<host> port=5432 dbname=app user=app \
  sslmode=verify-full sslrootcert=ca.crt"

Чтобы sslmode=verify-full работал, полученный выше CA-бандл должен быть сохранён в ca.crt. Без него используйте sslmode=require (шифрует, но не проверяет серверный сертификат).

Параметры

Общие параметры

Конфигурация TLS

Параметры, специфичные для приложения

Синхронная репликация на основе кворума

Конфигурация пользователей

Конфигурация баз данных

Параметры резервного копирования

Параметры начальной загрузки (восстановления)

Примеры и справочник по параметрам

resources и resourcesPreset

resources задаёт явные конфигурации CPU и памяти для каждой реплики. Если оставить пустым, применяется пресет, указанный в resourcesPreset.

resources:
  cpu: 4000m
  memory: 4Gi

resourcesPreset задаёт именованные конфигурации CPU и памяти для каждой реплики. Эта настройка игнорируется, если задано соответствующее значение resources.

Пресеты следуют облачной схеме именования <серия>.<размер>. Пять серий покрывают весь диапазон соотношений CPU к памяти (t1 1:0.5, c1 1:1, s1 1:2, u1 1:4, m1 1:8), и каждая серия поставляется с восемью размерами (от nano до 4xlarge). Устаревшие плоские имена (nano, micro, small, medium, large, xlarge, 2xlarge) по-прежнему принимаются как устаревшие псевдонимы соответствующих типов инстансов с соотношением 1:1.

См. docs/operations/resource-presets.md, где приведены полная матрица размеров и сопоставление устаревших имён с типами инстансов.

users

users:
  user1:
    password: strongpassword
  user2:
    password: hackme
  airflow:
    password: qwerty123
  debezium:
    replication: true

databases

databases:
  myapp:
    roles:
      admin:
      - user1
      - debezium
      readonly:
      - user2
  airflow:
    roles:
      admin:
      - airflow
    extensions:
    - hstore