Празниците завршија и се враќаме со нашата втора објава во серијата Istio Service Mesh.
Денешната тема е Прекинувач, што преведено на руски електротехника значи „прекинувач“, во обичен идимски јазик – „прекинувач“. Само во Истио оваа машина не исклучува скратено или преоптоварено коло, туку неисправни контејнери.
Како ова треба да функционира идеално
Кога Kubernetes управува со микроуслугите, на пример во рамките на платформата OpenShift, тие автоматски се зголемуваат и намалуваат во зависност од оптоварувањето. Бидејќи микросервисите работат во подлоги, може да има повеќе примероци на контејнеризирана микросервис на една крајна точка, а Kubernetes ќе ги насочува барањата и ќе вчита рамнотежа меѓу нив. И - идеално - сето ова треба да функционира совршено.
Се сеќаваме дека микросервисите се мали и ефемерни. Ефемерноста, што овде значи леснотија на појавување и исчезнување, често се потценува. Раѓањето и смртта на уште еден примерок на микросервис во pod се сосема очекувани работи, OpenShift и Kubernetes добро се справуваат со ова, и сè функционира одлично - но повторно во теорија.
Како навистина функционира
Сега замислете дека одреден пример на микросервис, односно контејнер, станал неупотреблив: или не реагира (грешка 503), или, што е понепријатно, реагира, но премногу бавно. Со други зборови, станува блескав или не одговара на барањата, но не се отстранува автоматски од базенот. Што треба да се направи во овој случај? Да се обиде повторно? Дали треба да го отстранам од шемата за рутирање? А што значи „премногу бавно“ - колку е тоа во бројки и кој ги одредува? Можеби само да се одмори и да се обиде повторно подоцна? Ако е така, колку подоцна?
Што е исфрлање базен во Истио
И тука Istio доаѓа на помош со своите машини за заштита од прекинувачи, кои привремено ги отстрануваат неисправните контејнери од базенот на ресурси за насочување и балансирање на оптоварување, спроведувајќи ја процедурата за исфрлање базен.
Користејќи стратегија за откривање на оддалеченост, Istio ги детектира кривите подлоги кои се надвор од линијата и ги отстранува од базенот на ресурси на одредено време, наречено прозорец за спиење.
За да покажеме како функционира ова во Kubernetes на платформата OpenShift, да започнеме со скриншот на нормално работните микросервиси од примерот во складиштето . Овде имаме две мешунки, 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:
Поправање на дефектот
Значи, имаме неисправен контејнер и време е за Pool Ejection. Користејќи многу едноставна конфигурација, ќе го исклучиме овој неуспешен контејнер од какви било шеми за рутирање 15 секунди со надеж дека ќе се врати во здрава состојба (или рестартирајте или обновете ги перформансите). Еве како изгледа оваа конфигурација и резултатите од нејзината работа:
Како што можете да видите, неуспешниот v2 контејнер повеќе не се користи за барања за рутирање бидејќи е отстранет од базенот. Но, по 15 секунди автоматски ќе се врати во базенот. Всушност, само покажавме како функционира Pool Ejection.
Да почнеме да градиме архитектура
Pool Ejection, во комбинација со способностите за следење на Istio, ви овозможува да започнете со изградба на рамка за автоматска замена на неисправни контејнери за да се намали, ако не и елиминира, времето на застој и дефекти.
НАСА има едно гласно мото - Неуспехот не е опција, чиј автор се смета за директор на летот . Може да се преведе на руски како „Неуспехот не е опција“, а значењето овде е дека сè може да функционира ако имате доволно волја. Меѓутоа, во реалниот живот, неуспесите не се случуваат само, тие се неизбежни, секаде и во сè. И како да се справиме со нив во случај на микросервис? Според наше мислење, подобро е да се потпреме не на волјата, туку на можностите на контејнерите, , И .
Истио, како што напишавме погоре, го имплементира концептот на прекинувачи, кој добро се докажа во физичкиот свет. И исто како што електричниот прекинувач исклучува проблематичен дел од колото, софтверот Istio Circuit Breaker ја отвора врската помеѓу протокот на барања и проблематичниот контејнер кога нешто не е во ред со крајната точка, на пример, кога серверот паднал или почнал да успори.
Покрај тоа, во вториот случај има само повеќе проблеми, бидејќи сопирачките на еден контејнер не само што предизвикуваат каскада од одложувања во услугите што пристапуваат до него и, како резултат на тоа, ги намалуваат перформансите на системот како целина, туку и генерираат повторени барања до услуга која веќе бавно работи, што само ја влошува ситуацијата.
Прекинувач во теорија
Circuit Breaker е прокси што го контролира протокот на барања до крајната точка. Кога оваа точка ќе престане да работи или, во зависност од наведените поставки, ќе почне да забавува, проксито ја прекинува врската со контејнерот. Сообраќајот потоа се пренасочува кон други контејнери, едноставно поради балансирање на товарот. Врската останува отворена за даден прозорец за спиење, да речеме две минути, а потоа се смета за полуотворена. Обидот да се испрати следното барање ја одредува понатамошната состојба на врската. Ако сè е во ред со услугата, врската се враќа во работна состојба и повторно се затвора. Ако сè уште не е во ред со услугата, врската е исклучена и прозорецот за мирување е повторно овозможен. Еве како изгледа поедноставен дијаграм на состојбата на прекинувачот:
Овде е важно да се забележи дека сето ова се случува на ниво на, така да се каже, системска архитектура. Така, во одреден момент ќе мора да ги научите вашите апликации да работат со прекинувачот, како на пример обезбедување на стандардна вредност како одговор или, ако е можно, игнорирање на постоењето на услугата. За ова се користи шема на преграда, но тоа е надвор од опсегот на овој напис.
Прекинувач во пракса
На пример, ќе работиме две верзии на нашиот микросервис за препораки на OpenShift. Верзијата 1 ќе работи добро, но во v2 ќе изградиме со задоцнување за да симулираме забавувања на серверот. За да ги видите резултатите, користете ја алатката :
siege -r 2 -c 20 -v customer-tutorial.$(minishift ip).nip.io
Се чини дека сè функционира, но по која цена? На прв поглед, имаме 100% достапност, но погледнете подобро - максималното времетраење на трансакцијата е дури 12 секунди. Ова е очигледно тесно грло и треба да се прошири.
За да го направите ова, ќе го користиме Istio за да ги елиминираме повиците до бавните контејнери. Вака изгледа соодветната конфигурација со користење на прекинувачот:
Последната линија со параметарот httpMaxRequestsPerConnection сигнализира дека врската со треба да се исклучи кога се обидувате да создадете друга - втора - врска покрај постоечката. Бидејќи нашиот контејнер симулира бавна услуга, таквите ситуации ќе се појавуваат периодично, а потоа Истио ќе врати грешка 503, но еве што ќе покаже опсадата:
Добро, имаме прекинувач, што е следно?
Значи, имплементиравме автоматско исклучување без воопшто да го допираме изворниот код на самите услуги. Користејќи го прекинувачот и постапката за исфрлање на базенот опишана погоре, можеме да ги отстраниме контејнерите за сопирачките од базенот на ресурси додека не се вратат во нормала и да го провериме нивниот статус на одредена фреквенција - во нашиот пример, ова е две минути (параметар за спиење прозорец).
Имајте предвид дека способноста на апликацијата да одговори на грешка 503 сè уште е поставена на ниво на изворниот код. Постојат многу стратегии за користење на прекинувачот, во зависност од ситуацијата.
Во следниот пост: Ќе зборуваме за следењето и следењето што е веќе вградено или лесно додадено во Istio, како и за тоа како намерно да се воведат грешки во системот.
Извор: www.habr.com