本記事では、 Crunchy Postgres Operator (PGO) v5 のインストール方法と主な機能の使い方について紹介します。

Operator を使う理由や Crunchy Postgres Operator の概要については以前の記事 Kubernetes PostgreSQL Operatorの紹介、Crunchy Postgres Operatorの紹介 を参照してください。

PGO v5 の主な変更点

以前 v4 で紹介した以下の機能は、v5 でも引き続き利用できます。利用する際の設定方法は v4 までと異なるので、詳しい設定方法については後述します。

• PostgreSQL HA クラスタのデプロイ・管理
• ストリーミングレプリケーション (同期・非同期)
• フェイルオーバー
• バックアップ
• WALアーカイブ
• リストア・PITR
• アップグレード
• コネクションプール
• モニタリング

PGO v5 における構築・運用の主な変更点は以下の通りです。

• PGO v5 では、Kustomize または Helm を利用し、PGO をインストールします。v4 までの方法に比べて、より簡単にインストールできるようになりました。
• PGO v4 では基本的に pgo クライアントコマンドを利用して各種操作を行っていましたが、PGO v5 では pgo クライアントコマンドが廃止されました。PGO v5では、Kubernetes で一般的によく使われるコマンドラインツール kubectl を利用して PostgreSQL の構築および管理を行います。
• PostgreSQL インスタンスは StatefulSet を使用するようになりました。
• PGO v4 までは PostgreSQL のマイナーバージョンアップを行うために、「PGO 自身のアップデート」と「PostgreSQL のアップデート」の2段階のアップデートを実行する必要がありましたが、PGO v5 では、PGO のバージョンを更新せず、PostgreSQL のイメージをアップデートするだけでマイナーバージョンアップができるようになりました。

その他の改良や変更点についてはPGO 5.0.0 のリリースノートを参照してください。

PGO v5 の動作環境

本記事執筆時点 (2022 年 3 月) では、以下の環境で動作確認が行われています。

• Kubernetes 1.19 以降
• OpenShift 4.6 以降
• Rancher
• Google Kubernetes Engine (GKE), Anthos を含む
• Amazon EKS
• Microsoft AKS
• VMware Tanzu

検証環境およびバージョン情報

本記事では Kubernetes のマネージドサービスである Amazon EKS 上で PGO v5 のデプロイ・動作確認を行います。

環境の構成およびバージョン情報は以下のとおりです。各ソフトウェアは 2022 年 3 月時点での最新バージョンを利用しています。

• PGO 5.0.5
• Amazon EKS
  • Kubernetes バージョン: 1.21
  • ノード数: 3ノード
  • ノードタイプ: t3.medium
• オブジェクトストレージ: Amazon S3
• ローカル作業環境: CentOS 7.9 (VirtualBox 上の VM)

検証内容

本記事では、PGO v5 を用いて PostgreSQL クラスタを構築し、以下の機能について動作確認を行います。

• PGO のデプロイ
• PostgreSQL クラスタの作成
• psql による接続確認
• PostgreSQL の設定
• フェイルオーバー
• スケーリング
• ボリュームサイズの拡張
• バックアップ
• リストア・PITR
• モニタリング

前提条件

PGO をデプロイする前に、次の準備が完了していることが前提となります。

• • EKS クラスタの作成 (こちらを参照)
  • Amazon S3 バケットの作成 (こちらを参照)
    ※作成したバケットの名前は PostgresCluster (後述) の YAML ファイルに設定します。

PGO のデプロイ

PGO v5 以降、PGO のデプロイは Kustomize または Helm を使うことになりました。本記事では、Kustomize を用いて PGO をデプロイします。

各種サンプル設定ファイルを含むpostgres-operator-examplesリポジトリを作業環境に複製します。

$ git clone https://github.com/CrunchyData/postgres-operator-examples.git
$ cd postgres-operator-examples/

PGO をデプロイします。

$ kubectl apply -k kustomize/install

上記コマンドを実行すると、postgres-operator という名前空間が作成され、PGO のデプロイに必要なすべてのオブジェクトがこの名前空間に作成されます。

$ kubectl get pods -n postgres-operator
NAME                   READY   STATUS    RESTARTS   AGE
pgo-59c4f987b6-cd6pn   1/1     Running   0          29s

ストレージクラスの作成

Amazon EKS ではデフォルトで gp2 という名前のストレージクラスが作成されていますが、本記事では以下の属性を持つ PGO 専用のストレージクラスを作成します。

• allowVolumeExpansion: ボリュームの拡張を許可するように true を設定する。
• reclaimPolicy: PVC が削除された際に PV を残すように Retain を設定する。

$ cat > ~/pgo-sc.yaml <<EOF
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: pgo
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp2
  fsType: ext4
allowVolumeExpansion: true
reclaimPolicy: Retain
EOF

$ kubectl apply -f ~/pgo-sc.yaml

作成したストレージクラス pgo を確認します。

$ kubectl get sc pgo
NAME   PROVISIONER             RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
pgo    kubernetes.io/aws-ebs   Retain          Immediate           true                   6m36s

PostgreSQL クラスタの作成

PostgreSQL クラスタをデプロイします。

今回は以下のような構成の PostgreSQL クラスタを作成します。

• master 1台、replica 2台
• 同期レプリケーション
• 自動フェイルオーバー (デフォルト)
• WAL アーカイブ (デフォルト)
• 永続ボリュームと Amazon S3 にバックアップと WAL アーカイブを保存

取得したバックアップや WAL アーカイブは永続ボリュームのほか、S3 や GCS、Azure Blob Storage などのオブジェクトストレージにも保存できます。今回は、Amazon S3 を使います。GCS や Azure Blob Storage の設定については、こちらを参照してください。

postgres-operator-examples リポジトリに各種構成のサンプル設定ファイルが用意されているので、それらのファイルを元に設定ファイルを作成します。今回は S3 を利用するために、kustomize/s3 配下のサンプルファイルをコピーし、必要に応じて編集します。

$ cp -r  kustomize/s3 kustomize/my-postgres

PGO v5 では PostgresCluster リソース (CRD) を使って、PostgreSQL クラスタのデプロイ・管理を行います。 PostgresCluster 設定のサンプルは postgres.yaml ファイルに記述されているので、必要に応じて編集します。

今回は以下のような YAML ファイルを利用して PostgresCluster をデプロイします。

$ cat kustomize/my-postgres/postgres.yaml
apiVersion: postgres-operator.crunchydata.com/v1beta1
kind: PostgresCluster
metadata:
  name: my-postgres
spec:
  image: registry.developers.crunchydata.com/crunchydata/crunchy-postgres:centos8-14.2-0
  postgresVersion: 14
  instances:
    - name: pg-1
      replicas: 3
      dataVolumeClaimSpec:
        accessModes:
        - "ReadWriteOnce"
        resources:
          requests:
            storage: 10Gi
        storageClassName: pgo
  backups:
    pgbackrest:
      image: registry.developers.crunchydata.com/crunchydata/crunchy-pgbackrest:centos8-2.36-1
      configuration:
      - secret:
          name: pgo-s3-creds
      global:
        repo2-path: /pgbackrest/postgres-operator/my-postgres/repo2
      repos:
      - name: repo1
        volume:
          volumeClaimSpec:
            accessModes:
            - "ReadWriteOnce"
            resources:
              requests:
                storage: 10Gi
            storageClassName: pgo
      - name: repo2
        s3:
          bucket: "my-postgres"
          endpoint: "s3.us-west-2.amazonaws.com"
          region: "us-west-2"
  patroni:
    dynamicConfiguration:
      synchronous_mode: true
  users:
    - name: postgres
    - name: testuser
      databases:
        - testdb

パラメータの意味は以下のとおりです。

• spec.instances.replicas: レプリカの数を指定します。上記設定では、master 1台、replica 2台の PostgreSQL クラスタが作成されます。
• spec.backups.pgbackrest.repos.name: バックアップと WAL アーカイブの保存先を設定します。repoN 形式で複数の保存先を指定可能です。上記設定では、永続ボリュームを repo1、S3 を repo2 と設定しています。
• spec.backups.pgbackrest.repos.s3: Amazon S3 バケット情報を設定します。今回は前述の「前提条件」であらかじめ作成したバケットを利用します。
• spec.instances.dataVolumeClaimSpec: PostgreSQL データ保存用の PVC を設定します。
• spec.backups.pgbackrest.repos.volume.volumeClaimSpec: バックアップと WAL アーカイブ保存用の PVC を設定します。
• spec.patroni.dynamicConfiguration.synchronous_mode: 同期レプリケーションを利用するか否かを true/false で設定します。
• spec.users: デプロイ時に作成する PostgreSQL ユーザとデータベースを指定します。上記設定では、postgres と testuser ユーザ、testdb データベースが作成され、testuser に testdb へのアクセス権限が付与されます。

次に、Amazon S3 にアクセスするためのクレデンシャルを登録します。repoN には、上記 postgres.yaml に設定した S3 のリポジトリ名を指定します。

$ cp kustomize/my-postgres/s3.conf{.example,}
$ vi kustomize/my-postgres/s3.conf
[global]
repo2-s3-key=<アクセスキー>
repo2-s3-key-secret=<シークレットアクセスキー>

マニフェストの設定が完了したら、PostgreSQL クラスタをデプロイします。

$ kubectl apply -k kustomize/my-postgres/

PostgreSQL クラスタの状態を確認します。3つの Pod が作成されます。各 Pod が master か replica かはラベルで確認できます。

$ kubectl get pods -n postgres-operator --selector=postgres-operator.crunchydata.com/instance-set \
  -L postgres-operator.crunchydata.com/role
NAME                      READY   STATUS    RESTARTS   AGE     ROLE
my-postgres-pg-1-45cl-0   3/3     Running   0          7m14s   master
my-postgres-pg-1-ctj8-0   3/3     Running   0          7m14s   replica
my-postgres-pg-1-rgc4-0   3/3     Running   0          7m14s   replica

psql による接続確認

Kubernetes クラスタ内のノードから、または他の Pod からは上記の PostgreSQL の Pod に接続できますが、作業環境から psql でアクセスしたい場合は kubectl の port-forward 機能を利用します。
ここでは master Pod の 5432 ポートをローカルの 5432 へポートフォワードを行います。
※ PG_CLUSTER_MASTER_POD には master の Pod 名が入ります。

$ PG_CLUSTER_MASTER_POD=$(kubectl get pod -n postgres-operator -o name -l postgres-operator.crunchydata.com/cluster=my-postgres,postgres-operator.crunchydata.com/role=master)
$ kubectl -n postgres-operator port-forward "${PG_CLUSTER_MASTER_POD}" 5432:5432 &

psql で接続します。testuser ユーザの情報を格納する Secret からデータベースの接続情報を取得します。

$ PG_CLUSTER_USER_SECRET_NAME=my-postgres-pguser-testuser
$ PGPASSWORD=$(kubectl get secrets -n postgres-operator "${PG_CLUSTER_USER_SECRET_NAME}" -o go-template='{{.data.password | base64decode}}') \
PGUSER=$(kubectl get secrets -n postgres-operator "${PG_CLUSTER_USER_SECRET_NAME}" -o go-template='{{.data.user | base64decode}}') \
PGDATABASE=$(kubectl get secrets -n postgres-operator "${PG_CLUSTER_USER_SECRET_NAME}" -o go-template='{{.data.dbname | base64decode}}') \
psql -h localhost
Handling connection for 5432
psql (14.2)
SSL connection (protocol: TLSv1.2, cipher: ECDHE-ECDSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.

testdb=> \du+
                                            List of roles
  Role name   |                         Attributes                         | Member of | Description 
--------------+------------------------------------------------------------+-----------+-------------
 _crunchyrepl | Replication                                                | {}        | 
 postgres     | Superuser, Create role, Create DB, Replication, Bypass RLS | {}        | 
 testuser     |                                                            | {}        |

次に、postgres スーパーユーザで接続し、レプリケーションの状態を確認します。

$ PG_CLUSTER_USER_SECRET_NAME=my-postgres-pguser-postgres
$ PGPASSWORD=$(kubectl get secrets -n postgres-operator "${PG_CLUSTER_USER_SECRET_NAME}" -o go-template='{{.data.password | base64decode}}') \
PGUSER=$(kubectl get secrets -n postgres-operator "${PG_CLUSTER_USER_SECRET_NAME}" -o go-template='{{.data.user | base64decode}}') \
psql -h localhost
Handling connection for 5432
psql (14.2)
SSL connection (protocol: TLSv1.2, cipher: ECDHE-ECDSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.

postgres=# select application_name, state, sync_state from pg_stat_replication;
    application_name     |   state   | sync_state 
-------------------------+-----------+------------
 my-postgres-pg-1-rgc4-0 | streaming | sync
 my-postgres-pg-1-ctj8-0 | streaming | async
(2 rows)

PostgreSQL の設定

PostgreSQL のパラメータは spec.patroni.dynamicConfiguration.postgresql.parameters で設定します。
例えば、log_statement: all の設定を追加して適用すると、自動的に PostgreSQL に反映されます。

vi kustomize/my-postgres/postgres.yaml
(以下を追加)
spec:
  patroni:
    dynamicConfiguration:
      synchronous_mode: true
      postgresql:
        parameters:
          log_statement: all

$ kubectl apply -k kustomize/my-postgres/

設定値が変更されていることを確認します。

$ PG_CLUSTER_MASTER_POD=$(kubectl get pod -n postgres-operator -o name -l postgres-operator.crunchydata.com/cluster=my-postgres,postgres-operator.crunchydata.com/role=master)
$ kubectl exec ${PG_CLUSTER_MASTER_POD} -n postgres-operator -it -- psql
Handling connection for 5432
psql (14.2)
SSL connection (protocol: TLSv1.2, cipher: ECDHE-ECDSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.

postgres=# show log_statement;
 log_statement 
---------------
 all
(1 row)

ただし、PostgreSQL の Pod の再起動が必要になるパラメータもあります。
例えば、max_connections の設定値を変更した場合、Pod の再起動が必要になります。
以下のコマンドを実行し、アノテーションを編集することで、PGO が自動的に変更を検出し、1つずつ Pod の再起動を行います。

$ kubectl patch postgrescluster/my-postgres -n postgres-operator --type merge \
  --patch '{"spec":{"metadata":{"annotations":{"restarted":"'"$(date)"'"}}}}'

フェイルオーバー

PostgreSQL の master Pod に故障が発生した場合は、自動的にフェイルオーバーしていずれかの replica が master に昇格します。また、定義した「あるべき状態」を満たすために、新たな replica が起動します。この節では、PGO のフェイルオーバーの動作を検証してみます。

まず、master Pod を削除します。

$ PG_CLUSTER_MASTER_POD=$(kubectl get pod -n postgres-operator -o name -l postgres-operator.crunchydata.com/cluster=my-postgres,postgres-operator.crunchydata.com/role=master)
$ kubectl delete ${PG_CLUSTER_MASTER_POD} -n postgres-operator
pod "my-postgres-pg-1-45cl-0" deleted

すると、replica Pod「my-postgres-pg-1-ctj8-0」が master に昇格し、旧 master Pod が replica として再起動されることを確認できます。

$ kubectl get pods -n postgres-operator --selector=postgres-operator.crunchydata.com/cluster=my-postgres,postgres-operator.crunchydata.com/instance-set \
  -L postgres-operator.crunchydata.com/role
NAME                      READY   STATUS    RESTARTS   AGE   ROLE
my-postgres-pg-1-45cl-0   3/3     Running   0          74s   replica
my-postgres-pg-1-ctj8-0   3/3     Running   0          52m   master
my-postgres-pg-1-rgc4-0   3/3     Running   0          52m   replica

スケーリング

スケーリングとは、replica を追加または削除することです。
PostgreSQL クラスタに replica を追加することをクラスタのスケールアップ、クラスタから replica を削除することをクラスタのスケールダウンといいます。
スケーリングすることにより、データベースの負荷分散や耐障害性の向上を実現できます。

YAML ファイルの replicas の数を変更し、適用するだけで、簡単にクラスタのスケールアップ/スケールダウンを行えます。
以下のように replicas の数を 3 から 4 に変更して適用すると、新しい replica Pod が起動します。

$ vi kustomize/my-postgres/postgres.yaml
(replicas を 3 から 4 に変更)
apiVersion: postgres-operator.crunchydata.com/v1beta1
kind: PostgresCluster
metadata:
  name: my-postgres
spec:
  image: registry.developers.crunchydata.com/crunchydata/crunchy-postgres:centos8-14.2-0
  postgresVersion: 14
  instances:
    - name: pg-1
      replicas: 4
(省略)

$ kubectl apply -k kustomize/my-postgres/

新しい replica が起動することを確認します。

$ kubectl get pods -n postgres-operator --selector=postgres-operator.crunchydata.com/cluster=my-postgres,postgres-operator.crunchydata.com/instance-set \
  -L postgres-operator.crunchydata.com/role
NAME                      READY   STATUS    RESTARTS   AGE     ROLE
my-postgres-pg-1-2fzw-0   3/3     Running   0          27s     replica
my-postgres-pg-1-45cl-0   3/3     Running   0          8m14s   replica
my-postgres-pg-1-ctj8-0   3/3     Running   0          59m     master
my-postgres-pg-1-rgc4-0   3/3     Running   0          59m     replica

$ PG_CLUSTER_MASTER_POD=$(kubectl get pod -n postgres-operator -o name -l postgres-operator.crunchydata.com/cluster=my-postgres,postgres-operator.crunchydata.com/role=master)
$ kubectl exec ${PG_CLUSTER_MASTER_POD} -n postgres-operator -it -- psql
Handling connection for 5432
psql (14.2)
SSL connection (protocol: TLSv1.2, cipher: ECDHE-ECDSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.

postgres=# select application_name, state, sync_state from pg_stat_replication;
    application_name     |   state   | sync_state 
-------------------------+-----------+------------
 my-postgres-pg-1-45cl-0 | streaming | async
 my-postgres-pg-1-rgc4-0 | streaming | sync
 my-postgres-pg-1-2fzw-0 | streaming | async
(3 rows)

元の設定に戻したい場合には、replicas の数を 4 から 3 に減らすと、いずれかの replica Pod が削除されます。

$ vi kustomize/my-postgres/postgres.yaml
(replicas を 4 から 3 に変更)
apiVersion: postgres-operator.crunchydata.com/v1beta1
kind: PostgresCluster
metadata:
  name: my-postgres
spec:
  image: registry.developers.crunchydata.com/crunchydata/crunchy-postgres:centos8-14.2-0
  postgresVersion: 14
  instances:
    - name: pg-1
      replicas: 3
(省略)

$ kubectl apply -k kustomize/my-postgres/

replica Pod が削除されていることを確認します。

$ kubectl get pods -n postgres-operator --selector=postgres-operator.crunchydata.com/cluster=my-postgres,postgres-operator.crunchydata.com/instance-set \
  -L postgres-operator.crunchydata.com/role
NAME                      READY   STATUS    RESTARTS   AGE   ROLE
my-postgres-pg-1-45cl-0   3/3     Running   0          15m   replica
my-postgres-pg-1-ctj8-0   3/3     Running   0          67m   master
my-postgres-pg-1-rgc4-0   3/3     Running   0          67m   replica

ボリュームサイズの拡張

Kubernetes では、ボリュームの拡張が許可される場合のみ、既存の永続ボリューム (PV) のサイズを拡張できます。ボリュームの拡張を許可するかはストレージクラスの allowVolumeExpansion 属性で設定します。

ボリュームの拡張を行う前に、デプロイ済みの PostgreSQL クラスタが利用しているストレージクラスの allowVolumeExpansion の設定値が true であることを確認します。

$ kubectl get sc pgo
NAME   PROVISIONER             RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
pgo    kubernetes.io/aws-ebs   Retain          Immediate           true                   97m

PV と PVC のサイズを確認します。

$ kubectl get pv,pvc -n postgres-operator
NAME                                                        CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                                            STORAGECLASS   REASON   AGE
persistentvolume/pvc-04060f68-9590-4af1-a341-2dd8e1b42055   10Gi       RWO            Delete           Bound    postgres-operator/my-postgres-repo1              pgo                     91m
persistentvolume/pvc-1e13602d-1455-46b7-bfb0-7dee549ac70f   10Gi       RWO            Delete           Bound    postgres-operator/my-postgres-pg-1-rgc4-pgdata   pgo                     91m
persistentvolume/pvc-4dde75fe-c392-4f75-b483-326dcd6e5d46   10Gi       RWO            Delete           Bound    postgres-operator/my-postgres-pg-1-45cl-pgdata   pgo                     91m
persistentvolume/pvc-ff62508e-e743-482d-a67b-19726c075c2c   10Gi       RWO            Delete           Bound    postgres-operator/my-postgres-pg-1-ctj8-pgdata   pgo                     91m

NAME                                                 STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
persistentvolumeclaim/my-postgres-pg-1-45cl-pgdata   Bound    pvc-4dde75fe-c392-4f75-b483-326dcd6e5d46   10Gi       RWO            pgo            91m
persistentvolumeclaim/my-postgres-pg-1-ctj8-pgdata   Bound    pvc-ff62508e-e743-482d-a67b-19726c075c2c   10Gi       RWO            pgo            91m
persistentvolumeclaim/my-postgres-pg-1-rgc4-pgdata   Bound    pvc-1e13602d-1455-46b7-bfb0-7dee549ac70f   10Gi       RWO            pgo            91m
persistentvolumeclaim/my-postgres-repo1              Bound    pvc-04060f68-9590-4af1-a341-2dd8e1b42055   10Gi       RWO            pgo            91m

PostgreSQL のデータ保存用の PVC とバックアップ保存用の PVC の要求サイズを 20GB に変更してみます。

$ vi kustomize/my-postgres/postgres.yaml
(省略)
spec:
  image: registry.developers.crunchydata.com/crunchydata/crunchy-postgres:centos8-14.2-0
  postgresVersion: 14
  instances:
    - name: pg-1
      replicas: 3
      dataVolumeClaimSpec:
        accessModes:
        - "ReadWriteOnce"
        resources:
          requests:
            storage: 20Gi
        storageClassName: pgo
  backups:
    pgbackrest:
      - name: repo1
        volume:
          volumeClaimSpec:
            accessModes:
            - "ReadWriteOnce"
            resources:
              requests:
                storage: 20Gi
            storageClassName: pgo
(省略)

$ kubectl apply -k kustomize/my-postgres/

PVC と PV のサイズが拡張されていることを確認します。

$ kubectl get pv,pvc -n postgres-operator
NAME                                                        CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                                            STORAGECLASS   REASON   AGE
persistentvolume/pvc-04060f68-9590-4af1-a341-2dd8e1b42055   20Gi       RWO            Delete           Bound    postgres-operator/my-postgres-repo1              pgo                     103m
persistentvolume/pvc-1e13602d-1455-46b7-bfb0-7dee549ac70f   20Gi       RWO            Delete           Bound    postgres-operator/my-postgres-pg-1-rgc4-pgdata   pgo                     103m
persistentvolume/pvc-4dde75fe-c392-4f75-b483-326dcd6e5d46   20Gi       RWO            Delete           Bound    postgres-operator/my-postgres-pg-1-45cl-pgdata   pgo                     103m
persistentvolume/pvc-ff62508e-e743-482d-a67b-19726c075c2c   20Gi       RWO            Delete           Bound    postgres-operator/my-postgres-pg-1-ctj8-pgdata   pgo                     103m

NAME                                                 STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
persistentvolumeclaim/my-postgres-pg-1-45cl-pgdata   Bound    pvc-4dde75fe-c392-4f75-b483-326dcd6e5d46   20Gi       RWO            pgo            103m
persistentvolumeclaim/my-postgres-pg-1-ctj8-pgdata   Bound    pvc-ff62508e-e743-482d-a67b-19726c075c2c   20Gi       RWO            pgo            103m
persistentvolumeclaim/my-postgres-pg-1-rgc4-pgdata   Bound    pvc-1e13602d-1455-46b7-bfb0-7dee549ac70f   20Gi       RWO            pgo            103m
persistentvolumeclaim/my-postgres-repo1              Bound    pvc-04060f68-9590-4af1-a341-2dd8e1b42055   20Gi       RWO            pgo            103m

allowVolumeExpansion 機能に対応していないストレージでは、既存の永続ボリュームのサイズを拡張できないため、ボリュームサイズが大きい、新しい PostgreSQL クラスタを作成し、既存のクラスタと同期させる必要があります。詳細についてはこちらを参照してください。

バックアップ

PGO のバックアップ/リストアは内部的に pgBackRest のバックアップ/リストアユーティリティを利用しています。定期的にフルバックアップまたは差分バックアップを取得することができます。バックアップのスケジュールは cron 表記で指定します。

定期バックアップのスケジュールは spec.backups.pgbackrest.repos.schedules で設定します。
例えば、以下のように設定すると、毎日午前1時にフルバックアップ、4時間ごとに差分バックアップを実行するようになります。

$ vi kustomize/my-postgres/postgres.yaml
(省略)
spec:
  backups:
    pgbackrest:
      image: registry.developers.crunchydata.com/crunchydata/crunchy-pgbackrest:centos8-2.36-1
      configuration:
      - secret:
          name: pgo-s3-creds
      global:
        repo2-path: /pgbackrest/postgres-operator/my-postgres/repo2
      repos:
      - name: repo1
        volume:
          volumeClaimSpec:
            accessModes:
            - "ReadWriteOnce"
            resources:
              requests:
                storage: 10Gi
      - name: repo2
        schedules:
          full: "0 1 * * *"
          incremental: "0 */4 * * *"
        s3:
          bucket: "crunchy-pg-backup"
          endpoint: "s3.us-west-2.amazonaws.com"
          region: "us-west-2"
(省略)

リストア

PostgreSQL クラスタの複製

PGO v5 では、既存の PostgreSQL クラスタを複製できます。
既存のクラスタを複製するには、spec.dataSource.postgresCluster にコピー元のクラスタ名、バックアップの格納先のリポジトリ名を指定します。

spec:
  dataSource:
    postgresCluster:
      clusterName: my-postgres
      repoName: repo2

デフォルトでは最新のデータにリストアしますが、spec.dataSource.postgresCluster.options を指定して、特定の時点までリストア可能です。

spec:
  dataSource:
    postgresCluster:
      clusterName: my-postgres
      repoName: repo2
      options:
      - --type=time
      - --target="2022-03-16 14:00:00+09"

既存の PostgreSQL クラスタの PITR

起動中の PostgreSQL クラスタを以前の時点にリストアするには spec.backups.pgbackrest.restore を設定します。既存のデータディレクトリでリストアを実行するので、クラスタが一旦停止され、作成しなおされます。

例えば、2022-03-16 14:00:00 時点までリストアする場合は、以下の手順を実行します。

まず、PostgresCluster リソースを設定する YAML ファイル postgres.yaml を編集し、適用します。
※この時点ではリストアが実行されません。

$ vi kustomize/my-postgres/postgres.yaml
(省略)
spec:
  backups:
    pgbackrest:
      restore:
        enabled: true
        repoName: repo2
        options:
        - --type=time
        - --target="2022-03-16 14:00:00+09"
(省略)

$ kubectl apply -k kustomize/my-postgres/

次に、PostgresCluster のアノテーションを設定します。
PostgresCluster のアノテーションを設定すると、リストアが実行されます。

$ kubectl annotate postgrescluster my-postgres  -n postgres-operator --overwrite \
  postgres-operator.crunchydata.com/pgbackrest-restore=id1

リストア完了後、リストアの設定を無効にしておきます。

$ vi kustomize/my-postgres/postgres.yaml
(省略)
spec:
  backups:
    pgbackrest:
      restore:
        enabled: false
(省略)

$ kubectl apply -k kustomize/my-postgres/

モニタリング

PGO は Prometheus によるモニタリング機能を提供しています。Kubernetes では Prometheus を利用した監視がよく使われています。Prometheus がクラスタの各種メトリクスを収集し、Grafana と連携して、Grafana のダッシュボードで Kubernetes クラスタと PostgreSQL を監視することができます。

モニタリング機能を利用するために、まず、各  Pod に Exporter サイドカーを追加する必要があります。

$ vi kustomize/my-postgres/postgres.yaml
(省略)
spec:
  monitoring:
    pgmonitor:
      exporter:
        image: registry.developers.crunchydata.com/crunchydata/crunchy-postgres-exporter:ubi8-5.0.5-0
(省略)

$ kubectl apply -k kustomize/my-postgres

$ kubectl get pods -n postgres-operator --selector=postgres-operator.crunchydata.com/cluster=my-postgres,postgres-operator.crunchydata.com/instance-set \
  -L postgres-operator.crunchydata.com/role
NAME                      READY   STATUS    RESTARTS   AGE     ROLE
my-postgres-pg-1-45cl-0   4/4     Running   0          3m4s    master
my-postgres-pg-1-ctj8-0   4/4     Running   0          3m35s   replica
my-postgres-pg-1-rgc4-0   4/4     Running   0          2m14s   replica

次に、監視アプリケーション Prometheus、Grafana、Alertmanager をデプロイします。

Amazon EKS のデフォルトのストレージクラス gp2 を利用しても良いですが、今回は前述の手順で作成したストレージクラスを利用します。Prometheus、Grafana、Alertmanager の PVC を定義する YAML ファイルを編集します。
※ デフォルトのストレージクラスを利用する場合は編集不要です。

$ vi kustomize/monitoring/pvcs.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  labels:
    app.kubernetes.io/name: pgo-monitoring
    vendor: crunchydata
  name: alertmanagerdata
spec:
(省略)
  storageClassName: pgo
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  labels:
    app.kubernetes.io/name: pgo-monitoring
    vendor: crunchydata
  name: grafanadata
spec:
(省略)
  storageClassName: pgo
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  labels:
    app.kubernetes.io/name: pgo-monitoring
    vendor: crunchydata
  name: prometheusdata
spec:
(省略)
  storageClassName: pgo

Prometheus、Grafana、Alertmanager をデプロイします。

$ kubectl apply -k kustomize/monitoring

Prometheus、Grafana、Alertmanager の Pod が起動していることを確認できます。

$ kubectl get pods -n postgres-operator --selector=app.kubernetes.io/name=postgres-operator-monitoring
NAME                                   READY   STATUS    RESTARTS   AGE
crunchy-alertmanager-f7b79cbd8-lfv7s   1/1     Running   0          4m47s
crunchy-grafana-548446d646-lqw4l       1/1     Running   0          4m45s
crunchy-prometheus-556f754797-98lcn    1/1     Running   0          4m44s

作業環境のブラウザから Grafana にアクセスするために、Grafana Pod の 3000 ポートをローカルの 3000 へポートフォワードを行います。

$ GRAFANA_POD=$(kubectl get pod -n postgres-operator -o name -l app.kubernetes.io/name=postgres-operator-monitoring,name=crunchy-grafana)
$ kubectl -n postgres-operator port-forward ${GRAFANA_POD} 3000:3000 &

ブラウザで http://localhost:3000/ にアクセスすると、Grafana のログイン画面が表示されます。Grafana のログインユーザ名とパスワードは以下のコマンドで確認できます。

$ kubectl get secret grafana-secret -n postgres-operator -ojsonpath='{.data.username}' | base64 --decode ; echo 
$ kubectl get secret grafana-secret -n postgres-operator -ojsonpath='{.data.password}' | base64 --decode ; echo

Grafana にログインし、ダッシュボードで Kubernetes クラスタや PostgreSQL の稼働状況を確認できます。

おわりに

今回は Crunchy Postgres Operator v5 について紹介しました。

インストールや管理方法が大幅に変更され、kubectl が使用できるようになり、以前のバージョンより構築・管理がさらに容易になりました。さらに詳しく知りたい方は、公式ドキュメントをご覧ください。

Kubernetes を用いて簡単にコンテナとしてアプリケーションをデプロイ・削除をできるのがメリットですが、コンテナを削除するとコンテナ内のデータも削除されてしまいます。そのため、データベースのようなステートフルアプリケーションを利用する場合には、データの永続化が必要となります。

今回は Charmed Kubernetes の永続ストレージ機能を紹介し、Charmed Kubernetes 上でのステートフルアプリケーションの構築について紹介します。

Kubernetes の永続ストレージ

Kubernetes の Podを削除すると Pod 内に保存されていたデータも一緒に削除されてしまいますので、データの永続化はできません。Kubernetes ノード上の領域を Pod にマウントすることで、Pod を削除した後もデータはノードに残るため、データの永続化は可能ですが、Pod が別ノードに再スケジュールされた場合にはデータの再利用ができないというデメリットがあります。

Kubernetes ノードとは別に外部ストレージを利用することで、Pod が削除されてもデータは外部ストレージに存在するため、データの永続化が可能です。また、外部ストレージはノードとは独立して存在しており、Pod が別のノードで再起動したとしてもデータが外部に存在するため、データの再利用が可能です。

Kubernetes でデータ永続化を実現するために、以下のリソースを利用します。

• PersistentVolume (PV)
• PersistentVolumeClaim (PVC)
• StorageClass

事前に永続ボリューム (PersistentVolume) リソースを Kubernetes 上に作成しておき、Pod デプロイ時に PersistentVolumeClaim によって PersistentVolume が要求されると、Kubernetes は事前に作成しておいた PersistentVolume から要求に適したものを Pod に割り当てます。このような方法では、予め PersistentVolume を作成する手間がかかり、また、PersistentVolumeClaim の要求以上の容量の PersistentVolume が割り当てられてしまうという問題があります。

これに対して、PersistentVolume を動的に作成する仕組み Dynamic Provisioning を利用することができます。Dynamic Provisioning は StorageClass を利用し、PersistentVolumeClaim によって PersistentVolume が要求されたタイミングで PersistentVolume を動的に作成し、Pod に割り当てます。Dynamic Provisioning を利用することで、事前に PersistentVolume を作成する手間が省けます。また、PersistentVolumeClaim の要求よりも大きい容量の PersistentVolume が作成されることも回避できます。

本稿では Charmed Kubernetes 上で Dynamic Provisioning を利用したデータ永続化のソリューションを紹介します。

Charmed Kubernetes の永続ストレージ

Charmed Kubernetes で以下の方法を用いてデータの永続化を実現することができます。

クラウドのストレージソリューション

Charmed Kubernetes のクラウド基盤統合機能を利用すると、クラウドベンダーによって提供されているストレージソリューションをすぐに使用できます。

例えば、OpenStack 統合機能を有効にして Charmed Kubernetes をデプロイすると、cdk-cinder という名前の StorageClass が自動的に作成されます。

Ceph

Ceph Charm を用いてデプロイした Ceph クラスタを外部ストレージとして使用し、PersistentVolume を作成します。

NFS

NFS Charm を用いてデプロイした NFS サーバを外部ストレージとして使用し、PersistentVolume を作成します。

ベアメタルにデプロイされた Kubernetes では、クラウドの機能を利用できないため、Ceph や NFS を利用することになります。本稿では、Juju を用いて Charmed Kubernetes 上に Ceph を構築し、ステートフルアプリケーションのデータの永続化を実現する方法を紹介します。

前提条件

Charmed Kubernetes のデプロイが既に完了していることが前提となっています。今回は AWS 上にデプロイした Charmed Kubernetes を利用します。(デプロイ方法はこちらを参照)

Ceph ストレージの構築

Ceph はオープンソースの分散ストレージソフトウェアです。

Kubernetes の永続ストレージに Ceph を利用すると、拡張可能な高可用ストレージを実現することができます。本節では、Juju を用いた Ceph ストレージの構築方法を説明します。

デプロイ済みの Charmed Kubernetes クラスタにアクセスし、ノード状態を確認します。まだデプロイしていない場合は、こちらのデプロイ手順を参照してください。

$ kubectl get node
NAME               STATUS   ROLES    AGE     VERSION
ip-172-31-54-236   Ready    <none>   9m48s   v1.23.4
ip-172-31-7-84     Ready    <none>   9m43s   v1.23.4
ip-172-31-90-192   Ready    <none>   9m43s   v1.23.4

セキュリティの観点から、モデルを分けることをお勧めしますが、本稿は Charmed Kubernetes 上で Ceph による Dynamic Provisioning を検証することが目的なので、Kubernetes と Ceph を同一 モデルにデプロイします。

Charmed Kubernetes がデプロイされているモデルに切り替えます。

$ juju switch k8s

Ceph Monitor ノードをデプロイします。

Ceph Monitor はクラスタの管理、状態監視を行うコンポーネントです。高可用性を実現するために、3台以上の奇数台が必要です。ここでは、3台の Ceph Monitor ノードをデプロイします。

$ juju deploy -n 3 ceph-mon

Ceph OSD ノードをデプロイします。

Ceph OSD はデータの保存、データの冗長化などを行うコンポーネントです。
Juju の ceph-osd Charm では、--storage オプションに2種類のストレージを設定できます。

• osd-devices: データを格納するストレージ
• osd-journals: ジャーナルを格納するストレージ

--storage オプションは <storage pool>,<size>,<number> 形式で指定します。

• storage pool: ストレージプールを指定します。ストレージプールはクラウド基盤に依存します。指定しない場合は、クラウド基盤のデフォルトのストレージプールを使用します。AWS のデフォルトのストレージプールは ebs となります。
• size: 各ボリュームのサイズを指定します。
• number: ボリュームの数を指定します。

ここでは、3台の Ceph OSD ノードをデプロイします。各 OSD ノードに2つのデータ用のボリューム（50GB）と1つのジャーナル用のボリューム（10GB）を作成します。

$ juju deploy -n 3 ceph-osd --storage osd-devices=50G,2 --storage osd-journals=10G,1

Ceph Monitor と Ceph OSD の関連付けを行います。

$ juju add-relation ceph-osd ceph-mon

RBD で作成した PersistentVolume のアクセスモードが ReadWriteOnce となりますので、アクセスモード ReadWriteMany の PersistentVolume を利用する場合には、CephFS をデプロイする必要があります。利用する場合には、以下のコマンドを実行し、CephFS のデプロイおよび関連付けの設定を行います。

$ juju deploy -n 1 ceph-fs
$ juju add-relation ceph-fs ceph-mon

Charmed Kubernetes で Ceph ストレージを利用するために、関連付けの設定を行います。

$ juju add-relation ceph-mon:admin kubernetes-master
$ juju add-relation ceph-mon:client kubernetes-master

Charmed Kubernetes と Ceph の関連付けの設定が完了したら、kubectl get sc を実行し、StorageClass が表示されていることを確認します。
※cephfs ストレージクラスは、ceph-fs をデプロイした場合にのみ表示されます。

$ kubectl get sc
NAME                PROVISIONER         RECLAIMPOLICY   VOLUMEBINDINGMODE  ALLOWVOLUMEEXPANSION  AGE
ceph-ext4           rbd.csi.ceph.com    Delete          Immediate          true                  2m39s
ceph-xfs (default)  rbd.csi.ceph.com    Delete          Immediate          true                  2m39s
cephfs              cephfs.csi.ceph.com Delete          Immediate          true                  2m39s

Pod の状態を確認します。
※cephfs の Pod は、ceph-fs をデプロイした場合にのみ表示されます。

$ kubectl get pod
NAME                                            READY   STATUS    RESTARTS   AGE
csi-cephfsplugin-927cv                          3/3     Running   0          18s
csi-cephfsplugin-b6q66                          3/3     Running   0          22s
csi-cephfsplugin-provisioner-6f7ffd894d-b2sh4   6/6     Running   0          101s
csi-cephfsplugin-provisioner-6f7ffd894d-d5b9x   6/6     Running   0          101s
csi-cephfsplugin-provisioner-6f7ffd894d-kqvxn   6/6     Running   0          101s
csi-cephfsplugin-vqgtb                          3/3     Running   0          15s
csi-rbdplugin-fsh7g                             3/3     Running   0          15s
csi-rbdplugin-nt2lq                             3/3     Running   0          22s
csi-rbdplugin-provisioner-7dffff7f4d-8l8l5      7/7     Running   0          101s
csi-rbdplugin-provisioner-7dffff7f4d-wmvct      7/7     Running   0          101s
csi-rbdplugin-provisioner-7dffff7f4d-z7nm9      7/7     Running   0          101s
csi-rbdplugin-ts8rw                             3/3     Running   0          19s

これで Ceph クラスタを Charmed Kubernetes の外部ストレージとして使用し Dynamic Provisioning を実現するための準備が完了です。

スケールアウト

Ceph のスケールアウトとは、新しいノードまたはデバイスを追加することによって利用可能な容量を拡張することです。本節では Ceph のスケールアウト手順について説明します。

Ceph ストレージの容量を拡張するには、Ceph OSD ノードを追加するか、既存の Ceph OSD ノードにストレージを追加します。

まず、既存のストレージの割り当てを確認します。

$ juju storage
Unit        Storage id      Type   Pool  Size   Status    Message
ceph-osd/0  osd-devices/0   block  ebs   50GiB  attached  
ceph-osd/0  osd-devices/1   block  ebs   50GiB  attached  
ceph-osd/0  osd-journals/2  block  ebs   10GiB  attached  
ceph-osd/1  osd-devices/3   block  ebs   50GiB  attached  
ceph-osd/1  osd-devices/4   block  ebs   50GiB  attached  
ceph-osd/1  osd-journals/5  block  ebs   10GiB  attached  
ceph-osd/2  osd-devices/6   block  ebs   50GiB  attached  
ceph-osd/2  osd-devices/7   block  ebs   50GiB  attached  
ceph-osd/2  osd-journals/8  block  ebs   10GiB  attached

新しい Ceph OSD ノードを追加します。

$ juju add-unit ceph-osd -n 1

新しいノード ceph-osd/3 が追加されていることを確認します。

$ juju storage
Unit        Storage id       Type   Pool  Size   Status    Message
ceph-osd/0  osd-devices/0    block  ebs   50GiB  attached  
ceph-osd/0  osd-devices/1    block  ebs   50GiB  attached  
ceph-osd/0  osd-journals/2   block  ebs   10GiB  attached  
ceph-osd/1  osd-devices/3    block  ebs   50GiB  attached  
ceph-osd/1  osd-devices/4    block  ebs   50GiB  attached  
ceph-osd/1  osd-journals/5   block  ebs   10GiB  attached  
ceph-osd/2  osd-devices/6    block  ebs   50GiB  attached  
ceph-osd/2  osd-devices/7    block  ebs   50GiB  attached  
ceph-osd/2  osd-journals/8   block  ebs   10GiB  attached  
ceph-osd/3  osd-devices/10   block  ebs   50GiB  attached  
ceph-osd/3  osd-devices/9    block  ebs   50GiB  attached  
ceph-osd/3  osd-journals/11  block  ebs   10GiB  attached

$ juju status ceph-osd
Model  Controller      Cloud/Region   Version  SLA          Timestamp
k8s    k8s-controller  aws/us-east-1  2.9.22   unsupported  15:39:18+09:00

App       Version  Status  Scale  Charm     Store     Channel  Rev  OS      Message
ceph-osd  15.2.14  active      4  ceph-osd  charmhub  stable   513  ubuntu  Unit is ready (2 OSD)

Unit         Workload  Agent  Machine  Public address  Ports  Message
ceph-osd/0*  active    idle   13       3.83.100.242           Unit is ready (2 OSD)
ceph-osd/1   active    idle   14       3.238.52.73            Unit is ready (2 OSD)
ceph-osd/2   active    idle   15       3.235.171.220          Unit is ready (2 OSD)
ceph-osd/3   active    idle   17       54.82.234.9            Unit is ready (2 OSD)

Machine  State    DNS            Inst id              Series  AZ          Message
13       started  3.83.100.242   i-074dcc388f5b35c1b  focal   us-east-1d  running
14       started  3.238.52.73    i-0b2d721800fd923d6  focal   us-east-1c  running
15       started  3.235.171.220  i-0e9916138314d204b  focal   us-east-1f  running
17       started  54.82.234.9    i-0cf8cad9824868068  focal   us-east-1a  running

既存の Ceph OSD ノードにストレージを追加するために、juju add-storage コマンドを実行します。以下のコマンドを実行し、ceph-osd/0 ノードに 50GB の新しいボリュームを追加します。

$ juju add-storage ceph-osd/0 osd-devices=50G,1

ceph-osd/0 ノードに 50GB のボリュームが追加されていることを確認します。

$ juju storage
Unit        Storage id       Type   Pool  Size   Status    Message
ceph-osd/0  osd-devices/0    block  ebs   50GiB  attached  
ceph-osd/0  osd-devices/1    block  ebs   50GiB  attached  
ceph-osd/0  osd-devices/12   block  ebs   50GiB  attached  
ceph-osd/0  osd-journals/2   block  ebs   10GiB  attached  
ceph-osd/1  osd-devices/3    block  ebs   50GiB  attached  
ceph-osd/1  osd-devices/4    block  ebs   50GiB  attached  
ceph-osd/1  osd-journals/5   block  ebs   10GiB  attached  
ceph-osd/2  osd-devices/6    block  ebs   50GiB  attached  
ceph-osd/2  osd-devices/7    block  ebs   50GiB  attached  
ceph-osd/2  osd-journals/8   block  ebs   10GiB  attached  
ceph-osd/3  osd-devices/10   block  ebs   50GiB  attached  
ceph-osd/3  osd-devices/9    block  ebs   50GiB  attached  
ceph-osd/3  osd-journals/11  block  ebs   10GiB  attached

アプリケーションをデプロイしてみる

Charmed Kubernetes の永続ストレージの動的プロビジョニング機能を検証するために、ステートフルアプリケーションをデプロイしてみます。

本稿では、ステートフルアプリケーションとして PostgreSQL を扱います。

Kubernetes 上で PostgreSQL を動かすために、PostgreSQL Operator が必要になります。PostgreSQL Operator は PostgreSQL のデプロイや管理を自動化するためのソフトウェアです。

今回は検証目的で Charmed Kubernetes 環境向けに開発された PostgreSQL Charmを利用して PostgreSQL を構築します。現時点では、PostgreSQL  Charm はスケーリングとフェイルオーバにのみ対応しており、バックアップやリストア・PITR などの管理は手動で行う必要があるため、本番環境での利用はお勧めしません。

本番環境で PostgreSQL をデプロイする場合は、以前の記事で紹介した Crunchy PostgreSQL Operator または Zalando PostgreSQL Operator を利用すると良いと思います。

Charmed Kubernetes  上に Juju チャームをデプロイするために、デプロイ済みの Charmed Kubernetes を Juju に登録する必要があります。

juju add-k8s コマンドを実行し、Charmed Kubernetes 環境を登録します。ここでは、my-k8s という名前で 登録します。

$ juju add-k8s my-k8s

pg-controller という名前でコントローラーをデプロイします。

$ juju bootstrap my-k8s pg-controller

PostgreSQL をデプロイするためのモデルを作成します。モデル名と同じ名前の Namespace が Kubernetes に作成され、PostgreSQL がこの Namespace にデプロイされます。

ここで pg-model という名前のモデルを作成します。

$ juju add-model pg-model

次に、PostgreSQL をデプロイします。

PostgreSQL Charm の –storage オプションに2種類のストレージを設定できます。

• pgdata: データベースのデータを格納するストレージ
• logs: PostgreSQL のログを格納するストレージ

$ juju deploy postgresql-k8s -n 3 --storage pgdata=20G --storage logs=1G

上記コマンドを実行すると、primary 1台、replica 2台 の PostgreSQL クラスタが作成されます。

$ kubectl get pod -n pg-model
NAME                             READY   STATUS    RESTARTS   AGE
modeloperator-7896f7f67d-pwch5   1/1     Running   0          4m17s
postgresql-k8s-0                 1/1     Running   0          2m14s
postgresql-k8s-1                 1/1     Running   0          2m14s
postgresql-k8s-2                 1/1     Running   0          2m14s
postgresql-k8s-operator-0        1/1     Running   0          3m8s

PersistentVolumeClaim (PVC) と PersistentVolume (PV) を確認してみましょう。
PostgreSQL Charm の PVC によって PV が自動的に作成されていることを確認します。

$ kubectl get pvc -n pg-model
NAME                               STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
logs-2c7ce802-postgresql-k8s-0     Bound    pvc-265cd94c-77ec-4862-b021-b9d199326ef6   1Gi        RWO            ceph-xfs       2m52s
logs-2c7ce802-postgresql-k8s-1     Bound    pvc-6f71aa9a-77fd-4de5-93a8-bcd4e88fe35d   1Gi        RWO            ceph-xfs       2m52s
logs-2c7ce802-postgresql-k8s-2     Bound    pvc-cbca4843-f12f-49e3-ae89-5436d9791819   1Gi        RWO            ceph-xfs       2m52s
pgdata-2c7ce802-postgresql-k8s-0   Bound    pvc-7b40a98c-6f00-4f64-8c0a-701ccc0515d3   20Gi       RWO            ceph-xfs       2m52s
pgdata-2c7ce802-postgresql-k8s-1   Bound    pvc-cd6415e2-2322-4b5f-89f2-640b8d65d515   20Gi       RWO            ceph-xfs       2m52s
pgdata-2c7ce802-postgresql-k8s-2   Bound    pvc-5eb9547b-e14a-42a3-9746-e012411121a7   20Gi       RWO            ceph-xfs       2m52s

$ kubectl get pv
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                                           STORAGECLASS   REASON   AGE
pvc-2572bd8d-286f-4ffd-89b6-e22a95a11873   20Gi       RWO            Delete           Bound    controller-pg-controller/storage-controller-0   ceph-xfs                6m30s
pvc-265cd94c-77ec-4862-b021-b9d199326ef6   1Gi        RWO            Delete           Bound    pg-model/logs-2c7ce802-postgresql-k8s-0         ceph-xfs                3m8s
pvc-5eb9547b-e14a-42a3-9746-e012411121a7   20Gi       RWO            Delete           Bound    pg-model/pgdata-2c7ce802-postgresql-k8s-2       ceph-xfs                3m6s
pvc-6f71aa9a-77fd-4de5-93a8-bcd4e88fe35d   1Gi        RWO            Delete           Bound    pg-model/logs-2c7ce802-postgresql-k8s-1         ceph-xfs                3m7s
pvc-7b40a98c-6f00-4f64-8c0a-701ccc0515d3   20Gi       RWO            Delete           Bound    pg-model/pgdata-2c7ce802-postgresql-k8s-0       ceph-xfs                3m8s
pvc-cbca4843-f12f-49e3-ae89-5436d9791819   1Gi        RWO            Delete           Bound    pg-model/logs-2c7ce802-postgresql-k8s-2         ceph-xfs                3m5s
pvc-cd6415e2-2322-4b5f-89f2-640b8d65d515   20Gi       RWO            Delete           Bound    pg-model/pgdata-2c7ce802-postgresql-k8s-1       ceph-xfs                3m7s

Replica の数を減らして、データが残るか検証します。

$ juju remove-unit postgresql-k8s --num-units 1

Pod が削除されても PVC と PV が削除されないことを確認します。

$ kubectl get pod -n pg-model
NAME                             READY   STATUS    RESTARTS   AGE
modeloperator-7896f7f67d-pwch5   1/1     Running   0          6m22s
postgresql-k8s-0                 1/1     Running   0          4m19s
postgresql-k8s-1                 1/1     Running   0          4m19s
postgresql-k8s-operator-0        1/1     Running   0          5m13s

$ kubectl get pvc -n pg-model
NAME                               STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
logs-2c7ce802-postgresql-k8s-0     Bound    pvc-265cd94c-77ec-4862-b021-b9d199326ef6   1Gi        RWO            ceph-xfs       4m37s
logs-2c7ce802-postgresql-k8s-1     Bound    pvc-6f71aa9a-77fd-4de5-93a8-bcd4e88fe35d   1Gi        RWO            ceph-xfs       4m37s
logs-2c7ce802-postgresql-k8s-2     Bound    pvc-cbca4843-f12f-49e3-ae89-5436d9791819   1Gi        RWO            ceph-xfs       4m37s
pgdata-2c7ce802-postgresql-k8s-0   Bound    pvc-7b40a98c-6f00-4f64-8c0a-701ccc0515d3   20Gi       RWO            ceph-xfs       4m37s
pgdata-2c7ce802-postgresql-k8s-1   Bound    pvc-cd6415e2-2322-4b5f-89f2-640b8d65d515   20Gi       RWO            ceph-xfs       4m37s
pgdata-2c7ce802-postgresql-k8s-2   Bound    pvc-5eb9547b-e14a-42a3-9746-e012411121a7   20Gi       RWO            ceph-xfs       4m37s

$ kubectl get pv
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                                           STORAGECLASS   REASON   AGE
pvc-2572bd8d-286f-4ffd-89b6-e22a95a11873   20Gi       RWO            Delete           Bound    controller-pg-controller/storage-controller-0   ceph-xfs                8m30s
pvc-265cd94c-77ec-4862-b021-b9d199326ef6   1Gi        RWO            Delete           Bound    pg-model/logs-2c7ce802-postgresql-k8s-0         ceph-xfs                5m8s
pvc-5eb9547b-e14a-42a3-9746-e012411121a7   20Gi       RWO            Delete           Bound    pg-model/pgdata-2c7ce802-postgresql-k8s-2       ceph-xfs                5m6s
pvc-6f71aa9a-77fd-4de5-93a8-bcd4e88fe35d   1Gi        RWO            Delete           Bound    pg-model/logs-2c7ce802-postgresql-k8s-1         ceph-xfs                5m7s
pvc-7b40a98c-6f00-4f64-8c0a-701ccc0515d3   20Gi       RWO            Delete           Bound    pg-model/pgdata-2c7ce802-postgresql-k8s-0       ceph-xfs                5m8s
pvc-cbca4843-f12f-49e3-ae89-5436d9791819   1Gi        RWO            Delete           Bound    pg-model/logs-2c7ce802-postgresql-k8s-2         ceph-xfs                5m5s
pvc-cd6415e2-2322-4b5f-89f2-640b8d65d515   20Gi       RWO            Delete           Bound    pg-model/pgdata-2c7ce802-postgresql-k8s-1       ceph-xfs                5m7s

おわりに

2回に渡って Canonical Kubernetes ディストリビューション Charmed Kubernetes を紹介しました。

エンタープライズ向けの機能を備えた Charmed Kubernetes は幅広いプラットフォームに対応しており、特にオンプレミスやプライベートクラウドにおいても容易に Kubernetes の環境を構築・管理できるという点は Charmed Kubernetes ならではの強みと言えます。オンプレミスやプライベートクラウドでエンタープライズ向けの Kubernetes を構築したい場合、Charmed Kubernetes は有力な選択肢だと言えるでしょう。

Canonical 社が提供する Charmed Kubernetes はパブリッククラウドからオンプレミスまで様々なプラットフォームに対応しており、サービスのデプロイツールである Juju を用いてオンプレミスやプライベートクラウドにおいても容易に Kubernetes の環境を構築・管理できます。

本記事では、 Charmed Kubernetes の特長、構築方法および主な機能について紹介します。

Charmed Kubernetes とは

Charmed Kubernetes は Linux ディストリビューション Ubuntu の開発元であるイギリスの Canonical 社が提供するエンタープライズ向けの Kubernetes ディストリビューションです。

パブリッククラウドからオンプレミスのプライベートクラウドや仮想化基盤、ベアメタルまで、幅広いプラットフォームに対応しており、高可用性、スケーリング、ダウンタイムなしのアップグレード、暗号化通信、永続ストレージなど、エンタープライズレベルのセキュリティと管理機能を備えています。

Charmed Kubernetes の特長

Charmed Kubernetes には次のような特長があります。

クラウド基盤との統合

Charmed Kubernetes は幅広いクラウド基盤と統合することができます。統合することによって、クラウドサービスのネイティブ機能を直接使用することもできます。例えば、AWSと統合することで、AWS が提供しているストレージサービス（EBS）やロードバランサーサービス（ELB）をデフォルトで利用可能です。

アップストリーム Kubernetes の最新バージョン対応

Charmed Kubernetes はアップストリーム Kubernetes と並行してリリースされているため、アップストリーム Kubernetes の最新バージョンへアップグレードすることができ、いち早く最新機能を活用することが可能です。

幅広いプラットフォームに対応

Charmed Kubernetes は幅広いプラットフォームに対応しています。現時点では以下のプラットフォームに対応しています。

• パブリッククラウド
  • Amazon AWS
  • Google GCE
  • Microsoft Azure
  • Oracle
  • Rackspace
  • Equinix Metal
• プライベートクラウド
  • OpenStack
  • VMware vSphere
  • MAAS
• ローカル
  • LXD

可用性とセキュリティに優れたエンタープライズ向けの Kubernetes

パブリッククラウドの場合は、クラウドベンダーが提供する機能によって、一部のデータセンターに障害が起きてもサービスが継続して利用できる構成となっています。一方、オンプレミスのプライベートクラウドの場合は、障害対策のためにサーバの冗長化やバックアップなどの措置が必要になります。

Charmed Kubernetes は高可用性機能を提供しており、一部のサーバに障害が起きても、Kubernetes クラスタが動作し続けます。また、Charmed Kubernetes のすべてのコンポーネントが TLS による暗号化通信を行うため、セキュアで堅牢な Kubernetes を実現できます。

Juju とは

Juju は Canonical 社が開発しているサービスをデプロイするための自動化ツールです。

Juju を用いて対応しているプラットフォーム上に複数の Ubuntu サーバの作成から、Kubernetes クラスタの構築まで、いくつかのコマンドを実行するだけで、簡単に行えます。

本記事では、Juju を用いて Charmed Kubernetes クラスタを構築し、以下の機能について動作確認を行います。

• スケーリング
• アップグレード
• モニタリング
• 永続ストレージ(こちらを参照)

検証環境およびバージョン情報

Charmed Kubernetes は様々なプラットフォーム上に構築できますが、本記事では気軽に利用できるパブリッククラウド AWS を使って Charmed Kubernetes を構築します。各ソフトウェアは投稿時点での最新バージョンを利用しています。

環境およびバージョン情報は以下の通りです。

• Kubernetes 1.23
• Juju 2.9.22
• ローカルの作業環境: Ubuntu 20.04.3 LTS (Focal Fossa)

Juju がクラウドにアクセスするために、認証情報の登録が必要になります。
AWS の場合は、アクセスキーとシークレットキーが必要になりますので、事前に確認しておいてください。

Charmed Kubernetesのデプロイ

Juju のインストール

Juju をインストールします。

$ sudo snap install juju --classic

kubectl のインストール

kubectl をインストールします。

$ sudo snap install kubectl --classic

クレデンシャルの追加

Juju に AWS にアクセスするためのクレデンシャルを登録します。

$ juju add-credential aws
Select region [any region, credential is not region specific]: <任意のリージョンを指定>
Using auth-type "access-key".
Enter access-key: <アクセスキー>
Enter secret-key: <シークレットアクセスキー>
Credential "aws" added locally for cloud "aws".

登録後、以下のコマンドを実行し、AWS が登録されていることを確認します。

$ juju clouds
...
Clouds available on the client:
Cloud      Regions  Default    Type  Credentials  Source    Description
aws        22       us-east-1  ec2   1            public    Amazon Web Services
localhost  1        localhost  lxd   0            built-in  LXD Container Hypervisor

Juju コントローラーのデプロイ

Juju コントローラーをデプロイします。

Juju コントローラーは、Juju を使ってデプロイされたサービスを管理するために使用されます。以下のコマンドを実行すると、us-east-1 リージョンの EC2 インスタンスに Juju コントローラーがデプロイされます。リージョンを指定したい場合には、juju bootstrap aws/<リージョン> <コントローラー名>を実行してください。

$ juju bootstrap aws k8s-controller

デフォルトでは、 「mem=4G cores=2 」の t2.medium タイプの EC2 インスタンスが Juju コントローラーのマシンとして作成されます。CPU やメモリを変更したい場合は、デプロイ時に --bootstrap-constraints を指定することでインスタンスタイプを変更できます。

$ juju bootstrap --bootstrap-constraints "mem=8G cores=4" aws k8s-controller

モデルの作成

Juju モデルはアプリケーションやマシンがデプロイされるワークスペースです。コントローラーは複数のモデルを持つことができますが、モデルは単一のコントローラーにしか関連付けられません。各モデルは複数のマシン、サービスを持つことができます。

サービスをデプロイする際に、デフォルトでは default というモデルにデプロイされますが、サービスごとにモデルを作成することを推奨されているため、ここでは Kubernetes 専用のモデルを作成します。

$ juju add-model k8s

モデルが作成されていることを確認します。

$ juju status
Model  Controller      Cloud/Region   Version  SLA          Timestamp
k8s    k8s-controller  aws/us-east-1  2.9.22   unsupported  12:02:03+09:00

$ juju models
Controller: k8s-controller

Model       Cloud/Region   Type  Status     Machines  Cores  Access  Last connection
controller  aws/us-east-1  ec2   available         1      2  admin   just now
default     aws/us-east-1  ec2   available         0      -  admin   53 seconds ago
k8s*        aws/us-east-1  ec2   available         0      -  admin   14 seconds ago

Kubernetes のデプロイ

準備ができましたので、早速 Kubernetes をデプロイしましょう。

Juju を利用してアプリケーションをデプロイするには、Charm または Bundle を使います。

Charm を利用することで任意のマシンにアプリケーションをデプロイできます。複数アプリケーションから構成されるサービスでは、アプリケーションデプロイ後、アプリケーション同士の関連付けを設定する必要があります。Bundle は YAML 形式で記述したスクリプトファイルで、マシンの作成から、アプリケーションのデプロイ、そして関連付けまでの一連の処理を自動的にセットアップしてくれるツールです。

今回は Charm から Kubernetes をデプロイします。また、AWS のストレージサービスなどを利用するために、--overlay を利用してクラウド統合機能を有効にします。--overlay については後述します。デフォルトでは最新版がインストールされます。バージョンを指定してインストールを行う場合は後述する Bundle を使用したインストールを参照してください。

$ wget https://raw.githubusercontent.com/charmed-kubernetes/bundle/master/overlays/aws-overlay.yaml
$ juju deploy charmed-kubernetes --overlay aws-overlay.yaml --trust

すべてのアプリケーションのデプロイが完了するまで、15分~20分程度かかります。すべてのアプリケーション（App） の「Status」が「active」になったらデプロイ完了です。

juju status コマンドで状態を確認してみましょう。

App には Kubernetes の各コンポーネント、Machine には各インスタンスが表示されます。デフォルトでは 11台のマシン（インスタンス）が立ち上がり、マスタノード2台、ワーカーノード3台の Kubernetes クラスタが構成されます。

$ juju status
Model  Controller      Cloud/Region   Version  SLA          Timestamp
k8s    k8s-controller  aws/us-east-1  2.9.22   unsupported  12:27:04+09:00

App                    Version   Status  Scale  Charm                  Store       Channel   Rev  OS      Message
aws-integrator         1.15.58   active      1  aws-integrator         charmstore  stable    174  ubuntu  Ready
containerd             go1.13.8  active      5  containerd             charmstore  stable    200  ubuntu  Container runtime available
easyrsa                3.0.1     active      1  easyrsa                charmstore  stable    441  ubuntu  Certificate Authority connected.
etcd                   3.4.5     active      3  etcd                   charmstore  stable    655  ubuntu  Healthy with 3 known peers
flannel                0.11.0    active      5  flannel                charmstore  stable    619  ubuntu  Flannel subnet 10.1.6.1/24
kubeapi-load-balancer  1.18.0    active      1  kubeapi-load-balancer  charmstore  stable    866  ubuntu  Loadbalancer ready.
kubernetes-master      1.23.4    active      2  kubernetes-master      charmstore  stable   1106  ubuntu  Kubernetes master running.
kubernetes-worker      1.23.4    active      3  kubernetes-worker      charmstore  stable    838  ubuntu  Kubernetes worker running.

Unit                      Workload  Agent  Machine  Public address  Ports             Message
aws-integrator/0*         active    idle   0        54.196.183.155                    Ready
easyrsa/0*                active    idle   1        34.232.80.105                     Certificate Authority connected.
etcd/0                    active    idle   2        54.204.103.118  2379/tcp          Healthy with 3 known peers
etcd/1                    active    idle   3        3.236.214.69    2379/tcp          Healthy with 3 known peers
etcd/2*                   active    idle   4        44.198.164.226  2379/tcp          Healthy with 3 known peers
kubeapi-load-balancer/0*  active    idle   5        107.22.102.7    443/tcp,6443/tcp  Loadbalancer ready.
kubernetes-master/0*      active    idle   6        44.200.39.125   6443/tcp          Kubernetes master running.
  containerd/3            active    idle            44.200.39.125                     Container runtime available
  flannel/3               active    idle            44.200.39.125                     Flannel subnet 10.1.2.1/24
kubernetes-master/1       active    idle   7        3.83.124.151    6443/tcp          Kubernetes master running.
  containerd/0*           active    idle            3.83.124.151                      Container runtime available
  flannel/0               active    idle            3.83.124.151                      Flannel subnet 10.1.6.1/24
kubernetes-worker/0*      active    idle   8        54.160.123.197  80/tcp,443/tcp    Kubernetes worker running.
  containerd/1            active    idle            54.160.123.197                    Container runtime available
  flannel/1*              active    idle            54.160.123.197                    Flannel subnet 10.1.42.1/24
kubernetes-worker/1       active    idle   9        54.209.207.221  80/tcp,443/tcp    Kubernetes worker running.
  containerd/2            active    idle            54.209.207.221                    Container runtime available
  flannel/2               active    idle            54.209.207.221                    Flannel subnet 10.1.13.1/24
kubernetes-worker/2       active    idle   10       3.81.86.195     80/tcp,443/tcp    Kubernetes worker running.
  containerd/4            active    idle            3.81.86.195                       Container runtime available
  flannel/4               active    idle            3.81.86.195                       Flannel subnet 10.1.35.1/24

Machine  State    DNS             Inst id              Series  AZ          Message
0        started  54.196.183.155  i-02e9a6edcd5ac1cd5  focal   us-east-1a  running
1        started  34.232.80.105   i-05671fd8500a33119  focal   us-east-1f  running
2        started  54.204.103.118  i-0f28aea6be2d08e9d  focal   us-east-1d  running
3        started  3.236.214.69    i-0159b2e42b4b9c24e  focal   us-east-1f  running
4        started  44.198.164.226  i-0fd02e8e11ec1bfef  focal   us-east-1c  running
5        started  107.22.102.7    i-0bbd5a7a0ef45e4ef  focal   us-east-1b  running
6        started  44.200.39.125   i-05096429e51aeaa39  focal   us-east-1c  running
7        started  3.83.124.151    i-07c224c10603b0218  focal   us-east-1d  running
8        started  54.160.123.197  i-03a01a0e7b2bfe073  focal   us-east-1e  running
9        started  54.209.207.221  i-003d3e37b1a655e2e  focal   us-east-1a  running
10       started  3.81.86.195     i-001459c2be09d5db8  focal   us-east-1b  running

Charmed Kubernetes 設定のカスタマイズ

Charmed Kubernetes の設定をカスタマイズする方法は2つあります。

• Bundle ファイルの使用
• Overlay の使用

Bundle ファイルの使用

Bundle ファイルは各種設定、デプロイの手順などを記載した YAML ファイルです。Bundle ファイルを必要に応じて編集することで、設定のカスタマイズが可能です。

特定の Kubernetes バージョンの Bundle ファイルは、こらちからダウンロードできます。

一例として、v1.21 の Bundle ファイルをダウンロードし、ワーカーノードの数を変更してみます。

$ wget https://api.jujucharms.com/charmstore/v5/charmed-kubernetes-733/archive/bundle.yaml
$ vi bundle.yaml
(ワーカーノードの数を3->4に変更)
...
kubernetes-worker:
annotations:
gui-x: '90'
gui-y: '850'
charm: cs:~containers/kubernetes-worker-838
constraints: cores=4 mem=4G root-disk=16G
expose: true
num_units: 4
...

Bundle ファイルを用いてデプロイします。

juju deploy ./bundle.yaml

Overlayの使用

--overlay オプションを利用することで、デフォルトの設定にマージ、またはデフォルトの設定を上書きすることができます。

例えば、Google Cloud 統合機能を利用する場合は、以下の設定を --overlay オプションに指定します。

description: Charmed Kubernetes overlay to add native GCP support.
applications:
  gcp-integrator:
    annotations:
      gui-x: "600"
      gui-y: "300"
    charm: cs:~containers/gcp-integrator
    num_units: 1
    trust: true
relations:
  - ['gcp-integrator', 'kubernetes-master']
  - ['gcp-integrator', 'kubernetes-worker']

各クラウドサービスむけの機能統合のYAMLファイルはこちらからダウンロードできます。

Google Cloud を利用する場合は、以下の手順を実行します。

$ wget https://raw.githubusercontent.com/charmed-kubernetes/bundle/master/overlays/gcp-overlay.yaml
$ juju deploy charmed-kubernetes --overlay gcp-overlay.yaml --trust

また、一部の設定を変更したい場合も、--overlay オプションが利用可能です。

例えば、ワーカーノードのデフォルトの制約は「constraints: cores=4 mem=4G root-disk=16G」となりますが、以下の設定を --overlay に設定することで、デフォルトの設定を上書きすることができます。

$ cat myoverlay.yaml
applications:
  kubernetes-worker:
    constraints: cores=4 mem=8G root-disk=100G
    num_units: 3

$ juju deploy charmed-kubernetes --overlay myoverlay.yaml

Kubernetes クラスタへ接続

Charmed Kubernetes のデプロイが完了したら、Kubernetes に接続してクラスタの状態を確認します。

まず、マスタノードから接続設定ファイルを取得します。

$ mkdir -p .kube
$ juju scp kubernetes-master/0:config ~/.kube/config

次に、馴染みのある kubectl get コマンドを実行し、ワーカーノードや Pod の状態を確認してみます。

$ kubectl get nodes
NAME                            STATUS   ROLES    AGE   VERSION
ip-172-31-26-174.ec2.internal   Ready    <none>   21m   v1.23.4
ip-172-31-42-12.ec2.internal    Ready    <none>   19m   v1.23.4
ip-172-31-49-88.ec2.internal    Ready    <none>   22m   v1.23.4

$ kubectl get pods --all-namespaces
NAME                            STATUS   ROLES    AGE   VERSION
ip-172-31-26-174.ec2.internal   Ready    <none>   21m   v1.23.4
ip-172-31-42-12.ec2.internal    Ready    <none>   19m   v1.23.4
ip-172-31-49-88.ec2.internal    Ready    <none>   22m   v1.23.4

$ kubectl get pods --all-namespaces
NAMESPACE                         NAME                                                      READY   STATUS    RESTARTS   AGE
ingress-nginx-kubernetes-worker   default-http-backend-kubernetes-worker-6cd58d8886-nthsf   1/1     Running   0          21m
ingress-nginx-kubernetes-worker   nginx-ingress-controller-kubernetes-worker-mb75q          1/1     Running   0          21m
ingress-nginx-kubernetes-worker   nginx-ingress-controller-kubernetes-worker-vjp95          1/1     Running   0          19m
ingress-nginx-kubernetes-worker   nginx-ingress-controller-kubernetes-worker-wgbfj          1/1     Running   0          18m
kube-system                       coredns-5564855696-b2fcm                                  1/1     Running   0          25m
kube-system                       kube-state-metrics-5ccbcf64d5-5g49x                       1/1     Running   0          25m
kube-system                       metrics-server-v0.5.1-79b4746b65-bzhm5                    2/2     Running   0          25m
kubernetes-dashboard              dashboard-metrics-scraper-5cd54464bf-kc54z                1/1     Running   0          25m
kubernetes-dashboard              kubernetes-dashboard-55796c99c-r7v76                      1/1     Running   0          25m

AWS 統合機能によって、デフォルトの StorageClass が自動的に作成されていることを確認します。

$ kubectl get sc
NAME      PROVISIONER             RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
cdk-ebs   kubernetes.io/aws-ebs   Delete          WaitForFirstConsumer   false                  26m

これで Kubernetes クラスタのデプロイは完了です。

スケーリング

Kubernetes クラスタのスケーリングとは、ワーカーノードを追加または削除することです。

Kubernetes クラスタにワーカーノードを追加することをクラスタのスケールアップ、クラスタからノードを削除することをクラスタのスケールダウンと言います。

Charmed Kubernetes では juju add-unit/remove-unit を実行することで、簡単にクラスタのスケールアップ/スケールダウンを行えます。

スケールアップ

新しいノードをクラスタに追加します。

$ juju add-unit kubernetes-worker -n 1

新しいワーカーノードが追加されていることを確認します。

$ juju status
...
kubernetes-worker/0*      active    idle   8        54.160.123.197  80/tcp,443/tcp    Kubernetes worker running.
  containerd/1            active    idle            54.160.123.197                    Container runtime available
  flannel/1*              active    idle            54.160.123.197                    Flannel subnet 10.1.42.1/24
kubernetes-worker/1       active    idle   9        54.209.207.221  80/tcp,443/tcp    Kubernetes worker running.
  containerd/2            active    idle            54.209.207.221                    Container runtime available
  flannel/2               active    idle            54.209.207.221                    Flannel subnet 10.1.13.1/24
kubernetes-worker/2       active    idle   10       3.81.86.195     80/tcp,443/tcp    Kubernetes worker running.
  containerd/4            active    idle            3.81.86.195                       Container runtime available
  flannel/4               active    idle            3.81.86.195                       Flannel subnet 10.1.35.1/24
kubernetes-worker/3       active    idle   11       174.129.117.55  80/tcp,443/tcp    Kubernetes worker running.
  containerd/5            active    idle            174.129.117.55                    Container runtime available
  flannel/5               active    idle            174.129.117.55                    Flannel subnet 10.1.7.1/24


$ kubectl get node -o wide
NAME                            STATUS   ROLES    AGE   VERSION   INTERNAL-IP     EXTERNAL-IP      OS-IMAGE             KERNEL-VERSION    CONTAINER-RUNTIME
ip-172-31-26-174.ec2.internal   Ready       44m   v1.23.4   172.31.26.174   54.209.207.221   Ubuntu 20.04.4 LTS   5.11.0-1028-aws   containerd://1.5.5
ip-172-31-42-12.ec2.internal    Ready       42m   v1.23.4   172.31.42.12    3.81.86.195      Ubuntu 20.04.4 LTS   5.11.0-1028-aws   containerd://1.5.5
ip-172-31-49-88.ec2.internal    Ready       45m   v1.23.4   172.31.49.88    54.160.123.197   Ubuntu 20.04.4 LTS   5.11.0-1028-aws   containerd://1.5.5
ip-172-31-83-85.ec2.internal    Ready       13m   v1.23.4   172.31.83.85    174.129.117.55   Ubuntu 20.04.4 LTS   5.11.0-1028-aws   containerd://1.5.5

スケールダウン

スケールダウンするときには、ノードを安全に停止・削除するために、その Node 上で実行中の Podを退去させてから、スケールダウンを行う必要があります。

検証用の Nginx の Pod をデプロイします。

$ kubectl create deployment --image=nginx nginx

Nginx の Pod がデプロイされているワーカーノードを確認します。「ip-172-31-83-85.ec2.internal」というノード（kubernetes-worker/3）にデプロイされています。今回は、kubernetes-worker/3 を削除してみます。

$ kubectl get pod -o wide
NAME                     READY   STATUS    RESTARTS   AGE     IP         NODE                           NOMINATED NODE   READINESS GATES
nginx-85b98978db-hsbvd   1/1     Running   0          2m41s   10.1.7.2   ip-172-31-83-85.ec2.internal

ノードを安全に停止・削除するために、以下のコマンドを実行し、kubernetes-worker/3 上で動作中の Nginx の Pod を移動させ、新たに Pod がスケジュールされないようにします。

$ juju run-action kubernetes-worker/3 pause --wait
unit-kubernetes-worker-3:
  UnitId: kubernetes-worker/3
  id: "2"
  results:
    Stderr: |
      WARNING: ignoring DaemonSet-managed Pods: ingress-nginx-kubernetes-worker/nginx-ingress-controller-kubernetes-worker-rwt52
  status: completed
  timing:
    completed: 2022-02-16 04:14:20 +0000 UTC
    enqueued: 2022-02-16 04:14:16 +0000 UTC
    started: 2022-02-16 04:14:17 +0000 UTC

上記コマンドを実行すると、ノードが SchedulingDisabled になり、Pod が別のノード上で起動していることを確認できます。

$ kubectl get node -o wide
NAME                            STATUS                     ROLES    AGE   VERSION   INTERNAL-IP     EXTERNAL-IP      OS-IMAGE             KERNEL-VERSION    CONTAINER-RUNTIME
ip-172-31-26-174.ec2.internal   Ready                         55m   v1.23.4   172.31.26.174   54.209.207.221   Ubuntu 20.04.4 LTS   5.11.0-1028-aws   containerd://1.5.5
ip-172-31-42-12.ec2.internal    Ready                         53m   v1.23.4   172.31.42.12    3.81.86.195      Ubuntu 20.04.4 LTS   5.11.0-1028-aws   containerd://1.5.5
ip-172-31-49-88.ec2.internal    Ready                         56m   v1.23.4   172.31.49.88    54.160.123.197   Ubuntu 20.04.4 LTS   5.11.0-1028-aws   containerd://1.5.5
ip-172-31-83-85.ec2.internal    Ready,SchedulingDisabled      24m   v1.23.4   172.31.83.85    174.129.117.55   Ubuntu 20.04.4 LTS   5.11.0-1028-aws   containerd://1.5.5

$ kubectl get pod -o wide
NAME                     READY   STATUS    RESTARTS   AGE    IP          NODE                           NOMINATED NODE   READINESS GATES
nginx-85b98978db-x9dzg   1/1     Running   0          2m5s   10.1.35.2   ip-172-31-42-12.ec2.internal

これで、kubernetes-worker/3 ノードを安全に削除することができます。

$ juju remove-unit kubernetes-worker/3

しばらく経つと、kubernetes-worker/3 ノードが削除されていることを確認できます。

$ juju status
...
kubernetes-worker/0*      active    idle   8        54.160.123.197  80/tcp,443/tcp    Kubernetes worker running.
  containerd/1            active    idle            54.160.123.197                    Container runtime available
  flannel/1*              active    idle            54.160.123.197                    Flannel subnet 10.1.42.1/24
kubernetes-worker/1       active    idle   9        54.209.207.221  80/tcp,443/tcp    Kubernetes worker running.
  containerd/2            active    idle            54.209.207.221                    Container runtime available
  flannel/2               active    idle            54.209.207.221                    Flannel subnet 10.1.13.1/24
kubernetes-worker/2       active    idle   10       3.81.86.195     80/tcp,443/tcp    Kubernetes worker running.
  containerd/4            active    idle            3.81.86.195                       Container runtime available
  flannel/4               active    idle            3.81.86.195                       Flannel subnet 10.1.35.1/24

$ kubectl get node -o wide
NAME                            STATUS   ROLES    AGE   VERSION   INTERNAL-IP     EXTERNAL-IP      OS-IMAGE             KERNEL-VERSION    CONTAINER-RUNTIME
ip-172-31-26-174.ec2.internal   Ready       68m   v1.23.4   172.31.26.174   54.209.207.221   Ubuntu 20.04.4 LTS   5.11.0-1028-aws   containerd://1.5.5
ip-172-31-42-12.ec2.internal    Ready       67m   v1.23.4   172.31.42.12    3.81.86.195      Ubuntu 20.04.4 LTS   5.11.0-1028-aws   containerd://1.5.5
ip-172-31-49-88.ec2.internal    Ready       69m   v1.23.4   172.31.49.88    54.160.123.197   Ubuntu 20.04.4 LTS   5.11.0-1028-aws   containerd://1.5.5

アップグレード

この節では、Charmed Kubernetes のマスタノードとワーカーノードのアップグレード方法を説明します。その他のコンポーネント containerd、easyrsa、etcd、flannel、kubeapi-load-balancer については、ドキュメントを参照してください。

Charmed Kubernetes のワーカーノードをアップグレードするために、2つの方法があります。

• Blue-green アップグレード: この方法では一時的により多くのリソースを利用しますが、一番安全でダウンタイムのないアップグレードを行えます。
• In-place アップグレード: この方法では既存のノードのアップグレードを行い、追加のリソースは必要ありませんが、サービスの停止が発生します。

本番環境で利用する場合は、Blue-green アップグレードを推奨します。

ここでは、Blue-green アップグレードを利用したワーカーノードのアップグレードを検証してみます。

アップグレードする前に、Charmed Kubernetes が対応している Kubernetes のバージョン情報を確認します。今回は v1.21 の Charmed Kubernetes を v1.23 にアップグレードします。

検証用の Kubernetes クラスタをデプロイします。

$ wget https://raw.githubusercontent.com/charmed-kubernetes/bundle/master/releases/1.21/bundle.yaml
$ juju deploy ./bundle.yaml

マスタノードとワーカーノードのバージョンを確認します。

$ juju status
...
App                    Version   Status       Scale  Charm                  Store       Channel   Rev  OS      Message
containerd             go1.13.8  active           5  containerd             charmstore  stable    146  ubuntu  Container runtime available
easyrsa                3.0.1     active           1  easyrsa                charmstore  stable    395  ubuntu  Certificate Authority connected.
etcd                   3.4.5     active           3  etcd                   charmstore  stable    607  ubuntu  Healthy with 1 known peer
flannel                0.11.0    active           3  flannel                charmstore  stable    571  ubuntu  Flannel subnet 10.1.78.1/24
kubeapi-load-balancer  1.18.0    active           1  kubeapi-load-balancer  charmstore  stable    814  ubuntu  Loadbalancer ready.
kubernetes-master      1.21.9    active           2  kubernetes-master      charmstore  stable   1034  ubuntu  Restarting snap.kube-proxy.daemon service
kubernetes-worker      1.21.9    active           3  kubernetes-worker      charmstore  stable    788  ubuntu  Waiting for kube-proxy to start.

$ juju scp kubernetes-master/0:config ~/.kube/config
$ kubectl get node
NAME               STATUS   ROLES    AGE    VERSION
ip-172-31-1-0      Ready    <none>   3m1s   v1.21.9
ip-172-31-44-16    Ready    <none>   3m9s   v1.21.9
ip-172-31-92-202   Ready    <none>   3m6s   v1.21.9

まず、kubeapi-load-balancer をアップグレードします。

$ juju upgrade-charm kubeapi-load-balancer

次に、マスタノードをアップグレードします。以下のようにバージョンを指定して、upgrade を実行すると、マスタノードのアップグレードが始まります。

$ juju upgrade-charm kubernetes-master
$ juju config kubernetes-master channel=1.23/stable

$ juju run-action kubernetes-master/0 upgrade
$ juju run-action kubernetes-master/1 upgrade

最後に、ワーカーノードをアップグレードします。ワーカーノードのアップグレードを検証するために、アプリケーションをデプロイします。

$ kubectl create deployment --image=nginx nginx
$ kubectl get pod -o wide
NAME                     READY   STATUS    RESTARTS   AGE     IP          NODE              NOMINATED NODE   READINESS GATES
nginx-74d589986c-d8gqr   1/1     Running   0          6m51s   10.1.30.2   ip-172-31-30-80              

ワーカーノードのバージョンを設定します。

$ juju upgrade-charm kubernetes-worker
$ juju config kubernetes-worker channel=1.23/stable

$ kubectl get node
NAME               STATUS   ROLES    AGE   VERSION
ip-172-31-14-158   Ready    <none>   25m   v1.21.9
ip-172-31-30-80    Ready    <none>   25m   v1.21.9
ip-172-31-64-109   Ready    <none>   23m   v1.21.9

新たにワーカーノードを3つ追加します。新しく追加されるワーカーノードは新しいバージョンで作成されます。

$ juju add-unit kubernetes-worker -n 3

$ kubectl get node
NAME               STATUS   ROLES    AGE     VERSION
ip-172-31-14-158   Ready    <none>   44m     v1.21.9
ip-172-31-30-80    Ready    <none>   44m     v1.21.9
ip-172-31-46-231   Ready    <none>   70s     v1.23.4
ip-172-31-46-47    Ready    <none>   4m58s   v1.23.4
ip-172-31-64-109   Ready    <none>   42m     v1.21.9
ip-172-31-81-150   Ready    <none>   2m13s   v1.23.4

旧バージョンのワーカーノードを一時停止します。

$ juju run-action kubernetes-worker/0 pause
$ juju run-action kubernetes-worker/1 pause
$ juju run-action kubernetes-worker/2 pause

すると、Nginx の Pod が新バージョンのワーカーノードに移動されます。

$ kubectl get pod -o wide
NAME                                READY   STATUS    RESTARTS   AGE     IP          NODE               NOMINATED NODE   READINESS GATES
nginx-deployment-74d589986c-d8gqr   1/1     Running   0          17m     10.1.30.2   ip-172-31-81-150              

これで、旧バージョンのワーカーノード安全に削除することができます。

$ juju remove-unit kubernetes-worker/0
$ juju remove-unit kubernetes-worker/1
$ juju remove-unit kubernetes-worker/2

$ kubectl get node
NAME               STATUS   ROLES    AGE   VERSION
ip-172-31-46-231   Ready    <none>   22m   v1.23.4
ip-172-31-46-47    Ready    <none>   26m   v1.23.4
ip-172-31-81-150   Ready    <none>   24m   v1.23.4

$ juju status
App                    Version   Status  Scale  Charm                  Store       Channel  Rev   OS      Message
containerd             go1.13.8  active  4      containerd             charmstore  stable   200   ubuntu  Container runtime available
easyrsa                3.0.1     active  1      easyrsa                charmstore  stable   441   ubuntu  Certificate Authority connected.
etcd                   3.4.5     active  1      etcd                   charmstore  stable   655   ubuntu  Healthy with 1 known peer
flannel                0.11.0    active  4      flannel                charmstore  stable   619   ubuntu  Flannel subnet 10.1.66.1/24
kubeapi-load-balancer  1.18.0    active  1      kubeapi-load-balancer  charmstore  stable   866   ubuntu  Loadbalancer ready.
kubernetes-master      1.23.4    active  1      kubernetes-master      charmstore  stable   1106  ubuntu  Kubernetes master running.
kubernetes-worker      1.23.4    active  3      kubernetes-worker      charmstore  stable   838   ubuntu  Kubernetes worker running.

モニタリング

Charmed Kubernetes では Prometheus によるモニタリング機能が利用可能です。

Kubernetes では Prometheus を利用した監視がよく使われています。Prometheus がクラスタの各種メトリクスを収集し、Grafana と連携して、Grafana のダッシュボードで Kubernetes クラスタとクラスタ上で動作するアプリケーションを監視することができます。

Prometheus によるモニタリング機能を利用するために、Bundleファイルをダウンロードし、デプロイ時に --overlay オプションに指定します。

$ wget https://raw.githubusercontent.com/charmed-kubernetes/bundle/master/overlays/monitoring-pgt-overlay.yaml
$ juju deploy charmed-kubernetes --overlay monitoring-pgt-overlay.yaml

prometheus、grafana、telegraf が起動していることを確認できます。

$ juju status
Model  Controller      Cloud/Region   Version  SLA          Timestamp
k8s    k8s-controller  aws/us-east-1  2.9.22   unsupported  15:17:06+09:00

App                    Version   Status  Scale  Charm                  Store       Channel  Rev   OS      Message
containerd             go1.13.8  active  4      containerd             charmstore  stable   200   ubuntu  Container runtime available
easyrsa                3.0.1     active  1      easyrsa                charmstore  stable   441   ubuntu  Certificate Authority connected.
etcd                   3.4.5     active  1      etcd                   charmstore  stable   655   ubuntu  Healthy with 1 known peer
flannel                0.11.0    active  4      flannel                charmstore  stable   619   ubuntu  Flannel subnet 10.1.24.1/24
grafana                          active  1      grafana                charmhub    stable   51    ubuntu  Ready
kubeapi-load-balancer  1.18.0    active  1      kubeapi-load-balancer  charmstore  stable   866   ubuntu  Loadbalancer ready.
kubernetes-master      1.23.4    active  1      kubernetes-master      charmstore  stable   1106  ubuntu  Kubernetes master running.
kubernetes-worker      1.23.4    active  3      kubernetes-worker      charmstore  stable   838   ubuntu  Kubernetes worker running.
prometheus                       active  1      prometheus2            charmhub    stable   25    ubuntu  Ready
telegraf                         active  4      telegraf               charmhub    stable   44    ubuntu  Monitoring kubernetes-worker/1 (source version/commit 26e531a)
...

以下のコマンドを実行し、Grafana の URL とログイン情報を取得します。

$ juju run-action --wait grafana/0 get-login-info
unit-grafana-0:
  UnitId: grafana/0
  id: "4"
  results:
    password: 3cSfb2PshGHPLWJ4
    url: http://<IP/ Address>:3000/
    username: admin
  status: completed
...

ブラウザから上記コマンドで確認した Grafana の URL に接続し、ログインします。Grafana のダッシュボードで Kubernetes クラスタ全体のリソースの使用状況などが確認できます。

おわりに

今回は Canonical Kubernetes ディストリビューション Charmed Kubernetes の特長、構築方法、スケーリング、アップグレード、モニタリング機能について紹介しましたが、いかがでしたでしょうか。

Juju というアプリケーションのデプロイツールを用いてオンプレミスでもコマンドを実行するだけで容易に Kubernetes 環境を構築できる Charmed Kubernetes は魅力的ではないでしょうか。

次回はエンタープライズでの利用に欠かせない永続的ストレージについて説明します。

今回はマルチクラウド Kubernetes 構成に対応した Crunchy PostgreSQL Operator の高可用性とディザスタリカバリ (DR) について紹介します。

マルチクラウド Kubernetes とは

マルチクラウド Kubernetes は特定の地域やクラウドサービスに依存せず、 複数のクラウドにまたがって Kubernetes クラスタをデプロイすることで、アプリケーションの可用性と耐障害性を向上させる構成です。

Kubernetes では Pod レベルもしくはノードレベルの障害を自動復旧させることはできますが、Kubernetes クラスタが所属している地域に災害が起きた場合、またはクラウドサービスが利用不能になった場合には、Kubernetes クラスタ全体がダウンしてしまいます。

マルチクラウド Kubernetes 構成を組むことで、一方の Kubernetes クラスタがダウンしても、別のクラスタでサービスを継続させることで、システムのダウンタイムを最小限に抑え、迅速に障害や災害から復旧することが可能になります。

しかし、複数の Kubernetes クラスタやクラウドをまたいでデータベースを管理し、データの同期を行うのは極めて困難です。Crunchy PostgreSQL Operator を利用することで、クラウド間で自動的にレプリケーションされている複数の PostgreSQL クラスタを容易に構築・運用できます。

マルチクラウド Kubernetes に対応した Crunchy PostgreSQL Operator

Crunchy PostgreSQL Operator は PostgreSQL インスタンスレベルの可用性を実現することもできますが、複数の Kubernetes クラスタにデプロイしている PostgreSQL クラスタを同期させ、クラスタ間でもフェイルオーバーさせることが可能です。さらに、複数の Kubernetes クラスタを物理的に独立した地域やクラウドに分散配置することでディザスタリカバリにも活用できます。

次の図は、Crunchy PostgreSQL Operator を用いたマルチクラウド Kubernetes の構成図になります。2つの独立した Kubernetes クラスタを異なるクラウドサービス、異なるリージョンに配置します。PostgreSQL クラスタをそれぞれの Kubernetes クラスタにデプロイし、アクティブ/スタンバイ構成で冗長化します。

上記の構成図では、例として PostgreSQL アクティブクラスタを AWS に、スタンバイクラスタを GCP にデプロイしていますが、基本的には Crunchy PostgreSQL Operator が対応しているクラウド環境であれば、どの環境でも使用できます。また、オブジェクトストレージとしては S3 (もしくは S3と互換性のあるオブジェクトストレージ) と GCS のどちらでも利用できます。

上記構成の仕組みについて詳しく説明すると、

• PostgreSQL アクティブクラスタが定期的にバックアップと WAL アーカイブをオブジェクトストレージに保存します。
• PostgreSQL スタンバイクラスタが継続的にオブジェクトストレージから WAL を読み込んで、PostgreSQL のアクティブ・スタンバイクラスタ間で同期を行います。
• アクティブクラスタに障害が発生した場合は、手動でスタンバイクラスタをアクティブクラスタに昇格し、サービスを継続させることができます。
• また、ダウンしていた旧アクティブクラスタは手動操作により、スタンバイクラスタとして復旧することも可能です。

検証環境

本記事では、Crunchy PostgreSQL Operator を利用し、AWS と GCP を組み合わせたマルチクラウド環境で動作確認を行いました。検証環境の構成は以下の通りです。

• PostgreSQL アクティブクラスタ
  • Kubernetes クラスタ: EKS (AWS が提供するマネージド Kubernetes サービス)
  • リージョン: 東京リージョン
• PostgreSQL スタンバイクラスタ
  • Kubernetes クラスタ: GKE (Google が提供するマネージド Kubernetes サービス)
  • リージョン: 大阪リージョン
• オブジェクトストレージ
  • Amazon S3
  • リージョン: 東京リージョン

本記事では投稿時点での各ソフトウェアの最新バージョンを用いて以下の項目について動作確認を行いました。

• バージョン情報
  • Crunchy PostgreSQL Operator 4.7.0
  • PostgreSQL 13.3
  • Kubernetes 1.20
• 動作確認項目
  • PostgreSQL アクティブクラスタのデプロイ
  • PostgreSQL スタンバイクラスタのデプロイ
  • クラスタ間レプリケーションの確認
  • PostgreSQL スタンバイクラスタの昇格
  • 旧 PostgreSQL アクティブクラスタの復旧

なお、動作確認を行う前に、以下項目がすでに完了しているものとします。

• EKS クラスタの作成 (こちらを参照)
• GKE クラスタの作成 (こちらを参照)
• Amazon S3 バケットの作成 (こちらを参照)

PostgreSQL Operator および pgo のインストール・設定

動作確認を行う前に、それぞれの Kubernetes クラスタにおいて、Crunchy PostgreSQL Operator および pgo クライアントコマンドのインストール・設定を行います。クラスタの切り替えは kubectl config use-context <クラスタ名> コマンドを使用します。クラスタの一覧は kubectl config get-contexts コマンドで確認できます。

まず、Amazon EKS クラスタに接続します。

Crunchy PostgreSQL Operator をインストールします。

$ kubectl config use-context <EKSクラスタ名>
$ curl -LO https://raw.githubusercontent.com/CrunchyData/postgres-operator/v4.7.0/installers/kubectl/postgres-operator.yml
$ kubectl create namespace pgo
$ kubectl apply -f postgres-operator.yml

pgo コマンドのインストール・設定を行います。本記事では、ローカル環境から各 Kubernetes クラスタに接続し、各種操作を行いますので、それぞれのクラスタに接続するための情報を $HOME/.pgo/eks と $HOME/.pgo/gke に格納します。

$ curl -LO https://raw.githubusercontent.com/CrunchyData/postgres-operator/v4.7.0/installers/kubectl/client-setup.sh
$ chmod +x client-setup.sh
$ ./client-setup.sh
$ mv $HOME/.pgo/pgo/pgo /usr/local/bin/pgo
$ mv $HOME/.pgo/pgo $HOME/.pgo/eks
$ cat >> $HOME/env-eks <<EOF
export PGOUSER=$HOME/.pgo/eks/pgouser
export PGO_CA_CERT=$HOME/.pgo/eks/client.crt
export PGO_CLIENT_CERT=$HOME/.pgo/eks/client.crt
export PGO_CLIENT_KEY=$HOME/.pgo/eks/client.key
export PGO_APISERVER_URL='https://127.0.0.1:8443/'
export PGO_NAMESPACE=pgo
EOF
$ source $HOME/env-eks
$ kubectl -n pgo port-forward svc/postgres-operator 8443:8443 &

設定完了後、pgo コマンドを実行してみます。バージョン番号が表示されれば、正しく設定できています。

$ pgo version
pgo client version 4.7.0
Handling connection for 8443
pgo-apiserver version 4.7.0

次に、GKE クラスタに切り替えて、同様の設定を行います。

$ kubectl config use-context <GKEクラスタ名>
$ kubectl create namespace pgo
$ kubectl apply -f postgres-operator.yml
$ ./client-setup.sh
$ mv $HOME/.pgo/pgo $HOME/.pgo/gke

ローカルの 8443 ポートがすでにアクティブクラスタへの接続で使われていますので、スタンバイクラスタへの接続はローカルの 8444 ポートを使用します。

$ cat >> $HOME/env-gke <<EOF
export PGOUSER=$HOME/.pgo/gke/pgouser
export PGO_CA_CERT=$HOME/.pgo/gke/client.crt
export PGO_CLIENT_CERT=$HOME/.pgo/gke/client.crt
export PGO_CLIENT_KEY=$HOME/.pgo/gke/client.key
export PGO_APISERVER_URL='https://127.0.0.1:8444/'
export PGO_NAMESPACE=pgo
EOF
$ source $HOME/env-gke
$ kubectl -n pgo port-forward svc/postgres-operator 8444:8443 &

正しく設定されているかを確認します。

$ pgo version
pgo client version 4.7.0
Handling connection for 8444
pgo-apiserver version 4.7.0

以上で、PostgreSQL Operator および pgo コマンドのインストール・設定が完了です。

ここからは、Crunchy PostgreSQL Operator を用いたマルチクラウド Kubernetes の動作確認を行います。

PostgreSQL アクティブクラスタのデプロイ

まず、EKS クラスタ上に、PostgreSQL アクティブクラスタをデプロイします。

$ kubectl config use-context <EKSクラスタ名> && source $HOME/env-eks
$ pgo create cluster hippo \
--replica-count=2 \
--pgbackrest-storage-type="s3" \
--pgbackrest-s3-bucket="crunchy-pg-backup" \
--pgbackrest-s3-region="ap-northeast-1" \
--pgbackrest-s3-endpoint="s3.ap-northeast-1.amazonaws.com" \
--pgbackrest-s3-key="XXXXXXXX" \
--pgbackrest-s3-key-secret="XXXXXXXXXXXXXXXXXXXXXXXXX" \
--password-superuser="postgres" \
--password-replication="postgres" \
--password="postgres"

それぞれのオプションの意味は以下の通りです。

• --replica-count: レプリカの数。2を指定すると、プライマリ1台、レプリカ2台がストリーミングレプリケーションを構成します。
• --pgbackrest-storage-type: バックアップと WAL アーカイブの保存先。s3 または gcs を指定します。Kubernetes の永続ボリュームにも保存したい場合は、local,s3 または local,gcs を指定します。
• --pgbackrest-s3-bucket: Amazon S3 の Bucket 名。
• --pgbackrest-s3-region: Amazon S3 のリージョン。
• --pgbackrest-s3-endpoint: Amazon S3 のエンドポイント。
• --pgbackrest-s3-key: アクセスキーID。
• --pgbackrest-s3-key-secret: シークレットアクセスキー。
• --password-superuser: postgres スーパーユーザのパスワード。
• --password-replication: レプリケーション用のユーザのパスワード。
• --password: クラスタ作成時に作られる一般ユーザのパスワード。

--password-superuser や--password-replication、--password にそれぞれのユーザのパスワードを指定します。指定しない場合はランダムに生成されます。ここでは、検証目的のため、すべてのユーザのパスワードを「postgres」と指定しています。

しばらくしたら、クラスタの状態を確認します。プライマリ、レプリカそれぞれの Pod (Instance) と Serviceが  UP 状態になっていれば、正常に起動できています。PostgreSQL アクティブクラスタが定期的に WAL アーカイブを S3 に転送します。

$ pgo test hippo
cluster : hippo
Services
primary (10.100.113.239:5432): UP
replica (10.100.57.205:5432): UP
Instances
primary (hippo-7b8b78bf8f-2pd7c): UP
replica (hippo-fmju-7d7586ffcf-mlzxj): UP
replica (hippo-hyrz-789c4bb98c-fkgbf): UP

PostgreSQL スタンバイクラスタのデプロイ

次に、GKE クラスタ上に、PostgreSQL スタンバイクラスタをデプロイします。PostgreSQL スタンバイクラスタが継続的に S3 から WAL を読み込み、変更を適用します。

$ kubectl config use-context <GKEクラスタ名> && source $HOME/env-gke
$ pgo create cluster hippo-standby \
--standby \
--replica-count=2 \
--pgbackrest-storage-type="s3" \
--pgbackrest-s3-bucket="crunchy-pg-backup" \
--pgbackrest-s3-region="ap-northeast-1" \
--pgbackrest-s3-endpoint="s3.ap-northeast-1.amazonaws.com" \
--pgbackrest-s3-key="XXXXXXXX" \
--pgbackrest-s3-key-secret="XXXXXXXXXXXXXXXXXXXXXXXXX" \
--pgbackrest-repo-path="/backrestrepo/hippo-backrest-shared-repo" \
--password-superuser="postgres" \
--password-replication="postgres" \
--password="postgres"

それぞれのオプションの意味は以下の通りです。

• --standby: スタンバイクラスタとして起動します。
• --replica-count: レプリカの数。2を指定すると、スタンバイ1台、レプリカ2台がカスケードレプリケーションを構成します。
• --pgbackrest-storage-type: アクティブクラスタのバックアップと WAL アーカイブの保存先。s3 または gcs を指定します。
• --pgbackrest-s3-bucket: Amazon S3 の Bucket 名。
• --pgbackrest-s3-region: Amazon S3 のリージョン。
• --pgbackrest-s3-endpoint: Amazon S3 のエンドポイント。
• --pgbackrest-s3-key: アクセスキーID。
• --pgbackrest-s3-key-secret: シークレットアクセスキー。
• --pgbackrest-repo-path: バックアップや WAL アーカイブを格納するディレクトリのパス。
• --password-superuser: アクティブクラスタで設定している postgres スーパーユーザのパスワード。
• --password-replication: アクティブクラスタで設定しているレプリケーション用のユーザのパスワード。
• --password: アクティブクラスタで設定している一般ユーザのパスワード。

--password-superuser や --password-replication、--password に指定しているパスワードとアクティブクラスタで指定しているパスワードが一致している必要があるので、注意してください。
しばらくしたら、クラスタの状態を確認します。

$ pgo test hippo-standby
cluster : hippo-standby
Services
primary (10.8.7.45:5432): UP
replica (10.8.2.146:5432): UP
Instances
primary (hippo-standby-5848d9d45c-j52n5): UP
replica (hippo-standby-eezm-b757c4d98-qt6pr): UP
replica (hippo-standby-jgom-5976f8bf8-lb54f): UP

レプリケーションの確認

PostgreSQL アクティブ/スタンバイクラスタのデプロイが完了したら、クラスタ間でレプリケーションが正しく動作するかを確認します。

まず、アクティブクラスタのプライマリに接続し、データの更新を行います。

$ kubectl config use-context <EKSクラスタ名> && source $HOME/env-eks
$ kubectl port-forward svc/hippo 5432:5432 -n pgo &

$ PASSWORD=$(kubectl get secret hippo-postgres-secret -n pgo -o 'jsonpath={.data.password}' | base64 -d)
$ PGPASSWORD=$PASSWORD psql -h 127.0.0.1 -U postgres
postgres=# create table t1 (id int);
postgres=# insert into t1 select generate_series(1,10);

次に、スタンバイクラスタに接続し、データが同期されていることを確認します。

$ kubectl config use-context <GKEクラスタ名> && source $HOME/env-gke
$ kubectl port-forward svc/hippo-standby 5433:5432 -n pgo &
$ PASSWORD=$(kubectl get secret hippo-standby-postgres-secret -n pgo -o 'jsonpath={.data.password}' | base64 -d)
$ PGPASSWORD=$PASSWORD psql -h 127.0.0.1 -U postgres -p 5433
postgres=# select * from t1;
id
----
1
2
3
4
5
6
7
8
9
10

アクティブクラスタで行った更新がスタンバイクラスタに反映されているので、レプリケーションが正しく設定されていることがわかります。

PostgreSQL スタンバイクラスタの昇格

アクティブクラスタに障害が発生した場合、手動でスタンバイクラスタをアクティブクラスタに昇格することが可能です。

ここではアクティブクラスタを停止し、疑似的にクラスタ障害を起こします。

$ kubectl config use-context <EKSクラスタ名> && source $HOME/env-eks
$ pgo update cluster hippo --shutdown
WARNING: Are you sure? (yes/no): yes
Handling connection for 8443
updated pgcluster hippo

スプリットブレイン状態にならないように、アクティブクラスタが完全に停止しているかを確認します。

$ pgo test hippo
cluster : hippo
Services
Instances
primary (): DOWN

アクティブクラスタが DOWN という状態になったら、スタンバイクラスタを昇格させます。

$ kubectl config use-context <GKEクラスタ名> && source $HOME/env-gke
$ pgo update cluster hippo-standby --promote-standby
Disabling standby mode will enable database writes for this cluster.
Please ensure the cluster this standby cluster is replicating from has been properly shutdown before proceeding!
WARNING: Are you sure? (yes/no): yes
Handling connection for 8444
updated pgcluster hippo-standby

上記コマンドを実行すると、スタンバイクラスタがアクティブクラスタに昇格され、書き込みクエリ/読み取りクエリを処理できるようになります。

$ PASSWORD=$(kubectl get secret hippo-standby-postgres-secret -n pgo -o 'jsonpath={.data.password}' | base64 -d)
$ PGPASSWORD=$PASSWORD psql -h 127.0.0.1 -U postgres -p 5433
postgres=# insert into t1 select generate_series(11,20);
INSERT 0 10

スタンバイクラスタ昇格後、新しいタイムラインが生成され、新しいアクティブクラスタが定期的に WAL アーカイブを S3 に転送します。以下のコマンドで WAL アーカイブを格納するディレクトリの中身を確認できます。

$ aws s3 ls --recursive s3://crunchy-pg-backup/backrestrepo/hippo-backrest-shared-repo/archive/db/13-1/
2021-06-24 15:45:48 1861462 backrestrepo/hippo-backrest-shared-repo/archive/db/13-1/0000000100000000/000000010000000000000001-f8f3f3cf686b527c734c658cd6225294e708d398.gz
2021-06-24 15:46:47 16882 backrestrepo/hippo-backrest-shared-repo/archive/db/13-1/0000000100000000/000000010000000000000002-b354378ca96866d80fb0ce5dde0bc20e5e97811c.gz
2021-06-24 15:47:22 370 backrestrepo/hippo-backrest-shared-repo/archive/db/13-1/0000000100000000/000000010000000000000002.00000028.backup
2021-06-24 15:47:22 16834 backrestrepo/hippo-backrest-shared-repo/archive/db/13-1/0000000100000000/000000010000000000000003-d19c52e43342f0677293844fce0e9763bd4dc0fd.gz
2021-06-24 15:49:21 16936 backrestrepo/hippo-backrest-shared-repo/archive/db/13-1/0000000100000000/000000010000000000000004-e4353d933eee841030b4a644d457645510501e38.gz
2021-06-24 15:51:22 16461 backrestrepo/hippo-backrest-shared-repo/archive/db/13-1/0000000100000000/000000010000000000000005-f3692f7a98b733e2a16db695d03d85ec7e36a76a.gz
2021-06-24 16:23:28 38823 backrestrepo/hippo-backrest-shared-repo/archive/db/13-1/0000000100000000/000000010000000000000006-54001cf223598aaa70dab09817a960c77186712a.gz
2021-06-24 16:26:27 16457 backrestrepo/hippo-backrest-shared-repo/archive/db/13-1/0000000100000000/000000010000000000000007-768ad2fa8f6a87db51bf0a7e199341a93f7839d7.gz
2021-06-24 17:13:36 41 backrestrepo/hippo-backrest-shared-repo/archive/db/13-1/00000002.history
2021-06-24 17:13:55 16518 backrestrepo/hippo-backrest-shared-repo/archive/db/13-1/0000000200000000/000000020000000000000008-edfd6aae39a79700c091d0be5786fb322288f2cc.gz
2021-06-24 17:14:01 16479 backrestrepo/hippo-backrest-shared-repo/archive/db/13-1/0000000200000000/000000020000000000000009-d43396f9558ba42ed492f3085d93edf3d995891f.gz
2021-06-24 17:14:02 370 backrestrepo/hippo-backrest-shared-repo/archive/db/13-1/0000000200000000/000000020000000000000009.00000028.backup
2021-06-24 17:16:02 18147 backrestrepo/hippo-backrest-shared-repo/archive/db/13-1/0000000200000000/00000002000000000000000A-5732b47a4a1a9a7069f567a5e8379104cfe2c32e.gz
2021-06-24 17:19:02 16462 backrestrepo/hippo-backrest-shared-repo/archive/db/13-1/0000000200000000/00000002000000000000000B-298ede92cecd0d1a1dd09852660c1164f9e73b69.gz

旧 PostgreSQL アクティブクラスタの復旧

Kubernetes クラスタが障害から回復したら、ダウンしていた PostgreSQL アクティブクラスタをスタンバイクラスタとして復旧させることも可能です。
以下のコマンドを実行し、PostgreSQL クラスタをスタンバイクラスタとして起動します。以下のコマンドを実行すると、既存の PVC が削除され、再作成されます。永続ボリュームを残したい場合は、利用している StorageClass の reclaimPolicy を Retain に設定してください。

$ kubectl config use-context <EKSクラスタ名> && source $HOME/env-eks
$ pgo update cluster hippo --enable-standby
Enabling standby mode will result in the deltion of all PVCs for this cluster!
Data will only be retained if the proper retention policy is configured for any associated storage
classes and/or persistent volumes.
Please proceed with caution.
WARNING: Are you sure? (yes/no): yes
Handling connection for 8443
updated pgcluster hippo

ConfigMap からスタンバイクラスタとして設定されていることを確認できます。

$ kubectl get cm hippo-config -n pgo -o yaml | grep standby
archive-get %f \"%p\""},"use_pg_rewind":true,"use_slots":false},"standby_cluster":{"create_replica_methods":["pgbackrest_standby"],"restore_command":"source

上記設定を確認できたら、スタンバイクラスタを起動します。

$ pgo update cluster hippo --startup
WARNING: Are you sure? (yes/no): yes
Handling connection for 8443
updated pgcluster hippo

正常に起動していることを確認します。

$ pgo test hippo
cluster : hippo
Services
primary (10.100.113.239:5432): UP
replica (10.100.57.205:5432): UP
Instances
primary (hippo-7b8b78bf8f-kdhk4): UP
replica (hippo-fmju-7d7586ffcf-5kxw5): UP
replica (hippo-hyrz-789c4bb98c-l2c4w): UP

PVC の状態を確認します。「AGE」から PVC が再作成されていることがわかります。

$ kubectl get pvc -n pgo
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
NAME              STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
hippo             Bound    pvc-51b396c1-7204-45ed-9a03-5542a77dda8f   1Gi        RWO            gp2            1m40s
hippo-fmju        Bound    pvc-5223e924-abdb-45a9-bd05-cf4c4ecc4dbd   1Gi        RWO            gp2            1m40s
hippo-hyrz        Bound    pvc-fadc8764-1b7c-4004-8c69-70afe9f5142f   1Gi        RWO            gp2            1m39s
hippo-pgbr-repo   Bound    pvc-48d60253-4928-4bd3-967a-727d61c71d7d   1Gi        RWO            gp2            1m39s

マルチクラウド Kubernetes の運用

マルチクラウド Kubernetes 構成では、S3/GCS を介して PostgreSQL アクティブ/スタンバイクラスタがデータの同期を行っていますので、WAL アーカイブが行われる間隔 archive_timeout の設定値が大きすぎると、スタンバイクラスタに適用されるまで大きな遅延が発生する可能性がありますので、運用方針に合わせて設定値を調整してください。Crunchy PostgreSQL Operator のデフォルト値は archive_timeout = 60 となります。

また、すでに運用している単一 Kubernetes クラスタをマルチクラスタ構成に変更することも可能です。S3/GCS にベースバックアップおよびベースバックアップ取得後の WAL アーカイブがあれば、いつでも PostgreSQL スタンバイクラスタを追加できます。

終わりに

今回は、Crunchy PostgreSQL Operator を用いて複数のクラウドサービス、複数のリージョンにまたがって PostgreSQL を冗長化する方法、障害時の復旧、運用の注意点などについて紹介しました。マルチクラウド Kubernetes 構成により、迅速に障害や災害から復旧することが可能になります。PostgreSQL の高可用性や災害対策を検討する際に、マルチクラウド Kubernetes が1つの有効な選択肢になるでしょう。

本記事の執筆時点では、障害発生時に自動的にスタンバイクラスタを昇格させる機能がなく、手動操作によりフェイルオーバーさせる必要がありますが、開発元が積極的に機能追加を行っており、今後の機能拡張が期待できます。

Zalando Postgres Operatorとは

Zalando Postgres Operator (以下 Postgres Operator)は、コンテナの管理ツールであるKubernetes上でHA構成のPostgreSQLクラスタを容易に構築できるようにするoperatorです(operatorはKubernetesの機能を拡張するプラグインのような機構です)。本ソフトウェアはドイツのファッション系eコマース企業であるZalando SEによって開発され、自社のサービスで運用されています。本ソフトウェアはMITライセンスの元公開されています。

Operatorについて

OperatorはKubernetes上で動作するアプリケーションの各種管理を自動化するための機能です。従来システム管理者が手動で行っていた、監視、障害時の対応、バックアップ、スケーリングといった様々な操作をプログラムとして記述し、Kubernetesに組み込むことでKubernetesの動作を拡張できます。

また、PostgreSQLに新たなoperatorが必要となるもう一つの要因として、PostgreSQLクラスタはプライマリとレプリカ(スタンバイ)の役割を考慮する必要があり、ステートレスなアプリケーション(例:Webサーバ)のように簡単にレプリカ(複製)を複数台用意することができないことが挙げられます。

Postgres Operatorの機能

Postgres Operatorによりストリーミングレプリケーションを用いたプライマリ1台、レプリカ(スタンバイ)複数台のPostgreSQLクラスタを簡単に構築することができます。

Postgres Operatorの主な機能は以下になります。

• PostgreSQL HAクラスタの管理
• ストリーミングレプリケーション (同期・非同期)
• コネクションプール (PgBouncer使用)
• フェイルオーバー (pg_rewindにより高速な復旧が可能)
• ローリングアップデート
• 論理バックアップ (S3使用)
• WALアーカイブ・PITR (WAL-E、S3使用)

Zalando社による講演

PGCon 2020カンファレンスイベントにてZalando社により行われた講演の資料が公開されています。こちらもあわせて参照ください。
PostgreSQL on K8s at Zalando: Two years in production

検証環境

本記事ではKubernetesのマネージドサービスであるAmazon EKS上でZalando Postgres Operatorを動作させます。
本記事では以下の構成で解説を行います。

• Kubernetes: Amazon EKS (Kubernetesのマネージドサービス)
• ワーカーノード: t3.medium 2ノード
• アーカイブ用ストレージ: Amazon S3
• 作業環境: CentOS 8.1 (VirtualBox上のVM)

なお、EKSクラスタの作成は既に完了しているものとします。EKSの使用方法についてはこちらを参照ください。

検証内容

今回はPostgres Operatorの以下の項目について確認しました。

• Postgres Operator のデプロイ
• Web UI
• PostgreSQL クラスタの作成
• PostgreSQLの動作確認
• フェイルオーバー
• スケーリング
• ローリングアップグレード
• 論理バックアップ
• WALアーカイブ・PITR
• ログ

Postgres Operatorのデプロイ

Postgres OperatorはKubernetesとしては基本的な構成のため、導入は比較的簡単です。

Githubのリポジトリを作業環境にcloneします(もしくはtarballを展開します)。

$ git clone https://github.com/zalando/postgres-operator.git
$ cd postgres-operator/

グローバルな設定はconfigmap.yamlファイルに記述されているので、必要に応じて修正します。
ここではバックアップ先のS3の設定などのグローバルな設定を記述します。

kubectl create -fで各YAMLファイルを適用していきます。

$ kubectl create -f configmap.yaml
$ kubectl create -f operator-service-account-rbac.yaml
$ kubectl create -f postgres-operator.yaml
$ kubectl create -f api-service.yaml

オブジェクトが作成され、正常に動作していることを確認します。

$ kubectl get all
NAME                                     READY   STATUS    RESTARTS   AGE
pod/postgres-operator-85978df8cf-zqwjd   1/1     Running   0          48s

NAME                        TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
service/kubernetes          ClusterIP   10.100.0.1       <none>        443/TCP    168m
service/postgres-operator   ClusterIP   10.100.197.174   <none>        8080/TCP   22s

NAME                                READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/postgres-operator   1/1     1            1           48s

NAME                                           DESIRED   CURRENT   READY   AGE
replicaset.apps/postgres-operator-85978df8cf   1         1         1       49s

Web UI

Postgres OperatorにはWeb UIが同梱されており、ブラウザから以下の操作が可能です。

• クラスタの作成・削除
• 複製
• 設定編集
• 状態確認

Web UIのデプロイは同様にkubectlを使用して行います。

$ kubectl create -f ui/manifests/

Postgresクラスタの作成

PostgresクラスタのデプロイはYAMLファイルを作成して適用するか、前述のWeb UIで作成操作を行います。

サンプルのYAMLファイルが同梱されていますので、それを元に設定ファイルを作成します。

• minimal-postgres-manifest.yaml: 最小限の設定
• complete-postgres-manifest.yaml: 各種設定を網羅
• standby-manifest.yaml: スタンバイ専用クラスタ設定

基本的な設定を含む設定ファイルは以下になります。

apiVersion: "acid.zalan.do/v1"
kind: postgresql
metadata:
  name: sraoss-minimal-cluster           # クラスタ名の指定
spec:
  teamId: "sraoss"
  volume:
    size: 1Gi                            # ボリュームサイズの指定
  numberOfInstances: 2                   # インスタンス数(マスター+レプリカ)の指定
  users:                                 # DBユーザーの作成
    zalando:  # database owner
    - superuser
    - createdb
    foo_user: []  # role for application foo
  databases:                             # データベースの作成
    foo: zalando  # dbname: owner
  preparedDatabases:
    bar: {}
  postgresql:
    version: "12"                        # PostgreSQLバージョンの指定(9.6～12)
  enableLogicalBackup: true              # 論理バックアップの有効化
  logicalBackupSchedule: "30 00 * * * *" # cron形式のバックアップスケジュール
  enableConnectionPooler: true           # コネクションプールの有効化
  connectionPooler:
    numberOfInstances: 2

これに加え、PostgreSQLのpostgresql.conf、pg_hba.confに相当する追加の設定を行うこともできます。

...
  postgresql:
    version: "12“
    parameters:                          # postgresql.conf内のパラメータの指定
      shared_buffers: "64MB"
      max_connections: "50"
      log_statement: "all“
  patroni:
    initdb:                              # initdb時のパラメータの指定
      encoding: "UTF8"
      locale: "ja_JP.UTF-8"
      data-checksums: "true"
    pg_hba:                              # pg_hba.conf内のパラメータの指定
    - hostssl all all 0.0.0.0/0 md5
    - host    all all 0.0.0.0/0 md5

同様にkubectlで適用します。

$ kubectl create -f test-postgres-manifest.yaml

クラスタの状態を確認します。numberOfInstances: 2の場合は2つのPodが作成されます。各Podがmasterかreplicaかはspilo-roleラベルで確認できます。

$ kubectl get postgresql
NAME                     TEAM     VERSION   PODS   VOLUME   CPU-REQUEST   MEMORY-REQUEST   AGE    STATUS
sraoss-minimal-cluster   sraoss   12        2      1Gi                                     113s   Running

$ kubectl get pods -l application=spilo -L spilo-role
NAME                       READY   STATUS    RESTARTS   AGE     SPILO-ROLE
sraoss-minimal-cluster-0   1/1     Running   0          2m19s   master
sraoss-minimal-cluster-1   1/1     Running   0          95s     replica

PostgreSQLの動作確認

Kubernetesクラスタ内の他のPodからは上記のmasterおよびreplicaにアクセスすることができます。

作業環境からpsqlでアクセスしたい場合はkubectlのport-forward機能を利用します。
※ PGMASTERにはmasterのPod名が入ります。

$ export PGMASTER=$(kubectl get pods -o jsonpath={.items..metadata.name} -l application=spilo,cluster-name=sraoss-minimal-cluster,spilo-role=master)
$ kubectl port-forward $PGMASTER 6432:5432

別端末からlocalhost:6432に接続します。なお、接続時にはSSLが必須となります。
※ パスワードはPostgresクラスタ作成時に自動生成されます。

$ kubectl get secret postgres.sraoss-minimal-cluster.credentials -o 'jsonpath={.data.password}' | base64 -d
(パスワード文字列が表示される)
$ export PGSSLMODE=require
$ psql -U postgres -h localhost -p 6432
ユーザ postgres のパスワード:(上記パスワード文字列)
postgres=# create table t (t text); postgres=# insert into t values ('hoge'); postgres=# select * from t; t ------ hoge (1 行)

フェイルオーバー

masterのPodに故障が発生した場合は、自動的にフェイルオーバーしてreplicaがmasterに昇格します。これはPostgres Operatorが使用している、SpiloというPostgreSQLおよびHAを実現するためのテンプレート(Patroni)を含むDockerイメージにより実現しています。

master Podを削除した場合は元replicaがmasterに昇格し、削除したPodが再作成されてreplicaとして復帰します。データサイズが少ない状態ではあるものの、フェイルオーバーは数10秒程度ですばやく完了します。

$ kubectl delete pod sraoss-minimal-cluster-0
pod "sraoss-minimal-cluster-0" deleted

$ kubectl get pods -l application=spilo -L spilo-role
NAME                       READY   STATUS              RESTARTS   AGE   SPILO-ROLE
sraoss-minimal-cluster-0   0/1     ContainerCreating   0          6s
sraoss-minimal-cluster-1   1/1     Running             0          12m   master

$ kubectl get pods -l application=spilo -L spilo-role
NAME                       READY   STATUS    RESTARTS   AGE   SPILO-ROLE
sraoss-minimal-cluster-0   1/1     Running   0          23s   replica
sraoss-minimal-cluster-1   1/1     Running   0          12m   master

masterのプロセス故障が発生した場合は元replicaがmasterに昇格し、元masterはPodを維持したままプロセスを再起動しreplicaに降格します。以下の例ではmaster Pod内に入り、initプロセスを停止させて疑似的にプロセス故障を起こしています。

$ kubectl exec sraoss-minimal-cluster-0 -it /bin/sh
# kill 1

スケーリング

デプロイ済みのPostgresクラスタの設定を変更すると、変更内容に応じてクラスタの状態を自動的に追従させます。
クラスタのPodの数を指定するnumberOfInstancesを2から3に変更すると、Statefulsetsのレプリカ数も2から3に変更され、新しいreplica Podが起動します。

$ kubectl edit postgresql
spec:
  numberOfInstances: 2 -> 3 に修正

$ kubectl get postgresql
NAME                     TEAM     VERSION   PODS   VOLUME   CPU-REQUEST   MEMORY-REQUEST   AGE   STATUS
sraoss-minimal-cluster   sraoss   12        3      1Gi                                     53m   Running
$ kubectl get statefulsets
NAME                     READY   AGE
sraoss-minimal-cluster   3/3     14m
$ kubectl get po -l application=spilo -L spilo-role
NAME                       READY   STATUS    RESTARTS   AGE     SPILO-ROLE
sraoss-minimal-cluster-0   1/1     Running   0          50m     master
sraoss-minimal-cluster-1   1/1     Running   0          50m     replica
sraoss-minimal-cluster-2   1/1     Running   0          7m21s   replica

ローリングアップデート

PostgreSQLのマイナーバージョンアップ(Dockerイメージの更新)、およびPostgreSQLの設定変更はローリングアップデートによりサービスの停止なしに行うことができます。なお、メジャーバージョンアップはローリングアップデートでは行えないため、ベースバックアップからクラスタの複製により行う必要があります。

以下、Dockerイメージを更新した場合にローリングアップデートが行われる様子を実際に確認してみます。

Dockerイメージの更新

$ kubectl edit postgresql sraoss-test-cluster
  dockerImage: (旧Dockerイメージ) -> (新Dockerイメージ)
  postgresql:
    version: "12"

ローリングアップデート開始

$ kubectl get postgresql
NAME                  TEAM     VERSION   PODS   VOLUME   CPU-REQUEST   MEMORY-REQUEST   AGE     STATUS
sraoss-test-cluster   sraoss   12        2      1Gi                                     9m19s   Updating

$ kubectl get pods -l application=spilo -L spilo-role
NAME                    READY   STATUS        RESTARTS   AGE     SPILO-ROLE
sraoss-test-cluster-0   1/1     Running       0          9m24s   master
sraoss-test-cluster-1   1/1     Terminating   0          8m42s

$ kubectl get pods -l application=spilo -L spilo-role
NAME                    READY   STATUS              RESTARTS   AGE     SPILO-ROLE
sraoss-test-cluster-0   1/1     Running             0          9m34s   master
sraoss-test-cluster-1   0/1     ContainerCreating   0          8s

元replica Podが再作成され、masterに昇格

$ kubectl get pods -l application=spilo -L spilo-role
NAME                    READY   STATUS    RESTARTS   AGE     SPILO-ROLE
sraoss-test-cluster-0   1/1     Running   0          9m39s
sraoss-test-cluster-1   1/1     Running   0          13s     promoted

元master Podの再作成

$ kubectl get pods -l application=spilo -L spilo-role
NAME                    READY   STATUS        RESTARTS   AGE     SPILO-ROLE
sraoss-test-cluster-0   1/1     Terminating   0          9m49s
sraoss-test-cluster-1   1/1     Running       0          23s     master

$ kubectl get pods -l application=spilo -L spilo-role
NAME                    READY   STATUS              RESTARTS   AGE   SPILO-ROLE
sraoss-test-cluster-0   0/1     ContainerCreating   0          4s
sraoss-test-cluster-1   1/1     Running             0          30s   master

元master Podがreplicaとして復帰

$ kubectl get pods -l application=spilo -L spilo-role
NAME                    READY   STATUS    RESTARTS   AGE   SPILO-ROLE
sraoss-test-cluster-0   1/1     Running   0          14s   replica
sraoss-test-cluster-1   1/1     Running   0          40s   master

論理バックアップ

Postgres Operatorでは定期的にAmazon S3に論理バックアップ(pg_dumpall)を取ることができます。なお、論理バックアップからの自動リストア機能はないので、リストアはクラスタ作成後手動で行う必要があります。

前述のconfigmap.yamlでバックアップ先のS3の設定を行います。

logical_backup_s3_bucket: "zalando-backup"
logical_backup_s3_access_key_id: "xxxxxxxxxxxxxxxx"
logical_backup_s3_secret_access_key: "xxxxxxxxxxxxxxxx

Postgresクラスタの設定で論理バックアップを有効にします。スケジュールはcron表記で指定します(以下は毎日0:30に実行)。

  enableLogicalBackup: true
  logicalBackupSchedule: “30 00 * * *"

指定時刻にKubernetesのCronJobとしてバックアップが実行されます。

$ kubectl get cronjob
NAME                                    SCHEDULE      SUSPEND   ACTIVE   LAST SCHEDULE   AGE
logical-backup-sraoss-minimal-cluster   30 00 * * *   False     0        6m48s           27m

$ kubectl get job
NAME                                               COMPLETIONS   DURATION   AGE
logical-backup-sraoss-minimal-cluster-1593418800   1/1           3s         6m46s

$ kubectl describe job logical-backup-sraoss-minimal-cluster-1593418800
...
Pods Statuses:  0 Running / 1 Succeeded / 0 Failed

S3の以下の場所にバックアップファイルがアップロードされます。

s3://<bucket-name>/spilo/<cluster-name>/<UUID>/logical_backups/<job ID>.sql.gz

WALアーカイブ・PITR

前述のconfigmap.yamlでバックアップ先のS3の設定を行います。なお、EKSクラスタからS3 bucketへのアクセスが許可されている必要があります。

wal_s3_bucket: "zalando-wal-backup"

S3の以下の場所にWALがアーカイブされます。

s3://<bucket-name>/spilo/<cluster-name>/<UUID>/wal/basebackups_00x/
s3://<bucket-name>/spilo/<cluster-name>/<UUID>/wal/wal_00x/

S3のバックアップからクラスタを複製(clone)することでPITRが可能です。PITRの復元位置を指定することもできます。

spec:
  clone:
    uid: "efd12e58-5786-11e8-b5a7-06148230260c"
    cluster: “sraoss-test-cluster"
    timestamp: "2017-12-19T12:40:33+01:00"

ログ

Postges Operator自体はログ管理に関する機能を持ちません。Podのsidecarコンテナをユーザが追加することは可能なので、ログ収集のための補助コンテナを導入し、fluentdと連携するなどの作り込みは必要となります。また、Kubernetesクラスタのログを集約するKubernetes Log WatcherというツールがZalando社によって公開されています。

クラスタの各Podのログはkubectl logsコマンドにより確認できます。

$ kubectl logs sraoss-minimal-cluster-0

また、Pod内のPostgreSQLログは以下のように格納されています。

/home/postgres/pgdata/pgroot/pg_log/
-rw-r--r-- 1 postgres postgres      0 Jun 29 06:12 postgresql-0.csv
-rw-r--r-- 1 postgres postgres 277783 Jun 29 06:58 postgresql-1.csv
-rw-r--r-- 1 postgres postgres    205 Jun 29 06:12 postgresql-1.log
-rw-r--r-- 1 postgres postgres      0 Jun 29 06:12 postgresql-2.csv
-rw-r--r-- 1 postgres postgres      0 Jun 29 06:12 postgresql-3.csv
-rw-r--r-- 1 postgres postgres      0 Jun 29 06:12 postgresql-4.csv
-rw-r--r-- 1 postgres postgres      0 Jun 29 06:12 postgresql-5.csv
-rw-r--r-- 1 postgres postgres      0 Jun 29 06:12 postgresql-6.csv
-rw-r--r-- 1 postgres postgres      0 Jun 29 06:12 postgresql-7.csv

おわりに

手動でPostgreSQL HAクラスタを構築するとなるとかなりの手間がかかります。また、Kubernetes上にそれを構築しようとするのはかなり困難です。Zalando Postgres Operatorを用いることで、Kubernetes上のPostgreSQL HAクラスタの構築が非常に容易になります。実際に開発元のサービスで運用されている実績があり、機能的にまだ不十分なところもあるものの、フェイルオーバーなどの重要な機能に関してはしっかりと作り込まれていると感じました。今後の発展が楽しみなソフトウェアといえます。

今回の記事では、前回の記事に続いてCrunchy Postgres Operatorについて解説します。

本記事の説明は Crunchy Postgres Operator  4.7 を対象にします。2021 年にリリースされたバージョン 5 (v5) についてはCrunchy Postgres Operator v5 の紹介を参照してください。

Crunchy Postgres Operatorとは

Crunchy Postgres Operatorは、コンテナの管理ツールであるKubernetes上でPostgreSQL HAクラスタを容易に構築ためのOperatorの1つです(OperatorはKubernetesの機能を拡張するプラグインのような機構です)。Crunchy Postgres OperatorはPostgreSQLの関連サービスを提供しているアメリカの会社であるCrunchy Dataによって開発され、Apache License 2.0で公開されています。PostgreSQL 9.5以降に対応しています。

全体構成図

Crunchy Postgres Operatorの機能

Crunchy Postgres Operatorの主な機能は以下の通りです。

• PostgreSQL HAクラスタのデプロイ・管理
• CLI (pgo)
• ストリーミングレプリケーション (同期・非同期)
• フェイルオーバー
• バックアップ (S3対応)
• WALアーカイブ (S3対応)
• リストア・PITR
• 自動アップグレード
• コネクションプール (PgBouncer使用)
• PostgreSQLのログ解析
• 監視

検証環境

本記事ではKubernetesのマネージドサービスであるAmazon EKS上でCrunchy Postgres Operatorの動作確認を行いました。
環境の構成およびバージョン情報は以下の通りです。

• Crunchy Postgres Operator  4.7.0
• Kubernetes: Amazon EKS (Kubernetesのマネージドサービス)
• ワーカーノード: t3.medium 2ノード
• アーカイブ用ストレージ: Amazon S3
• 作業環境: CentOS 7.6 (AWS上のEC2)

なお、EKSクラスタの作成は既に完了しているものとします。EKSの使用方法についてはこちらを参照ください。

検証内容

本記事はCrunchy Postgres Operator 4.7.0を用いて以下の項目について動作確認を行いました。

• Crunchy Postgres Operatorのデプロイ
• pgoクライアントコマンドのインストール
• PostgreSQLクラスタの作成
• psql による接続確認
• PostgreSQLの設定
• フェイルオーバー
• スケーリング
• バックアップ
• リストア・PITR
• アップグレード

Crunchy Postgres Operatorのデプロイ

以下の方法でPostgreSQL Operatorをデプロイできます。
– Ansible
– Bashスクリプト
– pgo-deploy Job (※推奨、v4.3.0 ～)

v4.3.0から追加された「pgo-deploy Job」を用いたデプロイ方法は他の方法より簡単にPostgreSQL Operatorをインストール/アップデート/アンインストールできるため、こちらの方法の利用が推奨されています。

以下では「pgo-deploy Job」を用いたデプロイ方法を紹介します。

1. まず、デプロイの設定を記述したマニフェストを取得します。

$ curl -LO https://raw.githubusercontent.com/CrunchyData/postgres-operator/v4.7.0/installers/kubectl/postgres-operator.yml

2. 環境に合わせて、マニフェストを編集します。

最低限Operatorが利用するストレージの設定が必要になります。指定しない場合は、Amazon EKSデフォルトのストレージクラスを利用します。

デフォルトのストレージクラスが定義されていることを確認します。

$ kubectl get sc
NAME           PROVISIONER            AGE
gp2 (default)  kubernetes.io/aws-ebs  5h49m

3. デフォルトではOperatorがpgoというNamespaceにインストールされるため、pgoというNamespaceを作成し、マニフェストを適用します。

$ kubectl create namespace pgo
$ kubectl apply -f postgres-operator.yml

4. インストール後、PostgreSQL Operatorが正常にインストールされていることを確認します。

$ kubectl get pod -n pgo
NAME                                 READY   STATUS      RESTARTS   AGE
pgo-deploy-bq9fs                     0/1     Completed   0          4m50s
postgres-operator-5d5ff486c7-jtdc6   4/4     Running     1          3m52s

$ kubectl get svc -n pgo
NAME                TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                      AGE
postgres-operator   ClusterIP   10.100.180.218   <none>        8443/TCP,4171/TCP,4150/TCP   19m

5. 終了した 「pgo-deploy」Jobを削除するには以下のコマンドを実行します。

$ kubectl delete -f postgres-operator.yml

pgoクライアントコマンドのインストール

1. client-setup.shスクリプトをダウンロード・実行し、pgoクライアントをインストールします。

$ curl -LO https://raw.githubusercontent.com/CrunchyData/postgres-operator/v4.7.0/installers/kubectl/client-setup.sh
$ chmod +x client-setup.sh
$ ./client-setup.sh

2. 以下の環境変数を設定します。

$ cat >> ~/.bashrc <<EOF 
export PATH="$HOME/.pgo/pgo:$PATH"
export PGOUSER="$HOME/.pgo/pgo/pgouser"
export PGO_CA_CERT="$HOME/.pgo/pgo/client.crt"
export PGO_CLIENT_CERT="$HOME/.pgo/pgo/client.crt"
export PGO_CLIENT_KEY="$HOME/.pgo/pgo/client.key"
export PGO_NAMESPACE=pgo
EOF
$ source ~/.bashrc

3. インストール後、pgoクライアントが正常にインストールされていることを確認します。

postgres-operatorをローカルの8443へポートフォワードを行います。

$ kubectl -n pgo port-forward svc/postgres-operator 8443:8443 &

APIサーバの環境変数をローカルの8443ポートに設定します。

$ cat >> ~/.bashrc <<EOF 
export PGO_APISERVER_URL="https://127.0.0.1:8443/"
EOF

clientとAPIサーバのバージョン番号が表示されれば、正しくインストールできています。

$ pgo version
pgo client version 4.7.0
Handling connection for 8443
pgo-apiserver version 4.7.0

PostgreSQLクラスタの作成

pgo create clusterコマンドを用いて PostgreSQLクラスタを作成します。

$ pgo create cluster hippo --replica-count=1 --sync-replication

上記コマンドで以下のような構成のクラスタが作成されます。

• primary 1台、replica 1台
• 同期レプリケーション
• 自動フェイルオーバー (デフォルト)
• バックアップ (デフォルト)
• WAL アーカイブ (デフォルト)
• ローカルストレージにバックアップと WALアーカイブを保存 (デフォルト)

postgresスーパーユーザのパスワードを設定したい場合は--password-superuserオプションで設定可能です。指定しない場合は自動生成されます。また、バックアップの保存先やサイドカー機能などのオプションの詳細については、後述する「バックアップ」や「サイドカー機能」を参照ください。

クラスタの状態を確認します。正常に起動できれば、primary、replicaそれぞれのPod (Instance)とServiceがUP状態になっています。

$ pgo test hippo
Handling connection for 8443

cluster : hippo
        Services
                primary (10.100.43.244:5432): UP
                replica (10.100.157.106:5432): UP
        Instances
                primary (hippo-646dfd49f5-lbc8l): UP
                replica (hippo-gfps-65f776cc6-mhdcw): UP

psql による接続確認

Kubernetesクラスタ内のノードからは上記primary及びreplicaのServiceに接続することができます。
作業環境からpsqlでprimary及びreplicaのServiceに接続したい場合はkubectlのport-forward機能を利用します。
ここではprimary Serviceの5432ポートをローカルの5432へポートフォワードを行います。
※ PGPRIMARYにはprimaryのService名が入ります。

$ export PGPRIMARY=$(kubectl get svc -o jsonpath={.items..metadata.name} -l name=hippo,pg-cluster=hippo,vendor=crunchydata -n pgo)
$ kubectl -n pgo port-forward svc/$PGPRIMARY 5432:5432 &

psqlで接続します。
接続時にパスワード入力プロンプトが表示されるため、クラスタ作成時に指定したパスワードを入力します。

$ psql -h localhost -U postgres
ユーザ postgres のパスワード:
postgres=# select application_name, state, sync_state from pg_stat_replication;
      application_name      |   state   | sync_state 
----------------------------+-----------+------------
 hippo-gfps-65f776cc6-mhdcw | streaming | sync
(1 行)

クラスタ作成時にパスワードを設定していない場合はランダムに生成されています。生成されたパスワードはkubectl get secretコマンドで確認できます。

$ kubectl get secret hippo-postgres-secret -n pgo -o 'jsonpath={.data.password}' | base64 -d

PostgreSQLの設定

PostgreSQLのpostgresql.confやpg_hba.conf、pg_ident.conf などの設定はConfigMapで設定できます。
事前に作成したConfigMapはクラスタ作成時に--custom-configオプションで適用可能です。
指定しない場合は、クラスタ作成時に<clusterName>-pgha-configというConfigMapが作成されます。

ConfigMap <clusterName>-pgha-configは以下で構成されます。

• Distributed Configuration Store (DCS) : クラスタ全体の設定
• local Database : PostgreSQLサーバごとの設定

kubectl describe configmapコマンドを用いてConfigMapの設定を確認できます。

$ kubectl describe configmap hippo-pgha-config -n pgo

設定を変更するには kubectl edit configmap コマンドを利用します。
例えば、log_statementをnoneからallに変更するには以下のコマンドを実行します。
変更するとOperatorによって変更が検出され、自動的にPostgreSQLに反映されます。

$ kubectl edit configmap hippo-pgha-config -n pgo
data:
  hippo-dcs-config: |
    postgresql:
      parameters:
      ...
        log_statement: none -> all に変更

ただし、PostgreSQLの再起動が必要になるパラメータもあり、再起動が必要かどうかはpgo restart hippo --queryコマンドで確認できます。
例えば、max_wal_sendersの設定値を変更した場合、PostgreSQLの再起動が必要になります。

$ kubectl edit configmap hippo-pgha-config -n pgo
data:
  hippo-dcs-config: |
    postgresql:
      parameters:
      ...
        max_wal_senders: 6 -> 8 に変更

設定変更後pgo restart hippo --queryを実行し、PENDING RESTARTカラムがtrueになっていれば、再起動が必要なことを意味しています。

$ pgo restart hippo --query
Handling connection for 8443
Cluster: hippo
INSTANCE                ROLE            STATUS          NODE                                                       REPLICATION LAG         PENDING RESTART
hippo                   primary         running         ip-192-168-84-180.us-west-2.compute.internal               0 MB                    true
hippo-gfps              replica         running         ip-192-168-30-254.us-west-2.compute.internal               0 MB                    true

上記結果より、hippo及びhippo-gfpsの再起動が必要なので、それぞれのPod (Instance)名をpgo restartコマンドの--targetオプションに指定し、再起動します。

$ pgo restart hippo --target hippo 
$ pgo restart hippo --target hippo-gfps

フェイルオーバー

primaryのPodに故障が発生した場合は、自動的にフェイルオーバーしてreplicaがprimaryに昇格します。これはPostgreSQL HAのテンプレートであるPatroniを利用して実現しています。

Podを削除した場合

primaryのPodを削除した場合、replicaがprimary に昇格し、新たなreplicaが生成され、復旧します。
replicaの生成はpgBackRestのdelta restoreの機能で、迅速に復旧することができます。

$ pgo test hippo
Handling connection for 8443
cluster : hippo
        Services
                primary (10.100.43.244:5432): UP
                replica (10.100.157.106:5432): UP
        Instances
                primary (hippo-646dfd49f5-lbc8l): UP
                replica (hippo-gfps-65f776cc6-mhdcw): UP

$ kubectl delete pods hippo-646dfd49f5-lbc8l -n pgo
pod "hippo-646dfd49f5-lbc8l" deleted

$ pgo test hippo
Handling connection for 8443
cluster : hippo
        Services
                primary (10.100.43.244:5432): UP
                replica (10.100.157.106:5432): UP
        Instances
                replica (hippo-646dfd49f5-x7m67): UP
                primary (hippo-gfps-65f776cc6-mhdcw): UP

プロセス障害の場合

primaryの Podのプロセス障害が発生した場合は、replicaがprimaryに昇格し、
旧primaryはPodを維持したままreplicaとして再起動します。
以下の例ではPod内に入り、initプロセスを停止させて疑似的にプロセス障害を起こしています。

$ kubectl exec hippo-gfps-65f776cc6-mhdcw -it -n pgo -- /bin/sh
$ kill 1

$ pgo test hippo
Handling connection for 8443
cluster : hippo
        Services
                primary (10.100.43.244:5432): UP
                replica (10.100.157.106:5432): UP
        Instances
                primary (hippo-646dfd49f5-x7m67): UP
                replica (hippo-gfps-65f776cc6-mhdcw): UP

スケーリング

PostgreSQLのreplicaのスケーリングンにより、データベースの負荷分散や耐障害性の向上を実現できます。
pgoクライアントコマンドを実行することで、簡単にスケールアップ/スケールダウンが可能です。

スケールアップ

replicaを1台から2台に増やします。

$ pgo scale hippo --replica-count=1
$ pgo test hippo
Handling connection for 8443
cluster : hippo
        Services
                primary (10.100.43.244:5432): UP
                replica (10.100.157.106:5432): UP
        Instances
                primary (hippo-646dfd49f5-x7m67): UP
                replica (hippo-gfps-65f776cc6-mhdcw): UP
                replica (hippo-zdlq-69dcc59d9-8hn6f): UP

スケールダウン

スケールダウン可能なreplicaを確認します。

$ pgo scaledown hippo --query
Handling connection for 8443
Cluster: hippo
REPLICA   STATUS   NODE                                          REPLICATION LAG  PENDING RESTART
hippo-gfps running ip-192-168-30-254.us-west-2.compute.internal  0 MB             false
hippo-zdlq running ip-192-168-84-180.us-west-2.compute.internal  0 MB             false

replica「hippo-zdlq」を削除します。

$ pgo scaledown hippo --target=hippo-zdlq

$ pgo test hippo
Handling connection for 8443
cluster : hippo
        Services
                primary (10.100.43.244:5432): UP
                replica (10.100.157.106:5432): UP
        Instances
                primary (hippo-646dfd49f5-x7m67): UP
                replica (hippo-gfps-65f776cc6-mhdcw): UP

バックアップ

Crunchy Postgres Operatorのバックアップ/リストアは内部的にpgBackRestのバックアップ/リストアユーティリティを利用しています。
定期的にフルバックアップまたは差分バックアップを取得することができます。
取得したバックアップやWALアーカイブはローカルストレージもしくはAmazon S3に保存することができ、保存先の設定はPostgreSQLクラスタ作成時に設定可能です。

バックアップに関するクラスタ作成時のオプションは以下のようなものがあります。

$ pgo create cluster hippo \
--replica-count=1 \
--pgbackrest-storage-type="local,s3" \
--pgbackrest-s3-bucket="crunchy-postgres-backup" \
--pgbackrest-s3-region="us-west-2" \
--pgbackrest-s3-endpoint="s3.us-west-2.amazonaws.com" \
--pgbackrest-s3-key="xxxxxxxxxx" \
--pgbackrest-s3-key-secret="xxxxxxxxxxxxxxxxxxxx" \
--pgbackrest-s3-verify-tls=false

それぞれのオプションの意味は以下の通りです。

• --pgbackrest-storage-type: バックアップとWALアーカイブの保存先。”local,s3″を指定した場合は、ローカルストレージとAmazon S3に保存します。デフォルトではローカルストレージに保存します。
• --pgbackrest-s3-bucket: Amazon S3のBucket名を指定します。
• --pgbackrest-s3-region: Amazon S3のリージョンを指定します。
• --pgbackrest-s3-endpoint: Amazon S3のエンドポイントを指定します。
• --pgbackrest-s3-key: Amazon S3 キーを指定します。
• --pgbackrest-s3-key-secret: Amazon S3 シークレットキーを指定します。
• --pgbackrest-s3-verify-tls: pgBackRestがAmazon S3に接続するときにTLS証明書を検証するかどうかを設定します。

定期バックアップを設定するにはpgo create scheduleコマンドを使います。
バックアップのスケジュールはcron表記で指定します。

(毎日午前1時にフルバックアップを実行)
$ pgo create schedule hippo --schedule="0 1 * * *" \
--schedule-type=pgbackrest --pgbackrest-backup-type=full

差分バックアップを行いたい場合は、--pgbackrest-backup-type=incrを指定します。

(1時間ごとに差分バックアップを実行)
$ pgo create schedule hippo --schedule="0 */1 * * *" \
--schedule-type=pgbackrest --pgbackrest-backup-type=incr

リストア

新しいPostgreSQLクラスタの作成

バックアップから新しいPostgreSQLクラスタを作成するにはpgo create clusterを利用します。
例えば、開発やテスト目的で本番環境と同じ環境を用意するときに、--restore-fromオプションを使用して本番環境の名前を指定するだけです。

pgo create cluster hippo2 --restore-from=hippo

デフォルトでは最新のデータに復元しますが、--restore-optsオプションを使用して、特定の時点まで復元可能です。

pgo create cluster hippo2 \
--restore-from=hippo \
--restore-opts="--type=time --target='2020-07-27 14:50:00.000000+00'"

また、Amazon S3に保存されているバックアップからPostgreSQLクラスタを作成する場合は、
--repo-type=s3を指定します。

pgo create cluster hippo2 --restore-from=hippo --restore-opts="--repo-type=s3"

起動中のPostgreSQLクラスタのPITR

起動中のPostgreSQLクラスタを以前の時点に復元するにはpgo restoreコマンドを使います。
pgo restoreコマンドは既存のデータディレクトリでリカバリを実行しますので、
クラスタが一旦停止され、作り直されます。

$ pgo restore hippo --pitr-target="2020-07-27 14:50:00.000000+00" \
--backup-opts="--type=time"

ログ

Crunchy PostgeSQL Operator自体にはログを収集する機能がありません。Podのsidecarコンテナとしてfluentdを導入し外部に転送するなどの作り込みは必要となります。

以下の方法でPodのログやPostgreSQLのログを確認可能です。
クラスタの各Podのログはkubectl logsコマンドにより確認できます。

kubectl logs hippo-646dfd49f5-x7m67 -c database -n pgo

また、Pod内のPostgreSQLログは以下のように格納されています。

kubectl exec -i -n pgo -t hippo-646dfd49f5-x7m67 -- ls -alt /pgdata/hippo/pg_log
-rw-------  1 postgres postgres  588 Jul  1 12:00 postgresql-Wed.log

アップグレード

新しいバージョンにアップグレードするには、以下2段階のアップグレードを実行する必要があります。

1. Crunchy Postgres Operator自身のアップグレード
2. PostgreSQLクラスタのアップグレード

アップグレードに伴う注意点は以下の通りです。

• Operatorのアップグレード後、PostgreSQLクラスタのアップグレード完了まで既存のPostgreSQLクラスタの操作はできない。
• PostgreSQLクラスタアップグレード時、replica及びreplicaのPVCが削除されるが、primaryとbackrest-repoのPVCがそのまま残り、それぞれの新しいPodに引き継がれる。
• PostgreSQLクラスタのアップグレード中、primary Podが停止し、再作成されるので、PostgreSQLクラスタのダウンタイムが発生する。

Crunchy Postgres Operatorのアップグレード

前述の通り、pgo-deploy Jobにより、PostgreSQL Operatorをアップデートできるので、
新しいバージョンのpostgres-operator.ymlにてDEPLOY_ACTIONをupdateに変更し、適用します。

$ vi postgres-operator.yml
...
- name: DEPLOY_ACTION
value: "install" -> "update" に変更

$ kubectl apply -f postgres-operator.yml

PostgreSQLクラスタのアップグレード

PostgreSQLクラスタのアップグレードにはpgo upgradeコマンドを使います。

$ pgo upgrade <クラスタ名>

便利な機能

PostgreSQLクラスタ作成時に、オプションを指定することで、コネクションプールやpgbadgerによるPostgreSQLログ解析、Prometheus監視用のメトリクスの出力といった機能が利用できます。

例えば、pgo create clusterでクラスタ作成時に--pgbouncer --metrics --pgbadgerを指定することで、これら機能が有効になります。

$ pgo create cluster hippo \ 
--replica-count=1 \ 
--pgbouncer \ 
--metrics \ 
--pgbadger

それぞれのオプションの意味は以下の通りです。

• --pgbouncer: pgbouncer Pod起動し、コネクションプール機能を有効にする
• --metrics: Prometheus Exporterコンテナを各それぞれのPostgreSQLのPodに追加し、データベースサーバのパフォーマンスや使用状況、PostgreSQLクラスタの状態などのPrometheusメトリクスを出力する
• --pgbadger: pgbadgerコンテナをそれぞれのPostgreSQLのPodに追加し、PostgreSQLのログを解析する

おわりに

今回はPostgreSQL Operatorの1つCrunchy Postgres Operatorについて紹介しました。Crunchy Postgres Operatorを用いることで、Kubernetes上のPostgreSQL HAクラスタの構築・管理が非常に容易になります。開発元が新機能の追加や機能改善に力をいれており、PostgreSQLの最新バージョンに対応するスピードも速く、Kubernets上でPostgreSQLクラスタの構築を検討する際に、1つの有力な選択肢だと言えるでしょう。