Мереке аяқталды, біз Istio Service Mesh сериясындағы екінші жазбамызбен оралдық.
Бүгінгі тақырыбымыз - автоматты ажыратқыш, орыс тілінде «автоматты ауыстырып-қосқыш» немесе ауызекі тілмен айтқанда, «сөндіргіш» дегенді білдіреді. Istio-да бұл автоматты ажыратқыш қысқа тұйықталған немесе шамадан тыс жүктелген тізбектерді емес, ақаулы контейнерлерді ажыратады.
Ол қалай дұрыс жұмыс істеуі керек
Микросервистерді Kubernetes басқарған кезде, мысалы, OpenShift платформасында олар жүктемеге байланысты автоматты түрде үлкейеді және кішірейеді. Микросервистер подкасттарда жұмыс істейтіндіктен, контейнерленген микросервистің бірнеше даналары бір соңғы нүктеде жұмыс істей алады және Kubernetes сұрауларды бағыттайды және олардың арасындағы жүктемені теңестіреді. Ең дұрысы, мұның бәрі тамаша жұмыс істеуі керек.
Микросервистердің шағын және уақытша екенін есте ұстаймыз. Бұл жерде пайда болу және жоғалу жеңілдігін білдіретін эфемеральдылық жиі бағаланбайды. Тұтастағы тағы бір микросервис данасы тууы мен өлімі толығымен күтіледі; OpenShift және Kubernetes мұны жақсы өңдейді және бәрі тамаша жұмыс істейді, бірақ бұл тек теорияда ғана.
Бұл іс жүзінде қалай жұмыс істейді
Енді нақты микросервис данасы немесе контейнер жарамсыз болып қалды деп елестетіп көріңіз: не ол жауап бермейді (503 қатесі) немесе одан да жаманы, ол жауап береді, бірақ тым баяу. Басқаша айтқанда, ол қателеседі немесе жауап бермейді, бірақ ол автоматты түрде бассейннен жойылмайды. Бұл жағдайда не істеу керек? Қайтадан байқап көріңіз? Оны маршруттаудан жою керек пе? Ал «тым баяу» деген нені білдіреді? Бұл қанша және оны кім анықтайды? Мүмкін сізге үзіліс беріп, кейінірек қайталап көру керек шығар? Егер солай болса, қанша уақытқа?
Истиодағы бассейнді шығару дегеніміз не?
Дәл осы жерде Istio автоматты ажыратқышты қорғау механизмдерімен бірге келеді, ол пулды шығару процедурасын жүзеге асыру арқылы маршруттау және жүктемені теңестіретін ресурс пулынан ақаулы контейнерлерді уақытша алып тастайды.
Шектеулерді анықтау стратегиясын пайдалана отырып, Istio синхрондалмаған подкасттарды анықтайды және оларды ұйқы терезесі деп аталатын белгілі бір уақытқа ресурс пулынан жояды.
Мұның OpenShift платформасындағы Kubernetes жүйесінде қалай жұмыс істейтінін көрсету үшін мысал репозиторийінен қалыпты іске қосылған микросервистердің скриншотынан бастайық. Мұнда бізде әрқайсысы бір контейнермен жұмыс істейтін 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 екеніне кінәлі болуы мүмкін, бірақ уақыт өте келе жағдай жақсарады.
Біз қателік тудырып жатырмыз
Енді бір сау v1 контейнері, бір сау v2 контейнері және бір сынған v2 контейнері болуы үшін екі v2 контейнерінің бірін өшірейік:
Біз мәселені шешіп жатырмыз
Сонымен, бізде сәтсіз контейнер бар және Pool Ejection уақыты келді. Өте қарапайым конфигурацияны пайдалана отырып, біз бұл сәтсіз контейнерді барлық бағыттаудан 15 секундқа шығарып тастаймыз, ол өздігінен қалпына келеді деп үміттенеміз (қайта іске қосу немесе өнімділікті қалпына келтіру арқылы). Міне, бұл конфигурация қалай көрінеді және нәтижелер:
Көріп отырғаныңыздай, ақаулы v2 контейнері енді сұрауды бағыттау үшін пайдаланылмайды, себебі ол пулдан жойылған. Дегенмен, 15 секундтан кейін ол автоматты түрде бассейнге оралады. Шын мәнінде, біз жаңа ғана Pool Ejection қалай жұмыс істейтінін көрсеттік.
Сәулет салуды бастайық
Pool Ejection, Istio бақылау мүмкіндіктерімен біріктірілген, тоқтау уақытын және сәтсіздіктерді жою болмаса, қысқарту үшін сәтсіз контейнерлерді автоматты түрде ауыстыруға арналған құрылымды құруды бастауға мүмкіндік береді.
NASA-ның бір ұраны бар - сәтсіздікке жол берілмейді, оның авторы ұшу директоры болып саналады. Оны орыс тіліне «Сәтсіздік - бұл опция» деп аударуға болады және ойы жеткілікті ерік-жігермен жұмыс істеу үшін кез келген нәрсені жасауға болады. Дегенмен, шынайы өмірде сәтсіздіктер жайдан-жай бола бермейді; олар барлық жерде және барлық жерде сөзсіз. Сонымен, микросервис жағдайында олармен қалай күресуге болады? Біздің ойымызша, ерік-жігерге емес, контейнерлердің мүмкіндіктеріне сүйенген дұрыс. , мен .
Istio, жоғарыда айтқанымыздай, физикалық әлемде автоматты ажыратқыштардың жақсы қалыптасқан тұжырымдамасын жүзеге асырады. Электр сөндіргіші тізбектің проблемалы бөлігін ажырататыны сияқты, Istio бағдарламалық жасақтамасына негізделген автоматты ажыратқыш соңғы нүктеде бірдеңе дұрыс емес болғанда, мысалы, сервер істен шыққанда немесе баяулағанда сұрау ағыны мен проблемалық контейнер арасындағы байланысты ажыратады.
Сонымен қатар, екінші жағдайда, проблемалар тек өседі, өйткені бір контейнердің баяулауы оған қол жеткізу қызметтерінің кешігуінің каскадын тудырып қана қоймайды және нәтижесінде тұтастай алғанда жүйенің өнімділігін төмендетеді, сонымен қатар баяу қызметке қайталанатын сұраныстарды тудырады, бұл жағдайды нашарлатады.
Теориядағы автоматты ажыратқыш
Circuit Breaker - соңғы нүктеге сұраулар ағынын басқаратын прокси. Бұл соңғы нүкте жұмысын тоқтатқанда немесе конфигурацияланған параметрлерге байланысты баяулай бастағанда, прокси контейнерге қосылымды ажыратады. Содан кейін трафик тек жүктемені теңестіру мақсатында басқа контейнерлерге қайта бағытталады. Қосылым белгіленген ұйқы терезесі үшін, айталық, екі минут үшін ашық қалады, содан кейін жартылай ашық болып саналады. Келесі сұрауды жіберу әрекеті қосылымның кейінгі күйін анықтайды. Егер қызмет дұрыс болса, қосылым жұмыс күйіне оралады және қайтадан жабылады. Егер қызмет әлі де сәтсіз болса, қосылым ажыратылады және ұйқы терезесі қайта қосылады. Мұнда автоматты ажыратқыш күйіне ауысудың жеңілдетілген диаграммасы берілген:
Айта кету керек, мұның бәрі жүйе архитектурасы деңгейінде, былайша айтқанда. Сондықтан, белгілі бір уақытта, мысалы, жауап ретінде әдепкі мәнді беру немесе мүмкін болса, қызметтің бар екенін елемеу арқылы қолданбаларды автоматты ажыратқышпен жұмыс істеуге үйрету керек болады. Бұл аралық қалқан үлгісін пайдалану арқылы орындалады, бірақ ол осы мақаланың ауқымынан тыс.
Тәжірибедегі автоматты ажыратқыш
Бұл мысал үшін OpenShift жүйесінде ұсынылған микросервистің екі нұсқасын іске қосамыз. 1-нұсқа қалыпты жұмыс істейді, бірақ v2-де сервердің лагін модельдеу үшін кідіріс қосамыз. Нәтижелерді көру үшін құралды пайдаланыңыз :
siege -r 2 -c 20 -v customer-tutorial.$(minishift ip).nip.io
Барлығы жұмыс істеп тұрған сияқты, бірақ қанша тұрады? Бір қарағанда, бізде 100% қолжетімділік бар, бірақ мұқият қараңыз - транзакцияның максималды ұзақтығы - 12 секунд. Бұл тығырыққа тірелгені анық, оны шешу керек.
Мұны істеу үшін біз баяу контейнерлерге қоңырауларды болдырмау үшін Istio пайдаланамыз. Ажыратқышты пайдалану арқылы сәйкес конфигурация келесідей болады:
httpMaxRequestsPerConnection параметрі бар соңғы жол бұрыннан бар қосылымға қосымша екінші қосылым жасау әрекеті кезінде қосылымды жабу керектігін көрсетеді. Біздің контейнер баяу қызметті модельдейтіндіктен, мұндай жағдайлар мезгіл-мезгіл орын алады, содан кейін Istio 503 қатесін қайтарады және Siege мынаны көрсетеді:
Жарайды, бізде автоматты ажыратқыш бар, енді не болады?
Осылайша, біз қызметтердің бастапқы кодына қол тигізбестен автоматты түрде өшіруді енгіздік. Жоғарыда сипатталған Circuit Breaker және Pool Ejection процедурасын пайдалану арқылы біз баяу контейнерлерді қалыпты жағдайға оралғанша ресурс пулынан алып тастай аламыз және олардың күйін белгілі бір аралықта тексере аламыз — біздің мысалда әрбір екі минут сайын (sleepWindow параметрі).
Қолданбаның 503 қатесіне жауап беру мүмкіндігі әлі де бастапқы код деңгейінде анықталғанын ескеріңіз. Жағдайға байланысты автоматты ажыратқышпен жұмыс істеудің әртүрлі стратегиялары бар.
Келесі постта: Біз Istio ішіне енгізілген немесе оңай қосылатын бақылау мен бақылауды, сондай-ақ жүйеге қателерді әдейі енгізу жолын қарастырамыз.
Ақпарат көзі: www.habr.com
