Настраиваем тесты Liveness и Readiness
Эта тема нередко обсуждается в Kubernetes-сообществе. Почему же так важно хорошо разбираться в тестах готовности (Readiness) и жизнеспособности (Liveness)? Потому что они как минимум обеспечивают устойчивую работу ПО, минимизируя время простоя. К тому же, если тесты настроены неправильно, они могут существенно повлиять на производительность вашего приложения.
Итак, Liveness показывает нам, работает ли контейнер. Когда Liveness выходит из строя, kubelet убивает контейнер, и происходит перезапуск. Если же контейнер не оснащен Liveness-пробой, то дефолтным состоянием, как утверждается в документации, будет успех.
Пробы Liveness не должны потреблять много ресурсов, так как они запускаются довольно часто. Также они должны информировать Kubernetes, что программное приложение запущено. Например, когда установлен параметр для запуска каждую секунду, это добавляет 1 запрос в секунду, поэтому надо принимать во внимание, что для обработки данного трафика потребуются дополнительные ресурсы.
Можно настроить тесты Liveness таким образом, чтобы они проверяли основные компоненты приложения даже в том случае, если данные доступны не полностью (к примеру, данные из кэша либо из удаленной БД). Также можно настроить конечную точку «работоспособности», возвращающую код ответа 200. Это будет показывать, что процесс запущен и может обрабатывать запросы (но не трафик).
Благодаря Readiness мы понимаем, готов ли контейнер к тому, чтобы обслуживать запросы. Когда Readiness выходит из строя, то контроллер конечных точек выполняет удаление IP-адреса пода из конечных точек абсолютно всех служб, которые соответствуют поду (об этом, кстати, тоже сказано в документации).
При этом Readiness-пробы потребляют больше ресурсов, ведь они должны попадать в backend, причем так, чтобы показать готовность программного приложения к приему запросов.
В Kubernetes-сообществе нередко спорят, надо ли обращаться непосредственно к БД. Если учесть накладные расходы (проверки ведь выполняются часто, однако их можно регулировать), можно прийти к следующему решению: для ряда программных приложений готовность обслуживать трафик засчитывается лишь после проверки, что из БД возвращаются записи. При этом хорошо продуманные пробы готовности обеспечат повышенный уровень доступности и устранение простоев в процессе развертывания.
Таким образом, если решите делать запрос к БД для проверки готовности приложения, сначала убедитесь, что этот запрос обходится вам как можно «дешевле».
Для примера рассмотрим следующий запрос:
А теперь выполним настройку:
Также у нас есть возможность по добавлению дополнительных конфигурационных параметров: • initialDelaySeconds — количество секунд, которое проходит между запуском контейнера и запуском проб; • periodSeconds — интервал ожидания между запусками проб; • timeoutSeconds — число секунд, по прошествии которых под будет считаться аварийным. Скажем так, обычный time out; • failureThreshold — число тестовых отказов тестов, по достижению которого в под отправится сигнал перезапуска; • successThreshold — число успешных проб, по достижению которого под перейдет в состояние готовности (например, после сбоя, когда под снова запускается/восстанавливается).
По материалам статьи «5 Things We Overlooked When Deploying Our First App on Kubernetes».
