Майрамдар аяктады жана биз Istio Service Mesh сериясындагы экинчи постубуз менен кайтып келдик.
Бүгүнкү тема Circuit Breaker болуп саналат, ал орус электр инженериясына которгондо "схема өчүргүч" дегенди билдирет, жалпы тил менен айтканда - "схема өчүргүч". Истиодо гана бул машина кыска ту-шулган же ашыкча жуктелген чынжырды ажыратпай, бузулган контейнерлерди.
Бул кандайча идеалдуу иштеши керек
Микросервистерди Kubernetes башкарганда, мисалы, OpenShift платформасында, алар жүктөмгө жараша автоматтык түрдө чоңойт жана кичирейт. Микросервистер поддондордо иштегендиктен, бир акыркы чекитте контейнерлештирилген микросервистин бир нече учурлары болушу мүмкүн жана Kubernetes сурамдарды багыттап, алардын ортосундагы жүк балансын түзөт. Жана - идеалдуу - мунун баары кемчиликсиз иштеши керек.
Микросервистер кичинекей жана убактылуу экенин эстейбиз. Бул жерде пайда болуу жана жок болуу жеңилдигин билдирген эфемердүүлүккө көп учурда баа берилбейт. Подгондогу микросервистин башка инстанциясынын төрөлүшү жана өлүмү күтүлгөн нерсе, OpenShift жана Kubernetes муну жакшы чечет жана баары сонун иштейт - бирок теорияда дагы.
Бул иш жүзүндө кантип иштейт
Эми микросервистин белгилүү бир инстанциясы, башкача айтканда, контейнер жараксыз болуп калганын элестетиңиз: же ал жооп бербейт (ката 503), же эң жагымсызы, ал жооп берет, бирок өтө жай. Башкача айтканда, ал бузулуп калат же суроо-талаптарга жооп бербейт, бирок ал автоматтык түрдө бассейнден чыгарылбайт. Бул учурда эмне кылуу керек? Кайра аракет кылуу үчүнбү? Мен аны маршруттук схемадан алып салышым керекпи? Ал эми "өтө жай" деген эмнени билдирет - бул сандарда канча жана аларды ким аныктайт? Балким, жөн эле тыныгуу берип, кийинчерээк кайра аракет кылыңыз? Эгер ошондой болсо, канчадан кийин?
Istioдагы Pool Ejection деген эмне
Жана бул жерде Istio жардамга өзүнүн Circuit Breaker коргоо машиналары менен келет, алар туура эмес контейнерлерди маршрутташтыруу жана жүктү теңдөөчү ресурс пулунан убактылуу алып салышат, Pool Ejection процедурасын ишке ашырышат.
Чектөөлөрдү аныктоо стратегиясын колдонуп, 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'нун мониторинг мүмкүнчүлүктөрү менен айкалышып, иштебей калууларды жана бузулууларды жок кылбаса, кыскартуу үчүн, бузулган контейнерлерди автоматтык түрдө алмаштыруу үчүн негиз түзө баштоого мүмкүндүк берет.
НАСАнын бир катуу урааны бар - Ийгилик эмес, бул вариант, анын автору учуу директору болуп эсептелет. . Аны орусчага “Ийгилик эмес вариант” деп которсо болот жана бул жерде эрк жетиштүү болсо, бардыгын ишке ашырууга болот дегенди билдирет. Бирок, чыныгы жашоодо, ийгиликсиздиктер жөн эле боло бербейт, алар сөзсүз түрдө, бардык жерде жана бардык нерседе болот. Ал эми микросервистерде алар менен кантип күрөшүү керек? Биздин оюбузча, эркке эмес, контейнерлердин мүмкүнчүлүктөрүнө таянуу жакшы, , жана .
Istio, биз жогоруда жазгандай, физикалык дүйнөдө өзүн жакшы далилдеген автоматтык өчүргүчтөр концепциясын ишке ашырат. Жана электрдик өчүргүч чынжырдын көйгөйлүү бөлүгүн өчүргөндөй эле, Istio программасынын Circuit Breaker акыркы чекитте бир нерсе туура эмес болгондо, мисалы, сервер кыйрап же иштей баштаганда, суроо-талаптардын агымы менен көйгөйлүү контейнердин ортосундагы байланышты ачат. жайла.
Андан тышкары, экинчи учурда дагы көйгөйлөр бар, анткени бир контейнердин тормоздору ага жетүү кызматтарынын кечигүү каскадын гана жаратпастан, бүтүндөй системанын иштешин төмөндөтөт, ошондой эле кайра-кайра пайда болот. жай иштеп жаткан кызматка суроо-талаптар, бул абалды гана курчутат.
Теорияда автоматтык өчүргүч
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 катасын кайтарат, бирок курчоо муну көрсөтөт:
Макул, бизде Circuit Breaker бар, андан ары эмне болот?
Ошентип, биз кызматтардын баштапкы кодуна такыр тийбей туруп, автоматтык түрдө өчүрүүнү ишке ашырдык. Жогоруда сүрөттөлгөн Circuit Breaker жана Pool Ejection процедурасын колдонуу менен, биз тормоздук контейнерлерди алар нормалдуу абалга кайтканга чейин ресурстук бассейнден чыгарып, алардын абалын белгиленген жыштыкта текшере алабыз - биздин мисалда бул эки мүнөт (sleepWindow параметри).
Колдонмонун 503 катасына жооп берүү жөндөмү дагы эле баштапкы код деңгээлинде коюлганын эске алыңыз. Кырдаалга жараша Circuit Breakerди колдонуунун көптөгөн стратегиялары бар.
Кийинки постто: Биз Istio'го мурунтан эле орнотулган же оңой кошулган байкоо жана мониторинг, ошондой эле системага каталарды кантип атайылап киргизүү керектиги жөнүндө сүйлөшөбүз.
Source: www.habr.com