Kubernetes 上のデータベース (オペレーター)

症状

目標: オペレーターを使って Kubernetes 上でデータベースを実行する。素の StatefulSet ではなく、オペレーターが提供する自動フェイルオーバー、永続ストレージ、バックアップの機能を使う。

1. なぜオペレーターか: StatefulSet だけでは不十分

素の StatefulSet は安定した ID と PVC を持つ Pod を提供するが、フェイルオーバー、レプリケーションの構築、バックアップ、アップグレードのロジックは提供しない。オペレーターは、このデータベース固有の運用知識をコントローラー + カスタムリソース (CRD) としてパッケージ化する。'Cluster' という CR を書けば、オペレーターがその背後の StatefulSet、Service、Secret、バックアップジョブを管理する。本番では、オペレーターでデータベースを実行する方法が一般に好まれる。

PostgreSQL

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

2. オペレーターを選択してインストールする

エンジンに合ったオペレーターを選ぶ: PostgreSQL には CloudNativePG または Zalando postgres-operator。MySQL と MongoDB には Percona のオペレーター (Percona Operator for MySQL / for MongoDB) が一般的である。オペレーターは Helm またはバンドルマニフェストでインストールする。この手順でクラスタに CRD とコントローラー Pod が追加される。

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 で指定する。低レイテンシのブロックストレージ、理想的にはローカルに近い SSD を提供する StorageClass を選ぶ。ネットワークファイルシステム (NFS) は大半のデータベースで推奨されない。縮小は難しいため、PVC のサイズと拡張可能性 (allowVolumeExpansion) は最初から正しく設定する。

PostgreSQL

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

4. Cluster CR を適用する (レプリカと自動フェイルオーバー)

CR でインスタンス/レプリカの数を指定する。オペレーターは同期/非同期レプリケーションを構築し、プライマリ障害時にはレプリカを昇格させて自動フェイルオーバーを行う。アプリケーションはオペレーターが作成する '-rw' (読み取り/書き込み) Service に接続すべきである。このサービスは常に現在のプライマリを指すため、フェイルオーバー中も接続先は変わらない。

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. CR 経由でバックアップを S3 に書き込む

オペレーターはバックアップも宣言的に管理する: CR でプライマリのバックアップ先 (オブジェクトストレージ/S3) と WAL アーカイブを定義する。CloudNativePG では S3 の詳細を spec.backup.barmanObjectStore で指定する (1.26 以降は非推奨。新規デプロイでは Barman Cloud Plugin とその ObjectStore リソースを使う)。継続的な WAL アーカイブ + ベースバックアップでポイントインタイムリカバリが可能になる。認証情報は 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 式で定期的にベースバックアップを取る。リストアも宣言的である: 'bootstrap.recovery' で既存のオブジェクトストアのバックアップから新しい Cluster をブートストラップする。リストア訓練を定期的に行うこと。バックアップを取るだけでは不十分で、復旧をテストする。

PostgreSQL

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