Как последовательно диагностировать под, застрявший в CrashLoopBackOff?

Короткий ответ

Диагностику ведут по шагам: смотрят kubectl describe pod на код завершения и причину (Last State, Reason), затем логи предыдущего запуска (kubectl logs --previous), и только после этого делают вывод — упало ли приложение само (ошибка кода/конфигурации) или его убил Kubernetes (например, по failed liveness probe или OOM).

Как это работает подробнее

CrashLoopBackOff — это состояние, в котором kubelet увеличивает интервал между попытками перезапуска контейнера экспоненциально после повторных сбоев. Причина сбоя всегда одна из: ненулевой exit code процесса приложения, провал liveness probe (Kubernetes сам убивает контейнер), либо OOMKilled (убийство ядром из-за превышения лимита памяти).

Пример кода

Команды и выводКопировать

kubectl describe pod payments-7f9c8
Last State:  Terminated
  Reason:    OOMKilled
  Exit Code: 137

Что использовать на практике

• Практика. exit code 1 обычно означает необработанное исключение или ошибку конфигурации на старте — приложение не смогло подключиться к зависимости (БД, очередь) или получило некорректные переменные окружения; exit code 137 указывает на SIGKILL, что характерно для OOMKilled или ручного убийства; провал liveness виден в Events как Liveness probe failed. Для медленно стартующих приложений нужно проверить, не слишком ли агрессивны пороги liveness/startup probe относительно реального времени старта.

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

• Риски. сразу увеличивать backoffLimit/лимиты ресурсов "на всякий случай", не выяснив первопричину; путать OOMKilled (контроллер памяти ядра) с провалом liveness (решение Kubernetes) — это разные проблемы с разными решениями; не проверять зависимые сервисы (БД, DNS), к которым приложение не может подключиться при старте.