Pi bon pratik Kubernetes. Fèmen kòrèk Mete fen

Pi bon pratik Kubernetes. Kreye ti resipyan
Pi bon pratik Kubernetes. Òganizasyon Kubernetes ak espas non
Pi bon pratik Kubernetes. Validasyon Kubernetes Liveness ak Preparasyon ak Tès Liveness
Pi bon pratik Kubernetes. Mete kanpe demann resous ak limit

Pi bon pratik Kubernetes. Fèmen kòrèk Mete fen

Важным моментом в работе распределенных систем является обработка сбоев. Kubernetes помогает в этом, используя контроллеры, которые следят за состоянием вашей системы и перезапускают переставшие работать сервисы. Однако Kubernetes может принудительно останавливать работу ваших приложений, чтобы обеспечить общую жизнеспособность системы. В этой серии мы рассмотрим, как можно помочь Kubernetes выполнять свою работу более эффективно и сокращать время простоя приложений.

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

Kubernetes использует петлю событий «наблюдение – фиксация отличий – совершение действия», чтобы убедиться, что ресурсы сохраняют работоспособность по пути из контейнеров к самим узлам.

Pi bon pratik Kubernetes. Fèmen kòrèk Mete fen

Это означает, что вам больше не нужно вручную запускать мониторинг процессов. Если ресурс не прошел проверку работоспособности Health Check, Kubernetes просто автоматически предоставит ему замену. При этом Kubernetes делает гораздо больше, чем просто следит за сбоями ваших приложений. Он может создавать больше копий приложения для работы на нескольких машинах, обновлять приложение или одновременно запускать несколько версий вашего приложения.
Поэтому существует множество причин, по которым Kubernetes может прервать работу совершенно здорового контейнера. Например, если вы обновляете свое развертывание, Kubernetes будет медленно останавливать старые поды, одновременно запуская новые. Если вы отключаете узел, Kubernetes прекратит работу всех подов в этом узле. Наконец, если у узла закончатся ресурсы, Kubernetes отключит все поды, чтобы освободить эти ресурсы.

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

На практике это означает, что ваше приложение должно уметь обрабатывать сообщение SIGTERM – сигнал завершения процесса, который является сигналом по умолчанию для утилиты kill в ОС семейства Unix. Получив это сообщение, приложение должно отключиться.

После того, как Kubernetes решил завершить pod, происходит целый ряд событий. Давайте рассмотрим каждый шаг, который совершает Kubernetes при завершении работы контейнера или пода.

Предположим, что мы хотим завершить один из подов. В этот момент он перестанет получать новый трафик – работающие в поде контейнеры не будут затронуты, но весь новый трафик будет заблокирован.

Pi bon pratik Kubernetes. Fèmen kòrèk Mete fen

Давайте рассмотрим хук preStop — это специальная команда или HTTP-запрос, который отправляется контейнерам в поде. Если ваше приложение при получении SIGTERM выключается не корректно, вы можете использовать preStop для правильного завершения работы.

Pi bon pratik Kubernetes. Fèmen kòrèk Mete fen

Большинство программ при получении сигнала SIGTERM завершают свою работу корректно, но если вы используете сторонний код или какую-то систему, которую не можете полностью контролировать, хук preStop служит отличным способом вызвать изящное отключение без изменения приложения.

После исполнения этого хука Kubernetes пошлет контейнерам в поде сигнал SIGTERM, который даст им знать, что скоро они будут отключены. Получив этот сигнал, ваш код перейдет к процессу отключения. Этот процесс может включать в себя остановку любых долгоживущих соединений, таких, как подключение к базе данных или поток WebSocket, сохранение текущего состояния и тому подобное.

Даже если вы используете хук preStop, очень важно проверить, что именно происходит с вашим приложением, когда вы посылаете ему сигнал SIGTERM, как оно себя при этом ведет, чтобы события или изменения в работе системы, вызванные отключением пода, не стали для вас неожиданностью.

В этот момент, прежде чем предпринять дальнейшие действия, Kubernetes будет ждать в течение указанного времени, называемого terminationGracePeriodSecond, или периодом для корректного отключения при получении сигнала SIGTERM.

Pi bon pratik Kubernetes. Fèmen kòrèk Mete fen

По умолчанию этот период составляет 30 секунд. Важно отметить, что он длится параллельно с preStop hook и сигналом SIGTERM. Kubernetes не будет ждать, пока закончится preStop hook и SIGTERM — если ваше приложение завершит работу до окончания периода TerminationGracePeriod, Kubernetes немедленно перейдет к следующему шагу. Поэтому проверьте, чтобы значение данного периода в секундах было не меньше времени, требуемого для корректного отключения пода, и если оно превышает 30с, увеличьте период до нужной величины в YAML. В приведенном примере он составляет 60с.

И наконец, последний шаг — если контейнеры все еще продолжают работать по истечении terminationGracePeriod, они пошлют сигнал SIGKILL и будут принудительно удалены. В этот момент Kubernetes также вычистит все остальные объекты пода.

Pi bon pratik Kubernetes. Fèmen kòrèk Mete fen

Kubernetes прекращает работу подов по многим причинам, поэтому убедитесь, что в любом случае ваше приложение будет завершено корректно, чтобы обеспечить стабильную работу сервиса.

Pi bon pratik Kubernetes. Kat jeyografik sèvis ekstèn

Kèk piblisite 🙂

Mèsi paske w rete avèk nou. Ou renmen atik nou yo? Vle wè plis kontni enteresan? Sipòte nou pa mete yon lòd oswa rekòmande pou zanmi, nwaj VPS pou devlopè soti nan $ 4.99, yon analogue inik nan sèvè nivo antre, ki te envante pa nou pou ou: Tout verite sou VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps soti nan $ 19 oswa ki jan yo pataje yon sèvè? (disponib ak RAID1 ak RAID10, jiska 24 nwayo ak jiska 40GB DDR4).

Dell R730xd 2 fwa pi bon mache nan sant done Equinix Tier IV nan Amstèdam? Sèlman isit la 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV soti nan $199 nan Netherlands! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - soti nan $ 99! Li sou Ki jan yo bati enfrastrikti corp. klas ak itilizasyon Dell R730xd E5-2650 v4 serveurs ki vo 9000 ero pou yon jounen travay?

Sous: www.habr.com

Add nouvo kòmantè