Troubleshooting =============== .. raw:: html このページでは、Kubernetesクラスター展開でCloudNativePGをトラブルシューティングする方法に関する基本的な情報を見つけることができます。 .. tip:: Kubernetes管理者は、 `kubectl `_ ページをブックマークする必要があります。 　 始める前に ---------- Kubernetes環境 ^^^^^^^^^^^^^^ トラブルシューティングアクティビティに違いをもたらすのは、基になるKubernetesシステムに関する明確な情報を提供することです。 次のことを確認してください - 使用しているKubernetesディストリビューションとバージョン - PostgreSQLが実行されているノードの仕様 - 運用に入る前に実行したストレージクラスとベンチマークを含む、実際の :ref:`その他のS3互換オブジェクトストレージプロバイダー <その他のS3互換オブジェクトストレージプロバイダー>` について可能な限り。 - クラスターで使用している関連するKubernetesアプリケーションつまりPrometheus、Grafana、Istio、Certmanagerなど。 - 継続的なバックアップの状況、特にそれが配置され、正常に動作している場合。そうでない場合、必ず :ref:`緊急バックアップ <緊急バックアップ>` を取ってください 潜在的な破壊的な操作を実行する前に 便利なユーティリティ ^^^^^^^^^^^^^^^^^^^^ トラブルシューティングの為、必須の\ ``kubectl`` ユーティリティに加えて、次のプラグイン/ユーティリティをシステムで使用できることをお勧めします。 - ``kubectl`` の場合 :ref:`postgresql.cnpg.io/v1 ` - `jq `_ 、軽量で柔軟なコマンドラインJSONプロセッサー - `grep `_ 、1つ以上の入力ファイルで、指定されたパターンとの一致を含む行を検索します。これは、ほとんどの*nixディストリビューションで既に利用可能です。 Windows OSを使用している場合は、 ``grep`` の代替として `findstr `_ を使用するか、 `wsl `_ を直接使用できます。 そして、好みの*nixディストリビューションをインストールし、上記のツールを使用します。 最初の一歩 ---------- クラスターまたはインストールの概要をすばやく取得するために、\ ``kubectl`` プラグインは使用する主なツールです。 1. :ref:`status subcommand ` は、クラスターの概要を提供します 2. :ref:`report subcommand ` は、クラスターとオペレーター展開のマニフェストを提供します。 ``--logs`` オプションを使用してログを含めることもできます。プラグインを介して生成されたレポートには、完全なクラスターマニフェストが含まれます。 プラグインは、パッケージを介してエアギャップシステムにインストールできます。完全な手順については、 :ref:`plugin document ` を参照してください。 バックアップはありますか？ -------------------------- プラグインでクラスターマニフェストを取得した後、バックアップがセットアップされ動作しているかどうかを確認する必要があります。 トラブルシューティング操作を続行する前に、バックアップに関する結果によっては、緊急バックアップを実行することをお勧めします。手順については、次のセクションを参照してください。 定期的なバックアップを保持せずに運用データベースを操作することは、 **非常にリスク** です。 緊急バックアップ ---------------- 一部の緊急の状況では、メインの\ ``app`` データベースの緊急論理バックアップを作成する必要がある場合があります。 .. Note:: 以下にある指示は、緊急の場合、および一時的なバックアップファイルは、組織で有効なデータ保護ポリシーの下で保存される場合にのみ実行する必要があります。ダンプファイルは実際に`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 .. Note:: このセクションの例では、推奨に従って、ダンプとリストアの他のグローバルオブジェクトデータベースとロールがないことを前提としています。複数のロールがある場合は、 `pg_dumpall -g` を使用してバックアップをとり、新しいクラスターに手動で復元していることを確認します。複数のデータベースがある場合、一度に1つのデータベースごとに上記の操作を繰り返し、適切な所有権を割り当てていることを確認する必要があります。 PostgreSQLに慣れていない場合は、専門のサポート会社の指導の下でこれらの重要な操作を実行することをお勧めします。 　 上記の手順は、将来のある段階で\ ``cnpg`` プラグインに統合される可能性があります。 ログ ---- CloudNativePGによって作成および管理されるすべてのリソースは、 :ref:`JSON形式のPostgreSQLエラーメッセージの標準出力ログ ` を使用して、Kubernetes規約に従って標準出力に記録されます。 ログは通常インフラレベルで処理され、CloudNativePGからのログが含まれますが、トラブルシューティング中にコマンドラインインターフェイスからログに直接アクセスすることが重要です。これには、3つの主なオプションがあります。 - ``kubectl logs`` コマンドを使用して特定のリソースからログを取得し、読みやすいように\ ``jq`` を適用します。 - CloudNativePG固有のロギングには :ref:`kubectl cnpg logs ` を使用します。 - `stern `_ のような専用のオープンソースツールを活用し、複数のリソースたとえば、 ``cnpg.io/clusterName`` ラベルを選択してPostgreSQLクラスター内のすべてのポッドからログを集計し、ログエントリをフィルタリング、出力形式をカスタマイズできます。 .. 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:18.1-system-trixie 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` オプションを追加することにより、詳細情報を印刷できます。 　 PostgreSQLコンテナイメージバージョンを取得します。 .. code:: shell kubectl describe cluster -n | grep "Image Name" 出力 .. code:: shell Image Name: ghcr.io/cloudnative-pg/postgresql:18.1-system-trixie .. 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, .record.message] | @csv タイムスタンプがUnixエポック時間で表示されている場合、使いやすい形式に変換できます。 .. 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 出力 .. code:: 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= ストレージ情報 -------------- 次のように、クラスターが使用する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 クラスターの準備ができているかどうか。 .. code:: bash $ kubectl wait --for=condition=Ready cluster/ -n 以下は、失敗条件を含む\ ``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:`Networking ` セクションをご覧ください。 既存の環境に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:`Labels and Annotations ` を参照してください。 CloudNativePGが提供する標準のアノテーションの詳細については、 をご覧ください。 　 デフォルトでは、これがほとんどの場合最も安全なアプローチであるため、ダンプから共有メモリセグメントを除外するために、 ``cnpg.io/coredumpFilter`` は\ ``0x31`` に設定されます。 .. Note:: `Core dump filtering settings `_ を参照してください。コアダンプフィルタを制御するビットマスクを設定する方法の詳細については、 　 .. Note:: この設定はポッドの起動中にのみ有効になり、アノテーションを変更してもインスタンスの自動ロールアウトはトリガーされないことに注意してください。 　 あなたはコアダンプの検査に個人的に関わっていないかもしれませんが、 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 これで、ファイルができました。コアダンプを削除して、サーバー上の領域を解放してください。 プロファイリングデータの視覚化と分析 ------------------------------------ CloudNativePGは `pprof `_ と統合して、2つのレベルでプロファイリングデータを収集および分析します。 - **オペレーターレベル** – ``--pprof-server=true`` オプションをオペレーター展開に追加することにより有効にします :ref:`Operator configuration ` を参照してください。 - **Postgresクラスターレベル** – ``alpha.cnpg.io/enableInstancePprof`` アノテーションを\ ``Cluster`` リソース以下に説明を追加することにより有効にします。 ``alpha.cnpg.io/enableInstancePprof`` アノテーションが\ ``"true"`` に設定されている場合、各インスタンスポッドは、インスタンスマネージャーが提供するGo pprof HTTPサーバーを公開します。 - サーバーはポッド内の\ ``0.0.0.0:6060`` でリッスンします。 - ``pprof`` ``6060/TCP`` という名前のコンテナポートがポッド仕様に自動的に追加されます。 アノテーションを削除するか、\ ``"false"`` に設定することにより、いつでもpprofを無効にできます。オペレーターは変更を自動的にロールアウトして、pprofポートとフラグを削除します。 .. Note:: pprofサーバーは、ポート`6060` でプレーンHTTPのみを提供します。 　 例 ^^ 次のアノテーションを追加して、クラスターでpprofを有効にします。 .. code:: yaml apiVersion: postgresql.cnpg.io/v1 kind: Cluster metadata: name: cluster-example annotations: alpha.cnpg.io/enableInstancePprof: "true" spec: instances: 3 # ... このアノテーションを変更すると、インスタンスポッド仕様が更新されポート\ ``6060`` および対応するフラグが追加され、ローリング更新がトリガーされます。 .. Warning:: 次の例では、ローカルテストのみに`kubectl port-forward` を使用します。これは、運用環境で機能を公開するための意図された方法ではありません**。 pprofを機密デバッグインターフェイスとして扱い、決して公開しないでください。リモートでアクセスする必要がある場合は、適切なネットワークポリシーとアクセス制御で保護してください。 　 ポート転送を使用してpprofエンドポイントにアクセスします。 .. code:: bash kubectl port-forward -n pod/ 6060 curl -sS http://localhost:6060/debug/pprof/ go tool pprof http://localhost:6060/debug/pprof/profile?seconds=30 `http://localhost:6060/debug/pprof/ `_ ブラウザーを使用してpprofにアクセスすることもできます。 .. _障害対応-1: 障害対応 ^^^^^^^^ 最初に、クラスターに\ ``alpha.cnpg.io/enableInstancePprof: "true"`` アノテーションセットがあることを確認します。 次に、instance managerコマンドに\ ``--pprof-server`` フラグが含まれ、ポート\ ``6060/TCP`` が公開されていることを確認します。これは、次を実行して行うことができます。 .. code:: bash kubectl -n describe pod 次に、出力の **Command** および **Ports** セクションを確認します。 最後に、ポート転送を使用していない場合は、ネットワークポリシーがポート\ ``6060/TCP`` へのアクセスを許可していることを確認します。 いくつかの既知の問題 -------------------- ストレージがいっぱいです ^^^^^^^^^^^^^^^^^^^^^^^^ ストレージがいっぱいの場合、PostgreSQLポッドは新しいデータを書き込むことができません。または、WALセグメントを含むディスクがいっぱいである場合、PostgreSQLはシャットダウンします。 ディスクがいっぱいであることに関するメッセージがログにある場合は、影響を受けるPVCのサイズを増やす必要があります。これは、PVCを編集し、\ ``spec.resources.requests.storage`` フィールドを変更することにより行うことができます。その後、新しいサイズでクラスターリソースを更新して、同じ変更をすべてのポッドに適用する必要があります。ドキュメントの :ref:`ボリュームの拡張 <ボリュームの拡張>` を参照してください。 WALセグメントの領域が使い果たされると、ポッドはクラッシュループし、クラスターステータスは\ ``Not enough disk space`` と報告されます。 PVC、次にクラスターリソースのサイズを増やすと、問題が解決されます。 :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:`インストールされたネットワークポリシーにより、ネットワーキングが障害されます <インストールされたネットワークポリシーにより、ネットワーキングが障害されます>` に関連していることがわかりました。ネットワークの問題は、次のようにステータス列に反映されます。 .. code:: text Instance Status Extraction Error: HTTP communication issue インストールされたネットワークポリシーにより、ネットワーキングが障害されます ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ :ref:`Networking ` で指摘されたように、ローカルネットワークポリシーは、必要な接続の一部を妨げる可能性があります。 接続が障害されていることを示す兆候は、オペレーターログに次のようなメッセージが存在することです。 .. 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: Nothonoring huge_pages setting during initdb causes DB crash inKubernetes `_ を確認してください。 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を解放する必要があります。 ブートストラップジョブが実行中ステータスでハングする ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``Running`` ステータスにあるときにクラスターの初期化ジョブがハングし、メッセージ「APIサーバーが到達可能になるのを待機しているときにエラーが発生した場合」は、おそらくネットワークに問題があり、Kubernetes APIサーバーとの通信を妨げています。初期化ジョブほとんどのジョブと同様に、Kubernetes APIにアクセスする必要があります。ネットワークを確認してください。 もう1つの考えられる原因は、サイドカーインジェクションを構成している場合です。 Istioなどのサイドカーは、起動中にネットワークを一時的に利用できなくなる場合があります。サイドカーインジェクションを有効にしている場合は、インジェクションを無効にして再試行します。 レプリカは、フェールオーバー後の再接続に2分以上かかります ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ プライマリインスタンスに障害が発生すると、オペレーターは最も高度なスタンバイをプライマリロールに昇格させます。他のスタンバイインスタンスは、レプリケーションのために\ ``-rw`` サービスに再接続しようとします。ただし、この再接続プロセス中に、\ ``kube-proxy`` はルーティング情報をまだ更新していない場合があります。その結果、スタンバイインスタンスによって送信された最初の\ ``SYN`` パケットは、目的の宛先に到達しない場合があります。 ネットワークがパケットを拒否するのではなく、サイレントにドロップするように構成されている場合、スタンバイインスタンスは応答を受信せず、指数バックオフ期間の後に接続を再試行します。 Linuxシステムでは、 ``tcp_syn_retries`` カーネルパラメーターのデフォルト値は6です。これは、システムが断念するまでに約127秒間の接続の確立を試行することを意味します。この再試行期間が長くなると、再接続プロセスが大幅に遅延する可能性があります。詳細については、 `tcp_syn_retries documentation `_ を参照してください。 :ref:`Operator configuration ` で\ ``STANDBY_TCP_USER_TIMEOUT`` を設定することにより、この問題をワークアラウンドできます。これにより、最初の\ ``SYN`` パケットが指定されたタイムアウト内に確認されない場合、スタンバイインスタンスはTCP接続を閉じ、より迅速に接続を再試行できます。