Мереке аяқталды және біз Istio Service Mesh сериясындағы екінші жазбамызбен оралдық.
Бүгінгі тақырып – автоматты ажыратқыш, ол орысша электротехникадан аударғанда «сұрақ сөндіргіш» дегенді білдіреді, жалпы тілмен айтқанда – «сұрақ сөндіргіш». Тек Истиода бұл машина тұйықталған немесе шамадан тыс жүктелген тізбекті емес, ақаулы контейнерлерді ажыратады.
Бұл қалай дұрыс жұмыс істеуі керек
Микросервистерді Kubernetes басқарған кезде, мысалы, OpenShift платформасында, олар жүктемеге байланысты автоматты түрде үлкейтеді және кішірейеді. Микросервистер подкасттарда жұмыс істейтіндіктен, бір соңғы нүктеде контейнерленген микросервистің бірнеше даналары болуы мүмкін және Kubernetes сұрауларды бағыттайды және олардың арасындағы жүктеме балансын жасайды. Және - ең дұрысы - мұның бәрі тамаша жұмыс істеуі керек.
Микросервистердің шағын және уақытша екенін есте ұстаймыз. Бұл жерде пайда болу және жоғалу жеңілдігін білдіретін эфемерлік жиі бағаланбайды. Бөлмедегі микросервистің басқа данасының тууы және өлуі күтілетін нәрсе, OpenShift және Kubernetes мұны жақсы өңдейді және бәрі жақсы жұмыс істейді, бірақ теорияда тағы да.
Бұл іс жүзінде қалай жұмыс істейді
Енді микросервистің белгілі бір данасы, яғни контейнер жарамсыз болып қалды деп елестетіп көріңіз: не ол жауап бермейді (503 қатесі), не жағымсызы, ол жауап береді, бірақ тым баяу. Басқаша айтқанда, ол ақауға айналады немесе сұрауларға жауап бермейді, бірақ ол автоматты түрде пулдан жойылмайды. Бұл жағдайда не істеу керек? Қайталап көру керек пе? Оны маршруттау схемасынан алып тастауым керек пе? Ал «тым баяу» деген нені білдіреді – ол санда қанша және оларды кім анықтайды? Мүмкін үзіліс жасап, кейінірек қайталап көріңіз? Олай болса, қанша уақыттан кейін?
Istio-да бассейнді шығару дегеніміз не
Міне, 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 екеніне кінәлі бола аласыз, бірақ уақыт өте келе жағдай жақсарады.
Ақаулық жасау
Енді бір сау v2 контейнері, бір сау v1 контейнері және бір ақаулы v2 контейнері болуы үшін екі v2 контейнерінің бірін өшірейік:
Ақаулықты түзету
Сонымен, бізде ақаулы контейнер бар және бассейнді шығару уақыты келді. Өте қарапайым конфигурацияны пайдалана отырып, біз бұл сәтсіз контейнерді кез келген бағыттау схемаларынан 15 секундқа шығарып тастаймыз, ол сау күйіне оралады (қайта іске қосу немесе өнімділікті қалпына келтіру). Бұл конфигурацияның көрінісі және оның жұмысының нәтижелері:
Көріп отырғаныңыздай, сәтсіз v2 контейнері бұдан былай бағыттау сұраулары үшін пайдаланылмайды, себебі ол пулдан жойылған. Бірақ 15 секундтан кейін ол автоматты түрде бассейнге оралады. Шын мәнінде, біз жай ғана Pool Ejection қалай жұмыс істейтінін көрсеттік.
Сәулет салуды бастайық
Pool Ejection, Istio бақылау мүмкіндіктерімен біріктірілген, тоқтау уақытын және сәтсіздіктерді жою болмаса, қысқарту үшін ақаулы контейнерлерді автоматты түрде ауыстыру үшін негіз құруды бастауға мүмкіндік береді.
NASA-ның бір ұраны бар - сәтсіздікке жол берілмейді, оның авторы ұшу директоры болып саналады. . Оны орыс тіліне «Сәтсіздік - бұл опция» деп аударуға болады және мұндағы мағынасы, егер сізде жеткілікті ерік болса, барлығын орындауға болады. Алайда, шынайы өмірде сәтсіздіктер жайдан-жай бола бермейді, олар барлық жерде және барлық жерде болмай қоймайды. Ал микросервис жағдайында олармен қалай күресуге болады? Біздің ойымызша, ерік-жігерге емес, контейнерлердің мүмкіндіктеріне сүйенген дұрыс, , мен .
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 параметрі бар соңғы жол бар қосылымға қосымша басқа - екінші қосылымды құру әрекеті кезінде қосылымды ажырату керектігін білдіреді. Біздің контейнер баяу қызмет көрсетуді модельдейтіндіктен, мұндай жағдайлар мезгіл-мезгіл пайда болады, содан кейін Istio 503 қатесін қайтарады, бірақ қоршау мынаны көрсетеді:
Жарайды, бізде автоматты ажыратқыш бар, енді не болады?
Осылайша, біз қызметтердің бастапқы кодын мүлде қозғамай, автоматты түрде өшіруді жүзеге асырдық. Жоғарыда сипатталған автоматты ажыратқышты және пулды шығару процедурасын пайдалана отырып, біз тежегіш контейнерлерді қалыпты жағдайға оралғанша ресурс пулынан алып тастай аламыз және олардың күйін белгілі бір жиілікте тексере аламыз - біздің мысалда бұл екі минут (sleepWindow параметрі).
Қолданбаның 503 қатесіне жауап беру мүмкіндігі әлі де бастапқы код деңгейінде орнатылғанын ескеріңіз. Жағдайға байланысты Circuit Breaker пайдаланудың көптеген стратегиялары бар.
Келесі постта: Біз Istio-ға ендірілген немесе оңай қосылған бақылау және бақылау, сондай-ақ жүйеге қателерді әдейі енгізу жолы туралы сөйлесетін боламыз.
Ақпарат көзі: www.habr.com