Istio անջատիչ. անջատում է կոտրված բեռնարկղերը

Տոներն ավարտվեցին, և մենք վերադարձանք Istio Service Mesh շարքի մեր երկրորդ գրառմամբ։

Այսօրվա թեման է Circuit Breaker-ը, որը ռուսերեն էլեկտրատեխնիկայում նշանակում է «ավտոմատ անջատիչ», տարածված լեզվով՝ «պաշտպանիչ անջատիչ»։ Միայն Իստիոյում է, որ այս անջատիչը չի անջատում կարճ միացումը կամ գերբեռնվածությունը, այլ անջատում է անսարք տարաները։

Ինչպես պետք է այն իդեալականորեն աշխատի

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

Մենք հիշում ենք, որ միկրոսպասարկումները փոքր են և ժամանակավոր։ Անժամանակավորությունը, որն այստեղ նշանակում է առաջանալու և անհետանալու հեշտությունը, հաճախ թերագնահատվում է։ Մեկ այլ միկրոսերվիսային օրինակի ծնունդն ու մահը պոդում բավականին սպասելի բաներ են, OpenShift-ը և Kubernetes-ը լավ են հաղթահարում սա, և ամեն ինչ հիանալի է աշխատում, բայց կրկին՝ տեսականորեն։

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

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

Ի՞նչ է լողավազանի արտանետումը Իստիոյում

Ահա այստեղ է, որ Istio-ն օգնության է հասնում իր անջատիչներից պաշտպանող սարքերով, որոնք ժամանակավորապես հեռացնում են անսարք կոնտեյներները երթուղայնացման և բեռի հավասարակշռման ռեսուրսների լողավազանից՝ իրականացնելով Pool Ejection ընթացակարգը։

Օգտագործելով արտառոց երևույթների հայտնաբերման ռազմավարություն՝ Istio-ն հայտնաբերում է այն պոդերը, որոնք չեն համընկնում մնացած պոդերի հետ և հեռացնում դրանք ռեսուրսների ֆոնդից որոշակի ժամանակահատվածով, որը կոչվում է քնի պատուհան։

Ցույց տալու համար, թե ինչպես է սա աշխատում Kubernetes-ում OpenShift հարթակում, եկեք սկսենք պահոցում օրինակից միկրոսերվիսների սովորական ռեժիմով աշխատող էկրանի նկարով։ Red Hat մշակողների դեմոներ. Այստեղ մենք ունենք երկու պոդ՝ v1 և v2, որոնցից յուրաքանչյուրն աշխատում է մեկ կոնտեյներով։ Երբ Istio երթուղայնացման կանոնները չեն օգտագործվում, Kubernetes-ը լռելյայնորեն օգտագործում է միատեսակ հավասարակշռված շրջանաձև երթուղայնացում։

Պատրաստվելով ձախողմանը

Pool Ejection-ը կատարելուց առաջ անհրաժեշտ է ստեղծել Istio routing կանոն։ Ենթադրենք, որ մենք ուզում ենք հարցումները բաշխել պոդերի միջև 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-ի մոնիթորինգի հնարավորությունների հետ, թույլ է տալիս սկսել կառուցել մի շրջանակ՝ անսարք կոնտեյներները ավտոմատ կերպով փոխարինելու համար՝ անսարքությունները և խափանումները կրճատելու կամ վերացնելու համար։
 
ՆԱՍԱ-ն ունի մեկ բարձր կարգախոս՝ «Ձախողումը տարբերակ չէ», որի հեղինակը, ենթադրաբար, թռիչքի տնօրենն է։ Ջին Կրանց. Ռուսերենում այն ​​կարելի է թարգմանել որպես «Ձախողումը տարբերակ չէ», և այստեղ իմաստն այն է, որ ամեն ինչ կարելի է աշխատեցնել, եթե բավարար կամքի ուժ ունես։ Սակայն իրական կյանքում անհաջողությունները ոչ միայն տեղի են ունենում, այլև անխուսափելի են՝ ամենուր և ամեն ինչում։ Այսպիսով, ինչպե՞ս ենք մենք դրանց հետ գործ ունենում միկրոծառայությունների դեպքում։ Մեր կարծիքով, ավելի լավ է հույսը դնել ոչ թե կամքի ուժի, այլ տարաների հնարավորությունների վրա, Կուբերնետես, Red Hat OpenShift- ըԻսկ Իստիո.

Իստիոն, ինչպես գրել ենք վերևում, իրականացնում է անջատիչների հայեցակարգը, որը լավ է ապացուցել իրեն ֆիզիկական աշխարհում: Եվ ինչպես էլեկտրական անջատիչը անջատում է շղթայի խնդրահարույց հատվածը, այնպես էլ 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 սխալ, և ահա թե ինչ կցուցադրի siege-ը.

Լավ, մենք ունենք անջատիչ, ի՞նչ է հաջորդը։

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

Նկատի ունեցեք, որ ծրագրի 503 սխալին արձագանքելու ունակությունը դեռևս սահմանվում է դրա սկզբնական կոդի մակարդակով։ Կան անջատիչի հետ գործ ունենալու բազմաթիվ ռազմավարություններ, որոնք կարող են օգտագործվել՝ կախված իրավիճակից:

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

Source: www.habr.com