Kubernetes աշխատող հանգույցներ. շատ փոքր, թե մի քանի խոշոր:

Kubernetes կլաստերի ստեղծման ժամանակ կարող են հարցեր առաջանալ՝ քանի՞ աշխատող հանգույց պետք է կազմաձևել և ինչ տեսակի: Ի՞նչն է ավելի լավ ներկառուցված կլաստերի համար. գնել մի քանի հզոր սերվեր կամ օգտագործել մեկ տասնյակ հին մեքենաներ ձեր տվյալների կենտրոնում: Արդյո՞ք ավելի լավ է ամպի մեջ վերցնել ութ միամիջուկ կամ երկու քառամիջուկ օրինակ:

Այս հարցերի պատասխանները՝ հոդվածում։ Դանիել Վեյբել, ծրագրային ապահովման ինժեներ և Learnk8s կրթական նախագծի ուսուցիչ հրամանի թարգմանության մեջ Kubernetes aaS Mail.ru-ից.

Կլաստերի հզորությունը

Ընդհանուր առմամբ, Kubernetes կլաստերը կարելի է համարել մեծ «գերհանգույց»: Նրա ընդհանուր հաշվողական հզորությունը նրա բոլոր բաղկացուցիչ հանգույցների հզորությունների գումարն է։

Գոյություն ունեն մի քանի եղանակներ՝ հասնելու ձեր ցանկալի կլաստերի հզորության թիրախին: Օրինակ, մեզ անհրաժեշտ է 8 պրոցեսորային միջուկ ընդհանուր հզորությամբ կլաստեր և 32 ԳԲ օպերատիվ հիշողություն, քանի որ մի շարք հավելվածներ պահանջում են շատ ռեսուրսներ: Այնուհետև կարող եք տեղադրել երկու հանգույց՝ 16 ԳԲ հիշողությամբ կամ չորս հանգույց՝ 8 ԳԲ հիշողությամբ, երկու քառամիջուկ պրոցեսոր կամ չորս երկմիջուկ:

Ահա կլաստեր ստեղծելու ընդամենը երկու հնարավոր եղանակ.

Երկու տարբերակներն էլ արտադրում են նույն հզորությամբ կլաստեր, սակայն ներքևի կոնֆիգուրացիան ունի չորս փոքր հանգույց, իսկ վերին կազմաձևը՝ երկու ավելի մեծ հանգույց:

Ո՞ր տարբերակն է ավելի լավ:

Այս հարցին պատասխանելու համար եկեք դիտարկենք երկու տարբերակների առավելությունները: Մենք դրանք ամփոփել ենք աղյուսակում։

Մի քանի խոշոր հանգույցներ

Շատ փոքր հանգույցներ

Կլաստերների ավելի հեշտ կառավարում (եթե դա ներկառուցված է)

Սահուն ավտոմատ մասշտաբավորում

Ավելի էժան (եթե տեղում է)

Գինը մի փոքր տարբերվում է (ամպի մեջ)

Կարող է գործարկել ռեսուրսների ինտենսիվ ծրագրեր

Ամբողջական կրկնօրինակում

Ռեսուրսներն ավելի արդյունավետ են օգտագործվում (ավելի քիչ գերավճար համակարգի դևերի վրա):
Կլաստերային սխալների ավելի բարձր հանդուրժողականություն

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

Այսպիսով, եկեք ավելի մանրամասն քննարկենք աղյուսակի յուրաքանչյուր կետ:

Առաջին տարբերակը մի քանի խոշոր հանգույցներ

Ամենածայրահեղ տարբերակը մեկ աշխատող հանգույց է ամբողջ կլաստերի հզորության համար: Վերոնշյալ օրինակում սա կլինի մեկ աշխատող հանգույց՝ 16 պրոցեսորի միջուկով և 16 ԳԲ օպերատիվ հիշողությամբ:

Կոալիցիայում

Plus No 1. Ավելի հեշտ կառավարում
Ավելի հեշտ է կառավարել մի քանի մեքենաներ, քան մի ամբողջ նավատորմ: Թարմացումներն ու շտկումներն ավելի արագ են տարածվում, և ավելի հեշտ է համաժամացումը: Բացարձակ թվերով խափանումների թիվը նույնպես քիչ է։

Խնդրում ենք նկատի ունենալ, որ վերը նշված բոլորը վերաբերում են ձեր սարքաշարին, ձեր սերվերներին և ոչ թե ամպային օրինակներին:

Իրավիճակն այլ է ամպի մեջ. Այնտեղ կառավարումը վարում է ամպային ծառայության մատակարարը: Այսպիսով, ամպի մեջ տասը հանգույցների կառավարումը շատ չի տարբերվում մեկ հանգույցի կառավարումից:

Երթևեկության երթուղի և բեռի բաշխում ամպի մեջ գտնվող պատյանների միջև կատարվում է ավտոմատ կերպովԻնտերնետից եկող տրաֆիկը ուղարկվում է հիմնական բեռի հավասարակշռողին, որը փոխանցում է երթևեկությունը հանգույցներից մեկի նավահանգիստ (NodePort ծառայությունը սահմանում է նավահանգիստը 30000-32767 միջակայքում յուրաքանչյուր կլաստերային հանգույցում): Kube-proxy-ի կողմից սահմանված կանոնները վերահղում են երթևեկությունը հանգույցից դեպի pod: Ահա թե ինչ տեսք ունի երկու հանգույցների վրա տասը պատիճ.

Pro #2: Ավելի քիչ ծախսեր մեկ հանգույցի համար
Հզոր մեքենան ավելի թանկ է, բայց թանկացումը պարտադիր չէ, որ գծային լինի։ Այլ կերպ ասած, 10 ԳԲ հիշողությամբ մեկ տասը միջուկային սերվերը սովորաբար ավելի էժան է, քան նույն քանակությամբ հիշողությամբ տասը միամիջուկ սերվեր:

Բայց նկատի ունեցեք, որ այս կանոնը սովորաբար չի գործում ամպային ծառայություններում: Բոլոր հիմնական ամպային մատակարարների ընթացիկ գնագոյացման սխեմաներում գները աճում են գծային՝ հզորությամբ:

Այսպիսով, ամպի մեջ դուք սովորաբար չեք կարող խնայել ավելի հզոր սերվերների վրա:

Pro #3. Դուք կարող եք գործարկել ռեսուրսներ պահանջող ծրագրեր
Որոշ հավելվածներ պահանջում են հզոր սերվերներ կլաստերի մեջ: Օրինակ, եթե մեքենայական ուսուցման համակարգը պահանջում է 8 ԳԲ հիշողություն, դուք չեք կարողանա այն գործարկել 1 ԳԲ հանգույցների վրա, այլ միայն առնվազն մեկ խոշոր աշխատող հանգույցով:

Դեմ

Թերություն թիվ 1. Մեկ հանգույցի համար շատ պատիճներ
Եթե ​​նույն առաջադրանքը կատարվի ավելի քիչ հանգույցների վրա, ապա նրանցից յուրաքանչյուրը բնականաբար կունենա ավելի շատ բլոկներ:

Սա կարող է խնդիր լինել:

Պատճառն այն է, որ յուրաքանչյուր մոդուլ ներկայացնում է որոշակի գերավճար կոնտեյների գործարկման ժամանակին (օրինակ՝ Docker), ինչպես նաև kubelet-ին և cAdvisor-ին:

Օրինակ, կուբելետը կանոնավոր կերպով հետազոտում է հանգույցի վրա գտնվող բոլոր բեռնարկղերը՝ գոյատևելու համար. որքան շատ բեռնարկղեր, այնքան ավելի շատ աշխատանք պետք է կատարի կուբելետը:

CAdvisor-ը հավաքում է ռեսուրսների օգտագործման վիճակագրությունը հանգույցի վրա գտնվող բոլոր բեռնարկղերի համար, և kubelet-ը պարբերաբար հարցում է անում այս տեղեկատվությունը և տրամադրում այն ​​API-ի միջոցով: Կրկին, ավելի շատ բեռնարկղեր նշանակում է ավելի շատ աշխատանք ինչպես cAdvisor-ի, այնպես էլ kubelet-ի համար:

Եթե ​​մոդուլների քանակն ավելանա, դա կարող է դանդաղեցնել համակարգը և նույնիսկ խաթարել դրա հուսալիությունը:

Kubernetes-ի պահոցում որոշ բողոքել էոր հանգույցները ցատկում են Ready/NotReady կարգավիճակների միջև, քանի որ հանգույցի վրա գտնվող բոլոր բեռնարկղերի կանոնավոր kubelet ստուգումները չափազանց երկար են տևում:
Այս պատճառով Kubernetes խորհուրդ է տալիս տեղադրել ոչ ավելի, քան 110 պատիճ յուրաքանչյուր հանգույցում. Կախված հանգույցի կատարողականից, դուք կարող եք ավելի շատ բլոկներ գործարկել մեկ հանգույցում, բայց դժվար է կանխատեսել՝ խնդիրներ կլինեն, թե ամեն ինչ լավ կաշխատի: Արժե աշխատանքը նախապես փորձարկել։

Թերություն թիվ 2. Վերարտադրման սահմանափակում
Չափազանց քիչ հանգույցներ սահմանափակում են հավելվածի վերարտադրության արդյունավետ չափը: Օրինակ, եթե դուք ունեք բարձր հասանելիության ծրագիր հինգ կրկնօրինակներով, բայց միայն երկու հանգույցով, ապա հավելվածի արդյունավետ կրկնօրինակման աստիճանը կրճատվում է երկուսի:

Հինգ կրկնօրինակներ կարող են բաշխվել միայն երկու հանգույցների վրա, և եթե դրանցից մեկը ձախողվի, այն միանգամից կվերացնի մի քանի կրկնօրինակներ:

Եթե ​​ունեք հինգ կամ ավելի հանգույց, յուրաքանչյուր կրկնօրինակ կաշխատի առանձին հանգույցի վրա, և մեկ հանգույցի ձախողումը կհեռացնի առավելագույնը մեկ կրկնօրինակ:

Այսպիսով, մատչելիության բարձր պահանջները կարող են պահանջել կլաստերի որոշակի նվազագույն թվով հանգույցներ:

Թերություն թիվ 3. Անհաջողության ավելի վատ հետեւանքները
Փոքր քանակությամբ հանգույցների դեպքում յուրաքանչյուր ձախողում ավելի լուրջ հետևանքներ է ունենում: Օրինակ, եթե դուք ունեք ընդամենը երկու հանգույց, և դրանցից մեկը ձախողվում է, ձեր մոդուլների կեսը անմիջապես անհետանում է:

Իհարկե, Kubernetes-ը կտեղափոխի ծանրաբեռնվածությունը ձախողված հանգույցից մյուսներին: Բայց եթե դրանք քիչ են, ապա կարող է բավարար ազատ հզորություն չլինել: Արդյունքում, ձեր որոշ հավելվածներ անհասանելի կլինեն, մինչև չհայտնեք ձախողված հանգույցը:

Այսպիսով, որքան շատ հանգույցներ, այնքան քիչ է ապարատային խափանումների ազդեցությունը:

Թերություն # 4. ավելի շատ ավտոմատ մասշտաբավորման քայլեր
Kubernetes-ն ունի ամպային ենթակառուցվածքի կլաստերի ավտոմատ մասշտաբավորման համակարգ, որը թույլ է տալիս ավտոմատ կերպով ավելացնել կամ հեռացնել հանգույցներ՝ կախված ձեր ընթացիկ կարիքներից: Ավելի մեծ հանգույցների դեպքում ավտոմատ մասշտաբը դառնում է ավելի կտրուկ և կոպիտ: Օրինակ, երկու հանգույցների վրա հավելյալ հանգույց ավելացնելը անմիջապես կբարձրացնի կլաստերի հզորությունը 50%-ով։ Եվ դուք ստիպված կլինեք վճարել այդ ռեսուրսների համար, նույնիսկ եթե դրանք ձեզ հարկավոր չեն:

Այսպիսով, եթե դուք նախատեսում եք օգտագործել ավտոմատ կլաստերային մասշտաբավորում, որքան փոքր են հանգույցները, այնքան ավելի ճկուն և ծախսարդյունավետ մասշտաբներ կստանաք:

Այժմ եկեք տեսնենք մեծ թվով փոքր հանգույցների առավելություններն ու թերությունները:

Երկրորդ տարբերակը `շատ փոքր հանգույցներ

Այս մոտեցման առավելությունները, ըստ էության, բխում են մի քանի խոշոր հանգույցներով հակառակ տարբերակի թերություններից:

Կոալիցիայում

Pro #1. ձախողման ավելի քիչ ազդեցություն
Որքան շատ հանգույցներ, այնքան քիչ պատիճներ յուրաքանչյուր հանգույցի վրա: Օրինակ, եթե դուք ունեք հարյուր մոդուլ տասը հանգույցից, ապա յուրաքանչյուր հանգույց կունենա միջինը տասը մոդուլ:

Այս կերպ, եթե հանգույցներից մեկը ձախողվի, դուք կորցնում եք ծանրաբեռնվածության միայն 10%-ը: Հավանականությունը մեծ է, որ կրկնօրինակների միայն փոքր մասը կազդի, և ընդհանուր հավելվածը կմնա գործող:

Բացի այդ, մնացած հանգույցները, հավանաբար, կունենան բավականաչափ ազատ ռեսուրսներ՝ ձախողված հանգույցի ծանրաբեռնվածությունը կարգավորելու համար, այնպես որ Kubernetes-ը կարող է ազատորեն վերադասավորել բլոկները, և ձեր հավելվածները համեմատաբար արագ կվերադառնան ֆունկցիոնալ վիճակի:

Pro #2: Լավ կրկնօրինակում
Եթե ​​կան բավարար հանգույցներ, Kubernetes ժամանակացույցը կարող է տարբեր հանգույցներ վերագրել բոլոր կրկնօրինակներին: Այս կերպ, եթե հանգույցը ձախողվի, կազդի միայն մեկ կրկնօրինակը, և հավելվածը կմնա հասանելի:

Դեմ

Թերություն թիվ 1. Դժվար է վերահսկել
Մեծ թվով հանգույցների կառավարումն ավելի դժվար է: Օրինակ, Kubernetes-ի յուրաքանչյուր հանգույց պետք է շփվի բոլոր մյուսների հետ, այսինքն՝ կապերի թիվը քառակուսի աճում է, և այդ բոլոր կապերը պետք է հետևել:

Kubernetes Controller Manager-ի հանգույցների կարգավորիչը կանոնավոր կերպով քայլում է կլաստերի բոլոր հանգույցները՝ ստուգելու առողջությունը. որքան շատ հանգույցներ, այնքան ավելի շատ բեռնվածություն վերահսկիչի վրա:

Բեռը etcd տվյալների բազայի վրա նույնպես աճում է՝ յուրաքանչյուր kubelet և kube-proxy զանգեր դիտող etcd-ի համար (API-ի միջոցով), որին etcd-ը պետք է հեռարձակի օբյեկտների թարմացումները:

Ընդհանուր առմամբ, յուրաքանչյուր աշխատող հանգույց լրացուցիչ բեռ է դնում հիմնական հանգույցների համակարգի բաղադրիչների վրա:

Kubernetes-ը պաշտոնապես աջակցում է կլաստերների հետ հանգույցների թիվը մինչև 5000. Այնուամենայնիվ, գործնականում արդեն կա 500 հանգույց կարող է առաջացնել ոչ աննշան խնդիրներ.

Մեծ թվով աշխատող հանգույցներ կառավարելու համար դուք պետք է ընտրեք ավելի հզոր հիմնական հանգույցներ: Օրինակ, kube-up ինքնաբերաբար տեղադրվում է ճիշտ VM չափը հիմնական հանգույցի համար՝ կախված աշխատող հանգույցների քանակից: Այսինքն, որքան շատ աշխատող հանգույցներ, այնքան ավելի արդյունավետ պետք է լինեն վարպետ հանգույցները:

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

Թերություն # 2. Ավելի մեծ ծախսեր:
Յուրաքանչյուր աշխատող հանգույցի վրա Kubernetes-ը գործարկում է համակարգի դևերի մի շարք. դրանք ներառում են կոնտեյների գործարկման ժամանակը (օրինակ՝ Docker), kube-proxy և kubelet, ներառյալ cAdvisor-ը: Նրանք միասին սպառում են որոշակի ֆիքսված քանակությամբ ռեսուրսներ։

Եթե ​​դուք ունեք շատ փոքր հանգույցներ, ապա յուրաքանչյուր հանգույցի վրա այս գլխավճարի մասնաբաժինը ավելի մեծ է: Օրինակ, պատկերացրեք, որ մեկ հանգույցի բոլոր համակարգային դևերը միասին օգտագործում են 0,1 պրոցեսորի միջուկ և 0,1 ԳԲ հիշողություն: Եթե ​​դուք ունեք մեկ տասը միջուկային հանգույց 10 ԳԲ հիշողությամբ, ապա դևերը սպառում են կլաստերի հզորության 1%-ը: Մյուս կողմից, 1 ԳԲ հիշողությամբ տասը միամիջուկ հանգույցների վրա դևերը կվերցնեն կլաստերի հզորության 10%-ը։

Այսպիսով, որքան քիչ հանգույցներ, այնքան ավելի արդյունավետ է օգտագործվում ենթակառուցվածքը:

Թերություն թիվ 3. ռեսուրսների անարդյունավետ օգտագործում
Փոքր հանգույցներում կարող է լինել, որ մնացած ռեսուրսների կտորները չափազանց փոքր են որևէ ծանրաբեռնվածություն վերագրելու համար, ուստի դրանք մնում են չօգտագործված:

Օրինակ, յուրաքանչյուր պատիճ պահանջում է 0,75 ԳԲ հիշողություն: Եթե ​​ունեք տասը հանգույց, որոնցից յուրաքանչյուրը ունի 1 ԳԲ հիշողություն, կարող եք գործարկել տասը հանգույց՝ թողնելով յուրաքանչյուր հանգույցի 0,25 ԳԲ չօգտագործված հիշողություն:

Սա նշանակում է, որ ամբողջ կլաստերի հիշողության 25%-ը վատնում է:

10 ԳԲ հիշողությամբ մեծ հանգույցի վրա կարող եք գործարկել այս մոդուլներից 13-ը, և կմնա միայն մեկ չօգտագործված հատված՝ 0,25 ԳԲ:

Այս դեպքում հիշողության միայն 2,5%-ն է վատնում:

Այսպիսով, ռեսուրսներն ավելի օպտիմալ են օգտագործվում ավելի մեծ հանգույցների վրա:

Մի քանի խոշոր հանգույց, թե՞ շատ փոքր:

Այսպիսով, ո՞րն է ավելի լավ՝ մի քանի խոշոր հանգույցներ կլաստերում, թե՞ շատ փոքր: Ինչպես միշտ, հստակ պատասխան չկա։ Շատ բան կախված է կիրառման տեսակից:

Օրինակ, եթե հավելվածը պահանջում է 10 ԳԲ հիշողություն, ավելի մեծ հանգույցներն ակնհայտ ընտրություն են: Եվ եթե հավելվածը պահանջում է տասնապատիկ կրկնօրինակում բարձր հասանելիության համար, ապա հազիվ թե արժե վտանգել կրկնօրինակներ տեղադրել ընդամենը երկու հանգույցների վրա. կլաստերում պետք է լինի առնվազն տասը հանգույց:

Միջանկյալ իրավիճակներում ընտրություն կատարեք՝ ելնելով յուրաքանչյուր տարբերակի առավելություններից և թերություններից: Միգուցե որոշ փաստարկներ ավելի համապատասխան են ձեր իրավիճակին, քան մյուսները:

Եվ բոլորովին էլ պարտադիր չէ բոլոր հանգույցները նույն չափի դարձնել։ Ոչինչ չի խանգարում, որ սկզբում փորձեր կատարես նույն չափի հանգույցների հետ, այնուհետև ավելացնել դրանց տարբեր չափերի հանգույցներ՝ համատեղելով դրանք կլաստերի մեջ: Kubernetes կլաստերի աշխատող հանգույցները կարող են լիովին տարասեռ լինել: Այսպիսով, դուք կարող եք փորձել համատեղել երկու մոտեցումների առավելությունները:

Չկա մեկ բաղադրատոմս, և յուրաքանչյուր իրավիճակ ունի իր նրբությունները, և միայն արտադրությունը ցույց կտա ճշմարտությունը:

Թարգմանությունը պատրաստվել է ամպային հարթակի թիմի կողմից Mail.ru Cloud Solutions.

Ավելին Kubernetes-ի մասին. 25 Օգտակար գործիքներ կլաստերների կառավարման և տեղակայման համար.

Source: www.habr.com