EDB Postgres® AI for CloudNativePG™ Cluster Plugin

EDB Postgres® AI for CloudNativePG™ Cluster Plugin#

CloudNativePG™クラスターのEDB Postgres® AIは、Kubernetesでクラスターを管理するためのkubectl のプラグインを提供します。プラグインは、OpenShift環境でのoc でも動作します。

インストール#

さまざまな方法を使用してcnp プラグインをインストールできます。

注釈

エアギャップシステムの場合、以前にダウンロードしたファイルを使用して、パッケージマネージャーを介したインストールが良いオプションである場合があります。

インストールスクリプトを介して#

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 では、関心のあるリリースに移動できますCloudNativePG™クラスターオペレーターのEDB Postgres® AIと同じまたは新しいリリースを選択します。その中には Assets セクションがあります。そのセクションには、さまざまなシステム用の事前ビルドパッケージが含まれています。その結果、標準の手順と手順に従って、システムにインストールできます。

Debianパッケージ#

たとえば、Intelベースの64ビットサーバーの場合、プラグインの1.29.0リリースをインストールしてみましょう。最初に、適切な.deb ファイルをダウンロードします。

wget https://github.com/EnterpriseDB/kubectl-cnp/releases/download/v1.29.0/kubectl-cnp_1.29.0_linux_x86_64.deb \
  --output-document kube-plugin.deb

次に、スーパーユーザー権限で、 dpkg を使用してローカルファイルからインストールします。

$ 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.29.0) ...
Setting up kubectl-cnp (1.29.0) ...

RPMパッケージ#

.rpm パッケージの例と同様に、Intel 64ビットマシンの1.29.0リリースをインストールしましょう。ファイル名を提供する--output フラグに注意してください。

curl -L https://github.com/EnterpriseDB/kubectl-cnp/releases/download/v1.29.0/kubectl-cnp_1.29.0_linux_x86_64.rpm \
  --output kube-plugin.rpm

次に、スーパーユーザー権限を使用して、yum でインストールすると、使用する準備が整います。

$ 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.29.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® AI for 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 が含まれていると仮定すると、これは次のコマンドで実行できます。

cat > kubectl_complete-cnp <<EOF
# !/usr/bin/env sh

#  Call the __complete command passing it all arguments

kubectl cnp __complete "\$@"
EOF

chmod +x kubectl_complete-cnp

#  Important: the following command may require superuser permission

sudo mv kubectl_complete-cnp /usr/local/bin

使用する#

プラグインがインストールおよび展開されたら、次のように使用を開始できます。

kubectl cnp <command> <args...>

注釈

プラグインは、標準出力チャンネルが端末に接続されているかどうかを自動的に検出します。このような場合、ANSIカラーをコマンド出力に追加する場合があります。色を無効にするには、コマンドで`--color=never` オプションを使用します。

インストールマニフェストの生成#

cnp プラグインを使用して、オペレーターのインストールのためのYAMLマニフェストを生成できます。このオプションは通常、レプリカの数、インストール名前空間、監視する名前空間などのデフォルト構成をオーバーライドする場合に使用されます。

詳細および使用可能なオプションについては、次を実行します。

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 コマンドの例は、次のとおりです。

kubectl cnp install generate \
  -n king \
  --version 1.23 \
  --replicas 3 \
  --watch-namespace "albert, bb, freddie" \
  > operator.yaml

上記のコマンドのフラグは、次の意味を持っています。

  • -n king {{name.abbr}}演算子を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に対応します。

kubectl cnp status sandbox

Cluster Summary
Name:                default/sandbox
System ID:           7423474350493388827
PostgreSQL Image:    docker.enterprisedb.com/k8s/edb-postgres-extended:18.1-standard-ubi9
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.29.0           k8s-eu-worker
sandbox-2  0/604DE38    Standby (async)   OK      BestEffort  1.29.0           k8s-eu-worker2
sandbox-3  0/604DE38    Standby (async)   OK      BestEffort  1.29.0           k8s-eu-worker

より詳細なステータス情報が必要な場合は、 --verbose オプションまたは略して-v を使用します。フラグが繰り返されるたびに、詳細レベルが増加します。

kubectl cnp status sandbox --verbose

Cluster Summary
Name:                default/sandbox
System ID:           7423474350493388827
PostgreSQL Image:    docker.enterprisedb.com/k8s/edb-postgres-extended:18.1-standard-ubi8
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.29.0           k8s-eu-worker
sandbox-2  0/6053720    Standby (async)   OK      BestEffort  1.29.0           k8s-eu-worker2
sandbox-3  0/6053720    Standby (async)   OK      BestEffort  1.29.0           k8s-eu-worker

追加の-v kubectl cnp status sandbox -v -v などを使用すると、PostgreSQL構成、HBA設定、および証明書を表示することもできます。

このコマンドは、 yaml およびjson 形式での出力もサポートしています。

プロモート#

このコマンドの意味は、クラスター内のポッドをプライマリにpromote することにより、メンテナンス作業を開始したり、クラスターでのスイッチオーバー状況をテストしたりできます

kubectl cnp promote cluster-example cluster-example-2

または、インスタンスノード番号を使用してプロモートせることができます

kubectl cnp promote cluster-example 2

証明書#

EDB Postgres® AI for CloudNativePG™ クラスターオペレーターを使用して作成されたクラスターは、CAと連携してTLS認証証明書に署名します。

証明書を取得するには、資格情報を保存するシークレットの名前、クラスター名、およびこの証明書のユーザーを提供する必要があります

kubectl cnp certificate cluster-cert --cnp-cluster cluster-example --cnp-user appuser

シークレットが作成された後、 kubectl を使用して取得できます

kubectl get secret cluster-cert

また、次のコマンドを使用してプレーンテキストで同じ内容を取得します。

kubectl get secret cluster-cert -o json | jq -r .data | map(@base64d) | .[]

再起動#

kubectl cnp restart コマンドは、次の2つの場合に使用できます。

  • 特定のクラスターのロールアウト再起動を調整するようにオペレーターに要求します。これは、カスタム監視クエリを含むConfigMapなどのクラスター依存オブジェクトに構成変更を適用する場合に役立ちます。

  • 単一インスタンスの再起動を要求します。インスタンスがクラスターのプライマリの場合はインプレース、またはレプリカの場合はポッドの削除と再作成。

#  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イメージのマイナーアップグレードです。

注釈

ConfigMapsとSecretsをインスタンスによって**自動的に**リロードしたい場合は、キー`k8s.enterprisedb.io/reload` を持つラベルをそれに追加できます。

リロード#

kubectl cnp reload コマンドは、オペレーターに、特定のクラスターの調整ループをトリガーするように要求します。これは、カスタム監視クエリを含むConfigMapなどのクラスター依存オブジェクトに構成変更を適用する場合に役立ちます。

次のコマンドは、特定のクラスターのすべての構成をリロードします。

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をメンテナンスに設定する場合は、次のコマンドを記述するだけです。

kubectl cnp maintenance set --all-namespaces

更新するすべてのクラスターのリストが得られます

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 サブコマンドは、オペレーターの展開、構成、およびイベントに関する情報の提供をオペレーターに要求します。

注釈

デフォルトでは、オペレーターログは収集されませんが、 --logs フラグを使用してオペレーターログ収集を有効にできます

  • 展開情報 オペレーター展開とオペレーターポッド

  • configuration オペレーター名前空間のシークレットとConfigMap

  • events オペレーター名前空間のイベント

  • webhook configuration Webhook構成の変更および検証

  • webhook service Webhookサービス

  • logs JSON行形式のオペレーターポッドのログオプショナル、デフォルトではオフ

このコマンドは、YAML形式のさまざまなマニフェストを含むZIPファイルを生成しますデフォルトでは、 -o フラグを使用してJSONに設定可能です。 -f フラグを使用して、結果ファイルに明示的に名前を付けます。 -f フラグを使用しない場合、zipファイルにデフォルトのタイムスタンプ付きファイル名が作成されます。

注釈

Reportプラグインは`kubectl` 規約に従い、名前空間によって制限されたオブジェクトを検索します。 {{name.short}}オペレーターは、通常、クラスターと同じ名前空間にインストールされません。例デフォルトのインストール名前空間はpostgresql-operator-systemです

kubectl cnp report operator -n <namespace>

での結果

Successfully written report to "report_operator_<TIMESTAMP>.zip" (format: "yaml")

-f フラグを設定した場合

kubectl cnp report operator -n <namespace> -f reportRedacted.zip

ファイルを解凍すると、タイムスタンプ付きのトップレベルフォルダーが生成され、ディレクトリを整理します。

unzip reportRedacted.zip

結果は次のとおりです。

Archive:  reportRedacted.zip
   creating: report_operator_<TIMESTAMP>/
   creating: report_operator_<TIMESTAMP>/manifests/
  inflating: report_operator_<TIMESTAMP>/manifests/deployment.yaml
  inflating: report_operator_<TIMESTAMP>/manifests/operator-pod.yaml
  inflating: report_operator_<TIMESTAMP>/manifests/events.yaml
  inflating: report_operator_<TIMESTAMP>/manifests/validating-webhook-configuration.yaml
  inflating: report_operator_<TIMESTAMP>/manifests/mutating-webhook-configuration.yaml
  inflating: report_operator_<TIMESTAMP>/manifests/webhook-service.yaml
  inflating: report_operator_<TIMESTAMP>/manifests/postgresql-operator-ca-secret.yaml
  inflating: report_operator_<TIMESTAMP>/manifests/postgresql-operator-webhook-cert.yaml

--logs オプションをアクティブにすると、追加のサブディレクトリが表示されます。

Archive:  report_operator_<TIMESTAMP>.zip
  <snipped …>
  creating: report_operator_<TIMESTAMP>/operator-logs/
  inflating: report_operator_<TIMESTAMP>/operator-logs/postgresql-operator-controller-manager-66fb98dbc5-pxkmh-logs.jsonl

注釈

プラグインは、 PREVIOUSオペレーターのログを取得しようとします。これは、再起動されたオペレーターを調査するときに役立ちます。すべての場合、現在のオペレーターログも取得しようとします。現在と以前のログが利用可能な場合、両方が表示されます。

====== 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.29.0","build":{"Version":"1.29.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"}
  <snipped …>

====== 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.29.0","build":{"Version":"1.29.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 … ガードが表示されますが、中にコンテンツはありません。

機密情報がデフォルトで編集されていることを確認できます。

cd report_operator_<TIMESTAMP>/manifests/
head postgresql-operator-ca-secret.yaml

data:
  ca.crt: ""
  ca.key: ""
metadata:
  creationTimestamp: "2022-03-22T10:42:28Z"
  managedFields:
  - apiVersion: v1
    fieldsType: FieldsV1
    fieldsV1:

-S --stopRedaction オプションを有効にすると、シークレットが表示されます。

kubectl cnp report operator -n <namespace> -f reportNonRedacted.zip -S

機密情報を表示しようとしていることを示すリマインダーが届きます。

WARNING: secret Redaction is OFF. Use it with caution
Successfully written report to "reportNonRedacted.zip" (format: "yaml")

unzip reportNonRedacted.zip
head postgresql-operator-ca-secret.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 は無効になっていることに注意してください。

注釈

デフォルトでは、クラスターログは収集されませんが、 --logs フラグを使用してクラスターログ収集を有効にできます

使用法

kubectl cnp report cluster <clusterName> [flags]

operator サブコマンドとは異なり、 cluster サブコマンドの場合、クラスターがデフォルトの場合を除き、クラスター名前と、多くの場合、名前空間を指定する必要があることに注意してください。

kubectl cnp report cluster example -f report.zip -n example_namespace

そして

unzip report.zip

Archive:  report.zip
   creating: report_cluster_example_<TIMESTAMP>/
   creating: report_cluster_example_<TIMESTAMP>/manifests/
  inflating: report_cluster_example_<TIMESTAMP>/manifests/cluster.yaml
  inflating: report_cluster_example_<TIMESTAMP>/manifests/cluster-pods.yaml
  inflating: report_cluster_example_<TIMESTAMP>/manifests/cluster-jobs.yaml
  inflating: report_cluster_example_<TIMESTAMP>/manifests/events.yaml

--logs フラグを使用して、ポッドとジョブログをZIPに追加できることに注意してください。

kubectl cnp report cluster example -n example_namespace --logs

結果は次のとおりです。

Successfully written report to "report_cluster_example_<TIMESTAMP>.zip" (format: "yaml")

unzip report_cluster_<TIMESTAMP>.zip

Archive:  report_cluster_example_<TIMESTAMP>.zip
   creating: report_cluster_example_<TIMESTAMP>/
   creating: report_cluster_example_<TIMESTAMP>/manifests/
  inflating: report_cluster_example_<TIMESTAMP>/manifests/cluster.yaml
  inflating: report_cluster_example_<TIMESTAMP>/manifests/cluster-pods.yaml
  inflating: report_cluster_example_<TIMESTAMP>/manifests/cluster-jobs.yaml
  inflating: report_cluster_example_<TIMESTAMP>/manifests/events.yaml
   creating: report_cluster_example_<TIMESTAMP>/logs/
  inflating: report_cluster_example_<TIMESTAMP>/logs/cluster-example-full-1.jsonl
   creating: report_cluster_example_<TIMESTAMP>/job-logs/
  inflating: report_cluster_example_<TIMESTAMP>/job-logs/cluster-example-full-1-initdb-qnnvw.jsonl
  inflating: report_cluster_example_<TIMESTAMP>/job-logs/cluster-example-full-2-join-tvj8r.jsonl

OpenShiftのサポート#

report operator 指示子は、クラスターがOpenShiftで実行されているかどうかを自動的に検出し、クラスターサービスバージョンとインストールプランを取得して、openshift サブフォルダーの下のzipに自動的に追加します。

注釈

OpenShiftでは名前空間が非常に重要になります。 CNPのOpenShiftのデフォルトの名前空間は「openshift-operators」です。多くのほとんどのクライアントは、CNPオペレーターに別の名前空間を使用します。

kubectl cnp report operator -n openshift-operators

での結果

Successfully written report to "report_operator_<TIMESTAMP>.zip" (format: "yaml")

OpenShift関連のファイルはopenshift サブフォルダーにあります。

unzip report_operator_<TIMESTAMP>.zip
cd report_operator_<TIMESTAMP>/
cd openshift
head clusterserviceversions.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 コマンドを使用すると、CloudNativePG™クラスターのEDB Postgres® AIに関連するポッドのコレクションのログを一度にたどることができます。

現時点では、使用可能なサブコマンドが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 は、ログに従う必要があることを意味します。

使用法

kubectl cnp logs cluster <clusterName> [flags]

-f オプションを使用して次のことを行います。

kubectl cnp report cluster cluster-example -f

--tail オプションを使用して各ポッドから3行を表示し、 -f オプションを追跡します。

kubectl cnp report cluster cluster-example -f --tail 3

{"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 を指定する場合

$ kubectl cnp logs cluster cluster-example --output my-cluster.log

Successfully written logs to "my-cluster.log"

かなり#

pretty サブコマンドは、標準入力からログストリームを読み取り、人間が判読可能な出力にフォーマットし、タイムスタンプでエントリを並べ替えようとします。

次の例に示すように、kubectl cnp logs cluster と組み合わせて使用できます。

$ 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® AI for CloudNativePG™ Cluster 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形式で{{name.abbr}}ログを生成する他のコマンドと組み合わせて使用できます。

$ kubectl logs cluster-example-1 | kubectl cnp logs pretty
2024-10-15T17:35:00.336 INFO     cluster-example-1 instance-manager Starting EDB Postgres® AI for CloudNativePG™ Cluster 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 サブコマンドは、高度なログフィルタリングもサポートしているため、ユーザーは特定のポッドまたはロガーのログを表示したり、重大度レベルでログをフィルタリングしたりできます。次に例を示します。

$ 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を介して構成できます。

$ 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® AI for CloudNativePG™ Cluster 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 フラグを使用して、サポートされているフラグとその使用法の詳細を確認します。

注釈

-v オプションを追加して、ログの詳細度を高めることもできます。

デストロイ#

kubectl cnp destroy コマンドは、インスタンスと、関連するすべてのPVCをKubernetesクラスターから削除するのに役立ちます。

オプションの--keep-pvc フラグを指定すると、PVCを保持したまま、インスタンスによって設定されたすべてのmetadata.ownerReferences を削除できます。さらに、PVCのk8s.enterprisedb.io/pvcStatus ラベルがready からdetached に変更され、使用されなくなったことを示します。

--keep-pvc フラグを指定せずにコマンドを再度実行すると、分離されたPVCが削除されます。

使用法

kubectl cnp destroy [CLUSTER_NAME] [INSTANCE_ID]

次の例は、cluster-example-2 ポッドと関連するPVCを削除します。

kubectl cnp destroy cluster-example 2

クラスターハイバーネーション#

データを保持しながらCloudNativePG™クラスターCluster のEDB Postgres® AIの実行を一時停止し、後でアクティビティを再開することが必要になる場合があります。この機能を クラスターハイバーネーション と呼びます。

ハイバネーションは、 kubectl cnp hibernate [on|off] コマンドを介してのみ使用できます。

CloudNativePG™クラスタークラスターのEDB Postgres® AIを休止することは、 PostgreSQLプライマリインスタンスに属するPVCを除き、クラスターによって生成されたすべてのリソースを破棄することを意味します。

次の方法でクラスターを休止状態にできます。

kubectl cnp hibernate on <cluster-name>

これにより、

  1. すべてのPostgreSQLインスタンスをシャットダウンする

  2. プライマリインスタンスのデータを含むPVCを切断し、最新のデータベースステータスと最新のクラスター構成でアノテーションを付けます。

  3. 生成されたすべてのリソースを含むCluster リソースを削除します-前述のPVCを除く

休止している場合、CloudNativePG™クラスタークラスターのEDB Postgres® AIは、PVCのグループだけで表され、PGDATA を含むものには、pg_controldata のコンテンツを含む最新の利用可能なステータスで注釈が付けられます。

警告

フェンシングもハイバーネーションプロシージャの一部であるため、フェンスされたインスタンスを持つクラスターは休止できません。

エラーが発生した場合、オペレーターはプロシージャーを元に戻すことはできません。次のコマンドを使用して操作を強制できます。

kubectl cnp hibernate on cluster-example --force

休止状態のクラスターは、次の方法で再開できます。

kubectl cnp hibernate off <cluster-name>

クラスターが休止状態になると、最後の構成と、シャットダウン後にPostgreSQLのステータスを表示できます。それは次の方法で行うことができます。

kubectl cnp status <cluster-name>

pgbenchを使用したデータベースのベンチマーク#

Pgbenchは、次のコマンドを使用して、既存のPostgreSQLクラスターに対して実行できます。

kubectl cnp pgbench <cluster-name> -- --time 30 --client 1 --jobs 1

詳細については、 Benchmarking pgbench section を参照してください。

fioを使用したストレージのベンチマーク#

fioは、次のコマンドを使用して既存のストレージクラスで実行できます。

kubectl cnp fio <fio-job-name> -n <namespace>

詳細については、 Benchmarking fio section を参照してください。

新しい物理バックアップの要求#

kubectl cnp backup コマンドは、新しいBackup リソースを作成することにより、既存のPostgresクラスターの新しい物理バックアップを要求します。

注釈

リリース1.21から、 backup コマンドは、新しいフラグ`-m` を受け入れて、バックアップ方法を指定します。ボリュームスナップショットを使用してバックアップを要求するには、 -m volumeSnapshot を設定します

次の例は、特定のクラスターのオンデマンドバックアップを要求します。

kubectl cnp backup [cluster_name]

または、ボリュームスナップショットを使用する場合

kubectl cnp backup [cluster_name] -m volumeSnapshot

作成されるバックアップには、要求時間に基づいた名前が付けられます。

$ kubectl cnp backup cluster-example
backup/cluster-example-20230121002300 created

デフォルトでは、新しく作成されるバックアップは、クラスターで定義されたバックアップターゲットポリシーを使用して、実行するインスタンスを選択します。ただし、このポリシーは--backup-target オプションでオーバーライドできます。

ボリュームスナップショットバックアップの場合、 --online オプションを使用して、オンライン/ホットバックアップまたはオフライン/コールドバックアップを要求することもできます。さらに、 --immediate-checkpoint および--wait-for-archive オプションを明示的に設定することにより、オンラインバックアップを調整することもできます。

Appendix B - Backup on object stores には、構成設定に関する詳細情報が含まれています。

psqlの起動#

kubectl cnp psql コマンドは、実際のポッドから実行しているかのように、既存のPostgresクラスターに接続された新しいPostgreSQL対話型フロントエンドプロセス psqlを起動します。これは、 postgres ユーザーを使用することを意味します。

$ kubectl cnp psql cluster-example

psql (17.0 (Debian 17.0-1.pgdg110+1))
Type "help" for help.

postgres=#

デフォルトでは、コマンドはプライマリインスタンスに接続します。ユーザーは--replica オプションを使用して、レプリカに対して作業することを選択できます。

$ 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で実行されているインスタンスに接続する場合、

security measure built intoOpenShift のため、ユーザー名を`psql` コマンドに明示的に渡す必要があります。

kubectl cnp psql cluster-example -- -U postgres

警告

kubectl cnp snapshot コマンドは削除されました。 新しい物理バックアップの要求 を使用して、ボリュームスナップショットを使用したバックアップを要求してください。

評価/デモ目的でのみpgAdmin4を使用する#

pgAdmin は、PostgreSQLの最も人気のある機能が豊富なオープンソースの管理および開発プラットフォームです。プロジェクトの詳細については、公式 documentation を参照してください。

pgAdmin開発チームが公式のDockerコンテナイメージを維持していることを考えると、標準のKubernetes展開として環境にpgAdminをインストールできます。

ただし、 デモと評価の目的で 、CloudNativePG™クラスターのEDB Postgres® AIは、適切なソリューションを提供します。 cnp プラグインはpgadmin4 コマンドを実装し、特定のデータベースCluster に接続し、kind などのローカル環境でそのコンテンツをナビゲートする簡単な方法を提供します。

たとえば、次のとおりにcluster-example クラスターのpgAdmin4のデモ展開をインストールできます。

kubectl cnp pgadmin4 cluster-example

このコマンドは次を生成します。

ConfigMap/cluster-example-pgadmin4 created
Deployment/cluster-example-pgadmin4 created
Service/cluster-example-pgadmin4 created
Secret/cluster-example-pgadmin4 created

[...]

pgAdminを展開した後、 kubectlを使用してポートを転送し、画面の指示に従ってブラウザーを介して接続します。

Screenshot of desktop installation of pgAdmin

Screenshot of desktop installation of pgAdmin#

いつものように、--dry-run オプションを使用してYAMLファイルを生成できます。

kubectl cnp pgadmin4 --dry-run cluster-example

pgAdmin4はデスクトップまたはサーバーモードでインストールできます。デフォルトはサーバーです。

server モードでは、ランダムに生成されたパスワードを使用して認証が必要で、ユーザーは接続するデータベースを手動で指定する必要があります。

一方、desktop モードは、認証を必要とせずにpgAdmin Webインターフェイスを開始します。 app ユーザーとしてapp データベースに自動的に接続するため、 kind を使用したローカル展開などの簡単なデモに最適です。

kubectl cnp pgadmin4 --mode desktop cluster-example

デモが終了した後、次のコマンドを実行してpgAdmin展開を確実に終了します。

kubectl cnp pgadmin4 --dry-run cluster-example | kubectl delete -f -

警告

プラグインを使用してpgAdminを運用環境に展開しないでください。

ロジカルレプリケーションのパブリケーション#

cnp publication コマンドグループは、

PostgreSQL logical replication publications の作成と削除を合理化するように設計されています。これらのコマンドは、主に、特にリモートのPostgreSQLデータベースでの論理レプリケーションパブリケーションの作成を支援することを目的としていることに注意してください。

警告

これらのコマンドを使用する前に、PostgreSQLのネイティブ論理レプリケーションシステムの機能と制限の両方をしっかりと理解することが重要です。特に、

logical replication restrictions に注意してください。

新しいパブリケーションの作成#

論理レプリケーションパブリケーションを作成するには、 cnp publication create コマンドを使用します。このコマンドの基本的な構造は次のとおりです。

kubectl cnp 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 データベースにパブリケーションを作成します。

警告

外部クラスターに接続するときは、指定されたユーザーに`CREATE PUBLICATION` コマンドを実行するための十分な権限があることを確認してください。

CREATE PUBLICATION と同様に、いくつかのオプションがあります

コマンドを使用して、レプリケートするテーブルのグループを定義します。重要なオプションには次のものが含まれます。

  • --all-tables オプションを指定した場合、パブリケーションFOR ALL TABLES を作成します。

  • または、次の複数のオカレンスを指定できます。

    • --table 特定のテーブル式を追加します。

    • --schema 指定されたデータベーススキーマPostgreSQL 15から利用可能にあるすべてのテーブルを含めます。

--dry-run オプションを使用すると、プラグインが実行するSQLコマンドをプレビューできます。

追加情報と詳細な手順については、次のコマンドを入力してください。

kubectl cnp publication create --help

例#

source-cluster およびdestination-cluster を指定して、 source-cluster 上のデータのパブリケーションを作成します。 destination-cluster には、source-cluster を指すexternalClusters スタンザにエントリーがあります。

次を実行できます。

kubectl cnp publication create destination-cluster  \
  --external-cluster=source-cluster --all-tables

これは、 destination-cluster でSQLコマンドを実行し、 source-cluster のすべてのテーブルのパブリケーションを作成します。

または、その代わりに、次を実行できます。

kubectl cnp publication create source-cluster \
  --publication=app --all-tables

これは、 source-cluster 内のすべてのテーブルにapp という名前のパブリケーションを作成し、ソースクラスターでSQLコマンドを実行します。

注釈

イラストとインスピレーションのために提供されている2つのサンプルファイル logical-source および logical-destination があります。

パブリケーションの削除#

cnp publication drop コマンドは、パブリケーション名、クラスター名、オプションの外部クラスターを含む同様のキーオプションを提供することにより、 create コマンドをシームレスに補完します。次のコマンド構造を使用してPUBLICATION をドロップできます。

kubectl cnp publication drop \
  --publication <PUBLICATION_NAME> \
  [--external-cluster <EXTERNAL_CLUSTER>]
  <LOCAL_CLUSTER> [options]

さらに詳細と正確な指示にアクセスするには、次のコマンドを使用します。

kubectl cnp publication drop --help

論理レプリケーションサブスクリプション#

cnp subscription コマンドグループは、

PostgreSQL logical replication subscriptions の作成と削除を簡素化するように設計された専用のコマンドセットです。これらのコマンドは、特にリモートのPostgreSQLデータベースを扱う場合、論理レプリケーションサブスクリプションの確立を支援するように特別に作成されています。

警告

これらのコマンドを使用する前に、PostgreSQLのネイティブ論理レプリケーションシステムの機能と制限の両方を包括的に理解することが重要です。特に、

logical replication restrictions に注意してください。

サブスクリプション管理に加えて、ソースクラスターからすべてのシーケンスを同期するための役立つコマンドを提供します。その適用性は異なる場合がありますが、このコマンドは、メジャーアップグレードまたはリモートサーバーからのデータのインポートを含むシナリオで特に役立ちます。

新しいサブスクリプションの作成#

論理レプリケーションサブスクリプションを作成するには、 cnp subscription create コマンドを使用します。このコマンドの基本的な構造は次のとおりです。

kubectl cnp subscription create \
  --subscription <SUBSCRIPTION_NAME> \
  --publication <PUBLICATION_NAME> \
  --external-cluster <EXTERNAL_CLUSTER> \
  <LOCAL_CLUSTER> [options]

このコマンドは、 <LOCAL_CLUSTER> のexternalClusters スタンザで定義されているとおりに、指定された外部クラスター内の指定されたパブリケーションを対象としたサブスクリプションを構成します。

追加情報と詳細な手順については、次のコマンドを入力してください。

kubectl cnp subscription create --help

例#

パブリケーションに関するセクションと同様に、source-cluster およびdestination-cluster があり、app というパブリケーションを既に作成しています。

次のコマンド

kubectl cnp subscription create destination-cluster \
  --external-cluster=source-cluster \
  --publication=app --subscription=app

は、宛先クラスターにapp のサブスクリプションを作成します。

警告

非実稼働環境でのテストサブスクリプションを優先して、実稼働設定に実装する前にその有効性を確認し、潜在的な問題を特定します。

注釈

イラストとインスピレーションのために提供されている2つのサンプルファイル logical-source および logical-destination 。

サブスクリプションの削除#

cnp subscription drop コマンドは、 create コマンドをシームレスに補完します。次のコマンド構造を使用してSUBSCRIPTION をドロップできます。

kubectl cnp subcription drop \
  --subscription <SUBSCRIPTION_NAME> \
  <LOCAL_CLUSTER> [options]

さらに詳細と正確な指示にアクセスするには、次のコマンドを使用します。

kubectl cnp subscription drop --help

シーケンスの同期#

パブリケーションとサブスクリプションを介して実装されるPostgreSQL論理レプリケーションの重要な制約の1つは、シーケンス同期の欠如です。これは、論理レプリケーションを利用する場合に特に関連します ライブデータベース移行、特にPostgreSQLの上位バージョンの場合。このプロセスの重要なステップには、アプリケーションを新しいデータベース カットオーバー に移行する前にシーケンスの更新が含まれます。

この制限に対処するために、 cnp subscription sync-sequences コマンドは解決策を提供します。このコマンドは、ソースデータベースとの接続を確立し、関連するすべてのシーケンスを取得し、その後、一致するIDでローカルシーケンスを更新しますデータベーススキーマとシーケンス名に基づいて。

以下に示すようにコマンドを使用できます。

kubectl cnp subscription sync-sequences \
  --subscription <SUBSCRIPTION_NAME> \
  <LOCAL_CLUSTER>

包括的な詳細と特定の手順については、次のコマンドを使用します。

kubectl cnp subscription sync-sequences --help

例#

パブリケーションとサブスクリプションに関する以前のセクションと同様に、source-cluster およびdestination-cluster があります。パブリケーションとサブスクリプションは、両方ともapp と呼ばれますが、既に存在します。

次のコマンドは、app サブスクリプションに関係するシーケンスをソースクラスターから宛先クラスターに同期します。

kubectl cnp subscription sync-sequences destination-cluster \
  --subscription=app

警告

非実稼働環境でのテストサブスクリプションを優先して、実稼働設定に展開する前にその有効性を保証し、潜在的な問題を検出します。

K9sとの統合#

cnp プラグインは、Kubernetesクラスターと対話するための人気のターミナルベースのUIである K9s に簡単に統合できます。

詳細は、 k9s/plugins.yml を参照してください。

プラグインに必要な権限#

プラグインには、実行するコマンドに応じて一連のKubernetes権限が必要です。これらの権限は、ポッド、PDB、PVCなどのリソースやサブリソースに影響を与え、get 、delete 、patch などのアクションを有効にする場合があります。次の表には、完全な詳細が含まれています。

Command

Resource Permissions

backup

clusters: get<br/>backups: create

certificate

clusters: get<br/>secrets: get,create

destroy

pods: get,delete<br/>jobs: delete,list<br/>PVCs: list,delete,update

fencing

clusters: get,patch<br/>pods: get

fio

PVCs: create<br/>configmaps: create<br/>deployment: create

hibernate

clusters: get,patch,delete<br/>pods: list,get,delete<br/>pods/exec: create<br/>jobs: list<br/>PVCs: get,list,update,patch,delete

install

none

logs

clusters: get<br/>pods: list<br/>pods/log: get

maintenance

clusters: get,patch,list<br/>

pgadmin4

clusters: get<br/>configmaps: create<br/>deployments: create<br/>services: create<br/>secrets: create

pgbench

clusters: get<br/>jobs: create<br/>

promote

clusters: get<br/>clusters/status: patch<br/>pods: get

psql

pods: get,list<br/>pods/exec: create

publication

clusters: get<br/>pods: get,list<br/>pods/exec: create

reload

clusters: get,patch

report cluster

clusters: get<br/>pods: list<br/>pods/log: get<br/>jobs: list<br/>events: list<br/>PVCs: list

report operator

configmaps: get<br/>deployments: get<br/>events: list<br/>pods: list<br/>pods/log: get<br/>secrets: get<br/>services: get<br/>mutatingwebhookconfigurations: list[^1]<br/> validatingwebhookconfigurations: list[^1]<br/> If OLM is present on the K8s cluster, also:<br/>clusterserviceversions: list<br/>installplans: list<br/>subscriptions: list

restart

clusters: get,patch<br/>pods: get,delete

status

clusters: get<br/>pods: list<br/>pods/exec: create<br/>pods/proxy: create<br/>PDBs: list

subscription

clusters: get<br/>pods: get,list<br/>pods/exec: create

version

none

[^1]:権限は、クラスタースコープのClusterRoleリソースです。

///脚注はここにあります///

さらに、 clusters にlist 権限を割り当てると、複数のコマンドのオートコンプリートが有効になります。

ロールの例#

権限が制限されたロールを作成することが可能です。次の例では、クラスターログにのみアクセスするロールを作成します。

- --
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 コマンドを使用してクラスターステータスを取得するために必要な最小限の権限を持つロールを示しています。

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
目次