Pod в CrashLoopBackOff — как отличить падение приложения от проваленной liveness-пробы?
Pod в CrashLoopBackOff и перезапускается. Объясните, что статус говорит и чего НЕ говорит, затем по артефакту решите, это падение приложения или проваленная liveness-проба — и как отличить их в общем случае.
$ kubectl get pod worker-84c
NAME READY STATUS RESTARTS AGE
worker-84c 0/1 CrashLoopBackOff 5 4m
$ kubectl describe pod worker-84c
Last State: Terminated
Reason: Error
Exit Code: 1
Restart Count: 5
Events:
Warning BackOff kubelet Back-off restarting failed containerДиагностируйте и исправьте.
CrashLoopBackOff значит, что контейнер умирает, а kubelet ждёт — но не почему. Смотрите logs --previous и lastState.terminated: Reason Error, Exit 1 — падение кода. Убийство liveness даёт Liveness probe failed; выход 137 — SIGKILL.
- ✗Считать
CrashLoopBackOffкорневой причиной, а не симптомом - ✗Читать живые логи вместо
logs --previousдля мёртвого контейнера - ✗Считать любой рестарт багом кода, упуская убийство liveness-пробой
- →Какой код выхода ждёте при OOM-убийстве и чем он отличается от этого случая?
- →Как слишком агрессивный
initialDelaySecondsу liveness вызывает crash loop?
Решение
1. Статус — это симптом, а не причина
CrashLoopBackOff значит только: контейнер стартует, падает, kubelet ждёт (10s, 20s, 40s… до 5m) и пробует снова. Почему падает — нужно смотреть отдельно.
2. Ключевой различитель
$ kubectl logs worker-84c --previous # stdout мёртвого инстанса
...
panic: connect tcp 10.0.0.9:5432: connection refused
$ kubectl describe pod worker-84c | sed -n '/Last State/,/Exit Code/p'
Last State: Terminated Reason: Error Exit Code: 1видна в logs --previous. Здесь — приложение само упало (не смогло к БД).
рестартует по решению kubelet, а не из-за выхода приложения.
- Падение приложения:
lastState.terminatedс ненулевым кодом (1,2), причина - Убийство liveness-пробой: в Events будет
Liveness probe failed: ..., а контейнер - Exit Code 137 = 128 + 9 (SIGKILL) — OOM или убийство пробой; смотрите
Reason.
3. Фикс
Здесь — приложение: чините недоступную зависимость или добавьте ретраи/ожидание. Если бы это была проба, ослабили бы initialDelaySeconds/failureThreshold.
