発端
- 新しく作るK8sベースのWebアプリのDBに、数年前使っていたPostgreSQLのKubernetes OperatorであるCrunchy DataのPGOを使おうと思った
- しかし、Crunchy DataのPGOを改めて調べてみると、ソース自体はオープンソースだが、使っているコンテナイメージがオープンソースではなく実質商用利用できないらしいことがわかった参考1参考2
- そこでオープンソースのPostgreSQL向けOperatorを調査して使うべきものを選定した
- ざっくりした選定基準は、Cloud Providerにバックアップできるか、カスタマイズ項目が多いか、カスタマイズしやすいか、将来的に使い続けられそうか等
俯瞰調査
- 下記のオープンソースのPostgreSQL向けOperatorについて調査
- CrunchyData/postgres-operator
- cloudnative-pg/cloudnative-pg
- zalando/postgres-operator
- ongres/stackgres
- percona/percona-postgresql-operator
- sorintlab/stolon
- (kubedb/docs)
- 上記のプロジェクトの概要（カスタマイズ性やプロジェクトの盛り上がり等）を調査したところ、機能面で優れるCrunchyDataのPGOをforkして作られたPerconaのPostgres Operatorと、CNCFプロジェクト（Sandbox）にリクエストしたCloudNativePGが良さそうに思えた
- 比較調査の詳細はこちら：KubernetesのPostgreSQL向けOperator比較
- CNCFについて
percona-postgresql-operatorとcloudnative-pgをローカルで試す
- WSL2のkind上にそれぞれのOperatorをデプロイしてみた
percona-postgresql-operator
- v2.0.0が最新バージョンとの記載があったが、Helmでもソースからでもエラーが出てデプロイできなかった（デフォルト設定でデプロイできるかのみを試した）ので、v1.3.0でテスト（v1.3.0はCrunchy Data PGOの4.7相当）
- アプリから使うときはpgBounderというServiceにアクセスすることでDBを利用する
- 手順と上記の話の詳細：Percona Operator for PostgreSQLを動かしてみる
cloudnative-pg
- 通常は、Cluster名の後に-r、-ro、-rwがsuffixとしてついたServiceにアクセスすることで、DBを利用する（読み書きしたければ、-rwのServiceを使う）
- 手順と上記の話の詳細：CloudNativePGを動かしてみる
ここまで調べての所感＋議論したこと
- Crunchy DataのPostgreSQL Operatorの知見を利用できるCrunchy DataのPGOをforkしたPerconaのOperatorは機能的に非常に魅力的
- ただし、Crunchy Dataの後追いになる
- CloudNativePGは、CNCFにリクエストしたのもあり、将来性にも強力なオープンソースコミュニティになりそう（注目度が高いのか、GithubのStar数の伸びがPerconaを上回る）
- PerconaのOperatorが将来的にオープンソースでなくなることはないと思うが、なんともいえないところ
- CLoudNativePGのfull-exampleのyamlと、PerconaのOperatorのOptionページを見ると、PerconaのOperatorの方が圧倒的に設定項目数が多いため、PerconaのOperatorの方がカスタマイズ性は高そう
- ドキュメントはCloudNativePGの方がわかりやすいのでアーキテクチャをイメージしやすい（PerconaのOperatorのドキュメントはところどころCrunchy Dataへのリンクになっているところがある）
（追記する可能性あり）
結論
- CNCFの認定ステージを注視しつつ、CloudNativePGで進める