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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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