オペレーター能力レベル#

このセクションでは、CloudNativePGによって実装された機能の概要を提供します、

Operator SDK definition of Capability Levels

フレームワーク。

Operator Capability Levels

Operator Capability Levels#

重要

Operator Capability Levels model に基づいて、CloudNativePGオペレーターからの**「レベルV - 自動パイロット」**機能セットを期待できます。

各機能レベルは、オペレーターが提供する特定の管理機能のセットに関連付けられています。

1.基本的なインストール

2.シームレスなアップグレード

3.完全なライフサイクル

4.深い洞察

5.オートパイロット

注釈

私たちは、このフレームワークを、オペレーターでの将来の作業と実装のガイドと考えます。

レベル1:基本的なインストール#

機能レベル1には、オペレーターの インストール と 構成 が含まれます。このカテゴリには、オペレーターやPostgreSQLクラスター構成との対話方法の改善など、使いやすさとユーザーエクスペリエンスの強化が含まれています。

重要

**情報セキュリティ**はこのレベルの一部であると考えられます。

宣言的構成を介したOperatorの展開#

オペレーターは、4つのメジャーCustomResourceDefinition オブジェクトCluster 、Pooler 、Backup 、およびScheduledBackup を定義するKubernetesマニフェストを使用して宣言的方法でインストールされます。

宣言的構成を介したPostgreSQLクラスターの展開#

PostgreSQLクラスターオペランドは、Cluster カスタムリソースを使用して完全に宣言的な方法で定義されます。 PostgreSQLバージョンは、CRで定義されたオペランドコンテナイメージによって決定されます。これは、要求されたレジストリから自動的に取得されます。オペランドを展開するときに、オペレーターは次のリソースも自動的に作成します。Pod 、Service 、Secret 、ConfigMap 、PersistentVolumeClaim 、PodDisruptionBudget 、ServiceAccount 、RoleBinding 、Role 。

CRDを介したオペランドイメージのオーバーライド#

オペレーターは、内部にPostgreSQLを使用したオペランドコンテナイメージをサポートするように設計されています。デフォルトでは、オペレーターはPostgreSQLコミュニティでサポートされ、ghcr.ioで公開された最新の安定したメジャーバージョンの利用可能な最新のマイナーバージョンを使用します。 CRでimageName 属性を設定することにより、プライマリ/スタンバイアーキテクチャをサポートするPostgreSQLの互換イメージを直接使用できます。また、オペレーターは、プライベートコンテナレジストリにアクセスするためのimagePullSecrets と、コンテナイメージの不変性をより詳細に制御するためのタグに加えてダイジェストもサポートします。

ラベルとアノテーション#

KubernetesインフラストラクチャでのCloudNativePG展開の組織を向上させることを目的に、クラスターのメタデータで定義されたラベルとアノテーションの継承をサポートするようにオペレーターを構成できます。

自己完結型インスタンスマネージャー#

PatroniやStolonなどの外部ツールに依存してKubernetesクラスターポッド内のPostgreSQLインスタンスを調整する代わりに、オペレーターは各ポッド内の/controller/manager という名前のファイルにオペレーター実行可能ファイルを注入します。アプリケーションは、基になるPostgreSQLインスタンスを制御し、PostgreSQLクラスタートポロジに基づいてインスタンス自分自身とポッドステータスを調整するために使用されます。インスタンスマネージャーは、プローブのkubelet によって呼び出されるWebサーバーも起動します。 kubelet によって呼び出されたUnixシグナルは、インスタンスマネージャーによってフィルタリングされ、必要に応じてpostgres プロセスに転送され、外部イベントに対する高速で制御された反応が行われます。インスタンスマネージャーはGoで書かれており、外部依存関係はありません。

ストレージ構成#

ストレージは、データベースワークロードの重要なコンポーネントです。オペレーターは、ストレージに関するKubernetesのネイティブ機能とリソースを利用して、基になるKubernetes環境が提供できるものに基づいて、ワークロード要件に適切なストレージを選択するための十分な柔軟性を提供します。これは、パブリッククラウド環境で特定のストレージクラスを選択するか、CRのstorage パラメーターのPVCテンプレートを介して生成されたPVCを微調整することを意味します。パフォーマンスの向上とより詳細な制御のために、クラスターの書き込み先行ログWAL、pg_wal としても知られるを別のボリューム、できれば別のストレージでホストすることを選択することもできます。

cnp-bench オープンソースプロジェクトは、運用前にストレージとデータベースの両方のベンチマークを使用できます。

レプリカ構成#

オペレーターは、instances と呼ばれる単一のパラメーターを介してクラスター内のレプリカを自動的に検出します。 1 に設定されている場合、クラスターは、レプリカのない単一のプライマリPostgreSQLインスタンスで構成されます。 1 より高い場合、オペレーターは、自動フェイルオーバーを介した高可用性HA、スイッチオーバー操作を介したローリング更新を含むinstances -1 レプリカを管理します。 CloudNativePGは、HAクラスター内のすべてのレプリカのレプリケーションスロットを自動的に管理し、以前に提案されたPostgreSQLの

Failover slots と呼ばれるパッチからインスパイアされた実装を使用します。

データベース構成#

オペレーターは、単一のデータベースでPostgreSQLクラスターを管理するように設計されています。オペレーターは、読み取り書き込み、読み取り、および読み取り専用のワークロードに対して自動的にプロビジョニングおよび管理される3つのKubernetesサービスを介して、データベースへのアクセスを透過的に管理します。構成よりも規約のアプローチを使用して、オペレーターはapp と呼ばれるデータベースを作成します。デフォルトでは、同じ名前の通常のPostgresユーザーが所有します。必要に応じて、データベース名とユーザー名の両方を指定できます。クラスターを実行するための構成は必要ありませんが、 CRのpostgresql セクションでPostgreSQLランタイム構成とPostgreSQLホストベースの認証ルールの両方をカスタマイズできます。

Postgresのロール、ユーザー、グループの構成#

CloudNativePGは management of PostgreSQL roles, users, and groups through declarative configuration をサポート

.spec.managed.roles スタンザを使用します。

ポッドセキュリティポリシー#

InfoSec要件の場合、オペレーターはコンテナに特権モードを必要とせず、読み取り専用のルートファイルシステムを適用して、オペレーターとオペランドポッドの両方でコンテナの不変性を保証します。また、必要なセキュリティコンテキストも明示的に設定します。

アフィニティ#

クラスターのaffinity セクションでは、ポッドと永続ボリュームなどの関連リソースをKubernetesクラスターのノード全体でスケジュールする方法を微調整できます。特に、オペレーターは以下をサポートしています。

  • ポッドアフィニティとアンチアフィニティ

  • ノードセレクター

  • テイントと許容範囲

トポロジスプレッドコンストレイン#

クラスターのtopologySpreadConstraints セクションにより、トポロジ全体でポッドのスケジューリングの追加制御が有効になり、アフィニティとアンチアフィニティが提供できる機能が強化されます。

コマンドラインインターフェイス#

CloudNativePGには、独自のコマンドラインインターフェイスがありません。これは、PostgreSQLクラスター管理エクスペリエンスを強化および簡素化するcnpg と呼ばれるプラグインを提供することにより、Kubernetesに最適なコマンドラインインターフェイスkubectl に依存するだけです。

クラスターの現在のステータス#

オペレーターは、クラスターの観察されたステータスでCRのステータスセクションを継続的に更新します。 PostgreSQLクラスター全体のステータスは、各ポッドで実行されているインスタンスマネージャーによって継続的に監視されます。インスタンスマネージャーは、制御対象のPostgreSQLインスタンスに必要な変更を適用して、クラスターの必要なステータスに収束します。例、クラスターステータスがレポートされた場合そのポッド -1 がプライマリであり、ポッド -1 は自分自身を昇格させる必要がありますが、他のポッドはポッド -1 に従う必要があります。同じステータスは、kubectl のcnpg プラグインによって使用され、詳細を提供します。

オペレーターの認証局#

オペレーターは、自分自身の認証局を自動的に作成します。 Webhookサーバーが使用するリーフ証明書を作成および署名し、Kubernetes APIサーバーとオペレーター自分自身間の安全な通信を保証します。

クラスターの認証局#

オペレーターは、すべてのPostgreSQLクラスターの認証局を自動的に作成します。これは、パスワードの代わりにストリーミングレプリケーションスタンバイサーバーを含むクライアントの認証のためのTLS証明書を発行および更新するために使用されます。クライアント証明書のカスタム認証局のサポートは、シークレットを介して利用できます。これには、cert-managerとの統合も含まれます。証明書は、 kubectl のcnpg プラグインを使用して発行できます。

TLS接続#

オペレーターは、TLS / SSL接続を透過的にサポートし、クラスターの認証局を使用してクライアント/サーバー通信を暗号化し、セキュリティを向上させます。カスタムサーバー証明書のサポートは、シークレットを介して利用できます。これには、cert-managerとの統合も含まれます。

ストリーミングレプリケーションの証明書認証#

オペレーターは、パスワードおよびシークレットに依存するのではなく、TLSクライアント証明書認証を使用して、スタンバイサーバーからのストリーミングレプリケーション接続を承認します。

継続的な構成管理#

オペレーターを使用すると、PostgreSQL構成のCluster リソースYAMLセクションに変更を適用でき、構成オプションに応じて、すべてのインスタンスが適切にリロードまたは再起動されます。 現在の制限 ALTER SYSTEM による変更は検出されません。つまり、クラスター状態が適用されません。

既存のPostgreSQLデータベースのインポート#

バージョン1.16以降、オペレーターは、オフライン移行を使用して、Kubernetesの新しいCloudNativePG Cluster に既存のPostgresデータベースをインポートする宣言的方法を提供します。同じ機能は、PostgreSQLデータベースのオフラインメジャーアップグレードもカバーしています。オフラインとは、データベースがインポートされるまで、アプリケーションがソースで書き込み操作を停止する必要があることを意味します。この機能は、 initdb ブートストラップ方法を拡張して、別のPostgreSQLデータベースで使用可能なデータの論理スナップショットを使用して、新しいPostgreSQLクラスターを作成します。これらのデータベースには、スーパーユーザー接続を介してネットワーク経由でアクセスできます。インポートは、Postgresのサポートされているバージョンからであり、オペレーションのすべてのデータベース部分、および要求に応じてロールの新しいクラスタープライマリから実行されるpg_dump およびpg_restore に依存しています。

PostGISクラスター#

CloudNativePGは、

PostGISクラスター を使用したクラスターのインストールをサポートしています

地理データベース用のオープンソース拡張機能。PostgreSQLで最も人気のある拡張機能の1つです。

PostgreSQLの基本的なLDAP認証#

オペレーターを使用すると、 PostgreSQL documentation: LDAP authentication で説明しているように、 シンプルバインド または search+bind モードを使用して、PostgreSQLクライアントのLDAP認証を構成できます。

複数のインストール方法#

オペレーターは、kubectl apply を介してKubernetesマニフェストを介してインストールでき、パブリックおよびプライベートクラウド環境での従来のKubernetesインストールで使用できます。さらに、CloudNativePGは、OperatorHub.ioからのHelm ChartまたはOLMバンドルを介したインストールをサポートしています。

構成より規約#

オペレーターは、構成上の規則パラダイムをサポートし、標準のデフォルト値を決定しながら、オーバーライドしてカスタマイズできます。いくつかのYAMLコード行でCluster CRDを使用して、PostgreSQLクラスターのデプロイメントを指定できます。

レベル2:シームレスなアップグレード#

機能レベル2は、 オペレーターと実際のワークロードの更新 、この場合はPostgreSQLサーバーを有効にすることに関するものです。これには、 PostgreSQLマイナーリリース更新 通常はセキュリティとバグ修正と メジャーオンラインアップグレード が含まれます。

オペレーターのアップグレード#

オペレーターを新しい展開としてシームレスにアップグレードできます。インスタンスマネージャーのインジェクションのおかげで、演算子の変更はオペランドの変更を必要としません。オペレーターは、オペランドの古いバージョンを管理できます。

CloudNativePGは インスタンスマネージャーのインプレース更新 もサポート

オペレーターのアップグレード後。インプレース更新では、クラスターのローリング更新とその後のスイッチオーバーを必要としません。

管理対象ワークロードのアップグレード#

CR、特にimageName パラメーターの変更の一部として、宣言的構成アプローチを使用してオペランドをアップグレードできます。オペレーターは、PostgreSQLのメジャーアップグレードを防止しながら、メジャーバージョン内のマイナーPostgreSQLリリースの点で両方向に進むことを可能にします更新とロールバックを有効にします。

スタンバイサーバーが存在する場合、オペレーターは、既存のポッドをドロップし、基になるストレージを再利用する新しい要求されたオペランドイメージで新しいポッドを作成することにより、レプリカから開始するローリング更新を実行します。 primaryUpdateStrategy の値に応じて、オペレーターは元のプライマリunsupervised を更新する前にスイッチオーバーを続行するか、ユーザーがkubectl のcnpg プラグインを介してスイッチオーバープロシージャsupervised を手動で発行するのを待ちます。この操作は、実際のデータベースのワークロードに基づいて、アプリケーションのダウンタイムを生成する可能性があるため、どの設定を使用するかはビジネス要件によって異なります。

アップグレード中にクラスターの可用性ステータスを表示する#

任意の時点で、クラスターの高可用性ステータスたとえば、 Setting up primary 、Creating a new replica 、Cluster in healthy state 、Switchover in progress 、Failing over 、Upgrading cluster などを伝えます。

レベル3:完全なライフサイクル#

機能レベル3では、オペレーターは 事業継続性 と スケーラビリティー の側面を管理する必要があります。 ディザスターリカバリー は、データベースのバックアップとリカバリーの両方が正常に動作することを必要とするビジネス継続コンポーネントです。出発点として、目標はRPO < 5分を達成することですが、長期的な目標はRPO=0のバックアップソリューションを実装することです。 高可用性 は、事業継続のもう1つの重要なコンポーネントであり、PostgreSQLネイティブ物理レプリケーションとホットスタンバイレプリカを介して、オペレーターがフェールオーバーとスイッチオーバー操作を実行できます。この領域には、次の機能の強化が含まれます。

  • 同期レプリケーション、カスケードレプリケーションクラスターなどのPostgreSQL物理レプリケーションの制御。

  • 接続プーリング pgBouncerを使用した接続プーリングレイヤーを介してパフォーマンスと制御を向上させます。

PostgreSQL WALアーカイブ#

オペレーターは、オブジェクトストアAWS S3およびS3互換、Azure Blob Storage、Google Cloud Storage、およびMinIOのようなゲートウェイへのWALファイルのPostgreSQL継続的アーカイブをサポートしています。

WALアーカイブは、クラスター定義のbackup パラメーターを介して、S3プロトコルの宛先URLたとえば、AWS S3バケットの特定のフォルダーをポイントし、オプションで汎用エンドポイントを指定することにより、クラスターレベルで宣言的に定義されますURL。

継続的バックアップの前提条件であるWALアーカイブは、ユーザーからの追加アクションを必要としません。オペレーターは、barman-cloud-wal-archive に依存するようにarchive_command を自動的に透過的に設定して、定義されたエンドポイントにWALファイルをシップします。ユーザーは、圧縮アルゴリズムと、アーカイブにWALファイルを同時にアップロードする並列ジョブの数を決定できます。それに加えて、 Instance Manager は、WALファイルの最初のセットの出荷を開始する前にbarman-cloud-check-wal-archive コマンドを実行することにより、アーカイブの宛先の正しさを自動的にチェックします。

PostgreSQLのバックアップ#

オペレーターは、物理ベースのバックアップと継続的なWALアーカイブに基づいたPostgreSQLのネイティブ継続的ホットバックアップテクノロジーを使用して、アプリケーションレベルのバックアップを提供するように設計されています。ベースバックアップは次の場所に保存できます。

  • Kubernetesボリュームスナップショット

  • オブジェクトストアAWS S3およびS3互換、Azure Blob Storage、Google Cloud Storage、およびMinIOのようなゲートウェイ

ベースバックアップは、クラスター定義のbackup パラメーターを介して、クラスターレベルで宣言的に定義されます。

ベースバックアップは2つの方法で定義できます。オンデマンド Backup カスタムリソース定義を介して またはスケジュール ScheduledBackup カスタムリソース定義を介して、 cronのような構文を使用します。

ボリュームスナップショットは、この機能を基になるストレージクラスとCSIドライバーに委任するKubernetes APIに直接依存しています。ボリュームスナップショットバックアップは、非常に大規模なデータベースVLDBコンテキストに適しています。

オブジェクトストアのバックアップは、ジョブアプリケーションコンテナイメージの一部として配布のbarman-cloud-backup に依存して、WALファイルと同じエンドポイントでバックアップを中継します。

barman-cloud-wal-restore とbarman-cloud-backup は両方とも、GNU GPL 3条件に基づいてアプリケーションコンテナイメージで配布されます。

オブジェクトストアのバックアップは、PostgreSQLの稼働中に実行されますホットバックアップ。ボリュームスナップショットバックアップは、現在PostgreSQLがシャットダウンされた後に取得されますコールドバックアップ。これは、オンラインボリュームスナップショットバックアップのサポートにより、将来的に変わります。

スタンバイからのバックアップ#

オペレーターは、データベースのRPOに影響を与えることなく、ベースバックアップのスタンバイへのオフロードをサポートします。これにより、プライマリのリソース、特に標準のデータベース操作のためにI/Oを保持できます。

バックアップからの完全な復元#

オペレーターを使用すると、ボリュームスナップショットまたはオブジェクトストア内の既存のアクセス可能なバックアップから新しいクラスターとその設定をブートストラップできます。

ブートストラッププロセスが完了すると、オペレーターはリカバリモードでインスタンスを起動し、指定されたアーカイブから使用可能なすべてのWALファイルを再生し、リカバリを終了してプライマリとして起動します。次に、オペレーターは、要求された数のスタンバイインスタンスをプライマリからクローン作成します。 CloudNativePGは、アーカイブからの並列WAL取得をサポートしています。

バックアップからのポイントインタイムリカバリーPITR#

オペレーターを使用すると、既存のバックアップをタイムスタンプ、ラベル、またはトランザクションIDで定義された特定のポイントインタイムにリカバリーすることにより、新しいPostgreSQLクラスターを作成できます。この機能は、完全なリストアのものの上に構築され、

PostgreSQL for PITR で使用可能なすべてのオプションをサポートしています。

同期レプリケーションを介したゼロデータ損失クラスター#

クォーラムベースの同期レプリケーションサポートを介して、ローカルの高可用性CloudNativePGクラスターで ゼロデータ損失 RPO=0を達成します。オペレーターは、いつでも使用可能な予想同期スタンバイレプリカの最小および最大数を制御する2つの構成オプションを提供します。オペレーターは、クラスター内の使用可能な準備ができているPostgreSQLインスタンスの数に基づいて、次のクォーラム q の式を介して、それに応じて反応します。

1 <= minSyncReplicas <= q <= maxSyncReplicas <= readyReplicas

レプリカクラスター#

PostgreSQLのネイティブストリーミングとカスケードレプリケーションを利用して、PostgreSQLクラスターのクロスKubernetesクラスタートポロジを定義します。 replica オプションを介して、同じメジャーバージョンの別のPostgreSQLソースからデータを継続的にレプリケートするように独立したクラスターをセットアップできます。このようなソースは、2つのエンドポイントからTLSを介した直接ストリーミング接続が許可されている限り、どこにでもあります。さらに、ソースはKubernetesの外部で、物理的または仮想環境で実行されている場合もあります。レプリカクラスターは、ボリュームスナップショット、リカバリオブジェクトストアBarman Cloudフォーマットでのバックアップから、またはpg_basebackup を介したストリーミングを介して作成できます。 WALファイルのシッピングとWALストリーミングの両方が許可されます。レプリカクラスターは、KubernetesのPostgreSQLデータベースのビジネス継続体制を劇的に向上させ、マルチプルのデータセンターにまたがり、ハイブリッドおよびマルチクラウドセットアップの扉を開きます。現在、Kubernetesフェデレーションネイティブ機能を待機している間、データセンター間の手動スイッチオーバーが必要です。

Livenessおよびreadnessプローブ#

オペレーターは、kubeletによって呼び出されるPostgresコンテナのlivenessプローブとreadnessプローブを定義します。これらは、インスタンスマネージャーによって直接管理されるWebサーバーの/healthz および/readyz エンドポイントにそれぞれマッピングされます。 livenessプローブはpg_isready 実行可能ファイルに基づいており、ポッドは正常であると考えられ、終了コード0サーバーは通常に接続を受け入れますおよび1サーバーは起動中などに接続を拒否しています。準備状況プローブは、単純なクエリー; を発行して、サーバーが接続を受け入れる準備ができていることを確認します。

ローリング展開#

オペレーターは、ダウンタイムを最小限に抑えるためにローリング展開をサポートし、PostgreSQLクラスターが公開されている場合、サービスは初期化または更新中に使用可能なポッドにのみ読み取り専用トラフィックをロードバランシングします。

レプリカのスケールアップとスケールダウン#

演算子を使用すると、PostgreSQLクラスター内のインスタンスの数をスケールアップおよびダウンできます。新しいレプリカはプライマリサーバーから自動的に起動され、クラスターのHAインフラストラクチャに参加します。 CRDは、ユーザーがkubectl scale コマンドを使用できるようにする「scale」サブリソースを宣言します。

KubernetesノードのメンテナンスウィンドウとPodDisruptionBudget#

オペレーターはPodDisruptionBudget リソースを作成して、同時中断数を1つのプライマリインスタンスに制限します。この構成により、メンテナンス操作でクラスター内のすべてのポッドが削除されるのを防ぎ、指定された数のインスタンスを作成できます。 PodDisruptionBudgetは、ノードのドレイン操作中に適用され、クラスターサービスの中断を防ぎます。

この戦略は、ストレージがすべてのワーカーノードで共有されるKubernetesクラスターには正しいですが、ローカルストレージを使用するクラスター、またはプライベートクラウドにインストールされたクラスターには、最適なソリューションではない場合があります。オペレーターを使用すると、メンテナンスウィンドウを指定し、基になるノードのエビクションへの反応を構成できます。メンテナンスウィンドウセクションのReusePVC オプションを使用すると、使用する戦略を指定できます。追い出されたインスタンスの別のPVCに新しいストレージを割り当てるか、基になるノードが再び利用可能になるのを待ちます。

フェンシング#

フェンシングは、PostgreSQLクラスターの1つ以上、またはすべてのインスタンスに障害があると思われる場合に、データを保護するプロセスです。インスタンスがフェンスされると、PostgreSQLサーバープロセスは保証的にシャットダウンされますが、ポッドは実行されたままです。これにより、フェンスが解除されるまで、ポッド上のデータがPostgreSQLによって変更されず、デバッグとトラブルシューティングの目的でファイルシステムを調査できることが保証されます。

ハイバネーション宣言的#

CloudNativePGは hibernation of a running PostgreSQL cluster をサポート

cnpg.io/hibernation アノテーションを介して宣言的な方法で。ハイバネーションでは、データベースPVCを維持したままデータベースポッドを削除することにより、CPUパワーを節約できます。この機能は、0インスタンスへのスケーリングをシミュレートします。

ハイバネーション(必須)#

CloudNativePGは hibernation of a running PostgreSQL cluster をサポート

cnpg プラグインを介して。ハイバネーションは、高可用性クラスター内のすべてのPostgresインスタンスをシャットダウンし、 PGDATA およびWALを含むプライマリのPVCグループの静的コピーを保持します。プラグインは、プライマリを再開し、すべてのレプリカが存在する場合を再作成することにより、ハイバーネーションフェーズを終了できます。

ポッドの永続ボリュームストレージの再利用#

ユーザーが削除したポッド、またはKubernetesメンテナンスオペレーションによって削除されたポッドをオペレーターが作成する必要がある場合、利用可能な場合はPersistentVolumeClaim を再利用し、プライマリからデータを再クローンする必要がありません。

CPUとメモリの要求と制限#

オペレーターを使用すると、管理者は、マニフェストのresources セクションを介して、クラスターのポッドによるリソースの使用を制御および管理できます。特に requests およびlimits 値は、CPUとRAMの両方に設定できます。

PgBouncerを使用した接続プーリング#

CloudNativePGは、 PostgreSQLで最も人気のあるオープンソース接続プーラーの1つである

PgBouncerIntegrationStatus {postgresql-cnpg-io-v1-PgBouncerIntegrationStatus}

を使用した接続プーリングのネイティブサポートを提供します。アーキテクチャの観点から、PgBouncer接続プーラーのネイティブ実装は、データベースにアクセスするための新しいレイヤーを導入します。これにより、インスタンスへのクエリフローが最適化され、基になるPostgreSQLリソースの使用がより効率的になります。 PostgreSQLサービスに直接接続する代わりに、アプリケーションはPgBouncerサービスに接続し、既存の接続の再利用を開始できるようになりました。

レベル4 深い洞察#

機能レベル4は、 可観測性 、特にモニタリング、アラート、トレンド、ログ処理に関するものです。これには、Prometheus、Grafana、Fluent Bitなどの外部ツール、およびJSON形式で直接エラーログを出力するためのPostgreSQLエンジンの拡張機能の使用が含まれる場合があります。

CloudNativePGは、柔軟なモニタリングとロギングのための業界標準およびコミュニティで認められたツールと簡単に統合するために必要なすべてを提供するように設計されています。

構成可能なクエリを備えたPrometheusエクスポータ#

インスタンスマネージャーは、プラグ可能なフレームワークを提供し、 metrics ポート 9187でリッスンする独自のWebサーバーを介して、

Prometheus モニタリングおよびアラートツールのメトリックをエクスポートするエンドポイントを公開します。オペレーターは、 postgres_exporter と互換性のある構文を使用して、 ConfigMap

および/またはSecret オブジェクトとして定義されたカスタムモニタリングクエリーをサポートします。 CloudNativePGは、コンテキストに統合して適応できるPostgreSQLの基本的なモニタリングクエリセットを提供します。

JSON形式のPostgreSQLエラーメッセージの標準出力ログ#

すべてのログメッセージは、タイムスタンプの第1レベル定義、ログレベル、正規のPostgreSQLエラーメッセージチャネルのpostgres などのログエントリのタイプを含むJSON形式で標準出力に配信されます。その結果、CloudNativePGによって管理されるすべてのポッドは、ソースデータ型としてJSONをサポートするダウンストリームログ処理スタックと簡単かつ直接統合できます。

リアルタイムクエリモニタリング#

CloudNativePGは以下を透過的かつネイティブにサポートします。

  • 必須の pg_stat_statements 、PostgreSQLサーバーによって実行されるすべてのSQLステートメントの計画と実行統計の追跡を有効にします。

  • auto_explain は、 EXPLAIN を手動で実行せずに、遅いステートメントの実行プランを自動的にログに記録する手段を提供します最適化されていないクエリーを追跡するのに役立ちます。

  • pg_failover_slots 物理的フェールオーバーにわたって論理レプリケーションスロットを使用できるようにし、PostgreSQLのネイティブ論理レプリケーションに基づいて変更データキャプチャCDCコンテキストの復元力を保証します。

監査#

CloudNativePGを使用すると、データベースとセキュリティの管理者、監査人、およびオペレーターは、 PGAudit PostgreSQLの場合を使用してデータベースアクティビティを追跡および分析できます。このようなアクティビティはJSONログで直接フローし、Fluentdのような一般的なログブローカーを使用して正しいダウンストリームターゲットに適切にルーティングできます。

Kubernetesイベント#

リソースの作成、ノードの削除、アップグレードなど、Kubernetes APIが想定するメジャーイベントを記録します。イベントは、 kubectl describe およびkubectl get events コマンドを使用して表示できます。

レベル5 オートパイロット#

機能レベル5は、オブザーバビリティレイヤーから現れた異常と洞察の発見を介して、 自動スケーリング 、 ヒーリング 、および チューニング に焦点を当てています。

自己修復のための自動フェイルオーバー#

プライマリで障害が検出された場合、オペレーターは、最も調整されたレプリカを新しいターゲットプライマリとして設定することにより、クラスターのステータスを変更します。その結果、各生きているポッドのインスタンスマネージャーは、新しいプライマリになるか、それに従うことにより、クラスターの要求されたステータスに自分自身を合わせるために必要な手順を開始します。元のプライマリが復旧した場合、同じメカニズムにより、アプリケーションがそれに到達しないようにし、サーバーでpg_rewind を実行し、スタンバイとして再起動することにより、スプリットブレインを回避します。

スタンバイの自動再作成#

スタンバイをホスティングするポッドが削除された場合、オペレーターは、スタンバイサーバーを再作成する手順を開始します。