このページは Cloud Translation API によって翻訳されました。

高可用性 PostgreSQL データベースを GKE にデプロイする

Autopilot Standard

PostgreSQL は、信頼性とデータの整合性で有名なオープンソースのオブジェクトリレーショナルデータベースです。それは ACID に準拠し、外部キー、結合、ビュー、トリガー、ストアドプロシージャをサポートしています。

このドキュメントは、高可用性の PostgreSQL トポロジを Google Kubernetes Engine（GKE）にデプロイすることに関心があるデータベース管理者、クラウドアーキテクト、運用の担当者を対象としています。

目標

このチュートリアルの学習内容は次のとおりです。

Terraform を使用して GKE のリージョンクラスタを作成する。
高可用性 PostgreSQL データベースをデプロイする。
PostgreSQL アプリケーションのモニタリングを設定する。
PostgreSQL データベースと GKE クラスタのアップグレードを実行します。
クラスタの中断と PostgreSQL レプリカのフェイルオーバーをシミュレートする。
PostgreSQL データベースのバックアップと復元を行う。

アーキテクチャ

このセクションでは、このチュートリアルで構築するソリューションのアーキテクチャについて説明します。

2 つの GKE クラスタを異なるリージョンにプロビジョニングします。プライマリクラスタとバックアップクラスタです。このチュートリアルでは、プライマリクラスタは us-central1 リージョンにあり、バックアップクラスタは us-west1 リージョンにあります。このアーキテクチャでは、このチュートリアルの後の部分で説明するように、高可用性 PostgreSQL データベースをプロビジョニングし、障害復旧をテストできるようにします。

ソースクラスタの場合は、Helm チャート（bitnami/postgresql-ha）を使用して、高可用性 PostgreSQL クラスタを設定します。

図は、高可用性 PostgreSQL クラスタのアーキテクチャの例を示しています。 — **図 1**: 高可用性 PostgreSQL クラスタのアーキテクチャの例

費用

このドキュメントでは、Google Cloud の次の課金対象のコンポーネントを使用します。

料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを生成できます。新しい Google Cloud ユーザーは無料トライアルをご利用いただける場合があります。

このドキュメントに記載されているタスクの完了後、作成したリソースを削除すると、それ以上の請求は発生しません。詳細については、クリーンアップをご覧ください。

始める前に

プロジェクトを設定する

Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

In the Google Cloud console, on the project selector page, click Create project to begin creating a new Google Cloud project.

Go to project selector

Make sure that billing is enabled for your Google Cloud project.

Enable the Google Kubernetes Engine, Backup for GKE, Artifact Registry, Compute Engine, and IAM APIs.

Enable the APIs

In the Google Cloud console, on the project selector page, click Create project to begin creating a new Google Cloud project.

Go to project selector

Make sure that billing is enabled for your Google Cloud project.

Enable the Google Kubernetes Engine, Backup for GKE, Artifact Registry, Compute Engine, and IAM APIs.

Enable the APIs

ロールの設定

Grant roles to your user account. Run the following command once for each of the following IAM roles: role/storage.objectViewer, role/logging.logWriter, role/artifactregistry.Admin, roles/container.clusterAdmin, role/container.serviceAgent, roles/serviceusage.serviceUsageAdmin, roles/iam.serviceAccountAdmin
```
gcloud projects add-iam-policy-binding PROJECT_ID --member="user:USER_IDENTIFIER" --role=ROLE
```
- Replace PROJECT_ID with your project ID.
- Replace USER_IDENTIFIER with the identifier for your user account. For example, user:myemail@example.com.
- Replace ROLE with each individual role.

環境の設定

このチュートリアルでは、Cloud Shell を使用して Google Cloud でホストされるリソースを管理します。Cloud Shell には、Docker、kubectl、gcloud CLI、Helm、Terraform を含む、このチュートリアルに必要なソフトウェアがプリインストールされています。

Cloud Shell を使用して環境を設定するには:

Google Cloud コンソールで [Cloud Shell を有効化する] をクリックして、Google Cloud コンソールから Cloud Shell セッションを起動します。これにより、Google Cloud コンソールの下部ペインでセッションが起動します。
環境変数を設定します。
```
export PROJECT_ID=PROJECT_ID
export SOURCE_CLUSTER=cluster-db1
export REGION=us-central1
```
次の値を置き換えます。
- PROJECT_ID: Google Cloud プロジェクト ID
デフォルトの環境変数を設定します。
```
gcloud config set project PROJECT_ID
```

コードリポジトリのクローンを作成します。

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

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

cd kubernetes-engine-samples/databases/gke-stateful-postgres

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

このセクションでは、Terraform スクリプトを実行して、カスタム Virtual Private Cloud（VPC）、PostgreSQL イメージを保存する Artifact Registry リポジトリ、および 2 つのリージョン GKE クラスタを作成します。1 つのクラスタは us-central1 にデプロイされ、バックアップ用の 2 番目のクラスタは us-west1 にデプロイされます。

クラスタの作成手順は次のとおりです。

Autopilot

Cloud Shell で、次のコマンドを実行します。

terraform -chdir=terraform/gke-autopilot init
terraform -chdir=terraform/gke-autopilot apply -var project_id=$PROJECT_ID

プロンプトが表示されたら、「yes」と入力します。

Terraform の構成を理解する

Terraform 構成ファイルは、次のリソースを作成して、インフラストラクチャをデプロイします。

Docker イメージを保存するための Artifact Registry リポジトリを作成します。

resource "google_artifact_registry_repository" "main" {
  location      = "us"
  repository_id = "main"
  format        = "DOCKER"
  project       = var.project_id
}

VM のネットワークインターフェース用に VPC ネットワークとサブネットを作成します。

module "gcp-network" {
  source  = "terraform-google-modules/network/google"
  version = "< 8.0.0"

  project_id   = var.project_id
  network_name = "vpc-gke-postgresql"

  subnets = [
    {
      subnet_name           = "snet-gke-postgresql-us-central1"
      subnet_ip             = "10.0.0.0/17"
      subnet_region         = "us-central1"
      subnet_private_access = true
    },
    {
      subnet_name           = "snet-gke-postgresql-us-west1"
      subnet_ip             = "10.0.128.0/17"
      subnet_region         = "us-west1"
      subnet_private_access = true
    },
  ]

  secondary_ranges = {
    ("snet-gke-postgresql-us-central1") = [
      {
        range_name    = "ip-range-pods-db1"
        ip_cidr_range = "192.168.0.0/18"
      },
      {
        range_name    = "ip-range-svc-db1"
        ip_cidr_range = "192.168.64.0/18"
      },
    ],
    ("snet-gke-postgresql-us-west1") = [
      {
        range_name    = "ip-range-pods-db2"
        ip_cidr_range = "192.168.128.0/18"
      },
      {
        range_name    = "ip-range-svc-db2"
        ip_cidr_range = "192.168.192.0/18"
      },
    ]
  }
}

output "network_name" {
  value = module.gcp-network.network_name
}

output "primary_subnet_name" {
  value = module.gcp-network.subnets_names[0]
}

output "secondary_subnet_name" {
  value = module.gcp-network.subnets_names[1]
}

プライマリ GKE クラスタを作成します。

Terraform は us-central1 リージョンに限定公開クラスタを作成し、Backup for GKE で障害復旧を、Managed Service for Prometheus でクラスタのモニタリングを有効にします。

Managed Service for Prometheus は、GKE バージョン 1.25 以降を実行している Autopilot クラスタでのみサポートされます。

module "gke-db1-autopilot" {
  source                          = "../modules/beta-autopilot-private-cluster"
  project_id                      = var.project_id
  name                            = "cluster-db1"
  kubernetes_version              = "1.25" # Will be ignored if use "REGULAR" release_channel
  region                          = "us-central1"
  regional                        = true
  zones                           = ["us-central1-a", "us-central1-b", "us-central1-c"]
  network                         = module.network.network_name
  subnetwork                      = module.network.primary_subnet_name
  ip_range_pods                   = "ip-range-pods-db1"
  ip_range_services               = "ip-range-svc-db1"
  horizontal_pod_autoscaling      = true
  release_channel                 = "RAPID" # Default version is 1.22 in REGULAR. GMP on Autopilot requires V1.25 via var.kubernetes_version
  enable_vertical_pod_autoscaling = true
  enable_private_endpoint         = false
  enable_private_nodes            = true
  master_ipv4_cidr_block          = "172.16.0.0/28"
  create_service_account          = false
}

障害復旧のために us-west1 リージョンにバックアップクラスタを作成します。

module "gke-db2-autopilot" {
  source                          = "../modules/beta-autopilot-private-cluster"
  project_id                      = var.project_id
  name                            = "cluster-db2"
  kubernetes_version              = "1.25" # Will be ignored if use "REGULAR" release_channel
  region                          = "us-west1"
  regional                        = true
  zones                           = ["us-west1-a", "us-west1-b", "us-west1-c"]
  network                         = module.network.network_name
  subnetwork                      = module.network.secondary_subnet_name
  ip_range_pods                   = "ip-range-pods-db2"
  ip_range_services               = "ip-range-svc-db2"
  horizontal_pod_autoscaling      = true
  release_channel                 = "RAPID" # Default version is 1.22 in REGULAR. GMP on Autopilot requires V1.25 via var.kubernetes_version
  enable_vertical_pod_autoscaling = true
  enable_private_endpoint         = false
  enable_private_nodes            = true
  master_ipv4_cidr_block          = "172.16.0.16/28"
  create_service_account          = false
}

スタンダード

Cloud Shell で、次のコマンドを実行します。

terraform -chdir=terraform/gke-standard init
terraform -chdir=terraform/gke-standard apply -var project_id=$PROJECT_ID

プロンプトが表示されたら、「yes」と入力します。

Terraform の構成を理解する

Terraform 構成ファイルは、次のリソースを作成して、インフラストラクチャをデプロイします。

Docker イメージを保存するための Artifact Registry リポジトリを作成します。

resource "google_artifact_registry_repository" "main" {
  location      = "us"
  repository_id = "main"
  format        = "DOCKER"
  project       = var.project_id
}
resource "google_artifact_registry_repository_iam_binding" "binding" {
  provider   = google-beta
  project    = google_artifact_registry_repository.main.project
  location   = google_artifact_registry_repository.main.location
  repository = google_artifact_registry_repository.main.name
  role       = "roles/artifactregistry.reader"
  members = [
    "serviceAccount:${module.gke-db1.service_account}",
  ]
}

VM のネットワークインターフェース用に VPC ネットワークとサブネットを作成します。

module "gcp-network" {
  source  = "terraform-google-modules/network/google"
  version = "< 8.0.0"

  project_id   = var.project_id
  network_name = "vpc-gke-postgresql"

  subnets = [
    {
      subnet_name           = "snet-gke-postgresql-us-central1"
      subnet_ip             = "10.0.0.0/17"
      subnet_region         = "us-central1"
      subnet_private_access = true
    },
    {
      subnet_name           = "snet-gke-postgresql-us-west1"
      subnet_ip             = "10.0.128.0/17"
      subnet_region         = "us-west1"
      subnet_private_access = true
    },
  ]

  secondary_ranges = {
    ("snet-gke-postgresql-us-central1") = [
      {
        range_name    = "ip-range-pods-db1"
        ip_cidr_range = "192.168.0.0/18"
      },
      {
        range_name    = "ip-range-svc-db1"
        ip_cidr_range = "192.168.64.0/18"
      },
    ],
    ("snet-gke-postgresql-us-west1") = [
      {
        range_name    = "ip-range-pods-db2"
        ip_cidr_range = "192.168.128.0/18"
      },
      {
        range_name    = "ip-range-svc-db2"
        ip_cidr_range = "192.168.192.0/18"
      },
    ]
  }
}

output "network_name" {
  value = module.gcp-network.network_name
}

output "primary_subnet_name" {
  value = module.gcp-network.subnets_names[0]
}

output "secondary_subnet_name" {
  value = module.gcp-network.subnets_names[1]
}

プライマリ GKE クラスタを作成します。

module "gke-db1" {
  source                   = "../modules/beta-private-cluster"
  project_id               = var.project_id
  name                     = "cluster-db1"
  regional                 = true
  region                   = "us-central1"
  network                  = module.network.network_name
  subnetwork               = module.network.primary_subnet_name
  ip_range_pods            = "ip-range-pods-db1"
  ip_range_services        = "ip-range-svc-db1"
  create_service_account   = true
  enable_private_endpoint  = false
  enable_private_nodes     = true
  master_ipv4_cidr_block   = "172.16.0.0/28"
  network_policy           = true
  cluster_autoscaling = {
    "autoscaling_profile": "OPTIMIZE_UTILIZATION",
    "enabled" : true,
    "gpu_resources" : [],
    "min_cpu_cores" : 36,
    "min_memory_gb" : 144,
    "max_cpu_cores" : 48,
    "max_memory_gb" : 192,
  }
  monitoring_enable_managed_prometheus = true
  gke_backup_agent_config = true

  node_pools = [
    {
      name            = "pool-sys"
      autoscaling     = true
      min_count       = 1
      max_count       = 3
      max_surge       = 1
      max_unavailable = 0
      machine_type    = "e2-standard-4"
      node_locations  = "us-central1-a,us-central1-b,us-central1-c"
      auto_repair     = true
    },
    {
      name            = "pool-db"
      autoscaling     = true
      max_surge       = 1
      max_unavailable = 0
      machine_type    = "e2-standard-8"
      node_locations  = "us-central1-a,us-central1-b,us-central1-c"
      auto_repair     = true
    },
  ]
  node_pools_labels = {
    all = {}
    pool-db = {
      "app.stateful/component" = "postgresql"
    }
    pool-sys = {
      "app.stateful/component" = "postgresql-pgpool"
    }
  }
  node_pools_taints = {
    all = []
    pool-db = [
      {
        key    = "app.stateful/component"
        value  = "postgresql"
        effect = "NO_SCHEDULE"
      },
    ],
    pool-sys = [
      {
        key    = "app.stateful/component"
        value  = "postgresql-pgpool"
        effect = "NO_SCHEDULE"
      },
    ],
  }
  gce_pd_csi_driver = true
}

障害復旧のために us-west1 リージョンにバックアップクラスタを作成します。

module "gke-db2" {
  source                   = "../modules/beta-private-cluster"
  project_id               = var.project_id
  name                     = "cluster-db2"
  regional                 = true
  region                   = "us-west1"
  network                  = module.network.network_name
  subnetwork               = module.network.secondary_subnet_name
  ip_range_pods            = "ip-range-pods-db2"
  ip_range_services        = "ip-range-svc-db2"
  create_service_account   = false
  service_account          = module.gke-db1.service_account
  enable_private_endpoint  = false
  enable_private_nodes     = true
  master_ipv4_cidr_block   = "172.16.0.16/28"
  network_policy           = true
  cluster_autoscaling = {
    "autoscaling_profile": "OPTIMIZE_UTILIZATION",
    "enabled" : true,
    "gpu_resources" : [],
    "min_cpu_cores" : 10,
    "min_memory_gb" : 144,
    "max_cpu_cores" : 48,
    "max_memory_gb" : 192,
  }
  monitoring_enable_managed_prometheus = true
  gke_backup_agent_config = true
  node_pools = [
    {
      name            = "pool-sys"
      autoscaling     = true
      min_count       = 1
      max_count       = 3
      max_surge       = 1
      max_unavailable = 0
      machine_type    = "e2-standard-4"
      node_locations  = "us-west1-a,us-west1-b,us-west1-c"
      auto_repair     = true
    },
    {
      name            = "pool-db"
      autoscaling     = true
      max_surge       = 1
      max_unavailable = 0
      machine_type    = "e2-standard-8"
      node_locations  = "us-west1-a,us-west1-b,us-west1-c"
      auto_repair     = true
    },
  ]
  node_pools_labels = {
    all = {}
    pool-db = {
      "app.stateful/component" = "postgresql"
    }
    pool-sys = {
      "app.stateful/component" = "postgresql-pgpool"
    }
  }
  node_pools_taints = {
    all = []
    pool-db = [
      {
        key    = "app.stateful/component"
        value  = "postgresql"
        effect = "NO_SCHEDULE"
      },
    ],
    pool-sys = [
      {
        key    = "app.stateful/component"
        value  = "postgresql-pgpool"
        effect = "NO_SCHEDULE"
      },
    ],
  }
  gce_pd_csi_driver = true
}

PostgreSQL をクラスタにデプロイする

このセクションでは、Helm チャートを使用して、PostgreSQL データベースインスタンスをデプロイして、GKE で実行します。

PostgreSQL のインストール

クラスタに PostgreSQL をインストールするには、次の手順を行います。

Docker アクセスを構成します。

gcloud auth configure-docker us-docker.pkg.dev

必要な PostgreSQL Docker イメージを Artifact Registry に入力します。
```
./scripts/gcr.sh bitnami/postgresql-repmgr 15.1.0-debian-11-r0
./scripts/gcr.sh bitnami/postgres-exporter 0.11.1-debian-11-r27
./scripts/gcr.sh bitnami/pgpool 4.3.3-debian-11-r28
```
スクリプトは、次の Bitnami イメージを Artifact Registry for Helm に push してインストールします。
- postgresql-repmgr: この PostgreSQL クラスタソリューションには、PostgreSQL クラスタでのレプリケーションとフェイルオーバーを管理するためのオープンソースツールである PostgreSQL レプリケーションマネージャー（repmgr）が含まれています。
- postgres-exporter: PostgreSQL Exporter は、Prometheus の使用のための PostgreSQL 指標を収集します。
- pgpool: Pgpool-II は PostgreSQL プロキシです。それは接続プーリングとロードバランシングを提供します。

正しいイメージがリポジトリに保存されていることを確認します。

gcloud artifacts docker images list us-docker.pkg.dev/$PROJECT_ID/main \
    --format="flattened(package)"

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

---
image: us-docker.pkg.dev/[PROJECT_ID]/main/bitnami/pgpool
---
image: us-docker.pkg.dev/[PROJECT_ID]/main/bitnami/postgres-exporter
---
image: us-docker.pkg.dev/h[PROJECT_ID]/main/bitnami/postgresql-repmgr

プライマリクラスタへの kubectl コマンドラインアクセスを構成します。

gcloud container clusters get-credentials $SOURCE_CLUSTER \
--region=$REGION --project=$PROJECT_ID

Namespace を作成します。

export NAMESPACE=postgresql
kubectl create namespace $NAMESPACE

Autopilot クラスタにデプロイする場合は、3 つのゾーンにわたるノードプロビジョニングを構成します。Standard クラスタにデプロイする場合は、この手順をスキップしてください。

デフォルトでは、Autopilot は 2 つのゾーンにのみリソースをプロビジョニングします。prepareforha.yaml で定義されたデプロイにより、Autopilot は次の値を設定して、クラスタ内の 3 つのゾーンにノードをプロビジョニングします。

replicas:3
requiredDuringSchedulingIgnoredDuringExecution　と　topologyKey: "topology.kubernetes.io/zone" とともに podAntiAffinity

kubectl -n $NAMESPACE apply -f scripts/prepareforha.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: prepare-three-zone-ha
  labels:
    app: prepare-three-zone-ha
    app.kubernetes.io/name: postgresql-ha
spec:
  replicas: 3
  selector:
    matchLabels:
      app: prepare-three-zone-ha
      app.kubernetes.io/name: postgresql-ha
  template:
    metadata:
      labels:
        app: prepare-three-zone-ha
        app.kubernetes.io/name: postgresql-ha
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - prepare-three-zone-ha
            topologyKey: "topology.kubernetes.io/zone"
        nodeAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - preference:
              matchExpressions:
              - key: cloud.google.com/compute-class
                operator: In
                values:
                - "Scale-Out"
            weight: 1
      nodeSelector:
        app.stateful/component: postgresql
      tolerations:
      - effect: NoSchedule
        key: app.stateful/component
        operator: Equal
        value: postgresql
      containers:
      - name: prepare-three-zone-ha
        image: busybox:latest
        command:
            - "/bin/sh"
            - "-c"
            - "while true; do sleep 3600; done"
        resources:
          limits:
            cpu: "500m"
            ephemeral-storage: "10Mi"
            memory: "0.5Gi"
          requests:
            cpu: "500m"
            ephemeral-storage: "10Mi"
            memory: "0.5Gi"

Helm の依存関係を更新します。

cd helm/postgresql-bootstrap
helm dependency update

Helm がインストールするチャートを調べて確認します。

helm -n postgresql template postgresql . \
  --set global.imageRegistry="us-docker.pkg.dev/$PROJECT_ID/main"

Helm チャートをインストールします。

helm -n postgresql upgrade --install postgresql . \
    --set global.imageRegistry="us-docker.pkg.dev/$PROJECT_ID/main"

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

NAMESPACE: postgresql
STATUS: deployed
REVISION: 1
TEST SUITE: None

PostgreSQL のレプリカが動作していることを確認します。

kubectl get all -n $NAMESPACE

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

NAME                                                          READY   STATUS    RESTARTS   AGE
pod/postgresql-postgresql-bootstrap-pgpool-75664444cb-dkl24   1/1     Running   0          8m39s
pod/postgresql-postgresql-ha-pgpool-6d86bf9b58-ff2bg          1/1     Running   0          8m39s
pod/postgresql-postgresql-ha-postgresql-0                     2/2     Running   0          8m39s
pod/postgresql-postgresql-ha-postgresql-1                     2/2     Running   0          8m39s
pod/postgresql-postgresql-ha-postgresql-2                     2/2     Running   0          8m38s

NAME                                                   TYPE        CLUSTER-IP        EXTERNAL-IP   PORT(S)    AGE
service/postgresql-postgresql-ha-pgpool                ClusterIP   192.168.99.236    <none>        5432/TCP   8m39s
service/postgresql-postgresql-ha-postgresql            ClusterIP   192.168.90.20     <none>        5432/TCP   8m39s
service/postgresql-postgresql-ha-postgresql-headless   ClusterIP   None              <none>        5432/TCP   8m39s
service/postgresql-postgresql-ha-postgresql-metrics    ClusterIP   192.168.127.198   <none>        9187/TCP   8m39s

NAME                                                     READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/postgresql-postgresql-bootstrap-pgpool   1/1     1            1           8m39s
deployment.apps/postgresql-postgresql-ha-pgpool          1/1     1            1           8m39s

NAME                                                                DESIRED   CURRENT   READY   AGE
replicaset.apps/postgresql-postgresql-bootstrap-pgpool-75664444cb   1         1         1       8m39s
replicaset.apps/postgresql-postgresql-ha-pgpool-6d86bf9b58          1         1         1       8m39s

NAME                                                   READY   AGE
statefulset.apps/postgresql-postgresql-ha-postgresql   3/3     8m39s

テストデータセットを作成する

このセクションでは、データベースとサンプル値を含むテーブルを作成します。データベースは、このチュートリアルの後の部分でテストするフェイルオーバープロセスのテストデータセットとして機能します。

PostgreSQL インスタンスに接続します。

cd ../../
./scripts/launch-client.sh

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

Launching Pod pg-client in the namespace postgresql ...
pod/pg-client created
waiting for the Pod to be ready
Copying script files to the target Pod pg-client ...
Pod: pg-client is healthy

シェルセッションを開始します。

kubectl exec -it pg-client -n postgresql -- /bin/bash

データベースとテーブルを作成し、いくつかのテスト行を挿入します。
```
psql -h $HOST_PGPOOL -U postgres -a -q -f /tmp/scripts/generate-db.sql
```
各テーブルの行数を確認します。
```
psql -h $HOST_PGPOOL -U postgres -a -q -f /tmp/scripts/count-rows.sql
```
出力は次のようになります。
```
select COUNT(*) from tb01;
 count
--------
 300000
(1 row)

select COUNT(*) from tb02;
 count
--------
 300000
(1 row)
```
ヒント: pgbench を使用してダミーデータを作成することもできますが、クエリが必要とするトラフィックをより簡単に識別するには、提供したスクリプトを使用して、読み取り / 書き込みテスト中にクエリを実行するデータベースとテーブルを作成することをおすすめします。

テストデータを生成します。

export DB=postgres
pgbench -i -h $HOST_PGPOOL -U postgres $DB -s 50

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

dropping old tables...
creating tables...
generating data (client-side)...
5000000 of 5000000 tuples (100%) done (elapsed 29.85 s, remaining 0.00 s)
vacuuming...
creating primary keys...
done in 36.86 s (drop tables 0.00 s, create tables 0.01 s, client-side generate 31.10 s, vacuum 1.88 s, primary keys 3.86 s).

postgres クライアント Pod を終了します。
```
exit
```

PostgreSQL をモニタリングする

このセクションでは、PostgreSQL インスタンス用の指標を表示して、アラートを設定します。Google Cloud Managed Service for Prometheus を使用して、モニタリングとアラートを実行します。

指標を表示する

PostgreSQL の Deployment には、postgresql-exporter サイドカーコンテナが含まれています。このコンテナは /metrics エンドポイントを公開します。Google Cloud Managed Service for Prometheus は、このエンドポイントで PostgreSQL Pod をモニタリングするように構成されています。これらの指標は、Google Cloud コンソールのダッシュボードで確認できます。

Google Cloud コンソールは、ダッシュボードの構成を作成して保存する方法をいくつか提供します。

作成とエクスポート: Google Cloud コンソールでダッシュボードを直接作成してから、コードリポジトリにそれらをエクスポートして保存できます。そうするには、ダッシュボードのツールバーで JSON エディタを開き、ダッシュボードの JSON ファイルをダウンロードします。
ストレージとインポート: [+ ダッシュボードを作成する ]をクリックして、[JSON エディタ ] メニューを使用して、ダッシュボードの JSON コンテンツをアップロードすることで、JSON ファイルからダッシュボードをインポートできます。

PostgreSQL アプリケーションと GKE クラスタからのデータを可視化するには、次の手順に従います。

次のダッシュボードを作成します。

cd monitoring
gcloud monitoring dashboards create \
        --config-from-file=dashboard/postgresql-overview.json \
        --project=$PROJECT_ID
gcloud monitoring dashboards create \
        --config-from-file dashboard/gke-postgresql.json \
        --project $PROJECT_ID

Google Cloud コンソールで、Cloud Monitoring ダッシュボードに移動します。Cloud Monitoring ダッシュボードに移動する
ダッシュボードのリストから [カスタム] を選択します。次のダッシュボードが表示されます。
- PostgreSQL の概要: データベースの稼働時間、データベースのサイズ、トランザクションのレイテンシを含む、PostgreSQL アプリケーションの指標を表示します。
- GKE PostgreSQL クラスタ: CPU 使用率、メモリ使用量、ボリューム使用率を含む、PostgreSQL が実行されている GKE クラスタの指標を表示します。
各リンクをクリックして、生成されたダッシュボードを調べます。

アラートを設定する

アラートによって、アプリケーションの問題をタイムリーに認識できるため、問題をすばやく解決できます。アラートポリシーを作成して、アラートを受け取る状況と通知される方法を指定できます。アラートの送信先を選択できる通知チャンネルを作成することもできます。

このセクションでは、Terraform を使用して次の例のアラートを構成します。

db_max_transaction: トランザクションの最大ラグを秒単位でモニタリングします。値が 10 より大きい場合は、アラートがトリガーされます。
db_node_up: データベース Pod のステータスをモニタリングします。0 は、Pod がダウンして、アラートをトリガーすることを意味します。

アラートを設定する手順は次のとおりです。

Terraform を使用してアラートを構成します。

EMAIL=YOUR_EMAIL
cd alerting/terraform
terraform init
terraform plan -var project_id=$PROJECT_ID -var email_address=$EMAIL
terraform apply -var project_id=$PROJECT_ID -var email_address=$EMAIL

次の値を置き換えます。

YOUR_EMAIL: メールアドレス。

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

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

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

cd ../../../
kubectl exec -it --namespace postgresql pg-client -- /bin/bash

負荷テストを生成して、db_max_transaction アラートをテストします。

pgbench -i -h $HOST_PGPOOL -U postgres -s 200 postgres

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

dropping old tables...
creating tables...
generating data (client-side)...
20000000 of 20000000 tuples (100%) done (elapsed 163.22 s, remaining 0.00 s)
vacuuming...
creating primary keys...
done in 191.30 s (drop tables 0.14 s, create tables 0.01 s, client-side generate 165.62 s, vacuum 4.52 s, primary keys 21.00 s).

アラートがトリガーされると、件名が「[アラート] トランザクションの最大ラグ」で始まるメールが YOUR_EMAIL に送信されます。

Google Cloud コンソールで、[アラートポリシー] ページに移動します。

アラートポリシーに移動する
リスト内のポリシーから db_max_transaction を選択します。チャートから、Prometheus 指標 pg_stat_activity_max_tx_duration/gauge のしきい値の 10 を超える負荷テストの急増が確認できます。
postgres クライアント Pod を終了します。
```
exit
```

PostgreSQL と GKE のアップグレードを管理する

PostgreSQL と Kubernetes の両方のバージョンの更新は定期的なスケジュールでリリースされます。運用に関するベストプラクティスに沿って、ソフトウェア環境を定期的に更新します。デフォルトでは、GKE はクラスタとノードプールを管理して、アップグレードします。

PostgreSQL をアップグレードする

このセクションでは、PostgreSQL のバージョンアップグレードを行う方法について説明します。このチュートリアルでは、どの時点でもすべての Pod がダウンすることがないように、Pod のアップグレードにローリングアップデート戦略を使用します。

バージョンアップグレードの手順は次のとおりです。

更新されたバージョンの postgresql-repmgr イメージを Artifact Registry に push します。新しいバージョンを定義します（例えば、postgresql-repmgr 15.1.0-debian-11-r1）。
```
NEW_IMAGE=us-docker.pkg.dev/$PROJECT_ID/main/bitnami/postgresql-repmgr:15.1.0-debian-11-r1
./scripts/gcr.sh bitnami/postgresql-repmgr 15.1.0-debian-11-r1
```

kubectl を使用してローリングアップデートをトリガーします。

kubectl set image statefulset -n postgresql postgresql-postgresql-ha-postgresql postgresql=$NEW_IMAGE
kubectl rollout restart statefulsets -n postgresql postgresql-postgresql-ha-postgresql
kubectl rollout status statefulset -n postgresql postgresql-postgresql-ha-postgresql

StatefulSet は、序数が最も高いレプリカから開始し、最も低いものまで、ローリングアップデートが完了することが確認できます。

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

Waiting for 1 pods to be ready...
waiting for statefulset rolling update to complete 1 pods at revision postgresql-postgresql-ha-postgresql-5c566ccf49...
Waiting for 1 pods to be ready...
Waiting for 1 pods to be ready...
waiting for statefulset rolling update to complete 2 pods at revision postgresql-postgresql-ha-postgresql-5c566ccf49...
Waiting for 1 pods to be ready...
Waiting for 1 pods to be ready...
statefulset rolling update complete 3 pods at revision postgresql-postgresql-ha-postgresql-5c566ccf49...

Standard クラスタで GKE のアップグレードを計画する

このセクションは、Standard クラスタを実行している場合に適用されます。ステートフルサービスの実行時に、次のように、予防的な措置を講じて、リスクを軽減してクラスタのアップグレードをよりスムーズに行うための構成を設定することができます。

クラスタのアップグレードの GKE ベストプラクティスに従います。適切なアップグレード戦略を選択して、メンテナンスの時間枠の期間内にアップグレードが確実に行われるようにします。
- コストの最適化が重要であり、ワークロードが 60 分未満で正常なシャットダウンを許容できる場合は、サージアップグレードを選択します。
- ワークロードの中断を許容できず、リソース使用量の増加によって一時的な費用の増加が許容される場合は、Blue/Green アップグレードを選択します。
詳細については、ステートフルワークロードを実行するクラスタをアップグレードするをご覧ください。
Recommender サービスを使用して、サービスの中断を避けるために、非推奨の分析情報と推奨事項を確認します。
メンテナンスの時間枠を使用すると、アップグレードが意図したときに行われるようになります。メンテナンスの時間枠の前に、データベースのバックアップが成功したことを確認します。
アップグレードされたノードへのトラフィックを許可する前に、Readiness プローブと Liveness プローブを使用して、トラフィックの準備ができていることを確認します。
トラフィックの受信前に、レプリケーションが同期しているかどうかを評価するプローブを作成します。これは、データベースの複雑さと規模に応じて、カスタムスクリプトを通じて実行できます。

Standard クラスタのアップグレード中にデータベースの可用性を確認する

このセクションは、Standard クラスタを実行している場合に適用されます。アップグレード中に PostgreSQL の可用性を検証するには、アップグレード処理中に PostgreSQL データベースに対してトラフィックを生成することが一般的な処理です。その後、pgbench を使用して、データベースが完全に使用可能になったときに比べて、アップグレード中にデータベースがトラフィックのベースラインレベルを処理できることを確認します。

PostgreSQL インスタンスに接続します。

./scripts/launch-client.sh

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

Launching Pod pg-client in the namespace postgresql ...
pod/pg-client created
waiting for the Pod to be ready
Copying script files to the target Pod pg-client ...
Pod: pg-client is healthy

Cloud Shell で、クライアント Pod にシェルを追加します。
```
kubectl exec -it -n postgresql pg-client -- /bin/bash
```

pgbench を初期化します。

pgbench -i -h $HOST_PGPOOL -U postgres postgres

次のコマンドを使用して、アップグレードの時間枠内に PostgreSQL アプリケーションの可用性が高いままであることを確認するベースラインの結果を取得します。ベースライン結果を取得するには、30 秒間、マルチジョブ（スレッド）を介したマルチ接続でテストします。

pgbench -h $HOST_PGPOOL -U postgres postgres -c10 -j4 -T 30 -R 200

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

pgbench (14.5)
starting vacuum...end.
transaction type: <builtin: TPC-B (sort of)>
scaling factor: 1
query mode: simple
number of clients: 10
number of threads: 4
duration: 30 s
number of transactions actually processed: 5980
latency average = 7.613 ms
latency stddev = 2.898 ms
rate limit schedule lag: avg 0.256 (max 36.613) ms
initial connection time = 397.804 ms
tps = 201.955497 (without initial connection time)

アップグレード中の可用性を確保するには、データベースに対してある程度の負荷を生成し、PostgreSQL アプリケーションがアップグレード中も一貫した応答率を確実に示すようにします。このテストを行うには、pgbench コマンドを使用して、データベースに対するある程度のトラフィックを生成します。次のコマンドは、200 TPS（1 秒あたりのトランザクション数）を目標に、2 秒ごとにリクエスト率を一覧表示しながら、1 時間 pgbench を実行します。
```
pgbench -h $HOST_PGPOOL -U postgres postgres --client=10 --jobs=4 --rate=200 --time=3600 --progress=2 --select-only
```
ここで
- --client: シミュレートされたクライアントの数、つまりデータベースセッションの同時実行数。
- --jobs: pgbench 内のワーカースレッド数。マルチ CPU マシンでは、複数のスレッドの使用が便利です。クライアントは、使用可能なスレッド間でできるだけ均等に分散されます。デフォルトは 1 です。
- --rate: レートは 1 秒あたりのトランザクション数で指定します。
- --progress: 進捗レポートを 1 秒ごとに表示します。
出力は次のようになります。
```
pgbench (14.5)
starting vacuum...end.
progress: 5.0 s, 354.8 tps, lat 25.222 ms stddev 15.038
progress: 10.0 s, 393.8 tps, lat 25.396 ms stddev 16.459
progress: 15.0 s, 412.8 tps, lat 24.216 ms stddev 14.548
progress: 20.0 s, 405.0 tps, lat 24.656 ms stddev 14.066
```
Google Cloud コンソールで、Cloud Monitoring の PostgreSQL の概要ダッシュボードに戻ります。[DB あたりの接続] グラフと [Pod あたりの接続] グラフの急増に注意してください。
クライアント Pod を終了します。
```
exit
```

クライアント Pod を削除します。

kubectl delete pod -n postgresql pg-client

PostgreSQL サービスの中断をシミュレートする

このセクションでは、レプリケーションマネージャーサービスを停止して、PostgreSQL レプリカの 1 つでのサービスの中断をシミュレートします。これにより、Pod がピアレプリカにトラフィックを送信できなくなり、liveness プローブも失敗します。

新しい Cloud Shell セッションを開き、プライマリクラスタへの kubectl コマンドラインアクセスを構成します。
```
gcloud container clusters get-credentials $SOURCE_CLUSTER \
--region=$REGION --project=$PROJECT_ID
```

Kubernetes で出力された PostgreSQL イベントを表示します。

kubectl get events -n postgresql --field-selector=involvedObject.name=postgresql-postgresql-ha-postgresql-0 --watch

以前の Cloud Shell セッションで、PostgreSQL repmgr を停止してサービス障害をシミュレートします。
1. セッションをデータベースコンテナにアタッチします。
```
kubectl exec -it -n $NAMESPACE postgresql-postgresql-ha-postgresql-0 -c postgresql -- /bin/bash
```
2. repmgr を使用してサービスを停止し、チェックポイントと dry-run 引数を削除します。
```
export ENTRY='/opt/bitnami/scripts/postgresql-repmgr/entrypoint.sh'
export RCONF='/opt/bitnami/repmgr/conf/repmgr.conf'
$ENTRY repmgr -f $RCONF node service --action=stop --checkpoint
```

PostgreSQL コンテナ用に構成された liveness プローブが開始して 5 秒以内に失敗します。失敗しきい値の 6 回の失敗に達するまで、10 秒ごとにこれが繰り返されます。failureThreshold の値に達すると、コンテナが再起動されます。これらのパラメータを構成して、liveness プローブの許容範囲を下げて、デプロイの SLO 要件を調整できます。

イベントストリームから、Pod の liveness プローブと readiness プローブが失敗し、コンテナを再起動する必要があるというメッセージが表示されることが確認できます。出力は次のようになります。

0s          Normal    Killing                pod/postgresql-postgresql-ha-postgresql-0   Container postgresql failed liveness probe, will be restarted
0s          Warning   Unhealthy              pod/postgresql-postgresql-ha-postgresql-0   Readiness probe failed: psql: error: connection to server at "127.0.0.1", port 5432 failed: Connection refused...
0s          Normal    Pulled                 pod/postgresql-postgresql-ha-postgresql-0   Container image "us-docker.pkg.dev/psch-gke-dev/main/bitnami/postgresql-repmgr:14.5.0-debian-11-r10" already present on machine
0s          Normal    Created                pod/postgresql-postgresql-ha-postgresql-0   Created container postgresql
0s          Normal    Started                pod/postgresql-postgresql-ha-postgresql-0   Started container postgresql

障害復旧に備える

サービス中断イベントの発生時に本番環境のワークロードの可用性を確保するには、障害復旧（DR）計画を準備する必要があります。DR 計画の詳細については、障害復旧計画ガイドをご覧ください。

Kubernetes の障害復旧は、次の 2 つのフェーズで実現できます。

バックアップは、サービス中断イベントの発生前に、状態またはデータの特定の時点のスナップショットの作成に関与します。
復旧は、障害の発生後のバックアップコピーから状態またはデータの復元に関与します。

GKE クラスタでワークロードをバックアップして、復元するには、Backup for GKE を使用します。このサービスは、新規および既存のクラスタで有効にできます。これにより、クラスタで実行される Backup for GKE エージェントがデプロイされます。エージェントは、構成とボリュームのバックアップデータと取得と、復旧のオーケストレートを担当します。

バックアップと復元は、クラスタ全体、Namespace、アプリケーション（matchLabels などのセレクタで定義）の範囲に設定できます。

PostgreSQL のバックアップと復元のシナリオの例

このセクションの例では、ProtectedApplication カスタムリソースを使用して、アプリケーションの範囲でバックアップと復元の操作を実行する方法を紹介しています。

次の図は、ProtectedApplication のコンポーネントリソースを示しています。つまり、postgresql-ha アプリケーションを表す StatefulSet と、同じラベル（app.kubernetes.io/name: postgresql-ha）を使用する pgpool の Deployment を示しています。

高可用性 PostgreSQL クラスタ用のバックアップと復元のソリューションの例を示す図。 — **図 2**: 高可用性 PostgreSQL クラスタのバックアップと復元のソリューションの例

PostgreSQL ワークロードのバックアップと復元を準備するには、次の手順に従います。

環境変数を設定します。この例では、ProtectedApplication を使用して、PostgreSQL ワークロードとそのボリュームを移行元の GKE クラスタ（us-central1）から復元してから、異なるリージョン（us-west1）の別の GKE クラスタに復元します。

export SOURCE_CLUSTER=cluster-db1
export TARGET_CLUSTER=cluster-db2
export REGION=us-central1
export DR_REGION=us-west1
export NAME_PREFIX=g-db-protected-app
export BACKUP_PLAN_NAME=$NAME_PREFIX-bkp-plan-01
export BACKUP_NAME=bkp-$BACKUP_PLAN_NAME
export RESTORE_PLAN_NAME=$NAME_PREFIX-rest-plan-01
export RESTORE_NAME=rest-$RESTORE_PLAN_NAME

クラスタで Backup for GKE が有効になっていることを確認します。これは、以前に実行した Terraform 設定の一部としてすでに有効になっているはずです。
```
gcloud container clusters describe $SOURCE_CLUSTER \
    --project=$PROJECT_ID  \
    --region=$REGION \
    --format='value(addonsConfig.gkeBackupAgentConfig)'
```
Backup for GKE が有効になっている場合、コマンドの出力に enabled=True と表示されます。

バックアッププランを設定して復元を実行する

Backup for GKE を使用すると、cron ジョブとしてバックアッププランを作成できます。バックアッププランには、ソースクラスタ、バックアップするワークロードの選択、このプランで生成したバックアップアーティファクトが保存されているリージョンなどのバックアップ構成が含まれます。

バックアップと復元を実行する手順は次のとおりです。

cluster-db1 で ProtectedApplication のステータスを確認します。

kubectl get ProtectedApplication -A

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

NAMESPACE    NAME            READY TO BACKUP
postgresql   postgresql-ha   true

ProtectedApplication のバックアッププランを作成します。

export NAMESPACE=postgresql
export PROTECTED_APP=$(kubectl get ProtectedApplication -n $NAMESPACE | grep -v 'NAME' | awk '{ print $1 }')

gcloud beta container backup-restore backup-plans create $BACKUP_PLAN_NAME \
--project=$PROJECT_ID \
--location=$DR_REGION \
--cluster=projects/$PROJECT_ID/locations/$REGION/clusters/$SOURCE_CLUSTER \
--selected-applications=$NAMESPACE/$PROTECTED_APP \
--include-secrets \
--include-volume-data \
--cron-schedule="0 3 * * *" \
--backup-retain-days=7 \
--backup-delete-lock-days=0

バックアップを手動で作成します。

gcloud beta container backup-restore backups create $BACKUP_NAME \
--project=$PROJECT_ID \
--location=$DR_REGION \
--backup-plan=$BACKUP_PLAN_NAME \
--wait-for-completion

復元プランを設定します。

gcloud beta container backup-restore restore-plans create $RESTORE_PLAN_NAME \
  --project=$PROJECT_ID \
  --location=$DR_REGION \
  --backup-plan=projects/$PROJECT_ID/locations/$DR_REGION/backupPlans/$BACKUP_PLAN_NAME \
  --cluster=projects/$PROJECT_ID/locations/$DR_REGION/clusters/$TARGET_CLUSTER \
  --cluster-resource-conflict-policy=use-existing-version \
  --namespaced-resource-restore-mode=delete-and-restore \
  --volume-data-restore-policy=restore-volume-data-from-backup \
  --selected-applications=$NAMESPACE/$PROTECTED_APP \
  --cluster-resource-scope-selected-group-kinds="storage.k8s.io/StorageClass","scheduling.k8s.io/PriorityClass"

バックアップから復元します。

gcloud beta container backup-restore restores create $RESTORE_NAME \
  --project=$PROJECT_ID \
  --location=$DR_REGION \
  --restore-plan=$RESTORE_PLAN_NAME \
  --backup=projects/$PROJECT_ID/locations/$DR_REGION/backupPlans/$BACKUP_PLAN_NAME/backups/$BACKUP_NAME \
  --wait-for-completion

クラスタが復元されていることを確認する

復元されたクラスタにすべての期待される Pod、PersistentVolume、StorageClass リソースがあることを確認する手順は次のとおりです。

バックアップクラスタ cluster-db2 への kubectl コマンドラインアクセスを構成します。
```
gcloud container clusters get-credentials $TARGET_CLUSTER --region $DR_REGION --project $PROJECT_ID
```

3/3 Pod で StatefulSet の準備ができていることを確認します。

kubectl get all -n $NAMESPACE

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

NAME                                                   READY   STATUS    RESTARTS        AGE
pod/postgresql-postgresql-ha-pgpool-778798b5bd-k2q4b   1/1     Running   0               4m49s
pod/postgresql-postgresql-ha-postgresql-0              2/2     Running   2 (4m13s ago)   4m49s
pod/postgresql-postgresql-ha-postgresql-1              2/2     Running   0               4m49s
pod/postgresql-postgresql-ha-postgresql-2              2/2     Running   0               4m49s

NAME                                                   TYPE        CLUSTER-IP        EXTERNAL-IP   PORT(S)    AGE
service/postgresql-postgresql-ha-pgpool                ClusterIP   192.168.241.46    <none>        5432/TCP   4m49s
service/postgresql-postgresql-ha-postgresql            ClusterIP   192.168.220.20    <none>        5432/TCP   4m49s
service/postgresql-postgresql-ha-postgresql-headless   ClusterIP   None              <none>        5432/TCP   4m49s
service/postgresql-postgresql-ha-postgresql-metrics    ClusterIP   192.168.226.235   <none>        9187/TCP   4m49s

NAME                                              READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/postgresql-postgresql-ha-pgpool   1/1     1            1           4m49s

NAME                                                         DESIRED   CURRENT   READY   AGE
replicaset.apps/postgresql-postgresql-ha-pgpool-778798b5bd   1         1         1       4m49s

NAME                                                   READY   AGE
statefulset.apps/postgresql-postgresql-ha-postgresql   3/3     4m49s

postgres Namespace 内のすべての Pod が動作していることを確認します。

kubectl get pods -n $NAMESPACE

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

postgresql-postgresql-ha-pgpool-569d7b8dfc-2f9zx   1/1     Running   0          7m56s
postgresql-postgresql-ha-postgresql-0              2/2     Running   0          7m56s
postgresql-postgresql-ha-postgresql-1              2/2     Running   0          7m56s
postgresql-postgresql-ha-postgresql-2              2/2     Running   0          7m56s

PersistentVolume と StorageClass を確認します。復元処理中に、Backup for GKE は、ターゲットワークロードにプロキシクラスを作成して、ソースワークロード（サンプル出力の gce-pd-gkebackup-dn）でプロビジョニングされた StorageClass を置き換えます。

kubectl get pvc -n $NAMESPACE

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

NAME                                         STATUS   VOLUME                 CAPACITY   ACCESS MODES   STORAGECLASS          AGE
data-postgresql-postgresql-ha-postgresql-0   Bound    pvc-be91c361e9303f96   8Gi        RWO            gce-pd-gkebackup-dn   10m
data-postgresql-postgresql-ha-postgresql-1   Bound    pvc-6523044f8ce927d3   8Gi        RWO            gce-pd-gkebackup-dn   10m
data-postgresql-postgresql-ha-postgresql-2   Bound    pvc-c9e71a99ccb99a4c   8Gi        RWO            gce-pd-gkebackup-dn   10m

期待されたデータが復元されていることを確認する

期待されたデータが復元されていることを確認するには、次の手順に従います。

PostgreSQL インスタンスに接続します。

./scripts/launch-client.sh
kubectl exec -it pg-client -n postgresql -- /bin/bash

各テーブルの行数を確認します。
```
psql -h $HOST_PGPOOL -U postgres -a -q -f /tmp/scripts/count-rows.sql
select COUNT(*) from tb01;
```
以前にテストデータセットを作成するで書き込んだデータと同様の結果を確認できます。出力は次のようになります。
```
300000
(1 row)
```
クライアント Pod を終了します。
```
exit
```

クリーンアップ

このチュートリアルで使用したリソースについて、Google Cloud アカウントに課金されないようにするには、リソースを含むプロジェクトを削除するか、プロジェクトを維持して個々のリソースを削除します。

プロジェクトを削除する

課金が発生しないようにする最も簡単な方法は、チュートリアル用に作成したプロジェクトを削除することです。

注意: プロジェクトを削除すると、次のような影響があります。

プロジェクト内のすべてのものが削除されます。このドキュメントのタスクで既存のプロジェクトを使用した場合、それを削除すると、そのプロジェクトで行った他の作業もすべて削除されます。
カスタムプロジェクト ID が失われます。このプロジェクトを作成したときに、将来使用するカスタムプロジェクト ID を作成した可能性があります。そのプロジェクト ID を使用した URL（たとえば、appspot.com）を保持するには、プロジェクト全体ではなくプロジェクト内の選択したリソースだけを削除します。

複数のアーキテクチャ、チュートリアル、クイックスタートを実施する予定がある場合は、プロジェクトを再利用すると、プロジェクトの割り当て上限を超えないようにすることができます。

Delete a Google Cloud project:

gcloud projects delete PROJECT_ID

次のステップ

GKE にデータベースをデプロイするためのベストプラクティスを学びます。
永続ボリュームの詳細を確認する。
高可用性 PostgreSQL クラスタでのストリーミングレプリケーションに Pgpool-II を使用する方法の例をご覧ください。

高可用性 PostgreSQL データベースを GKE にデプロイする

目標

アーキテクチャ

費用

始める前に

プロジェクトを設定する

ロールの設定

環境の設定

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

Autopilot

Terraform の構成を理解する

スタンダード

Terraform の構成を理解する

PostgreSQL をクラスタにデプロイする

PostgreSQL のインストール

テスト データセットを作成する

PostgreSQL をモニタリングする

指標を表示する

アラートを設定する

PostgreSQL と GKE のアップグレードを管理する

PostgreSQL をアップグレードする

Standard クラスタで GKE のアップグレードを計画する

Standard クラスタのアップグレード中にデータベースの可用性を確認する

PostgreSQL サービスの中断をシミュレートする

障害復旧に備える

PostgreSQL のバックアップと復元のシナリオの例

バックアップ プランを設定して復元を実行する

クラスタが復元されていることを確認する

期待されたデータが復元されていることを確認する

クリーンアップ

プロジェクトを削除する

次のステップ

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

テストデータセットを作成する

バックアッププランを設定して復元を実行する