オペレーターの能力レベル¶
このセクションでは、 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
オブジェクト、Cluster 、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
と、コンテナーイメージの不変性をより細かく制御するためのタグもサポートしています。
ラベルとアノテーション¶
オペレーターは、クラスターのメタデータで定義されたラベルとアノテーションの継承をサポートするように構成できます。
自己完結型のインスタンスマネージャー¶
オペレーターは、PatroniやStolonなどの外部ツールを使用してKubernetesクラスターポッド内のPostgreSQLインスタンスを調整する代わりに、各ポッド内の/controller/manager
という名前のファイルにオペレーター実行可能ファイルを挿入します。このアプリケーションは、基になるPostgreSQLインスタンスを制御し、PostgreSQLクラスタートポロジに基づいてポッドのステータスをインスタンス自分自身と調整するために使用されます。インスタンスマネージャーは、プローブのkubelet
によって呼び出されるWebサーバーも起動します。 kubelet
によって呼び出されたUnixシグナルはインスタンスマネージャーによってフィルター処理され、必要に応じて、外部イベントへの高速で制御された反応のためにpostgres
プロセスに転送されます。インスタンスマネージャーはGoで作成されており、外部依存関係はありません。
ストレージ構成¶
ストレージは、データベース
ワークロードの重要なコンポーネントです。オペレーターは、ストレージの観点からKubernetesのネイティブ機能とリソースを利用するため、基盤となるKubernetes環境が提供できるものに基づいて、ワークロードの要件に適したストレージを選択するのに十分な柔軟性を提供します。これは、パブリッククラウド環境で特定のストレージクラスを選択するか、CRの
storage
パラメーターのPVCテンプレートを介して生成されたPVCを微調整することを意味します。
cnp-bench オープンソースプロジェクトを使用して、実稼働前にストレージとデータベースの両方をベンチマークできます。
レプリカ構成¶
オペレーターは、instances
と呼ばれる単一のパラメーターを使用して、クラスター内のレプリカを自動的に検出します。
1
に設定されている場合、クラスターはレプリカのない単一のプライマリPostgreSQLインスタンスで構成されます。
1 より大きい場合、オペレーターはinstances -1
レプリカを管理します。これには、自動フェイルオーバーによる高可用性とスイッチオーバー操作によるローリング更新が含まれます。
データベース構成¶
オペレーターは、単一のデータベースで PostgreSQL
クラスターを管理するように設計されています。オペレーターは、読み取り/書き込み、読み取り、読み取り専用のワークロード用に自動的にプロビジョニングおよび管理される
3 つの Kubernetes
サービスを使用して、データベースへのアクセスを透過的に管理します。構成よりも規約のアプローチを使用して、オペレーターはapp
というデータベースを作成します。デフォルトでは、同じ名前の通常のPostgresユーザーが所有します。必要に応じて、データベース名とユーザー名の両方を指定できます。クラスターを実行するための構成は必要ありませんが、CRの
postgresql
セクションでPostgreSQLランタイム構成とPostgreSQLホストベースの認証ルールの両方をカスタマイズできます。
ポッドセキュリティポリシー¶
InfoSec要件については、オペレーターはコンテナーの特権モードを必要とせず、読み取り専用のルートファイルシステムを適用して、オペレーターとオペランドポッドの両方に対してコンテナーの不変性を保証します。また、必要なセキュリティコンテキストを明示的に設定します。
アフィニティ¶
クラスターの affinity
セクションを使用すると、ポッドと、永続ボリュームなどの関連リソースをKubernetesクラスターのノード全体でスケジュールする方法を微調整できます。特に、オペレーターは以下をサポートしています。
ポッドアフィニティとアンチアフィニティ
ノードセレクター
テイントと寛容
コマンドラインインターフェース¶
CloudNativePGには、独自のコマンドラインインターフェイスがありません。
PostgreSQLクラスター管理エクスペリエンスを強化および簡素化するcnpg
というプラグインを提供することにより、Kubernetesに最適なコマンドラインインターフェイスであるkubectl
に依存しています。
クラスターの現在のステータス¶
オペレーターは、監視されたクラスターのステータスでCRのステータスセクションを継続的に更新します。
PostgreSQLクラスター全体のステータスは、各ポッドで実行されているインスタンスマネージャーによって継続的に監視されます。インスタンスマネージャーは、制御されたPostgreSQLインスタンスに必要な変更を適用して、クラスターの必要なステータスに収束します（例：そのpod
-1 はプライマリであり、pod -1
は自分自身を昇格させる必要がありますが、他のPodはpod -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以降、オペレーターは、オフライン移行を使用して、既存のPostgresデータベースをKubernetesの新しいCloudNativePG
Cluster
にインポートする方法を提供します。同じ機能は、PostgreSQLデータベースのオフラインのメジャーアップグレードもカバーしています。オフラインは、データベースがインポートされるまで、アプリケーションがソースで書き込み操作を停止する必要があることを意味します。この機能は、
initdb
ブートストラップメソッドを拡張して、別のPostgreSQLデータベースで利用可能なデータの論理スナップショットを使用して新しいPostgreSQLクラスターを作成します。これは、スーパーユーザー接続を介してアクセスできます。インポートはサポートされているバージョンのPostgresからであり、操作のすべてのデータベース部分、および要求された場合はロールに対して実行される新しいクラスタープライマリからのpg_dump
およびpg_restore に依存しています。
PostGISクラスター¶
CloudNativePGは、PostgreSQLの最も一般的な拡張機能の1つである地理データベース用の PostGISクラスター オープンソース拡張機能を使用したクラスターのインストールをサポートしています。
PostgreSQLの基本的なLDAP認証¶
オペレーターを使用すると、 PostgreSQL documentation: LDAP authentication で説明されているように、シンプルバインドまたは検索+バインドモードを使用して、PostgreSQLクライアントのLDAP認証を構成できます。
複数のインストール方法¶
Operatorは、 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条件に基づいてアプリケーションコンテナイメージで配布されます。
バックアップからの完全な復元¶
オペレーターを使用すると、 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
probeは pg_isready
実行可能ファイルに基づいており、ポッドは正常であると見なされ、終了コード0（サーバーは正常に接続を受け入れます）および1（サーバーは起動中などに接続を拒否しています）。
readinessプローブは、単純なクエリ（;
）を発行して、サーバーが接続を受け入れる準備ができていることを確認します。
ローリングデプロイメント¶
オペレーターは、ダウンタイムを最小限に抑えるためにローリングデプロイをサポートしています。PostgreSQLクラスターが公開されている場合、サービスは初期化または更新中に使用可能なポッドにのみ読み取り専用トラフィックを負荷分散します。
レプリカのスケールアップとスケールダウン¶
オペレーターを使用すると、PostgreSQL
クラスター内のインスタンスの数をスケールアップまたはスケールダウンできます。新しいレプリカはプライマリサーバーから自動的に起動され、クラスターの
HA インフラストラクチャに参加します。
CRDは、ユーザーがkubectl scale
コマンドを使用できるようにする「scale」サブリソースを宣言します。
KubernetesノードのメンテナンスウィンドウとPodDisruptionBudget¶
オペレーターは、 PodDisruptionBudget
リソースを作成して、同時中断の数を1つのプライマリインスタンスに制限します。この構成により、メンテナンスオペレーションでクラスター内のすべてのポッドが削除されるのを防ぎ、指定された数のインスタンスを作成できます。
PodDisruptionBudgetはノードのドレイン操作中に適用され、クラスターサービスの中断を防ぎます。
この戦略は、すべてのワーカーノードでストレージが共有される Kubernetes
クラスターには適していますが、ローカルストレージを使用するクラスターまたはプライベートクラウドにインストールされたクラスターには最適なソリューションではない場合があります。オペレーターを使用すると、メンテナンスウィンドウを指定し、基になるノードのエビクションへの反応を構成できます。メンテナンスウィンドウセクションのReusePVC
オプションを使用すると、使用する戦略を指定できます。削除されたインスタンスに新しいストレージを割り当てるか、基になるノードが再び使用可能になるまで待機します。
フェンシング¶
フェンシングとは、PostgreSQLクラスターの1つ、複数、またはすべてのインスタンスが誤動作している場合に、そのデータを保護するプロセスです。インスタンスがフェンスされると、ポッドの実行中にPostgreSQLサーバープロセスがシャットダウンされることが保証されます。これにより、フェンスが解除されるまで、ポッド上のデータがPostgreSQLによって変更されず、デバッグとトラブルシューティングの目的でファイルシステムを調査できます。
ポッドでの永続ボリュームストレージの再利用¶
オペレーターは、ユーザーによって削除されたポッド、または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の基本的なモニタリングクエリのセットを提供します。
[cnp-sandboxプロジェクト]は、いくつかの基本的なメトリックとダッシュボードの例を提供することにより、CloudNativePGをPrometheusおよびGrafanaと統合する方法を示すオープンソースのHelmチャートです。
JSON形式のPostgreSQLエラーメッセージの標準出力ログ¶
すべてのログメッセージは、タイムスタンプの第1レベルの定義、ログレベル、およびログエントリのタイプ（正規のPostgreSQLエラーメッセージチャネルの
postgres
など）とともに、JSON形式で標準出力に配信されます。その結果、CloudNativePGによって管理されるすべてのPodを、ソースデータタイプとしてJSONをサポートするダウンストリームのログ処理スタックと簡単かつ直接統合できます。
リアルタイムのクエリモニタリング¶
CloudNativePGは以下を透過的かつネイティブにサポートします。
重要な :ref:``pg_stat_statements` を有効にする<pg_stat_statements を有効にする>` 。PostgreSQLサーバーによって実行されるすべてのSQLステートメントの計画と実行の統計を追跡できます。
:ref:
auto_explain` を有効にする<`auto_explain` を有効にする>` 。 ``EXPLAIN
を手動で実行せずに、遅いステートメントの実行計画を自動的にログに記録する手段を提供します（最適化されていないクエリを追跡するのに役立ちます）。
監査¶
CloudNativePGを使用すると、データベースとセキュリティの管理者、監査人、オペレーターは、PGAudit（PostgreSQL用）を使用してデータベースアクティビティを追跡および分析できます。このようなアクティビティは JSON ログを直接流れ、Fluentd などの一般的なログブローカーを使用して適切なダウンストリームターゲットにルーティングできます。
Kubernetesイベント¶
リソースの作成、ノードの削除、アップグレードなど、Kubernetes
APIで予想される主要なイベントを記録します。イベントは、
kubectl describe およびkubectl get events
コマンドを使用して表示できます。
レベル5 - オートパイロット¶
機能レベル 5は、オブザーバビリティレイヤーから浮上した異常と洞察の発見を通じた、 自動スケーリング 、 修復 、および チューニング に焦点を当てています。
自己修復のための自動フェールオーバー¶
プライマリで障害が検出された場合、オペレーターは、最もアラインされたレプリカを新しいターゲットプライマリとして設定することにより、クラスターのステータスを変更します。その結果、各生きているポッドのインスタンスマネージャーは、新しいプライマリになるか、それに従うことにより、クラスターの要求されたステータスに自分自身を調整するために必要な手順を開始します。前のプライマリが復旧した場合、同じメカニズムにより、アプリケーションがプライマリに到達できないようにし、サーバーでpg_rewind
を実行し、スタンバイとして再起動します。
スタンバイの自動再作成¶
スタンバイをホストしているポッドが削除された場合、オペレーターはスタンバイサーバーを再作成する手順を開始します。
