Сообщить об ошибкеКороткий ответ
Сначала быстро проверить логи и события пода (`kubectl logs --previous`, `kubectl describe pod`), чтобы понять причину (ошибка конфигурации, недоступная зависимость, паника приложения при старте); если причина не устраняется мгновенно и очевидно (например, опечатка в переменной окружения), безопаснее сразу выполнить `kubectl rollout undo`, а разбираться с первопричиной уже на спокойном окружении (staging/локально).
Как это работает подробнее
CrashLoopBackOff означает, что контейнер завершается с ошибкой и Kubernetes с нарастающей задержкой пытается его перезапустить. `kubectl logs --previous` показывает вывод именно упавшего контейнера (текущий лог может быть пустым, если контейнер уже перезапустился), а `kubectl describe pod` — события вроде `OOMKilled`, `Error`, `BackOff`.
Пример кода
$ kubectl get pods
myapp-7d9f8c9-abcde 0/1 CrashLoopBackOff 5 4m
$ kubectl logs myapp-7d9f8c9-abcde --previous
Error: cannot connect to database: FATAL: password authentication failed
$ kubectl rollout undo deployment/myapp
deployment.apps/myapp rolled backЧто использовать на практике
- На практике. при наличии rolling update в проде часть старых подов обычно ещё жива, поэтому сервис может продолжать частично работать — но решение об откате нужно принимать быстро, не дожидаясь, пока новая версия заменит все поды. Приоритет — восстановить стабильность сервиса (откат), а детальное расследование первопричины вести уже после этого на копии проблемного пода/логов.
- Пример. Ожидаемое поведение: после отката поды возвращаются к предыдущему рабочему образу и переходят в статус `Running` с `READY 1/1`; параллельно выясняется, что в новой версии изменилась переменная `DB_PASSWORD_SECRET_KEY`, не совпадающая с реальным ключом в Secret.
Подводные камни
- Частые ошибки. пытаются «на живую» патчить конфигурацию в проде методом проб и ошибок вместо отката — это продлевает инцидент; смотрят только `kubectl logs` без `--previous` и видят пустой вывод, ошибочно решая, что логов нет вообще.