Kubectl Plugin ============== .. raw:: html CloudNativePGは、Kubernetesでクラスターを管理するための\ ``kubectl`` のプラグインを提供します。 インストール ------------ さまざまな方法を使用して\ ``cnpg`` プラグインをインストールできます。 .. Note:: エアギャップシステムの場合、以前にダウンロードしたファイルを使用して、パッケージマネージャーを介したインストールが良いオプションである場合があります。 　 インストールスクリプトを介して ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ .. code:: sh curl -sSfL \ https://github.com/cloudnative-pg/cloudnative-pg/raw/main/hack/install-cnpg-plugin.sh | \ sudo sh -s -- -b /usr/local/bin DebianまたはRedHatパッケージを使用する ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `releases section of the GitHub repository `_ では、関心のあるリリースCloudNativePGオペレーターと同じまたは新しいリリースを選択してくださいに移動できます。その中には **Assets** セクションがあります。そのセクションには、さまざまなシステム用の事前ビルドパッケージが含まれています。その結果、標準の手順と手順に従って、システムにインストールできます。 Debianパッケージ ^^^^^^^^^^^^^^^^ たとえば、Intelベースの64ビットサーバーの場合、プラグインの1.28.0リリースをインストールしてみましょう。最初に、適切な\ ``.deb`` ファイルをダウンロードします。 .. code:: sh wget https://github.com/cloudnative-pg/cloudnative-pg/releases/download/v1.28.0/kubectl-cnpg_1.28.0_linux_x86_64.deb \ --output-document kube-plugin.deb 次に、スーパーユーザー権限で、 ``dpkg`` を使用してローカルファイルからインストールします。 .. code:: console $ sudo dpkg -i kube-plugin.deb Selecting previously unselected package cnpg. (Reading database ... 6688 files and directories currently installed.) Preparing to unpack kube-plugin.deb ... Unpacking cnpg (1.28.0) ... Setting up cnpg (1.28.0) ... RPMパッケージ ^^^^^^^^^^^^^ ``.rpm`` パッケージの例と同様に、Intel 64ビットマシンの1.28.0リリースをインストールしましょう。ファイル名を提供する\ ``--output`` フラグに注意してください。 .. code:: sh curl -L https://github.com/cloudnative-pg/cloudnative-pg/releases/download/v1.28.0/kubectl-cnpg_1.28.0_linux_x86_64.rpm \ --output kube-plugin.rpm 次に、スーパーユーザー権限を使用して、\ ``yum`` でインストールすると、使用する準備が整います。 .. code:: console $ sudo yum --disablerepo=* localinstall kube-plugin.rpm Failed to set locale, defaulting to C.UTF-8 Dependencies resolved. ==================================================================================================== Package Architecture Version Repository Size ==================================================================================================== Installing: cnpg x86_64 1.28.0 @commandline 20 M Transaction Summary ==================================================================================================== Install 1 Package Total size: 20 M Installed size: 78 M Is this ok [y/N]: y Arch LinuxユーザーリポジトリAURパッケージを使用する ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `AUR `_ からプラグインをインストールするには、次の手順を実行します。 .. code:: sh git clone https://aur.archlinux.org/kubectl-cnpg.git cd kubectl-cnpg makepkg -si または、お気に入りのAURヘルパー、たとえば `paru `_ を使用します。 .. code:: sh paru -S kubectl-cnpg Krewを使用する ^^^^^^^^^^^^^^ `Krew `_ を既にインストールしている場合は、単に実行できます。 .. code:: sh kubectl krew install cnpg プラグインの新しいバージョンがリリースされたら、次の方法で既存のインストールを更新できます。 .. code:: sh kubectl krew update kubectl krew upgrade cnpg Homebrewを使用する ^^^^^^^^^^^^^^^^^^ .. Note:: Homebrewコミュニティが `kubectl-cnpg plugin on Homebrew `_ の可用性を管理していることに注意してください。 　 `Homebrew `_ を既にインストールしている場合は、単に実行できます。 .. code:: sh brew install kubectl-cnpg プラグインの新しいバージョンがリリースされたら、次の方法で既存のインストールを更新できます。 .. code:: sh brew update brew upgrade kubectl-cnpg .. Note:: kubectlプラグインのオートコンプリートは、既にHomebrewによって管理されています。以下で説明する`kubectl_complete-cnpg` スクリプトを作成する必要はありません。 　 サポートされているアーキテクチャ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ CloudNativePGプラグインは、現在次のオペレーティングシステムとアーキテクチャ用にビルドされています。 - Linux - amd64 - arm 5/6/7 - arm64 - s390x - ppc64le - macOS - amd64 - arm64 - Windows - 386 - amd64 - arm 5/6/7 - arm64 オートコンプリートの設定 ^^^^^^^^^^^^^^^^^^^^^^^^ プラグインのオートコンプリートを構成するには、ヘルパーシェルスクリプトを現在のPATHにインストールする必要があります。後者に\ ``/usr/local/bin`` が含まれていると仮定すると、これは次のコマンドで実行できます。 .. code:: sh cat > kubectl_complete-cnpg < operator.yaml 上記のコマンドのフラグは、次の意味を持っています。 - ``-n king`` CNPGオペレーターを\ ``king`` 名前空間にインストールします - ``--version 1.23`` マイナーバージョン1.23の最新パッチバージョンをインストールします - ``--replicas 3`` 3つのレプリカを使用してオペレーターをインストールします - ``--watch-namespace "albert, bb, freddie"`` は、オペレーターに\ ``albert`` 、\ ``bb`` 、および\ ``freddie`` 名前空間の変更のみを監視させます ステータス ^^^^^^^^^^ ``status`` コマンドは、クラスターの現在のステータスの概要を提供します。 - **一般情報** クラスターの名前、PostgreSQLのシステムID、インスタンス数、現在のタイムライン、WAL内の位置 - **backup** リカバリー可能ポイント、およびプライマリまたはレプリカクラスターの場合は指定されたプライマリから\ ``pg_stat_archiver`` ビューによって返されるWALアーカイブステータス - **ストリーミングレプリケーション** プライマリインスタンスの\ ``pg_stat_replication`` ビューから直接取得した情報 - **instances** 各Postgresインスタンスに関する情報、各インスタンスマネージャーによって直接取得されます。スタンバイの場合、\ ``Current LSN`` フィールドは、リカバリー中に再生された最新のログ先行書き込みの場所リプレイLSNに対応します。 .. Note:: 上記のステータス情報は、異なる時間に異なる場所で取得されたため、わずかに一貫性のない戻り値が発生します。たとえば、メインヘッダーの`Current Write LSN` 場所は、2つの異なる時間間隔で取得されるため、インスタンスステータスの`Current LSN` フィールドとは異なる場合があります。 　 .. code:: sh kubectl cnpg status sandbox .. code:: output Cluster Summary Name: default/sandbox System ID: 7423474350493388827 PostgreSQL Image: ghcr.io/cloudnative-pg/postgresql:16.4 Primary instance: sandbox-1 Primary start time: 2024-10-08 18:31:57 +0000 UTC (uptime 1m14s) Status: Cluster in healthy state Instances: 3 Ready instances: 3 Size: 126M Current Write LSN: 0/604DE38 (Timeline: 1 - WAL File: 000000010000000000000006) Continuous Backup status Not configured Streaming Replication status Replication Slots Enabled Name Sent LSN Write LSN Flush LSN Replay LSN Write Lag Flush Lag Replay Lag State Sync State Sync Priority Replication Slot - --- -------- --------- --------- ---------- --------- --------- ---------- ----- ---------- ------------- ---------------- sandbox-2 0/604DE38 0/604DE38 0/604DE38 0/604DE38 00:00:00 00:00:00 00:00:00 streaming async 0 active sandbox-3 0/604DE38 0/604DE38 0/604DE38 0/604DE38 00:00:00 00:00:00 00:00:00 streaming async 0 active Instances status Name Current LSN Replication role Status QoS Manager Version Node - --- ----------- ---------------- ------ --- --------------- ---- sandbox-1 0/604DE38 Primary OK BestEffort 1.28.0 k8s-eu-worker sandbox-2 0/604DE38 Standby (async) OK BestEffort 1.28.0 k8s-eu-worker2 sandbox-3 0/604DE38 Standby (async) OK BestEffort 1.28.0 k8s-eu-worker より詳細なステータス情報が必要な場合は、 ``--verbose`` オプションまたは略して\ ``-v`` を使用します。フラグが繰り返されるたびに、詳細レベルが増加します。 .. code:: sh kubectl cnpg status sandbox --verbose .. code:: output Cluster Summary Name: default/sandbox System ID: 7423474350493388827 PostgreSQL Image: ghcr.io/cloudnative-pg/postgresql:16.4 Primary instance: sandbox-1 Primary start time: 2024-10-08 18:31:57 +0000 UTC (uptime 2m4s) Status: Cluster in healthy state Instances: 3 Ready instances: 3 Size: 126M Current Write LSN: 0/6053720 (Timeline: 1 - WAL File: 000000010000000000000006) Continuous Backup status Not configured Physical backups No running physical backups found Streaming Replication status Replication Slots Enabled Name Sent LSN Write LSN Flush LSN Replay LSN Write Lag Flush Lag Replay Lag State Sync State Sync Priority Replication Slot Slot Restart LSN Slot WAL Status Slot Safe WAL Size - --- -------- --------- --------- ---------- --------- --------- ---------- ----- ---------- ------------- ---------------- ---------------- --------------- ------------------ sandbox-2 0/6053720 0/6053720 0/6053720 0/6053720 00:00:00 00:00:00 00:00:00 streaming async 0 active 0/6053720 reserved NULL sandbox-3 0/6053720 0/6053720 0/6053720 0/6053720 00:00:00 00:00:00 00:00:00 streaming async 0 active 0/6053720 reserved NULL Unmanaged Replication Slot Status No unmanaged replication slots found Managed roles status No roles managed Tablespaces status No managed tablespaces Pod Disruption Budgets status Name Role Expected Pods Current Healthy Minimum Desired Healthy Disruptions Allowed - --- ---- ------------- --------------- ----------------------- ------------------- sandbox replica 2 2 1 1 sandbox-primary primary 1 1 1 0 Instances status Name Current LSN Replication role Status QoS Manager Version Node - --- ----------- ---------------- ------ --- --------------- ---- sandbox-1 0/6053720 Primary OK BestEffort 1.28.0 k8s-eu-worker sandbox-2 0/6053720 Standby (async) OK BestEffort 1.28.0 k8s-eu-worker2 sandbox-3 0/6053720 Standby (async) OK BestEffort 1.28.0 k8s-eu-worker 追加の\ ``-v`` ``kubectl cnpg status sandbox -v -v`` などを使用すると、PostgreSQL構成、HBA設定、および証明書を表示することもできます。 このコマンドは、 ``yaml`` および\ ``json`` 形式での出力もサポートしています。 .. Note:: `status` コマンドは、クラスターサイズを計算する`du` や構成ファイルを読み取る`cat` など、Podファイルシステムにアクセスする操作を実行します。大規模なデータ量1TBを超えるクラスターの場合、これらの操作はデフォルトのタイムアウトの10秒よりも長くかかる場合があります。 `--timeout` フラグ `kubectl cnpg status sandbox --timeout 45s` などを使用してタイムアウトを調整できます。 　 プロモート ^^^^^^^^^^ このコマンドの意味は、クラスター内のポッドをプライマリに\ ``promote`` することにより、メンテナンス作業を開始するか、クラスターでスイッチオーバー状況をテストできます。 .. code:: sh kubectl cnpg promote CLUSTER CLUSTER-INSTANCE または、インスタンスノード番号を使用してプロモートせることができます。 .. code:: sh kubectl cnpg promote CLUSTER INSTANCE 証明書 ^^^^^^ CloudNativePGオペレーターを使用して作成されたクラスターは、CAと連携してTLS認証証明書に署名します。 証明書を取得するには、資格情報を保存するシークレットの名前、クラスター名、およびこの証明書のユーザーを提供する必要があります。 .. code:: sh kubectl cnpg certificate cluster-cert --cnpg-cluster CLUSTER --cnpg-user USER シークレットが作成されたら、\ ``kubectl`` を使用して取得できます。 .. code:: sh kubectl get secret cluster-cert また、次のコマンドを使用してプレーンテキストで同じ内容を取得します。 .. code:: sh kubectl get secret cluster-cert -o json | jq -r .data | map(@base64d) | .[] 再起動 ^^^^^^ ``kubectl cnpg restart`` コマンドは、次の2つの場合に使用できます。 - 特定のクラスターのロールアウト再起動を調整するようにオペレーターに要求します。これは、カスタム監視クエリを含む\ ``ConfigMaps`` などのクラスター依存オブジェクトに構成変更を適用する場合に役立ちます。 - 単一インスタンスの再起動を要求します。インスタンスがクラスターのプライマリの場合はインプレース、またはレプリカの場合はポッドの削除と再作成。 .. code:: sh ## this command will restart a whole cluster in a rollout fashion kubectl cnpg restart CLUSTER ## this command will restart a single instance, according to the policy above kubectl cnpg restart CLUSTER INSTANCE インプレース・リスタートが要求されたが、スイッチオーバーなしでは変更を適用できない場合、スイッチオーバーはインプレース・リスタートより優先されます。この一般的なケースは、PostgreSQLイメージのマイナーアップグレードです。 .. Note:: ConfigMapsとSecretsをインスタンスによって**自動的に**リロードしたい場合は、キー`cnpg.io/reload` を持つラベルをそれに追加できます。 　 リロード ^^^^^^^^ ``kubectl cnpg reload`` コマンドは、オペレーターに、特定のクラスターの調整ループをトリガーするように要求します。これは、カスタム監視クエリを含むConfigMapなどのクラスター依存オブジェクトに構成変更を適用する場合に役立ちます。 次のコマンドは、特定のクラスターのすべての構成をリロードします。 .. code:: sh kubectl cnpg reload CLUSTER メンテナンス ^^^^^^^^^^^^ ``kubectl cnpg maintenance`` コマンドは、名前空間全体で1つ以上のクラスターを変更し、メンテナンスウィンドウ値を設定するのに役立ちます。次のフィールドを変更します。 - ``.spec.nodeMaintenanceWindow.inProgress`` - ``.spec.nodeMaintenanceWindow.reusePVC`` これを使用して\ ``set`` および\ ``unset`` を引数として受け入れ、\ ``set`` の場合は\ ``inProgress`` を\ ``true`` に設定し、\ ``unset`` の場合は\ ``false`` に設定します。 デフォルトでは、 ``--reusePVC`` フラグが渡されない限り、 ``reusePVC`` は常に\ ``false`` に設定されます。 プラグインは、変更するクラスターのリストとその新しい値の確認を求めます。これが受け入れられる場合、このアクションはリスト内のすべてのクラスターに適用されます。 Kubernetesクラスター内のすべてのPostgreSQLをメンテナンスに設定する場合は、次のコマンドを記述するだけです。 .. code:: sh kubectl cnpg maintenance set --all-namespaces 更新するすべてのクラスターのリストが得られます .. code:: output The following are the new values for the clusters Namespace Cluster Name Maintenance reusePVC - -------- ------------ ----------- -------- default cluster-example true false default pg-backup true false test cluster-example true false Do you want to proceed? [y/n]: y レポート ^^^^^^^^ ``kubectl cnpg report`` コマンドは、さまざまな情報をZIPファイルにバンドルします。実稼働環境のクラスターの問題をデバッグするために必要なコンテキストを提供することを目的としています。 ``operator`` および\ ``cluster`` の2つのサブコマンドがあります。 レポート演算子 ^^^^^^^^^^^^^^ ``operator`` サブコマンドは、オペレーターの展開、構成、およびイベントに関する情報の提供をオペレーターに要求します。 .. Note:: SecretsとConfigMapのすべての機密情報は編集されています。データマップには**キー**が表示されますが、値は空になります。フラグ`-S` / `--stopRedaction` は、リダクションを無効にし、値を表示します。自己の責任でのみ使用します。これはプライベートデータを共有します。 　 .. Note:: デフォルトでは、オペレーターログは収集されませんが、 `--logs` フラグを使用してオペレーターログ収集を有効にできます 　 .. Note:: `report operator` コマンドは、最小限の権限で動作します。オペレーターの展開のみが**必須**です。他のすべてのリソースはオプショナルであり、ベストエフォートベースで収集されます。特定のリソースWebhook、OLMリソースなどの権限が不足している場合、警告がログに記録され、利用可能なデータでレポート生成が続行されます。 　 レポートには以下が含まれます。 - **展開情報** 必須 オペレーター ``Deployment`` - **operator pods** オプショナル オペレーター\ ``Pod`` 情報 - **configuration** オプショナル オペレーター名前空間の\ ``Secrets`` および\ ``ConfigMaps`` - **events** オプショナル オペレーター名前空間の\ ``Events`` - **webhook configuration** オプショナル ウェブフック構成の変更と検証 クラスタースコープ - **webhook service** (オプショナル) Webhookサービス - **OLMリソース** オプショナル サブスクリプション、クラスターサービスバージョン、インストールプランOLMがインストールされている場合 - **logs** オプショナル 演算子\ ``Pod`` JSON行形式のログ ``--logs`` フラグが必要 .. Warning:: オペレーター名前空間のオペレーターデプロイメントへの読み取りアクセス 。これにより、名前空間スコープのユーザーは基本的なトラブルシューティングレポートを生成できます。 　 .. Note:: ポッド、イベントに`list` を追加します。シークレット、構成マップ、サービス名前空間スコープの`get` 。およびWebhook構成クラスタースコープの`list` 。 　 名前空間スコープの権限のみを持つユーザーは、引き続き有用なレポートを生成できます。 .. code:: sh ## With only deployment read access kubectl cnpg report operator -n cnpg-system -f report.zip .. Note:: このコマンドは、アクセスできないリソースの警告をログに記録しますが、展開マニフェストを使用したレポートを正常に生成します。多くの場合、基本的なトラブルシューティングには十分です。 　 このコマンドは、YAML形式のさまざまなマニフェストを含むZIPファイルを生成しますデフォルトでは、 ``-o`` フラグを使用してJSONに設定可能です。 ``-f`` フラグを使用して、結果ファイルに明示的に名前を付けます。 ``-f`` フラグを使用しない場合、zipファイルにデフォルトのタイムスタンプ付きファイル名が作成されます。 .. Note:: Reportプラグインは`kubectl` 規約に従い、名前空間によって制限されたオブジェクトを検索します。 CNPGオペレーターは、通常、クラスターと同じ名前空間にインストールされません。例デフォルトのインストール名前空間はcnpg-systemです。 　 .. code:: sh kubectl cnpg report operator -n cnpg-system での結果 .. code:: output Successfully written report to "report_operator_.zip" (format: "yaml") ``-f`` フラグを設定した場合 .. code:: sh kubectl cnpg report operator -n cnpg-system -f reportRedacted.zip ファイルを解凍すると、タイムスタンプ付きのトップレベルフォルダーが生成され、ディレクトリを整理します。 .. code:: sh unzip reportRedacted.zip 結果は次のとおりです。 .. code:: output Archive: reportRedacted.zip creating: report_operator_/ creating: report_operator_/manifests/ inflating: report_operator_/manifests/deployment.yaml inflating: report_operator_/manifests/operator-pod.yaml inflating: report_operator_/manifests/events.yaml inflating: report_operator_/manifests/validating-webhook-configuration.yaml inflating: report_operator_/manifests/mutating-webhook-configuration.yaml inflating: report_operator_/manifests/webhook-service.yaml inflating: report_operator_/manifests/cnpg-ca-secret(secret).yaml inflating: report_operator_/manifests/cnpg-webhook-cert(secret).yaml ``--logs`` オプションをアクティブにすると、追加のサブディレクトリが表示されます。 .. code:: output Archive: report_operator_.zip creating: report_operator_/operator-logs/ inflating: report_operator_/operator-logs/cnpg-controller-manager-66fb98dbc5-pxkmh-logs.jsonl .. Note:: プラグインは、 PREVIOUSオペレーターのログを取得しようとします。これは、再起動されたオペレーターを調査するときに役立ちます。すべての場合、現在のオペレーターログも取得しようとします。現在と以前のログが利用可能な場合、両方が表示されます。 　 .. code:: output ====== Beginning of Previous Log ===== 2023-03-28T12:56:41.251711811Z {"level":"info","ts":"2023-03-28T12:56:41Z","logger":"setup","msg":"Starting CloudNativePG Operator","version":"1.28.0","build":{"Version":"1.28.0+dev107","Commit":"cc9bab17","Date":"2023-03-28"}} 2023-03-28T12:56:41.251851909Z {"level":"info","ts":"2023-03-28T12:56:41Z","logger":"setup","msg":"Starting pprof HTTP server","addr":"0.0.0.0:6060"} ====== End of Previous Log ===== 2023-03-28T12:57:09.854306024Z {"level":"info","ts":"2023-03-28T12:57:09Z","logger":"setup","msg":"Starting CloudNativePG Operator","version":"1.28.0","build":{"Version":"1.28.0+dev107","Commit":"cc9bab17","Date":"2023-03-28"}} 2023-03-28T12:57:09.854363943Z {"level":"info","ts":"2023-03-28T12:57:09Z","logger":"setup","msg":"Starting pprof HTTP server","addr":"0.0.0.0:6060"} オペレーターが再起動されていない場合、\ ``====== Begin …`` および\ ``====== End …`` ガードが表示されますが、中にコンテンツはありません。 機密情報がデフォルトで編集されていることを確認できます。 .. code:: sh cd report_operator_/manifests/ head cnpg-ca-secret\(secret\).yaml .. code:: yaml data: ca.crt: "" ca.key: "" metadata: creationTimestamp: "2022-03-22T10:42:28Z" managedFields: - apiVersion: v1 fieldsType: FieldsV1 fieldsV1: ``-S`` ``--stopRedaction`` オプションを有効にすると、シークレットが表示されます。 .. code:: sh kubectl cnpg report operator -n cnpg-system -f reportNonRedacted.zip -S 機密情報を表示しようとしていることを示すリマインダーが届きます。 .. code:: output WARNING: secret Redaction is OFF. Use it with caution Successfully written report to "reportNonRedacted.zip" (format: "yaml") .. code:: sh unzip reportNonRedacted.zip head cnpg-ca-secret\(secret\).yaml .. code:: yaml data: ca.crt: LS0tLS1CRUdJTiBD… ca.key: LS0tLS1CRUdJTiBF… metadata: creationTimestamp: "2022-03-22T10:42:28Z" managedFields: - apiVersion: v1 fieldsType: FieldsV1 レポートクラスター ^^^^^^^^^^^^^^^^^^ ``cluster`` サブコマンドは、以下を収集します。 - **クラスターリソース** クラスター情報、\ ``kubectl get cluster -o yaml`` と同じ - **クラスターポッド** クラスター名と一致するクラスター名前空間内のポッド - **クラスタージョブ** クラスター名と一致するクラスター名前空間内のジョブがある場合 - **events** クラスター名前空間のイベント - **pod logs** JSON行形式のクラスターポッドのログオプショナル、デフォルトでオフ - **ジョブログ** ジョブによって作成されたポッドのログオプショナル、デフォルトでオフJSON行形式で ``cluster`` サブコマンドは、 ``operator`` が行うように、\ ``-f`` および\ ``-o`` フラグを受け入れます。 ``-f`` フラグを使用しない場合、デフォルトのタイムスタンプ付きレポート名が使用されます。クラスター情報には構成シークレット/構成マップが含まれていないため、 ``-S`` は無効になっていることに注意してください。 .. Note:: デフォルトでは、クラスターログは収集されませんが、 `--logs` フラグを使用してクラスターログ収集を有効にできます 　 使用法 .. code:: sh kubectl cnpg report cluster CLUSTER [flags] ``operator`` サブコマンドとは異なり、 ``cluster`` サブコマンドの場合、クラスターがデフォルトの場合を除き、クラスター名前と、多くの場合、名前空間を指定する必要があることに注意してください。 .. code:: sh kubectl cnpg report cluster CLUSTER -f report.zip [-n NAMESPACE] そして .. code:: sh unzip report.zip .. code:: output Archive: report.zip creating: report_cluster_example_/ creating: report_cluster_example_/manifests/ inflating: report_cluster_example_/manifests/cluster.yaml inflating: report_cluster_example_/manifests/cluster-pods.yaml inflating: report_cluster_example_/manifests/cluster-jobs.yaml inflating: report_cluster_example_/manifests/events.yaml ``--logs`` フラグを使用して、ポッドとジョブログをZIPに追加できることに注意してください。 .. code:: sh kubectl cnpg report cluster CLUSTER [-n NAMESPACE] --logs 結果は次のとおりです。 .. code:: output Successfully written report to "report_cluster_example_.zip" (format: "yaml") .. code:: sh unzip report_cluster_.zip .. code:: output Archive: report_cluster_example_.zip creating: report_cluster_example_/ creating: report_cluster_example_/manifests/ inflating: report_cluster_example_/manifests/cluster.yaml inflating: report_cluster_example_/manifests/cluster-pods.yaml inflating: report_cluster_example_/manifests/cluster-jobs.yaml inflating: report_cluster_example_/manifests/events.yaml creating: report_cluster_example_/logs/ inflating: report_cluster_example_/logs/cluster-example-full-1.jsonl creating: report_cluster_example_/job-logs/ inflating: report_cluster_example_/job-logs/cluster-example-full-1-initdb-qnnvw.jsonl inflating: report_cluster_example_/job-logs/cluster-example-full-2-join-tvj8r.jsonl ログ ^^^^ ``kubectl cnpg logs`` コマンドを使用すると、CloudNativePGに関連するポッドのコレクションのログを一度にたどることができます。 現時点では、使用可能なサブコマンドが1つあります\ ``cluster`` 。 クラスターログ ^^^^^^^^^^^^^^ ``cluster`` サブコマンドは、クラスターのすべてのポッドログを単一のストリームまたはファイルに収集します。これは、単一のターミナルウィンドウで、コマンドを1回呼び出して、すべてのポッドログを取得できることを意味します。 すべてのcnpgプラグインサブコマンドと同様に、\ ``-h`` フラグの指示とヘルプを取得できます。 ``kubectl cnpg logs cluster -h`` ``logs`` コマンドは、 ``--timestamps`` フラグを使用しない限り、JSON行形式でログを表示します。その場合、人間が判読可能なタイムスタンプが各行の先頭に追加されます。この場合、行は有効なJSONでなくなり、 ``jq`` などのツールが目的のように動作しない場合があります。 ``logs cluster`` サブコマンドに\ ``-f`` フラグ別名\ ``--follow`` が指定されている場合、クラスターポッドログをたどり、コマンドが呼び出された後にクラスターで作成された新しいポッドを監視します。再起動または再作成されたポッドを含む、見つかった新しいポッドもポッドが追跡されます。ログは端末の標準出力に表示されます。このコマンドは、クラスターにポッドが残っていない場合、またはユーザーによって中断された場合にのみ終了します。 ``-f`` オプションを指定せずに\ ``logs`` が呼び出された場合、呼び出されるまですべてのクラスターポッドからログを読み取り、ターミナルの標準出力に表示してから終了します。 ``-o`` または\ ``--output`` フラグを提供して、標準出力で表示する代わりに、ログを保存するファイルの名前を指定できます。 ``--tail`` フラグを使用して、クラスター内の各ポッドから取得するログ行数を指定できます。デフォルトでは、 ``logs cluster`` サブコマンドは、クラスター内の各ポッドからのすべてのログを表示します。 「follow」フラグ\ ``-f`` と組み合わせると、\ ``--tail`` で指定された数のログが現在まで取得され、それ以降新しいログが追跡されます。 注他の\ ``cnpg`` プラグインコマンドとは異なり、 ``-f`` はファイルを指定するのではなく「フォロー」を示すために使用されます。これは、 ``kubectl logs`` の規則に従いますが、 ``-f`` は、ログに従う必要があることを意味します。 使用法 .. code:: sh kubectl cnpg logs cluster CLUSTER [flags] ``-f`` オプションを使用して次のことを行います。 .. code:: sh kubectl cnpg report cluster CLUSTER -f ``--tail`` オプションを使用して各ポッドから3行を表示し、 ``-f`` オプションを追跡します。 .. code:: sh kubectl cnpg report cluster CLUSTER -f --tail 3 .. code:: output {"level":"info","ts":"2023-06-30T13:37:33Z","logger":"postgres","msg":"2023-06-30 13:37:33.142 UTC [26] LOG: ending log output to stderr","source":"/controller/log/postgres","logging_pod":"cluster-example-3"} {"level":"info","ts":"2023-06-30T13:37:33Z","logger":"postgres","msg":"2023-06-30 13:37:33.142 UTC [26] HINT: Future log output will go to log destination \"csvlog\".","source":"/controller/log/postgres","logging_pod":"cluster-example-3"} … … ``-o`` オプションを省略し、\ ``--output`` を指定する場合 .. code:: console $ kubectl cnpg logs cluster CLUSTER --output my-cluster.log Successfully written logs to "my-cluster.log" Pretty ^^^^^^^^ ``pretty`` サブコマンドは、標準入力からログストリームを読み取り、人間が判読可能な出力にフォーマットし、タイムスタンプでエントリを並べ替えようとします。 次の例に示すように、\ ``kubectl cnpg logs cluster`` と組み合わせて使用できます。 .. code:: console $ kubectl cnpg logs cluster cluster-example | kubectl cnpg logs pretty 2024-10-15T17:35:00.336 INFO cluster-example-1 instance-manager Starting CloudNativePG Instance Manager 2024-10-15T17:35:00.336 INFO cluster-example-1 instance-manager Checking for free disk space for WALs before starting PostgreSQL 2024-10-15T17:35:00.347 INFO cluster-example-1 instance-manager starting tablespace manager 2024-10-15T17:35:00.347 INFO cluster-example-1 instance-manager starting external server manager [...] または、次の例にあるように、JSON形式でCNPGログを生成する他のコマンド、\ ``stern`` 、\ ``kubectl logs`` などと組み合わせて使用できます。 .. code:: console $ kubectl logs cluster-example-1 | kubectl cnpg logs pretty 2024-10-15T17:35:00.336 INFO cluster-example-1 instance-manager Starting CloudNativePG Instance Manager 2024-10-15T17:35:00.336 INFO cluster-example-1 instance-manager Checking for free disk space for WALs before starting PostgreSQL 2024-10-15T17:35:00.347 INFO cluster-example-1 instance-manager starting tablespace manager 2024-10-15T17:35:00.347 INFO cluster-example-1 instance-manager starting external server manager [...] ``pretty`` サブコマンドは、高度なログフィルタリングもサポートしているため、ユーザーは特定のポッドまたはロガーのログを表示したり、重大度レベルでログをフィルタリングしたりできます。次に例を示します。 .. code:: console $ kubectl cnpg logs cluster cluster-example | kubectl cnpg logs pretty --pods cluster-example-1 --loggers postgres --log-level info 2024-10-15T17:35:00.509 INFO cluster-example-1 postgres 2024-10-15 17:35:00.509 UTC [29] LOG: redirecting log output to logging collector process 2024-10-15T17:35:00.509 INFO cluster-example-1 postgres 2024-10-15 17:35:00.509 UTC [29] HINT: Future log output will appear in directory "/controller/log"... 2024-10-15T17:35:00.510 INFO cluster-example-1 postgres 2024-10-15 17:35:00.509 UTC [29] LOG: ending log output to stderr 2024-10-15T17:35:00.510 INFO cluster-example-1 postgres ending log output to stderr [...] ``pretty`` サブコマンドは、ログを推論しやすくするために、ログストリームをソートしようとします。これを行うために、ログをグループに収集し、グループ内でタイムスタンプで並べ替えます。 ``pretty`` は「follow」モードのコマンドからパイプされる場合があるため、これは対話型で並べ替える唯一の方法です。サブコマンドは、ソートされた各グループの最後にグループ区切り線\ ``---`` を追加します。次の例に示すように、グループのサイズは\ ``--sorting-group-size`` フラグデフォルト1000を介して構成できます。 .. code:: console $ kubectl cnpg logs cluster cluster-example | kubectl cnpg logs pretty --sorting-group-size=3 2024-10-15T17:35:20.426 INFO cluster-example-2 instance-manager Starting CloudNativePG Instance Manager 2024-10-15T17:35:20.426 INFO cluster-example-2 instance-manager Checking for free disk space for WALs before starting PostgreSQL 2024-10-15T17:35:20.438 INFO cluster-example-2 instance-manager starting tablespace manager - -- 2024-10-15T17:35:20.438 INFO cluster-example-2 instance-manager starting external server manager 2024-10-15T17:35:20.438 INFO cluster-example-2 instance-manager starting controller-runtime manager 2024-10-15T17:35:20.439 INFO cluster-example-2 instance-manager Starting EventSource - -- [...] 使用可能なすべてのオプションを確認するには、 ``-h`` フラグを使用して、サポートされているフラグとその使用法の詳細を確認します。 .. Note:: `-v` オプションを追加して、ログの詳細度を高めることもできます。 　 デストロイ ^^^^^^^^^^ ``kubectl cnpg destroy`` コマンドは、インスタンスと、関連するすべてのPVCをKubernetesクラスターから削除するのに役立ちます。 オプションの\ ``--keep-pvc`` フラグを指定すると、PVCを保持したまま、インスタンスによって設定されたすべての\ ``metadata.ownerReferences`` を削除できます。さらに、PVCの\ ``cnpg.io/pvcStatus`` ラベルが\ ``ready`` から\ ``detached`` に変更され、使用されなくなったことを示します。 ``--keep-pvc`` フラグを指定せずにコマンドを再度実行すると、分離されたPVCが削除されます。 使用法 .. code:: sh kubectl cnpg destroy CLUSTER INSTANCE 次の例は、\ ``cluster-example-2`` ポッドと関連するPVCを削除します。 .. code:: sh kubectl cnpg destroy cluster-example 2 クラスターハイバネーション ^^^^^^^^^^^^^^^^^^^^^^^^^^ データを保存しながらCloudNativePG ``Cluster`` を一時的に一時停止し、後でオペレーションを再開できるようにする必要がある場合があります。この機能は、 **クラスターハイバーネーション** と呼ばれます。 ハイバネーションは、 ``cnpg.io/hibernation`` アノテーションを使用して宣言的に管理されます。 .. Note:: 詳細については、 :ref:`Declarative hibernation ` を参照してください。 ドキュメントページ。 　 プロセスを簡素化するために、 ``kubectl`` の\ ``cnpg`` プラグインは ``hibernate`` コマンドを提供します。これは、アノテーションを適用するための便利なショートカットとして機能します。 クラスターを休止状態にするには、次のコマンドを実行します。 .. code:: sh kubectl cnpg hibernate on CLUSTER このコマンドは、 ``cnpg.io/hibernation=on`` アノテーションをクラスターに適用し、実行を一時停止します。 休止状態のクラスターを再開するには、次を使用します。 .. code:: sh kubectl cnpg hibernate off CLUSTER これにより、\ ``cnpg.io/hibernation=off`` を設定することによりハイバーネーション状態が削除されます。 クラスターのステータスは、次の方法でいつでも確認できます。 .. code:: sh kubectl cnpg status CLUSTER これにより、クラスターの現在の状態が表示されます、休止状態かどうかを含む。 pgbenchを使用したデータベースのベンチマーク ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Pgbenchは、次のコマンドを使用して、既存のPostgreSQLクラスターに対して実行できます。 .. code:: sh kubectl cnpg pgbench CLUSTER -- --time 30 --client 1 --jobs 1 詳細については、 :ref:`Benchmarking pgbench section ` を参照してください。 fioを使用したストレージのベンチマーク ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``fio`` は、次のコマンドを使用して既存のストレージクラスで実行できます。 .. code:: sh kubectl cnpg fio FIO_JOB_NAME [-n NAMESPACE] 詳細については、 :ref:`Benchmarking fio section ` を参照してください。 新しい物理バックアップの要求 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``kubectl cnpg backup`` コマンドは、新しい\ ``Backup`` リソースを作成することにより、既存のPostgresクラスターの新しい物理バックアップを要求します。 次の例は、特定のクラスターのオンデマンドバックアップを要求します。 .. code:: sh kubectl cnpg backup CLUSTER または、ボリュームスナップショットを使用する場合 .. code:: sh kubectl cnpg backup CLUSTER -m volumeSnapshot 作成されるバックアップには、要求時間に基づいた名前が付けられます。 .. code:: console $ kubectl cnpg backup cluster-example backup/cluster-example-20230121002300 created デフォルトでは、新しく作成されるバックアップは、クラスターで定義されたバックアップターゲットポリシーを使用して、実行するインスタンスを選択します。ただし、このポリシーは\ ``--backup-target`` オプションでオーバーライドできます。 ボリュームスナップショットバックアップの場合、 ``--online`` オプションを使用して、オンライン/ホットバックアップまたはオフライン/コールドバックアップを要求することもできます。さらに、 ``--immediate-checkpoint`` および\ ``--wait-for-archive`` オプションを明示的に設定することにより、オンラインバックアップを調整することもできます。 :ref:`Appendix B - Backup on object stores ` には、構成設定に関する詳細情報が含まれています。 psqlの起動 ^^^^^^^^^^ ``kubectl cnpg psql CLUSTER`` コマンドは、実際のポッドから実行しているかのように、既存のPostgresクラスターに接続された新しいPostgreSQL対話型フロントエンドプロセス psqlを起動します。これは、 ``postgres`` ユーザーを使用することを意味します。 .. Note:: `postgres` ユーザーとして接続するため、運用環境では、この方法は許可された担当者のみが細心の注意を払って使用する必要があります。 　 .. code:: console $ kubectl cnpg psql cluster-example psql (18.1 (Debian 18.1-1.pgdg110+1)) Type "help" for help. postgres=# デフォルトでは、コマンドはプライマリインスタンスに接続します。ユーザーは\ ``--replica`` オプションを使用して、レプリカに対して作業することを選択できます。 .. code:: console $ kubectl cnpg psql --replica cluster-example psql (18.1 (Debian 18.1-1.pgdg110+1)) Type "help" for help. postgres=# select pg_is_in_recovery(); pg_is_in_recovery - ------------------ t (1 row) postgres=# \q このコマンドは\ ``kubectl exec`` を起動します。正常に動作するには、\ ``PATH`` 変数で\ ``kubectl`` 実行可能ファイルに到達できる必要があります。 Postgresクラスターのスナップショット ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ .. Warning:: `kubectl cnpg snapshot` コマンドは削除されました。 :ref:`新しい物理バックアップの要求 <新しい物理バックアップの要求>` を使用して、ボリュームスナップショットを使用したバックアップを要求してください。 　 評価/デモ目的でのみpgAdmin4を使用する ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `pgAdmin `_ は、PostgreSQLの最も人気のある機能が豊富なオープンソースの管理および開発プラットフォームです。プロジェクトの詳細については、公式 `documentation `_ を参照してください。 pgAdmin開発チームが公式のDockerコンテナイメージを維持していることを考えると、標準のKubernetes展開として環境にpgAdminをインストールできます。 .. Note:: Kubernetes運用環境でのpgAdminの展開は、このドキュメントの範囲を超えており、より広範にはCloudNativePGプロジェクトの範囲を超えています。 　 ただし、 **デモと評価の目的で** 、CloudNativePGは適切なソリューションを提供します。 ``cnpg`` プラグインは\ ``pgadmin4`` コマンドを実装し、特定のデータベース\ ``Cluster`` に接続し、\ ``kind`` などのローカル環境でそのコンテンツをナビゲートする簡単な方法を提供します。 たとえば、次のとおりに\ ``cluster-example`` クラスターのpgAdmin4のデモ展開をインストールできます。 .. code:: sh kubectl cnpg pgadmin4 cluster-example このコマンドは次を生成します。 .. code:: output ConfigMap/cluster-example-pgadmin4 created Deployment/cluster-example-pgadmin4 created Service/cluster-example-pgadmin4 created Secret/cluster-example-pgadmin4 created [...] pgAdminを展開した後、 kubectlを使用してポートを転送し、画面の指示に従ってブラウザーを介して接続します。 .. figure:: /images/pgadmin4.png :width: 70% :alt: Screenshot of desktop installation of pgAdmin Screenshot of desktop installation of pgAdmin いつものように、\ ``--dry-run`` オプションを使用してYAMLファイルを生成できます。 .. code:: sh kubectl cnpg pgadmin4 --dry-run cluster-example pgAdmin4はデスクトップまたはサーバーモードでインストールできます。デフォルトはサーバーです。 ``server`` モードでは、ランダムに生成されたパスワードを使用して認証が必要で、ユーザーは接続するデータベースを手動で指定する必要があります。 一方、\ ``desktop`` モードは、認証を必要とせずにpgAdmin Webインターフェイスを開始します。 ``app`` ユーザーとして\ ``app`` データベースに自動的に接続するため、 ``kind`` を使用したローカル展開などの簡単なデモに最適です。 .. code:: sh kubectl cnpg pgadmin4 --mode desktop cluster-example デモが終了した後、次のコマンドを実行してpgAdmin展開を確実に終了します。 .. code:: sh kubectl cnpg pgadmin4 --dry-run cluster-example | kubectl delete -f - .. Warning:: プラグインを使用してpgAdminを運用環境に展開しないでください。 　 ロジカルレプリケーションのパブリケーション ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``cnpg publication`` コマンドグループは、 `PostgreSQL logical replication publications `_ の作成と削除を合理化するように設計されています。これらのコマンドは、主に、特にリモートのPostgreSQLデータベースでの論理レプリケーションパブリケーションの作成を支援することを目的としていることに注意してください。 .. Warning:: これらのコマンドを使用する前に、PostgreSQLのネイティブ論理レプリケーションシステムの機能と制限の両方をしっかりと理解することが重要です。特に、 `logical replication restrictions `_ に注意してください。 　 新しいパブリケーションの作成 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 論理レプリケーションパブリケーションを作成するには、 ``cnpg publication create`` コマンドを使用します。このコマンドの基本的な構造は次のとおりです。 .. code:: sh kubectl cnpg publication create \ --publication PUBLICATION_NAME \ [--external-cluster EXTERNAL_CLUSTER] LOCAL_CLUSTER [options] 2つの主な使用例があります。 - ``--external-cluster`` の場合 このオプションを使用して、外部クラスターつまり ``externalClusters`` スタンザで定義された上にパブリケーションを作成します。コマンドは\ ``LOCAL_CLUSTER`` から発行されますが、パブリケーションは\ ``EXTERNAL_CLUSTER`` のデータ用です。 - ``--external-cluster`` なし このオプションを使用して、 ``LOCAL_CLUSTER`` PostgreSQL ``Cluster`` デフォルトでは ``app`` データベースにパブリケーションを作成します。 .. Warning:: 外部クラスターに接続するときは、指定されたユーザーに`CREATE PUBLICATION` コマンドを実行するための十分な権限があることを確認してください。 　 `CREATE PUBLICATION `_ と同様の、いくつかのオプションがあります。 コマンドを使用して、レプリケートするテーブルのグループを定義します。重要なオプションには次のものが含まれます。 - ``--all-tables`` オプションを指定した場合、パブリケーション\ ``FOR ALL TABLES`` を作成します。 - または、次の複数のオカレンスを指定できます。 - ``--table`` 特定のテーブル式を追加します。 - ``--schema`` 指定されたデータベーススキーマPostgreSQL 15から利用可能にあるすべてのテーブルを含めます。 ``--dry-run`` オプションを使用すると、プラグインが実行するSQLコマンドをプレビューできます。 追加情報と詳細な手順については、次のコマンドを入力してください。 .. code:: sh kubectl cnpg publication create --help 例 '' ``source-cluster`` および\ ``destination-cluster`` を指定して、 ``source-cluster`` 上のデータのパブリケーションを作成します。 ``destination-cluster`` には、\ ``source-cluster`` を指す\ ``externalClusters`` スタンザにエントリーがあります。 次を実行できます。 .. code:: sh kubectl cnpg publication create destination-cluster \ --external-cluster=source-cluster --all-tables これは、 ``destination-cluster`` でSQLコマンドを実行し、 ``source-cluster`` のすべてのテーブルのパブリケーションを作成します。 または、その代わりに、次を実行できます。 .. code:: sh kubectl cnpg publication create source-cluster \ --publication=app --all-tables これは、 ``source-cluster`` 内のすべてのテーブルに\ ``app`` という名前のパブリケーションを作成し、ソースクラスターでSQLコマンドを実行します。 .. Note:: イラストとインスピレーションのために提供されている2つのサンプルファイル `logical-source `_ および `logical-destination `_ 。 　 パブリケーションの削除 ^^^^^^^^^^^^^^^^^^^^^^ ``cnpg publication drop`` コマンドは、パブリケーション名、クラスター名、オプションの外部クラスターを含む同様のキーオプションを提供することにより、 ``create`` コマンドをシームレスに補完します。次のコマンド構造を使用して\ ``PUBLICATION`` をドロップできます。 .. code:: sh kubectl cnpg publication drop \ --publication PUBLICATION_NAME \ [--external-cluster EXTERNAL_CLUSTER] LOCAL_CLUSTER [options] さらに詳細と正確な指示にアクセスするには、次のコマンドを使用します。 .. code:: sh kubectl cnpg publication drop --help 論理レプリケーションサブスクリプション ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``cnpg subscription`` コマンドグループは、 `PostgreSQL logical replication subscriptions `_ の作成と削除を簡素化するように設計された専用のコマンドセットです。これらのコマンドは、特にリモートのPostgreSQLデータベースを扱う場合、論理レプリケーションサブスクリプションの確立を支援するように特別に作成されています。 .. Warning:: これらのコマンドを使用する前に、PostgreSQLのネイティブ論理レプリケーションシステムの機能と制限の両方を包括的に理解することが重要です。特に、 `logical replication restrictions `_ に注意してください。 　 サブスクリプション管理に加えて、ソースクラスターからすべてのシーケンスを同期するための役立つコマンドを提供します。その適用性は異なる場合がありますが、このコマンドは、メジャーアップグレードまたはリモートサーバーからのデータのインポートを含むシナリオで特に役立ちます。 新しいサブスクリプションの作成 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 論理レプリケーションサブスクリプションを作成するには、 ``cnpg subscription create`` コマンドを使用します。このコマンドの基本的な構造は次のとおりです。 .. code:: sh kubectl cnpg subscription create \ --subscription SUBSCRIPTION_NAME \ --publication PUBLICATION_NAME \ --external-cluster EXTERNAL_CLUSTER \ LOCAL_CLUSTER [options] このコマンドは、 ``LOCAL_CLUSTER`` の\ ``externalClusters`` スタンザで定義されているとおりに、指定された外部クラスター内の指定されたパブリケーションを対象としたサブスクリプションを構成します。 追加情報と詳細な手順については、次のコマンドを入力してください。 .. code:: sh kubectl cnpg subscription create --help .. _例-1: 例 '' パブリケーションに関するセクションと同様に、\ ``source-cluster`` および\ ``destination-cluster`` があり、\ ``app`` というパブリケーションを既に作成しています。 次のコマンド .. code:: sh kubectl cnpg subscription create destination-cluster \ --external-cluster=source-cluster \ --publication=app --subscription=app は、宛先クラスターに\ ``app`` のサブスクリプションを作成します。 .. Warning:: 非実稼働環境でのテストサブスクリプションを優先して、実稼働設定に実装する前にその有効性を確認し、潜在的な問題を特定します。 　 .. Note:: イラストとインスピレーションのために提供されている2つのサンプルファイル `logical-source `_ および `logical-destination `_ 。 　 サブスクリプションの削除 ^^^^^^^^^^^^^^^^^^^^^^^^ ``cnpg subscription drop`` コマンドは、 ``create`` コマンドをシームレスに補完します。次のコマンド構造を使用して\ ``SUBSCRIPTION`` をドロップできます。 .. code:: sh kubectl cnpg subcription drop \ --subscription SUBSCRIPTION_NAME \ LOCAL_CLUSTER [options] さらに詳細と正確な指示にアクセスするには、次のコマンドを使用します。 .. code:: sh kubectl cnpg subscription drop --help シーケンスの同期 ^^^^^^^^^^^^^^^^ パブリケーションとサブスクリプションを介して実装されるPostgreSQL論理レプリケーションの重要な制約の1つは、シーケンス同期の欠如です。これは、論理レプリケーションを利用する場合に特に関連します ライブデータベース移行、特にPostgreSQLの上位バージョンの場合。このプロセスの重要なステップには、アプリケーションを新しいデータベース *カットオーバー* に移行する前にシーケンスの更新が含まれます。 この制限に対処するために、 ``cnpg subscription sync-sequences`` コマンドは解決策を提供します。このコマンドは、ソースデータベースとの接続を確立し、関連するすべてのシーケンスを取得し、その後、一致するIDでローカルシーケンスを更新しますデータベーススキーマとシーケンス名に基づいて。 以下に示すようにコマンドを使用できます。 .. code:: sh kubectl cnpg subscription sync-sequences \ --subscription SUBSCRIPTION_NAME \ LOCAL_CLUSTER 包括的な詳細と特定の手順については、次のコマンドを使用します。 .. code:: sh kubectl cnpg subscription sync-sequences --help .. _例-2: 例 '' パブリケーションとサブスクリプションに関する以前のセクションと同様に、\ ``source-cluster`` および\ ``destination-cluster`` があります。パブリケーションとサブスクリプションは、両方とも\ ``app`` と呼ばれますが、既に存在します。 次のコマンドは、\ ``app`` サブスクリプションに関係するシーケンスをソースクラスターから宛先クラスターに同期します。 .. code:: sh kubectl cnpg subscription sync-sequences destination-cluster \ --subscription=app .. Warning:: 非実稼働環境でのテストサブスクリプションを優先して、実稼働設定に展開する前にその有効性を保証し、潜在的な問題を検出します。 　 K9sとの統合 ----------- ``cnpg`` プラグインは、Kubernetesクラスターと対話するための人気のターミナルベースのUIである `K9s `_ に簡単に統合できます。 詳細は、 :ref:`k9s/plugins.yml ` を参照してください。 プラグインに必要な権限 ---------------------- プラグインには、実行するコマンドに応じて一連のKubernetes権限が必要です。これらの権限は、ポッド、PDB、PVCなどのリソースやサブリソースに影響を与え、\ ``get`` 、\ ``delete`` 、\ ``patch`` などのアクションを有効にする場合があります。次の表には、完全な詳細が含まれています。 .. csv-table:: :header: Command,Resource Permissions :widths: 10,30 :align: left :class: longtable backup,clusters: get backups: create certificate,"clusters: get secrets: get,create" destroy,"pods: get,delete jobs: delete,list PVCs: list,delete,update" fencing,"clusters: get,patch pods: get" fio,PVCs: create configmaps: create deployment: create hibernate,"clusters: get,patch,delete pods: list,get,delete pods/exec: create jobs: list PVCs: get,list,update,patch,delete" install,none logs,clusters: get pods: list pods/log: get maintenance,"clusters: get,patch,list" pgadmin4,clusters: get configmaps: create deployments: create services: create secrets: create pgbench,clusters: get jobs: create promote,clusters: get clusters/status: patch pods: get psql,"pods: get,list pods/exec: create" publication,"clusters: get pods: get,list pods/exec: create" reload,"clusters: get,patch" report cluster,clusters: get pods: list pods/log: get jobs: list events: list PVCs: list report operator,**Required:** deployments: get **Optional (for full report):** configmaps: get events: list pods: list pods/log: get secrets: get services: get mutatingwebhookconfigurations: list[^1] validatingwebhookconfigurations: list[^1] **If OLM is present:** clusterserviceversions: list[^1] installplans: list[^1] subscriptions: list[^1] restart,"clusters: get,patch pods: get,delete" status,clusters: get pods: list pods/exec: create pods/proxy: create PDBs: list objectstores.barmancloud.cnpg.io: get subscription,"clusters: get pods: get,list pods/exec: create" version,none [^1] 権限は、クラスタースコープのClusterRoleリソースです。 ///脚注はここにあります/// さらに、 ``clusters`` に\ ``list`` 権限を割り当てると、複数のコマンドのオートコンプリートが有効になります。 ロールの例 ^^^^^^^^^^ 権限が制限されたロールを作成することが可能です。次の例では、クラスターログにのみアクセスするロールを作成します。 .. code:: yaml - -- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: cnpg-log rules: - verbs: - get apiGroups: - postgresql.cnpg.io resources: - clusters - verbs: - list apiGroups: - resources: - pods - verbs: - get apiGroups: - resources: - pods/log 次の例は、プラグインの\ ``status`` コマンドを使用してクラスターステータスを取得するために必要な最小限の権限を持つロールを示しています。 .. code:: yaml apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: cnpg-status rules: - verbs: - get apiGroups: - postgresql.cnpg.io resources: - clusters - verbs: - list apiGroups: - resources: - pods - verbs: - create apiGroups: - resources: - pods/exec - verbs: - create apiGroups: - resources: - pods/proxy - verbs: - list apiGroups: - policy resources: - poddisruptionbudgets - verbs: - get apiGroups: - barmancloud.cnpg.io resources: - objectstores .. Note:: `resources` ごとおよび`apiGroups` ごとに動詞を制限したままにすると、意図した以上の権限を誤って付与するのを防ぐことができます。