Базы данных в Kubernetes (оператор)

Симптом

Цель: запустить базу данных в Kubernetes с помощью оператора; вместо голого StatefulSet использовать предоставляемые оператором автоматическую отработку отказа, постоянное хранилище и бэкапы.

1. Зачем оператор: одного StatefulSet недостаточно

Обычный StatefulSet даёт поды со стабильными идентификаторами и PVC, но не логику отработки отказа, настройки репликации, бэкапа и обновлений. Оператор упаковывает эти специфичные для БД эксплуатационные знания в контроллер + пользовательский ресурс (CRD). Вы пишете CR под названием 'Cluster', а оператор управляет стоящими за ним StatefulSet, Service, Secret и заданиями бэкапа. В production запуск баз данных через оператор, как правило, предпочтителен.

PostgreSQL

# operators for PostgreSQL:
#  - CloudNativePG (CNPG)
#  - Zalando postgres-operator
#  - Crunchy PGO

2. Выберите и установите оператор

Выберите оператор для вашего движка: CloudNativePG или Zalando postgres-operator для PostgreSQL; для MySQL и MongoDB распространены операторы Percona (Percona Operator for MySQL / for MongoDB). Установите оператор через Helm или bundle-манифест; этот шаг добавляет в кластер CRD и под контроллера.

PostgreSQL

# CloudNativePG installation
kubectl apply --server-side -f \
  https://raw.githubusercontent.com/cloudnative-pg/cloudnative-pg/main/releases/cnpg-1.24.0.yaml

MySQL

# Percona Operator for MySQL (Helm)
helm install my-op percona/pxc-operator

MongoDB

# Percona Operator for MongoDB (Helm)
helm install psmdb-op percona/psmdb-operator

3. Спланируйте хранилище (StorageClass / PVC)

Состояние базы данных хранится в PVC; укажите используемый StorageClass в CR. Выбирайте StorageClass с блочным хранилищем низкой задержки, в идеале локальным SSD; сетевые файловые системы (NFS) для большинства баз данных не рекомендуются. Сразу правильно задайте размер PVC и возможность расширения (allowVolumeExpansion), потому что уменьшить его сложно.

PostgreSQL

spec:
  storage:
    storageClass: fast-ssd
    size: 50Gi

4. Примените Cluster CR (реплики и автоматическая отработка отказа)

Укажите в CR число экземпляров/реплик; оператор настраивает синхронную/асинхронную репликацию и при сбое primary выполняет автоматическую отработку отказа, повышая реплику. Приложение должно подключаться к Service '-rw' (read-write), созданному оператором; этот сервис всегда указывает на текущий primary. Поэтому цель подключения при отработке отказа не меняется.

PostgreSQL

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: app-db
spec:
  instances: 3
  storage:
    storageClass: fast-ssd
    size: 50Gi
# the application connects to: app-db-rw

5. Запись бэкапов в S3 через CR

Операторы также управляют бэкапами декларативно: в CR задаётся основное место назначения бэкапов (объектное хранилище/S3) и архивирование WAL. В CloudNativePG параметры S3 задаются через spec.backup.barmanObjectStore (устарело с 1.26; для новых развёртываний используйте Barman Cloud Plugin и его ресурс ObjectStore); непрерывное архивирование WAL + базовые бэкапы обеспечивают восстановление на момент времени (PITR). Учётные данные берите по ссылке из Kubernetes Secret.

PostgreSQL

spec:
  backup:
    barmanObjectStore:
      destinationPath: s3://company-backup/app-db
      s3Credentials:
        accessKeyId:
          name: s3-creds
          key: ACCESS_KEY_ID
        secretAccessKey:
          name: s3-creds
          key: SECRET_ACCESS_KEY

6. CR для бэкапа по расписанию и восстановления

Создайте Backup CR для разового бэкапа и ScheduledBackup CR для бэкапов по расписанию; регулярно делайте базовые бэкапы по cron-выражению. Восстановление также декларативно: новый Cluster разворачивается из существующего бэкапа в объектном хранилище через 'bootstrap.recovery'. Регулярно проводите учения по восстановлению; делать бэкапы недостаточно — проверяйте восстановление.

PostgreSQL

apiVersion: postgresql.cnpg.io/v1
kind: ScheduledBackup
metadata:
  name: nightly-backup
spec:
  schedule: "0 0 2 * * *"
  cluster:
    name: app-db