Istio Circuit Breaker: дезактивиране на дефектни контейнери

Празниците свършиха и ние се завръщаме с нашата втора публикация от поредицата Istio Service Mesh.

Днешната тема е Circuit Breaker, което в превод на руска електротехника означава „прекъсвач“, на общ език – „прекъсвач“. Само в Istio тази машина не изключва късо или претоварена верига, а дефектни контейнери.

Как това трябва да работи в идеалния случай

Когато микроуслугите се управляват от Kubernetes, например в рамките на платформата OpenShift, те автоматично се мащабират нагоре и надолу в зависимост от натоварването. Тъй като микроуслугите се изпълняват в подове, може да има множество екземпляри на контейнеризирана микроуслуга на една крайна точка и Kubernetes ще насочва заявките и ще балансира натоварването между тях. И - в идеалния случай - всичко това трябва да работи перфектно.

Спомняме си, че микроуслугите са малки и ефимерни. Ефимерността, която тук означава лекотата на появяване и изчезване, често се подценява. Раждането и смъртта на друг екземпляр на микроуслуга в pod са доста очаквани неща, OpenShift и Kubernetes се справят добре с това и всичко работи чудесно - но отново на теория.

Как наистина работи

Сега си представете, че конкретен екземпляр на микроуслуга, тоест контейнер, е станал неизползваем: или не отговаря (грешка 503), или, което е по-неприятно, реагира, но твърде бавно. С други думи, той става бъг или не отговаря на заявки, но не се премахва автоматично от пула. Какво трябва да се направи в този случай? Да опитам отново? Трябва ли да го премахна от схемата за маршрутизиране? И какво означава „прекалено бавно“ – колко е в цифри и кой ги определя? Може би просто си починете и опитайте отново по-късно? Ако да, колко по-късно?

Какво е Pool Ejection в Istio

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

Използвайки стратегия за откриване на отклонения, Istio открива криви, които са извън линията, и ги премахва от ресурсния пул за определен период от време, наречен прозорец на заспиване.

За да покажем как работи това в Kubernetes на платформата OpenShift, нека започнем с екранна снимка на нормално работещи микроуслуги от примера в хранилището Демонстрации за разработчици на Red Hat. Тук имаме две подове, v1 и v2, всяка от които работи с един контейнер. Когато правилата за маршрутизиране на Istio не се използват, Kubernetes по подразбиране използва равномерно балансирано кръгово маршрутизиране:

Подготвям се за катастрофа

Преди да направите Pool Ejection, трябва да създадете правило за маршрутизиране на Istio. Да кажем, че искаме да разпределим заявките между подовете в съотношение 50/50. Освен това ще увеличим броя на v2 контейнерите от един на два, както следва:

oc scale deployment recommendation-v2 --replicas=2 -n tutorial

Сега задаваме правило за маршрутизиране, така че трафикът да се разпределя между подовете в съотношение 50/50.

Ето как изглежда резултатът от това правило:

Може да се заяде, че този екран не е 50/50, а 14:9, но с времето ситуацията ще се подобри.

Правене на бъг

Сега нека деактивираме един от двата контейнера v2, така че да имаме един здрав контейнер v1, един здрав контейнер v2 и един дефектен контейнер v2:

Коригиране на проблема

И така, имаме дефектен контейнер и е време за изхвърляне на басейна. Използвайки много проста конфигурация, ние ще изключим този неуспешен контейнер от всякакви схеми за маршрутизиране за 15 секунди с надеждата, че ще се върне в здравословно състояние (или рестартиране, или възстановяване на производителността). Ето как изглежда тази конфигурация и резултатите от нейната работа:

Както можете да видите, неуспешният v2 контейнер вече не се използва за заявки за маршрутизиране, тъй като е премахнат от пула. Но след 15 секунди автоматично ще се върне в басейна. Всъщност току-що показахме как работи Pool Ejection.

Да започнем да строим архитектура

Pool Ejection, комбиниран с възможностите за наблюдение на Istio, ви позволява да започнете да изграждате рамка за автоматична подмяна на дефектни контейнери, за да намалите, ако не и елиминирате, времето на престой и повреди.
 
НАСА има едно силно мото - Провалът не е опция, чийто автор се смята за директор на полета Джийн Кранц. Може да се преведе на руски като „Провалът не е опция“, а смисълът тук е, че всичко може да се направи, ако имате достатъчно воля. В реалния живот обаче провалите не се случват просто, те са неизбежни, навсякъде и във всичко. И как да се справим с тях в случай на микроуслуги? Според нас е по-добре да не разчитаме на силата на волята, а на възможностите на контейнерите, Kubernetes, Red Hat OpenShiftИ Истио.

Istio, както писахме по-горе, прилага концепцията за прекъсвачи, която се е доказала добре във физическия свят. И точно както прекъсвачът на електрическа верига изключва проблемна част от веригата, софтуерът Circuit Breaker на Istio отваря връзката между поток от заявки и проблемен контейнер, когато нещо не е наред с крайната точка, например когато сървърът се срине или започне да забави.

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

Прекъсвач на теория

Circuit Breaker е прокси, което контролира потока от заявки към крайна точка. Когато тази точка спре да работи или, в зависимост от зададените настройки, започне да се забавя, проксито прекъсва връзката с контейнера. След това трафикът се пренасочва към други контейнери, просто поради балансиране на натоварването. Връзката остава отворена за даден прозорец на заспиване, да кажем две минути, след което се счита за полуотворена. Опитът за изпращане на следващата заявка определя по-нататъшното състояние на връзката. Ако всичко е наред с услугата, връзката се връща в работно състояние и отново се затваря. Ако все още има нещо нередно с услугата, връзката се прекъсва и прозорецът за заспиване се активира отново. Ето как изглежда опростена диаграма на състоянието на прекъсвача:

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

Прекъсвач на практика

Например, ние ще стартираме две версии на нашата препоръчителна микроуслуга на OpenShift. Версия 1 ще работи добре, но във v2 ще вградим забавяне, за да симулираме забавяне на сървъра. За да видите резултатите, използвайте инструмента обсада:

siege -r 2 -c 20 -v customer-tutorial.$(minishift ip).nip.io

Всичко изглежда работи, но на каква цена? На пръв поглед имаме 100% наличност, но погледнете по-отблизо – максималната продължителност на транзакцията е цели 12 секунди. Това очевидно е тясно място и трябва да бъде разширено.

За да направим това, ще използваме Istio, за да елиминираме повикванията към бавни контейнери. Ето как изглежда съответната конфигурация с помощта на Circuit Breaker:

Последният ред с параметъра httpMaxRequestsPerConnection сигнализира, че връзката с трябва да бъде прекъсната, когато се опитвате да създадете друга - втора - връзка в допълнение към съществуващата. Тъй като нашият контейнер симулира бавна услуга, такива ситуации ще възникват периодично и след това Istio ще върне грешка 503, но ето какво ще покаже siege:

Добре, имаме прекъсвач, какво следва?

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

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

В следващия пост: Ще разгледаме проследяването и мониторинга, които вече са вградени или лесно добавени към Istio, както и как умишлено да въвеждате грешки в системата.

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