障害対応

このページでは、Kubernetesクラスター展開でCloudNativePGをトラブルシューティングする方法に関する基本的な情報を見つけることができます。

ヒント

Kubernetes管理者は、 kubectl ページをブックマークする必要があります。

始める前に

Kubernetes環境

トラブルシューティングアクティビティに違いをもたらすのは、基になるKubernetesシステムに関する明確な情報を提供することです。

次のことを確認してください

  • 使用しているKubernetesディストリビューションとバージョン

  • PostgreSQLが実行されているノードの仕様

  • 運用に入る前に実行したストレージクラスとベンチマークを含む、実際の その他のS3互換オブジェクトストレージプロバイダー について可能な限り。

  • クラスターで使用している関連するKubernetesアプリケーションつまりPrometheus、Grafana、Istio、Certmanagerなど。

  • 継続的なバックアップの状況、特にそれが配置され、正常に動作している場合。そうでない場合、必ず 緊急バックアップ を取ってください

潜在的な破壊的な操作を実行する前に

便利なユーティリティ

トラブルシューティングの為、必須のkubectl ユーティリティに加えて、次のプラグイン/ユーティリティをシステムで使用できることをお勧めします。

  • kubectl の場合 Backup {postgresql-cnpg-io-v1-Backup}

  • jq 、軽量で柔軟なコマンドラインJSONプロセッサー

  • grep 、1つ以上の入力ファイルで、指定されたパターンとの一致を含む行を検索します。これは、ほとんどの*nixディストリビューションで既に利用可能です。 Windows OSを使用している場合は、 grep の代替として findstr を使用するか、 wsl を直接使用できます。

そして、好みの*nixディストリビューションをインストールし、上記のツールを使用します。

最初の一歩

クラスターまたはインストールの概要をすばやく取得するために、kubectl プラグインは使用する主なツールです。

  1. status subcommand は、クラスターの概要を提供します

  2. report subcommand は、クラスターとオペレーター展開のマニフェストを提供します。 --logs オプションを使用してログを含めることもできます。プラグインを介して生成されたレポートには、完全なクラスターマニフェストが含まれます。

プラグインは、パッケージを介してエアギャップシステムにインストールできます。完全な手順については、

plugin document を参照してください。

バックアップはありますか？

プラグインでクラスターマニフェストを取得した後、バックアップがセットアップされ動作しているかどうかを確認する必要があります。

バックアップが設定されたクラスターでは、クラスターステータスにフィールド lastSuccessfulBackup およびfirstRecoverabilityPoint があります。最近のlastSuccessfulBackup があることを確認する必要があります。

.spec.backup スタンザが欠けているクラスターにはバックアップがありません。しつこいメッセージがPostgreSQLログに表示されます。

Backup not configured, skip WAL archiving.

トラブルシューティング操作を続行する前に、バックアップに関する結果によっては、緊急バックアップを実行することをお勧めします。手順については、次のセクションを参照してください。

定期的なバックアップを保持せずに運用データベースを操作することは、 非常にリスク です。

緊急バックアップ

一部の緊急の状況では、メインのapp データベースの緊急論理バックアップを作成する必要がある場合があります。

重要

以下にある指示は、緊急の場合、および一時的なバックアップファイルは、組織で有効なデータ保護ポリシーの下で保存される場合にのみ実行する必要があります。ダンプファイルは実際に`kubectl` コマンドを実行するクライアントマシンに保存されているため、すべての保護が設定されており、バックアップファイルを保存するための十分な領域があることを確認してください。

次の例は、cluster-example-1 ポッドからcluster-example Postgresクラスターのapp データベースの論理バックアップを取得する方法を示しています。

kubectl exec cluster-example-1 -c postgres \
  -- pg_dump -Fc -d app > app.dump

注釈

環境で使用したオブジェクトの名前を提供することにより、上記のコマンドをクラスターのバックアップに簡単に適合させることができます。

上記のコマンドは、カスタム形式でpg_dump コマンドを発行します。これは、

logical backups in PostgreSQL を取得する最も汎用性の高い方法です。

次の手順は、データベースを復元することです。初期化されたばかりの新しいPostgreSQLクラスターで操作していることを前提としていますので、 app データベースは空です。

次の例は、プライマリ new-cluster-example-1 ポッドに接続することにより、new-cluster-example Postgresクラスターのapp データベースに上記の論理バックアップを復元する方法を示しています。

kubectl exec -i new-cluster-example-1 -c postgres \
  -- pg_restore --no-owner --role=app -d app --verbose < app.dump

重要

このセクションの例では、推奨に従って、ダンプとリストアの他のグローバルオブジェクトデータベースとロールがないことを前提としています。複数のロールがある場合は、 pg_dumpall -g を使用してバックアップをとり、新しいクラスターに手動で復元していることを確認します。複数のデータベースがある場合、一度に1つのデータベースごとに上記の操作を繰り返し、適切な所有権を割り当てていることを確認する必要があります。 PostgreSQLに慣れていない場合は、専門のサポート会社の指導の下でこれらの重要な操作を実行することをお勧めします。

上記の手順は、将来のある段階でcnpg プラグインに統合される可能性があります。

ログ

CloudNativePGによって作成および制御されるすべてのリソースは、Kubernetesが想定するとおりに標準出力にログし、JSON formatに直接記録します。そのため、 kubectl logs コマンドを使用して、特定のリソースからログを取得する必要があります。

詳細については、次のように入力します。

kubectl logs --help

ヒント

JSONログは、機械の読み取りには最適ですが、人間が読み取るのは困難です。 jq コマンドを使用して、使いやすさを向上させることをお勧めします。たとえば、 | jq -C を使用して`kubectl logs` コマンドを*パイプ*できます。

注釈

以下のセクションでは、CloudNativePGのトラブルシューティングに関して、さまざまなリソースに関するログを取得する方法に関する例をいくつか示します。

オペレーター情報

デフォルトでは、CloudNativePGオペレーターはKubernetesのcnpg-system 名前空間にDeployment としてインストールされます

デプロイメントの詳細 を参照してください

詳細についてはこちらをご覧ください。

次のコマンドを実行して、オペレーターポッドのリストを取得できます。

kubectl get pods -n cnpg-system

注釈

通常、オペレーターが実行されているポッドが1つあり、 cnpg-controller-manager- で始まる名前で識別されます。高可用性用にオペレーターを設定している場合、より多くのエントリがあるはずです。これらのポッドは、 cnpg-controller-manager という名前の展開によって管理されます。

次の方法を使用して、ポッド <POD> で実行されているオペレーターに関する関連情報を収集します。

kubectl describe pod -n cnpg-system <POD>

次に、次のコマンドを実行して同じポッドからログを取得します。

kubectl logs -n cnpg-system <POD>

オペレーターに関する詳細情報を収集する

次のコマンドを実行して、CloudNativePGオペレーター展開のすべてのポッドからログを取得しますマルチオペレーター展開がある場合。

kubectl logs -n cnpg-system \
  deployment/cnpg-controller-manager --all-containers=true

Tip

-f フラグを上記のコマンドに追加して、リアルタイムでログを追跡できます。

次のコマンドを実行して、ログをJSONファイルに保存します。

kubectl logs -n cnpg-system \
  deployment/cnpg-controller-manager --all-containers=true | \
  jq -r . > cnpg_logs.json

kubectl-cnpg プラグインを使用してCloudNativePGオペレーターバージョンを取得します。

kubectl-cnpg status <CLUSTER>

出力

Cluster in healthy state
Name:               cluster-example
Namespace:          default
System ID:          7044925089871458324
PostgreSQL Image:   ghcr.io/cloudnative-pg/postgresql:16.1-3
Primary instance:   cluster-example-1
Instances:          3
Ready instances:    3
Current Write LSN:  0/5000000 (Timeline: 1 - WAL File: 000000010000000000000004)

Continuous Backup status
Not configured

Streaming Replication status
Name               Sent LSN   Write LSN  Flush LSN  Replay LSN  Write Lag       Flush Lag       Replay Lag      State      Sync State  Sync Priority
- ---               --------   ---------  ---------  ----------  ---------       ---------       ----------      -----      ----------  -------------
cluster-example-2  0/5000000  0/5000000  0/5000000  0/5000000   00:00:00        00:00:00        00:00:00        streaming  async       0
cluster-example-3  0/5000000  0/5000000  0/5000000  0/5000000   00:00:00.10033  00:00:00.10033  00:00:00.10033  streaming  async       0

Instances status
Name               Database Size  Current LSN  Replication role  Status  QoS         Manager Version
- ---               -------------  -----------  ----------------  ------  ---         ---------------
cluster-example-1  33 MB          0/5000000    Primary           OK      BestEffort  1.12.0
cluster-example-2  33 MB          0/5000000    Standby (async)   OK      BestEffort  1.12.0
cluster-example-3  33 MB          0/5000060    Standby (async)   OK      BestEffort  1.12.0

クラスター情報

NAMESPACE 名前空間の<CLUSTER> クラスターのステータスは、次の方法で確認できます。

kubectl get cluster -n <NAMESPACE> <CLUSTER>

出力

NAME        AGE        INSTANCES   READY   STATUS                     PRIMARY
<CLUSTER>   10d4h3m    3           3       Cluster in healthy state   <CLUSTER>-1

上記の例では、すべてが 準備 状態で、<CLUSTER>-1 がプライマリである3つのインスタンスの正常なPostgreSQLクラスターをレポートします。

異常な状態の場合、 Cluster リソースのマニフェストを取得することにより、詳細を検出できます。

kubectl get cluster -o yaml -n <NAMESPACE> <CLUSTER>

収集するもう1つの重要なコマンドは、 cnpg プラグインが提供するstatus コマンドです。

kubectl cnpg status -n <NAMESPACE> <CLUSTER>

Tip

--verbose オプションを追加することにより、詳細情報を印刷できます。

注釈

クラスターのステータスを知ることに加えて、 cnpgプラグインを使用して次のこともできます。レプリカをプロモートします。<br /> 証明書を管理します。<br /> ロールアウト・リスタートクラスターを作成して構成変更を適用します。<br /> リコンシリエーションを行う構成変更をリロードして適用するループ。<br />詳細については、 Backup {postgresql-cnpg-io-v1-Backup} ドキュメントを参照してください。

PostgreSQLコンテナイメージバージョンを取得します。

kubectl describe cluster <CLUSTER_NAME> -n <NAMESPACE> | grep "Image Name"

出力

Image Name:    ghcr.io/cloudnative-pg/postgresql:16.1-3

注釈

また、 kubectl-cnpg status -n <NAMESPACE> <CLUSTER_NAME> を使用して同じ情報を取得できます。

ポッド情報

次の方法を使用して、特定のPostgreSQLクラスターに属するインスタンスのリストを取得できます。

kubectl get pod -l cnpg.io/cluster=<CLUSTER> -L role -n <NAMESPACE>

出力

NAME          READY   STATUS    RESTARTS   AGE       ROLE
<CLUSTER>-1   1/1     Running   0          10d4h5m   primary
<CLUSTER>-2   1/1     Running   0          10d4h4m   replica
<CLUSTER>-3   1/1     Running   0          10d4h4m   replica

次を実行して、ポッドに障害が発生しているかどうか、およびどのように障害が発生しているかを確認できます。

kubectl get pod -n <NAMESPACE> -o yaml <CLUSTER>-<N>

次の使用で、特定のPostgreSQLインスタンスのすべてのログを取得できます。

kubectl logs -n <NAMESPACE> <CLUSTER>-<N>

検索をPostgreSQLプロセスのみに制限したい場合は、次のコマンドを実行できます。

kubectl logs -n <NAMESPACE> <CLUSTER>-<N> | \
  jq select(.logger=="postgres") | .record.message

次の例では、タイムスタンプを使いやすい形式で追加します。

kubectl logs -n <NAMESPACE> <CLUSTER>-<N> | \
  jq -r select(.logger=="postgres") | [(.ts|strflocaltime("%Y-%m-%dT%H:%M:%S %Z")), .record.message] | @csv

PostgreSQLポッドに関する追加情報を収集およびフィルタリングする

クラッシュした特定のポッドからログを確認します。

kubectl logs -n <NAMESPACE> --previous <CLUSTER>-<N>

特定のPostgreSQLポッドからFATALエラーを取得します。

kubectl logs -n <NAMESPACE> <CLUSTER>-<N> | \
  jq -r .record | select(.error_severity == "FATAL")

出力

{
  "log_time": "2021-11-08 14:07:44.520 UTC",
  "user_name": "streaming_replica",
  "process_id": "68",
  "connection_from": "10.244.0.10:60616",
  "session_id": "61892f30.44",
  "session_line_num": "1",
  "command_tag": "startup",
  "session_start_time": "2021-11-08 14:07:44 UTC",
  "virtual_transaction_id": "3/75",
  "transaction_id": "0",
  "error_severity": "FATAL",
  "sql_state_code": "28000",
  "message": "role \"streaming_replica\" does not exist",
  "backend_type": "walsender"
}

特定のポッドのログにあるPostgreSQL DBエラーメッセージをフィルタリングします。

kubectl logs -n <NAMESPACE> <CLUSTER>-<N> | jq -r .err | select(. != null)

出力

dial unix /controller/run/.s.PGSQL.5432: connect: no such file or directory

err ワードと一致するメッセージを特定のポッドから取得します。

kubectl logs -n <NAMESPACE> <CLUSTER>-<N> | jq -r .msg | grep "err"

出力

2021-11-08 14:07:39.610 UTC [15] LOG:  ending log output to stderr

特定のポッドからPostgreSQLプロセスからすべてのログを取得します。

kubectl logs -n <NAMESPACE> <CLUSTER>-<N> | \
  jq -r . | select(.logger == "postgres") | select(.msg != "record") | .msg
```出力

```shell
2021-11-08 14:07:52.591 UTC [16] LOG:  redirecting log output to logging collector process
2021-11-08 14:07:52.591 UTC [16] HINT:  Future log output will appear in directory "/controller/log".
2021-11-08 14:07:52.591 UTC [16] LOG:  ending log output to stderr
2021-11-08 14:07:52.591 UTC [16] HINT:  Future log output will go to log destination "csvlog".

値を含むフィールドでフィルタリングされたPodログを取得し、実行している| で区切って結合します。

kubectl logs -n <NAMESPACE> <CLUSTER>-<N> | \
  jq -r [.level, .ts, .logger, .msg] | join(" | ")

出力

info | 1636380469.5728037 | wal-archive | Backup not configured, skip WAL archiving
info | 1636383566.0664876 | postgres | record

バックアップ情報

次の使用で、名前付けクラスターに対して作成されたバックアップをリストできます。

kubectl get backup -l cnpg.io/cluster=<CLUSTER>

重要

バックアップラベル付けは、CloudNativePGのバージョン1.10.0で導入されました。したがって、そのバージョン以降で作成されたリソースのみがこのようなラベルを含みます。

ストレージ情報

次のように、クラスターが使用するStorageClassをダブルチェックして、調査またはトラブルシューティング中により多くのコンテキストを理解すると役立つ場合があります。

STORAGECLASS=$(kubectl get pvc <POD> -o jsonpath={.spec.storageClassName})
kubectl get storageclasses $STORAGECLASS -o yaml

多くの場合、クラスターはデフォルトのStorageClassを使用して作成されるため、ここではクラスターポッドの1つからStorageClassを取得します。

ノード情報

Kubernetesノードは、最終的にPostgreSQLポッドが実行される場所です。それらについてできるだけ多くを知ることが戦略的に重要です。

次の使用で、Kubernetesクラスター内のノードのリストを取得できます。

#  look at the worker nodes and their status

kubectl get nodes -o wide

さらに、特定のクラスターのポッドが実行されているノードのリストを収集できます。

kubectl get pod -l cnpg.io/cluster=<CLUSTER> \
  -L role -n <NAMESPACE> -o wide
後者は、ポッドがどこに分散されているかを理解するために重要です。

affinity/anti-affinity rules and/or tolerations を使用している場合に非常に役立ちます。

条件

多くのネイティブkubernetesオブジェクト like here と同様に、クラスターはstatus.conditions も公開します。これにより、クラスター全体の状態に依存するのではなく、特定のイベントが発生するを「待機」できます。現在利用可能な条件は次のとおりです。

  • LastBackupSucceeded

  • 継続的アーカイブ

  • 準備完了

LastBackupSucceeded は、最新のバックアップのステータスを報告しています。 True に設定されている場合、最後のバックアップは正しく取得されており、それ以外の場合はFalse に設定されます。

ContinuousArchiving は、WALアーカイブのステータスを報告しています。 True に設定されている場合、最後のWALアーカイブプロセスは正常に終了しており、それ以外の場合はFalse に設定されます。

クラスターにユーザーが指定した数のインスタンスがあり、プライマリインスタンスの準備ができている場合、 Ready はTrue です。この条件は、クラスターが作成されるのを待機するスクリプトで使用できます。

特定の条件を待機する方法

  • バックアップ

$ kubectl wait --for=condition=LastBackupSucceeded cluster/<CLUSTER-NAME> -n <NAMESPACE>

  • 継続的アーカイブ

$ kubectl wait --for=condition=ContinuousArchiving cluster/<CLUSTER-NAME> -n <NAMESPACE>

  • Ready クラスターの準備ができているかどうか。

edb_notranlate_40 以下は、失敗条件を含むcluster.status のスニペットです。

$ kubectl get cluster/<cluster-name> -o yaml
.
.
.
  status:
    conditions:
    - message: unexpected failure invoking barman-cloud-wal-archive: exit status
        2
      reason: ContinuousArchivingFailing
      status: "False"
      type: ContinuousArchiving

    - message: exit status 2
      reason: LastBackupFailed
      status: "False"
      type: LastBackupSucceeded

    - message: Cluster Is Not Ready
      reason: ClusterIsNotReady
      status: "False"
      type: Ready

ネットワーキング

CloudNativePGには、基本的なネットワーキングと接続が必要です。詳細については、

ネットワーキング セクションをご覧ください。

既存の環境にCloudNativePGをインストールする場合、ネットワークポリシー、またはクラスター専用に作成されたその他のネットワーク構成が存在する可能性があります。これは、オペレーターとクラスターポッド間および/またはポッド間の必要な接続に影響を与える可能性があります。

次のコマンドを使用して、既存のネットワークポリシーを検索できます。

kubectl get networkpolicies

Kubernetesネットワーク管理者によって設定された複数のネットワークポリシーが存在する場合があります。

$ kubectl get networkpolicies
NAME                   POD-SELECTOR                      AGE
allow-prometheus       cnpg.io/cluster=cluster-example   47m
default-deny-ingress   <none>                            57m

PostgreSQLコアダンプ

まれに、PostgreSQLはクラッシュし、PGDATA フォルダーにコアダンプを生成する場合があります。それが発生した場合、通常、それはPostgreSQLのバグであり、ほとんどの場合、既に解決されています。これが、常にPostgreSQLの最新のマイナーバージョンを実行することが重要である理由です。

CloudNativePGでは、 cnpg.io/coredumpFilter アノテーションを介してコアダンプに含めるものを制御できます。

注釈

ラベルとアノテーション を参照してください。

CloudNativePGが提供する標準のアノテーションの詳細については、 をご覧ください。

デフォルトでは、これがほとんどの場合最も安全なアプローチであるため、ダンプから共有メモリセグメントを除外するために、 cnpg.io/coredumpFilter は0x31 に設定されます。

注釈

Core dump filtering settings を参照してください。コアダンプフィルタを制御するビットマスクを設定する方法の詳細については、

重要

この設定はポッドの起動中にのみ有効になり、アノテーションを変更してもインスタンスの自動ロールアウトはトリガーされないことに注意してください。

あなたはコアダンプの検査に個人的に関わっていないかもしれませんが、 Postgresの専門家がそれらを調べることができるようにそれらの提供を求められる場合があります。まず、次のコマンドを使用して、PGDATA ディレクトリにコアダンプがあることを確認します。Postgresインスタンスが実行されている正しいポッドに対して実行してください。

kubectl exec -ti POD -c postgres \
  -- find /var/lib/postgresql/data/pgdata -name core.*

通常、これは空のセットを返すはずです。例、コアダンプファイルがあるとします。

/var/lib/postgresql/data/pgdata/core.14177

ディスク上の領域が十分であることを確認したら、次のようにkubectl cp を介してマシンでコアダンプを収集できます。

kubectl cp POD:/var/lib/postgresql/data/pgdata/core.14177 core.14177

これで、ファイルができました。コアダンプを削除して、サーバー上の領域を解放してください。

よくある問題

ストレージがいっぱいです

クラスター内の1つ以上のポッドがCrashloopBackoff にあり、これがフルディスクが原因である可能性をログが示している場合、おそらくインスタンスのPersistentVolumeClaim のサイズを増やす必要があります。ドキュメントの ボリュームの拡張 を参照してください。

ポッドがPending 状態でスタックしている

クラスターのインスタンスがPending フェーズでスタックしている場合、ポッドのEvents セクションを確認して、この背後にある理由を理解する必要があります。

kubectl describe pod -n <NAMESPACE> <POD>

この考えられる原因の一部は次のとおりです。

  • nodeSelector と一致するノードはありません

  • Tolerationがノードのテイントと一致するように正しく構成されていません

  • 利用可能なノードがまったくありません。これは、cluster-autoscaler がいくつかの制限に到達したこと、または一時的な問題が発生したことに関連している可能性があります。

この場合、名前空間内のイベントをチェックすることも役立つ場合があります。

kubectl get events -n <NAMESPACE>
#  list events in chronological order

kubectl get events -n <NAMESPACE> --sort-by=.metadata.creationTimestamp

バックアップが構成されていない場合、レプリカが同期していない

場合によっては、メンテナンスのため、レプリカが少しの間オフになる場合がありますKubernetesノードがドレインされたときを考えてください。クラスターにバックアップが構成されていない場合、レプリカがバックアップしたときに、プライマリにはもう存在しないWALファイル

:ref:``postgresql` セクション <postgresql セクション>` で述べているように、WAL管理ポリシーに従って既にリサイクルされており、フォールアウトする場合があります同期のこと。

同様に、pg_rewind が以前のプライマリに存在しないWALファイルを必要とする場合、 pg_rewind: error: could not open file をレポートします。

これらの場合、ポッドの準備ができなくなるため、PVCを削除し、オペレーターにレプリカを再構築してもらう必要があります。

動的にプロビジョニングされた永続ボリュームに依存し、PV自分自身を削除することに自信がある場合は、次の方法で削除できます。

PODNAME=<POD>
VOLNAME=$(kubectl get pv -o json | \
  jq -r .items[]|select(.spec.claimRef.name==\"$PODNAME\")|.metadata.name)

kubectl delete pod/$PODNAME pvc/$PODNAME pvc/$PODNAME-wal pv/$VOLNAME

クラスターがCreating new replica でスタックしている

クラスターは「新しいレプリカの作成」でスタックしていますが、ポッドログには関連する問題は表示されません。これは、次の問題

on connectivity

に関連していることがわかりました。リリース1.20.1、1.19.3、および1.18.5から、ネットワークの問題は次のようにステータス列により明確に反映されます。

Instance Status Extraction Error: HTTP communication issue

インストールされたネットワークポリシーにより、ネットワーキングが障害されます

networking section で指摘されているように、ローカルネットワークポリシーは、必要な接続の一部を妨げる可能性があります。

接続が障害されていることを示す兆候は、オペレーターログに次のようなメッセージが存在することです。

"Cannot extract Pod status", […snipped…] "Get \"http://<pod IP>:8000/pg/status\": dial tcp <pod IP>:8000: i/o timeout"

ネットワークポリシーをリストし、接続を制限するポリシーを探す必要があります。

$ kubectl get networkpolicies
NAME                   POD-SELECTOR                      AGE
allow-prometheus       cnpg.io/cluster=cluster-example   47m
default-deny-ingress   <none>                            57m

たとえば、上記のリストでは、 default-deny-ingress が犯人である可能性が高いと思われます。それをドリルダウンできます。

  $ kubectl get networkpolicies default-deny-ingress -o yaml
  <…snipped…>
  spec:
    podSelector: {}
    policyTypes:
    - Ingress

:ref:`networking page <ネットワーキング>` には、オペレーターがクロスネームスペースをクラスターポッドに接続できるようにする\ ``NetworkPolicy``

を作成するようにカスタマイズできるネットワークポリシーファイルがあります。

データディレクトリのブートストラップ中のエラー

クラスターの初期化ジョブが「バスエラーコアダンプされた子プロセスが終了コード135で終了しました」でクラッシュした場合、クラスターhugepages設定を修正する必要がある可能性があります。

その理由は、v2で修正する必要があるcgroup v1のhugeページのサポートが不完全であるためです。詳細については、 PostgreSQL BUG #17757: Not honoring huge_pages setting during initdb causes DB crash in Kubernetesを確認してください。

hugeページが有効になっているかどうかを確認するには、Kubernetesノードでgrep HugePages /proc/meminfo を実行し、hugepageが存在するかどうか、そのサイズ、および空き数を確認します。

hugeページが存在する場合、すべてのPostgreSQLポッドで使用可能なhugepageメモリの量を構成する必要があります。

例

postgresql:
  parameters:
    shared_buffers: "128MB"

resources:
  requests:
    memory: "512Mi"
  limits:
    hugepages-2Mi: "512Mi"

クラスター内のすべてのポッドをスケジュールするには、十分なhugepagesメモリが必要であることに注意してください。上記の例では、ポッドごとに少なくとも512MiBを解放する必要があります。