Управляемый сервис 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 применяет barman-cloud ObjectStore через SSA и патчит spec.plugins координатами управляемого платформой бакета в момент первого BackupJob.

spec:
  backup:
    enabled: true
    useSystemBucket: true        # platform projects cozy-backups-creds + driver SSA-applies ObjectStore + patches spec.plugins

Устаревший вариант, управляемый чартом — для кластеров, созданных до появления платформенного BackupClass, или использующих настроенный нестандартный бакет. Укажите все координаты S3 напрямую (или через s3CredentialsSecret.name); spec.plugins и barman-cloud ObjectStore формируются начиная с helm-install.

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 выполняется сайдкар-архиватором плагина barman-cloud — CNPG может подключать или отключать плагин во время работы, но любой WAL, закрытый до начала архивирования плагином, теряется безвозвратно. В резервной копии, снятой с такого кластера, отсутствует WAL, на который указывает её begin_wal, и последующее восстановление завершается ошибкой WAL not found. Если чарт подключает плагин с момента helm-install, эта гонка исключается.

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

Сквозные манифесты находятся в examples/backups/postgres/. Кратко, задействованные компоненты:

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

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

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

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

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

## @param backup.enabled Включить архивирование WAL через плагин + сформировать управляемый чартом 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 целевого приложения снимком исходного spec, сохранённым в Backup.status.underlyingResources, так что post-install init-job чарта не теряет восстановленные роли или базы данных.

Покрытие e2e: восстановление в копию в том же пространстве имён (шаги 0-7) оставляет исходное приложение работающим и служит детерминированным сквозным сигналом; остаётся ручным / dev-cluster эталонным сценарием, не входящим в автоматизированный набор e2e-тестов. Кросс-тенантный вариант (целевой Postgres в другом тенанте, отличном от seaweedfs источника) остаётся ручным / dev-cluster упражнением — доступность заблокирована политикой исходящего трафика 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