Յուրաքանչյուր Kubernetes ռեսուրսի համար կարող եք կարգավորել երկու տեսակի պահանջներ՝ հարցումներ և սահմանափակումներ: Առաջինը նկարագրում է կոնտեյների կամ պատիճ գործարկելու համար անհրաժեշտ ազատ հանգույցի ռեսուրսների առկայության նվազագույն պահանջները, երկրորդը խստորեն սահմանափակում է կոնտեյների համար հասանելի ռեսուրսները:
Երբ Kubernetes-ը պլանավորում է պատիճներ, շատ կարևոր է, որ բեռնարկղերը բավարար ռեսուրսներ ունենան պատշաճ գործելու համար: Եթե դուք պլանավորում եք մեծ հավելված տեղակայել ռեսուրսներով սահմանափակված հանգույցի վրա, հնարավոր է, որ այն չաշխատի, քանի որ հանգույցի հիշողությունը սպառվում է կամ ավարտվում է պրոցեսորի հզորությունը: Այս հոդվածում մենք կանդրադառնանք, թե ինչպես կարող եք լուծել հաշվողական էներգիայի պակասը՝ օգտագործելով ռեսուրսների հարցումները և սահմանափակումները:
Հարցումները և սահմանափակումները մեխանիզմներ են, որոնք Kubernetes-ը օգտագործում է ռեսուրսները կառավարելու համար, ինչպիսիք են CPU-ն և հիշողությունը: Հարցումները այն են, որոնք ապահովում են բեռնարկղը ստանալ պահանջվող ռեսուրսը: Եթե կոնտեյները պահանջի ռեսուրս, Kubernetes-ը այն կծրագրի միայն այն հանգույցի վրա, որը կարող է տրամադրել այն: Սահմանափակումները վերահսկում են, որ կոնտեյների կողմից պահանջվող ռեսուրսները երբեք չեն գերազանցի որոշակի արժեքը:
Կոնտեյները կարող է մեծացնել իր հաշվողական հզորությունը միայն մինչև որոշակի սահմանաչափ, որից հետո այն կսահմանափակվի: Տեսնենք, թե ինչպես է այն աշխատում: Այսպիսով, կան երկու տեսակի ռեսուրսներ՝ պրոցեսոր և հիշողություն: Kubernetes-ի ժամանակացույցն օգտագործում է տվյալ ռեսուրսների մասին տվյալները՝ պարզելու, թե որտեղ պետք է գործարկել ձեր բլոկները: Տիպիկ ռեսուրսների ճշգրտումը պատիճների համար այսպիսի տեսք ունի.
Յուրաքանչյուր կոնտեյներ պատիճում կարող է սահմանել իր հարցումներն ու սահմանները, այդ ամենը հավելում է: Պրոցեսորային ռեսուրսները սահմանվում են միլիկորներով: Եթե ձեր բեռնարկղին գործարկելու համար անհրաժեշտ է երկու ամբողջական միջուկ, դուք արժեքը սահմանում եք 2000 մ: Եթե բեռնարկղին անհրաժեշտ է միայն միջուկի 1/4-ի հզորությունը, ապա արժեքը կլինի 250 մ: Հիշեք, որ եթե դուք նշանակեք CPU-ի ռեսուրսի արժեք, որն ավելի մեծ է, քան ամենամեծ հանգույցի միջուկների թիվը, ձեր pod-ն ընդհանրապես չի նախատեսվում սկսել: Նմանատիպ իրավիճակ կառաջանա, եթե դուք ունեք Pod, որին անհրաժեշտ է չորս միջուկ, իսկ Kubernetes կլաստերը բաղկացած է միայն երկու հիմնական վիրտուալ մեքենաներից:
Եթե ձեր հավելվածը հատուկ նախագծված չէ բազմաթիվ միջուկներից օգտվելու համար (ծրագրեր, ինչպիսիք են բարդ գիտական հաշվարկները և տվյալների բազայի գործառնությունները), ապա լավագույն պրակտիկան CPU Requests-ը սահմանելն է 1-ի կամ ավելի ցածր, այնուհետև ավելի շատ կրկնօրինակներ գործարկել ընդարձակելիության համար: Այս լուծումը համակարգին ավելի մեծ ճկունություն և հուսալիություն կտա:
Երբ խոսքը վերաբերում է պրոցեսորի սահմանափակումներին, ամեն ինչ ավելի հետաքրքիր է դառնում, քանի որ այն համարվում է սեղմվող ռեսուրս: Եթե ձեր հավելվածը սկսում է մոտենալ պրոցեսորի հզորության սահմանաչափին, Kubernetes-ը կսկսի դանդաղեցնել ձեր կոնտեյները՝ օգտագործելով CPU Throttling՝ նվազեցնելով պրոցեսորի հաճախականությունը: Սա նշանակում է, որ պրոցեսորը արհեստականորեն կխափանվի՝ հավելվածին պոտենցիալ ավելի վատ կատարողականություն տալով, բայց գործընթացը չի դադարեցվի կամ դուրս չգա:
Հիշողության ռեսուրսները սահմանվում են բայթերով: Սովորաբար պարամետրերում արժեքը չափվում է մեբիբայթներով Mib, բայց դուք կարող եք ցանկացած արժեք սահմանել՝ բայթից մինչև պետաբայթ: Այստեղ գործում է նույն իրավիճակը, ինչ պրոցեսորի դեպքում. եթե ձեր հանգույցների վրա հիշողության քանակից ավելի մեծ քանակի հիշողության հարցում եք դնում, այդ պատի կատարումը պլանավորված չի լինի: Բայց ի տարբերություն պրոցեսորի ռեսուրսների, հիշողությունը սեղմված չէ, քանի որ դրա օգտագործումը սահմանափակելու միջոց չկա: Հետևաբար, կոնտեյների գործարկումը կդադարեցվի, հենց որ այն դուրս գա իրեն հատկացված հիշողությունից։
Կարևոր է հիշել, որ դուք չեք կարող կարգավորել հարցումները, որոնք գերազանցում են ձեր հանգույցների տրամադրած ռեսուրսները: GKE վիրտուալ մեքենաների ընդհանուր ռեսուրսների բնութագրերը կարելի է գտնել այս տեսանյութի ներքևում գտնվող հղումներում:
Իդեալական աշխարհում կոնտեյների լռելյայն կարգավորումները բավարար կլինեն աշխատանքային հոսքերը սահուն գործելու համար: Բայց իրական աշխարհն այդպիսին չէ, մարդիկ կարող են հեշտությամբ մոռանալ ռեսուրսների օգտագործման կարգավորումը, կամ հաքերները կսահմանեն հարցումներ և սահմանափակումներ, որոնք գերազանցում են ենթակառուցվածքի իրական հնարավորությունները: Նման սցենարների առաջացումը կանխելու համար կարող եք կարգավորել ResourceQuota և LimitRange ռեսուրսների քվոտաները:
Անվանատարածք ստեղծելուց հետո այն կարող է արգելափակվել՝ օգտագործելով քվոտաներ: Օրինակ, եթե դուք ունեք prod և dev անվանատարածքներ, օրինակն այն է, որ արտադրության քվոտաներ ընդհանրապես չկան և զարգացման շատ խիստ քվոտաներ: Սա թույլ է տալիս արդյունահանողին, երթևեկության կտրուկ աճի դեպքում, տիրանալ ողջ հասանելի ռեսուրսին՝ ամբողջությամբ արգելափակելով մշակող սարքը:
Ռեսուրսների քվոտան կարող է այսպիսի տեսք ունենալ. Այս օրինակում կա 4 բաժին. սրանք կոդի 4 ստորին տողերն են:
Եկեք նայենք նրանցից յուրաքանչյուրին: Requests.cpu-ն CPU-ի համակցված հարցումների առավելագույն քանակն է, որը կարող է գալ անվանատարածքի բոլոր կոնտեյներներից: Այս օրինակում դուք կարող եք ունենալ 50 կոնտեյներ՝ 10 միլիոն հարցումներով, հինգ կոնտեյներ՝ 100 միլիոն հարցումներով կամ ընդամենը մեկ կոնտեյներ՝ 500 միլիոն հարցումներով: Քանի դեռ տվյալ անվանատարածքի requests.cpu-ի ընդհանուր թիվը 500 մ-ից պակաս է, ամեն ինչ լավ կլինի:
Հիշողության պահանջվող requests.memory-ը համակցված հիշողության հարցումների առավելագույն քանակն է, որը կարող են ունենալ անվանատարածքի բոլոր բեռնարկղերը: Ինչպես նախորդ դեպքում, դուք կարող եք ունենալ 50 2 մաբ կոնտեյներ, հինգ 20 մաբ կոնտեյներ կամ մեկ 100 մաբ տարողությամբ կոնտեյներ, քանի դեռ անվանատարածքում պահանջվող հիշողության ընդհանուր քանակը 100 մբիբայթից պակաս է:
Limits.cpu-ն CPU հզորության առավելագույն համակցված քանակն է, որը կարող են օգտագործել անվանատարածքի բոլոր կոնտեյներները: Մենք կարող ենք սա համարել պրոցեսորի էներգիայի պահանջների սահմանը:
Վերջապես, limits.memory-ը ընդհանուր հիշողության առավելագույն քանակն է, որը կարող են օգտագործել անվանատարածքի բոլոր կոնտեյներները: Սա ընդհանուր հիշողության հարցումների սահմանափակում է:
Այսպիսով, լռելյայնորեն, Kubernetes կլաստերի կոնտեյներները աշխատում են անսահմանափակ հաշվարկային ռեսուրսներով: Ռեսուրսների քվոտաներով, կլաստերի ադմինիստրատորները կարող են սահմանափակել ռեսուրսների սպառումը և ռեսուրսների ստեղծումը՝ հիմնվելով անունների տարածության վրա: Անվանատարածքում պատիճը կամ կոնտեյները կարող են սպառել այնքան պրոցեսորի էներգիա և հիշողություն, որքան որոշվում է անվանատարածքի ռեսուրսների քվոտայով: Այնուամենայնիվ, կա մտավախություն, որ մեկ պատիճ կամ կոնտեյներ կարող են մենաշնորհել բոլոր առկա ռեսուրսները: Այս իրավիճակը կանխելու համար օգտագործվում է սահմանային միջակայք՝ ռեսուրսների բաշխումը սահմանափակելու քաղաքականություն (փոդերի կամ բեռնարկղերի համար) անունների տարածքում:
Սահմանային միջակայքը ապահովում է սահմանափակումներ, որոնք կարող են.
- Ապահովել հաշվողական ռեսուրսների նվազագույն և առավելագույն օգտագործումը յուրաքանչյուր մոդուլի կամ կոնտեյների անվանատարածքում;
- պարտադրել նվազագույն և առավելագույն Starage Request պահպանման հարցումները յուրաքանչյուր PersistentVolumeClaim-ի համար անունների տարածքում.
- հաստատել հարաբերություններ անվանման տարածքում գտնվող ռեսուրսի հարցումի և սահմանաչափի միջև.
- սահմանել լռելյայն հարցումներ/սահմաններ հաշվողական ռեսուրսների համար անունների տարածքում և ավտոմատ կերպով ներարկել դրանք բեռնարկղերի մեջ գործարկման ժամանակ:
Այս կերպ Դուք կարող եք սահմանային տիրույթ ստեղծել ձեր անվանատարածքում: Ի տարբերություն քվոտայի, որը վերաբերում է ամբողջ անվանատարածքին, Limit Range-ն օգտագործվում է առանձին բեռնարկղերի համար: Սա կարող է թույլ չտալ օգտվողներին ստեղծել շատ փոքր կամ, ընդհակառակը, հսկայական կոնտեյներներ անունների տարածքում: Սահմանափակ տիրույթը կարող է այսպիսի տեսք ունենալ.
Ինչպես նախորդ դեպքում, այստեղ կարելի է առանձնացնել 4 բաժին. Եկեք նայենք յուրաքանչյուրին:
Լռելյայն բաժինը սահմանում է պատիճում գտնվող կոնտեյների լռելյայն սահմանաչափերը: Եթե դուք սահմանում եք այս արժեքները ծայրահեղ միջակայքում, ապա ցանկացած բեռնարկղ, որի համար այս արժեքները բացահայտորեն սահմանված չեն, կհետևեն լռելյայն արժեքներին:
Լռելյայն հարցում բաժինը defaultRequest կարգավորում է լռելյայն հարցումները պատիճում գտնվող կոնտեյների համար: Կրկին, եթե դուք սահմանեք այս արժեքները ծայրահեղ միջակայքում, ապա ցանկացած բեռնարկղ, որը բացահայտորեն չի սահմանում այս ընտրանքները, լռելյայն կլինի այս արժեքները:
Առավելագույն բաժինը սահմանում է առավելագույն սահմանները, որոնք կարող են սահմանվել պատիճում գտնվող կոնտեյների համար: Լռելյայն հատվածի արժեքները և բեռնարկղերի սահմանաչափերը չեն կարող սահմանվել այս սահմանից բարձր: Կարևոր է նշել, որ եթե արժեքը սահմանվում է առավելագույնը և չկա լռելյայն բաժին, ապա առավելագույն արժեքը դառնում է լռելյայն արժեք:
Min բաժինը սահմանում է նվազագույն պահանջները, որոնք կարող են սահմանվել պատիճում գտնվող կոնտեյների համար: Այնուամենայնիվ, կանխադրված բաժնում և կոնտեյների հարցումների արժեքները չեն կարող սահմանվել այս սահմանից ցածր:
Կրկին, կարևոր է նշել, որ եթե այս արժեքը սահմանված է, ապա լռելյայն չէ, ապա նվազագույն արժեքը դառնում է լռելյայն հուշում:
Այս ռեսուրսների հարցումներն ի վերջո օգտագործվում են Kubernetes-ի ժամանակացույցի կողմից՝ ձեր աշխատանքային բեռները կատարելու համար: Որպեսզի դուք ճիշտ կազմաձևեք ձեր բեռնարկղերը, շատ կարևոր է հասկանալ, թե ինչպես է այն աշխատում: Ենթադրենք, դուք ցանկանում եք գործարկել մի քանի պատիճներ ձեր կլաստերում: Ենթադրելով, որ pod բնութագրերը վավեր են, Kubernetes-ի ժամանակացույցը կօգտագործի շրջանաձև հավասարակշռումը՝ աշխատանքի ծանրաբեռնվածությունը գործարկող հանգույց ընտրելու համար:
Kubernetes-ը կստուգի, թե արդյոք Node 1-ը բավարար ռեսուրսներ ունի pod-ի բեռնարկղերի հարցումները կատարելու համար, և եթե չունի, այն կանցնի հաջորդ հանգույցին: Եթե համակարգի հանգույցներից ոչ մեկն ի վիճակի չէ բավարարել հարցումները, ապա բլոկները կմտնեն Սպասող վիճակ: Օգտագործելով Google Kubernetes շարժիչի առանձնահատկությունները, ինչպիսիք են հանգույցների ավտոմատ մասշտաբավորումը, GKE-ն կարող է ավտոմատ կերպով հայտնաբերել սպասման վիճակը և ստեղծել ևս մի քանի լրացուցիչ հանգույցներ:
Եթե դուք հետագայում սպառեք հանգույցի հզորությունը, ավտոմատ մասշտաբը կնվազեցնի հանգույցների քանակը՝ գումար խնայելու համար: Ահա թե ինչու Kubernetes-ը պլանավորում է պատիճները՝ հիմնվելով հարցումների վրա: Այնուամենայնիվ, սահմանը կարող է ավելի բարձր լինել, քան հարցումները, և որոշ դեպքերում հանգույցը կարող է իրականում սպառվել ռեսուրսներով: Այս պետությունը մենք անվանում ենք գերպարտավորության վիճակ։
Ինչպես ասացի, երբ խոսքը CPU-ի մասին է, Kubernetes-ը կսկսի սահմանափակել pods-ը: Յուրաքանչյուր պատիճ կստանա այնքան, որքան պահանջել է, բայց եթե այն չհասնի սահմանին, կսկսի կիրառվել շնչահեղձությունը:
Երբ խոսքը վերաբերում է հիշողության ռեսուրսներին, Kubernetes-ը ստիպված է որոշումներ կայացնել այն մասին, թե որ pod-երը ջնջել և որոնք պահել, մինչև դուք ազատեք համակարգի ռեսուրսները, հակառակ դեպքում ամբողջ համակարգը կխափանի:
Եկեք պատկերացնենք մի սցենար, երբ մեքենայի հիշողությունը սպառվում է. ինչպե՞ս կվարվեր Kubernetes-ը:
Kubernetes-ը կփնտրի պատիճներ, որոնք օգտագործում են ավելի շատ ռեսուրսներ, քան պահանջել են: Այսպիսով, եթե ձեր բեռնարկղերն ընդհանրապես հարցումներ չունեն, դա նշանակում է, որ նրանք լռելյայն օգտագործում են ավելին, քան խնդրել են, պարզապես այն պատճառով, որ նրանք ընդհանրապես ոչինչ չեն խնդրել: Նման բեռնարկղերը դառնում են անջատման հիմնական թեկնածուները: Հաջորդ թեկնածուները կոնտեյներներ են, որոնք բավարարել են իրենց բոլոր խնդրանքները, բայց դեռևս գտնվում են առավելագույն սահմանից ցածր:
Այսպիսով, եթե Kubernetes-ը գտնի մի քանի պատիճ, որոնք գերազանցել են իրենց պահանջի պարամետրերը, այն կդասավորի դրանք ըստ առաջնահերթության և այնուհետև կհեռացնի ամենացածր առաջնահերթության պատյանները: Եթե բոլոր պատիճներն ունեն նույն առաջնահերթությունը, ապա Kubernetes-ը կդադարեցնի այն պատիճները, որոնք ավելի շատ են գերազանցում իրենց խնդրանքները, քան մյուս պատյանները:
Շատ հազվադեպ դեպքերում Kubernetes-ը կարող է ընդհատել պատիճները, որոնք դեռևս գտնվում են իրենց խնդրանքների շրջանակում: Դա կարող է տեղի ունենալ, երբ համակարգի կարևոր բաղադրիչները, ինչպիսիք են Kubelet գործակալը կամ Docker-ը, սկսում են ավելի շատ ռեսուրսներ սպառել, քան նրանց համար նախատեսված էր:
Այսպիսով, փոքր ընկերությունների վաղ փուլերում Kubernetes կլաստերը կարող է լավ աշխատել՝ առանց ռեսուրսների հարցումների և սահմանափակումների սահմանման, բայց քանի որ ձեր թիմերն ու նախագծերը սկսում են մեծանալ, դուք վտանգի տակ եք առնում խնդիրներ այս ոլորտում: Ձեր մոդուլներին և անվանատարածքներին հարցումներ և սահմանափակումներ ավելացնելը շատ քիչ լրացուցիչ ջանք է պահանջում և կարող է խնայել շատ դժվարություններ:
Մի քանի գովազդ 🙂
Շնորհակալություն մեզ հետ մնալու համար: Ձեզ դուր են գալիս մեր հոդվածները: Ցանկանու՞մ եք տեսնել ավելի հետաքրքիր բովանդակություն: Աջակցեք մեզ՝ պատվիրելով կամ խորհուրդ տալով ընկերներին, , մուտքի մակարդակի սերվերների եզակի անալոգ, որը հորինվել է մեր կողմից ձեզ համար. (հասանելի է RAID1 և RAID10-ով, մինչև 24 միջուկով և մինչև 40 ԳԲ DDR4):
Dell R730xd 2 անգամ ավելի էժան Ամստերդամի Equinix Tier IV տվյալների կենտրոնում: Միայն այստեղ Նիդեռլանդներում! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99-ից: Կարդացեք մասին
Source: www.habr.com