Настраиваем тесты Liveness и Readiness | OTUS
⚡ Подписка на курсы OTUS!
Интенсивная прокачка навыков для IT-специалистов!
Подробнее

Курсы

Программирование
Team Lead Архитектура и шаблоны проектирования Разработчик IoT C# Developer. Professional PostgreSQL Подготовка к сертификации Oracle Java Programmer (OCAJP) C# ASP.NET Core разработчик
-5%
Kotlin Backend Developer
-8%
iOS Developer. Professional
-8%
Symfony Framework Unity Game Developer. Basic JavaScript Developer. Professional Android Developer. Basic JavaScript Developer. Basic Java Developer. Professional Highload Architect Reverse-Engineering. Professional Java Developer. Basic PHP Developer. Professional Алгоритмы и структуры данных Framework Laravel Cloud Solution Architecture Vue.js разработчик Интенсив «Оптимизация в Java» Супер - интенсив по паттернам проектирования Супер - интенсив по Kubernetes Супер-интенсив "Tarantool" PHP Developer. Basic
Инфраструктура
Мониторинг и логирование: Zabbix, Prometheus, ELK Дизайн сетей ЦОД Разработчик IoT PostgreSQL Экспресс-курс "Версионирование и командная работа с помощью Git"
-30%
Экспресс-курс «Введение в непрерывную поставку на базе Docker» Базы данных Reverse-Engineering. Professional Administrator Linux. Professional Network engineer Cloud Solution Architecture Внедрение и работа в DevSecOps Супер-практикум по работе с протоколом BGP Супер - интенсив по паттернам проектирования Супер - интенсив по Kubernetes Супер-интенсив «СУБД в высоконагруженных системах» Супер-интенсив "Tarantool" Network engineer. Basic
Корпоративные курсы
Безопасность веб-приложений IT-Recruiter Дизайн сетей ЦОД Компьютерное зрение Разработчик IoT Вебинар CERTIPORT Machine Learning. Professional
-6%
NoSQL Пентест. Практика тестирования на проникновение Java QA Engineer. Базовый курс Руководитель поддержки пользователей в IT
-8%
SRE практики и инструменты Cloud Solution Architecture Внедрение и работа в DevSecOps Супер-практикум по работе с протоколом BGP Infrastructure as a code Супер-практикум по использованию и настройке GIT Промышленный ML на больших данных Экспресс-курс «CI/CD или Непрерывная поставка с Docker и Kubernetes» BPMN: Моделирование бизнес-процессов Основы Windows Server
Специализации Курсы в разработке Подготовительные курсы Подписка
+7 499 938-92-02

Настраиваем тесты Liveness и Readiness

Эта тема нередко обсуждается в Kubernetes-сообществе. Почему же так важно хорошо разбираться в тестах готовности (Readiness) и жизнеспособности (Liveness)? Потому что они как минимум обеспечивают устойчивую работу ПО, минимизируя время простоя. К тому же, если тесты настроены неправильно, они могут существенно повлиять на производительность вашего приложения.

Итак, Liveness показывает нам, работает ли контейнер. Когда Liveness выходит из строя, kubelet убивает контейнер, и происходит перезапуск. Если же контейнер не оснащен Liveness-пробой, то дефолтным состоянием, как утверждается в документации, будет успех.

Пробы Liveness не должны потреблять много ресурсов, так как они запускаются довольно часто. Также они должны информировать Kubernetes, что программное приложение запущено. Например, когда установлен параметр для запуска каждую секунду, это добавляет 1 запрос в секунду, поэтому надо принимать во внимание, что для обработки данного трафика потребуются дополнительные ресурсы.

Можно настроить тесты Liveness таким образом, чтобы они проверяли основные компоненты приложения даже в том случае, если данные доступны не полностью (к примеру, данные из кэша либо из удаленной БД). Также можно настроить конечную точку «работоспособности», возвращающую код ответа 200. Это будет показывать, что процесс запущен и может обрабатывать запросы (но не трафик).

Благодаря Readiness мы понимаем, готов ли контейнер к тому, чтобы обслуживать запросы. Когда Readiness выходит из строя, то контроллер конечных точек выполняет удаление IP-адреса пода из конечных точек абсолютно всех служб, которые соответствуют поду (об этом, кстати, тоже сказано в документации).

При этом Readiness-пробы потребляют больше ресурсов, ведь они должны попадать в backend, причем так, чтобы показать готовность программного приложения к приему запросов.

В Kubernetes-сообществе нередко спорят, надо ли обращаться непосредственно к БД. Если учесть накладные расходы (проверки ведь выполняются часто, однако их можно регулировать), можно прийти к следующему решению: для ряда программных приложений готовность обслуживать трафик засчитывается лишь после проверки, что из БД возвращаются записи. При этом хорошо продуманные пробы готовности обеспечат повышенный уровень доступности и устранение простоев в процессе развертывания.

Таким образом, если решите делать запрос к БД для проверки готовности приложения, сначала убедитесь, что этот запрос обходится вам как можно «дешевле».

Для примера рассмотрим следующий запрос:

Screenshot_1-1801-e1a5bc.png

А теперь выполним настройку:

Screenshot_2-1801-54263e.png

Также у нас есть возможность по добавлению дополнительных конфигурационных параметров: • initialDelaySeconds — количество секунд, которое проходит между запуском контейнера и запуском проб; • periodSeconds — интервал ожидания между запусками проб; • timeoutSeconds — число секунд, по прошествии которых под будет считаться аварийным. Скажем так, обычный time out; • failureThreshold — число тестовых отказов тестов, по достижению которого в под отправится сигнал перезапуска; • successThreshold — число успешных проб, по достижению которого под перейдет в состояние готовности (например, после сбоя, когда под снова запускается/восстанавливается).

По материалам статьи «5 Things We Overlooked When Deploying Our First App on Kubernetes».

Не пропустите новые полезные статьи!

Спасибо за подписку!

Мы отправили вам письмо для подтверждения вашего email.
С уважением, OTUS!

Автор
0 комментариев
Для комментирования необходимо авторизоваться