テクノロジー · 実用ガイド
KubernetesがCrashLoopBackOff？Pod再起動前に前回終了の証拠を保存
CrashLoopBackOffはbackoff状態であり原因ではありません。削除や再起動の前に、対象container、Last State、exit code、event、previous logsを保存します。
PodのCrashLoopBackOffはcontainerが繰り返し終了し、Kubernetesが次の再起動を遅延していることを示すだけです。正常終了、OOM、probe失敗、app crashのどれかはまだ不明です。前回instanceを保存してから、終了証拠で次のownerを決めます。
証拠のwindowを固定する
namespace、Pod、正確なcontainer、所有controllerを特定し、restart countと時刻を保存します。Podのdescribeからcontainer status、Last State、reason、exit code、開始・終了時刻、最近のeventを記録し、container指定のprevious logsも保存します。削除やrollout restartより前に行います。
previous logsが空の場合
正しいcontainerを指定したか確認します。sidecarとinit containerは別記録です。app logがなくてもtermination reason、exit code、eventを読みます。termination-message設定を確認し、許可される場合は唯一の失敗標本を変更せずdebug copyを作ります。provider側保持だけに依存しません。
終了signalで分岐する
exit 0はprocessが正常完了したが、常駐を期待するworkloadやcommandに置かれた可能性を示します。OOMKilledはapp memoryとlimitを先に確認します。liveness/startup probe eventはtarget、timing、dependency readinessを確認します。app traceを伴う非ゼロ終了はcodeまたはdependency担当です。
原因familyを混ぜない
image pull、scheduling、admission errorは別状態です。現在のlogが読めても前回終了は消えません。probe症状だけでprobe設定が誤りとも断定できません。各artifactが証明する事実を書き、仮説をexit、event、logの観測から分けます。
一つのownerだけ変更し全windowを見る
command/controller形状、memory/limit、probe設定、app/dependencyのうち、証拠が示す一つだけを変更してworkload revisionを記録します。予想startupとprobe window全体でrestart count、Last State、eventを監視し、短い静穏を復旧と誤認しません。
再現可能な証拠で閉じる
想定controllerが正しいcontainerを実行し、restart countが増えず、probeが健康で元workflowが成功した時だけ完了です。変更前bundle、一つの変更、変更後window、rollbackを添付します。別ownerならbundleを渡し、盲目的に再起動しません。
