Յուրաքանչյուր Kubernetes ռեսուրսի համար հնարավոր է կարգավորել երկու տեսակի պահանջներ՝ հարցումներ և սահմանափակումներ: Առաջինը նկարագրում է կոնտեյների կամ պատիճ գործարկելու համար անհրաժեշտ ազատ հանգույցի ռեսուրսների առկայության նվազագույն պահանջները, երկրորդը խստորեն սահմանափակում է կոնտեյների համար հասանելի ռեսուրսները:
Երբ Kubernetes-ը պլանավորում է պատիճներ, կարևոր է, որ բեռնարկղերը ունենան բավարար ռեսուրսներ՝ ճիշտ աշխատելու համար: Եթե դուք նախատեսում եք մեծ հավելված տեղակայել ռեսուրսներով սահմանափակված հանգույցում, ապա միանգամայն հնարավոր է, որ այն ձախողվի, քանի որ հանգույցը սպառվում է հիշողությունից կամ չունի պրոցեսորի հզորություն: Այս հոդվածում մենք կանդրադառնանք, թե ինչպես լուծել անբավարար հաշվողական հզորության խնդիրները՝ օգտագործելով ռեսուրսների հարցումները և սահմանափակումները:
Հարցումները և սահմանափակումները մեխանիզմներ են, որոնք Kubernetes-ը օգտագործում է ռեսուրսները կառավարելու համար, ինչպիսիք են CPU-ն և հիշողությունը: Հարցումները այն են, ինչը ապահովում է, որ կոնտեյները ստանում է իր պահանջած ռեսուրսը: Երբ բեռնարկղը պահանջում է ռեսուրս, Kubernetes-ը այն պլանավորում է միայն այն հանգույցի վրա, որը կարող է տրամադրել այն: Սահմանափակումները երաշխավորում են, որ կոնտեյների կողմից պահանջվող ռեսուրսները երբեք չեն գերազանցում որոշակի արժեքը:
Բեռնարկղը կարող է միայն ավելացնել իր հաշվողական հզորությունը մինչև որոշակի սահմանաչափ, որից հետո այն կսահմանափակվի։ Տեսնենք, թե ինչպես է այն աշխատում: Այսպիսով, կան երկու տեսակի ռեսուրսներ՝ պրոցեսոր և հիշողություն: Kubernetes-ի ժամանակացույցն օգտագործում է տվյալ ռեսուրսների մասին տվյալները՝ պարզելու, թե որտեղ պետք է գործարկել ձեր բլոկները: Տիպիկ ռեսուրսների ճշգրտումը պատիճների համար այսպիսի տեսք ունի.
Յուրաքանչյուր կոնտեյներ պատիճում կարող է սահմանել իր սեփական պահանջներն ու սահմանները, բոլորը հավելումներ: Պրոցեսորային ռեսուրսները սահմանվում են միլիկորներով: Եթե ձեր բեռնարկղին գործարկելու համար անհրաժեշտ է երկու ամբողջական միջուկ, դուք արժեքը սահմանում եք 2000 մ: Եթե բեռնարկղին անհրաժեշտ է միայն 1/4 միջուկի հզորություն, արժեքը կլինի 250 մ: Հիշեք, որ եթե դուք CPU-ի արժեքն ավելի մեծ եք հատկացնում, քան ամենամեծ հանգույցի միջուկների թիվը, ձեր pod-ն ընդհանրապես չի պլանավորվի աշխատել: Նմանատիպ իրավիճակ կառաջանար, եթե ունեիք պատիճ, որի համար անհրաժեշտ էր չորս միջուկ, բայց Kubernetes կլաստերը ուներ միայն երկու հիմնական VM:
Եթե ձեր հավելվածը հատուկ նախագծված չէ բազմաթիվ միջուկներից օգտվելու համար (ծրագրեր, ինչպիսիք են բարդ գիտական հաշվարկները և տվյալների բազայի գործառնությունները), լավագույն պրակտիկան CPU Requests-ը սահմանելն է 1-ի կամ ավելի ցածր, այնուհետև գործարկել ավելի շատ կրկնօրինակներ՝ մասշտաբայնության համար: Այս լուծումը համակարգին ավելի մեծ ճկունություն և հուսալիություն կտա:
Երբ խոսքը վերաբերում է պրոցեսորի սահմանափակումներին, ամեն ինչ ավելի հետաքրքիր է դառնում, քանի որ այն համարվում է սեղմվող ռեսուրս: Եթե ձեր հավելվածը սկսի մոտենալ իր պրոցեսորի սահմանաչափին, Kubernetes-ը կսկսի խեղդել ձեր կոնտեյները՝ օգտագործելով CPU Throttling: Սա նշանակում է, որ պրոցեսորը արհեստականորեն կսահմանափակվի՝ հավելվածին պոտենցիալ ավելի վատ կատարողականություն տալով, բայց գործընթացը չի դադարեցվի կամ սպանվի:
Հիշողության ռեսուրսները սահմանվում են բայթերով: Սովորաբար կարգավորումներում արժեքը չափվում է Mib մբիբայթերով, բայց դուք կարող եք սահմանել ցանկացած արժեք՝ բայթից մինչև պետաբայթ: Այստեղ գործում է նույն իրավիճակը, ինչ պրոցեսորի դեպքում. եթե դուք ավելի շատ հիշողության խնդրանք ներկայացնեք, քան ձեր հանգույցները ունեն, այդ pod չի պլանավորվի: Բայց ի տարբերություն պրոցեսորի ռեսուրսների, հիշողությունը սեղմված չէ, քանի որ դրա օգտագործումը սահմանափակելու միջոց չկա: Հետևաբար, կոնտեյների աշխատանքը կդադարեցվի, հենց որ այն դուրս գա իրեն հատկացված հիշողության սահմաններից:
Կարևոր է հիշել, որ դուք չեք կարող կարգավորել հարցումները, որոնք ավելի մեծ են, քան ձեր հանգույցները կարող են տրամադրել: GKE վիրտուալ մեքենայի համօգտագործման բնութագրերը կարելի է գտնել այս տեսանյութի ներքևում գտնվող հղումներում:
Իդեալական աշխարհում բեռնարկղերի լռելյայն կարգավորումները բավարար կլինեն աշխատանքային հոսքերը սահուն գործելու համար: Բայց իրական աշխարհն այդպիսին չէ, մարդիկ կարող են հեշտությամբ մոռանալ ռեսուրսների օգտագործման կարգավորումը, կամ հաքերները կարող են հարցումներ և սահմանափակումներ դնել, որոնք գերազանցում են ենթակառուցվածքի իրական հնարավորությունները: Նման սցենարների առաջացումը կանխելու համար կարող եք կարգավորել ResourceQuota և LimitRange ռեսուրսների քվոտաները:
Անվանատարածքները ստեղծելուց հետո դրանք կարող են արգելափակվել՝ օգտագործելով քվոտաներ: Օրինակ, եթե դուք ունեք prod և dev անվանումների տարածքներ, ապա օգտագործված օրինակն այն է, որ արտադրության քվոտաները լիովին բացակայում են, մինչդեռ զարգացման քվոտաները շատ խիստ են: Սա թույլ է տալիս արդյունահանողներին, թրաֆիկի կտրուկ աճի դեպքում, տիրանալ բոլոր հասանելի ռեսուրսներին՝ ամբողջությամբ արգելափակելով զարգացումը:
Ռեսուրսների քվոտան կարող է այսպիսի տեսք ունենալ. Այս օրինակում կա 4 բաժին. սրանք կոդի ներքևի 4 տողերն են:
Եկեք նայենք նրանցից յուրաքանչյուրին: Requests.cpu-ն CPU-ի հզորության համակցված հարցումների առավելագույն քանակն է, որը կարող է գալ անվանատարածքի բոլոր կոնտեյներներից: Այս օրինակում դուք կարող եք ունենալ 50 կոնտեյներ՝ 10 միլիոն հարցումներով, հինգ կոնտեյներ՝ 100 միլիոն հարցումներով կամ ընդամենը մեկ կոնտեյներ՝ 500 միլիոն հարցումներով: Քանի դեռ տվյալ անվանատարածքի ընդհանուր requests.cpu count-ը 500 մ-ից պակաս է, ամեն ինչ լավ կլինի:
Պահանջվող հիշողության requests.memory-ը համակցված հիշողության հարցումների առավելագույն քանակն է, որը կարող են ունենալ անվանատարածքի բոլոր կոնտեյներները: Ինչպես նախորդ դեպքում, դուք կարող եք ունենալ 50 2 ՄԲ կոնտեյներ, հինգ 20 ՄԲ կոնտեյներ կամ մեկ 100 ՄԲ տարողությամբ կոնտեյներ, քանի դեռ անվանման տարածքում պահանջվող հիշողության ընդհանուր քանակը 100 ՄԲ-ից պակաս է:
Limits.cpu-ն CPU-ի հզորության առավելագույն համակցված արժեքն է, որը կարող են օգտագործել անվանատարածքի բոլոր կոնտեյներները: Սա կարելի է համարել պրոցեսորի էներգիայի պահանջների սահմանը:
Վերջապես, limits.memory-ը ընդհանուր հիշողության առավելագույն քանակն է, որը կարող են օգտագործել անվանատարածքի բոլոր կոնտեյներները: Սա ընդհանուր հիշողության պահանջների սահմանն է:
Այսպիսով, լռելյայնորեն, Kubernetes կլաստերի կոնտեյներները աշխատում են անսահմանափակ հաշվարկային ռեսուրսներով: Ռեսուրսների քվոտաները թույլ են տալիս կլաստերի ադմինիստրատորներին սահմանափակել ռեսուրսների սպառումը և ստեղծումը յուրաքանչյուր անվանատարածքի հիման վրա: Անվանատարածքում պատիճը կամ կոնտեյները կարող են սպառել այնքան պրոցեսոր և հիշողություն, որքան սահմանված է անվանատարածքի ռեսուրսների քվոտայով: Այնուամենայնիվ, կա մտավախություն, որ մեկ պատիճ կամ կոնտեյներ կարող է մենաշնորհել բոլոր առկա ռեսուրսները: Այս իրավիճակը կանխելու համար օգտագործվում է սահմանաչափի միջակայքը՝ ռեսուրսների բաշխումը սահմանափակելու քաղաքականություն (փոդերի կամ բեռնարկղերի համար) անունների տարածքում:
Շրջանակի սահմանաչափը սահմանում է սահմանափակումներ, որոնք կարող են.
- ապահովել հաշվողական ռեսուրսների նվազագույն և առավելագույն օգտագործումը յուրաքանչյուր մոդուլի կամ կոնտեյների անվանատարածքում.
- Ստիպել նվազագույն և առավելագույն Starage Request պահպանման հարցումը կատարել յուրաքանչյուր PersistentVolumeClaim-ի համար անունների տարածքում;
- ստիպել կապը Request-ի և Resource-ի սահմանաչափի միջև անվանման տարածքում.
- Սահմանեք լռելյայն հարցումներ/սահմաններ հաշվողական ռեսուրսների համար անունների տարածքում և ավտոմատ կերպով ներարկեք դրանք բեռնարկղերի մեջ գործարկման ժամանակ:
Այս կերպ Դուք կարող եք սահմանային տիրույթ ստեղծել ձեր անվանատարածքում: Ի տարբերություն քվոտայի, որը վերաբերում է ամբողջ անվանատարածքին, Limit Range-ը կիրառվում է առանձին բեռնարկղերի վրա: Սա կարող է թույլ չտալ օգտվողներին ստեղծել շատ փոքր կամ, ընդհակառակը, հսկայական կոնտեյներներ անվանատարածքի ներսում: Սահմանափակ տիրույթը կարող է այսպիսի տեսք ունենալ.
Ինչպես նախորդ դեպքում, այստեղ էլ կարելի է առանձնացնել 4 բաժին. Եկեք նայենք յուրաքանչյուրին:
Լռելյայն բաժինը սահմանում է լռելյայն սահմանաչափեր պատիճում գտնվող կոնտեյների համար: Եթե դուք սահմանեք այս արժեքները ծայրահեղ միջակայքում, ապա ցանկացած բեռնարկղ, որը չունի այդ արժեքները բացահայտորեն սահմանված, կօգտագործի լռելյայն արժեքները:
DefaultRequest բաժինը կարգավորում է լռելյայն հարցումները պատիճում գտնվող կոնտեյների համար: Կրկին, եթե դուք սահմանեք այս արժեքները ծայրահեղ միջակայքում, ցանկացած բեռնարկղ, որը բացահայտորեն չունի այս պարամետրերը, կօգտագործի այդ արժեքները լռելյայն:
Առավելագույն բաժինը նշում է առավելագույն սահմանները, որոնք կարող են սահմանվել պատիճում գտնվող կոնտեյների համար: Լռելյայն բաժնի և բեռնարկղերի սահմանաչափերի արժեքները չեն կարող սահմանվել այս սահմանից բարձր: Կարևոր է նշել, որ եթե max-ը սահմանված է, և լռելյայն բաժինը բացակայում է, ապա առավելագույն արժեքը դառնում է լռելյայն արժեք:
Min բաժինը սահմանում է նվազագույն պահանջները, որոնք կարող են սահմանվել պատիճում գտնվող կոնտեյների համար: Այնուամենայնիվ, կանխադրված բաժնում և կոնտեյների հարցումների արժեքները չեն կարող սահմանվել այս սահմանից ցածր:
Կրկին, կարևոր է նշել, որ եթե այս արժեքը սահմանված է, ապա լռելյայն արժեքը չէ, և նվազագույն արժեքը դառնում է լռելյայն հարցում:
Այս ռեսուրսների հարցումներն ի վերջո օգտագործվում են Kubernetes-ի ժամանակացույցի կողմից՝ ձեր աշխատանքային բեռները կատարելու համար: Ձեր տարաները ճիշտ տեղադրելու համար շատ կարևոր է հասկանալ, թե ինչպես է այն աշխատում: Ենթադրենք, դուք ցանկանում եք գործարկել մի քանի պատիճներ ձեր կլաստերում: Ենթադրելով, որ pod բնութագրերը վավեր են, Kubernetes-ի ժամանակացույցը կօգտագործի շրջանաձև հավասարակշռումը՝ աշխատանքի ծանրաբեռնվածությունը գործարկող հանգույց ընտրելու համար:
Kubernetes-ը կստուգի, թե արդյոք Node 1-ը բավարար ռեսուրսներ ունի pod-ի կոնտեյների հարցումները կատարելու համար, և եթե դա չկա, այն կտեղափոխվի հաջորդ հանգույց: Եթե համակարգի հանգույցներից և ոչ մեկը չկարողանա բավարարել հարցումները, ապա բլոկները կմտնեն Սպասող վիճակ: Օգտագործելով Google Kubernetes շարժիչի առանձնահատկությունները, ինչպիսիք են հանգույցների ավտոմատ մասշտաբավորումը, GKE-ն կարող է ավտոմատ կերպով հայտնաբերել առկախ վիճակ և ստեղծել լրացուցիչ հանգույցներ:
Եթե դուք հետագայում սպառեք հանգույցի հզորությունը, ավտոմատ մասշտաբը կնվազեցնի հանգույցների քանակը՝ գումար խնայելու համար: Ահա թե ինչու Kubernetes-ը պլանավորում է պատիճները՝ հիմնվելով հարցումների վրա: Այնուամենայնիվ, սահմանը կարող է ավելի բարձր լինել, քան հարցումները, և որոշ դեպքերում հանգույցը կարող է իրականում սպառվել ռեսուրսներով: Այս պետությունը մենք անվանում ենք գերպարտավորության վիճակ։
Ինչպես ասացի, եթե մենք խոսում ենք պրոցեսորի մասին, Kubernetes-ը կսկսի խեղդել պատիճները: Յուրաքանչյուր պատիճ կստանա այնքան, որքան պահանջել է, բայց եթե այն չհասնի սահմանին, կսկսվի շնչափողությունը:
Ինչ վերաբերում է հիշողության ռեսուրսներին, Kubernetes-ը պետք է որոշումներ կայացնի այն մասին, թե որ պատիճները պետք է սպանի և որոնք պահի այնքան ժամանակ, քանի դեռ չեք ազատել համակարգի ռեսուրսները, հակառակ դեպքում ամբողջ համակարգը կխափանի:
Եկեք պատկերացնենք մի սցենար, երբ դուք ունեք մեքենա, որը հասել է իր հիշողության սահմանաչափին. ինչպե՞ս կվարվի 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
