CloudNativePG を使用して PostgreSQL を GKE にデプロイする

このガイドでは、CloudNativePG オペレーターを使用して PostgreSQL クラスタを Google Kubernetes Engine（GKE）にデプロイする方法について説明します。

PostgreSQL は、数十年にわたって積極的に開発され、安定したクライアント パフォーマンスを実現するオープンソースのオブジェクト リレーショナル データベースです。レプリケーション、ポイントインタイム リカバリ、セキュリティ機能、拡張性など、幅広い機能を備えています。PostgreSQL は主要なオペレーティング システムと互換性があり、ACID（アトミック性、整合性、独立性、耐久性）標準に完全に準拠しています。

このガイドは、GKE に Postgres クラスタをデプロイすることに関心があるプラットフォーム管理者、クラウド アーキテクト、運用担当者を対象としています。Cloud SQL を使用する代わりに GKE で Postgres を実行すると、経験豊富なデータベース管理者がより柔軟に構成を管理できるようになります。

利点

CloudNativePG は、Apache 2 ライセンスの下で EDB が開発したオープンソースのオペレーターです。これにより、PostgreSQL のデプロイメントに次の機能が追加されます。

  • 宣言型および Kubernetes ネイティブの方法による PostgreSQL クラスタの管理と構成
  • Volume Snapshots または Cloud Storage を使用したバックアップ管理
  • 転送中の暗号化された TLS 接続、独自の認証局を使用する機能、TLS 証明書の自動発行とローテーションのための Certificate Manager とのインテグレーション
  • PostgreSQL のマイナー リリースに対するローリング アップデート
  • Kubernetes API サーバーを使用して、追加のツールなしで PostgreSQL クラスタのステータス維持と、高可用性のためのフェイルオーバーを実現
  • SQL で記述されたユーザー定義指標による組み込みの Prometheus エクスポータ構成

環境の設定

環境の設定手順は次のとおりです。

  1. 環境変数を設定します。

    export PROJECT_ID=PROJECT_ID
export KUBERNETES_CLUSTER_PREFIX=postgres
export REGION=us-central1

    PROJECT_ID は実際の Google Cloud プロジェクト ID に置き換えます。

  2. GitHub リポジトリのクローンを作成します。

    git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples

  3. 作業ディレクトリを変更します。

    cd kubernetes-engine-samples/databases/postgresql-cloudnativepg

クラスタ インフラストラクチャを作成する

このセクションでは、Terraform スクリプトを実行して、限定公開の高可用性リージョン GKE クラスタを作成します。

オペレーターは、Standard または Autopilot クラスタを使用してインストールできます。

Standard

次の図は、3 つの異なるゾーンにデプロイされた限定公開のリージョン GKE Standard クラスタを示しています。

このインフラストラクチャをデプロイするには、次のコマンドを実行します。

export GOOGLE_OAUTH_ACCESS_TOKEN=$(gcloud auth print-access-token)
terraform -chdir=terraform/gke-standard init
terraform -chdir=terraform/gke-standard apply \
-var project_id=${PROJECT_ID}   \
-var region=${REGION}  \
-var cluster_prefix=${KUBERNETES_CLUSTER_PREFIX}

プロンプトが表示されたら、「yes」と入力します。このコマンドが完了し、クラスタが準備完了ステータスになるまでに数分かかることがあります。

Terraform が次のリソースを作成します。

  • Kubernetes ノード用の VPC ネットワークとプライベート サブネット
  • NAT 経由でインターネットにアクセスするためのルーター
  • us-central1 リージョンの限定公開 GKE クラスタ
  • 自動スケーリングが有効になっているノードプール（ゾーンあたり 1～2 ノード、最小ゾーンあたり 1 ノード）

出力は次のようになります。

...
Apply complete! Resources: 14 added, 0 changed, 0 destroyed.
...

Autopilot

次の図は、限定公開のリージョン GKE Autopilot クラスタを示しています。

このインフラストラクチャをデプロイするには、次のコマンドを実行します。

export GOOGLE_OAUTH_ACCESS_TOKEN=$(gcloud auth print-access-token)
terraform -chdir=terraform/gke-autopilot init
terraform -chdir=terraform/gke-autopilot apply \
-var project_id=${PROJECT_ID} \
-var region=${REGION} \
-var cluster_prefix=${KUBERNETES_CLUSTER_PREFIX}

プロンプトが表示されたら、「yes」と入力します。このコマンドが完了し、クラスタが準備完了ステータスになるまでに数分かかることがあります。

Terraform が次のリソースを作成します。

  • Kubernetes ノード用の VPC ネットワークとプライベート サブネット
  • NAT 経由でインターネットにアクセスするためのルーター
  • us-central1 リージョンの限定公開 GKE クラスタ
  • ロギングとモニタリングの権限を持つ ServiceAccount
  • Google Cloud Managed Service for Prometheus（クラスタ モニタリング用）

出力は次のようになります。

...
Apply complete! Resources: 12 added, 0 changed, 0 destroyed.
...

クラスタに接続する

クラスタと通信を行うように kubectl を構成します。

gcloud container clusters get-credentials ${KUBERNETES_CLUSTER_PREFIX}-cluster --location ${REGION}

CloudNativePG オペレーターをデプロイする

Helm チャートを使用して、CloudNativePG を Kubernetes クラスタにデプロイします。

  1. CloudNativePG オペレーターの Helm チャート リポジトリを追加します。

    helm repo add cnpg https://cloudnative-pg.github.io/charts

  2. Helm コマンドライン ツールを使用して CloudNativePG オペレーターをデプロイします。

    helm upgrade --install cnpg \
    --namespace cnpg-system \
    --create-namespace \
    cnpg/cloudnative-pg

    出力は次のようになります。

    Release "cnpg" does not exist. Installing it now.
NAME: cnpg
LAST DEPLOYED: Fri Oct 13 13:52:36 2023
NAMESPACE: cnpg-system
STATUS: deployed
REVISION: 1
TEST SUITE: None
...

Postgres をデプロイする

次のマニフェストは、CloudNativePG オペレーターのカスタム リソースで定義された PostgreSQL クラスタを記述しています。

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: gke-pg-cluster
spec:
  description: "Standard GKE PostgreSQL cluster"
  imageName: ghcr.io/cloudnative-pg/postgresql:16.2
  enableSuperuserAccess: true
  instances: 3
  startDelay: 300
  primaryUpdateStrategy: unsupervised
  postgresql:
    pg_hba:
      - host all all 10.48.0.0/20 md5
  bootstrap:
    initdb:
      database: app
  storage:
    storageClass: premium-rwo
    size: 2Gi
  resources:
    requests:
      memory: "1Gi"
      cpu: "1000m"
    limits:
      memory: "1Gi"
      cpu: "1000m"
  affinity:
    enablePodAntiAffinity: true
    tolerations:
    - key: cnpg.io/cluster
      effect: NoSchedule
      value: gke-pg-cluster
      operator: Equal
    additionalPodAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: app.component
              operator: In
              values:
              - "pg-cluster"
          topologyKey: topology.kubernetes.io/zone
  monitoring:
    enablePodMonitor: true

このマニフェストには次のフィールドがあります。

  • spec.instances: クラスタ Pod の数
  • spec.primaryUpdateStrategy: ローリング アップデート戦略。
    • Unsupervised: レプリカノードの後にプライマリ クラスタノードを自律的に更新します。
    • Supervised: プライマリ クラスタノードの手動切り替えが必要です
  • spec.postgresql: postgres.conf ファイル パラメータのオーバーライド（pg-hba ルール、LDAP、満たすべき同期レプリカの要件など）。
  • spec.storage: ストレージ関連の設定（ストレージ クラス、Volume のサイズ、write-ahead log の設定など）。
  • spec.bootstrap: クラスタで作成された初期データベースのパラメータ、ユーザー認証情報、データベースの復元オプション
  • spec.resources: クラスタ Pod のリクエストと上限
  • spec.affinity: クラスタ ワークロードのアフィニティと反アフィニティ ルール

基本的な Postgres クラスタを作成する

  1. Namespace を作成します。

    kubectl create ns pg-ns

  2. カスタム リソースを使用して PostgreSQL クラスタを作成します。

    kubectl apply -n pg-ns -f manifests/01-basic-cluster/postgreSQL_cluster.yaml

    このコマンドの完了までに数分かかることがあります。

  3. クラスタのステータスを確認します。

    kubectl get cluster -n pg-ns --watch

    出力に Cluster in healthy state のステータスが表示されるまで待ってから、次のステップに進みます。

    NAME             AGE     INSTANCES   READY   STATUS                     PRIMARY
gke-pg-cluster   2m53s   3           3       Cluster in healthy state   gke-pg-cluster-1

リソースを検査する

GKE がクラスタのリソースを作成したことを確認します。

kubectl get cluster,pod,svc,pvc,pdb,secret,cm -n pg-ns

出力は次のようになります。

NAME                                        AGE   INSTANCES   READY   STATUS                     PRIMARY
cluster.postgresql.cnpg.io/gke-pg-cluster   32m   3           3       Cluster in healthy state   gke-pg-cluster-1

NAME                   READY   STATUS    RESTARTS   AGE
pod/gke-pg-cluster-1   1/1     Running   0          31m
pod/gke-pg-cluster-2   1/1     Running   0          30m
pod/gke-pg-cluster-3   1/1     Running   0          29m

NAME                        TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)    AGE
service/gke-pg-cluster-r    ClusterIP   10.52.11.24   <none>        5432/TCP   32m
service/gke-pg-cluster-ro   ClusterIP   10.52.9.233   <none>        5432/TCP   32m
service/gke-pg-cluster-rw   ClusterIP   10.52.1.135   <none>        5432/TCP   32m

NAME                                     STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
persistentvolumeclaim/gke-pg-cluster-1   Bound    pvc-bbdd1cdd-bdd9-4e7c-8f8c-1a14a87e5329   2Gi        RWO            standard       32m
persistentvolumeclaim/gke-pg-cluster-2   Bound    pvc-e7a8b4df-6a3e-43ce-beb0-b54ec1d24011   2Gi        RWO            standard       31m
persistentvolumeclaim/gke-pg-cluster-3   Bound    pvc-dac7f931-6ac5-425f-ac61-0cfc55aae72f   2Gi        RWO            standard       30m

NAME                                                MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
poddisruptionbudget.policy/gke-pg-cluster           1               N/A               1                     32m
poddisruptionbudget.policy/gke-pg-cluster-primary   1               N/A               0                     32m

NAME                                TYPE                       DATA   AGE
secret/gke-pg-cluster-app           kubernetes.io/basic-auth   3      32m
secret/gke-pg-cluster-ca            Opaque                     2      32m
secret/gke-pg-cluster-replication   kubernetes.io/tls          2      32m
secret/gke-pg-cluster-server        kubernetes.io/tls          2      32m
secret/gke-pg-cluster-superuser     kubernetes.io/basic-auth   3      32m

NAME                                DATA   AGE
configmap/cnpg-default-monitoring   1      32m
configmap/kube-root-ca.crt          1      135m

オペレーターが次のリソースを作成します。

  • オペレーターが制御する PostgreSQL クラスタを表すクラスタ カスタム リソース
  • 対応する永続ボリュームがある PersistentVolumeClaim リソース
  • データベースへのアクセスや Postgres ノード間のレプリケーションのためのユーザー認証情報を含むシークレット。
  • クラスタに接続する <name>-rw、<name>-ro、<name>-r の 3 つのデータベース エンドポイント サービス。詳細については、PostgreSQL のアーキテクチャをご覧ください。

Postgres に対する認証を行う

PostgreSQL データベースに接続し、オペレーターによって作成されたさまざまなサービス エンドポイントを介してアクセスを確認できます。これを行うには、PostgreSQL クライアントがあり、同期アプリケーション ユーザー認証情報が環境変数としてマウントされた追加の Pod を使用します。

  1. クライアント Pod を実行して Postgres クラスタとやり取りします。

    kubectl apply -n pg-ns -f manifests/02-auth/pg-client.yaml

  2. pg-client Pod で exec コマンドを実行し、gke-pg-cluster-rw Service にログインします。

    kubectl wait --for=condition=Ready -n pg-ns pod/pg-client --timeout=300s
kubectl exec -n pg-ns -i -t pg-client -- /bin/sh

  3. gke-pg-cluster-rw Service を使用してデータベースにログインし、読み取り / 書き込み権限で接続を確立します。

    psql postgresql://$CLIENTUSERNAME:$CLIENTPASSWORD@gke-pg-cluster-rw.pg-ns/app

    ターミナルはデータベース名で始まります。

    app=>

  4. テーブルを作成します。

    CREATE TABLE travel_agency_clients (
client VARCHAR ( 50 ) UNIQUE NOT NULL,
address VARCHAR ( 50 ) UNIQUE NOT NULL,
phone VARCHAR ( 50 ) UNIQUE NOT NULL);

  5. テーブルにデータを挿入します。

    INSERT INTO travel_agency_clients(client, address, phone)
VALUES ('Tom', 'Warsaw', '+55555')
RETURNING *;

  6. 作成したデータを表示します。

    SELECT * FROM travel_agency_clients ;

    出力は次のようになります。

    client | address |  phone
--------+---------+---------
Tom    | Warsaw  | +55555
(1 row)

  7. 現在のデータベース セッションからログアウトします。

    exit

  8. gke-pg-cluster-ro Service を使用してデータベースにログインし、読み取り専用アクセス権を確認します。この Service ではデータのクエリは許可されますが、書き込みオペレーションは制限されます。

    psql postgresql://$CLIENTUSERNAME:$CLIENTPASSWORD@gke-pg-cluster-ro.pg-ns/app

  9. 新しいデータの挿入を試みます。

    INSERT INTO travel_agency_clients(client, address, phone)
VALUES ('John', 'Paris', '+55555')
RETURNING *;

    出力は次のようになります。

    ERROR:  cannot execute INSERT in a read-only transaction

  10. データの読み取りを試みます。

    SELECT * FROM travel_agency_clients ;

    出力は次のようになります。

    client | address |  phone
--------+---------+---------
Tom    | Warsaw  | +55555
(1 row)

  11. 現在のデータベース セッションからログアウトします。

    exit

  12. Pod のシェルを終了します。

    exit

Prometheus が Postgres クラスタの指標を収集する仕組みを理解する

次の図は、Prometheus 指標の収集の仕組みを示しています。

この図では、GKE のプライベート クラスタに次のものが存在します。

  • パス / とポート 9187 の指標を収集する Postgres Pod
  • Postgres Pod の指標を処理する Prometheus ベースのコレクタ
  • Cloud Monitoring に指標を送信する PodMonitoring リソース

Pod から指標を収集できるようにするには、次の手順で操作します。

  1. PodMonitoring リソースを作成します。

    kubectl apply -f manifests/03-observability/pod-monitoring.yaml -n pg-ns

  2. Google Cloud コンソールで、[Metrics Explorer] のページに移動します。

    [Metrics Explorer] に移動

    ダッシュボードにゼロ以外の指標の取り込み率が表示されます。

  3. [指標を選択] で、「Prometheus Target」と入力します。

  4. [有効な指標カテゴリ] セクションで、[Cnpg] を選択します。

指標のダッシュボードを作成する

エクスポートされた指標を可視化するには、指標ダッシュボードを作成します。

  1. ダッシュボードをデプロイします。

    gcloud --project "${PROJECT_ID}" monitoring dashboards create --config-from-file manifests/03-observability/gcp-pg.json

  2. Google Cloud コンソールで [ダッシュボード] ページに移動します。

    ダッシュボードに移動する

  3. [PostgresQL Prometheus Overview] ダッシュボードを選択します。

    ダッシュボードがどのように関数をモニタリングしているかを確認するには、[データベース認証] セクションのアクションを再利用し、データベースに読み取り / 書き込みリクエストを適用した後、収集した指標の可視化をダッシュボードで確認します。

  4. クライアント Pod に接続します。

    kubectl exec -n pg-ns -i -t pg-client -- /bin/sh

  5. ランダムなデータを挿入します。

    psql postgresql://$CLIENTUSERNAME:$CLIENTPASSWORD@gke-pg-cluster-rw.pg-ns/app -c "CREATE TABLE test (id serial PRIMARY KEY, randomdata VARCHAR ( 50 ) NOT NULL);INSERT INTO test (randomdata) VALUES (generate_series(1, 1000));"

  6. ダッシュボードを更新します。グラフは実際の指標で更新されます。

  7. Pod のシェルを終了します。

    exit