障害対応 ======== このページでは、Kubernetesクラスター展開でCloudNativePGをトラブルシューティングする方法に関する基本的な情報を見つけることができます。 .. Hint:: Kubernetes管理者は、 `kubectl `_ ページをブックマークする必要があります。 始める前に ---------- Kubernetes環境 ^^^^^^^^^^^^^^ トラブルシューティングアクティビティに違いをもたらすのは、基になるKubernetesシステムに関する明確な情報を提供することです。 次のことを確認してください - 使用しているKubernetesディストリビューションとバージョン - PostgreSQLが実行されているノードの仕様 - 運用に入る前に実行したストレージクラスとベンチマークを含む、実際の :ref:`その他のS3互換オブジェクトストレージプロバイダー <その他のS3互換オブジェクトストレージプロバイダー>` について可能な限り。 - クラスターで使用している関連するKubernetesアプリケーションつまりPrometheus、Grafana、Istio、Certmanagerなど。 - 継続的なバックアップの状況、特にそれが配置され、正常に動作している場合。そうでない場合、必ず :ref:`緊急バックアップ <緊急バックアップ>` を取ってください 潜在的な破壊的な操作を実行する前に 便利なユーティリティ ^^^^^^^^^^^^^^^^^^^^ トラブルシューティングの為、必須の\ ``kubectl`` ユーティリティに加えて、次のプラグイン/ユーティリティをシステムで使用できることをお勧めします。 - ``kubectl`` の場合 :ref:`Backup {postgresql-cnpg-io-v1-Backup} ` - `jq `_ 、軽量で柔軟なコマンドラインJSONプロセッサー - `grep `_ 、1つ以上の入力ファイルで、指定されたパターンとの一致を含む行を検索します。これは、ほとんどの*nixディストリビューションで既に利用可能です。 Windows OSを使用している場合は、 ``grep`` の代替として `findstr `_ を使用するか、 `wsl `_ を直接使用できます。 そして、好みの*nixディストリビューションをインストールし、上記のツールを使用します。 緊急バックアップ ---------------- 一部の緊急の状況では、メインの\ ``app`` データベースの緊急論理バックアップを作成する必要がある場合があります。 .. Important:: 以下にある指示は、緊急の場合、および一時的なバックアップファイルは、組織で有効なデータ保護ポリシーの下で保存される場合にのみ実行する必要があります。ダンプファイルは実際に`kubectl` コマンドを実行するクライアントマシンに保存されているため、すべての保護が設定されており、バックアップファイルを保存するための十分な領域があることを確認してください。 次の例は、\ ``cluster-example-1`` ポッドから\ ``cluster-example`` Postgresクラスターの\ ``app`` データベースの論理バックアップを取得する方法を示しています。 .. code:: sh kubectl exec cluster-example-1 -c postgres \ -- pg_dump -Fc -d app > app.dump .. Note:: 環境で使用したオブジェクトの名前を提供することにより、上記のコマンドをクラスターのバックアップに簡単に適合させることができます。 上記のコマンドは、カスタム形式で\ ``pg_dump`` コマンドを発行します。これは、 `logical backups in PostgreSQL `_ を取得する最も汎用性の高い方法です。 次の手順は、データベースを復元することです。初期化されたばかりの新しいPostgreSQLクラスターで操作していることを前提としていますので、 ``app`` データベースは空です。 次の例は、プライマリ ``new-cluster-example-1`` ポッドに接続することにより、\ ``new-cluster-example`` Postgresクラスターの\ ``app`` データベースに上記の論理バックアップを復元する方法を示しています。 .. code:: sh kubectl exec -i new-cluster-example-1 -c postgres \ -- pg_restore --no-owner --role=app -d app --verbose < app.dump .. Important:: このセクションの例では、推奨に従って、ダンプとリストアの他のグローバルオブジェクトデータベースとロールがないことを前提としています。複数のロールがある場合は、 `pg_dumpall -g` を使用してバックアップをとり、新しいクラスターに手動で復元していることを確認します。複数のデータベースがある場合、一度に1つのデータベースごとに上記の操作を繰り返し、適切な所有権を割り当てていることを確認する必要があります。 PostgreSQLに慣れていない場合は、専門のサポート会社の指導の下でこれらの重要な操作を実行することをお勧めします。 上記の手順は、将来のある段階で\ ``cnpg`` プラグインに統合される可能性があります。 ログ ^^^^ CloudNativePGによって作成および制御されるすべてのリソースは、Kubernetesが想定するとおりに標準出力にログし、\ `JSON format `__\ に直接記録します。そのため、 ``kubectl logs`` コマンドを使用して、特定のリソースからログを取得する必要があります。 詳細については、次のように入力します。 .. code:: shell kubectl logs --help .. Hint:: JSONログは、機械の読み取りには最適ですが、人間が読み取るのは困難です。 `jq` コマンドを使用して、使いやすさを向上させることをお勧めします。たとえば、 `| jq -C` を使用して`kubectl logs` コマンドを*パイプ*できます。 .. Note:: 以下のセクションでは、CloudNativePGのトラブルシューティングに関して、さまざまなリソースに関するログを取得する方法に関する例をいくつか示します。 オペレーター情報 ---------------- デフォルトでは、CloudNativePGオペレーターはKubernetesの\ ``cnpg-system`` 名前空間に\ ``Deployment`` としてインストールされます :ref:`デプロイメントの詳細 <デプロイメントの詳細>` を参照してください 詳細についてはこちらをご覧ください。 次のコマンドを実行して、オペレーターポッドのリストを取得できます。 .. code:: shell kubectl get pods -n cnpg-system .. Note:: 通常、オペレーターが実行されているポッドが1つあり、 `cnpg-controller-manager-` で始まる名前で識別されます。高可用性用にオペレーターを設定している場合、より多くのエントリがあるはずです。これらのポッドは、 `cnpg-controller-manager` という名前の展開によって管理されます。 次の方法を使用して、ポッド ```` で実行されているオペレーターに関する関連情報を収集します。 .. code:: shell kubectl describe pod -n cnpg-system 次に、次のコマンドを実行して同じポッドからログを取得します。 .. code:: shell kubectl logs -n cnpg-system オペレーターに関する詳細情報を収集する ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 次のコマンドを実行して、CloudNativePGオペレーター展開のすべてのポッドからログを取得しますマルチオペレーター展開がある場合。 .. code:: shell kubectl logs -n cnpg-system \ deployment/cnpg-controller-manager --all-containers=true .. Tip:: `-f` フラグを上記のコマンドに追加して、リアルタイムでログを追跡できます。 次のコマンドを実行して、ログをJSONファイルに保存します。 .. code:: shell kubectl logs -n cnpg-system \ deployment/cnpg-controller-manager --all-containers=true | \ jq -r . > cnpg_logs.json ``kubectl-cnpg`` プラグインを使用してCloudNativePGオペレーターバージョンを取得します。 .. code:: shell kubectl-cnpg status 出力 .. code:: shell Cluster in healthy state Name: cluster-example Namespace: default System ID: 7044925089871458324 PostgreSQL Image: ghcr.io/cloudnative-pg/postgresql:16.0-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`` 名前空間の\ ```` クラスターのステータスは、次の方法で確認できます。 .. code:: shell kubectl get cluster -n 出力 .. code:: shell NAME AGE INSTANCES READY STATUS PRIMARY 10d4h3m 3 3 Cluster in healthy state -1 上記の例では、すべてが *準備* 状態で、\ ``-1`` がプライマリである3つのインスタンスの正常なPostgreSQLクラスターをレポートします。 異常な状態の場合、 ``Cluster`` リソースのマニフェストを取得することにより、詳細を検出できます。 .. code:: shell kubectl get cluster -o yaml -n 収集するもう1つの重要なコマンドは、 ``cnpg`` プラグインが提供する\ ``status`` コマンドです。 .. code:: shell kubectl cnpg status -n .. Tip:: `--verbose` オプションを追加することにより、詳細情報を印刷できます。 .. Note:: クラスターのステータスを知ることに加えて、 cnpgプラグインを使用して次のこともできます。レプリカをプロモートします。
証明書を管理します。
ロールアウト・リスタートクラスターを作成して構成変更を適用します。
リコンシリエーションを行う構成変更をリロードして適用するループ。
詳細については、 :ref:`Backup {postgresql-cnpg-io-v1-Backup} ` ドキュメントを参照してください。 PostgreSQLコンテナイメージバージョンを取得します。 .. code:: shell kubectl describe cluster -n | grep "Image Name" 出力 .. code:: shell Image Name: ghcr.io/cloudnative-pg/postgresql:16.0-3 .. Note:: また、 `kubectl-cnpg status -n ` を使用して同じ情報を取得できます。 ポッド情報 ---------- 次の方法を使用して、特定のPostgreSQLクラスターに属するインスタンスのリストを取得できます。 .. code:: shell kubectl get pod -l cnpg.io/cluster= -L role -n 出力 .. code:: shell NAME READY STATUS RESTARTS AGE ROLE -1 1/1 Running 0 10d4h5m primary -2 1/1 Running 0 10d4h4m replica -3 1/1 Running 0 10d4h4m replica 次を実行して、ポッドに障害が発生しているかどうか、およびどのように障害が発生しているかを確認できます。 .. code:: shell kubectl get pod -n -o yaml - 次の使用で、特定のPostgreSQLインスタンスのすべてのログを取得できます。 .. code:: shell kubectl logs -n - 検索をPostgreSQLプロセスのみに制限したい場合は、次のコマンドを実行できます。 .. code:: shell kubectl logs -n - | \ jq select(.logger=="postgres") | .record.message 次の例では、タイムスタンプを使いやすい形式で追加します。 .. code:: shell kubectl logs -n - | \ jq -r select(.logger=="postgres") | [(.ts|strflocaltime("%Y-%m-%dT%H:%M:%S %Z")), .record.message] | @csv PostgreSQLポッドに関する追加情報を収集およびフィルタリングする ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ クラッシュした特定のポッドからログを確認します。 .. code:: shell kubectl logs -n --previous - 特定のPostgreSQLポッドからFATALエラーを取得します。 .. code:: shell kubectl logs -n - | \ jq -r .record | select(.error_severity == "FATAL") 出力 .. code:: json { "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エラーメッセージをフィルタリングします。 .. code:: shell kubectl logs -n - | jq -r .err | select(. != null) 出力 .. code:: shell dial unix /controller/run/.s.PGSQL.5432: connect: no such file or directory ``err`` ワードと一致するメッセージを特定のポッドから取得します。 .. code:: shell kubectl logs -n - | jq -r .msg | grep "err" 出力 .. code:: shell 2021-11-08 14:07:39.610 UTC [15] LOG: ending log output to stderr 特定のポッドからPostgreSQLプロセスからすべてのログを取得します。 .. code:: shell kubectl logs -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ログを取得し、実行している\ ``|`` で区切って結合します。 .. code:: shell kubectl logs -n - | \ jq -r [.level, .ts, .logger, .msg] | join(" | ") 出力 .. code:: shell info | 1636380469.5728037 | wal-archive | Backup not configured, skip WAL archiving info | 1636383566.0664876 | postgres | record バックアップ情報 ---------------- 次の使用で、名前付けクラスターに対して作成されたバックアップをリストできます。 .. code:: shell kubectl get backup -l cnpg.io/cluster= .. Important:: バックアップラベル付けは、CloudNativePGのバージョン1.10.0で導入されました。したがって、そのバージョン以降で作成されたリソースのみがこのようなラベルを含みます。 ストレージ情報 -------------- 次のように、クラスターが使用するStorageClassをダブルチェックして、調査またはトラブルシューティング中により多くのコンテキストを理解すると役立つ場合があります。 .. code:: shell STORAGECLASS=$(kubectl get pvc -o jsonpath={.spec.storageClassName}) kubectl get storageclasses $STORAGECLASS -o yaml 多くの場合、クラスターはデフォルトのStorageClassを使用して作成されるため、ここではクラスターポッドの1つからStorageClassを取得します。 ノード情報 ---------- Kubernetesノードは、最終的にPostgreSQLポッドが実行される場所です。それらについてできるだけ多くを知ることが戦略的に重要です。 次の使用で、Kubernetesクラスター内のノードのリストを取得できます。 .. code:: shell # look at the worker nodes and their status kubectl get nodes -o wide さらに、特定のクラスターのポッドが実行されているノードのリストを収集できます。 .. code:: shell kubectl get pod -l cnpg.io/cluster= \ -L role -n -o wide 後者は、ポッドがどこに分散されているかを理解するために重要です。 :ref:`affinity/anti-affinity rules and/or tolerations <スケジューリング>` を使用している場合に非常に役立ちます。 条件 ---- 多くのネイティブkubernetesオブジェクト `like here `_ と同様に、クラスターは\ ``status.conditions`` も公開します。これにより、クラスター全体の状態に依存するのではなく、特定のイベントが発生するを「待機」できます。現在利用可能な条件は次のとおりです。 - LastBackupSucceeded - 継続的アーカイブ - 準備完了 ``LastBackupSucceeded`` は、最新のバックアップのステータスを報告しています。 ``True`` に設定されている場合、最後のバックアップは正しく取得されており、それ以外の場合は\ ``False`` に設定されます。 ``ContinuousArchiving`` は、WALアーカイブのステータスを報告しています。 ``True`` に設定されている場合、最後のWALアーカイブプロセスは正常に終了しており、それ以外の場合は\ ``False`` に設定されます。 クラスターにユーザーが指定した数のインスタンスがあり、プライマリインスタンスの準備ができている場合、 ``Ready`` は\ ``True`` です。この条件は、クラスターが作成されるのを待機するスクリプトで使用できます。 特定の条件を待機する方法 ^^^^^^^^^^^^^^^^^^^^^^^^ - バックアップ .. code:: bash $ kubectl wait --for=condition=LastBackupSucceeded cluster/ -n - 継続的アーカイブ .. code:: bash $ kubectl wait --for=condition=ContinuousArchiving cluster/ -n - Ready クラスターの準備ができているかどうか。 edb_notranlate_39 以下は、失敗条件を含む\ ``cluster.status`` のスニペットです。 .. code:: bash $ kubectl get cluster/ -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には、基本的なネットワーキングと接続が必要です。詳細については、 :ref:`ネットワーキング <ネットワーキング>` セクションをご覧ください。 既存の環境にCloudNativePGをインストールする場合、ネットワークポリシー、またはクラスター専用に作成されたその他のネットワーク構成が存在する可能性があります。これは、オペレーターとクラスターポッド間および/またはポッド間の必要な接続に影響を与える可能性があります。 次のコマンドを使用して、既存のネットワークポリシーを検索できます。 .. code:: sh kubectl get networkpolicies Kubernetesネットワーク管理者によって設定された複数のネットワークポリシーが存在する場合があります。 .. code:: sh $ kubectl get networkpolicies NAME POD-SELECTOR AGE allow-prometheus cnpg.io/cluster=cluster-example 47m default-deny-ingress 57m PostgreSQLコアダンプ -------------------- まれに、PostgreSQLはクラッシュし、\ ``PGDATA`` フォルダーにコアダンプを生成する場合があります。それが発生した場合、通常、それはPostgreSQLのバグであり、ほとんどの場合、既に解決されています。これが、常にPostgreSQLの最新のマイナーバージョンを実行することが重要である理由です。 CloudNativePGでは、 ``cnpg.io/coredumpFilter`` アノテーションを介してコアダンプに含めるものを制御できます。 .. Note:: :ref:`ラベルとアノテーション <ラベルとアノテーション>` を参照してください。 CloudNativePGが提供する標準のアノテーションの詳細については、 をご覧ください。 デフォルトでは、これがほとんどの場合最も安全なアプローチであるため、ダンプから共有メモリセグメントを除外するために、 ``cnpg.io/coredumpFilter`` は\ ``0x31`` に設定されます。 .. Note:: `Core dump filtering settings `_ を参照してください。コアダンプフィルタを制御するビットマスクを設定する方法の詳細については、 .. Important:: この設定はポッドの起動中にのみ有効になり、アノテーションを変更してもインスタンスの自動ロールアウトはトリガーされないことに注意してください。 あなたはコアダンプの検査に個人的に関わっていないかもしれませんが、 Postgresの専門家がそれらを調べることができるようにそれらの提供を求められる場合があります。まず、次のコマンドを使用して、\ ``PGDATA`` ディレクトリにコアダンプがあることを確認します。Postgresインスタンスが実行されている正しいポッドに対して実行してください。 .. code:: sh kubectl exec -ti POD -c postgres \ -- find /var/lib/postgresql/data/pgdata -name core.* 通常、これは空のセットを返すはずです。例、コアダンプファイルがあるとします。 :: /var/lib/postgresql/data/pgdata/core.14177 ディスク上の領域が十分であることを確認したら、次のように\ ``kubectl cp`` を介してマシンでコアダンプを収集できます。 .. code:: sh kubectl cp POD:/var/lib/postgresql/data/pgdata/core.14177 core.14177 これで、ファイルができました。コアダンプを削除して、サーバー上の領域を解放してください。 よくある問題 ------------ ストレージがいっぱいです ^^^^^^^^^^^^^^^^^^^^^^^^ クラスター内の1つ以上のポッドが\ ``CrashloopBackoff`` にあり、これがフルディスクが原因である可能性をログが示している場合、おそらくインスタンスの\ ``PersistentVolumeClaim`` のサイズを増やす必要があります。ドキュメントの :ref:`ボリュームの拡張 <ボリュームの拡張>` を参照してください。 ポッドが\ ``Pending`` 状態でスタックしている ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ クラスターのインスタンスが\ ``Pending`` フェーズでスタックしている場合、ポッドの\ ``Events`` セクションを確認して、この背後にある理由を理解する必要があります。 .. code:: shell kubectl describe pod -n この考えられる原因の一部は次のとおりです。 - ``nodeSelector`` と一致するノードはありません - Tolerationがノードのテイントと一致するように正しく構成されていません - 利用可能なノードがまったくありません。これは、\ ``cluster-autoscaler`` がいくつかの制限に到達したこと、または一時的な問題が発生したことに関連している可能性があります。 この場合、名前空間内のイベントをチェックすることも役立つ場合があります。 .. code:: shell kubectl get events -n # list events in chronological order kubectl get events -n --sort-by=.metadata.creationTimestamp バックアップが構成されていない場合、レプリカが同期していない ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 場合によっては、メンテナンスのため、レプリカが少しの間オフになる場合がありますKubernetesノードがドレインされたときを考えてください。クラスターにバックアップが構成されていない場合、レプリカがバックアップしたときに、プライマリにはもう存在しないWALファイル :ref:``postgresql` セクション <`postgresql` セクション>` で述べているように、WAL管理ポリシーに従って既にリサイクルされており、フォールアウトする場合があります同期のこと。 同様に、\ ``pg_rewind`` が以前のプライマリに存在しないWALファイルを必要とする場合、 ``pg_rewind: error: could not open file`` をレポートします。 これらの場合、ポッドの準備ができなくなるため、PVCを削除し、オペレーターにレプリカを再構築してもらう必要があります。 動的にプロビジョニングされた永続ボリュームに依存し、PV自分自身を削除することに自信がある場合は、次の方法で削除できます。 .. code:: shell PODNAME= 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`` でスタックしている ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ クラスターは「新しいレプリカの作成」でスタックしていますが、ポッドログには関連する問題は表示されません。これは、次の問題 :ref:`on connectivity <ネットワーキング>` に関連していることがわかりました。リリース1.20.1、1.19.3、および1.18.5から、ネットワークの問題は次のようにステータス列により明確に反映されます。 .. code:: text Instance Status Extraction Error: HTTP communication issue インストールされたネットワークポリシーにより、ネットワーキングが障害されます ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ :ref:`networking section <ネットワーキング>` で指摘されているように、ローカルネットワークポリシーは、必要な接続の一部を妨げる可能性があります。 接続が障害されていることを示す兆候は、オペレーターログに次のようなメッセージが存在することです。 .. code:: text "Cannot extract Pod status", […snipped…] "Get \"http://:8000/pg/status\": dial tcp :8000: i/o timeout" ネットワークポリシーをリストし、接続を制限するポリシーを探す必要があります。 .. code:: sh $ kubectl get networkpolicies NAME POD-SELECTOR AGE allow-prometheus cnpg.io/cluster=cluster-example 47m default-deny-ingress 57m たとえば、上記のリストでは、 ``default-deny-ingress`` が犯人である可能性が高いと思われます。それをドリルダウンできます。 .. code:: sh $ 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メモリの量を構成する必要があります。 例 .. code:: yaml postgresql: parameters: shared_buffers: "128MB" resources: requests: memory: "512Mi" limits: hugepages-2Mi: "512Mi" クラスター内のすべてのポッドをスケジュールするには、十分なhugepagesメモリが必要であることに注意してください。上記の例では、ポッドごとに少なくとも512MiBを解放する必要があります。