Если при отказе базы данных приложение начинает непрерывно перезапускаться, проверьте, не включён ли запрос к БД в liveness. Для приложения, способного восстановить соединение самостоятельно, недоступность обязательной базы должна означать «не готово принимать нагрузку», а не «процесс нужно убить».
Разделите две проверки: liveness оценивает работоспособность самого приложения, readiness — возможность обслужить нужные запросы с обязательными зависимостями. Затем подтвердите на изолированном стенде: при потере БД готовность пропадает, счётчик рестартов не растёт, после восстановления связи трафик возвращается.
Какие действия запускают проверки
В Kubernetes результат пробы влияет на управление контейнером и трафиком. Названия URL ниже условные: сами по себе они ничего не настраивают.
| Проверка | На какой вопрос отвечает | Реакция на устойчивый отказ | |---|---|---| | Liveness, например /live | Может ли приложение продолжать работу? | Перезапуск контейнера с учётом политики рестартов | | Readiness, например /ready | Можно ли сейчас направлять сюда запросы? | Pod исключается из готовых получателей трафика Service | | Startup | Завершилась ли начальная загрузка? | До успеха не запускаются readiness и liveness; исчерпание допустимых неудач ведёт к остановке контейнера |
Это поведение описано в документации Kubernetes о пробах. За пределами Kubernetes отдельно проверьте, что делает ваш балансировщик или supervisor: одинаковое слово health не гарантирует одинаковой реакции.
Как доказать, что рестарты вызваны пробой
- Сопоставьте время. Запишите начало ошибки БД, переход Pod в неготовность и первый рестарт. Совпадение полезно для поиска, но ещё не доказывает причину.
- Посмотрите причину завершения. В событиях Pod ищите неудачные liveness-пробы и последующую остановку контейнера. Отдельно проверьте OOMKilled, аварийный выход приложения и замену Pod при релизе.
- Проверьте фактическую конфигурацию. Сверьте путь, порт, тип пробы и пороги в работающем Pod. Один и тот же /health в readiness и liveness особенно подозрителен, если внутри выполняется SQL-запрос.
- Проследите обработчик. Даже отдельный /live может неявно требовать БД: например, через общий middleware сессий или загрузку настроек. Важно поведение всей цепочки, а не имя маршрута.
Если процесс сам завершается при потере соединения, изменение liveness не устранит рестарты. Сначала нужно разобраться с обработкой ошибки подключения в приложении.
Что оставить в readiness, а что убрать из liveness
Liveness должна выявлять состояние, из которого приложение не восстановится без перезапуска. Простой ответ веб-сервера перед приложением этого не подтверждает: nginx может быть жив, пока обработчики зависли.
Readiness включает БД, если без неё обслуживаемые запросы действительно не работают. У проверки должны быть ограничены время подключения и выполнения; её собственные повторы не должны превращать краткую ошибку в очередь зависших запросов.
Короткий запрос вроде SELECT 1 подтверждает только выполнение этого запроса через выбранное соединение. Он не доказывает наличие нужной схемы, разрешение записи, свежесть реплики или успешное оформление заказа. Добавляйте лишь те условия, которые нужны для заявленного контракта готовности, без записи тестовых заказов и тяжёлого обхода таблиц.
Если база общая для всех экземпляров
Потеря общей БД может одновременно сделать неготовыми все Pod. Переключать трафик тогда некуда: нужны обработка недоступности на входе и понятный ответ пользователю, а не ожидание, что readiness починит базу.
Необязательную аналитику или рекомендательный API не стоит автоматически делать причиной полной неготовности. Если каталог работает из кеша, а запись заказа требует БД, заранее определите допустимый режим деградации; одна глобальная проба не умеет отдельно управлять каждым маршрутом.
Как проверить исправление без аварии в production
На стенде с тестовыми данными воспроизведите три состояния:
- База доступна: приложение готово, контрольный рабочий запрос проходит.
- Связь с обязательной БД потеряна: readiness сообщает отказ, liveness остаётся успешной у работоспособного процесса, рестарты из-за проб отсутствуют.
- Связь восстановлена: приложение пересоздаёт неисправные соединения, readiness возвращается к успеху, рабочий запрос снова выполняется без ручного рестарта.
Последняя проверка важнее зелёного /live. Если пул держит оборванные соединения или приложение перестало пытаться подключиться, процесс жив, но сервис не восстановился.
Тайм-ауты и число последовательных неудач подбирайте по измеренному времени ответа и допустимой задержке реакции. Простое увеличение порогов откладывает ошибочный рестарт, но сохраняет его причину. Для долгой начальной загрузки предусмотрена startup-проба; параметры и порядок работы описаны в руководстве Kubernetes.
Какой контроль нужен снаружи
Внутренняя readiness не проверяет публичные DNS, TLS и весь путь посетителя. Внешний HTTP-мониторинг в Web-Puls может дополнить её контролем публичного URL, но не управляет пробами Kubernetes и не доказывает выполнение записи в БД. Выбор безопасной точки разобран в статье о мониторинге API.
Если причина рестартов остаётся неясной, отправьте заявку на диагностику: укажите публичный URL, время сбоя с часовым поясом, тип пробы и обезличенную последовательность событий. Не прикладывайте пароли, строки подключения и значения токенов; формат и стоимость работ согласуют до начала диагностики.