Istio Circuit Breaker: անջատում ենք неисправные контейներ

Ամառային տոները ավարտվեցին, և մենք վերադառնում ենք մեր երկրորդ գրառմամբ Istio Service Mesh-এর շարքում:

Այսօր քննարկում ենք Circuit Breaker-ը, որը ռուսերենում նշանակում է «ավտոմատ բացվող համակարգ», հասարակական լեզվով՝ «պաշտպանության ավտոմատ»: Սակայն Istio-ում այդ ավտոմատը անջատում է ոչ թե կարճ միացում կամ overloaded ցանց, այլ վնասված կոնտեյներներ:

Ինչպես պետք է աշխատի իդեալում

Երբ միկրոցանցերը կառավարվում են Kubernetes-ով, օրինակ՝ OpenShift հարթակում, դրանք ավտոմատ կերպով ընդլայնվում կամ փոքրանում են բեռի վրա հիմնված: Քանի որ միկրոցանցերը աշխատում են pod-երում, մեկ վերջնակետում կարող է լինել մի քանի կոնտեյներիզացված միկրոցանցների օրինակ, իսկ Kubernetes-ն ուղղորդում է հարցումները և բաշխում բեռը նրանց միջև: Եվ իդեալում՝ ամեն ինչ պետք է լավ աշխատի:

Հիշում ենք, որ միկրոցանցերը փոքր են և եթերային: Եթերայնությունը, որը այստեղ նշանակում է կարճաժամկետ ստեղծումը և անհետացումը, հաճախ undervalued է: Մարակում և մահանում է հերթական միկրոցանցի օրինակ pod-ում, այնքան ակնկալելի, որ OpenShift-ն ու Kubernetes-ն այն լավ են կառավարում, և ամեն ինչ լավ աշխատում է՝ սակայն ՝ միայն տեսաբար:

Ինչպե՞ս դա աշխատում է իրականում

Հիմա պատկերացրեք, որ ինչ-որ կոնկրետ միկրոցանցի օրինակ, որ արտահայտվում է կոնտեյներով, դարձել է անկարող: Կամ չի արձագանքում (503 սխալ), կամ, ինչը ավելի անհարմար է, արձագանքում է, բայց շատ դանդաղ: Այլ կերպ ասած, նա կանգառում է կամ չի արձանագում հարցումներին, բայց դեռևս ավտոմատ կերպով չի հեռացվում ռեսուրսների պուլից: Ինչ պետք է անել այս դեպքում? Կրկին փորձել? Հեռացնել այն երթուղայնացման սխեմայից? Նույնիսկ ի՞նչ է նշանակում «շատ դանդաղ»՝ ինչ թվերով, և ով ունի դրանք որոշելու իրավունքը: Գուցե պարզապես տալ նրա հանգիստը և փորձել ավելի ուշ?:

Ինչ է իհարկե Pool Ejection-ը Istio-ում

Եվ այստեղ օգնության է եկել Istio իր Circuit Breaker պաշտպանության ավտոմատներով, որոնք զգալիորեն հեռացնում են վնասված կոնտեյները ռեսուրսների երթուղայնացման և բաշխման համակարգից, իրականացնելով Pool Ejection ընթացակարգը:

Օգտվելով չսահմանափակվող պատկերի բացահայտման ռազմավարությունից (outlier detection), Istio իդենտիֆիկացնում է անկյունային pod-երը, որոնք դուրս են գալիս ընդհանուր շարքից, և հեռացնում նրանց ռեսուրսների պուլից որոշված ժամանակահատվածի համար, որը կոչվում է «քնի պատուհան» (sleep window):

Բերելով, թե ինչպես դա աշխատում է Kubernetes-ում OpenShift հարթակում, սկսենք այդտեղից, որտեղ նորմալ աշխատող միկրոցանցերի լուսանկարն է, որը գտնվում է օրինակներում: Red Hat Developer Demos. Այստեղ ունենք երկու pod՝ v1 և v2, որոնց յուրաքանչյուրում աշխատում է մեկ կոնտեյներ: Երբ Istio-ның երթուղային կանոնները չեն օգտագործվում, Kubernetes-ը այդ դեպքում կիրառեց հավասարաչափ բաշխված շրջանային երթուղային համակարգ:

Պատրաստվում ենք անհաջողություններին

Pool Ejection անելիս, նախ անհրաժեշտ է ստեղծել Istio-ի ուղղորդման կանոն։ Աrekզի, մենք ուզում ենք բաժանել հարցումները pod-երի միջև 50/50 հարաբերակցությամբ։ Պարզապես, մենք երկու կրկնակներով կավելացնենք v2 կոնտեյները, հետևյալ կերպ:

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

Այժմ որոշենք ուղղորդման կանոնը, որպեսզի երթևեկությունը բաժանվի pod-երի միջև 50/50 հարաբերակցությամբ:

Ստորև ներկայացված է, թե ինչպես է այս կանոնի աշխատանքը.

Կես տալ, որ այս նկարում չկա 50/50, այլ 14:9, սակայն ժամանակի ընթացքում իրավիճակը կշտկվի.

Ստեղծենք խափանում

Երթևեկություն խափանումներից մեկը v2-ից դուրս կհանի, որպեսզի մեզ մնար մեկ աշխատող v1 կոնտեյներ, մեկ աշխատող v2, և մեկ չաշխատող v2:

Ավեսման խափանումը

Այսպիսով, لدينا لدينا один неисправный контейнер, и время пришло для Pool Ejection. С помощью очень простого конфига мы исключим этот сбойный контейнер из любых схем маршрутизации на 15 секунд в расчете на то, что он сам вернется в исправное состояние (либо перезапустится, либо восстановит производительность). Вот как выглядит этот конфиг и результаты его работы:

Как видно, неисправный контейнер v2 больше не используется при маршрутизации запросов, поскольку его убрали из пула. Но по истечении 15 секунд он автоматически вернется в пул. Собственно, мы только что показали, как работает Pool Ejection.

Եկեք սկսենք կառուցել ճարտարապետությունը

Pool Ejection-ը և Istio-ի մշտադիտարկման հնարավորությունները հնարավորություն են տալիս սկսել ավտոմատ փոխարինման շրջանակի կառուցումը, որպեսզի նվազեցնել, նույնիսկ հնարավորինս վերացնել դադարներն ու խափանումները:
 
NASA-ն ունի մեկը նախաստիճան կարգախոս՝ Failure Is Not an Option, հեղինակությունով, ում համար պատասխանատու է Ջին Կրանց. Ռուսերեն կարելի է բնօրինակը թարգմանել որպես «Հաջողությունը՝ ոչ տարբերակ», և այստեղից բխում է, որ ամեն ինչ կարող է աշխատել, եթե բավարար կամք ունես դա անել։ Սակայն իրական կյանքում անխուսափելի են խափանումները և դրանք բոլոր տեղերում ու ամեն ինչում տեղի են ունենում։ Ինչպես պետք է վարվել նախարարական կետերի դեպքում։ Մեր կարծիքով, ավելի լավ է հույսը դնել կոնտեյների հնարավորությունների վրա, Kubernetes, Red Hat OpenShift, և Istio.

Ինչպես արդեն նշվել է, Istio-ն իրական աշխարհում վաղուց հաստատված ինքնաբերական անջատիչների գաղափարը կյանքի է կոչում։ Ինչպես էլեկտրական ավտոմատը հանում է խնդիրով հատվածը, այնպես էլ ծրագրային Circuit Breaker-ը Istio-ում բացում է կապը հարցումների հոսքի և խնդրահարույց կոնտեյների միջև, երբ վերջնական կետում ինչ-որ բան խանգարում է, օրինակ, երբ սերվերը ընկնում կամ սկսում է դանդաղել։

Երկրորդ դեպքում խնդիրները միայն ավելանում են, քանի որ մեկ կոնտեյների դանդաղացումը ոչ միայն առաջացնում է հետխաղաղություն ծառայություններին, որոնք դիմում են նրան, և, հետևաբար, նվազեցնում են համակարգի ընդհանուր արտադրողականությունը, այլ նաև առաջացնում է հետագա հավաքագրումներ արդեն դանդաղ աշխատող ծառայությանը, ինչը միայն վատացնում է իրավիճակը.

Circuit Breaker տեսության մեջ

Circuit Breaker-ը պրոքսի է, որը վերահսկում է վերջակետին հոսքը դեպի запросները: Երբ այդ կետն ասում է դադարեցնել աշխատանքը կամ, կախված սահմանված կարգավորումներից, սկսում է դանդաղել, պրոքսին կտրվածք է անում կոնտեյների հետ: Հոսքը դրանից հետո redirects-վում է այլ կոնտեյներների, պարզապես բեռի հավասարակշռության պատճառով: Կապը մնում է բաց (open) սահմանված քնած պատուհանի ընթացքում, ասենք՝ երկու րոպե, այնուհետև համարվում է կես-բաց (half-open): Սպասարկմանը հաջորդ запросի փորձը որոշում է կապի հետագա վիճակը: Եթե ծառայության հետ ամեն բան կարգին է, կապը վերադառնում է աշխատանքային վիճակին և կրկին դառնում է փակ (closed): Եթե же ծառայության հետ դեռևս ինչ-որ բան սխալ է, կապը կրկին բացվում է և՝ նորից ակտիվանում է քնած պատուհանը: Ահա թե ինչպես է թվում Circuit Breaker-ի խմբագրված վիճակների դիագրամը:

Այստեղ կարևոր է նշել, որ սա տեղի է ունենում համակարգային արխիտեկտուրայի մակարդակում: Հետևաբար, մի պահ ձեզ հարկավոր է դասավանդել ձեր դիմումներին աշխատել Circuit Breaker-ի հետ, օրինակ, մատակարարել պատասխանով նախնական արժեք կամ, եթե հնարավոր է,.ignore անել ծառայության առկայությունը: Bunun üçün bulkhead pattern istifadə edilir, amma bu məqalənin çərçivəsindən kənardadır.

Circuit Breaker պրակտիկայում

Օրինակ, մենք OpenShift-ում կսկսենք մեր առաջարկների միկրոսերվիսի երկու տարբերակները: 1-ին տարբերակը կարգին կաշխատի, իսկ v2-ում մենք ներառենք ուշացում, որպեսզի պատկղարզենք սերվերի դանդաղեցումները: Հնարավրված արդյունքները դիտելու համար օգտագործվում է գործիք siege:

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

Ամեն բան երևում է, որ գործում է, բայց ինչ գնով? Առաջին հայացքից ունենք 100 % հասանելիություն, բայց ուշադիր նայեք՝ գործարքի առավելագույն տևողությունն կազմում է целых 12 վարկյան: Սա ակնհայտ նեղ կայանք է, և այն պետք է լայնանալ:

Այ bunun համեմատ با Istio-er excluidas slow containers-ին դիմում՝ օգտագործելով Circuit Breaker: Ահա թե ինչպես է ցուցադրվում համապատասխան կոնֆիգյուրը:

Վերջին տողը httpMaxRequestsPerConnection պարամետրով ազդանշում է, որ կապը պետք է բացվի, երբ փորձ է արվում ստեղծել մեկ այլ՝ երկրորդ կապ ավելացնելով արդեն առկաին: Որպեսզի մեր կոնտեյները մոդելավորի դանդաղեցնող ծառայությունը՝ նման իրավիճակները երբեմն կլինեն առաջ, և այդ ժամանակ Istio-ն կվերադարձնի 503 սխալ, իսկ ինչ ցույց կտա siege:

ՕK, մենք ունենք Circuit Breaker, ինչ անել հիմա?

Այդպես, մենք իրականացրել ենք ավտոմատ անջատում, ընդհանրապես չպոպոխելով ծառայությունների սկզբնական կոդը: Օգտագործելով Circuit Breaker և վերոնշյալ Pool Ejection ընթացակարգը, մենք կարող ենք հեռացնել ռեսուրսների պուլից դանդաղեցնող կոնտեյներն այնքան ժամանակ, մինչև դրանք վերադառնան նորմալ վիճակի, ինչպես նաև ստուգել նրանց վիճակը ճիշտ ժամանակահատվածով՝ մեր օրինակով՝ երկու րոպե (sleepWindow պարամետր):

Խնդրում ենք ուշադրություն դարձնել, որ ծրագր application's-ի 503 սխալին արձագանքելու ունակությունը դեռևս սահմանվում է նրա սկզբնական կոդի մակարդակում: Post Circuit Breaker-ների կիրառման շատ ռազմավարություններ կան, որոնք կիրառում են մասնավորապես իրավիճակին համապատասխան:

Հաջորդ հրապարակմանը: կհայտնենք մտահղացումի և մոնիտորինգի մասին, որոնք արդեն տեղադրված են կամ հեշտությամբ ավելացվում են Istio-ում, ինչպես նաև այն մասին, թե ինչպես կարելի է սխալներ մտցնել համակարգ:

Ընտանիք: habr.com