Пробы liveness и readiness

Две пробы, два разных действия

Проба - это регулярный запрос к контейнеру: запрос по сети, команда внутри или проверка открытого порта. Отличаются пробы не тем, ЧТО спрашивают, а тем, что делает кластер с ответом.

Проба готовности управляет трафиком. Не прошла - под убирается из списка адресов сервиса, и запросы к нему не идут; сам контейнер при этом не трогают. Мой замер это подтверждает буквально: статус Running, ноль перезапусков и пустой список адресов за сервисом. Прошла обратно - под возвращается в раздачу сам.

// Проба живости управляет перезапуском. Не прошла заданное число раз подряд - контейнер убивают и запускают заново. В моём замере под с падающей живостью набрал два перезапуска и ушёл в состояние ожидания между попытками. Это лечение от зависаний, из которых приложение само не выходит: вечная блокировка, утечка соединений, замерший цикл.

проба готовности

решает, пускать ли на под трафик; контейнер не трогает

проба живости

решает, перезапускать ли контейнер

Проба запуска и медленный старт

Классическая авария: приложение поднимается 40 секунд (греет кэш, читает справочники), а проба живости начинает стучать через 10 и после трёх неудач убивает контейнер. Приложение не успевает стартовать никогда, а в логах видно бесконечный цикл перезапусков.

Лечится это отдельной пробой ЗАПУСКА: пока она не прошла, остальные пробы не работают вовсе. Ей дают щедрый предел - например, тридцать попыток по 10 секунд, то есть пять минут на старт, - а живости оставляют жёсткие короткие настройки. Так медленный старт и зависание в работе перестают конфликтовать.

// Старый способ - задержка первой проверки. Он хуже: задержку приходится ставить по худшему случаю, и всё это время зависший контейнер не будет замечен. Проба запуска эту дилемму снимает: она проверяет по-настоящему, а не ждёт по часам.

проба запуска

работает только на старте; пока не прошла, остальные пробы молчат

порог неудач

сколько неудачных проверок подряд считать поломкой

Что именно проверять

Проба живости должна проверять только сам процесс: отвечает ли он вообще. Простой адрес, который возвращает успех без обращения к чему-либо снаружи. Как только в живость попадает проверка базы, происходит следующее: база моргнула на минуту - и кластер ПЕРЕЗАПУСТИЛ все поды сервиса разом. Приложение было здорово, а теперь ещё и холодное.

Проба готовности, наоборот, может смотреть на зависимости: если без базы сервис не способен обслуживать запросы, честно вывести его из раздачи - правильное поведение. Но и тут есть край: если все реплики одновременно уйдут из раздачи, сервис исчезнет целиком. Иногда полезнее отдавать частичный ответ, чем полностью выпасть.

// Практические настройки, которые определяют скорость реакции: период между проверками, число неудач подряд до срабатывания и предел ожидания ответа. Ошибка в пределе ожидания даёт тихую беду: если проба ждёт ответа дольше, чем период между проверками, проверки наслаиваются, и под получает лишнюю нагрузку от собственного мониторинга.

живость без зависимостей

проверяет только сам процесс; падение базы не должно перезапускать поды

период и предел ожидания

как часто спрашиваем и сколько ждём ответа; вместе задают скорость реакции

Как отвечать: «Чем readiness отличается от liveness и что бывает, если их перепутать?»

Разные действия по итогу проверки. Готовность решает, пускать ли на под трафик: не прошла - адрес убирают из сервиса, а контейнер не трогают. Живость решает, перезапускать ли контейнер. Я проверял оба случая на стенде: под с падающей готовностью остался в состоянии Running с нулём перезапусков, но список адресов за сервисом стал пустым; под с падающей живостью ушёл в цикл перезапусков. Путают их двумя способами. Первый: в живость кладут проверку базы - и когда база моргает, кластер перезапускает все поды сервиса разом, хотя приложение здорово. Второй: живость ставят слишком агрессивно для медленно стартующего приложения, и оно не успевает подняться никогда; лечится отдельной пробой запуска, которая даёт щедрое время на старт и отключает остальные пробы, пока не пройдёт.

Ответ различает механизмы по действию, подтверждает измерением и называет обе типовые ошибки. Про пробу запуска вспоминают только те, кто ловил бесконечный цикл перезапусков.

На чём валятся

• −Кладут проверку базы в пробу живости: падение базы перезапускает все поды разом.
• −Ставят живость медленно стартующему приложению без пробы запуска.
• −Считают, что неготовый под перезапустится сам. Он останется работать, просто без трафика.
• −Задают предел ожидания больше периода проверок и получают наслоение проверок.
• −Обещают обновление без простоя, не настроив пробу готовности.