PGOを用いたPostgreSQL on Kubernetes入門（PostgreSQL Conference Japan 2022 発表資料）

© 2022 NTT DATA Corporation
【B2】 PGOを用いたPostgreSQL on Kubernetes入門
2022年11月11日 PostgreSQL Conference Japan 2022
株式会社NTTデータ技術開発本部
加藤慎也

© 2022 NTT DATA Corporation 2
自己紹介
• 名前
• 加藤慎也 @ShinyaKato_
• 所属
• 株式会社NTTデータ技術開発本部
• 業務
• PostgreSQLコミュニティでの開発
• PostgreSQLの研究開発やサポート業務

本講演について
• 講演資料はNTTデータのSlideShareで公開しています
• https://www.slideshare.net/nttdata-tech
• 講演資料に記載の情報は2022/11/1時点の情報となります
• スペースの都合上、コマンドの実行結果は一部省略している場合があります
• 質問は講演終了後やTwitterなどでお願いします

アジェンダ
Kubernetes上でPostgreSQLを運用管理するためのOperatorが複数
リリースされており、その1つであるPGOの機能や使い方、注意点を解説します！
• KubernetesとOperator
• PGOの基本機能
• PGOを使用する上での注意点

01
KubernetesとOperator

Kubernetes（K8s）とは
• コンテナ化されたアプリケーションのデプロイ、スケーリング、死活監視などを
自動化するためのコンテナオーケストレーションツール
• 初回リリース：2014年6月7日
• 最新版：1.25
デプロイ
スケーリング
死活監視
コンテナ
コンテナ
コンテナ
コンテナ
コンテナ
コンテナ

K8sクラスタのコンポーネント
• Pod
• K8sでコンテナを管理するための最小単位で、Pod内に1つ以上のコンテナを内包
• K8sクラスタはPodを実行するノードと呼ばれるワーカマシンの集合
• ワーカノード：Podをホスティング
• コントロールプレーン（マスタノード）：ワーカノードとPodを管理

K8sの主な機能 - Infrastructure as Code (IaC)
• YAMLで記述した宣言的なコード（マニフェスト）によってリソースの管理
• 同一環境の再現や複製、環境のGitでの管理が可能
apiVersion: v1
kind: Pod
metadata:
name: nginx-pod
spec:
containers:
- name: nginx
image: nginx:latest
nginx.yaml
apply
Pod
Pod
Pod
Pod
Pod
nginx-
Pod

K8sの主な機能 - （オート）スケーリング
• 同じコンテナイメージを元に複数のコンテナ（レプリカ）をデプロイでき、
負荷分散や耐障害性の確保が可能
• 負荷に応じたオートスケールも可能
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: nginx-replica
spec:
replicas: 3
selector:
matchLabels:
app: nginx-pod
template:
metadata:
labels:
app: nginx-pod
spec:
containers:
- name: nginx
image: nginx:latest
nginx.yaml
apply
Pod
Pod
Pod
Pod
Pod
nginx-
Pod
nginx-
Pod
nginx-
Pod

K8sの主な機能 - セルフヒーリング
• K8sはコンテナプロセスのヘルスチェックを行っている
• 例えば、ReplicaSetリソースに定義されたレプリカ数と実際にデプロイされている
Pod数を突合して、乖離があれば新たにPodをデプロイ
ReplicaSet（レプリカ数5）
Pod
Pod
Pod
Pod
Pod
Pod

K8sの主な機能 - リソースとコントローラ
• セルフヒーリングを実現する仕組みのように、
K8sには様々なリソースとその状態を管理するコントローラが存在する
リソースコントローラ主な役割
ReplicSet ReplicaSet Controller Podのレプリカを作成し、指定したPod数を維持
Deployment Deployment Controller 複数のReplicaSetを管理
（ローリングアップデート等を実現）
DaemonSet DaemonSet Controller 各ノードにPodを1つずつ配置
StatefulSet StatefulSet Controller データを永続化するための仕組みを提供
… … …

K8s上でのデータベース運用
• データベース運用者の視点
• 前述したK8sの標準のリソースとコントローラだけでは、
データベースの管理に生じる複雑な構築・運用作業の自動化を実装することが困難
• 例えば、PostgreSQLのHAクラスタを構築する場合
• PostgreSQLとクラスタウェア（PacemakerやPatroniなど）の構築
• 設定ファイルに適切なパラメータを設定
• レプリケーションロールの作成
• など・・・
これらの設定の自動化をK8s標準機能で実現することは困難

K8s Operator
• カスタムリソース（Custom Resource）
• K8sの標準リソースを利用しつつ、独自のリソース（あるべき状態）を定義
• カスタムコントローラ（Custom Controller）
• カスタムリソースに示したあるべき状態を保持するためのコントローラ
• Operator
• カスタムリソース+カスタムコントローラにより、前述の運用作業の自動化を実現
Operator
カスタム
リソース
カスタム
コントローラ
= +

OperatorによるK8s上のPostgreSQL運用管理
• Operatorにより機能の差異はあるが、
このようなPostgreSQLの環境を簡単に実現可能
バックアップ
モニタリングログ集約
PostgreSQL
HA構成
PostgreSQL PostgreSQL
HA構成
セットアップ
操作・監視
ユーザ

PostgreSQL Operator
• OperatorHub.ioに様々なOperatorが登録されており、
PostgreSQLのOperatorも複数登録されている
• OperatorHub.ioでPostgreSQLで検索した結果

PostgreSQL Operator
• 代表的なPostgreSQL Operatorの比較
本講演ではGitHubのスター数が最も多いPGOについて解説します！
PGO postgres-operator StackGres
メイン開発企業 Crunchy Data Zalando OnGres
初回リリース 2017年5月 2018年8月 2019年9月
最新バージョン 5.2.0 1.8.2 1.3.3
ライセンス Apache 2.0 MIT AGPLv3
スター数 3,012 2,877 487(GitHub), 75 (Gitlab)
コントリビュータ数 93 143 17
メイン実装言語 Go Go Java

02
PGOの基本機能

PGOの概要
• PostgreSQLコア開発者が複数所属している企業であるCrunchy Dataが
メインで開発・OSS提供しているOperator
• GitHubのスター数は3,012と人気のOperatorのうちの1つ
• PostgreSQL 10~14に対応

PGOのコンポーネント
• PGOは複数のソフトウェアから構成
クライアント
PgBouncer
postgres-
exporter
Patroni
postgres-
exporter
Patroni
postgres-
exporter
Patroni
pgBackRest
PVC AWS GCP Azure
コネクションプーリング
HA
バックアップ
モニタリング

今回構築する環境の完成図
• PGOの基本機能を紹介しながら環境を構築します
K8sクラスタ
ワーカ1
コントロールプレーン
Alertmanager
ワーカ2
ワーカ3
ワーカ4
クライアント
オブジェクトストレージ
バックアップ
primary
standby
standby
HA

使用バージョン
• Rocky Linux 8.6
• Docker 20.10.17
• kind 0.14.0
• Kubernetes 1.24
• PGO 5.20

K8s構築
• Docker、K8s（kind）、kubectlのインストール
• PGOは、Kubernetes、OpenShift、Rancher、GKE、EKS、AKS、VMware Tanzu
で使用可
• kindでコントロールプレーン1ノード、ワーカ4ノードのK8sを構築
• 構築手順は省略

現時点の環境図
K8sクラスタ
ワーカ1
ワーカ2
ワーカ3
ワーカ4
クライアント

PGOのインストール
• CrunchyのGitHubにあるサンプルを使用してPGOをインストール
$ git clone https://github.com/CrunchyData/postgres-operator-examples.git
$ cd postgres-operator-examples
$ git checkout b0f4500
$ kubectl apply -k kustomize/install/namespace
$ kubectl apply --server-side -k kustomize/install/default
$ kubectl get pods -n postgres-operator
NAME READY STATUS RESTARTS AGE
pgo-848fbd558f-7hjfn 1/1 Running 0 41s
pgo-upgrade-6b4b685577-tzqx9 1/1 Running 0 41s
PGOのPodとPostgreSQLのメジャー
バージョンアップに使用するPodが作成される

K8sクラスタ
ワーカ1
ワーカ2
ワーカ3
ワーカ4
クライアント
現時点では起動するノードを固定していないため、
別のノードに起動する場合があります。

DBクラスタ作成
• デフォルトのマニフェストでDBクラスタ作成
$ kubectl apply --server-side -k kustomize/postgres
$ kubectl get pods -n postgres-operator -l postgres-
operator.crunchydata.com/instance-set=instance1 -o wide
NAME READY STATUS NODE
hippo-instance1-gdhr-0 4/4 Running kind-worker4
hippoという名前のPostgreSQLのPodがワーカ4に起動

K8sクラスタ
ワーカ1
ワーカ2
ワーカ3
ワーカ4
クライアント

PostgreSQLの起動確認
• kubectl execコマンドでPod内のPostgreSQLコンテナに接続
$ kubectl exec -it -n postgres-operator hippo-instance1-gdhr-0 -- psql
Defaulted container "database" out of: database, replication-cert-copy,
pgbackrest, pgbackrest-config, postgres-startup (init), nss-wrapper-init (init)
psql (14.5)
Type "help" for help.
postgres=# SELECT version();
version
---------------------------------------------------------------------------------------------------------
PostgreSQL 14.5 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-10), 64-bit
(1 row)
PostgreSQLに接続し、SQLを実行できることを確認できる

レプリカの作成
• マニフェストにレプリカ数を設定して3冗長のDBクラスタを作成
$ git diff
diff --git a/kustomize/postgres/postgres.yaml b/kustomize/postgres/postgres.yaml
index f736b7e..fc30f17 100644
--- a/kustomize/postgres/postgres.yaml
+++ b/kustomize/postgres/postgres.yaml
@@ -7,6 +7,7 @@ spec:
postgresVersion: 14
instances:
- name: instance1
+ replicas: 3
dataVolumeClaimSpec:
accessModes:
- "ReadWriteOnce“
レプリカ数を3に設定

レプリカインスタンスの作成
• レプリカ数を設定して3冗長のDBクラスタを作成
hippo-instance1-27rc-0 4/4 Running kind-worker
hippo-instance1-gdhr-0 4/4 Running kind-worker4
hippo-instance1-qb5t-0 4/4 Running kind-worker4
変更をapply
PostgreSQLのPodが3つ起動

自動フェイルオーバ
• いずれかのPodに異常が発生したとき、PGOが自動でPodを再起動する
デモ動画

K8sクラスタ
ワーカ1
ワーカ2
ワーカ3
ワーカ4
クライアント
standby
HA
primary standby

各インスタンスが起動するワーカノードの固定
• 複数のワーカノードが存在するとき、
特定のワーカノードにPostgreSQLのPodを割り当てたい場合がある
• 高性能なSSD、高速なネットワークを備えているなど
• Node Affnityを用いて特定のノードにPodを割り当てる
• ワーカノードとPodの両方で設定が必要
DBサーバ用ワーカ Webサーバ用ワーカ
DBサーバ用ワーカに
スケジューリングしたい

• ワーカノードにラベル付けをする
$ kubectl label nodes kind-worker diskType=ssd
$ kubectl label nodes kind-worker2 diskType=ssd
$ kubectl label nodes kind-worker3 diskType=ssd
$ kubectl label nodes kind-worker4 diskType=hdd
$ kubectl get nodes --show-labels
NAME STATUS LABELS
kind-control-plane Ready ...
kind-worker Ready diskType=ssd,...
kind-worker2 Ready diskType=ssd,...
kind-worker3 Ready diskType=ssd,...
kind-worker3 Ready diskType=hdd,...
diskType=ssd diskType=ssd diskType=ssd diskType=hdd
ワーカ1 ワーカ2 ワーカ3 ワーカ4

• マニフェストにNode Affinityの設定をする
instances:
- name: instance1
replicas: 3
+ affinity:
+ nodeAffinity:
+ requiredDuringSchedulingIgnoredDuringExecution:
+ nodeSelectorTerms:
+ - matchExpressions:
+ - key: diskType
+ operator: In
+ values:
+ - ssd
diskType=ssdの
ノードに起動する

• マニフェストを適用
hippo-instance1-j4rd-0 4/4 Running kind-worker
hippo-instance1-jqz5-0 4/4 Running kind-worker
hippo-instance1-pslx-0 4/4 Running kind-worker2
ワーカ4にスケジューリング
されなくなった

K8sクラスタ
ワーカ1
ワーカ2
ワーカ3
ワーカ4
クライアント
primary
standby
standby
HA

各インスタンスを各ノードに適切に分散
• Topology Spread Constraintsを使用することで、
Region/Zone/Nodeなどの単位でPodを分散配置できる
• Region/Zone/Node障害発生時にも業務を継続できる
分散配置しない場合
AvailabilityZone A
分散配置する場合
AvailabilityZone A
AvailabilityZone B
AvailabilityZone Bで
業務継続できる

AvailabilityZoneの設定
• ワーカノードにラベル付けをする
$ kubectl label nodes kind-worker availabilityZone=A
$ kubectl label nodes kind-worker2 availabilityZone=B
$ kubectl label nodes kind-worker3 availabilityZone=C
$ kubectl get nodes --show-labels
NAME STATUS LABELS
kind-control-plane Ready ...
kind-worker Ready availabilityZone=A,...
kind-worker2 Ready availabilityZone=B,...
kind-worker3 Ready availabilityZone=C,...
kind-worker3 Ready ...
availabilityZone=A
ワーカ1 ワーカ2
availabilityZone=B
ワーカ3
availabilityZone=C

• マニフェストにTopology Spread Constraintsの設定をする
+ topologySpreadConstraints:
+ - maxSkew: 1
+ topologyKey: availabilityZone
+ whenUnsatisfiable: DoNotSchedule
+ labelSelector:
+ matchLabels:
+ postgres-operator.crunchydata.com/instance-set: instance1
+ postgres-operator.crunchydata.com/cluster: hippo
availabilityZoneで分散する

• マニフェストを適用
hippo-instance1-bzkw-0 4/4 Running kind-worker3
hippo-instance1-cmkl-0 4/4 Running kind-worker
hippo-instance1-m82d-0 4/4 Running kind-worker2
ワーカ1,2,3に分散して
スケジューリングされるようになった

K8sクラスタ
ワーカ1
ワーカ2
ワーカ3
ワーカ4
クライアント
primary
standby
standby
HA

モニタリングスタックのインストール
• PostgreSQLの性能情報をPrometheusにエクスポートするための
postgres-exporterコンテナをPostgreSQL Podに導入する
+ monitoring:
+ pgmonitor:
+ exporter:
+ image: registry.developers.crunchydata.com/crunchydata/crunchy-
postgres-exporter:ubi8-5.2.0-0
postgres-
exporter
メトリクス

モニタリングスタックのインストール
• Prometheus、Alertmanager、Grafanaをワーカ4にインストール
• Node AffinityとTopology Spread Constraintsの設定は前と同様
$ kubectl apply --server-side -k kustomize/monitoring
$ kubectl get pods -n postgres-operator -l app.kubernetes.io/name=postgres-
operator-monitoring -o wide
NAME READY NODE
crunchy-alertmanager-56b5bc54b-4c7f5 1/1 kind-worker4
crunchy-grafana-7fc46b99fd-m4c45 1/1 kind-worker4
crunchy-prometheus-6b67c667df-czbjd 1/1 kind-worker4
モニタリング関連の
YAMLファイルが格納
Prometheus、Alertmanager、
GrafanaのPodが起動

K8sクラスタ
ワーカ1
Alertmanager
ワーカ2
ワーカ3
ワーカ4
クライアント
primary
standby
standby
HA

PostgreSQLへの接続
• PGOはデフォルトでClusterIPというServiceを作成する
• ClusterIPはK8s内からの接続にしか使用できないため、
NodePortを作成し、K8s外からの接続を実現する
クライアント
ClusterIP
ClusterIP
クライアント
ClusterIP
NodePort
NodePort

Primary接続用NodePortの作成
• NodePortのマニフェストを作成
apiVersion: v1
kind: Service
metadata:
name: primary-nodeport
spec:
type: NodePort
selector:
postgres-operator.crunchydata.com/role: master
postgres-operator.crunchydata.com/cluster: hippo
ports:
- port: 5432
targetPort: 5432
nodePort: 30001
PrimaryのPodかつ
名前がhippoのPodに接続
Podの5432ポートを
ノードの30001ポートに

接続設定
• pg_hba.confの設定を行う
spec:
+ patroni:
+ dynamicConfiguration:
+ postgresql:
+ pg_hba:
+ - host all all 0.0.0.0/0 trust 全てのデータベース、ユーザ、接続元
からのTCP/IPでの接続を許可

Primaryへ接続
• ノードのIPアドレスを確認
$ kubectl get nodes -o wide
NAME STATUS ROLES VERSION INTERNAL-IP
kind-control-plane Ready control-plane v1.24.7 172.18.0.4
kind-worker Ready <none> v1.24.7 172.18.0.2
kind-worker2 Ready <none> v1.24.7 172.18.0.6

Primaryへ接続
• いずれかのノードのIPアドレス、NodePortのポート番号にpsqlで接続
$ psql -h 172.18.0.6 -p 30001 -U postgres postgres
psql (14.5)
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, bits: 256,
compression: off)
Type "help" for help.
postgres=#
同様の手順を踏めば
Standbyにも接続ができる

Primary、Standbyに接続して適切にレプリケーションされているか確認
• Primary、StandbyそれぞれにSQLを実行
デモ動画

Grafana接続用NodePortの作成
• NodePortのマニフェストを作成
apiVersion: v1
kind: Service
metadata:
name: grafana-nodeport
spec:
type: NodePort
selector:
app.kubernetes.io/name: postgres-operator-monitoring
name: crunchy-grafana
ports:
- port: 3000
targetPort: 3000
nodePort: 30003
Podの3000ポートを
ノードの30003ポートに

Grafana Dashboardへアクセス
• ブラウザからNodeのIPアドレス:NodePortのポート番号へアクセス
• ユーザ名admin、パスワードadminでログイン

Grafana Dashboardへアクセス
• 左のメニューからDashbords>Manage>PostgreSQLDetailsを開く

K8sクラスタ
ワーカ1
Alertmanager
ワーカ2
ワーカ3
ワーカ4
クライアント
primary
standby
standby
HA

バックアップ
• PGOに同梱のpgBackRestを使用する
• 自動/手動でバックアップの取得、バックアップ保持ポリシーの設定、PITRが可能
• K8sのストレージだけでなく、Amazon S3（S3 compatible含む）、
Google Cloud Storage、Azure Blob Storageへの保存も可能
pgBackRest Amazon Simple Storage
Service (Amazon S3)
pgBackRest

事前準備
• 今回はMinIOをローカルに立てて、バックアップ用のオブジェクトストレージとする
• 構築手順は省略
• MinIOのWebUIからバックアップ用バケットを作成

オブジェクトストレージ認証情報の設定
• kustomize/s3のマニフェストを使用
• 設定ファイルにMinIOの認証情報を設定
$ cp kustomize/s3/s3.conf.example kustomize/s3/s3.conf
$ vi s3.conf
[global]
repo1-s3-key=minioadmin
repo1-s3-key-secret=minioadmin

バックアップ基本設定
• マニフェストにバックアップの設定を行う
• 基本設定は以下
backups:
pgbackrest:
image: registry.developers.crunchydata.com/crunchydata/crunchy-
pgbackrest:ubi8-2.40-1
configuration:
- secret:
name: pgo-s3-creds
global:
repo1-s3-uri-style: path
repos:
- name: repo1
s3:
bucket: hippo-s3-backups
endpoint: http://127.0.0.1:9000
region: hoge
オブジェクトストレージのエンドポイント、
バケット名、リージョンを設定
（MinIOなどのS3互換でリージョンが存
在しない場合は任意の文字列）

自動バックアップ設定
• バックアップ保持ポリシー、バックアップ種別、バックアップ取得時刻の設定
global:
repo1-s3-uri-style: path
+ repo1-retention-full: 30
repos:
- name: repo1
+ schedules:
+ full: "0 1 * * *"
30個のバックアップを保持
repo1-retention-full-type: timeの
設定をすると30日間のバックアップを保持
full：フルバックアップ
differential：差分バックアップ
incremental：増分バックアップ
cron形式で実行タイミングを記述

手動バックアップ設定
• 以下をマニフェストに設定
• kubectl annotateコマンド実行を契機にバックアップ取得を開始
backups:
pgbackrest:
+ manual:
+ repoName: repo1
+ options:
+ - --type=full
$ kubectl annotate -n postgres-operator postgrescluster hippo-s3 ¥
postgres-operator.crunchydata.com/pgbackrest-backup="$(date)"
full：フルバックアップ
differential：差分バックアップ
incremental：増分バックアップ

完成図
K8sクラスタ
ワーカ1
Alertmanager
ワーカ2
ワーカ3
ワーカ4
クライアント
オブジェクトストレージ
バックアップ
primary
standby
standby
HA

その他の機能 - 設定変更（Patroni）
• Patroniの設定をマニフェストに記述することができる
spec:
+ patroni:
+ dynamicConfiguration:
+ master_stop_timeout: 60

その他の機能 - 設定変更（postgresql.conf）
• postgresql.confの設定をマニフェストに記述することができる
spec:
patroni:
dynamicConfiguration:
master_stop_timeout: 60
+ postgresql:
+ parameters:
+ autovacuum: off

その他の機能 - 設定変更（pg_hba.conf）
• pg_hba.confの設定をマニフェストに記述することができる
spec:
patroni:
dynamicConfiguration:
master_stop_timeout: 60
postgresql:
parameters:
autovacuum: off
+ pg_hba:
+ - host all all 0.0.0.0/0 trust

その他の機能 - DBクラスタの停止
• spec.shutdownをtrueとすることでDBクラスタを停止できる
デモ動画

その他の機能 - DBクラスタのスイッチオーバ
• スイッチオーバ（プライマリの切り替え）を実行できる
spec:
patroni:
+ switchover:
+ enabled: true
+ targetInstance: hippo-instance1-wm5p
切り替え先のPod名の指定は任意

その他の機能 - DBクラスタの手動フェイルオーバ
• 手動でのフェイルオーバを実行できる
diff --git a/kustomize/s3/postgres.yaml b/kustomize/s3/postgres.yaml
spec:
patroni:
switchover:
enabled: true
targetInstance: hippo-instance1-wm5p
+ type: Failover
切り替え先のPod名の指定は必須

その他の機能 - データベースの初期化
• DBクラスタ作成時にSQLスクリプトを自動実行できる
• 事前にSQLを記述したConfigMapを作成しておき、
DBクラスタのマニフェストに作成したConfigMap名を記述
apiVersion: v1
kind: ConfigMap
metadata:
name: init-sql
data:
init.sql: |
CREATE EXTENSION pg_stat_statements;
CREATE TABLE test_table (i INT);

その他の機能 - データベースの初期化
• DBクラスタ作成時にSQLスクリプトを自動実行できる
• 事前にSQLを記述したConfigMapを作成しておき、
DBクラスタのマニフェストに作成したConfigMap名を記述
diff --git a/kustomize/s3/postgres.yaml b/kustomize/s3/postgres.yaml
spec:
+ databaseInitSQL:
+ key: init.sql
+ name: init-sql

その他の機能 - マイナーバージョンアップ
• マイナーバージョンアップを試すために、バージョン14.4のPostgreSQLを起動
spec:
pgmonitor:
exporter:
image: registry.developers.crunchydata.com/crunchydata/crunchy-
postgres-exporter:ubi8-5.2.0-0
- image: registry.developers.crunchydata.com/crunchydata/crunchy-postgres:ubi8-
14.5-1
+ image: registry.developers.crunchydata.com/crunchydata/crunchy-postgres:ubi8-
14.4-0
postgresVersion: 14
instances:
- name: instance1
イメージ名のバージョンを変更

その他の機能 - マイナーバージョンアップ
• イメージのバージョンを変更し適用するとローリングアップデートが開始
デモ動画

その他の機能 - メジャーバージョンアップ
• PGO 5.1.0からメジャーバージョンアップにも対応

03
PGOを使用する上での注意点

WebUIがない
• postgres-operator（Zalando）、StackGres（OnGres）には
WebUIが付属しているがPGOには付属していない
postgres-operator（Zalando） StackGres（OnGres）

PGOバージョン4系との互換性がない
• 最新版のPGOバージョン5系は、バージョン4系と大きく異なっており、
互換性がない
• バージョン4系の最新版は4.7.7で、使用できるPostgreSQLの最新バージョン
はPostgreSQL 13.8であり、PostgreSQL 14を使用できない
• ドキュメントやWebでの検索結果はどちらのバージョンの記述かを
見極める必要がある

商用利用する場合はSupport Subscriptionに登録が必要
• Crunchy Dataの提供するDockerイメージは
Crunchy Data Developer Programの利用規約をもとに提供されている
• 開発目的の場合のみ無料でソフトウェアを使用することができる
• Dockerイメージを独自にビルドする場合も、
Dockerfile内でのPostgreSQLのインストールにCrunchy Data提供のRPM
を使用しているため、完璧なDockerイメージの再現は困難

使用できる拡張機能に制限がある
• 以下の拡張機能がPGOに同梱されている
• contribモジュール
• PgBouncer、PostGIS、orafce、pgAudit、pgAudit Analyze、pg_cron、
pg_partman、pgnodemx、set_user、TimescaleDB、wal2json、pgRouting
• 他の拡張機能を使用する場合には独自にDockerイメージをビルドする必要が
ある

一部の設定を変更することができない
• initdb時のパラメータ
• ロケールを設定したい場合、データベース単位での設定が必要
• Patroni管理、PGO管理のパラメータ
• HA関連パラメータ、バックアップ関連パラメータ、その他
• 例えば、shared_preload_librariesに必ずpgAuditが設定されてしまう
// PostgreSQLParameters sets the parameters required by pgAudit.
func PostgreSQLParameters(outParameters *postgres.Parameters) {
// Load the shared library when PostgreSQL starts.
// PostgreSQL must be restarted when changing this value.
// - https://github.com/pgaudit/pgaudit#settings
// - https://www.postgresql.org/docs/current/runtime-config-client.html
shared := outParameters.Mandatory.Value("shared_preload_libraries")
outParameters.Mandatory.Add("shared_preload_libraries",
strings.TrimPrefix(shared+",pgaudit", ","))
}
internal/pgaudit/postgres.go
PGO側が常にpgauditを設定

ログ収集の機能がない
• StackGresにはPostgreSQLやPatroniログを各Podから収集する機能がある
がPGOにはない
• 独自にFluentdやGrafana Lokiなどのソフトウェアを導入する必要がある

YAML上での設定変更を心がける必要がある
• Pod内の設定ファイルを直接書き換え
• Podが起動している間はその値が設定されるが、Podが再起動すると設定内容が消える
• YAMLでの設定値との乖離が発生
• ALTER SYSTEMコマンドでの設定変更
• Podが再起動しても設定内容は消えない（postgresql.auto.confは削除されない）
• YAMLでの設定値を常に上書きしてしまい、YAMLでの設定値との乖離が発生
• YAMLでの設定変更に慣れる必要がある
• PGO特有の注意点ではないが、Operatorによって挙動が異なる場合がある

まとめ
• PostgreSQL Operatorの1つであるPGOの紹介をしました
• PGOを活用することで、HA構成のPostgreSQLの構築、バックアップ/リストア、
モニタリング、バージョンアップなどを簡単に行うことができる
• PGOの使用にはいくつかの注意点がある

参考文献
• https://kubernetes.io/ja/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity/
• https://www.crunchydata.com/developers/terms-of-use
• https://min.io/docs/minio/linux/index.html
• https://kind.sigs.k8s.io/docs/user/quick-start/
• https://access.crunchydata.com/documentation/postgres-operator/v5/

PGOを用いたPostgreSQL on Kubernetes入門（PostgreSQL Conference Japan 2022 発表資料）

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a PGOを用いたPostgreSQL on Kubernetes入門（PostgreSQL Conference Japan 2022 発表資料）

Similar a PGOを用いたPostgreSQL on Kubernetes入門（PostgreSQL Conference Japan 2022 発表資料） (20)

Más de NTT DATA Technology & Innovation

Más de NTT DATA Technology & Innovation (20)

PGOを用いたPostgreSQL on Kubernetes入門（PostgreSQL Conference Japan 2022 発表資料）