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