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

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

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

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

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

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

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

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

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

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

Нека обсъдим 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 и ще бъдат принудително премахнати. В този момент 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 Е5-2650 v4 на стойност 9000 евро за копейки?

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