CloudNativePGプラグイン

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.18.1リリースをインストールしましょう。まず、適切な.deb ファイルをダウンロードします。

$ wget https://github.com/cloudnative-pg/cloudnative-pg/releases/download/v1.18.1/kubectl-cnpg_1.18.1_linux_x86_64.deb

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

$ dpkg -i kubectl-cnpg_1.18.1_linux_x86_64.deb
(Reading database ... 16102 files and directories currently installed.)
Preparing to unpack kubectl-cnpg_1.18.1_linux_x86_64.deb ...
Unpacking cnpg (1.18.1) over (1.18.1) ...
Setting up cnpg (1.18.1) ...

RPMパッケージ

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

curl -L https://github.com/cloudnative-pg/cloudnative-pg/releases/download/v1.18.1/kubectl-cnpg_1.18.1_linux_x86_64.rpm \
  --output kube-plugin.rpm

次に、 yum でインストールすると、使用する準備が整います。

$ yum --disablerepo=* localinstall kube-plugin.rpm
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.18.1-1                  @commandline                14 M

Transaction Summary
====================================================================================================
Install  1 Package

Total size: 14 M
Installed size: 43 M
Is this ok [y/N]: y

Krewの使用

Krewの使用 が既にインストールされている場合は、次を実行するだけです。

kubectl krew install cnpg

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

kubectl krew update
kubectl krew upgrade cnpg

サポートされているアーキテクチャ

CloudNativePGプラグインは現在、次のオペレーティングシステムとアーキテクチャ向けにビルドされています。

Linux amd64 arm5/6/7 arm64 s390x ppc64le

macOS amd64 * arm64

Windows 386 amd64 arm 5/6/7 * arm64

使用する

プラグインをインストールしてデプロイしたら、次のように使用を開始できます。

kubectl cnpg <command> <args...>

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

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

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

kubectl cnpg install generate --help

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

• -n ：オペレーターをインストールする名前空間（デフォルト：cnpg-system ）

• --replicas ：デプロイメント内のレプリカの数

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

• --watch-namespace ：ウォッチする名前空間を含むコンマ区切りの文字列（デフォルトではすべての名前空間）

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

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

上記のコマンドのフラグの意味は次のとおりです。

• -n king は、CNPGオペレーターをking 名前空間にインストールします

• --version 1.17 マイナーバージョン1.17の最新パッチバージョンをインストールします

• --replicas 3 は3つのレプリカでオペレーターをインストールします

• --watch-namespaces "albert, bb, freddie" は、オペレーターがalbert 、bb 、およびfreddie 名前空間の変更のみを監視します

ステータス

status コマンドは、以下を含むクラスターの現在のステータスの概要を提供します。

*** 一般情報**：クラスターの名前、PostgreSQLのシステムID、インスタンス数、現在のタイムラインとWAL内の位置

*** backup** ：回復可能性ポイント、およびプライマリからpg_stat_archiver ビューによって返されるWALアーカイブステータス-またはレプリカクラスターの場合は指定されたプライマリ

*** ストリーミングレプリケーション**：プライマリインスタンスのpg_stat_replication ビューから直接取得した情報

*** インスタンス** ：各インスタンスマネージャーが直接取得した各Postgresインスタンスに関する情報。スタンバイの場合、 Current LSN フィールドは、リカバリ中にリプレイされた最新のログ先行書き込みの場所（リプレイLSN）に対応します。

重要

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

kubectl cnpg status sandbox

Cluster in healthy state
Name:               sandbox
Namespace:          default
System ID:          7039966298120953877
PostgreSQL Image:   ghcr.io/cloudnative-pg/postgresql:15.3
Primary instance:   sandbox-2
Instances:          3
Ready instances:    3
Current Write LSN:  3AF/EAFA6168 (Timeline: 8 - WAL File: 00000008000003AF00000075)

Continuous Backup status
First Point of Recoverability:  Not Available
Working WAL archiving:          OK
Last Archived WAL:              00000008000003AE00000079   @   2021-12-14T10:16:29.340047Z
Last Failed WAL: -

Certificates Status
Certificate Name             Expiration Date                Days Left Until Expiration
- ---------------             ---------------                --------------------------
cluster-example-ca           2022-05-05 15:02:42 +0000 UTC  87.23
cluster-example-replication  2022-05-05 15:02:42 +0000 UTC  87.23
cluster-example-server       2022-05-05 15:02:42 +0000 UTC  87.23

Streaming Replication status
Name       Sent LSN      Write LSN     Flush LSN     Replay LSN    Write Lag        Flush Lag        Replay Lag       State      Sync State  Sync Priority
- ---       --------      ---------     ---------     ----------    ---------        ---------        ----------       -----      ----------  -------------
sandbox-1  3AF/EB0524F0  3AF/EB011760  3AF/EAFEDE50  3AF/EAFEDE50  00:00:00.004461  00:00:00.007901  00:00:00.007901  streaming  quorum      1
sandbox-3  3AF/EB0524F0  3AF/EB030B00  3AF/EB030B00  3AF/EB011760  00:00:00.000977  00:00:00.004194  00:00:00.008252  streaming  quorum      1

Instances status
Name       Database Size  Current LSN   Replication role  Status  QoS         Manager Version
- ---       -------------  -----------   ----------------  ------  ---         ---------------
sandbox-1  302 GB         3AF/E9FFFFE0  Standby (sync)    OK      Guaranteed  1.11.0
sandbox-2  302 GB         3AF/EAFA6168  Primary           OK      Guaranteed  1.11.0
sandbox-3  302 GB         3AF/EBAD5D18  Standby (sync)    OK      Guaranteed  1.11.0

--verbose または単に -v を追加することで、ステータスのより詳細なバージョンを取得することもできます

kubectl cnpg status sandbox --verbose

Cluster in healthy state
Name:               sandbox
Namespace:          default
System ID:          7039966298120953877
PostgreSQL Image:   ghcr.io/cloudnative-pg/postgresql:15.3
Primary instance:   sandbox-2
Instances:          3
Ready instances:    3
Current Write LSN:  3B1/61DE3158 (Timeline: 8 - WAL File: 00000008000003B100000030)

PostgreSQL Configuration
archive_command = /controller/manager wal-archive --log-destination /controller/log/postgres.json %p
archive_mode = on
archive_timeout = 5min
checkpoint_completion_target = 0.9
checkpoint_timeout = 900s
cluster_name = sandbox
dynamic_shared_memory_type = sysv
full_page_writes = on
hot_standby = true
jit = on
listen_addresses = *
log_autovacuum_min_duration = 1s
log_checkpoints = on
log_destination = csvlog
log_directory = /controller/log
log_filename = postgres
log_lock_waits = on
log_min_duration_statement = 1000
log_rotation_age = 0
log_rotation_size = 0
log_statement = ddl
log_temp_files = 1024
log_truncate_on_rotation = false
logging_collector = on
maintenance_work_mem = 2GB
max_connections = 1000
max_parallel_workers = 32
max_replication_slots = 32
max_wal_size = 15GB
max_worker_processes = 32
pg_stat_statements.max = 10000
pg_stat_statements.track = all
port = 5432
shared_buffers = 16GB
shared_memory_type = sysv
shared_preload_libraries = pg_stat_statements
ssl = on
ssl_ca_file = /controller/certificates/client-ca.crt
ssl_cert_file = /controller/certificates/server.crt
ssl_key_file = /controller/certificates/server.key
synchronous_standby_names = ANY 1 ("sandbox-1","sandbox-3")
unix_socket_directories = /controller/run
wal_keep_size = 512MB
wal_level = logical
wal_log_hints = on
cnpg.config_sha256 = 3cfa683e23fe513afaee7c97b50ce0628e0cc634bca8b096517538a9a4428efc

PostgreSQL HBA Rules

#  Grant local access

local all all peer map=local

#  Require client certificate authentication for the streaming_replica user

hostssl postgres streaming_replica all cert
hostssl replication streaming_replica all cert
hostssl all cnpg_pooler_pgbouncer all cert

#  Otherwise use the default authentication method

host all all all scram-sha-256

Continuous Backup status
First Point of Recoverability:  Not Available
Working WAL archiving:          OK
Last Archived WAL:              00000008000003B00000001D   @   2021-12-14T10:20:42.272815Z
Last Failed WAL: -

Streaming Replication status
Name       Sent LSN      Write LSN     Flush LSN     Replay LSN    Write Lag        Flush Lag        Replay Lag       State      Sync State  Sync Priority
- ---       --------      ---------     ---------     ----------    ---------        ---------        ----------       -----      ----------  -------------
sandbox-1  3B1/61E26448  3B1/61DF82F0  3B1/61DF82F0  3B1/61DF82F0  00:00:00.000333  00:00:00.000333  00:00:00.005484  streaming  quorum      1
sandbox-3  3B1/61E26448  3B1/61E26448  3B1/61DF82F0  3B1/61DF82F0  00:00:00.000756  00:00:00.000756  00:00:00.000756  streaming  quorum      1

Instances status
Name       Database Size  Current LSN   Replication role  Status  QoS         Manager Version
- ---       -------------  -----------   ----------------  ------  ---         ---------------
sandbox-1                 3B1/610204B8  Standby (sync)    OK      Guaranteed  1.11.0
sandbox-2                 3B1/61DE3158  Primary           OK      Guaranteed  1.11.0
sandbox-3                 3B1/62618470  Standby (sync)    OK      Guaranteed  1.11.0

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

宣伝する

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

kubectl cnpg promote cluster-example cluster-example-2

または、インスタンスノード番号を使用して昇格できます

kubectl cnpg promote cluster-example 2

証明書

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

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

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

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

kubectl get secret cluster-cert

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

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

再起動

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

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

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

#  this command will restart a whole cluster in a rollout fashion

kubectl cnpg restart [clusterName]

#  this command will restart a single instance, according to the policy above

kubectl cnpg restart [clusterName] [pod]

インプレース再起動が要求されたが、スイッチオーバーなしで変更を適用できない場合、スイッチオーバーはインプレース再起動よりも優先されます。この一般的なケースは、PostgreSQLイメージのマイナーアップグレードです。

注釈

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

リロード

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

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

kubectl cnpg reload [cluster_name]

メンテナンス

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とConfigMapsのすべての機密情報はREDACTEDです。データマップには**キー**が表示されますが、値は空になります。フラグ -S / --stopRedaction はリダクションを無効にし、値を表示します。あなた自身の責任でのみ使用してください、これはプライベートデータを共有します。

注釈

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

*** デプロイメント情報**：operator Deploymentとoperator Pod

*** 構成** ：オペレーター名前空間のSecretsとConfigMaps

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

*** webhook構成**：Webhook構成の変更と検証

*** webhook service**：ウェブフックサービス

*** logs** ：JSON行形式のオペレーターPod（オプション、デフォルトでオフ）のログ

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

注釈

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

kubectl cnpg report operator -n <namespace>

結果

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

-f フラグを設定します。

kubectl cnpg 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/cnpg-ca-secret.yaml
  inflating: report_operator_<TIMESTAMP>/manifests/cnpg-webhook-cert.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オペレーターのログの取得を試みます。これは、再起動されたオペレーターを調査するときに役立ちます。すべての場合において、 CURRENTオペレーターログの取得も試みます。現在および以前のログが利用可能な場合、それらの両方が表示されます。

====== Begin 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.19.1","build":{"Version":"1.19.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.19.1","build":{"Version":"1.19.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 … ガードは、内部にコンテンツなしで引き続き表示されます。

機密情報がデフォルトでREDACTEDであることを確認できます。

cd report_operator_<TIMESTAMP>/manifests/
head cnpg-ca-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 <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 cnpg-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 と同じ

*** cluster pods** ：クラスター名前と一致するクラスター名前空間内のポッド

*** クラスタージョブ**：クラスター名前と一致するクラスター名前空間にジョブがある場合

*** events** ：クラスター名前空間のイベント

*** ポッドログ**：JSON行形式のクラスターポッド（オプション、デフォルトでオフ）のログ

*** ジョブログ**：JSON行形式のジョブ（オプション、デフォルトでオフ）によって作成されたPodのログ

cluster サブコマンドは、 operator と同様に、 -f および-o フラグを受け入れます。 -f フラグが使用されない場合、デフォルトのタイムスタンプ付きのレポート名が使用されます。クラスター情報には構成Secrets / ConfigMapsが含まれていないため、 -S は無効になっていることに注意してください。

注釈

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

使用法：

kubectl cnpg report cluster <clusterName> [flags]

operator サブコマンドとは異なり、 cluster サブコマンドの場合、クラスターがデフォルトのものでない限り、クラスター名、およびほとんどの場合名前空間を提供する必要があることに注意してください。

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

ログ

kubectl cnpg logs コマンドを使用すると、CloudNativePGに関連するポッドのコレクションのログを一度に追跡できます。

現時点で1つの使用可能なサブコマンドがあります：cluster 。

クラスターログ

cluster サブコマンドは、クラスターのすべてのポッドログを単一のストリームまたはファイルに収集します。これは、コマンドを1回呼び出すだけで、1つのターミナルウィンドウですべてのポッドログを取得できることを意味します。

すべてのcnpgプラグインサブコマンドと同様に、 -h フラグの指示とヘルプを取得できます。

kubectl cnpg logs cluster -h

logs コマンドは、ログをJSON行形式で表示します。ただし、 --timestamps フラグが使用されている場合、人間が読める形式のタイムスタンプが各行の先頭に追加されます。この場合、行は有効なJSONではなくなり、 jq などのツールが期待どおりに動作しない場合があります。

logs cluster サブコマンドに-f フラグ（別名--follow ）が指定されている場合、クラスターポッドログに従い、コマンドが呼び出された後にクラスターで作成された新しいポッドも監視します。再起動または再作成されたポッドを含む、新しいポッドが見つかった場合、それらのポッドも追跡されます。ログは、端末の標準出力に表示されます。このコマンドは、クラスターにポッドがなくなった場合、またはユーザーによって中断された場合にのみ終了します。

logs が -f オプションなしで呼び出された場合、呼び出し時までにすべてのクラスターポッドからログを読み取り、ターミナルの標準出力に表示して終了します。 -o または--output フラグを提供して、標準出力に表示する代わりに、ログを保存するファイルの名前を指定できます。 --tail フラグを使用して、クラスター内の各ポッドから取得するログ行の数を指定できます。デフォルトでは、 logs cluster サブコマンドは、クラスター内の各ポッドのすべてのログを表示します。 “follow”フラグ-f と組み合わせると、 --tail で指定された数のログが現在時刻までに取得され、それ以降新しいログがフォローされます。

注：他のcnpg プラグインコマンドとは異なり、 -f は、ファイルを指定するのではなく、「フォロー」を示すために使用されます。これはkubectl logs の規約に従います。-f は、ログに従うことを意味します。

使用法：

kubectl cnpg logs cluster <clusterName> [flags]

-f オプションを使用してフォローします。

kubectl cnpg report cluster cluster-example -f

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

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

Successfully written logs to "my-cluster.log"

破壊する

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

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

--keep-pvc フラグを付けずにコマンドを再度実行すると、デタッチされたPVCが削除されます。

使用法：

kubectl cnpg destroy [CLUSTER_NAME] [INSTANCE_ID]

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

kubectl cnpg destroy cluster-example 2

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

場合によっては、データを保持しながらCloudNativePG Cluster の実行を一時停止し、後でアクティビティを再開することができます。この機能を クラスターハイバーネーション と呼んでいます。

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

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

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

kubectl cnpg hibernate on <cluster-name>

これにより：

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

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

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

休止状態になると、CloudNativePGクラスターはPVCのグループのみで表され、 PGDATA を含むものには、 pg_controldata のコンテンツを含む最新の利用可能なステータスで注釈が付けられます。

警告

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

エラーが発生した場合、オペレーターは手順を元に戻すことはできません。次のコマンドで操作を強制できます。

kubectl cnpg hibernate on cluster-example --force

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

kubectl cnpg hibernate off <cluster-name>

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

kubectl cnpg hibernate status <cluster-name>

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

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

kubectl cnpg pgbench <cluster-name> -- --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_name]

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

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

バックアップとリカバリ を参照してください

バックアップターゲットの詳細については。

psqlの起動

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

重要

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

kubectl cnpg psql cluster-example

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

postgres=#

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

kubectl cnpg psql --replica cluster-example
psql (15.3 (Debian 15.3-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 は、次の方法でPostgres Cluster の一貫したスナップショットを作成します。

1.作業するレプリカPodの選択

2.レプリカのフェンシング

3.スナップショットを撮る

4.レプリカのフェンシングを解除する

警告

フェンスで囲まれたインスタンスが既にあるクラスターはスナップショットを作成できません。

現時点では、このコマンドは少なくとも1つのレプリカを持つクラスターでのみ使用できます。そのレプリカはフェンシング手順によってシャットダウンされ、スナップショットの一貫性が保証されます（コールドバックアップ）。 KubernetesのVolumeSnapshot APIの宣言的サポートの開発が継続されると、この制限が削除され、ビジネス継続性が必要な場合にオンラインバックアップを取得できるようになります。

重要

プロシージャがレプリカをシャットダウンする場合でも、プライマリPodは関与しません。

kubectl cnpg snapshot コマンドにはクラスター名が必要です。

kubectl cnpg snapshot cluster-example

waiting for cluster-example-3 to be fenced
waiting for VolumeSnapshot cluster-example-3-1682539624 to be ready to use
unfencing pod cluster-example-3

VolumeSnapshot リソースは、空のVolumeSnapshotClass 参照で作成されます。そのリソースは、デフォルトとして構成されたVolumeSnapshotClass によって使用されることを目的としています。

-c オプションを使用して、特定のVolumeSnapshotClass を要求できます。

kubectl cnpg snapshot cluster-example -c longhorn