EDB Postgres for Kubernetes Plugin ================================== EDB Postgres for Kubernetesは、Kubernetesでクラスターを管理するための\ ``kubectl`` のプラグインを提供します。プラグインは、OpenShift環境での\ ``oc`` でも動作します。 インストール ------------ さまざまな方法を使用して\ ``cnp`` プラグインをインストールできます。 .. Note:: エアギャップシステムの場合、以前にダウンロードしたファイルを使用して、パッケージマネージャーを介したインストールが良いオプションである場合があります。 インストールスクリプトを介して ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ .. code:: sh curl -sSfL \ https://github.com/EnterpriseDB/kubectl-cnp/raw/main/install.sh | \ sudo sh -s -- -b /usr/local/bin DebianまたはRedHatパッケージを使用する ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `releases section of the GitHub repository `_ では、関心のあるリリースKubernetesオペレーターのEDB Postgresと同じまたは新しいリリースを選択してください。その中には **Assets** セクションがあります。そのセクションには、さまざまなシステム用の事前ビルドパッケージが含まれています。その結果、標準の手順と手順に従って、システムにインストールできます。 Debianパッケージ ^^^^^^^^^^^^^^^^ たとえば、Intelベースの64ビットサーバーの場合、プラグインの1.25.0リリースをインストールしてみましょう。最初に、適切な\ ``.deb`` ファイルをダウンロードします。 .. code:: sh wget https://github.com/EnterpriseDB/kubectl-cnp/releases/download/v1.25.0/kubectl-cnp_1.25.0_linux_x86_64.deb \ --output-document kube-plugin.deb 次に、スーパーユーザー権限で、 ``dpkg`` を使用してローカルファイルからインストールします。 .. code:: console $ sudo dpkg -i kube-plugin.deb Selecting previously unselected package cnp. (Reading database ... 6688 files and directories currently installed.) Preparing to unpack kube-plugin.deb ... Unpacking kubectl-cnp (1.25.0) ... Setting up kubectl-cnp (1.25.0) ... RPMパッケージ ^^^^^^^^^^^^^ ``.rpm`` パッケージの例と同様に、Intel 64ビットマシンの1.25.0リリースをインストールしましょう。ファイル名を提供する\ ``--output`` フラグに注意してください。 .. code:: sh curl -L https://github.com/EnterpriseDB/kubectl-cnp/releases/download/v1.25.0/kubectl-cnp_1.25.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: cnp x86_64 1.25.0-1 @commandline 20 M Transaction Summary ==================================================================================================== Install 1 Package Total size: 20 M Installed size: 78 M Is this ok [y/N]: y サポートされているアーキテクチャ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ EDB Postgres for Kubernetesプラグインは、現在次のオペレーティングシステムとアーキテクチャ用にビルドされています。 - 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:: shell cat > kubectl_complete-cnp < kubectl_complete-cnp < .. Note:: プラグインは、標準出力チャンネルが端末に接続されているかどうかを自動的に検出します。このような場合、ANSIカラーをコマンド出力に追加する場合があります。色を無効にするには、コマンドで`--color=never` オプションを使用します。 インストールマニフェストの生成 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``cnp`` プラグインを使用して、オペレーターのインストールのためのYAMLマニフェストを生成できます。このオプションは通常、レプリカの数、インストール名前空間、監視する名前空間などのデフォルト構成をオーバーライドする場合に使用されます。 詳細および使用可能なオプションについては、次を実行します。 .. code:: sh kubectl cnp install generate --help 主なオプションは次のとおりです。 - ``-n`` オペレーターデフォルト\ ``postgresql-operator-system`` をインストールする名前空間を指定します。 - ``--control-plane`` trueに設定されている場合、オペレーターの展開には\ ``node-role.kubernetes.io/control-plane`` の許容範囲とアフィニティが含まれます。 - ``--replicas`` 展開内のレプリカの数を設定します。 - ``--watch-namespace`` 監視する名前空間のコンマ区切りリストを指定しますデフォルトすべての名前空間。 - ``--version`` ``1.23`` など、インストールするオペレーターのマイナーバージョンを定義します。マイナーバージョンが指定された場合、プラグインはそのマイナーバージョンの最新のパッチバージョンをインストールします。バージョンが指定されない場合、プラグインはオペレーターの最新の\ ``MAJOR.MINOR.PATCH`` バージョンをインストールします。 オペレーターをインストールするYAMLマニフェストを生成する\ ``generate`` コマンドの例は、次のとおりです。 .. code:: sh kubectl cnp install generate \ -n king \ --version 1.23 \ --replicas 3 \ --watch-namespace "albert, bb, freddie" \ > operator.yaml 上記のコマンドのフラグは、次の意味を持っています。 - ``-n king`` PG4Kオペレーターを\ ``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に対応します。 .. Important:: 上記のステータス情報は、異なる時間に異なる場所で取得されたため、わずかに一貫性のない戻り値が発生します。たとえば、メインヘッダーの`Current Write LSN` 場所は、2つの異なる時間間隔で取得されるため、インスタンスステータスの`Current LSN` フィールドとは異なる場合があります。 .. code:: sh kubectl cnp status sandbox .. code:: output Cluster Summary Name: default/sandbox System ID: 7423474350493388827 PostgreSQL Image: docker.enterprisedb.com/k8s_enterprise/edb-postgres-extended: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.25.0 k8s-eu-worker sandbox-2 0/604DE38 Standby (async) OK BestEffort 1.25.0 k8s-eu-worker2 sandbox-3 0/604DE38 Standby (async) OK BestEffort 1.25.0 k8s-eu-worker より詳細なステータス情報が必要な場合は、 ``--verbose`` オプションまたは略して\ ``-v`` を使用します。フラグが繰り返されるたびに、詳細レベルが増加します。 .. code:: sh kubectl cnp status sandbox --verbose .. code:: output Cluster Summary Name: default/sandbox System ID: 7423474350493388827 PostgreSQL Image: docker.enterprisedb.com/k8s_enterprise/edb-postgres-extended: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.25.0 k8s-eu-worker sandbox-2 0/6053720 Standby (async) OK BestEffort 1.25.0 k8s-eu-worker2 sandbox-3 0/6053720 Standby (async) OK BestEffort 1.25.0 k8s-eu-worker 追加の\ ``-v`` ``kubectl cnp status sandbox -v -v`` などを使用すると、PostgreSQL構成、HBA設定、および証明書を表示することもできます。 このコマンドは、 ``yaml`` および\ ``json`` 形式での出力もサポートしています。 プロモート ^^^^^^^^^^ このコマンドの意味は、クラスター内のポッドをプライマリに\ ``promote`` することにより、メンテナンス作業を開始したり、クラスターでのスイッチオーバー状況をテストしたりできます .. code:: sh kubectl cnp promote cluster-example cluster-example-2 または、インスタンスノード番号を使用してプロモートせることができます .. code:: sh kubectl cnp promote cluster-example 2 証明書 ^^^^^^ EDB Postgres for Kubernetesオペレーターを使用して作成されたクラスターは、CAと連携してTLS認証証明書に署名します。 証明書を取得するには、資格情報を保存するシークレットの名前、クラスター名、およびこの証明書のユーザーを提供する必要があります .. code:: sh kubectl cnp certificate cluster-cert --cnp-cluster cluster-example --cnp-user appuser シークレットが作成された後、 ``kubectl`` を使用して取得できます .. code:: sh kubectl get secret cluster-cert また、次のコマンドを使用してプレーンテキストで同じ内容を取得します。 .. code:: sh kubectl get secret cluster-cert -o json | jq -r .data | map(@base64d) | .[] 再起動 ^^^^^^ ``kubectl cnp restart`` コマンドは、次の2つの場合に使用できます。 - 特定のクラスターのロールアウト再起動を調整するようにオペレーターに要求します。これは、カスタム監視クエリを含むConfigMapなどのクラスター依存オブジェクトに構成変更を適用する場合に役立ちます。 - 単一インスタンスの再起動を要求します。インスタンスがクラスターのプライマリの場合はインプレース、またはレプリカの場合はポッドの削除と再作成。 .. code:: sh # this command will restart a whole cluster in a rollout fashion kubectl cnp restart [clusterName] # this command will restart a single instance, according to the policy above kubectl cnp restart [clusterName] [pod] インプレース・リスタートが要求されたが、スイッチオーバーなしでは変更を適用できない場合、スイッチオーバーはインプレース・リスタートより優先されます。この一般的なケースは、PostgreSQLイメージのマイナーアップグレードです。 .. Note:: ConfigMapsとSecretsをインスタンスによって**自動的に**リロードしたい場合は、キー`k8s.enterprisedb.io/reload` を持つラベルを追加できます。 リロード ^^^^^^^^ ``kubectl cnp reload`` コマンドは、オペレーターに、特定のクラスターの調整ループをトリガーするように要求します。これは、カスタム監視クエリを含むConfigMapなどのクラスター依存オブジェクトに構成変更を適用する場合に役立ちます。 次のコマンドは、特定のクラスターのすべての構成をリロードします。 .. code:: sh kubectl cnp reload [cluster_name] メンテナンス ^^^^^^^^^^^^ ``kubectl cnp maintenance`` コマンドは、名前空間全体で1つ以上のクラスターを変更し、メンテナンスウィンドウ値を設定するのに役立ちます。次のフィールドを変更します。 - .spec.nodeMaintenanceWindow.inProgress - .spec.nodeMaintenanceWindow.reusePVC これを使用して\ ``set`` および\ ``unset`` を引数として受け入れ、\ ``set`` の場合は\ ``inProgress`` を\ ``true`` に設定し、\ ``unset`` の場合は\ ``false`` に設定します。 デフォルトでは、 ``--reusePVC`` フラグが渡されない限り、 ``reusePVC`` は常に\ ``false`` に設定されます。 プラグインは、変更するクラスターのリストとその新しい値の確認を求めます。これが受け入れられる場合、このアクションはリスト内のすべてのクラスターに適用されます。 Kubernetesクラスター内のすべてのPostgreSQLをメンテナンスに設定する場合は、次のコマンドを記述するだけです。 .. code:: sh kubectl cnp 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 cnp report`` コマンドは、さまざまな情報をZIPファイルにバンドルします。実稼働環境のクラスターの問題をデバッグするために必要なコンテキストを提供することを目的としています。 ``operator`` および\ ``cluster`` の2つのサブコマンドがあります。 レポート演算子 ^^^^^^^^^^^^^^ ``operator`` サブコマンドは、オペレーターの展開、構成、およびイベントに関する情報の提供をオペレーターに要求します。 .. Important:: SecretsとConfigMapのすべての機密情報は編集されています。データマップには**キー**が表示されますが、値は空になります。フラグ`-S` / `--stopRedaction` は、リダクションを無効にし、値を表示します。自己の責任でのみ使用します。これはプライベートデータを共有します。 .. Note:: デフォルトでは、オペレーターログは収集されませんが、 `--logs` フラグを使用してオペレーターログ収集を有効にできます - **展開情報** オペレーター展開とオペレーターポッド - **configuration** オペレーター名前空間のシークレットとConfigMap - **events** オペレーター名前空間のイベント - **webhook configuration** Webhook構成の変更および検証 - **webhook service** Webhookサービス - **logs** JSON行形式のオペレーターポッドのログオプショナル、デフォルトではオフ このコマンドは、YAML形式のさまざまなマニフェストを含むZIPファイルを生成しますデフォルトでは、 ``-o`` フラグを使用してJSONに設定可能です。 ``-f`` フラグを使用して、結果ファイルに明示的に名前を付けます。 ``-f`` フラグを使用しない場合、zipファイルにデフォルトのタイムスタンプ付きファイル名が作成されます。 .. Note:: Reportプラグインは`kubectl` 規約に従い、名前空間によって制限されたオブジェクトを検索します。 PG4K Operatorは、通常、クラスターと同じ名前空間にインストールされません。例デフォルトのインストール名前空間はpostgresql-operator-systemです .. code:: sh kubectl cnp report operator -n での結果 .. code:: output Successfully written report to "report_operator_.zip" (format: "yaml") ``-f`` フラグを設定した場合 .. code:: sh kubectl cnp report operator -n -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/postgresql-operator-ca-secret.yaml inflating: report_operator_/manifests/postgresql-operator-webhook-cert.yaml ``--logs`` オプションをアクティブにすると、追加のサブディレクトリが表示されます。 .. code:: output Archive: report_operator_.zip creating: report_operator_/operator-logs/ inflating: report_operator_/operator-logs/postgresql-operator-controller-manager-66fb98dbc5-pxkmh-logs.jsonl .. Note:: プラグインはPREVIOUSオペレーターのログを取得しようとします。これは、再起動されたオペレーターを調査するときに役立ちます。すべての場合、現在のオペレーターログも取得しようとします。現在と以前のログが利用可能な場合、両方が表示されます。 .. code:: output ====== Begin of Previous Log ===== 2023-03-28T12:56:41.251711811Z {"level":"info","ts":"2023-03-28T12:56:41Z","logger":"setup","msg":"Starting EDB Postgres for Kubernetes Operator","version":"1.25.0","build":{"Version":"1.25.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 EDB Postgres for Kubernetes Operator","version":"1.25.0","build":{"Version":"1.25.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 postgresql-operator-ca-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 cnp report operator -n -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 postgresql-operator-ca-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 cnp report cluster [flags] ``operator`` サブコマンドとは異なり、 ``cluster`` サブコマンドの場合、クラスターがデフォルトの場合を除き、クラスター名前と、多くの場合、名前空間を指定する必要があることに注意してください。 .. code:: sh kubectl cnp report cluster example -f report.zip -n example_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 cnp report cluster example -n example_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 OpenShiftのサポート ''''''''''''''''''' ``report operator`` 指示子は、クラスターがOpenShiftで実行されているかどうかを自動的に検出し、クラスターサービスバージョンとインストールプランを取得して、\ ``openshift`` サブフォルダーの下のzipに自動的に追加します。 .. Note:: OpenShiftでは名前空間が非常に重要になります。 CNPのOpenShiftのデフォルトの名前空間は「openshift-operators」です。多くのほとんどのクライアントは、CNPオペレーターに別の名前空間を使用します。 .. code:: sh kubectl cnp report operator -n openshift-operators での結果 .. code:: sh Successfully written report to "report_operator_.zip" (format: "yaml") OpenShift関連のファイルは\ ``openshift`` サブフォルダーにあります。 .. code:: sh unzip report_operator_.zip cd report_operator_/ cd openshift head clusterserviceversions.yaml .. code:: yaml apiVersion: operators.coreos.com/v1alpha1 items: - apiVersion: operators.coreos.com/v1alpha1 kind: ClusterServiceVersion metadata: annotations: alm-examples: |- [ { "apiVersion": "postgresql.k8s.enterprisedb.io/v1", ログ ^^^^ ``kubectl cnp logs`` コマンドを使用すると、KubernetesのEDB Postgresに関連するポッドのコレクションのログを一度にたどることができます。 現時点では、使用可能なサブコマンドが1つあります\ ``cluster`` 。 クラスターログ ^^^^^^^^^^^^^^ ``cluster`` サブコマンドは、クラスターのすべてのポッドログを単一のストリームまたはファイルに収集します。これは、単一のターミナルウィンドウで、コマンドを1回呼び出して、すべてのポッドログを取得できることを意味します。 すべてのcnpプラグインサブコマンドと同様に、\ ``-h`` フラグの指示とヘルプを取得できます。 ``kubectl cnp logs cluster -h`` ``logs`` コマンドは、 ``--timestamps`` フラグを使用しない限り、JSON行形式でログを表示します。その場合、人間が判読可能なタイムスタンプが各行の先頭に追加されます。この場合、行は有効なJSONでなくなり、 ``jq`` などのツールが目的のように動作しない場合があります。 ``logs cluster`` サブコマンドに\ ``-f`` フラグ別名\ ``--follow`` が指定されている場合、クラスターポッドログをたどり、コマンドが呼び出された後にクラスターで作成された新しいポッドを監視します。再起動または再作成されたポッドを含む、見つかった新しいポッドもポッドが追跡されます。ログは端末の標準出力に表示されます。このコマンドは、クラスターにポッドが残っていない場合、またはユーザーによって中断された場合にのみ終了します。 ``-f`` オプションを指定せずに\ ``logs`` が呼び出された場合、呼び出されるまですべてのクラスターポッドからログを読み取り、ターミナルの標準出力に表示してから終了します。 ``-o`` または\ ``--output`` フラグを提供して、標準出力で表示する代わりに、ログを保存するファイルの名前を指定できます。 ``--tail`` フラグを使用して、クラスター内の各ポッドから取得するログ行数を指定できます。デフォルトでは、 ``logs cluster`` サブコマンドは、クラスター内の各ポッドからのすべてのログを表示します。 「follow」フラグ\ ``-f`` と組み合わせると、\ ``--tail`` で指定された数のログが現在まで取得され、それ以降新しいログが追跡されます。 注他の\ ``cnp`` プラグインコマンドとは異なり、 ``-f`` はファイルを指定するのではなく「フォロー」を示すために使用されます。これは、 ``kubectl logs`` の規則に従いますが、 ``-f`` は、ログに従う必要があることを意味します。 使用法 .. code:: sh kubectl cnp logs cluster [flags] ``-f`` オプションを使用して次のことを行います。 .. code:: sh kubectl cnp report cluster cluster-example -f ``--tail`` オプションを使用して各ポッドから3行を表示し、 ``-f`` オプションを追跡します。 .. code:: sh kubectl cnp report cluster cluster-example -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 cnp logs cluster cluster-example --output my-cluster.log Successfully written logs to "my-cluster.log" かなり ^^^^^^ ``pretty`` サブコマンドは、標準入力からログストリームを読み取り、人間が判読可能な出力にフォーマットし、タイムスタンプでエントリを並べ替えようとします。 次の例に示すように、\ ``kubectl cnp logs cluster`` と組み合わせて使用できます。 .. code:: console $ kubectl cnp logs cluster cluster-example | kubectl cnp logs pretty 2024-10-15T17:35:00.336 INFO cluster-example-1 instance-manager Starting EDB Postgres for Kubernetes 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 [...] または、次の例にあるように、\ ``stern`` 、\ ``kubectl logs`` など、JSON形式でPG4Kログを生成する他のコマンドと組み合わせて使用できます。 .. code:: console $ kubectl logs cluster-example-1 | kubectl cnp logs pretty 2024-10-15T17:35:00.336 INFO cluster-example-1 instance-manager Starting EDB Postgres for Kubernetes 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 cnp logs cluster cluster-example | kubectl cnp 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 cnp logs cluster cluster-example | kubectl cnp logs pretty --sorting-group-size=3 2024-10-15T17:35:20.426 INFO cluster-example-2 instance-manager Starting EDB Postgres for Kubernetes 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 cnp destroy`` コマンドは、インスタンスと、関連するすべてのPVCをKubernetesクラスターから削除するのに役立ちます。 オプションの\ ``--keep-pvc`` フラグを指定すると、PVCを保持したまま、インスタンスによって設定されたすべての\ ``metadata.ownerReferences`` を削除できます。さらに、PVCの\ ``k8s.enterprisedb.io/pvcStatus`` ラベルが\ ``ready`` から\ ``detached`` に変更され、使用されなくなったことを示します。 ``--keep-pvc`` フラグを指定せずにコマンドを再度実行すると、分離されたPVCが削除されます。 使用法 .. code:: sh kubectl cnp destroy [CLUSTER_NAME] [INSTANCE_ID] 次の例は、\ ``cluster-example-2`` ポッドと関連するPVCを削除します。 .. code:: sh kubectl cnp destroy cluster-example 2 クラスターハイバーネーション ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ データを保持しながらKubernetes ``Cluster`` のEDB Postgresの実行を一時停止し、後でアクティビティを再開することが必要になる場合があります。この機能を **クラスターハイバーネーション** と呼びます。 ハイバネーションは、 ``kubectl cnp hibernate [on|off]`` コマンドを介してのみ使用できます。 KubernetesクラスターのEDB Postgresを休止することは、 PostgreSQLプライマリインスタンスに属するPVCを除き、クラスターによって生成されたすべてのリソースを破棄することを意味します。 次の方法でクラスターを休止状態にできます。 .. code:: sh kubectl cnp hibernate on これにより、 1. すべてのPostgreSQLインスタンスをシャットダウンする 2. プライマリインスタンスのデータを含むPVCを切断し、最新のデータベースステータスと最新のクラスター構成でアノテーションを付けます。 3. 生成されたすべてのリソースを含む\ ``Cluster`` リソースを削除します-前述のPVCを除く 休止している場合、KubernetesクラスターのEDB PostgresはPVCのグループだけで表され、\ ``PGDATA`` を含むものには、\ ``pg_controldata`` のコンテンツを含む最新の利用可能なステータスで注釈が付けられます。 .. Warning:: フェンシングもハイバーネーションプロシージャーの一部であるため、フェンスされたインスタンスを持つクラスターは休止できません。 エラーが発生した場合、オペレーターはプロシージャーを元に戻すことはできません。次のコマンドを使用して操作を強制できます。 .. code:: sh kubectl cnp hibernate on cluster-example --force 休止状態のクラスターは、次の方法で再開できます。 .. code:: sh kubectl cnp hibernate off クラスターが休止状態になると、最後の構成と、シャットダウン後にPostgreSQLのステータスを表示できます。それは次の方法で行うことができます。 .. code:: sh kubectl cnp hibernate status pgbenchを使用したデータベースのベンチマーク ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Pgbenchは、次のコマンドを使用して、既存のPostgreSQLクラスターに対して実行できます。 .. code:: sh kubectl cnp pgbench -- --time 30 --client 1 --jobs 1 詳細については、 :ref:`Benchmarking pgbench section ` を参照してください。 fioを使用したストレージのベンチマーク ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ fioは、次のコマンドを使用して既存のストレージクラスで実行できます。 .. code:: sh kubectl cnp fio -n 詳細については、 :ref:`Benchmarking fio section ` を参照してください。 新しい物理バックアップの要求 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``kubectl cnp backup`` コマンドは、新しい\ ``Backup`` リソースを作成することにより、既存のPostgresクラスターの新しい物理バックアップを要求します。 .. Note:: リリース1.21から、 `backup` コマンドは、新しいフラグ`-m` を受け入れて、バックアップ方法を指定します。ボリュームスナップショットを使用してバックアップを要求するには、 `-m volumeSnapshot` を設定します 次の例は、特定のクラスターのオンデマンドバックアップを要求します。 .. code:: sh kubectl cnp backup [cluster_name] または、ボリュームスナップショットを使用する場合 .. code:: sh kubectl cnp backup [cluster_name] -m volumeSnapshot 作成されるバックアップには、要求時間に基づいた名前が付けられます。 .. code:: console $ kubectl cnp backup cluster-example backup/cluster-example-20230121002300 created デフォルトでは、新しく作成されるバックアップは、クラスターで定義されたバックアップターゲットポリシーを使用して、実行するインスタンスを選択します。ただし、このポリシーは\ ``--backup-target`` オプションでオーバーライドできます。 ボリュームスナップショットバックアップの場合、 ``--online`` オプションを使用して、オンライン/ホットバックアップまたはオフライン/コールドバックアップを要求することもできます。さらに、 ``--immediate-checkpoint`` および\ ``--wait-for-archive`` オプションを明示的に設定することにより、オンラインバックアップを調整することもできます。 :ref:`Appendix A - Common object stores for backups ` には、構成設定に関する詳細情報が含まれています。 psqlの起動 ^^^^^^^^^^ ``kubectl cnp psql`` コマンドは、実際のポッドから実行しているかのように、既存のPostgresクラスターに接続された新しいPostgreSQL対話型フロントエンドプロセス psqlを起動します。これは、 ``postgres`` ユーザーを使用することを意味します。 .. Important:: `postgres` ユーザーとして接続するため、運用環境では、この方法は許可された担当者のみが細心の注意を払って使用する必要があります。 .. code:: console $ kubectl cnp psql cluster-example psql (17.0 (Debian 17.0-1.pgdg110+1)) Type "help" for help. postgres=# デフォルトでは、コマンドはプライマリインスタンスに接続します。ユーザーは\ ``--replica`` オプションを使用して、レプリカに対して作業することを選択できます。 .. code:: console $ kubectl cnp psql --replica cluster-example psql (17.0 (Debian 17.0-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`` 実行可能ファイルに到達できる必要があります。 !!!注 OpenShiftで実行されているインスタンスに接続する場合、 :ref:`security measure built intoOpenShift ` のため、ユーザー名を\ ``psql`` コマンドに明示的に渡す必要があります。 .. code:: sh kubectl cnp psql cluster-example -- -U postgres .. :: ### Postgresクラスターのスナップショットの作成 .. Warning:: `kubectl cnp snapshot` コマンドは削除されました。 :ref:`新しい物理バックアップの要求 <新しい物理バックアップの要求>` を使用して、ボリュームスナップショットを使用したバックアップを要求してください。 評価/デモ目的でのみpgAdmin4を使用する ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `pgAdmin `_ は、PostgreSQLの最も人気のある機能が豊富なオープンソースの管理および開発プラットフォームです。プロジェクトの詳細については、公式 `documentation `_ を参照してください。 pgAdmin開発チームが公式のDockerコンテナイメージを維持していることを考えると、標準のKubernetes展開として環境にpgAdminをインストールできます。 .. Important:: Kubernetes運用環境でのpgAdminの展開は、このドキュメントの範囲を超えており、より広範にはEDB Postgres for Kubernetesプロジェクトの範囲を超えています。 ただし、 **デモと評価の目的で** 、KubernetesのEDB Postgresは適切なソリューションを提供します。 ``cnp`` プラグインは\ ``pgadmin4`` コマンドを実装し、特定のデータベース\ ``Cluster`` に接続し、\ ``kind`` などのローカル環境でそのコンテンツをナビゲートする簡単な方法を提供します。 たとえば、次のとおりに\ ``cluster-example`` クラスターのpgAdmin4のデモ展開をインストールできます。 .. code:: sh kubectl cnp 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 cnp pgadmin4 --dry-run cluster-example pgAdmin4はデスクトップまたはサーバーモードでインストールできます。デフォルトはサーバーです。 ``server`` モードでは、ランダムに生成されたパスワードを使用して認証が必要で、ユーザーは接続するデータベースを手動で指定する必要があります。 一方、\ ``desktop`` モードは、認証を必要とせずにpgAdmin Webインターフェイスを開始します。 ``app`` ユーザーとして\ ``app`` データベースに自動的に接続するため、 ``kind`` を使用したローカル展開などの簡単なデモに最適です。 .. code:: sh kubectl cnp pgadmin4 --mode desktop cluster-example デモが終了した後、次のコマンドを実行してpgAdmin展開を確実に終了します。 .. code:: sh kubectl cnp pgadmin4 --dry-run cluster-example | kubectl delete -f - .. Warning:: プラグインを使用してpgAdminを運用環境に展開しないでください。 ロジカルレプリケーションのパブリケーション ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``cnp publication`` コマンドグループは、 :ref:`PostgreSQL logical replication publications ` の作成と削除を合理化するように設計されています。これらのコマンドは、主に、特にリモートのPostgreSQLデータベースでの論理レプリケーションパブリケーションの作成を支援することを目的としていることに注意してください。 .. Warning:: これらのコマンドを使用する前に、PostgreSQLのネイティブ論理レプリケーションシステムの機能と制限の両方をしっかりと理解することが重要です。特に、 :ref:`logical replication restrictions ` に注意してください。 新しいパブリケーションの作成 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 論理レプリケーションパブリケーションを作成するには、 ``cnp publication create`` コマンドを使用します。このコマンドの基本的な構造は次のとおりです。 .. code:: sh kubectl cnp publication create \ --publication \ [--external-cluster ] [options] 2つの主な使用例があります。 - ``--external-cluster`` の場合 このオプションを使用して、外部クラスターつまり ``externalClusters`` スタンザで定義された上にパブリケーションを作成します。コマンドは\ ```` から発行されますが、パブリケーションは\ ```` のデータ用です。 - ``--external-cluster`` なし このオプションを使用して、 ```` PostgreSQL ``Cluster`` デフォルトでは ``app`` データベースにパブリケーションを作成します。 .. Warning:: 外部クラスターに接続するときは、指定されたユーザーに`CREATE PUBLICATION` コマンドを実行するための十分な権限があることを確認してください。 `CREATE PUBLICATION `_ と同様に、いくつかのオプションがあります コマンドを使用して、レプリケートするテーブルのグループを定義します。重要なオプションには次のものが含まれます。 - ``--all-tables`` オプションを指定した場合、パブリケーション\ ``FOR ALL TABLES`` を作成します。 - または、次の複数のオカレンスを指定できます。 - ``--table`` 特定のテーブル式を追加します。 - ``--schema`` 指定されたデータベーススキーマPostgreSQL 15から利用可能にあるすべてのテーブルを含めます。 ``--dry-run`` オプションを使用すると、プラグインが実行するSQLコマンドをプレビューできます。 追加情報と詳細な手順については、次のコマンドを入力してください。 .. code:: sh kubectl cnp publication create --help 例 '' ``source-cluster`` および\ ``destination-cluster`` を指定して、 ``source-cluster`` 上のデータのパブリケーションを作成します。 ``destination-cluster`` には、\ ``source-cluster`` を指す\ ``externalClusters`` スタンザにエントリーがあります。 次を実行できます。 .. code:: sh kubectl cnp publication create destination-cluster \ --external-cluster=source-cluster --all-tables これは、 ``destination-cluster`` でSQLコマンドを実行し、 ``source-cluster`` のすべてのテーブルのパブリケーションを作成します。 または、その代わりに、次を実行できます。 .. code:: sh kubectl cnp publication create source-cluster \ --publication=app --all-tables これは、 ``source-cluster`` 内のすべてのテーブルに\ ``app`` という名前のパブリケーションを作成し、ソースクラスターでSQLコマンドを実行します。 .. Note:: イラストとインスピレーションのために提供されている2つのサンプルファイル :ref:`logical-source ` および :ref:`logical-destination ` があります。 パブリケーションの削除 ^^^^^^^^^^^^^^^^^^^^^^ ``cnp publication drop`` コマンドは、パブリケーション名、クラスター名、オプションの外部クラスターを含む同様のキーオプションを提供することにより、 ``create`` コマンドをシームレスに補完します。次のコマンド構造を使用して\ ``PUBLICATION`` をドロップできます。 .. code:: sh kubectl cnp publication drop \ --publication \ [--external-cluster ] [options] さらに詳細と正確な指示にアクセスするには、次のコマンドを使用します。 .. code:: sh kubectl cnp publication drop --help 論理レプリケーションサブスクリプション ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``cnp subscription`` コマンドグループは、 :ref:`PostgreSQL logical replication subscriptions ` の作成と削除を簡素化するように設計された専用のコマンドセットです。これらのコマンドは、特にリモートのPostgreSQLデータベースを扱う場合、論理レプリケーションサブスクリプションの確立を支援するように特別に作成されています。 .. Warning:: これらのコマンドを使用する前に、PostgreSQLのネイティブ論理レプリケーションシステムの機能と制限の両方を包括的に理解することが重要です。特に、 :ref:`logical replication restrictions ` に注意してください。 サブスクリプション管理に加えて、ソースクラスターからすべてのシーケンスを同期するための役立つコマンドを提供します。その適用性は異なる場合がありますが、このコマンドは、メジャーアップグレードまたはリモートサーバーからのデータのインポートを含むシナリオで特に役立ちます。 新しいサブスクリプションの作成 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 論理レプリケーションサブスクリプションを作成するには、 ``cnp subscription create`` コマンドを使用します。このコマンドの基本的な構造は次のとおりです。 .. code:: sh kubectl cnp subscription create \ --subscription \ --publication \ --external-cluster \ [options] このコマンドは、 ```` の\ ``externalClusters`` スタンザで定義されているとおりに、指定された外部クラスター内の指定されたパブリケーションを対象としたサブスクリプションを構成します。 追加情報と詳細な手順については、次のコマンドを入力してください。 .. code:: sh kubectl cnp subscription create --help .. _例-1: 例 '' パブリケーションに関するセクションと同様に、\ ``source-cluster`` および\ ``destination-cluster`` があり、\ ``app`` というパブリケーションを既に作成しています。 次のコマンド .. code:: sh kubectl cnp subscription create destination-cluster \ --external-cluster=source-cluster \ --publication=app --subscription=app は、宛先クラスターに\ ``app`` のサブスクリプションを作成します。 .. Warning:: 非実稼働環境でのテストサブスクリプションを優先して、実稼働設定に実装する前にその有効性を確認し、潜在的な問題を特定します。 .. Note:: イラストとインスピレーションのために提供されている2つのサンプルファイル :ref:`logical-source ` および :ref:`logical-destination ` 。 サブスクリプションの削除 ^^^^^^^^^^^^^^^^^^^^^^^^ ``cnp subscription drop`` コマンドは、 ``create`` コマンドをシームレスに補完します。次のコマンド構造を使用して\ ``SUBSCRIPTION`` をドロップできます。 .. code:: sh kubectl cnp subcription drop \ --subscription \ [options] さらに詳細と正確な指示にアクセスするには、次のコマンドを使用します。 .. code:: sh kubectl cnp subscription drop --help シーケンスの同期 ^^^^^^^^^^^^^^^^ パブリケーションとサブスクリプションを介して実装されるPostgreSQL論理レプリケーションの重要な制約の1つは、シーケンス同期の欠如です。これは、論理レプリケーションを利用する場合に特に関連します ライブデータベース移行、特にPostgreSQLの上位バージョンの場合。このプロセスの重要な手順には、アプリケーションを新しいデータベース_cutover_に移行する前にシーケンスの更新が含まれます。 この制限に対処するために、 ``cnp subscription sync-sequences`` コマンドは解決策を提供します。このコマンドは、ソースデータベースとの接続を確立し、関連するすべてのシーケンスを取得し、その後、一致するIDでローカルシーケンスを更新しますデータベーススキーマとシーケンス名に基づいて。 以下に示すようにコマンドを使用できます。 .. code:: sh kubectl cnp subscription sync-sequences \ --subscription \ 包括的な詳細と特定の手順については、次のコマンドを使用します。 .. code:: sh kubectl cnp subscription sync-sequences --help .. _例-2: 例 '' パブリケーションとサブスクリプションに関する以前のセクションと同様に、\ ``source-cluster`` および\ ``destination-cluster`` があります。パブリケーションとサブスクリプションは、両方とも\ ``app`` と呼ばれますが、既に存在します。 次のコマンドは、\ ``app`` サブスクリプションに関係するシーケンスをソースクラスターから宛先クラスターに同期します。 .. code:: sh kubectl cnp subscription sync-sequences destination-cluster \ --subscription=app .. Warning:: 非実稼働環境でのテストサブスクリプションを優先して、実稼働設定に展開する前にその有効性を保証し、潜在的な問題を検出します。 K9sとの統合 ----------- ``cnp`` プラグインは、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,"configmaps: get deployments: get events: list pods: list pods/log: get secrets: get services: get mutatingwebhookconfigurations: list[^1] validatingwebhookconfigurations: list[^1] If OLM is present on the K8s cluster, also: clusterserviceversions: list installplans: list subscriptions: list" restart,"clusters: get,patch pods: get,delete" status,clusters: get pods: list pods/exec: create pods/proxy: create PDBs: list 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: cnp-log rules: - verbs: - get apiGroups: - postgresql.k8s.enterprisedb.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: cnp-status rules: - verbs: - get apiGroups: - postgresql.k8s.enterprisedb.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 .. Important:: `resources` ごとおよび`apiGroups` ごとに動詞を制限したままにすると、意図した以上の権限を誤って付与するのを防ぐことができます。