カスタム Pod コントローラー

Kubernetes は Controller pattern を使用します

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

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

同じ仕様から構築された一連の Pod を作成して調整し、スティッキー 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 を作成します。その後、ポッドをスケジュールします

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

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

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

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

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

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

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