Под в CrashLoopBackOff. С чего начнёшь дебажить?

Пример

кода

kubectl describe pod api-123
kubectl logs api-123 -c api
kubectl logs api-123 -c api --previous
kubectl get pod api-123 -o jsonpath='{.status.containerStatuses[*].lastState}'
kubectl top pod api-123

Суть

CrashLoopBackOff — не причина, а симптом: контейнер стартует, завершается с ошибкой, kubelet перезапускает его и увеличивает задержку между попытками. Начинать нужно с evidence: exit code, логи предыдущего запуска, events и probes. Особенно важно использовать previous logs, потому что текущий контейнер может уже перезапуститься и потерять вывод прошлой попытки.

Как работает

kubectl describe pod покажет restart count, last state, reason, exit code, OOMKilled, failed probes и mounted volumes. kubectl logs --previous даст stdout/stderr предыдущего контейнера. Если exit code 137 или reason OOMKilled, проверяем memory limit и usage. Если приложение завершается сразу, проверяем command/args, config, Secret, env vars, missing files и подключения. Если контейнер жив, но livenessProbe его убивает, нужно анализировать endpoint probe, delay, timeout и внешние зависимости.

Подводные камни

• Лечить CrashLoopBackOff увеличением replicas. Это только размножит падающий контейнер.
• Не смотреть --previous logs. Самая полезная ошибка часто была в предыдущем запуске.
• Игнорировать livenessProbe. Неправильная liveness может сама создавать crash loop.

Что отличает сильный ответ

Хороший кандидат разделяет классы причин: приложение завершилось, runtime не может стартовать, OOMKilled, probe убивает, config отсутствует, dependency недоступна. Дальше он подтверждает гипотезу конкретной командой, а не меняет YAML вслепую. В production дополнительно проверяют, не начался ли массовый crash после релиза, и при необходимости откатывают rollout до глубокого разбора.

• Не проверять exit code
• Не читать previous logs
• Путать CrashLoopBackOff с ImagePullBackOff

• Знает --previous
• Умеет читать describe status
• Различает OOM/probe/app crash