[Перевод] Лучшие практики Kubernetes. Проверка жизнеспособности Kubernetes с помощью тестов Readiness и Liveness
Лучшие практики Kubernetes. Создание небольших контейнеров
Лучшие практики Kubernetes. Организация Kubernetes с пространством имен
Распределенными системами бывает трудно управлять по причине того, что в них имеется множество подвижных изменяемых элементов, и все они должны нормально работать для обеспечения функциональности системы. Если один из элементов выйдет из строя, то система должна его обнаружить, обойти и исправить, причем все это нужно делать автоматически. В этой серии «Kubernetes Best Practices» мы узнаем, как настраивать тесты Readiness и Liveness для проверки жизнеспособности кластера Kubernetes.
Проверка здоровья Health Check — это простой способ позволить системе знать, работает ли экземпляр вашего приложения или нет. Если экземпляр вашего приложения не работает, то другие службы не должны обращаться к нему или отправлять ему запросы. Вместо этого запрос должен быть отправлен другому экземпляру приложения, который уже запущен или запустится позже. Кроме того, система должна вернуть вашему приложению утраченную работоспособность.
По умолчанию Kubernetes начнет отправлять трафик в pod, когда все контейнеры внутри подов будут запущены, и перезагружать контейнеры, когда они аварийно завершат работу. Для начала такое поведение системы по умолчанию может быть достаточно хорошим, однако вы можете повысить надежность развертывания своего продукта, используя пользовательские проверки работоспособности.
К счастью, Kubernetes позволяет проделать это довольно просто, так что игнорированию подобных проверок нет никаких оправданий. Kubernetes предоставляет два типа тестов Health Check, причем важно понимать различия в применении каждого из них.
Тест готовности Readiness предназначен для того, чтобы сообщать Kubernetes о готовности вашего приложения обслуживать трафик. Прежде чем разрешить сервису отправить трафик в pod, Kubernetes должен убедиться в успешности проверки готовности. Если тест Readiness даст сбой, Kubernetes прекратит отправлять трафик в pod, пока тестирование не пройдет успешно.
Тест жизнеспособности Liveness сообщает Kubernetes о том, живо или мертво ваше приложение. В первом случае Kubernetes оставит его в покое, во втором удалит мертвый pod и заменит его новым.
Давайте представим себе сценарий, в котором вашему приложению на «разогрев» и запуск требуется 1 минута. Ваш сервис не начнет работать, пока приложение полностью не загрузится и не запустится, хотя рабочий процесс уже начался. Причем у вас также возникнут проблемы, если вы захотите увеличить масштаб этого развертывания до нескольких копий, ведь эти копии не должны получать трафик, пока они не будут полностью готовы. Однако по умолчанию Kubernetes запустит отправку трафика сразу же после начала процессов внутри контейнера.
При использовании теста готовности Readiness, Kubernetes будет ждать, пока приложение не будет полностью запущено и только после этого позволит сервису отправлять трафик на новую копию.
Давайте представим себе другой сценарий, при котором приложение зависает на длительное время, переставая обслуживать запросы. Поскольку процесс продолжает выполняться, по умолчанию Kubernetes посчитает, что все в порядке, и продолжит отправлять запросы на нерабочий pod. Но при использовании Liveness, Kubernetes обнаружит, что приложение больше не обслуживает запросы, и по умолчанию перезапустит нерабочий pod.
Рассмотрим, с помощью чего тестируется готовность и жизнеспособность. Существует три способа тестирования — HTTP, Сommand и TCP. Для проверки вы можете использовать любой из них. Наиболее распространенный способ пользовательского теста — это HTTP probe.
Даже если ваше приложение не является HTTP-сервером, вы все равно можете создать легковесный HTTP-сервер внутри вашего приложения для взаимодействия с тестом Liveness. После этого Kubernetes начнет пинговать pod, и если ответ HTTP будет находиться в диапазоне 200 или 300 мс, это будет означать, что pod «здоров». В противном случае модуль будет помечен как «нездоровый».
Для тестов с помощью Command Kubernetes выполняет команду внутри вашего контейнера. Если команда возвращается с нулевым exit code, то контейнер будет помечен как здоровый, в противном случае, при получении числа exit status от 1 до 255, контейнер будет отмечен как «больной». Этот способ тестирования полезен, если вы не можете или не хотите запускать HTTP-сервер, но способны запустить команду, которая проверит «здоровье» вашего приложения.
Последний механизм проверки — это тест TCP. Kubernetes попытается установить TCP соединение на указанном порту. Если это удается сделать, контейнер считается здоровым, если нет — нежизнеспособным. Этот способ может пригодиться, если вы используете сценарий, при котором тестирование с помощью HTTP-запроса или выполнения команды работает не очень хорошо. Например, основными сервисами для проверки с помощью TCP будут gRPC или FTP.
Тесты можно настроить несколькими способами с различными параметрами. Вы можете указать, как часто они должны выполняться, каковы пороговые значения успеха и неудачи, как долго ждать ответов. Более подробная информацию изложена в документации к тестам Readiness и Liveness. Однако есть один очень важный момент в настройке теста Liveness — начальная установка задержки тестирования initialDelaySeconds. Как я упоминал, неудачное выполнение этого теста приведет к перезапуску модуля. Поэтому вам нужно убедиться, что тестирование не начнется до тех пор, пока приложение не будет готово к работе, иначе оно начнет циклически перезапускаться. Я рекомендую использовать время стартапа P99 или среднее время запуска приложения из буфера. Не забывайте корректировать это значение по мере того, как время запуска вашего приложения становится все быстрее или замедляется.
Большинство специалистов подтвердит, что Health Check являются обязательной проверкой для любой распределенной системы, и Kubernetes не является исключением. Использование проверки «здоровья» сервисов обеспечивает надежную и безотказную работу Kubernetes и не составляет для пользователей никакого труда.
Продолжение будет совсем скоро…
Немного рекламы :)
Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас, оформив заказ или порекомендовав знакомым, облачные VPS для разработчиков от $4.99, уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5–2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps от $19 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).
Dell R730xd в 2 раза дешевле в дата-центре Equinix Tier IV в Амстердаме? Только у нас 2 х Intel TetraDeca-Core Xeon 2x E5–2697v3 2.6GHz 14C 64GB DDR4 4×960GB SSD 1Gbps 100 ТВ от $199 в Нидерландах! Dell R420 — 2x E5–2430 2.2Ghz 6C 128GB DDR3 2×960GB SSD 1Gbps 100TB — от $99! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5–2650 v4 стоимостью 9000 евро за копейки?
