Kubernetes-ին լիովին տիրապետելու համար դուք պետք է իմանաք կլաստերի ռեսուրսների մասշտաբավորման տարբեր եղանակներ , սա Kubernetes-ի գլխավոր խնդիրներից է։ Մենք բարձր մակարդակի ակնարկ ենք ներկայացրել հորիզոնական և ուղղահայաց ավտոմատ մասշտաբավորման և կլաստերի չափափոխման մեխանիզմների, ինչպես նաև դրանք արդյունավետ օգտագործելու վերաբերյալ առաջարկությունների վերաբերյալ:
Հոդված թարգմանվել է այն թիմի կողմից, որն իրականացրել է autoscaling-ը .
Ինչու է կարևոր մտածել մասշտաբի մասին
- գործիք ռեսուրսների կառավարման և նվագախմբի համար: Իհարկե, հաճելի է շտկել բլոկների տեղակայման, մոնիտորինգի և կառավարելու հիանալի առանձնահատկությունները (կետը բեռնարկղերի խումբ է, որոնք գործարկվում են ի պատասխան հարցման):
Այնուամենայնիվ, դուք պետք է մտածեք նաև հետևյալ հարցերի մասին.
- Ինչպե՞ս մեծացնել մոդուլները և հավելվածները:
- Ինչպե՞ս պահպանել բեռնարկղերը գործառնական և արդյունավետ:
- Ինչպե՞ս արձագանքել օգտվողների կողմից կոդի և աշխատանքային ծանրաբեռնվածության մշտական փոփոխություններին:
Kubernetes կլաստերների կազմաձևումը ռեսուրսների և կատարողականի հավասարակշռման համար կարող է դժվար լինել և պահանջում է փորձագիտական գիտելիքներ Kubernetes-ի ներքին աշխատանքի վերաբերյալ: Ձեր դիմումի կամ ծառայությունների ծանրաբեռնվածությունը կարող է տատանվել օրվա ընթացքում կամ նույնիսկ մեկ ժամվա ընթացքում, ուստի հավասարակշռությունը լավագույնս դիտարկվում է որպես շարունակական գործընթաց:
Kubernetes-ի ավտոմատ մասշտաբավորման մակարդակները
Արդյունավետ ավտոմատ մասշտաբավորումը պահանջում է համակարգում երկու մակարդակների միջև.
- Pod մակարդակը, ներառյալ հորիզոնական (Horizontal Pod Autoscaler, HPA) և ուղղահայաց ավտոմասշտիչ (Vertical Pod Autoscaler, VPA): Սա մեծացնում է ձեր բեռնարկղերի համար հասանելի ռեսուրսները:
- Կլաստերի մակարդակը, որը կառավարվում է Cluster Autoscaler-ի (CA) կողմից, որը մեծացնում կամ նվազեցնում է կլաստերի ներսում գտնվող հանգույցների թիվը:
Հորիզոնական Autoscaler (HPA) մոդուլ
Ինչպես անունն է հուշում, HPA-ն մեծացնում է պատիճների կրկնօրինակների քանակը: Deops-ների մեծ մասն օգտագործում է պրոցեսորի և հիշողության բեռնվածությունը որպես կրկնօրինակների քանակի փոփոխման գործարկիչներ: Այնուամենայնիվ, հնարավոր է համակարգի մասշտաբը հիմնվելով նրանց կամ նույնիսկ .
Բարձր մակարդակի HPA գործառնական դիագրամ.
- HPA-ն անընդհատ ստուգում է տեղադրման ժամանակ նշված մետրային արժեքները 30 վայրկյան կանխադրված ընդմիջումով:
- HPA-ն փորձում է ավելացնել մոդուլների քանակը, եթե հասնի նշված շեմը:
- HPA-ն թարմացնում է կրկնօրինակների թիվը տեղակայման/կրկնօրինակման կարգավորիչում:
- Այնուհետև տեղակայման/կրկնօրինակման կարգավորիչը տեղակայում է ցանկացած անհրաժեշտ լրացուցիչ մոդուլ:
HPA-ն սկսում է մոդուլի տեղակայման գործընթացը, երբ հասնում է մետրային շեմը
HPA-ն օգտագործելիս հաշվի առեք հետևյալը.
- Նախնական HPA ստուգման միջակայքը 30 վայրկյան է: Այն սահմանվում է դրոշով horizontal-pod-autoscaler-sync-period վերահսկիչի մենեջերում:
- Նախնական հարաբերական սխալը 10% է:
- Մոդուլների քանակի վերջին ավելացումից հետո HPA-ն ակնկալում է, որ չափումները կկայունանան երեք րոպեի ընթացքում: Այս միջակայքը սահմանվում է դրոշի կողմից horizontal-pod-autoscaler-upscale-delay.
- Մոդուլների քանակի վերջին կրճատումից հետո HPA-ն սպասում է հինգ րոպե կայունանալու համար: Այս միջակայքը սահմանվում է դրոշի կողմից horizontal-pod-autoscaler-downscale-delay.
- HPA-ն լավագույնս աշխատում է տեղակայման օբյեկտների, այլ ոչ թե վերարտադրման կարգավորիչների հետ: Հորիզոնական ավտոմատ մասշտաբավորումն անհամատեղելի է շարժակազմի թարմացման հետ, որն ուղղակիորեն շահարկում է կրկնօրինակման կարգավորիչները: Տեղակայման դեպքում կրկնօրինակների քանակն ուղղակիորեն կախված է տեղակայման օբյեկտներից:
Պատիճների ուղղահայաց ավտոմատ մասշտաբավորում
Ուղղահայաց ավտոմատ մասշտաբավորումը (VPA) ավելի շատ (կամ պակաս) CPU-ի ժամանակ կամ հիշողություն է հատկացնում գոյություն ունեցող բլոկներին: Հարմար է պետական կամ քաղաքացիություն չունեցող պատիճների համար, բայց հիմնականում նախատեսված է պետական ծառայությունների համար: Այնուամենայնիվ, դուք կարող եք նաև օգտագործել VPA-ն քաղաքացիություն չունեցող մոդուլների համար, եթե ձեզ անհրաժեշտ է ավտոմատ կերպով կարգավորել սկզբնապես հատկացված ռեսուրսների քանակը:
VPA-ն նաև արձագանքում է OOM (հիշողությունից դուրս) իրադարձություններին: Պրոցեսորի ժամանակն ու հիշողությունը փոխելու համար անհրաժեշտ է վերագործարկել պատյանները: Վերագործարկվելիս VPA-ն հարգում է հատկացման բյուջեն () երաշխավորել մոդուլների նվազագույն պահանջվող քանակը:
Դուք կարող եք սահմանել նվազագույն և առավելագույն ռեսուրսները յուրաքանչյուր մոդուլի համար: Այսպիսով, դուք կարող եք սահմանափակել հատկացված հիշողության առավելագույն քանակը մինչև 8 ԳԲ: Սա օգտակար է, եթե ընթացիկ հանգույցները հաստատ չեն կարող մեկ կոնտեյների համար հատկացնել 8 ԳԲ-ից ավելի հիշողություն: Մանրամասն բնութագրերը և գործառնական մեխանիզմը նկարագրված են .
Բացի այդ, VPA-ն ունի հետաքրքիր առաջարկությունների գործառույթ (VPA Recommender): Այն վերահսկում է ռեսուրսների օգտագործումը և բոլոր մոդուլների OOM իրադարձությունները՝ առաջարկելու հիշողության և պրոցեսորի ժամանակի նոր արժեքներ՝ հիմնված պատմական չափումների վրա հիմնված խելացի ալգորիթմի վրա: Կա նաև API, որը վերցնում է pod handle և վերադարձնում առաջարկվող ռեսուրսների արժեքները:
Հարկ է նշել, որ VPA Recommender-ը չի հետևում ռեսուրսի «սահմանաչափին»: Սա կարող է հանգեցնել նրան, որ մոդուլը մոնոպոլիզացնի ռեսուրսները հանգույցներում: Ավելի լավ է սահմանը սահմանել անվանատարածքի մակարդակում՝ հիշողության կամ պրոցեսորի հսկայական սպառումից խուսափելու համար:
Բարձր մակարդակի VPA գործառնական սխեմա.
- VPA-ն անընդհատ ստուգում է տեղադրման ժամանակ նշված մետրային արժեքները 10 վայրկյան կանխադրված ընդմիջումով:
- Եթե նշված շեմը հասնում է, VPA-ն փորձում է փոխել հատկացված ռեսուրսների քանակը:
- VPA-ն թարմացնում է ռեսուրսների քանակը տեղակայման/կրկնօրինակման վերահսկիչի ներսում:
- Երբ մոդուլները վերագործարկվում են, բոլոր նոր ռեսուրսները կիրառվում են ստեղծված ատյանների վրա:
VPA-ն ավելացնում է անհրաժեշտ քանակությամբ ռեսուրսներ
Խնդրում ենք հիշել հետևյալ կետերը VPA-ի օգտագործման ժամանակ.
- Scaling-ը պահանջում է պատի պարտադիր վերագործարկում: Սա անհրաժեշտ է փոփոխություններ կատարելուց հետո անկայուն շահագործումից խուսափելու համար: Հուսալիության համար մոդուլները վերագործարկվում և բաշխվում են հանգույցների վրա՝ հիմնվելով նոր հատկացված ռեսուրսների վրա:
- VPA-ն և HPA-ն դեռ համատեղելի չեն միմյանց հետ և չեն կարող աշխատել միևնույն պատիճների վրա: Եթե դուք օգտագործում եք չափման երկու մեխանիզմները նույն կլաստերում, համոզվեք, որ ձեր կարգավորումները թույլ չեն տալիս դրանք ակտիվացնել նույն օբյեկտների վրա:
- VPA-ն կարգավորում է բեռնարկղերի հարցումները ռեսուրսների համար՝ հիմնված միայն անցյալ և ընթացիկ օգտագործման վրա: Այն չի սահմանում ռեսուրսների օգտագործման սահմանափակումներ: Կարող են խնդիրներ առաջանալ, երբ հավելվածները ճիշտ չեն աշխատում և սկսում են ավելի ու ավելի շատ ռեսուրսներ տիրանալ, դա կհանգեցնի նրան, որ Kubernetes-ն անջատի այս pod-ը:
- VPA-ն դեռ զարգացման վաղ փուլում է։ Պատրաստ եղեք, որ մոտ ապագայում համակարգը կարող է որոշակի փոփոխությունների ենթարկվել։ Դուք կարող եք կարդալ մասին и . Այսպիսով, նախատեսվում է իրականացնել VPA-ի և HPA-ի համատեղ գործարկումը, ինչպես նաև մոդուլների տեղակայումը դրանց համար ուղղահայաց ավտոմասշտաբացման քաղաքականության հետ մեկտեղ (օրինակ՝ հատուկ պիտակը «պահանջում է VPA»):
Kubernetes կլաստերի ավտոմատ մասշտաբավորում
Cluster Autoscaler-ը (CA) փոխում է հանգույցների քանակը՝ ելնելով սպասող պատյանների քանակից: Համակարգը պարբերաբար ստուգում է առկախ մոդուլների առկայությունը և մեծացնում է կլաստերի չափը, եթե ավելի շատ ռեսուրսներ են անհրաժեշտ, և եթե կլաստերը չի գերազանցում սահմանված սահմանները: CA-ն շփվում է ամպային ծառայության մատակարարի հետ, խնդրում է նրանից լրացուցիչ հանգույցներ կամ թողարկում անգործուն հանգույցները: CA-ի առաջին ընդհանուր հասանելի տարբերակը ներկայացվել է Kubernetes 1.8-ում:
SA-ի գործունեության բարձր մակարդակի սխեման.
- CA-ն ստուգում է առկախ մոդուլների առկայությունը 10 վայրկյան կանխադրված ընդմիջումով:
- Եթե մեկ կամ մի քանի pods գտնվում են սպասման վիճակում, քանի որ կլաստերը չունի բավարար հասանելի ռեսուրսներ դրանք բաշխելու համար, այն փորձում է տրամադրել մեկ կամ մի քանի լրացուցիչ հանգույցներ:
- Երբ ամպային ծառայությունների մատակարարը հատկացնում է անհրաժեշտ հանգույցը, այն միանում է կլաստերին և պատրաստ է սպասարկելու պատյանները:
- Kubernetes-ի ժամանակացույցը բաժանում է սպասող pods նոր հանգույցին: Եթե դրանից հետո որոշ մոդուլներ դեռ մնում են սպասողական վիճակում, գործընթացը կրկնվում է և նոր հանգույցներ են ավելացվում կլաստերին։
Կլաստերային հանգույցների ավտոմատ ապահովում ամպի մեջ
CA-ն օգտագործելիս հաշվի առեք հետևյալը.
- CA-ն ապահովում է, որ կլաստերի բոլոր պատյանները գործելու տեղ ունենան՝ անկախ պրոցեսորի ծանրաբեռնվածությունից: Այն նաև փորձում է ապահովել, որ կլաստերում ավելորդ հանգույցներ չլինեն։
- CA-ն գրանցում է սանդղակի անհրաժեշտությունը մոտավորապես 30 վայրկյան հետո:
- Երբ հանգույցն այլևս անհրաժեշտ չէ, CA-ն կանխադրված է սպասում 10 րոպե, նախքան համակարգը դուրս բերելը:
- Autoscaling համակարգը ունի էքսպանդերի հայեցակարգ: Սրանք տարբեր ռազմավարություններ են հանգույցների խումբ ընտրելու համար, որոնց կավելացվեն նոր հանգույցներ:
- Օգտագործեք տարբերակը պատասխանատու կերպով cluster-autoscaler.kubernetes.io/safe-to-evict (ճշմարիտ). Եթե դուք տեղադրեք շատ պատյաններ, կամ եթե դրանցից շատերը ցրված են բոլոր հանգույցներում, դուք մեծապես կկորցնեք կլաստերը մեծացնելու ունակությունը:
- Օգտագործեք կանխելու պատիճների ջնջումը, ինչը կարող է հանգեցնել ձեր հավելվածի մասերի ամբողջական կոտրմանը:
Ինչպես են Kubernetes autoscalers փոխազդում միմյանց հետ
Կատարյալ ներդաշնակության համար ավտոմատ մասշտաբավորումը պետք է կիրառվի ինչպես pod մակարդակում (HPA/VPA), այնպես էլ կլաստերի մակարդակում: Նրանք փոխազդում են միմյանց հետ համեմատաբար պարզ.
- HPA-ները կամ VPA-ները թարմացնում են պատիճների կրկնօրինակները կամ ռեսուրսները, որոնք հատկացված են գոյություն ունեցող բլոկներին:
- Եթե պլանավորված մասշտաբի համար բավարար հանգույցներ չկան, CA-ն նկատում է սպասողական վիճակում գտնվող պատյանների առկայությունը:
- CA-ն հատկացնում է նոր հանգույցներ:
- Մոդուլները բաշխվում են նոր հանգույցների վրա:
Համատեղ Kubernetes սանդղակի համակարգ
Ընդհանուր սխալներ Kubernetes-ի ավտոմատ մասշտաբավորման մեջ
Կան մի քանի ընդհանուր խնդիրներ, որոնք առաջանում են, երբ փորձում են իրականացնել autoscaling:
HPA-ն և VPA-ն կախված են չափիչներից և որոշ պատմական տվյալներից: Եթե բավարար ռեսուրսներ հատկացվեն, մոդուլները նվազագույնի կհասցվեն և չեն կարողանա չափումներ ստեղծել: Այս դեպքում, autoscaling երբեք տեղի չի ունենա:
Սանդղակավորման գործողությունն ինքնին ժամանակի զգայուն է: Մենք ցանկանում ենք, որ մոդուլները և կլաստերը արագորեն մեծանան՝ նախքան օգտվողները նկատեն որևէ խնդիր կամ ձախողում: Հետևաբար, պետք է հաշվի առնել պատիճների և կլաստերի չափման միջին ժամանակը:
Իդեալական սցենար - 4 րոպե.
- 30 վայրկյան. Թարմացնել թիրախային չափումները՝ 30−60 վայրկյան:
- 30 վայրկյան. HPA-ն ստուգում է մետրային արժեքները՝ 30 վայրկյան:
- 2 վայրկյանից պակաս: Պոդերը ստեղծվում են և անցնում սպասման վիճակի` 1 վայրկյան:
- 2 վայրկյանից պակաս: CA-ն տեսնում է սպասող մոդուլները և զանգեր է ուղարկում մատակարարման հանգույցներին՝ 1 վայրկյան:
- 3 րոպե. Ամպային մատակարարը հատկացնում է հանգույցներ: K8-ը սպասում է, մինչև պատրաստ լինեն՝ մինչև 10 րոպե (կախված մի քանի գործոններից):
Վատագույն դեպք (ավելի իրատեսական) սցենար - 12 րոպե.
- 30 վայրկյան. Թարմացրեք թիրախային չափումները:
- 30 վայրկյան. HPA-ն ստուգում է մետրային արժեքները:
- 2 վայրկյանից պակաս: Փայտերը ստեղծվում են և մտնում են սպասման վիճակ:
- 2 վայրկյանից պակաս: CA-ն տեսնում է սպասող մոդուլները և զանգեր է կատարում հանգույցները տրամադրելու համար:
- 10 րոպե. Ամպային մատակարարը հատկացնում է հանգույցներ: K8-ը սպասում է, մինչև պատրաստ լինեն: Սպասման ժամանակը կախված է մի քանի գործոններից, ինչպիսիք են վաճառողի ուշացումը, ՕՀ-ի հետաձգումը և օժանդակ գործիքները:
Մի շփոթեք ամպային մատակարարների ընդլայնման մեխանիզմները մեր CA-ի հետ: Վերջինս աշխատում է Kubernetes կլաստերի ներսում, մինչդեռ ամպային մատակարարի շարժիչը գործում է հանգույցների բաշխման հիման վրա: Նա չգիտի, թե ինչ է կատարվում ձեր պատիճների կամ հավելվածի հետ: Այս համակարգերը գործում են զուգահեռաբար:
Ինչպես կառավարել մասշտաբը Kubernetes-ում
- Kubernetes-ը ռեսուրսների կառավարման և նվագախմբի գործիք է: Փոդների և կլաստերի ռեսուրսների կառավարման գործողությունները կարևորագույն իրադարձություն են Kubernetes-ի յուրացման գործում:
- Հասկացեք pod scalability-ի տրամաբանությունը՝ հաշվի առնելով HPA-ն և VPA-ն:
- CA-ն պետք է օգտագործվի միայն այն դեպքում, եթե դուք լավ հասկանում եք ձեր պատյանների և տարաների կարիքները:
- Կլաստերը օպտիմալ կերպով կարգավորելու համար դուք պետք է հասկանաք, թե ինչպես են տարբեր մասշտաբային համակարգեր աշխատում միասին:
- Սանդղման ժամանակը գնահատելիս հիշեք վատագույն և լավագույն դեպքերի սցենարները:
Source: www.habr.com