Custom Pod Controller

Kubernetesは Controller pattern を使用します

をクリックして、現在のクラスターの状態を目的の状態に調整します。

ステートフルアプリケーションは、通常、 StatefulSet で管理されます

コントローラ、同じ仕様から構築されたポッドのセットを作成および調整し、それらにスティッキーIDを割り当てます。

CloudNativePGは、 StatefulSet コントローラに依存するのではなく、PostgreSQLインスタンスを管理するための独自のカスタムコントローラを実装します。このデザインの選択により、実装がより複雑になる一方で、PostgreSQLクラスターのトポロジについて透過的でありながら、クラスターの管理方法についてより柔軟にオペレーターに提供されます。

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

PVCのサイズ変更

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

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

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

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

プライマリインスタンス 1つだけ
レプリカマルチプル、オプショナル

この違いは、特定の操作に対して実行する正しい展開戦略を決定する際に関連します。

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

その際、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インスタンスをホストしていたと仮定すると、データベースのサイズとクラウドインフラストラクチャによっては、次のいずれかのアクションを選択することができます。

ダウンしたノードにあるPVCとポッドをドロップします。別のPVCからデータのクローンを作成する新しいPVCを作成します。その後、そのためのポッドをスケジュールします
ポッドをドロップし、別のノードでポッドをスケジュールし、そこからPVCをマウントします
ポッドとPVCをそのままにして、ノードがバックアップされるのを待ちます。

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

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

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

CloudNativePGコントローラは、これらの戦略をすべて実装して、ユーザーがクラスターレベルで優先される動作を選択できるようにします。詳細については、 Kubernetes upgrade and maintenance セクションを読んでください。

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