Разпределените системи могат да бъдат трудни за управление, защото имат много движещи се, променящи се елементи, които всички трябва да работят правилно, за да функционира системата. Ако някой от елементите се повреди, системата трябва да го открие, да го заобиколи и да го поправи, като всичко това трябва да стане автоматично. В тази поредица от най-добри практики на Kubernetes ще научим как да настроим тестове за готовност и жизнеспособност, за да тестваме изправността на клъстер на Kubernetes.
Проверката на здравето е лесен начин да уведомите системата дали вашето приложение работи или не. Ако екземплярът на вашето приложение не работи, други услуги не трябва да имат достъп до него или да изпращат заявки към него. Вместо това заявката трябва да бъде изпратена до друго копие на приложението, което вече работи или ще бъде стартирано по-късно. Освен това системата трябва да възстанови загубената функционалност на вашето приложение.
По подразбиране Kubernetes ще започне да изпраща трафик към под, когато всички контейнери в подовете работят, и ще рестартира контейнерите, когато се сринат. Това поведение на системата по подразбиране може да е достатъчно добро за начало, но можете да подобрите надеждността на внедряването на вашия продукт, като използвате персонализирани проверки за надеждност.
За щастие Kubernetes прави това доста лесно за изпълнение, така че няма извинение за пренебрегването на тези проверки. Kubernetes предоставя два вида проверки на здравето и е важно да се разберат разликите в начина на използване на всеки от тях.
Тестът за готовност е предназначен да каже на Kubernetes, че вашето приложение е готово да обработва трафик. Преди да позволи на дадена услуга да изпраща трафик към под, Kubernetes трябва да провери дали проверката за готовност е успешна. Ако тестът за готовност е неуспешен, Kubernetes ще спре да изпраща трафик към групата, докато тестът не премине.
Тестът за живост казва на Kubernetes дали вашето приложение е живо или мъртво. В първия случай Kubernetes ще го остави сам, във втория ще изтрие мъртвия под и ще го замени с нов.
Нека си представим сценарий, при който приложението ви отнема 1 минута, за да загрее и стартира. Вашата услуга няма да започне да работи, докато приложението не бъде напълно заредено и стартирано, въпреки че работният процес вече е започнал. Също така ще имате проблеми, ако искате да увеличите мащаба на това внедряване до множество копия, тъй като тези копия не трябва да получават трафик, докато не са напълно готови. По подразбиране обаче Kubernetes ще започне да изпраща трафик веднага щом процесите в контейнера започнат.
Когато използвате теста за готовност, Kubernetes ще изчака, докато приложението започне да работи напълно, преди да позволи на услугата да изпрати трафик към новото копие.
Нека си представим друг сценарий, при който приложението виси за дълго време, спирайки да обслужва заявки. Тъй като процесът продължава да се изпълнява, по подразбиране Kubernetes ще приеме, че всичко е наред и ще продължи да изпраща заявки до неработещата група. Но когато използвате Liveness, Kubernetes ще открие, че приложението вече не обслужва заявки и ще рестартира мъртвия модул по подразбиране.
Нека да разгледаме как се проверява готовността и жизнеспособността. Има три метода за тестване - HTTP, Command и TCP. Можете да използвате всеки от тях за проверка. Най-често срещаният начин за тестване на потребител е HTTP сонда.
Дори ако вашето приложение не е HTTP сървър, все пак можете да създадете олекотен HTTP сървър във вашето приложение, за да взаимодействате с теста Liveness. След това Kubernetes ще започне да пингва групата и ако HTTP отговорът е в диапазона от 200 или 300 ms, това ще покаже, че групата е здрава. В противен случай модулът ще бъде маркиран като "нездравословен".
За командни тестове Kubernetes изпълнява командата във вашия контейнер. Ако командата се върне с нулев код за изход, тогава контейнерът ще бъде маркиран като здрав, в противен случай, при получаване на номер на статус на изход от 1 до 255, контейнерът ще бъде маркиран като „болен“. Този метод на тестване е полезен, ако не можете или не искате да стартирате HTTP сървър, но можете да изпълните команда, която ще провери изправността на вашето приложение.
Последният механизъм за проверка е TCP тестът. Kubernetes ще се опита да установи TCP връзка на посочения порт. Ако това може да се направи, контейнерът се счита за здрав; ако не, той се счита за нежизнеспособен. Този метод може да бъде полезен, ако използвате сценарий, при който тестването с HTTP заявка или изпълнение на команда не работи много добре. Например, основните услуги за проверка чрез TCP ще бъдат gRPC или FTP.
Тестовете могат да бъдат конфигурирани по няколко начина с различни параметри. Можете да посочите колко често трябва да се изпълняват, какви са праговете за успех и неуспех и колко време да чакате за отговори. За повече информация вижте документацията за тестовете за готовност и жизненост. Има обаче един много важен момент при настройването на теста за живост - първоначалната настройка на забавянето на тестването initialDelaySeconds. Както споменах, неуспехът на този тест ще доведе до рестартиране на модула. Така че трябва да се уверите, че тестването не започва, докато приложението не е готово за работа, в противен случай то ще започне да се циклично рестартира. Препоръчвам да използвате времето за стартиране на P99 или средното време за стартиране на приложението от буфера. Не забравяйте да коригирате тази стойност, тъй като времето за стартиране на вашето приложение става по-бързо или по-бавно.
Повечето експерти ще потвърдят, че проверките на здравето са задължителна проверка за всяка разпределена система и Kubernetes не е изключение. Използването на проверки на изправността на услугата гарантира надеждна, безпроблемна работа на Kubernetes и е безпроблемна за потребителите.
Продължение съвсем скоро...
Малко реклами 🙂
Благодарим ви, че останахте с нас. Харесвате ли нашите статии? Искате ли да видите още интересно съдържание? Подкрепете ни, като направите поръчка или препоръчате на приятели, , уникален аналог на сървъри от начално ниво, който беше изобретен от нас за вас: (предлага се с RAID1 и RAID10, до 24 ядра и до 40GB DDR4).
Dell R730xd 2 пъти по-евтин в центъра за данни Equinix Tier IV в Амстердам? Само тук в Холандия! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - от $99! Прочети за
Източник: www.habr.com