Pod & Container Failures
Pod とコンテナの異常終了を検知し、原因の特定に必要なログ、YAML、タイムラインを残します。
Pod が 5 分ごとに再起動しても、kubectl get には CrashLoopBackOff しか表示されません
kubernetes.io, Pod Lifecycle, Assign Memory Resources to Containers and Pods; Komodor, 2025 Enterprise Kubernetes Report.
kubectl get pods には CrashLoopBackOff が表示されるだけで、原因は表示されません。OOMKilled などの原因は kubectl describe に、失敗したコンテナのログは kubectl logs --previous にあります。
kubelet は再起動の間に 10 秒、20 秒、40 秒と待ち時間を延ばし、最大 5 分まで待ちます。誰かが確認する頃には、失敗したコンテナのログが消えていることがよくあります。
影響の大きい Kubernetes 障害の解決には中央値で 51 分かかり、39% は 1 時間以上かかります（Komodor, 2025 Enterprise Kubernetes Report）。
Back-off: 10 秒から倍々、最大 5 分（kubernetes.io、Pod Lifecycle）。再起動回数は例示です。
Wave の仕組み
コンテナメモリ limit 超過、またはクラッシュ- 再起動
kubelet10 秒、20 秒、40 秒、最大 5 分の間隔で再起動 - ステータス
kubectl get podsCrashLoopBackOff のみ表示、原因は出ない - 手作業
エンジニアkubectl describe と logs --previous を手で実行
Wave Agent全ノードで cAdvisor とともに状態変化ごとに送信- gRPCWave Core11 種類の障害タイプを照合、ポーリングなし
- 障害時証拠直前のログ、pod.yaml、node.yaml を障害時点で保存
- インシデントWave Console48 時間ヒートマップとインシデントタイムライン
11 種類の異常な遷移を検知する
OOMKilled、CrashLoopBackOff、ContainerCrash、退避、プリエンプションなどを、Wave Agent がすでに送っているデータから検知します。ワークロードごとの設定は不要です。
証拠を残す
失敗した瞬間に、直前のコンテナのログ、pod.yaml、node.yaml を保存します。
いつ始まったかを示す
ワークロードごとの 48 時間ヒートマップと、何が失敗し何を確認すべきかを分かりやすく説明するインシデントタイムラインを提供します。