ապրիլի 27-ին համաժողովում , որպես «DevOps» բաժնի մաս, տրվել է «Autoscaling and Resource Management in Kubernetes» զեկույցը։ Այն խոսում է այն մասին, թե ինչպես կարող եք օգտագործել K8-ները՝ ապահովելու ձեր հավելվածների բարձր հասանելիությունը և առավելագույն կատարողականությունը ապահովելու համար:
Ավանդույթի համաձայն մենք ուրախ ենք ներկայացնել (44 րոպե, շատ ավելի տեղեկատվական, քան հոդվածը) և հիմնական ամփոփումը տեքստային տեսքով: Գնա՛
Բառ առ բառ վերլուծենք հաշվետվության թեման ու սկսենք վերջից։
Կուբերնետես
Ենթադրենք, որ մենք ունենք Docker կոնտեյներներ մեր հյուրընկալողի վրա: Ինչի համար? Կրկնելիություն և մեկուսացում ապահովելու համար, որոնք իրենց հերթին թույլ են տալիս պարզ և լավ տեղակայում, CI/CD: Մենք ունենք բեռնարկղերով նման բազմաթիվ մեքենաներ։
Ի՞նչ է ապահովում Kubernetes-ն այս դեպքում:
- Մենք դադարում ենք մտածել այս մեքենաների մասին և սկսում ենք աշխատել «ամպի» հետ բեռնարկղերի կլաստեր կամ պատիճներ (տարաների խմբեր):
- Ավելին, մենք նույնիսկ չենք մտածում առանձին պատիճների մասին, այլ կառավարում ենք ավելինоավելի մեծ խմբեր: Այդպիսին բարձր մակարդակի պրիմիտիվներ թույլ տվեք ասել, որ կա որոշակի ծանրաբեռնվածություն գործարկելու ձևանմուշ, և ահա այն գործարկելու համար անհրաժեշտ թվով օրինակներ: Եթե մենք հետագայում փոխենք ձևանմուշը, բոլոր օրինակները կփոխվեն:
- Հետ դեկլարատիվ API Հատուկ հրամանների հաջորդականությունը կատարելու փոխարեն մենք նկարագրում ենք «աշխարհի կառուցվածքը» (YAML-ում), որը ստեղծվել է Kubernetes-ի կողմից: Եվ կրկին. երբ նկարագրությունը փոխվի, կփոխվի նաև դրա իրական ցուցադրումը:
Ռեսուրսների կառավարում
CPU
Եկեք սերվերի վրա գործարկենք nginx, php-fpm և mysql: Այս ծառայություններն իրականում կունենան ավելի շատ գործարկվող գործընթացներ, որոնցից յուրաքանչյուրը պահանջում է հաշվողական ռեսուրսներ.
(Սլայդի վրա թվերը «թութակներ են», յուրաքանչյուր գործընթացի վերացական անհրաժեշտությունը հաշվողական հզորության համար)
Սրա հետ աշխատելն ավելի հեշտ դարձնելու համար տրամաբանական է գործընթացները միավորել խմբերի մեջ (օրինակ՝ բոլոր nginx գործընթացները մեկ խմբի՝ «nginx»): Դա անելու պարզ և ակնհայտ միջոց է յուրաքանչյուր խումբ դնել տարայի մեջ.
Շարունակելու համար դուք պետք է հիշեք, թե ինչ է կոնտեյները (Linux-ում): Նրանց տեսքը հնարավոր է դարձել միջուկի երեք հիմնական հատկանիշների շնորհիվ, որոնք ներդրվել են բավականին վաղուց. , и . Եվ հետագա զարգացմանը նպաստեցին այլ տեխնոլոգիաներ (ներառյալ Docker-ի նման հարմար «պատյանները».
Զեկույցի համատեքստում մեզ միայն հետաքրքրում է խմբեր, քանի որ կառավարման խմբերը կոնտեյներների (Docker և այլն) ֆունկցիոնալության մի մասն են, որն իրականացնում է ռեսուրսների կառավարում։ Խմբերի մեջ համակցված գործընթացները, ինչպես ուզում էինք, վերահսկիչ խմբեր են։
Եկեք վերադառնանք այս գործընթացների համար CPU-ի պահանջներին, իսկ այժմ գործընթացների խմբերին.
(Կրկնում եմ, որ բոլոր թվերը ռեսուրսների անհրաժեշտության վերացական արտահայտությունն են)
Միևնույն ժամանակ, պրոցեսորն ինքն ունի որոշակի վերջավոր ռեսուրս (օրինակում սա 1000 է), որը կարող է բացակայել բոլորին (բոլոր խմբերի կարիքների գումարը 150+850+460=1460 է)։ Ի՞նչ կլինի այս դեպքում։
Միջուկը սկսում է ռեսուրսներ բաշխել և դա անում է «արդար»՝ յուրաքանչյուր խմբին տալով նույն քանակությամբ ռեսուրսներ։ Բայց առաջին դեպքում դրանք ավելի շատ են, քան անհրաժեշտ է (333>150), ուստի ավելցուկը (333-150=183) մնում է պահեստում, որը նույնպես հավասարապես բաշխվում է երկու այլ տարաների միջև.
Արդյունքում՝ առաջին կոնտեյներն ուներ բավարար ռեսուրսներ, երկրորդը՝ չուներ բավարար ռեսուրսներ, երրորդը՝ չուներ բավարար ռեսուրսներ։ Սա գործողությունների արդյունք է «ազնիվ» ժամանակացույց Linux-ում - . Դրա աշխատանքը կարող է ճշգրտվել՝ օգտագործելով հանձնարարությունը կշիռները տարաներից յուրաքանչյուրը: Օրինակ, այսպես.
Դիտարկենք երկրորդ կոնտեյների (php-fpm) ռեսուրսների պակասի դեպքը։ Բոլոր բեռնարկղային ռեսուրսները հավասարապես բաշխվում են գործընթացների միջև: Արդյունքում, հիմնական գործընթացը լավ է աշխատում, բայց բոլոր աշխատողները դանդաղում են՝ ստանալով իրենց անհրաժեշտի կեսից պակասը.
Ահա թե ինչպես է աշխատում CFS ժամանակացույցը: Մենք հետագայում կանվանենք այն կշիռները, որոնք մենք վերագրում ենք բեռնարկղերին հարցումներ. Ինչու է դա այդպես - տես հետագա:
Ամբողջ իրավիճակը նայենք մյուս կողմից։ Ինչպես գիտեք, բոլոր ճանապարհները տանում են Հռոմ, իսկ համակարգչի դեպքում՝ պրոցեսոր: Մեկ պրոցեսոր, շատ առաջադրանքներ՝ լուսացույց է պետք: Ռեսուրսները կառավարելու ամենապարզ միջոցը «երթևեկության լույսն» է. նրանք մի գործընթացին ֆիքսված մուտքի ժամանակ տվեցին պրոցեսորին, այնուհետև հաջորդին և այլն:
Այս մոտեցումը կոչվում է կոշտ քվոտաներ (դժվար սահմանափակող). Հիշենք դա պարզապես որպես սահմանները. Այնուամենայնիվ, եթե դուք սահմանափակումներ եք բաժանում բոլոր բեռնարկղերի վրա, խնդիր է առաջանում. mysql-ը քշում էր ճանապարհի երկայնքով և ինչ-որ պահի նրա CPU-ի կարիքն ավարտվեց, բայց մնացած բոլոր գործընթացները ստիպված են սպասել մինչև պրոցեսորը: պարապ.
Եկեք վերադառնանք Linux միջուկին և դրա փոխազդեցությանը CPU-ի հետ - ընդհանուր պատկերը հետևյալն է.
cgroup-ն ունի երկու կարգավորում. ըստ էության, դրանք երկու պարզ «շրջադարձեր» են, որոնք թույլ են տալիս որոշել.
- քաշը կոնտեյների (խնդրանքների) համար է բաժնետոմսեր;
- բեռնարկղային առաջադրանքների վրա աշխատելու համար պրոցեսորի ընդհանուր ժամանակի տոկոսը (սահմանները) կազմում է քվոտա.
Ինչպե՞ս չափել պրոցեսորը:
Կան տարբեր եղանակներ.
- Ինչ է թխվածքաբլիթներ, ոչ ոք չգիտի, դուք պետք է ամեն անգամ բանակցել:
- Հետաքրքրություն ավելի պարզ, բայց հարաբերական. 50 միջուկով և 4 միջուկով սերվերի 20%-ը լրիվ տարբեր բաներ են:
- Դուք կարող եք օգտագործել արդեն նշվածները կշիռները, որոնք Linux-ը գիտի, բայց դրանք նույնպես հարաբերական են։
- Ամենաադեկվատ տարբերակը հաշվողական ռեսուրսները չափելն է վայրկյան. Նրանք. պրոցեսորի ժամանակի վայրկյաններում իրական ժամանակի վայրկյանների համեմատ. պրոցեսորի ժամանակի 1 վայրկյանը տրվել է 1 իրական վայրկյանին. սա մեկ ամբողջ պրոցեսորի միջուկ է:
Խոսելն էլ ավելի հեշտացնելու համար նրանք սկսեցին ուղղակիորեն չափել միջուկներ, նկատի ունենալով նրանց կողմից նույն պրոցեսորի ժամանակը իրականի համեմատ: Քանի որ Linux-ը հասկանում է կշիռներ, բայց ոչ այնքան պրոցեսորի ժամանակ/միջուկներ, անհրաժեշտ էր մեխանիզմ՝ մեկից մյուսը թարգմանելու համար:
Դիտարկենք 3 պրոցեսորի միջուկ ունեցող սերվերի մի պարզ օրինակ, որտեղ երեք պատիճ կտրվի կշիռներ (500, 1000 և 1500), որոնք հեշտությամբ փոխարկվում են իրենց հատկացված միջուկների համապատասխան մասերին (0,5, 1 և 1,5):
Եթե վերցնում եք երկրորդ սերվերը, որտեղ երկու անգամ ավելի շատ միջուկներ կլինեն (6), և այնտեղ տեղադրեք նույն պատիճները, ապա միջուկների բաշխումը հեշտությամբ կարելի է հաշվարկել՝ պարզապես 2-ով բազմապատկելով (համապատասխանաբար 1, 2 և 3): Բայց կարևոր պահ է առաջանում, երբ այս սերվերի վրա հայտնվում է չորրորդ պատիճը, որի քաշը, հարմարության համար, կլինի 3000: Այն խլում է պրոցեսորի ռեսուրսների մի մասը (միջուկների կեսը), իսկ մնացած պատյանների համար դրանք վերահաշվարկվում են (կես անգամ կրճատվում).
Kubernetes և CPU ռեսուրսներ
Kubernetes-ում CPU-ի ռեսուրսները սովորաբար չափվում են միլիադրաքս, այսինքն. Որպես հիմնական քաշ ընդունվում է 0,001 միջուկ: (Լինուքսի/cgroups-ի տերմինաբանության մեջ նույն բանը կոչվում է պրոցեսորի մասնաբաժին, չնայած, ավելի ճիշտ՝ 1000 միլիկորեր = 1024 պրոցեսորի բաժնետոմս:) K8s-ը երաշխավորում է, որ սերվերի վրա չի տեղադրում ավելի շատ պատիճներ, քան առկա են պրոցեսորային ռեսուրսները բոլոր պատյանների կշիռների գումարի համար:
Ինչպե՞ս է դա տեղի ունենում: Երբ սերվեր եք ավելացնում Kubernetes կլաստերին, հաղորդվում է, թե քանի պրոցեսորի միջուկ ունի այն: Եվ երբ ստեղծում է նոր pod, Kubernetes-ի ժամանակացույցը գիտի, թե քանի միջուկ է անհրաժեշտ այս pod-ին: Այսպիսով, pod-ը կհատկացվի սերվերի, որտեղ կան բավարար միջուկներ:
Ինչ կլինի, եթե ոչ հարցումը նշված է (այսինքն, պատիճը չունի որոշակի քանակությամբ միջուկներ, որոնք անհրաժեշտ են): Եկեք պարզենք, թե ինչպես է Kubernetes-ը ընդհանուր առմամբ հաշվում ռեսուրսները:
Փոդի համար կարող եք նշել և՛ հարցումները (CFS ժամանակացույց) և՛ սահմանափակումներ (հիշո՞ւմ եք լուսացույցը):
- Եթե դրանք նշված են հավասար, ապա pod-ին վերագրվում է QoS դաս երաշխավորված. Նրան միշտ հասանելի միջուկների այս թիվը երաշխավորված է:
- Եթե հարցումը սահմանից փոքր է - QoS դաս պայթող. Նրանք. Մենք ակնկալում ենք, որ pod, օրինակ, միշտ օգտագործի 1 միջուկ, բայց այս արժեքը դրա համար սահմանափակում չէ. երբեմն pod-ը կարող է ավելի շատ օգտագործել (երբ սերվերն ունի դրա համար անվճար ռեսուրսներ):
- Կա նաև QoS դաս լավագույն ջանք — այն ներառում է հենց այն պատյանները, որոնց հարցումը նշված չէ: Ռեսուրսները նրանց տրվում են վերջինը:
հիշողություն
Հիշողության դեպքում իրավիճակը նման է, բայց մի փոքր այլ է. ի վերջո, այս ռեսուրսների բնույթը տարբեր է: Ընդհանուր առմամբ, անալոգիան հետևյալն է.
Տեսնենք, թե ինչպես են հարցումներն իրականացվում հիշողության մեջ: Թող պատիճները ապրեն սերվերում՝ փոխելով հիշողության սպառումը, մինչև դրանցից մեկն այնքան մեծանա, որ հիշողությունը սպառվի: Այս դեպքում հայտնվում է OOM մարդասպանը և սպանում ամենամեծ գործընթացը.
Սա մեզ ոչ միշտ է սազում, ուստի կարելի է կարգավորել, թե որ գործընթացներն են մեզ համար կարևոր և չպետք է սպանվեն։ Դա անելու համար օգտագործեք պարամետրը oom_score_adj.
Եկեք վերադառնանք պրոցեսորի QoS դասերին և անալոգիա նկարենք oom_score_adj արժեքների հետ, որոնք որոշում են հիշողության սպառման առաջնահերթությունները pods-ի համար.
- Ամենացածր oom_score_adj արժեքը՝ -998 - նշանակում է, որ այդպիսի պատիճը պետք է սպանվի վերջինը, սա երաշխավորված.
- Ամենաբարձրը՝ 1000-ն է լավագույն ջանք, նման պատիճները նախ սպանվում են։
- Մնացած արժեքները հաշվարկելու համար (պայթող) կա մի բանաձև, որի էությունը հանգում է նրան, որ որքան ավելի շատ ռեսուրսներ է պահանջել մի պատիճ, այնքան քիչ հավանական է, որ այն սպանվի:
Երկրորդ «շրջադարձ». limit_in_bytes - սահմանների համար: Դրա հետ ամեն ինչ ավելի պարզ է. մենք պարզապես հատկացնում ենք թողարկված հիշողության առավելագույն քանակը, և այստեղ (ի տարբերություն պրոցեսորի) հարց չկա, թե ինչպես չափել այն (հիշողությունը):
Ընդհանուր
Յուրաքանչյուր պատիճ Kubernetes-ում տրվում է requests и limits - երկու պարամետրերը պրոցեսորի և հիշողության համար.
- հարցումների հիման վրա աշխատում է Kubernetes ժամանակացույցը, որը բաշխում է pods սերվերների միջև.
- բոլոր պարամետրերի հիման վրա որոշվում է պատի QoS դասը.
- Հարաբերական կշիռները հաշվարկվում են պրոցեսորի հարցումների հիման վրա.
- CFS ժամանակացույցը կազմաձևված է պրոցեսորի հարցումների հիման վրա.
- OOM մարդասպանը կազմաձևված է հիշողության հարցումների հիման վրա.
- «երթևեկության լույսը» կազմաձևված է պրոցեսորի սահմանափակումների հիման վրա.
- Հիշողության սահմանափակումների հիման վրա սահմանվում է cgroup-ի համար սահմանաչափ:
Ընդհանուր առմամբ, այս նկարը պատասխանում է բոլոր այն հարցերին, թե ինչպես է ռեսուրսների կառավարման հիմնական մասը տեղի ունենում Kubernetes-ում:
Ավտոմասշտաբացում
K8s կլաստեր-ավտոմաշտաբաշխիչ
Եկեք պատկերացնենք, որ ամբողջ կլաստերն արդեն զբաղված է, և պետք է ստեղծել նոր պատիճ: Թեև պատիճը չի կարող հայտնվել, այն կախված է կարգավիճակում Ընթացքում. Որպեսզի այն հայտնվի, մենք կարող ենք միացնել նոր սերվեր կլաստերին կամ... տեղադրել cluster-autoscaler, որը դա կանի մեզ համար. պատվիրեք վիրտուալ մեքենա ամպի մատակարարից (օգտագործելով API հարցում) և միացրեք այն կլաստերին: , որից հետո պատիճը կավելացվի :
Սա Kubernetes կլաստերի ավտոմատ մասշտաբավորումն է, որը հիանալի է աշխատում (մեր փորձով): Այնուամենայնիվ, ինչպես այլուր, այստեղ էլ կան որոշ նրբերանգներ...
Քանի դեռ մենք մեծացնում էինք կլաստերի չափը, ամեն ինչ լավ էր, բայց ինչ է տեղի ունենում, երբ կլաստերը սկսեց ազատվել? Խնդիրն այն է, որ փոդերի միգրացիան (հոսթները ազատելու համար) տեխնիկապես շատ դժվար է և ծախսատար՝ ռեսուրսների առումով: Kubernetes-ը բոլորովին այլ մոտեցում է օգտագործում.
Դիտարկենք 3 սերվերների կլաստեր, որն ունի տեղակայում: Այն ունի 6 պատիճ. այժմ յուրաքանչյուր սերվերի համար կա 2: Ինչ-ինչ պատճառներով մենք ցանկանում էինք անջատել սերվերներից մեկը: Դա անելու համար մենք կօգտագործենք հրամանը kubectl drain, որը:
- արգելելու է նոր պատիճներ ուղարկել այս սերվերին.
- կջնջի առկա պատիճները սերվերում:
Քանի որ Kubernetes-ը պատասխանատու է պատիճների (6) քանակի պահպանման համար, այն պարզապես կվերստեղծի դրանք այլ հանգույցների վրա, բայց ոչ անջատվածի վրա, քանի որ այն արդեն նշվել է որպես անհասանելի նոր հանգույցներ տեղադրելու համար: Սա հիմնարար մեխանիզմ է Kubernetes-ի համար:
Այնուամենայնիվ, այստեղ էլ կա մի նրբերանգ. Նմանատիպ իրավիճակում StatefulSet-ի համար (տեղակայման փոխարեն) գործողությունները տարբեր կլինեն: Այժմ մենք արդեն ունենք պետական հավելված, օրինակ՝ երեք պատիճ MongoDB-ով, որոնցից մեկն ունի ինչ-որ խնդիր (տվյալները կոռումպացված են կամ մեկ այլ սխալ, որը թույլ չի տալիս պատիճը ճիշտ գործարկել): Եվ մենք կրկին որոշում ենք անջատել մեկ սերվեր: Ի՞նչ է լինելու։
MongoDB- ը կարող էր մահանալ, քանի որ քվորումի կարիք ունի. երեք կայանքներից բաղկացած կլաստերի համար առնվազն երկուսը պետք է գործեն: Այնուամենայնիվ, սա տեղի չի ունենում - շնորհիվ PodDisruptionBudget. Այս պարամետրը որոշում է աշխատանքային պատիճների նվազագույն պահանջվող քանակը: Իմանալով, որ MongoDB pod-երից մեկն այլևս չի աշխատում, և տեսնելով, որ PodDisruptionBudget-ը սահմանված է MongoDB-ի համար minAvailable: 2, Kubernetes-ը թույլ չի տա ձեզ ջնջել pod.
Ներքևի գիծ. որպեսզի կլաստերի ազատման ժամանակ փոդերի շարժումը (և իրականում վերստեղծումը) ճիշտ աշխատի, անհրաժեշտ է կարգավորել PodDisruptionBudget-ը։
Հորիզոնական մասշտաբավորում
Դիտարկենք մեկ այլ իրավիճակ. Կա մի ծրագիր, որն աշխատում է որպես տեղակայում Kubernetes-ում: Օգտատերերի տրաֆիկը գալիս է իր պատիճներին (օրինակ, դրանք երեքն են), և մենք դրանցում որոշակի ցուցանիշ ենք չափում (ասենք, պրոցեսորի ծանրաբեռնվածությունը): Երբ ծանրաբեռնվածությունը մեծանում է, մենք այն գրանցում ենք ժամանակացույցով և ավելացնում ենք հարցումների բաշխման համար նախատեսված պատիճների քանակը:
Այսօր Kubernetes-ում դա պետք չէ ձեռքով անել. պատյանների քանակի ավտոմատ ավելացում/նվազում է կազմաձևվում՝ կախված չափված բեռի ցուցիչների արժեքներից:
Այստեղ հիմնական հարցերն են. ինչ կոնկրետ չափել и ինչպես մեկնաբանել ձեռք բերված արժեքներ (կճղակների քանակի փոփոխության վերաբերյալ որոշում կայացնելու համար): Դուք կարող եք շատ բան չափել.
Ինչպես դա անել տեխնիկապես՝ հավաքել չափումներ և այլն: — Ես մանրամասն խոսել եմ զեկույցում . Իսկ օպտիմալ պարամետրեր ընտրելու հիմնական խորհուրդն է փորձ!
Կա (Օգտագործման հագեցվածություն և սխալներ), որի իմաստը հետեւյալն է. Ինչի՞ հիման վրա է իմաստ ունի մասշտաբավորել, օրինակ, php-fpm: Ելնելով այն հանգամանքից, որ աշխատողները վերջանում են, սա է օգտագործում. Իսկ եթե բանվորները վերջացել են ու նոր կապեր չեն ընդունվում, սա արդեն հագեցում. Այս երկու պարամետրերը պետք է չափվեն, և կախված արժեքներից, պետք է իրականացվի մասշտաբավորում:
Փոխարենը մի եզրակացության
Զեկույցն ունի շարունակություն՝ ուղղահայաց մասշտաբավորման և ճիշտ ռեսուրսների ընտրության մասին: Այս մասին ես կխոսեմ հետագա տեսանյութերում - Բաժանորդագրվեք, որպեսզի բաց չթողնեք:
Տեսանյութեր և սլայդներ
Տեսանյութ ներկայացումից (44 րոպե).
Զեկույցի ներկայացում.
PS
Այլ հաղորդումներ Kubernetes-ի մասին մեր բլոգում.
- «» (Անդրեյ Պոլովով; 8 թվականի ապրիլի 2019-ին Saint HighLoad++-ում);
- «» (Դմիտրի Ստոլյարով; նոյեմբերի 8, 2018 HighLoad++-ում);
- «» (Դմիտրի Ստոլյարով; մայիսի 28, 2018 RootConf-ում);
- «» (Դմիտրի Ստոլյարով; նոյեմբերի 7, 2017 HighLoad++-ում);
- «» (Դմիտրի Ստոլյարով; 6 թվականի հունիսի 2017-ին RootConf-ում).
Source: www.habr.com