オペレーターの能力レベル¶
- このセクションでは、
Operator SDK definition of Capability Levels を使用して分類された、CloudNativePGによって実装される機能の概要を提供します
フレームワーク。
Operator Capability Levels¶
重要
Operator Capability Levels model に基づいて 、 CloudNativePG Operatorからの**「レベルV - オートパイロット」**セットの機能を期待できます。
各機能レベルは、オペレーターが提供する特定の管理機能セットに関連付けられています。
1.基本インストール
2.シームレスなアップグレード
3.フルライフサイクル
4.深い洞察
5.オートパイロット
注釈
このフレームワークは、オペレーターでの将来の作業と実装のガイドと見なされます。
レベル1：基本インストール¶
能力レベル1には、オペレーターの インストール と 構成 が含まれます。このカテゴリには、オペレーターやPostgreSQLクラスター構成との対話方法の改善など、使いやすさとユーザーエクスペリエンスの強化が含まれます。
重要
このレベルの**情報セキュリティ**部分を検討します。
宣言型構成によるオペレーターの展開¶
オペレーターは、4つの主要なCustomResourceDefinition
オブジェクトを定義するKubernetesマニフェストを使用して、宣言的な方法でインストールされます。Cluster
、Pooler 、Backup 、およびScheduledBackup 。
宣言構成による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 より大きい場合、オペレーターはinstances -1
レプリカを管理します。これには、自動フェイルオーバーによる高可用性（HA）とスイッチオーバー操作によるローリング更新が含まれます。
CloudNativePGは、 Failover slots
と呼ばれるPostgreSQL用に以前に提案されたパッチに触発された実装を使用して、HAクラスター内のすべてのレプリカのレプリケーションスロットを自動的に管理します。
データベース構成¶
オペレーターは、単一のデータベースで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インスタンスに必要な変更を適用して、クラスターの必要なステータスに収束します（例：クラスターステータスがレポートそのpod
-1 がプライマリであり、pod -1
は自分自身を昇格させる必要がありますが、他のPodはpod -1
に従う必要があります）。同じステータスは、 kubectl のcnpg
プラグインによって使用され、詳細を提供します。
オペレーターの認証局¶
オペレータは、自分用の認証局を自動的に作成します。 Kubernetes APIサーバーとオペレーター自分自身の間の安全な通信を保証するために、Webhookサーバーが使用するリーフ証明書を作成してオペレーター認証局と署名します。
クラスターの認証局¶
オペレーターは、すべてのPostgreSQLクラスターに認証局を自動的に作成します。これは、ストリーミングレプリケーションスタンバイサーバー（パスワードの代わり）を含む、クライアントの認証用のTLS証明書の発行および更新に使用されます。クライアント証明書のカスタム認証局のサポートは、シークレットを介して利用できます。これには、cert-managerとの統合も含まれます。
kubectl のcnpg プラグインを使用して、証明書を発行できます。
TLS接続¶
オペレーターは、TLS / SSL接続を透過的かつネイティブにサポートし、クラスターの認証局を使用してセキュリティを強化するためにクライアント/サーバー通信を暗号化します。カスタムサーバー証明書のサポートは、シークレットを介して利用できます。これには、cert-managerとの統合も含まれます。
ストリーミングレプリケーションの証明書認証¶
オペレーターは、パスワード（したがってシークレット）に依存する代わりに、TLSクライアント証明書認証に依存して、スタンバイサーバーからのストリーミングレプリケーション接続を承認します。
継続的な構成管理¶
オペレーターを使用すると、PostgreSQL構成のCluster
リソースYAMLセクションに変更を適用でき、構成オプションに応じて、すべてのインスタンスが適切にリロードまたは再起動されます。
現在の制限： ALTER SYSTEM
による変更は検出されません。つまり、クラスターの状態は強制されません。
既存のPostgreSQLデータベースのインポート¶
バージョン1.16以降、オペレーターは、オフライン移行を使用して、既存のPostgresデータベースをKubernetesの新しいCloudNativePG
Cluster
にインポートする宣言的な方法を提供します。同じ機能は、PostgreSQLデータベースのオフラインメジャーアップグレードもカバーします。オフラインは、データベースがインポートされるまで、アプリケーションがソースで書き込み操作を停止する必要があることを意味します。この機能は、
initdb
ブートストラップメソッドを拡張し、別のPostgreSQLデータベースで利用可能なデータの論理スナップショットを使用して新しいPostgreSQLクラスターを作成します。これは、スーパーユーザー接続を介してネットワーク経由でアクセスできます。
ImportはサポートされているバージョンのPostgresからであり、 pg_dump
およびpg_restore
に依存して、オペレーションのすべてのデータベース部分、および要求された場合はロールの新しいクラスタープライマリから実行されます。
PostGISクラスター¶
- CloudNativePGは、
PostGISクラスター を使用したクラスターのインストールをサポートしています
地理データベースのオープンソース拡張機能であり、PostgreSQLの最も一般的な拡張機能の1つです。
PostgreSQLの基本LDAP認証¶
オペレーターを使用すると、 PostgreSQL documentation: LDAP authentication で説明されているように、 シンプルバインド または 検索+バインド モードを使用して、PostgreSQLクライアントのLDAP認証を構成できます。
複数のインストール方法¶
オペレーターは、 kubectl apply
を介してKubernetesマニフェストを介してインストールし、パブリックおよびプライベートクラウド環境の従来のKubernetesインストールで使用できます。さらに、オペレーター用のHelm
Chartも利用できます。
構成よりも規約¶
オペレーターは、構成パラダイムに対する規約をサポートし、標準のデフォルト値を決定しながら、オーバーライドおよびカスタマイズを許可します。数行の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アーカイブに基づいたPostgreSQLのネイティブ継続的ホットバックアップテクノロジーを使用して、アプリケーションレベルのバックアップを提供するように設計されています。具体的には、オペレーターは現在、オブジェクトストア（AWS S3およびS3互換、Azure Blob Storage、Google Cloud Storage、およびMinIOなどのゲートウェイ）でのバックアップのみをサポートしています。
WALアーカイブとベースバックアップは、クラスターレベルで宣言的に定義され、クラスター定義のbackup
パラメーターを介して、S3プロトコルの宛先URLを指定し（たとえば、AWS
S3バケット内の特定のフォルダーをポイントします）、オプションで、汎用エンドポイントURL。継続的バックアップの前提条件であるWALアーカイブは、ユーザーからのさらなるアクションを必要としません。オペレーターは、定義されたエンドポイントにWALファイルを出荷するためにbarman-cloud-wal-archive
に依存するようにarchive_command
を自動的かつ透過的に設定します。ユーザーは、圧縮アルゴリズムと、アーカイブ内のWALファイルを同時にアップロードする並列ジョブの数を決定できます。それに加えて、Instance Manager
は、WALファイルの最初のセットの出荷を開始する前にbarman-cloud-check-wal-archive
コマンドを実行することにより、アーカイブ先の正確性を自動的にチェックします。
オンデマンド（ Backup
カスタムリソース定義を介して）またはスケジュール（cronのような構文を使用して、
ScheduledBackup
カスタマーリソース定義を介して）の2つの方法でベースバックアップを定義できます。どちらもジョブ（アプリケーションコンテナイメージの一部として配布）をbarman-cloud-backup
に依存して、WALファイルとともに同じエンドポイントでバックアップを中継します。
barman-cloud-wal-restore とbarman-cloud-backup の両方は、GNU
GPL 3条件の下でアプリケーションコンテナイメージで配布されます。
スタンバイからのバックアップ¶
オペレーターは、データベースのRPOに影響を与えることなく、スタンバイへのベースバックアップのオフロードをサポートします。これにより、標準のデータベース操作のために、プライマリのリソース、特にI/Oを保持できます。
バックアップからの完全復元¶
オペレーターを使用すると、 barman-cloud-backup
を使用して取得されたアクセス可能な既存のバックアップから開始して、新しいクラスター（その設定）をブートストラップできます。ブートストラッププロセスが完了すると、オペレーターはインスタンスをリカバリモードで起動し、指定されたアーカイブから使用可能なすべてのWALファイルをリプレイし、リカバリを終了してプライマリとして起動します。その後、オペレーターは、プライマリから要求された数のスタンバイインスタンスを複製します。
CloudNativePGは、アーカイブからの並列WALフェッチをサポートしています。
バックアップからのポイントインタイムリカバリ（PITR）¶
- オペレーターを使用すると、既存のバックアップをタイムスタンプ、ラベル、またはトランザクションIDで定義された特定のポイントインタイムに復元することにより、新しいPostgreSQLクラスターを作成できます。この機能は、完全復元の上に構築され、
PostgreSQL for PITR で使用可能なすべてのオプションをサポートします。
同期レプリケーションによるゼロデータ損失クラスター¶
クォーラムベースの同期レプリケーションサポートにより、ローカル高可用性CloudNativePGクラスターで
ゼロデータ損失 (RPO =
0)を達成します。オペレーターは、いつでも使用可能な予想される同期スタンバイレプリカの最小数と最大数を制御する2つの構成オプションを提供します。オペレーターは、クォーラム（q
）の次の式を使用して、クラスター内の使用可能で準備ができているPostgreSQLインスタンスの数に基づいて、それに応じて反応します。
1 <= minSyncReplicas <= q <= maxSyncReplicas <= readyReplicas
レプリカクラスター¶
PostgreSQLのネイティブストリーミングおよびカスケードレプリケーションを利用して、PostgreSQLクラスターのクロスKubernetesクラスタートポロジを定義します。
replica
オプションを使用すると、独立したクラスターをセットアップして、同じメジャーバージョンの別のPostgreSQLソースからデータを継続的に複製できます。このようなソースは、2つのエンドポイントからのTLS経由の直接ストリーミング接続が許可されている限り、どこにあってもかまいません。さらに、ソースはKubernetesの外部にあっても、物理環境または仮想環境で実行できます。レプリカクラスターは、回復オブジェクトストア（
Barman Cloud形式のバックアップ）から、またはpg_basebackup
を介したストリーミングを介して作成できます。
WALファイルシッピングとWALストリーミングの両方が許可されています。レプリカクラスターは、マルチプルのデータセンターにまたがり、ハイブリッドおよびマルチクラウドのセットアップを可能にする、Kubernetes内のPostgreSQLデータベースのビジネス継続性態勢を劇的に向上させます（現在、Kubernetesフェデレーションネイティブ機能を待っている間、データセンター間の手動スイッチオーバーが必要です）。
LivenessとReadinessプローブ¶
オペレーターは、Postgresコンテナのlivenessプローブとreadinessプローブを定義し、kubeletによって呼び出されます。これらは、インスタンスマネージャーによって直接管理されるWebサーバーの/healthz
および/readyz エンドポイントにそれぞれマップされます。
livenessプローブはpg_isready
実行可能ファイルに基づいており、ポッドは正常であると見なされ、終了コード0（サーバーは通常に接続を受け入れます）および1（サーバーは、たとえば起動中にサーバーが接続を拒否します）で終了します。
readinessプローブは、単純なクエリ（;
）を発行して、サーバーが接続を受け入れる準備ができていることを確認します。
ローリングデプロイメント¶
オペレーターは、ダウンタイムを最小限に抑えるためのローリングデプロイをサポートしています。 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を維持しながらデータベースのPodを削除することにより、CPUの電力を節約できます。この機能は、0インスタンスへのスケーリングをシミュレートします。
ハイバネーション（必須）¶
CloudNativePGは hibernation of a running PostgreSQL cluster をサポート
cnpg
プラグインを介して。ハイバネーションは、高可用性クラスター内のすべてのPostgresインスタンスをシャットダウンし、
PGDATA
とWALを含むプライマリのPVCグループの静的コピーを保持します。プラグインを使用すると、プライマリを再開してからすべてのレプリカを再作成することにより、ハイバーネーションフェーズを終了できます。
Podでの永続ボリュームストレージの再利用¶
オペレーターが、ユーザーによって削除された、またはKubernetesメンテナンスオペレーションによってエビクトされたポッドを作成する必要がある場合、
PersistentVolumeClaim
利用可能な場合は再利用し、プライマリからデータを再クローンする必要を回避します。
CPUとメモリのリクエストと制限¶
オペレーターは、管理者がマニフェストの resources
セクションを介して、クラスターのポッドによるリソース使用量を制御および管理できるようにします。特に、
requests およびlimits の値は、CPUとRAMの両方に設定できます。
PgBouncerを使用した接続プーリング¶
- CloudNativePGは、PostgreSQL用の最も一般的なオープンソース接続プーラーの1つである
を使用した接続プーリングのネイティブサポートを提供します。アーキテクチャの観点からは、 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エラーメッセージの標準出力ロギング¶
すべてのログメッセージは、タイムスタンプ、ログレベル、および正規のPostgreSQLエラーメッセージチャネルの
postgres
などのログエントリのタイプの第1レベルの定義とともに、JSON形式で標準出力に配信されます。その結果、CloudNativePGによって管理されるすべてのPodを、ソースデータタイプとしてJSONをサポートするダウンストリームのログ処理スタックと簡単かつ直接統合できます。
リアルタイムクエリモニタリング¶
CloudNativePGは、以下を透過的かつネイティブにサポートします。
重要な :ref:``pg_stat_statements` を有効にする<pg_stat_statements を有効にする>` 。PostgreSQLサーバーによって実行されるすべてのSQLステートメントの計画および実行統計の追跡を可能にします。
:ref:
auto_explain` を有効にする<`auto_explain` を有効にする>` 、 ``EXPLAIN
を手動で実行せずに、遅いステートメントの実行計画を自動的にログに記録する手段を提供します（最適化されていないクエリを追跡するのに役立ちます）。
:ref:``pg_failover_slots` を有効にする<pg_failover_slots を有効にする>`
、論理レプリケーションスロットを物理フェイルオーバー全体で使用可能にし、PostgreSQLのネイティブ論理レプリケーションに基づいた変更データキャプチャ（CDC）コンテキストでの回復力を保証します。
監査¶
CloudNativePGを使用すると、データベースとセキュリティの管理者、監査人、オペレーターは、PGAudit（PostgreSQL用）を使用してデータベースアクティビティを追跡および分析できます。このようなアクティビティはJSONログ内を直接流れ、Fluentdなどの一般的なログブローカーを使用して、適切なダウンストリームターゲットに適切にルーティングできます。
Kubernetesイベント¶
リソースの作成、ノードの削除、アップグレードなど、Kubernetes
APIで予想される主要なイベントを記録します。イベントは、
kubectl describe およびkubectl get events
コマンドを使用して表示できます。
レベル5：オートパイロット¶
機能レベル5は、オブザーバビリティレイヤーから浮上した異常と洞察の発見を通じて、 自動スケーリング 、 修復 、および チューニング に焦点を当てています。
自己修復のための自動フェールオーバー¶
プライマリで障害が検出された場合、オペレーターは、最もアラインされたレプリカを新しいターゲットプライマリとして設定することにより、クラスターのステータスを変更します。その結果、各生きているポッドのインスタンスマネージャーは、新しいプライマリになるか、それに従うことにより、クラスターの要求されたステータスに自分自身を調整するために必要な手順を開始します。元のプライマリが復旧した場合、同じメカニズムにより、アプリケーションがプライマリに到達できないようにし、サーバーでpg_rewind
を実行し、スタンバイとして再起動することにより、スプリットブレインを回避します。
スタンバイの自動再作成¶
スタンバイをホスティングしているポッドが削除された場合、オペレーターはスタンバイサーバーを再作成する手順を開始します。
