KubePodCrashLooping: что делать при алерте

Правило алерта

alert: KubePodCrashLooping
expr: kube_pod_container_status_waiting_reason{reason="CrashLoopBackOff"} == 1
for: 10m
severity: warning

Сообщение алерта: Pod {{ $labels.namespace }}/{{ $labels.pod }} в CrashLoopBackOff

Что значит

Контейнер 10 минут в состоянии CrashLoopBackOff: процесс стартует, падает, а Kubernetes перезапускает его с растущей паузой.

Частые причины

Ошибка приложения при старте, неверный конфиг/секрет, недоступная БД, нехватка памяти (OOMKilled), неверная команда, не пройденный liveness probe.

Диагностика

kubectl -n <ns> get pod <pod>
kubectl -n <ns> describe pod <pod>              # раздел Events и Last State
kubectl -n <ns> logs <pod> -c <контейнер> --previous
kubectl -n <ns> get events --sort-by=.lastTimestamp | tail -n 20

Ключ --previous показывает лог предыдущего (упавшего) запуска.

Как исправить

Исправить причину из лога: конфигурацию, секрет, зависимость. Если ломается liveness probe — увеличить initialDelaySeconds / failureThreshold. После исправления: kubectl -n <ns> rollout restart deployment/<имя>.

Когда можно заглушить

Для известного нерабочего Pod в тестовом namespace. Для production — нет.