KubernetesでCrashLoopBackOffになる原因と確認手順｜ログ・OOMKilled
CrashLoopBackOffはコンテナの再起動が繰り返し失敗しているときの表示です。直前の失敗ログと終了理由を先に記録して、OOM・アプリ設定・probeを切り分けます。
この記事の目的
CrashLoopBackOffという結果ではなく、コンテナプロセスが終了した原因と再起動の仕組みを調べます。
最初にやること
kubectl describe podでLast StateとEventsを確認し、kubectl logs --previousで前回終了ログを取得します。
app・APP・POD_NAME・CONTAINER_NAMEは例です。context・namespace・権限を実環境で確認してください。関連するガイド
Kubernetes・kubectl基本操作
対象と原因を絞り、変更前後の確認手順へ進みます。
記事を読む →KubernetesDeploymentの更新と切り戻し
rollout history・status・undoと変更前後の確認を行います。
記事を読む →KubernetesImagePullBackOffの原因
対象と原因を絞り、変更前後の確認手順へ進みます。
記事を読む →1. CrashLoopBackOffは原因名ではない
CrashLoopBackOffはコンテナの失敗・再起動を繰り返す際の待機状態です。Podのphaseとは異なり、アプリ設定・権限・プロセス終了、probe失敗、メモリ不足など複数の原因があり得ます。
2. describeと前回ログ
複数コンテナの場合は-cで対象を指定します。前回コンテナのログが保持されていなければ、--previousが失敗しても正常とは限りません。
3. 終了理由を分類する
| 表示・状況 | 確認すること |
|---|---|
| OOMKilled | メモリlimits、実際の使用量、Node資源、直前のエラーログ |
| Exit Code 1等 | アプリ起動設定・引数・環境変数・Secretsの参照 |
| Exit Code 137 | SIGKILL等。OOMKilledやNode状態と組み合わせて判断 |
| Liveness probe failed | 起動後の生存確認、port・path・timeout・閾値 |
| Startup probe failed | 起動時間・初期化処理とprobeの猶予設定 |
4. PodとDeploymentの設定を見る
PodがDeploymentで管理されているなら、更新履歴とPodのテンプレートを確認します。describeのEventsは保持期間や集約に制限があります。Secretsの中身を公開チケットへ貼らないでください。
5. 終了理由別の対処と切り戻し条件
想定例（実機結果ではありません）：EventsにBack-off restarting failed containerと出ても、これは再起動待機を示すだけです。Last State、終了コード、直前ログ、probe失敗イベントと変更履歴から原因を判断します。
| 確認結果 | 次の具体的な対応 |
|---|---|
OOMKilled / 終了コード137 | メモリlimit、Node割当量、監視値、直前ログを突合。137だけではOOMと断定しない。リーク・一時負荷・設定不備を特定後、管理元で適切なリソース変更やアプリ修正を計画 |
終了コード1、Errorと設定読込エラー | コンテナの起動引数、必須環境変数、ConfigMap/Secret参照キー、アプリ権限、外部依存先を確認。ログに秘密を貼らず、管理元の設定を修正 |
Liveness probe failed | 実際のlisten port、path、応答時間と閾値を比較。アプリ障害なのかprobe定義不一致なのか切り分け、監視を単に無効化しない |
Startup probe failed | 初期化処理の所要時間・失敗ログを調査。原因が遅延なら起動猶予設定、アプリの異常ならアプリ側の修正を検討 |
Readiness probe failedのみ | Readyではない原因を確認。readiness失敗だけでは再起動しないため、別の終了理由・liveness/startupも調査 |
変更前の条件：Deploymentの管理元、対象context・Namespace、変更前revision、停止影響・レプリカ数、依存サービスを確保し、変更承認後に修正します。原因が直近のPodテンプレート変更ならDeploymentの更新・切り戻しで旧revisionの利用可否とデータ互換性を確認してください。SecretやDB変更はrollout undoでは戻りません。
復旧判定：新PodがReady、同条件で再起動が続かず、アプリのログ・Health・業務通信が正常であることを確認。解決しない場合はNode状態・kubelet/コンテナランタイムの管理者調査へ、発生時刻とEvents・変更差分を引き継ぎます。Kubernetes公式 — 各probeの役割。
6. その場しのぎの再起動を避ける
kubectl delete podやkubectl rollout restartを繰り返さないでください。再起動してもアプリ設定やprobeの問題が残れば再発します。変更が必要ならDeploymentの安全な更新と切り戻しで変更管理・確認手順を参照します。
7. 復旧後の確認
再起動回数、Ready、アプリのヘルスチェックと通信を確認します。Pod名が変わった場合は対象を新しいPodに切り替えます。