При перегрузке экземпляр начинает медленно отвечать, после чего его liveness-проверка становится неуспешной. Как перезапуск экземпляра может ухудшить ситуацию?
Перезапуск перегруженного экземпляра может ухудшить ситуацию, если liveness-проверка принимает временную неспособность быстро отвечать за необратимую неисправность. Экземпляр удаляется из обработки, его запросы перераспределяются на оставшиеся экземпляры, и нагрузка на них растёт; это может вызвать цепную перезагрузку.
Разделение проверок состояния появилось из-за разных задач управления жизненным циклом сервиса. Системе нужно отличать процесс, который действительно завис или сломан, от процесса, который жив, но временно перегружен и способен восстановиться после снижения нагрузки.
Liveness-проверка предназначена для обнаружения состояния, из которого экземпляр не может восстановиться без перезапуска. Readiness-проверка отвечает на другой вопрос: можно ли сейчас направлять на экземпляр новый трафик. Смешение этих целей приводит к тому, что механизм самовосстановления становится источником нестабильности.
Пусть экземпляр обслуживает запросы медленно из-за исчерпания CPU, блокировки внутри приложения или временного дефицита внешнего ресурса. Если liveness-проверка использует тот же перегруженный путь или требует ответа быстрее обычного, она начинает завершаться неуспешно.
Оркестратор может перезапустить экземпляр, хотя его состояние было обратимым без перезапуска. Во время остановки теряются незавершённые запросы либо они получают ошибки, а их повторная отправка дополнительно увеличивает нагрузку. Если аналогичные экземпляры испытывают тот же дефицит ресурса, возникает каскад отказов.
Liveness-проверка должна быть узкой и проверять только признаки состояния, при котором процесс действительно не способен продолжать работу: например, обнаруженное приложением необратимое зависание внутреннего исполнительного цикла. Она не должна использовать обычный бизнес-запрос или требовать успешной работы каждой зависимости.
Временную перегрузку обычно выражают через readiness: экземпляр временно перестаёт принимать новый трафик, но не перезапускается. Уже принятые запросы можно завершить, а после снижения нагрузки экземпляр снова сделать готовым. Это уменьшает давление на него без потери состояния и затрат на повторную инициализацию.
Проверки должны иметь разумные тайм-ауты, периоды наблюдения и порог последовательных неудач. Слишком агрессивные параметры создают ложные срабатывания, а слишком мягкие задерживают удаление действительно зависшего экземпляра. Важно также учитывать, что снятие экземпляра с маршрутизации не освобождает автоматически занятые CPU, память, соединения или очередь: для защиты ресурса могут понадобиться ограничение конкуренции и управление перегрузкой.
Readiness не заменяет liveness полностью. Если экземпляр гарантированно завис, бесконечно оставлять его неготовым нельзя: система должна иметь отдельный механизм обнаружения и перезапуска. Полезно также отделять проверку доступности самого процесса от доступности необязательных зависимостей, иначе отказ второстепенной зависимости может вызвать массовое удаление рабочих экземпляров.
В API-кластере проверка состояния выполняла короткий HTTP-запрос через тот же пул потоков, что и пользовательские запросы. При насыщении пула проверка не получала поток вовремя, экземпляры помечались нездоровыми и перезапускались. После этого оставшиеся экземпляры принимали больше трафика, поэтому перезапуски распространялись по кластеру.
Рассматривались три варианта. Увеличение тайм-аута проверки уменьшало ложные срабатывания, но замедляло обнаружение настоящего зависания. Полное отключение liveness устраняло каскад перезапусков, но оставляло зависшие экземпляры в системе. Разделение проверок, выделение лёгкого внутреннего сигнала жизнеспособности и перевод перегруженного экземпляра в состояние неготовности сохранили возможность восстановления без необоснованного перезапуска.
Выбранное решение было предпочтительным, потому что различало перегрузку и необратимое зависание. В результате кратковременная перегрузка приводила к уменьшению входящего трафика на экземпляр, а не к его уничтожению; при этом отдельный сигнал зависания по-прежнему позволял перезапускать экземпляры, которые действительно перестали прогрессировать.
Ответ: Нет. Успешная liveness-проверка обычно доказывает лишь то, что процесс способен выполнить узкую проверку и вернуть результат. Она не подтверждает корректность бизнес-логики, доступность всех зависимостей, достаточную пропускную способность или приемлемую задержку для пользователей. Для маршрутизации трафика нужна readiness-проверка, а пользовательское качество дополнительно контролируют метрики и синтетические проверки.
Ответ: Все экземпляры могут одновременно стать неготовыми, даже если само приложение исправно. Это предотвратит отправку новых запросов в заведомо неработающий путь, но также может скрыть возможность обслуживать операции, не требующие базы, и создать полный отказ сервиса. Поэтому состав readiness-проверки выбирают по критичному пути конкретного трафика; иногда применяют разные типы готовности для разных функций или явно проектируют деградированный режим.
Ответ: Такой порог снижает чувствительность к единичным задержкам, но не устраняет общую причину: проверка всё ещё может зависеть от перегруженного ресурса, а одновременно перегруженные экземпляры всё равно пройдут порог. Защита требует разделить семантику liveness и readiness, ограничить влияние проверки на рабочий трафик и учитывать темп перезапусков. Полезен также контролируемый интервал между перезапусками, чтобы механизм восстановления не создавал дополнительный всплеск нагрузки.