Տոներն ավարտվեցին, և մենք վերադառնում ենք Istio Service Mesh շարքի մեր երկրորդ գրառումով:
Այսօրվա թեման Circuit Breaker-ն է, որը ռուսերենից թարգմանաբար նշանակում է «անջատիչ», ընդհանուր լեզվով ասած՝ «անջատիչ»: Միայն Istio-ում այս մեքենան անջատում է ոչ թե կարճացված կամ գերբեռնված միացում, այլ անսարք տարաներ:
Ինչպես դա պետք է իդեալական աշխատի
Երբ միկրոծառայությունները կառավարվում են Kubernetes-ի կողմից, օրինակ՝ OpenShift հարթակի շրջանակներում, դրանք ավտոմատ կերպով մեծանում են և նվազում՝ կախված ծանրաբեռնվածությունից: Քանի որ միկրոսերվիսներն աշխատում են պատիճներով, մեկ վերջնական կետում կարող են լինել կոնտեյներային միկրոծառայության մի քանի դեպքեր, և Kubernetes-ը կուղարկի հարցումները և բեռնում հավասարակշռությունը դրանց միջև: Եվ - իդեալական - այս ամենը պետք է կատարյալ աշխատի:
Մենք հիշում ենք, որ միկրոծառայությունները փոքր են և ժամանակավոր: Ժամանակավորությունը, որն այստեղ նշանակում է երեւալու ու անհետանալու հեշտություն, հաճախ թերագնահատվում է։ Միկրոծառայության մեկ այլ օրինակի ծնունդն ու մահը պատիճում միանգամայն սպասելի բաներ են, OpenShift-ը և Kubernetes-ը լավ են կառավարում դա, և ամեն ինչ հիանալի է աշխատում, բայց նորից տեսականորեն:
Ինչպես է այն իրականում աշխատում
Հիմա պատկերացրեք, որ միկրոսերվիսի կոնկրետ օրինակը, այսինքն՝ կոնտեյները, դարձել է անօգտագործելի՝ կա՛մ չի արձագանքում (սխալ 503), կա՛մ, որ ավելի տհաճ է, արձագանքում է, բայց շատ դանդաղ։ Այլ կերպ ասած, այն դառնում է փայլուն կամ չի արձագանքում հարցումներին, բայց ինքնաբերաբար չի հանվում լողավազանից: Ի՞նչ է պետք անել այս դեպքում: Կրկին փորձե՞լ: Պե՞տք է այն հանեմ երթուղային սխեմայից: Իսկ ի՞նչ է նշանակում «չափազանց դանդաղ». քանի՞սն է այն թվերով, և ո՞վ է դրանք որոշում: Միգուցե պարզապես դադար տալ և ավելի ուշ նորից փորձել: Եթե այո, ապա ինչքա՞ն հետո:
Ինչ է Pool Ejection-ը Իստիոյում
Եվ ահա Istio-ն օգնության է հասնում իր Circuit Breaker-ի պաշտպանության մեքենաներով, որոնք ժամանակավորապես հեռացնում են անսարք կոնտեյներները երթուղային և բեռը հավասարակշռող ռեսուրսների լողավազանից՝ իրականացնելով Pool Ejection ընթացակարգը:
Օգտվելով արտաքին հայտնաբերման ռազմավարությունից՝ Istio-ն հայտնաբերում է կորի պատյանները, որոնք դուրս են գծից և հեռացնում դրանք ռեսուրսների ֆոնդից որոշակի ժամանակով, որը կոչվում է քնի պատուհան:
Որպեսզի ցույց տանք, թե ինչպես է սա աշխատում Kubernetes-ում OpenShift հարթակում, եկեք սկսենք սովորական աշխատող միկրոծառայությունների սքրինշոթից՝ պահեստի օրինակից։ . Այստեղ մենք ունենք երկու պատիճ՝ 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 կոնտեյներ:
Խափանումը շտկելով
Այսպիսով, մենք ունենք անսարք կոնտեյներ, և ժամանակն է Pool Ejection-ի: Օգտագործելով շատ պարզ կոնֆիգուրգ, մենք 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-ը և Pool Ejection ընթացակարգը, որը նկարագրված է վերևում, մենք կարող ենք հեռացնել արգելակային բեռնարկղերը ռեսուրսների լողավազանից, մինչև նրանք վերադառնան նորմալ, և ստուգենք դրանց կարգավիճակը որոշակի հաճախականությամբ. մեր օրինակում սա երկու րոպե է (sleepWindow պարամետր):
Նկատի ունեցեք, որ 503 սխալին արձագանքելու հավելվածի կարողությունը դեռ սահմանված է սկզբնական կոդի մակարդակում: Անջատիչի օգտագործման բազմաթիվ ռազմավարություններ կան՝ կախված իրավիճակից:
Հաջորդ գրառման մեջ. Մենք կխոսենք Istio-ում արդեն ներկառուցված կամ հեշտությամբ ավելացված հետագծման և մոնիտորինգի մասին, ինչպես նաև այն մասին, թե ինչպես դիտավորյալ սխալներ մտցնել համակարգ:
Source: www.habr.com