Custom Pod Controller ===================== Kubernetesは :ref:`Controller pattern ` を使用します をクリックして、現在のクラスターの状態を目的の状態に調整します。 ステートフルアプリケーションは、通常、 :ref:`StatefulSet ` で管理されます コントローラ、同じ仕様から構築されたポッドのセットを作成および調整し、それらにスティッキーIDを割り当てます。 EDB CloudNativePGクラスターは、 ``StatefulSet`` コントローラに依存するのではなく、PostgreSQLインスタンスを管理するための独自のカスタムコントローラを実装します。このデザインの選択により、実装がより複雑になる一方で、PostgreSQLクラスターのトポロジについて透過的でありながら、クラスターの管理方法についてより柔軟にオペレーターに提供されます。 デザイン領域の多くの選択と同様に、ものが異なると他の妥協が発生します。以下のセクションでは、このデザインの選択によりEDB CloudNativePG クラスターの実装の信頼性が向上し、理解しやすくなったと考えられるいくつかのポイントについて説明します。 PVCのサイズ変更 --------------- これは\ ``StatefulSet`` のよく知られた制限です。PVCのサイズ変更はサポートされていません。これはデータベースにとって不便です。ボリュームのサイズを変更するには、複雑な回避策が必要です。 対照的に、EDB CloudNativePGクラスターは、構成されたストレージクラスを活用して基になるPVCを直接管理し、ストレージクラスがサポートしている場合はPVCのサイズ変更を処理できます。 プライマリインスタンスとレプリカ -------------------------------- ``StatefulSet`` コントローラは、1つのテンプレートからポッドのセットを作成するように設計されています。 PostgreSQLインスタンスごとに1つの\ ``Pod`` を使用することを考えると、2種類のポッドがあります。 1. プライマリインスタンス 1つだけ 2. レプリカマルチプル、オプショナル この違いは、特定の操作に対して実行する正しい展開戦略を決定する際に関連します。 一部の操作は、最初にレプリカで実行し、次にプライマリで実行する必要がありますが、更新されたレプリカが新しいプライマリとして昇格した後にのみです。たとえば、別のPostgreSQLイメージバージョンを適用する場合、または ``max_connections`` `treated specially by PostgreSQL because EDB CloudNativePG Cluster uses hot standbyreplicas `_ のような構成パラメーターを増加する場合。 その際、EDB CloudNativePG クラスターは、シリアル番号だけでなく、PostgreSQLインスタンスのロールを考慮します。 場合によっては、オペレーターは逆のプロセスに従う必要があります。最初にプライマリで作業し、次にレプリカで作業します。例、\ ``max_connections`` を下げた場合。その場合、EDB CloudNativePGクラスターは次のことを行います。 - 新しい設定をプライマリインスタンスに適用します - 再起動します - レプリカに新しい設定を適用します ``StatefulSet`` コントローラはアプリケーションに依存しないため、PostgreSQLのネイティブレプリケーションテクノロジーに固有のこの動作を組み込むことができません。 PVCのコヒーレンス ----------------- PostgreSQLインスタンスは、複数のPVCで動作するように構成できます。これが、WALストレージを\ ``PGDATA`` から分離する方法です。 2つのデータストアは、同時に使用されるため、PostgreSQLの観点から一貫性がある必要があります。インスタンスのWALストレージに対応するPVCを削除すると、\ ``PGDATA`` が保存されているPVCは使用できなくなります。 この動作はPostgreSQLに固有であり、\ ``StatefulSet`` コントローラには実装されていません - 後者はアプリケーション固有ではありません。 ユーザーがPVCをドロップした後、\ ``StatefulSet`` はそれを再作成するだけで、破損したPostgreSQLインスタンスが発生します。 EDB CloudNativePGクラスターは、代わりに残りのPVCを使用不可として分類し、別のインスタンスがクラスターに正しく参加するようにPVCの新しいペアの作成を開始します。 ローカルストレージ、リモートストレージ、およびデータベースのサイズ ------------------------------------------------------------------ 場合によっては、アップグレードを行うためにKubernetesノードをダウンする必要がある場合があります。アップグレード後、アップグレード戦略によっては、更新されたノードが再び起動するか、新しいノードに置き換えられる場合があります。 使用できないノードがPostgreSQLインスタンスをホストしていたと仮定すると、データベースのサイズとクラウドインフラストラクチャによっては、次のいずれかのアクションを選択することができます。 1. ダウンしたノードにあるPVCとポッドをドロップします。別のPVCからデータのクローンを作成する新しいPVCを作成します。その後、そのためのポッドをスケジュールします 2. ポッドをドロップし、別のノードでポッドをスケジュールし、そこからPVCをマウントします 3. ポッドとPVCをそのままにして、ノードがバックアップされるのを待ちます。 最初の解決策は、データベースのサイズが許可する場合に実用的で、目的の数のレプリカをすぐに戻すことができます。 2番目の解決策は、ローカルノードのストレージを使用していない場合にのみ実行可能であり、別のホストでのPVCの再マウントは合理的な時間で可能ですあなたとあなたの組織のみが知っています。 3番目のソリューションは、データベースが大規模で、パフォーマンスとデータの耐久性を最大化するためにローカルノードストレージを使用する場合に適しています。 EDB CloudNativePG クラスターコントローラーは、これらの戦略をすべて実装して、ユーザーがクラスターレベルで優先される動作を選択できるようにします。詳細については、 :ref:`Kubernetes Upgrade and Maintenance ` セクションを読んでください。 ``StatefulSet`` は汎用であるため、このレベルのカスタマイズはできません。