Лучшие практики Kubernetes. Создание небольших контейнеров Лучшие практики Kubernetes. Организация Kubernetes с пространством имен 
Распределенными системами может быть сложно управлять, поскольку в них много движущихся и изменяющихся элементов, которые должны работать правильно, чтобы система функционировала.
Если один из элементов выходит из строя, система должна его обнаружить, обойти и исправить, и все это должно происходить автоматически.
В этой серии лучших практик Kubernetes мы узнаем, как настроить тесты готовности и работоспособности для проверки работоспособности кластера Kubernetes. Проверка работоспособности — это простой способ сообщить системе, запущен ли ваш экземпляр приложения или нет. Если экземпляр вашего приложения не работает, другие службы не должны получать к нему доступ или отправлять к нему запросы.
Вместо этого запрос необходимо отправить другому экземпляру приложения, которое уже запущено или будет запущено позже.
Кроме того, система должна восстановить утраченную функциональность вашего приложения.
По умолчанию Kubernetes начнет отправлять трафик в модуль, когда все контейнеры внутри модуля работают, и перезагружает контейнеры в случае их сбоя.
Это поведение системы по умолчанию может быть достаточно хорошим для начала, но вы можете повысить надежность развертывания вашего продукта, используя специальные проверки работоспособности.
К счастью, Kubernetes позволяет сделать это довольно легко, поэтому игнорированию этих проверок нет оправдания.
Kubernetes предоставляет два типа проверок работоспособности, и важно понимать различия в использовании каждого из них.
Тест готовности предназначен для того, чтобы сообщить Kubernetes, что ваше приложение готово обрабатывать трафик.
Прежде чем разрешить службе отправлять трафик в модуль, Kubernetes должен убедиться, что проверка готовности прошла успешно.
Если тест готовности не пройден, Kubernetes прекратит отправку трафика в модуль до тех пор, пока тест не пройдет. Тест Liveness сообщает Kubernetes, живо ваше приложение или мертво.
В первом случае Kubernetes оставит его в покое, во втором — удалит мертвый под и заменит его новым.
Давайте представим себе сценарий, в котором вашему приложению требуется 1 минута для прогрева и запуска.
Ваш сервис не начнет работать, пока приложение не будет полностью загружено и запущено, хотя рабочий процесс уже запущен.
У вас также возникнут проблемы, если вы захотите масштабировать это развертывание до нескольких копий, поскольку эти копии не должны получать трафик, пока они не будут полностью готовы.
Однако по умолчанию Kubernetes начнет отправлять трафик, как только начнутся процессы внутри контейнера.
При использовании теста готовности Kubernetes будет ждать, пока приложение заработает полностью, прежде чем разрешить службе отправлять трафик в новую копию.
Представим себе другой сценарий, при котором приложение надолго зависает, прекращая обслуживание запросов.
Поскольку процесс продолжает выполняться, Kubernetes по умолчанию считает, что все в порядке, и продолжает отправлять запросы неработающему поду.
Но при использовании Liveness Kubernetes обнаружит, что приложение больше не обслуживает запросы, и по умолчанию перезапустит неработающий модуль.
Давайте посмотрим, как проверяются готовность и жизнеспособность.
Существует три метода тестирования — HTTP, Command и TCP. Для проверки вы можете использовать любой из них.
Самый распространенный способ протестировать пользователя — это HTTP-зонд. Даже если ваше приложение не является HTTP-сервером, вы все равно можете создать внутри своего приложения облегченный HTTP-сервер для взаимодействия с тестом Liveness. После этого Kubernetes начнет пинговать модуль, и если ответ HTTP находится в диапазоне 200 или 300 мс, это будет указывать на то, что модуль работоспособен.
В противном случае модуль будет помечен как «неработоспособный».
Для командных тестов Kubernetes запускает команду внутри вашего контейнера.
Если команда возвращает нулевой код выхода, то контейнер будет помечен как исправный, в противном случае при получении номера статуса выхода от 1 до 255 контейнер будет помечен как «больной».
Этот метод тестирования полезен, если вы не можете или не хотите запускать HTTP-сервер, но можете запустить команду, которая проверит работоспособность вашего приложения.
Последний механизм проверки — это TCP-тест. Kubernetes попытается установить TCP-соединение через указанный порт. Если это удается сделать, контейнер считается исправным; в противном случае оно считается нежизнеспособным.
Этот метод может быть полезен, если вы используете сценарий, в котором тестирование с помощью HTTP-запроса или выполнения команды работает не очень хорошо.
Например, основными сервисами для проверки с использованием TCP будут gRPC или FTP. 
Тесты можно настроить несколькими способами с разными параметрами.
Вы можете указать, как часто они должны выполняться, каковы пороговые значения успеха и неудачи и как долго ждать ответов.
Дополнительные сведения см.
в документации по тестам готовности и работоспособности.
Однако есть один очень важный момент в настройке теста Liveness — первоначальная настройка задержки тестирования InitialDelaySeconds. Как я уже упоминал, провал этого теста приведет к перезапуску модуля.
Поэтому вам необходимо убедиться, что тестирование не начнется до тех пор, пока приложение не будет готово к работе, иначе оно начнет циклически перезапускаться.
Рекомендую использовать время запуска P99 или среднее время запуска приложения из буфера.
Не забывайте корректировать это значение по мере того, как время запуска вашего приложения увеличивается или замедляется.
Большинство экспертов подтвердят, что Health Checks — это обязательная проверка для любой распределенной системы, и Kubernetes не является исключением.
Использование проверок работоспособности сервисов обеспечивает надежную и бесперебойную работу Kubernetes и упрощает работу пользователей.
Продолжение будет совсем скоро.
Немного рекламы :)
Спасибо, что остаетесь с нами.Вам нравятся наши статьи? Хотите увидеть больше интересных материалов? Поддержите нас, разместив заказ или порекомендовав друзьям, облачный VPS для разработчиков от $4,99 , уникальный аналог серверов начального уровня, который мы придумали для вас: Вся правда о VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps от 19$ или как правильно раздать сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40 ГБ DDR4).
Dell R730xd в 2 раза дешевле в дата-центре Equinix Tier IV в Амстердаме? Только здесь 2 x Intel TetraDeca-Core Xeon, 2 x E5-2697v3, 2,6 ГГц, 14C, 64 ГБ DDR4, 4 твердотельных накопителя по 960 ГБ, 1 Гбит/с, 100 ТВ от 199 долларов США в Нидерландах! Dell R420 — 2x E5-2430, 2,2 ГГц, 6C, 128 ГБ DDR3, 2 твердотельных накопителя по 960 ГБ, 1 Гбит/с, 100 ТБ — от 99 долларов США! Прочтите об этом Как построить корпоративную инфраструктуру класса, используя серверы Dell R730xd E5-2650 v4 стоимостью 9000 евро за копейки? Теги: #Хостинг #ИТ-инфраструктура #Системное администрирование #Kubernetes
-
Официальный Блог Google Был Взломан Хакерами
19 Oct, 24 -
Как Развиваться В It
19 Oct, 24 -
Офис Uiddesign Group
19 Oct, 24 -
Каким Вы Видите Ит-Образование?
19 Oct, 24 -
Котлин 1.5: Онлайн-Мероприятие
19 Oct, 24
