Най-добри практики на Kubernetes. Коректно изключване Terminate

Най-добри практики за Kubernetes. Създаване на малки контейнери
Най-добри практики за Kubernetes. Организиране на Kubernetes с пространство за имена
Най-добри практики за Kubernetes. Проверка на жизненоспособността на Kubernetes с тестове за готовност и жизненост
Най-добри практики за Kubernetes. Настройка на заявки и лимити на ресурсите

Важен аспект в работата на разпределените системи е обработката на повреди. Kubernetes помага в това, използвайки контролери, които следят състоянието на системата ви и рестартират неработещите услуги. Въпреки това, Kubernetes може да спре принудително вашите приложения, за да осигури общата жизнеспособност на системата. В тази серия ще разгледаме как можете да помогнете на Kubernetes да изпълнява работата си по-ефективно и да намали времето за престой на приложенията.

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

Kubernetes използва цикъл на събития „наблюдение – фиксация на разлики – предприемане на действие“, за да се увери, че ресурсите запазват работоспособността си по пътя от контейнерите до самите възли.

Това означава, че вече не трябва ръчно да стартирате мониторинг на процесите. Ако ресурсът не премине проверката за работоспособност Health Check, Kubernetes просто автоматично предоставя замяна. Освен това, Kubernetes прави много повече от просто наблюдение на повредите на вашите приложения. Той може да създава повече копия на приложението за работа на множество машини, да обновява приложението или едновременно да стартира няколко версии на вашето приложение.
Затова съществуват множество причини, поради които Kubernetes може да прекрати работата на напълно здрав контейнер. Например, ако обновявате внедряването си, Kubernetes бавно ще спре старите подове, докато одновременно стартира нови. Ако деактивирате възел, Kubernetes ще прекрати работата на всички подове на този възел. Накрая, ако на възела свършат ресурсите, Kubernetes ще изключи всички подове, за да освободи тези ресурси.

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

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

След като Kubernetes реши да приключи pod, се извършва цяла поредица от събития. Нека разгледаме всяка стъпка, която предприема Kubernetes при прекратяване на работа на контейнера или pod.

Да предположим, че искаме да приключим един от подовете. В този момент той ще престане да получава нов трафик – работещите в пода контейнери няма да бъдат засегнати, но целият нов трафик ще бъде блокиран.

Нека разгледаме preStop hook – това е специална команда или HTTP заявка, която се изпраща на контейнерите в пода. Ако приложението ви не се изключва коректно при получаване на SIGTERM, можете да използвате preStop за правилно приключване на работата.

Повечето програми при получаване на сигнал SIGTERM приключват работата си коректно, но ако използвате външен код или система, която не можете да контролирате напълно, preStop hook е отличен начин да предизвикате елегантно изключване без промяна на приложението.

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

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

В този момент, преди да предприемете по-нататъшни действия, Kubernetes ще изчака указаното време, наречено terminationGracePeriodSecond, или период за коректно изключване при получаване на сигнала SIGTERM.

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

И накрая, последната стъпка — ако контейнерите все още продължават да работят след изтичането на terminationGracePeriod, те ще изпратят сигнал SIGKILL и ще бъдат forcibly removed. В този момент Kubernetes също ще почисти всички останали обекти на пода.

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

Най-добри практики на Kubernetes. Мапиране на външни услуги

Малко реклама 🙂

Благодарим ви, че оставате с нас. Харесвате ли нашите статии? Искате ли да виждате повече интересни материали? Подкрепете ни, като направите поръчка или препоръчате на познати, облачни VPS за разработчици от $4.99, уникален аналог на entry-level сървъри, който е създаден от нас за вас: Цялата истина за VPS (KVM) E5-2697 v3 (6 ядра) 10GB DDR4 480GB SSD 1Gbps от $19 или как да делите правилно сървър? (с налични опции за RAID1 и RAID10, до 24 ядра и до 40GB DDR4).

Dell R730xd на половин цена в дата центъра Equinix Tier IV в Амстердам? Всичко това само при нас 2 х Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100TB от 199 $ в Нидерландия! Dell R420 — 2x E5-2430 2.2GHz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — от 99 $! Чете се за това Как да построим инфраструктура от корпоративен клас с помощта на сървъри Dell R730xd E5-2650 v4 на стойност 9000 евро за малко пари?

Източник: habr.com