CrashLoopBackOff: полевой гид по отладке

Алгоритм отладки падающего пода: логи, события, ливнес-пробы и 80%-причина, о которой все забывают.

---

CrashLoopBackOff — самое частое сообщение в аварийном канале. Это не «кластер сломался», это под просто умирает и kubelet честно говорит, что пробует снова. Разбираем алгоритм отладки по шагам.

Шаг 1: логи

kubectl logs <pod> -c <container>
kubectl logs <pod> -c <container> --previous

--previous — половина успеха: текущая попытка часто еще ничего не напечатала, а предыдущая смерть — уже да.

Шаг 2: типичные причины

Симптом	Вероятная причина
Ошибка в логах сразу после старта	Нет зависимости: БД/конфиг еще не готовы
connection refused	Service/Selector не совпадают, сервис на другом порту
Секунды работы, потом death	Liveness-проб слишком агрессивный
Смерть без логов	OOMKilled — проверить kubectl describe pod

Шаг 3: describe и события

kubectl describe pod <pod>

Ищем в Events: BackOff, Liveness probe failed, OOMKilled, FailedMount. Mount'ы — отдельная боль: секреты и ConfigMap должны существовать и совпадать по ключам.

Шаг 4: пробы

Liveness, который стартует раньше, чем приложение поднялось, убивает под в вечном цикле. Лечится startupProbe:

startupProbe:
  httpGet: { path: /healthz, port: 8080 }
  periodSeconds: 5
  failureThreshold: 30

Пока startup-проба не прошла, liveness молчит — приложение спокойно стартует.

Правило пальца

80% CrashLoop'ов — это конфигурация: переменные окружения, DNS-имена сервисов, тайминги старта. Начинайте с логов и событий, а не с пересборки образа.