Лучшие практики Kubernetes. Организация Kubernetes с пространством имен
Лучшие практики Kubernetes. Проверка жизнеспособности Kubernetes с помощью тестов Readiness и Liveness
Лучшие практики Kubernetes. Настройка запросов и лимитов ресурсов
Важным моментом в работе распределенных систем является обработка сбоев. Kubernetes помогает в этом, используя контроллеры, которые следят за состоянием вашей системы и перезапускают переставшие работать сервисы. Однако Kubernetes может принудительно останавливать работу ваших приложений, чтобы обеспечить общую жизнеспособность системы. В этой серии мы рассмотрим, как можно помочь Kubernetes выполнять свою работу более эффективно и сокращать время простоя приложений.
До начала применения контейнеров большинство приложений работали на виртуальных или физических машинах. Если приложение давало сбой или зависало, требовалось много времени, чтобы снять выполняемую задачу и заново загрузить программу. В худшем случае кому-то приходилось решать эту проблему вручную ночью, в самое неурочное время. Если важную задачу выполняли всего 1-2 рабочих машины, такой сбой в работе был совершенно неприемлемым.
Поэтому вместо ручной перезагрузки начали использовать мониторинг на уровне процессов для автоматического перезапуска приложения в случае его аварийного завершения. Если программа дала сбой, процесс мониторинга захватывает exit-код и перезагружает сервер. С появлением таких систем, как Kubernetes, этот вид реагирования на сбои системы был просто интегрирован в инфраструктуру.
Kubernetes использует петлю событий «наблюдение – фиксация отличий – совершение действия», чтобы убедиться, что ресурсы сохраняют работоспособность по пути из контейнеров к самим узлам.
Это означает, что вам больше не нужно вручную запускать мониторинг процессов. Если ресурс не прошел проверку работоспособности Health Check, Kubernetes просто автоматически предоставит ему замену. При этом Kubernetes делает гораздо больше, чем просто следит за сбоями ваших приложений. Он может создавать больше копий приложения для работы на нескольких машинах, обновлять приложение или одновременно запускать несколько версий вашего приложения.
Поэтому существует множество причин, по которым Kubernetes может прервать работу совершенно здорового контейнера. Например, если вы обновляете свое развертывание, Kubernetes будет медленно останавливать старые поды, одновременно запуская новые. Если вы отключаете узел, Kubernetes прекратит работу всех подов в этом узле. Наконец, если у узла закончатся ресурсы, Kubernetes отключит все поды, чтобы освободить эти ресурсы.
Поэтому очень важно, чтобы ваше приложение прекращало работу с минимальным влиянием на конечного пользователя и минимальным временем восстановления. Это означает, что перед отключением оно должно сохранить все данные, которые необходимо сохранить, закрыть все сетевые подключения, завершить оставшуюся работу и успеть выполнить другие неотложные задачи.
На практике это означает, что ваше приложение должно уметь обрабатывать сообщение SIGTERM – сигнал завершения процесса, который является сигналом по умолчанию для утилиты kill в ОС семейства Unix. Получив это сообщение, приложение должно отключиться.
После того, как Kubernetes решил завершить pod, происходит целый ряд событий. Давайте рассмотрим каждый шаг, который совершает Kubernetes при завершении работы контейнера или пода.
Предположим, что мы хотим завершить один из подов. В этот момент он перестанет получать новый трафик – работающие в поде контейнеры не будут затронуты, но весь новый трафик будет заблокирован.
Давайте рассмотрим хук preStop — это специальная команда или HTTP-запрос, который отправляется контейнерам в поде. Если ваше приложение при получении SIGTERM выключается не корректно, вы можете использовать preStop для правильного завершения работы.
Большинство программ при получении сигнала SIGTERM завершают свою работу корректно, но если вы используете сторонний код или какую-то систему, которую не можете полностью контролировать, хук preStop служит отличным способом вызвать изящное отключение без изменения приложения.
После исполнения этого хука Kubernetes пошлет контейнерам в поде сигнал SIGTERM, который даст им знать, что скоро они будут отключены. Получив этот сигнал, ваш код перейдет к процессу отключения. Этот процесс может включать в себя остановку любых долгоживущих соединений, таких, как подключение к базе данных или поток WebSocket, сохранение текущего состояния и тому подобное.
Даже если вы используете хук preStop, очень важно проверить, что именно происходит с вашим приложением, когда вы посылаете ему сигнал SIGTERM, как оно себя при этом ведет, чтобы события или изменения в работе системы, вызванные отключением пода, не стали для вас неожиданностью.
В этот момент, прежде чем предпринять дальнейшие действия, Kubernetes будет ждать в течение указанного времени, называемого terminationGracePeriodSecond, или периодом для корректного отключения при получении сигнала SIGTERM.
По умолчанию этот период составляет 30 секунд. Важно отметить, что он длится параллельно с preStop hook и сигналом SIGTERM. Kubernetes не будет ждать, пока закончится preStop hook и SIGTERM — если ваше приложение завершит работу до окончания периода TerminationGracePeriod, Kubernetes немедленно перейдет к следующему шагу. Поэтому проверьте, чтобы значение данного периода в секундах было не меньше времени, требуемого для корректного отключения пода, и если оно превышает 30с, увеличьте период до нужной величины в YAML. В приведенном примере он составляет 60с.
И наконец, последний шаг — если контейнеры все еще продолжают работать по истечении terminationGracePeriod, они пошлют сигнал SIGKILL и будут принудительно удалены. В этот момент 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 4x960GB SSD 1Gbps 100 ТВ от $199 в Нидерландах! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — от $99! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?
Комментариев нет:
Отправить комментарий