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

Kubernetesは Controller pattern を使用します

現在のクラスターの状態を目的の状態に合わせます。

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

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

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

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

PVCリサイズ

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

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

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

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

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を作成します。その後、そのPodをスケジュールします

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

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

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

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

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

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

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

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