カスタムポッドコントローラー

Kubernetesは Controller pattern を使用して、現在のクラスターの状態を目的の状態に合わせます。

ステートフルアプリケーションは通常、

StatefulSet コントローラーで管理されます。これは、同じ仕様で構築された一連のPodを作成して調整し、それらに固定IDを割り当てます。

CloudNativePGは、 StatefulSet コントローラーに依存する代わりに、独自のカスタムコントローラーを実装してPostgreSQLインスタンスを管理します。この設計の選択により、実装がより複雑になりますが、オペレーターはPostgreSQLクラスターのトポロジを透過的にしながら、クラスターを管理する方法をより柔軟に行うことができます。

デザイン領域の多くの選択肢と同様に、異なる選択肢は他の妥協につながります。以下のセクションでは、この設計の選択によりCloudNativePGの実装の信頼性が向上し、理解しやすくなったと思われるいくつかのポイントについて説明します。

PVCのリサイズ

これは StatefulSet のよく知られた制限です。PVCのサイズ変更はサポートしていません。これはデータベースにとって不便です。ボリュームのサイズを変更するには、複雑な回避策が必要です。

対照的に、CloudNativePGは、構成されたストレージクラスを活用して基になるPVCを直接管理し、ストレージクラスがサポートしている場合はPVCのサイズ変更を処理できます。

プライマリインスタンスとレプリカ

StatefulSet コントローラーは、1つのテンプレートから一連のPodを作成するように設計されています。 PostgreSQLインスタンスごとに1つのPod を使用すると、2種類のポッドがあります。

1.プライマリインスタンス（1つだけ）

2.レプリカ（複数、オプション）

この違いは、特定の操作で実行する正しい展開戦略を決定するときに関係します。

一部の操作は、最初にレプリカで実行してからプライマリで実行する必要がありますが、更新されたレプリカが新しいプライマリとして昇格した後にのみ実行します。たとえば、別のPostgreSQLイメージバージョンを適用する場合、または max_connections （これはtreated specially by PostgreSQL because CloudNativePG uses hot standby replicas）のような構成パラメーターを増やす場合です。

その際、CloudNativePGはシリアル番号だけでなく、PostgreSQLインスタンスのロールを考慮します。

場合によっては、オペレーターは逆のプロセスに従う必要があります。最初にプライマリで作業し、次にレプリカで作業します。例えば、max_connections を下げる場合。その場合、CloudNativePGは次のことを行います。

  • 新しい設定をプライマリインスタンスに適用します

  • 再起動します

  • レプリカに新しい設定を適用します

StatefulSet コントローラーは、アプリケーションに依存しないため、PostgreSQLのネイティブレプリケーションテクノロジーに固有のこの動作を組み込むことができません。

PVCの一貫性

PostgreSQLインスタンスは、複数のPVCで動作するように構成できます。これが、WALストレージをPGDATA から分離する方法です。

2つのデータストアは同時に使用されるため、PostgreSQLの観点から一貫している必要があります。インスタンスのWALストレージに対応するPVCを削除すると、 PGDATA が保存されているPVCは使用できなくなります。

この動作はPostgreSQLに固有であり、 StatefulSet コントローラーには実装されていません。後者はアプリケーション固有ではありません。

ユーザーがPVCをドロップすると、 StatefulSet はそれを再作成し、PostgreSQLインスタンスが破損しました。

CloudNativePGは代わりに、残りのPVCを使用不可として分類し、別のインスタンスがクラスターに正しく参加するための新しいPVCペアの作成を開始します。

ローカルストレージ、リモートストレージ、およびデータベースサイズ

アップグレードを行うために、Kubernetesノードを停止する必要がある場合があります。アップグレード後、アップグレード戦略に応じて、更新されたノードが再び稼働するか、新しいノードに置き換えられます。

使用できないノードがPostgreSQLインスタンスをホストしていると仮定すると、データベースのサイズとクラウドインフラストラクチャに応じて、次のいずれかのアクションを選択できます。

1.ダウンしたノードにあるPVCとPodをドロップします。別のPVCからデータを複製する新しいPVCを作成します。その後、そのポッドをスケジュールします

2.ポッドをドロップし、別のノードでポッドをスケジュールし、そこからPVCをマウントします

  1. PodとPVCをそのままにして、ノードがバックアップするのを待ちます。

最初の解決策は、データベースのサイズが許す場合に実用的であり、必要な数のレプリカをすぐに戻すことができます。

2番目の解決策は、ローカルノードのストレージを使用していない場合にのみ実現可能であり、妥当な時間内に別のホストに再マウントできます（あなたとあなたの組織だけが知っています）。

3番目のソリューションは、データベースが大きく、パフォーマンスとデータの耐久性を最大限に高めるためにローカルノードストレージを使用する場合に適しています。

CloudNativePGコントローラーはこれらすべての戦略を実装するため、ユーザーはクラスターレベルで優先する動作を選択できます（詳細については、

Kubernetesのアップグレード セクションをお読みください）。

汎用であるため、 StatefulSet はこのレベルのカスタマイズを許可しません。