CrashLoopBackOff イベントのトラブルシューティング

Autopilot Standard

Google Kubernetes Engine（GKE）の Pod が CrashLoopBackOff 状態のままになっている場合、これは 1 つ以上のコンテナが起動と終了を繰り返していることを意味します。この動作により、アプリが不安定になったり、まったく使用できなくなったりする可能性があります。

このページを参考に、リソースの制限、liveness プローブの問題、アプリのエラー、構成ミスなどのカテゴリに分類されることが多い、この問題の根本原因を診断して解決してください。これらの問題をトラブルシューティングすることで、アプリが確実に動作して、常にユーザーが利用できるようになります。

このページで提供する情報は、コーディング エラー、エントリ ポイントの誤り、構成ファイルの問題、依存関係との接続の問題といったアプリレベルの問題を特定して修正する必要があるアプリケーション デベロッパーにとって重要となります。プラットフォーム管理者とオペレーターは、リソースの枯渇（OOMKilled）、ノードの停止、liveness プローブの構成ミスといったプラットフォーム関連の問題を特定して対処できます。 Google Cloud のコンテンツで使用されている一般的なロールとタスクの例の詳細については、一般的な GKE ユーザーのロールとタスクをご覧ください。

CrashLoopBackOff イベントについて理解する

Pod が CrashLoopBackOff 状態のままになると、Pod 内のコンテナが起動してクラッシュ / 終了するサイクルが繰り返されます。このクラッシュループが発生すると、Kubernetes は restartPolicy に従ってコンテナの再起動を試みます。再起動が失敗するたびに、次の試行までのバックオフ遅延は指数関数的に増加し（10 秒、20 秒、40 秒など）、最大で 5 分になります。

このイベントはコンテナ内の問題を示すものですが、貴重な診断シグナルでもあります。CrashLoopBackOff イベントは、ノードへの割り当てやコンテナ イメージの pull など、Pod の作成の多くの基本的なステップがすでに完了していることを裏付けるものです。この知識があれば、調査の重点をクラスタ インフラストラクチャではなく、コンテナのアプリまたは構成に絞ることができます。

CrashLoopBackOff 状態が発生する原因は、Kubernetes（特に kubelet）が Pod の再起動ポリシーに基づいてコンテナの終了を処理する方法にあります。通常、このサイクルは次のパターンに従います。

1. コンテナが起動する。
2. コンテナが終了する。
3. kubelet が停止したコンテナを監視し、Pod の restartPolicy に従って再起動する。
4. このサイクルが繰り返される間、徐々に増やされる指数バックオフ遅延の後に、コンテナが再起動されます。

この動作の鍵となるのが、Pod の restartPolicy です。デフォルト ポリシーの Always は、このループの最も一般的な原因となります。このポリシーでは、たとえコンテナが正常に終了したとしても、なんらかの理由で終了したコンテナを再起動するためです。OnFailure ポリシーでは、終了コードがゼロ以外の場合にのみコンテナを再起動するため、ループが発生する可能性は低くなります。また、Never ポリシーでは再起動が完全に回避されます。

CrashLoopBackOff イベントの症状を特定する

CrashLoopBackOff イベントの主な指標は、Pod のステータスが CrashLoopBackOff となっていることです。

ただし、CrashLoopBackOff イベントには、次のようなそれほど明白ではない症状が伴う場合もあります。

• ワークロードの正常なレプリカが一つもない。
• 正常なレプリカの数が急激に減る。
• 水平 Pod 自動スケーリングが有効にされているワークロードのスケーリングに時間がかかるか、スケーリングが失敗する。

system ワークロード（ロギング エージェントや指標エージェントなど）のステータスが CrashLoopBackOff の場合は、次の症状が伴う可能性もあります。

• 一部の GKE 指標が報告されない。
• 一部の GKE ダッシュボードとグラフにギャップがある。
• Pod レベルのネットワーキングで接続の問題が発生する

それほど明白ではない上記の症状が一つでも見られた場合は、次のステップとして CrashLoopBackOff イベントが発生したかどうかを確認する必要があります。

CrashLoopBackOff イベントを確認する

CrashLoopBackOff イベントを確認して調査するには、Kubernetes イベントとコンテナのアプリログから証拠を収集します。これら 2 つのソースから得られる問題に対する見解は、それぞれ異なるものの、互いに補完し合うものです。

• Kubernetes イベントでは、Pod がクラッシュしていることを確認できます。
• コンテナのアプリログでは、コンテナ内のプロセスが失敗した理由を確認できます。

これらの情報を確認するには、次のいずれかのオプションを選択します。

コンソール

Kubernetes イベントとアプリログを表示するには、次の手順に従います。

1. Google Cloud コンソールで、[ワークロード] ページに移動します。

   [ワークロード] に移動

2. 調査するワークロードを選択します。[概要] タブまたは [詳細] タブに、ワークロードのステータスに関する詳細情報が表示されます。

3. [マネージド Pod] セクションで、問題のある Pod の名前をクリックします。

4. Pod の詳細ページで、次の項目を調べます。

   • Kubernetes イベントの詳細を表示するには、[イベント] タブに移動します。
   • コンテナのアプリログを表示するには、[ログ] タブに移動します。このページには、アプリ固有のエラー メッセージやスタック トレースが表示されます。

kubectl

Kubernetes イベントとアプリログを表示するには、次の手順に従います。

1. クラスタで実行されているすべての Pod のステータスを確認します。

   kubectl get pods
   

   出力は次のようになります。

   NAME       READY  STATUS             RESTARTS  AGE
   POD_NAME   0/1    CrashLoopBackOff   23        8d
   

   出力で、次の列を確認します。

   • Ready: 使用できる状態のコンテナの数を確認します。この例での 0/1 は、想定される 1 つのコンテナのうち 0 個が使用できる状態であることを意味します。この値は、問題の明確な兆候です。
   • Status: ステータスが CrashLoopBackOff となっている Pod を特定します。
   • Restarts: 値が大きい場合、これは Kubernetes がコンテナの起動を繰り返し試みて失敗していることを意味します。

2. 失敗した Pod を特定したら、その Pod の状態に関連するクラスタレベルのイベントを確認します。

   kubectl describe pod POD_NAME -n NAMESPACE_NAME
   

   次のように置き換えます。

   • POD_NAME: kubectl get コマンドの出力で特定した Pod の名前
   • NAMESPACE_NAME: Pod の Namespace

   出力は次のようになります。

   Containers:
   container-name:
   ...
     State:          Waiting
       Reason:       CrashLoopBackOff
     Last State:     Terminated
       Reason:       StartError
       Message:      failed to create containerd task: failed to create shim task: context deadline exceeded: unknown
       Exit Code:    128
       Started:      Thu, 01 Jan 1970 00:00:00 +0000
       Finished:     Fri, 27 Jun 2025 16:20:03 +0000
     Ready:          False
     Restart Count:  3459
   ...
   Conditions:
   Type                        Status
   PodReadyToStartContainers   True
   Initialized                 True
   Ready                       False
   ContainersReady             False
   PodScheduled                True
   ...
   Events:
   Type     Reason   Age                     From     Message
   ----     ------   ----                    ----     -------
   Warning  Failed   12m (x216 over 25h)     kubelet  Error: context deadline exceeded
   Warning  Failed   8m34s (x216 over 25h)   kubelet  Error: context deadline exceeded
   Warning  BackOff  4m24s (x3134 over 25h)  kubelet  Back-off restarting failed container container-name in pod failing-pod(11111111-2222-3333-4444-555555555555)
   

   出力で次のフィールドを調べて、CrashLoopBackOff イベントの兆候の有無を確認します。

   • State: コンテナの状態は、CrashLoopBackOff が理由の Waiting になっている可能性があります。
   • Last State: 以前に終了したコンテナの状態。Terminated ステータスを探して、その終了コードを確認し、クラッシュが発生したのか（ゼロ以外の終了コード）、それとも予期せずに正常に終了したのか（ゼロの終了コード）を判断します。
   • Events: クラスタ自体によって実行されたアクション。コンテナの起動に関するメッセージを探し、そのメッセージの後に liveness プローブの失敗や Back-off restarting failed container などのバックオフ警告が続いているかどうかを確認します。

3. Pod が失敗した理由の詳細を確認するには、アプリのログを表示します。

   kubectl logs POD_NAME --previous
   

   --previous フラグにより、以前に終了したコンテナからログが取得されます。このログには、クラッシュの原因を明らかにする特定のスタック トレースやエラー メッセージが含まれています。現在のコンテナが新しすぎると、ログが記録されていない場合もあります。

   出力で、プロセスの終了原因となっているアプリ固有のエラーを探します。カスタムメイドのアプリを使用している場合、これらのエラー メッセージを解釈するのに適任なのは、そのアプリを作成したデベロッパーです。ビルド済みアプリを使用している場合は、アプリ固有のデバッグ手順が用意されていることがよくあります。

クラッシュループしている Pod のインタラクティブ ハンドブックを使用する

CrashLoopBackOff イベントを確認したら、インタラクティブ ハンドブックを使用してトラブルシューティングを開始します。

1. Google Cloud コンソールで、[GKE のインタラクティブ ハンドブック - クラッシュループしている Pod] ページに移動します。

   [クラッシュループしている Pod] に移動

2. [クラスタ] リストで、トラブルシューティングの対象とするクラスタを選択します。クラスタが見つからない場合は、[フィルタ] フィールドにクラスタの名前を入力します。

3. [Namespace] リストで、トラブルシューティングの対象とする Namespace を選択します。Namespace が見つからない場合は、[フィルタ] フィールドに Namespace を入力します。

4. 各セクションを確認して、次の疑問に対する答えを見つけます。

   1. アプリのエラーの特定: どのコンテナが再起動を繰り返しているのか？
   2. メモリ不足の問題についての調査: 構成ミスや、アプリに関連するエラーがあるか？
   3. ノード中断についての調査: ノードリソース上での中断によって、コンテナが再起動されているのか？
   4. liveness プローブの失敗についての調査: liveness プローブによってコンテナが停止されているのか？
   5. 変更イベントとの関連付け: コンテナがクラッシュするようになった時刻の前後に何が起きていたのか？

5. 省略可: 今後 CrashLoopBackOff イベントが発生した場合に通知を受け取るには、[今後の対応のヒント] セクションで [アラートを作成する] を選択します。

ハンドブックを使用しても問題が解決しない場合は、このガイドの残りの部分を読んで、CrashLoopBackOff イベントの解決方法の詳細を確認してください。

CrashLoopBackOff イベントを解決する

以降のセクションでは、CrashLoopBackOff イベントの最も一般的な原因である以下の問題を解決する方法を説明します。

• リソースの枯渇（OOMKilled）
• liveness プローブの失敗
• アプリの構成ミス

リソースの枯渇を解決する

多くの場合、CrashLoopBackOff イベントはメモリ不足（OOM）の問題が原因で発生します。kubectl describe の出力に次の内容が示されている場合は、OOM が原因であることを確認できます。

Last State: Terminated
  Reason: OOMKilled

OOM イベントを診断して解決する方法については、OOM イベントのトラブルシューティングをご覧ください。

liveness プローブの失敗を解決する

liveness プローブは、kubelet によって実行される定期的なヘルスチェックです。プローブが指定された回数（デフォルトでは 3 回）失敗すると、kubelet はコンテナを再起動します。プローブの失敗が続くと、CrashLoopBackOff イベントが発生する可能性があります。

liveness プローブが原因かどうかを確認する

liveness プローブの失敗が CrashLoopBackOff イベントをトリガーしているかどうかを確認するには、kubelet ログに対してクエリを実行します。これらのログには、プローブの失敗とそれに続く再起動について伝える明示的なメッセージが含まれていることがよくあります。

1. Google Cloud コンソールで、[ログ エクスプローラ] ページに移動します。

   [ログ エクスプローラ] に移動

2. クエリペインで次のクエリを入力して、liveness プローブに関連する再起動をフィルタします。

   resource.type="k8s_node"
   log_id("kubelet")
   jsonPayload.MESSAGE:"failed liveness probe, will be restarted"
   resource.labels.cluster_name="CLUSTER_NAME"
   

   CLUSTER_NAME は、使用するクラスタの名前に置き換えます。

3. 出力を確認します。Liveness プローブの失敗が CrashLoopBackOff イベントの原因である場合、クエリによって次のようなログメッセージが返されます。

   Container probe failed liveness probe, will be restarted
   

liveness プローブが CrashLoopBackOff イベントの原因であることを確認したら、一般的な原因のトラブルシューティングを開始します。

• liveness プローブの構成を確認する。
• CPU とディスク I/O の使用率を調べる。
• 大規模なデプロイに対処する。
• 一時的なエラーに対処する。
• プローブのリソース消費量に対処する。

liveness プローブの構成を確認する

プローブの構成ミスは、CrashLoopBackOff イベントの一般的な原因の一つです。プローブのマニフェストで次の設定を確認します。

• プローブのタイプを確認する: プローブの構成は、アプリが健全性をレポートする方法と一致している必要があります。たとえば、アプリにヘルスチェック URL（/healthz など）がある場合は、httpGet タイプのプローブを使用します。コマンドを実行して正常性が判断される場合は、exec タイプのプローブを使用します。たとえば、ネットワーク ポートが開いてリッスンしているかどうかを確認するには、tcpSocket タイプのプローブを使用します。
• プローブ パラメータを確認する:
  • パス（httpGet タイプのプローブの場合）: HTTP パスが正しく、アプリがそのパスでヘルスチェックを行っていることを確認します。
  • ポート: プローブで構成されているポートがアプリで実際に使用および公開されていることを確認します。
  • コマンド（exec タイプのプローブの場合）: コマンドがコンテナ内に存在し、成功時には終了コード 0 を返し、かつ、構成されている timeoutSeconds 期間内に完了することを確認します。
  • タイムアウト: timeoutSeconds の値が、特に起動時や負荷がかかっているときでもアプリが応答するのに十分であることを確認します。
  • 初期遅延（initialDelaySeconds）: プローブが開始される前にアプリが起動するのに十分な初期遅延が設けられているかどうかを確認します。

詳細については、Kubernetes ドキュメントの liveness プローブ、readiness プローブ、startup プローブを構成するをご覧ください。

CPU とディスク I/O の使用率を調べる

リソース競合によってプローブがタイムアウトすると、それが liveness プローブ失敗の主な原因となります。リソース使用率が liveness プローブ失敗の原因であるかどうかを確認するには、次の解決策を試してください。

• CPU 使用率を分析する: プローブ間隔中に、影響を受けるコンテナと、そのコンテナが実行されているノードの CPU 使用率をモニタリングします。その際に追跡する主な指標は kubernetes.io/container/cpu/core_usage_time です。コンテナまたはノードの CPU 使用率が高いと、アプリが時間内にプローブに応答できなくなる可能性があります。
• ディスク I/O をモニタリングする: ノードのディスク I/O 指標を確認します。compute.googleapis.com/guest/disk/operation_time 指標を使用すると、ディスク オペレーションに要した時間を評価できます。この指標は、読み取りと書き込みで分類されます。ディスク I/O が高いと、コンテナの起動やアプリの初期化にかなりの時間がかかったり、アプリ全体のパフォーマンスが大幅に低下したりする可能性があります。こうした状態は、プローブのタイムアウトにつながります。

大規模なデプロイに対応する

多数の Pod が同時にデプロイされるシナリオ（たとえば、ArgoCD などの CI/CD ツールによるデプロイ）では、新しい Pod の急増によってクラスタ リソースが過負荷状態になり、コントロール プレーンのリソースが枯渇する可能性があります。リソースが不足すると、アプリの起動に時間がかかるため、アプリの準備が整う前に liveness プローブが繰り返し失敗する可能性があります。

この問題を解決するには、次のことを試してください。

• 段階的なデプロイを実装する: ノードリソースの過負荷を避けるため、Pod をバッチで、または長期間にわたってデプロイする戦略を実装します。
• ノードを再構成またはスケールする: 段階的なデプロイが実現可能でない場合は、I/O 需要の増加に対応しやすくするために、高速または大容量のディスク、あるいは Persistent Volume Claim を使用してノードをアップグレードすることを検討してください。クラスタの自動スケーリングが適切に構成されるようにします。
• 待機して観察する: クラスタが深刻なリソース不足に陥っていないとしたら、ワークロードが大幅な遅延（30 分以上かかることもあります）の後にデプロイされることもあります。

一時的なエラーに対処する

アプリの起動時や初期化時に一時的なエラーや速度低下が発生すると、初めにプローブが失敗する可能性があります。最終的にアプリが回復したら、liveness プローブのマニフェストにある initialDelaySeconds フィールドまたは failureThreshold フィールドで定義されている値を大きくすることを検討してください。

プローブのリソース消費量に対処する

まれに、liveness プローブの実行自体が大量のリソースを消費して、リソース制約がトリガーされ、OOM 強制終了によってコンテナが終了することがあります。プローブ コマンドが軽量であることを確認します。プローブが軽量だと迅速かつ確実に実行される可能性が高くなるため、より優れた忠実度でアプリの実際の健全性を正確に報告します。

アプリの構成ミスを解決する

アプリの構成ミスにより、多くの CrashLoopBackOff イベントが発生します。アプリが停止した理由を把握するには、まず終了コードを調べます。このコードによって、トラブルシューティングの経路が決まります。

• 終了コード 0 は正常な終了を意味しますが、長時間実行されるサービスでは予期されないコードであり、コンテナのエントリ ポイントまたはアプリの設計に問題があることを示します。
• ゼロ以外の終了コードはアプリのクラッシュを示唆するため、構成エラー、依存関係の問題、コードのバグに注意を向けることになります。

終了コードを確認する

アプリの終了コードを確認する手順は次のとおりです。

1. Pod の説明を取得します。

   kubectl describe pod POD_NAME -n NAMESPACE_NAME
   

   次のように置き換えます。

   • POD_NAME: 問題が発生している Pod の名前
   • NAMESPACE_NAME: Pod の Namespace

2. 出力の Last State セクションにある Exit Code フィールドで、関連するコンテナを確認します。終了コードが 0 の場合は、正常終了（終了コード 0）のトラブルシューティングをご覧ください。終了コードが 0 以外の数値の場合は、アプリクラッシュ（ゼロ以外の終了コード）のトラブルシューティングをご覧ください。

正常終了（終了コード 0）のトラブルシューティング

通常、終了コード 0 は、コンテナのプロセスが正常に終了したことを意味します。タスクベースの Job では、これは望ましい結果ですが、Deployment、StatefulSet、ReplicaSet などの長時間実行されるコントローラでは問題を示唆する可能性があります。

これらのコントローラは、Pod が常に稼働中の状態になるように動作するため、いずれの終了も修正すべき障害として扱います。kubelet はこの動作を強制するために、Pod の restartPolicy（デフォルトでは Always）に従って、正常に終了した後でもコンテナを再起動します。このアクションによりループが生じて、最終的には CrashLoopBackOff ステータスがトリガーされます。

予期しない正常終了の最も一般的な原因は次のとおりです。

• コンテナ コマンドが永続的なプロセスを開始しない: コンテナは、その初期プロセス（command または entrypoint）が実行されている間に限って稼働中の状態を維持します。このプロセスが長時間実行されるサービスでない場合、コマンドが完了すると同時にコンテナが終了します。たとえば、["/bin/bash"] のようなコマンドは、実行するスクリプトがないため、すぐに終了します。この問題を解決するには、コンテナの初期プロセスで、継続的に実行されるプロセスを開始するようにします。

• 作業キューが空になるとワーカーアプリが終了する: 多くのワーカーアプリは、キューでタスクの有無を確認し、キューが空の場合はすぐに終了するように設計されています。この問題を解決するには、Job コントローラ（完了するまで実行されるタスク用に設計されています）を使用するか、アプリのロジックを変更して永続的サービスとして実行されるようにします。

• 構成が欠落しているか、または無効なためにアプリが終了する: コマンドライン引数、環境変数、重要な構成ファイルなど、起動に必要な指示が欠落している場合、アプリが直ちに終了することがあります。

  この問題を解決するには、まずアプリのログで、構成の読み込みやパラメータの欠落に関連する特定のエラー メッセージがないかどうかを確認します。そのうえで、次の点を確認します。

  • アプリの引数または環境: 必要なコマンドライン引数と環境変数のすべてが、アプリの想定どおりに正しくコンテナに渡されていることを確認します。
  • 構成ファイルの存在: 必要な構成ファイルがコンテナ内の想定されるパスに存在することを確認します。
  • 構成ファイルの内容: 構成ファイルの内容と形式を調べて、構文エラー、必須フィールドの欠落、値の誤りがないことを確認します。

  この問題の一般的な例としては、ConfigMap ボリュームでマウントされたファイルから読み取るようにアプリが構成されている場合が挙げられます。構成が欠落している場合は終了するように設計されているアプリは、ConfigMap がアタッチされていないか、空であるか、または誤った名前のキーが使われていると、終了コード 0 で停止します。このような場合に確認すべき設定として、Pod のボリューム定義の ConfigMap 名が実際の名前と一致していることを確認します。また、ConfigMap 内のキーが、アプリがマウントされたボリューム内のファイル名として検出することになっているものと一致することも確認します。

  注: 必須の構成が欠落している場合、適切に設計されたアプリはゼロ以外のエラーコードで終了しますが、この状況でも（コード 0 で）正常に終了するように作成されているアプリもあります。

アプリクラッシュ（ゼロ以外の終了コード）のトラブルシューティング

コンテナがゼロ以外の終了コードで終了すると、Kubernetes はコンテナを再起動します。エラーの原因となった根本的な問題が解決されていなければ、アプリが再びクラッシュするというサイクルが繰り返されて、最終的に CrashLoopBackOff 状態になります。

ゼロ以外の終了コードは、アプリ自体でエラーが発生したことを示す明確なシグナルです。この場合、アプリの内部動作と環境を重点にデバッグ作業を行うことになります。ゼロ以外の終了コードでの終了は、次の問題が原因で発生することがよくあります。

• 構成エラー: ゼロ以外の終了コードは、アプリの構成または実行環境の問題を示唆していることがよくあります。アプリに次の一般的な問題がないかどうかを確認します。

  • 構成ファイルが見つからない: アプリが必要な構成ファイルを見つけられないか、アクセスできない可能性が考えられます。
  • 無効な構成: 構成ファイルに構文エラー、不正な値、互換性のない設定が含まれていると、アプリがクラッシュする可能性があります。
  • 権限の問題: アプリに構成ファイルの読み取りまたは書き込みに必要な権限が付与されていない可能性があります。
  • 環境変数: 環境変数が正しくないか、欠落していると、アプリが誤動作したり、起動に失敗したりする可能性があります。
  • 無効な entrypoint または command: コンテナの entrypoint フィールドまたは command フィールドで指定されたコマンドが正しくない可能性が考えられます。この問題は、実行可能ファイルへのパスが間違っているか、ファイル自体がコンテナ イメージに存在していない場合に、新しくデプロイされたイメージで発生する可能性があります。この構成ミスにより、多くの場合は 128 終了コードが返されます。

  • 制御されていないイメージの更新（:latest タグ）: ワークロード イメージで :latest タグを使用している場合、新しい Pod が更新されたイメージ バージョンを pull することで、破壊的変更が取り込まれる可能性があります。

    整合性と再現性を確保するため、本番環境では常に特定の不変のイメージタグ（v1.2.3 など）または SHA ダイジェスト（sha256:45b23dee08... など）を使用してください。この方法により、毎回必ず同じイメージ コンテンツが取得されるようになります。

• 依存関係の問題: 依存している他のサービスに接続できない場合、認証に失敗した場合、またはそれらにアクセスするための権限が不足している場合、アプリがクラッシュする可能性があります。

  • 外部サービスが利用できない: アプリが依存している外部サービス（データベースや API など）に、ネットワーク接続の問題やサービス停止が原因でアクセスできない可能性が考えられます。この問題をトラブルシューティングするには、Pod に接続します。詳細については、Kubernetes ドキュメントの実行中の Pod をデバッグするをご覧ください。

    Pod に接続したら、コマンドを実行してファイルやデータベースへのアクセスを確認したり、ネットワークをテストしたりできます。たとえば、curl などのツールを使用して、サービスの URL にアクセスできます。この操作を行うと、問題の原因がネットワーク ポリシー、DNS、またはサービス自体にあるかどうかを判断できます。

  • 認証の失敗: 認証情報が正しくないために、アプリが外部サービスで認証できない可能性が考えられます。コンテナのログで、401 Unauthorized（無効な認証情報）や 403 Forbidden（権限が不足しています）などのメッセージの有無を確認します。これらのメッセージは、多くの場合、Pod のサービス アカウントに外部 Google Cloudサービス呼び出しを行うために必要な IAM ロールがないことを意味します。

    GKE Workload Identity 連携を使用している場合は、プリンシパル ID にタスクを実行するのに必要な権限があることを確認します。GKE Workload Identity 連携を使用してプリンシパルに IAM ロールを付与する方法については、認可とプリンシパルを構成するをご覧ください。また、GKE メタデータ サーバーのリソース使用量が上限を超えていないことを確認する必要もあります。

  • タイムアウト: アプリが外部サービスからのレスポンスを待機しているときにタイムアウトしたことが原因で、クラッシュしている可能性が考えられます。

• アプリ固有のエラー: 構成と外部依存関係が正しいと思われる場合は、アプリのコード内にエラーがある可能性が考えられます。アプリログを調べて、次の一般的な内部エラーがないかどうかを確認します。

  • 未処理の例外: アプリログには、未処理の例外やコード関連のバグを示すスタック トレースやエラー メッセージが含まれている場合があります。
  • デッドロックまたはライブロック: アプリがデッドロックに陥っている可能性があります。デッドロックとは、複数のプロセスが互いの完了を待機している状態を指します。このシナリオでは、アプリは終了しないとしても無期限に応答を停止します。
  • ポートの競合: アプリが別のプロセスですでに使用されているポートにバインドしようとして、起動に失敗している可能性が考えられます。
  • 互換性のないライブラリ: アプリが、ランタイム環境に存在しないライブラリや、ランタイム環境と互換性のないライブラリに依存している可能性が考えられます。

  根本原因を特定するには、コンテナのログで特定のエラー メッセージまたはスタック トレースを調べます。この情報を参考に、アプリコードを修正するか、リソース上限を調整するか、環境の構成を修正するかを判断します。ログの詳細については、GKE ログについてをご覧ください。

次のステップ

• このドキュメントで問題を解決できない場合は、サポートを受けるで、次のトピックに関するアドバイスなど、詳細なヘルプをご覧ください。

  • Cloud カスタマーケアに問い合わせて、サポートケースを登録する。
  • StackOverflow で質問する、google-kubernetes-engine タグを使用して類似の問題を検索するなどして、コミュニティからサポートを受ける。#kubernetes-engine Slack チャネルに参加して、コミュニティ サポートを利用することもできます。
  • 公開バグトラッカーを使用して、バグの報告や機能リクエストの登録を行う。