Kubectl Plugin

CloudNativePGは、Kubernetesでクラスターを管理するためのkubectl のプラグインを提供します。

インストール

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

注釈

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

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

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 ファイルをダウンロードします。

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 を使用してローカルファイルからインストールします。

$ 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 フラグに注意してください。

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 でインストールすると、使用する準備が整います。

$ 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 からプラグインをインストールするには、次の手順を実行します。

git clone https://aur.archlinux.org/kubectl-cnpg.git
cd kubectl-cnpg
makepkg -si

または、お気に入りのAURヘルパー、たとえば paru を使用します。

paru -S kubectl-cnpg

Krewを使用する

Krew を既にインストールしている場合は、単に実行できます。

kubectl krew install cnpg

プラグインの新しいバージョンがリリースされたら、次の方法で既存のインストールを更新できます。

kubectl krew update
kubectl krew upgrade cnpg

Homebrewを使用する

注釈

Homebrewコミュニティが kubectl-cnpg plugin on Homebrew の可用性を管理していることに注意してください。

Homebrew を既にインストールしている場合は、単に実行できます。

brew install kubectl-cnpg

プラグインの新しいバージョンがリリースされたら、次の方法で既存のインストールを更新できます。

brew update
brew upgrade kubectl-cnpg

注釈

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

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

##  Call the __complete command passing it all arguments

kubectl cnpg __complete "\$@"
EOF

chmod +x kubectl_complete-cnpg

##  Important: the following command may require superuser permission

sudo mv kubectl_complete-cnpg /usr/local/bin

注釈

スクリプトの名前は、kubectlオートコンプリートプロセスで使用されるため、指定されたものと正確である必要があります

使用する

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

kubectl cnpg COMMAND [ARGS...]

注釈

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

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

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

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

kubectl cnpg install generate --help

主なオプションは次のとおりです。

• -n オペレーターデフォルトcnpg-system をインストールする名前空間を指定します。

• --control-plane trueに設定されている場合、オペレーターの展開にはnode-role.kubernetes.io/control-plane の許容範囲とアフィニティが含まれます。

• --replicas 展開内のレプリカの数を設定します。

• --watch-namespace 監視する名前空間のコンマ区切りリストを指定しますデフォルトすべての名前空間。

• --version 1.23 など、インストールするオペレーターのマイナーバージョンを定義します。マイナーバージョンが指定された場合、プラグインはそのマイナーバージョンの最新のパッチバージョンをインストールします。バージョンが指定されない場合、プラグインはオペレーターの最新のMAJOR.MINOR.PATCH バージョンをインストールします。

オペレーターをインストールするYAMLマニフェストを生成するgenerate コマンドの例は、次のとおりです。

kubectl cnpg install generate \
  -n king \
  --version 1.23 \
  --replicas 3 \
  --watch-namespace "albert, bb, freddie" \
  > 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に対応します。

注釈

上記のステータス情報は、異なる時間に異なる場所で取得されたため、わずかに一貫性のない戻り値が発生します。たとえば、メインヘッダーの`Current Write LSN` 場所は、2つの異なる時間間隔で取得されるため、インスタンスステータスの`Current LSN` フィールドとは異なる場合があります。

kubectl cnpg status sandbox

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 を使用します。フラグが繰り返されるたびに、詳細レベルが増加します。

kubectl cnpg status sandbox --verbose

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 形式での出力もサポートしています。

注釈

status コマンドは、クラスターサイズを計算する`du` や構成ファイルを読み取る`cat` など、Podファイルシステムにアクセスする操作を実行します。大規模なデータ量1TBを超えるクラスターの場合、これらの操作はデフォルトのタイムアウトの10秒よりも長くかかる場合があります。 --timeout フラグ kubectl cnpg status sandbox --timeout 45s などを使用してタイムアウトを調整できます。

プロモート

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

kubectl cnpg promote CLUSTER CLUSTER-INSTANCE

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

kubectl cnpg promote CLUSTER INSTANCE

証明書

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

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

kubectl cnpg certificate cluster-cert --cnpg-cluster CLUSTER --cnpg-user USER

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

kubectl get secret cluster-cert

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

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

再起動

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

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

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

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

注釈

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

リロード

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

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

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

kubectl cnpg 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 cnpg report コマンドは、さまざまな情報をZIPファイルにバンドルします。実稼働環境のクラスターの問題をデバッグするために必要なコンテキストを提供することを目的としています。

operator およびcluster の2つのサブコマンドがあります。

レポート演算子

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

注釈

SecretsとConfigMapのすべての機密情報は編集されています。データマップには**キー**が表示されますが、値は空になります。フラグ`-S` / --stopRedaction は、リダクションを無効にし、値を表示します。自己の責任でのみ使用します。これはプライベートデータを共有します。

注釈

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

注釈

report operator コマンドは、最小限の権限で動作します。オペレーターの展開のみが**必須**です。他のすべてのリソースはオプショナルであり、ベストエフォートベースで収集されます。特定のリソースWebhook、OLMリソースなどの権限が不足している場合、警告がログに記録され、利用可能なデータでレポート生成が続行されます。

レポートには以下が含まれます。

• 展開情報 必須 オペレーター Deployment

• operator pods オプショナル オペレーターPod 情報

• configuration オプショナル オペレーター名前空間のSecrets およびConfigMaps

• events オプショナル オペレーター名前空間のEvents

• webhook configuration オプショナル ウェブフック構成の変更と検証 クラスタースコープ

• webhook service (オプショナル) Webhookサービス

• OLMリソース オプショナル サブスクリプション、クラスターサービスバージョン、インストールプランOLMがインストールされている場合

• logs オプショナル 演算子Pod JSON行形式のログ --logs フラグが必要

警告

オペレーター名前空間のオペレーターデプロイメントへの読み取りアクセス 。これにより、名前空間スコープのユーザーは基本的なトラブルシューティングレポートを生成できます。

注釈

ポッド、イベントに`list` を追加します。シークレット、構成マップ、サービス名前空間スコープの`get` 。およびWebhook構成クラスタースコープの`list` 。

名前空間スコープの権限のみを持つユーザーは、引き続き有用なレポートを生成できます。

##  With only deployment read access

kubectl cnpg report operator -n cnpg-system -f report.zip

注釈

このコマンドは、アクセスできないリソースの警告をログに記録しますが、展開マニフェストを使用したレポートを正常に生成します。多くの場合、基本的なトラブルシューティングには十分です。

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

注釈

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

kubectl cnpg report operator -n cnpg-system

での結果

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

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

kubectl cnpg report operator -n cnpg-system -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/cnpg-ca-secret(secret).yaml
  inflating: report_operator_<TIMESTAMP>/manifests/cnpg-webhook-cert(secret).yaml

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

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

注釈

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

====== 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"}
  <snipped …>

====== 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 … ガードが表示されますが、中にコンテンツはありません。

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

cd report_operator_<TIMESTAMP>/manifests/
head cnpg-ca-secret\(secret\).yaml

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

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

kubectl cnpg report operator -n cnpg-system -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 cnpg-ca-secret\(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 cnpg report cluster CLUSTER [flags]

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

kubectl cnpg report cluster CLUSTER -f report.zip [-n 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 cnpg report cluster CLUSTER [-n 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

ログ

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 は、ログに従う必要があることを意味します。

使用法

kubectl cnpg logs cluster CLUSTER [flags]

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

kubectl cnpg report cluster CLUSTER -f

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

kubectl cnpg report cluster CLUSTER -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 cnpg logs cluster CLUSTER --output my-cluster.log

Successfully written logs to "my-cluster.log"

Pretty

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

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

$ 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 などと組み合わせて使用できます。

$ 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 サブコマンドは、高度なログフィルタリングもサポートしているため、ユーザーは特定のポッドまたはロガーのログを表示したり、重大度レベルでログをフィルタリングしたりできます。次に例を示します。

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

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

注釈

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

デストロイ

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

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

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

使用法

kubectl cnpg destroy CLUSTER INSTANCE

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

kubectl cnpg destroy cluster-example 2

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

データを保存しながらCloudNativePG Cluster を一時的に一時停止し、後でオペレーションを再開できるようにする必要がある場合があります。この機能は、 クラスターハイバーネーション と呼ばれます。

ハイバネーションは、 cnpg.io/hibernation アノテーションを使用して宣言的に管理されます。

注釈

詳細については、 Declarative hibernation を参照してください。

ドキュメントページ。

プロセスを簡素化するために、 kubectl のcnpg プラグインは hibernate コマンドを提供します。これは、アノテーションを適用するための便利なショートカットとして機能します。

クラスターを休止状態にするには、次のコマンドを実行します。

kubectl cnpg hibernate on CLUSTER

このコマンドは、 cnpg.io/hibernation=on アノテーションをクラスターに適用し、実行を一時停止します。

休止状態のクラスターを再開するには、次を使用します。

kubectl cnpg hibernate off CLUSTER

これにより、cnpg.io/hibernation=off を設定することによりハイバーネーション状態が削除されます。

クラスターのステータスは、次の方法でいつでも確認できます。

kubectl cnpg status CLUSTER

これにより、クラスターの現在の状態が表示されます、休止状態かどうかを含む。

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

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

kubectl cnpg pgbench CLUSTER -- --time 30 --client 1 --jobs 1

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

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

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

kubectl cnpg fio FIO_JOB_NAME [-n NAMESPACE]

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

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

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

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

kubectl cnpg backup CLUSTER

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

kubectl cnpg backup CLUSTER -m volumeSnapshot

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

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

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

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

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

psqlの起動

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

注釈

postgres ユーザーとして接続するため、運用環境では、この方法は許可された担当者のみが細心の注意を払って使用する必要があります。

$ kubectl cnpg psql cluster-example

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

postgres=#

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

$ 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クラスターのスナップショット

警告

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

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

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

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

注釈

Kubernetes運用環境でのpgAdminの展開は、このドキュメントの範囲を超えており、より広範にはCloudNativePGプロジェクトの範囲を超えています。

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

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

kubectl cnpg 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

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

kubectl cnpg pgadmin4 --dry-run cluster-example

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

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

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

kubectl cnpg pgadmin4 --mode desktop cluster-example

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

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

警告

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

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

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

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

警告

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

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

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

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

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

警告

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

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

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

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

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

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

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

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

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

kubectl cnpg publication create --help

例

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

次を実行できます。

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

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

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

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

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

注釈

イラストとインスピレーションのために提供されている2つのサンプルファイル

logical-source および logical-destination 。

パブリケーションの削除

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

kubectl cnpg publication drop \
  --publication PUBLICATION_NAME \
  [--external-cluster EXTERNAL_CLUSTER]
  LOCAL_CLUSTER [options]

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

kubectl cnpg publication drop --help

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

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

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

警告

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

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

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

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

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

kubectl cnpg subscription create \
  --subscription SUBSCRIPTION_NAME \
  --publication PUBLICATION_NAME \
  --external-cluster EXTERNAL_CLUSTER \
  LOCAL_CLUSTER [options]

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

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

kubectl cnpg subscription create --help

例

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

次のコマンド

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

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

警告

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

注釈

イラストとインスピレーションのために提供されている2つのサンプルファイル

logical-source および logical-destination 。

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

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

kubectl cnpg subcription drop \
  --subscription SUBSCRIPTION_NAME \
  LOCAL_CLUSTER [options]

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

kubectl cnpg subscription drop --help

シーケンスの同期

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

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

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

kubectl cnpg subscription sync-sequences \
  --subscription SUBSCRIPTION_NAME \
  LOCAL_CLUSTER

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

kubectl cnpg subscription sync-sequences --help

例

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

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

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

警告

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

K9sとの統合

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

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

プラグインに必要な権限

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

Command	Resource Permissions
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 権限を割り当てると、複数のコマンドのオートコンプリートが有効になります。

ロールの例

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

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

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

注釈

resources ごとおよび`apiGroups` ごとに動詞を制限したままにすると、意図した以上の権限を誤って付与するのを防ぐことができます。