🥇 Ինը խորհուրդ Kubernetes-ի աշխատանքը բարելավելու համար

Բարեւ բոլորին! Ես Օլեգ Սիդորենկովն եմ, աշխատում եմ DomClick-ում որպես ենթակառուցվածքի թիմի ղեկավար: Մենք օգտագործում ենք Cube-ը վաճառքի համար ավելի քան երեք տարի, և այս ընթացքում մենք շատ տարբեր հետաքրքիր պահեր ենք ապրել դրա հետ։ Այսօր ես ձեզ կասեմ, թե ինչպես ճիշտ մոտեցմամբ դուք կարող եք ավելի շատ արդյունավետություն քամել վանիլային Kubernetes-ից ձեր կլաստերի համար: Պատրաստ է, որ գնա:

Դուք բոլորդ լավ գիտեք, որ Kubernetes-ը լայնածավալ բաց կոդով համակարգ է կոնտեյներային նվագախմբավորման համար. լավ, կամ 5 երկուական, որոնք կախարդություն են անում՝ կառավարելով ձեր միկրոծառայությունների կյանքի ցիկլը սերվերային միջավայրում: Բացի այդ, սա բավականին ճկուն գործիք է, որը կարելի է հավաքել Lego կոնստրուկտորի նման՝ տարբեր առաջադրանքների համար առավելագույն հարմարեցման համար:

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

1. Հետևեք թիմի և հավելվածի ռեսուրսներին

Ամենաբնական, բայց արդյունավետ մեթոդներից մեկը հարցումների/սահմանափակումների ներդրումն է։ Հավելվածներն առանձնացրեք ըստ անվանատարածքների, իսկ անվանատարածքները՝ ըստ մշակողների թիմերի: Սահմանեք հավելվածը նախքան պրոցեսորի ժամանակի, հիշողության, ժամանակավոր պահպանման արժեքները տեղակայելը:

resources:
   requests:
     memory: 2Gi
     cpu: 250m
   limits:
     memory: 4Gi
     cpu: 500m

Փորձով մենք եկանք եզրակացության. չարժե 5 անգամից ավելի ուռճացնել սահմանաչափերից պահանջները։ Կլաստերի չափը հաշվարկվում է հարցումների հիման վրա, և եթե հավելվածը սահմանում եք ռեսուրսների տարբերության վրա, օրինակ, 10-XNUMX անգամ, ապա պատկերացրեք, թե ինչ կլինի ձեր հանգույցի հետ, երբ այն լցված է պատյաններով և հանկարծ բեռ է ստանում: Ոչ մի լավ բան։ Նվազագույնը` շնչափող, իսկ առավելագույնը` հրաժեշտ տվեք աշխատակցին և մնացած հանգույցների վրա ցիկլային բեռ ստացեք այն բանից հետո, երբ պատյանները կսկսեն շարժվել:

Բացի այդ, օգնությամբ limitranges Դուք կարող եք սկզբում սահմանել կոնտեյների համար ռեսուրսների արժեքները՝ նվազագույն, առավելագույն և լռելյայն.

➜  ~ kubectl describe limitranges --namespace ops
Name:       limit-range
Namespace:  ops
Type        Resource           Min   Max   Default Request  Default Limit  Max Limit/Request Ratio
----        --------           ---   ---   ---------------  -------------  -----------------------
Container   cpu                50m   10    100m             100m           2
Container   ephemeral-storage  12Mi  8Gi   128Mi            4Gi            -
Container   memory             64Mi  40Gi  128Mi            128Mi          2

Հիշեք սահմանափակել անվանատարածքի ռեսուրսները, որպեսզի մեկ հրաման չկարողանա վերցնել կլաստերի բոլոր ռեսուրսները.

➜  ~ kubectl describe resourcequotas --namespace ops
Name:                   resource-quota
Namespace:              ops
Resource                Used          Hard
--------                ----          ----
limits.cpu              77250m        80
limits.memory           124814367488  150Gi
pods                    31            45
requests.cpu            53850m        80
requests.memory         75613234944   150Gi
services                26            50
services.loadbalancers  0             0
services.nodeports      0             0

Ինչպես տեսնում եք նկարագրությունից resourcequotas, եթե ops հրամանը ցանկանում է տեղակայել pods, որոնք կսպառեն ևս 10 պրոցեսոր, ապա ժամանակացույցը թույլ չի տա դա անել և սխալ կթողնի.

Error creating: pods "nginx-proxy-9967d8d78-nh4fs" is forbidden: exceeded quota: resource-quota, requested: limits.cpu=5,requests.cpu=5, used: limits.cpu=77250m,requests.cpu=53850m, limited: limits.cpu=10,requests.cpu=10

Նմանատիպ խնդիր լուծելու համար կարող եք գրել գործիք, օրինակ, ինչպես այս, որը կարող է պահել և կատարել հրամանատարական ռեսուրսների վիճակը:

2. Ընտրեք լավագույն ֆայլերի պահեստը

Այստեղ ես կցանկանայի անդրադառնալ մշտական ծավալների թեմային և Kubernetes աշխատանքային հանգույցների սկավառակի ենթահամակարգին: Հուսով եմ, որ ոչ ոք չի օգտագործում «Cube» HDD-ի վրա արտադրության մեջ, բայց երբեմն նույնիսկ սովորական SSD-ն արդեն բավարար չէ: Մենք բախվեցինք այնպիսի խնդրի, որ տեղեկամատյանները սպանում էին սկավառակը I/O գործողություններով, և այստեղ շատ լուծումներ չկան.

Օգտագործեք բարձր արդյունավետության SSD-ներ կամ անցեք NVMe-ին (եթե դուք կառավարում եք ձեր սեփական սարքաշարը):
Նվազեցնել հատումների մակարդակը:
Կատարեք սկավառակը բռնաբարող պատյանների «խելացի» հավասարակշռում (podAntiAffinity).

Վերևի սքրինշոթը ցույց է տալիս, թե ինչ է տեղի ունենում nginx-ingress-controller-ի տակ սկավառակի հետ, երբ access_logs-ը միացված է (~12k logs/վրկ): Նման վիճակը, իհարկե, կարող է հանգեցնել այս հանգույցի բոլոր հավելվածների դեգրադացմանը:

Ինչ վերաբերում է PV-ին, ավաղ, ես ամեն ինչ չեմ փորձել։ տեսակներ Մշտական ծավալներ. Օգտագործեք լավագույն տարբերակը, որը հարմար է ձեզ: Մեր երկրում պատմականորեն պատահել է, որ ծառայությունների մի փոքր մասի կարիք ունեն RWX ծավալները, և շատ վաղուց նրանք սկսել են օգտագործել NFS պահեստավորումն այս առաջադրանքի համար։ Էժան և ... բավական: Իհարկե, մենք նրա հետ կերել ենք - առողջ եղեք, բայց մենք սովորեցինք, թե ինչպես կարգավորել նրան, և նրա գլուխն այլևս չի ցավում: Եվ եթե հնարավոր է, անցեք S3 օբյեկտների պահպանմանը:

3. Կառուցեք օպտիմիզացված պատկերներ

Ավելի լավ է օգտագործել կոնտեյներով օպտիմիզացված պատկերներ, որպեսզի Kubernetes-ը կարողանա դրանք ավելի արագ բերել և ավելի արդյունավետ կերպով կատարել:

Օպտիմալացումը նշանակում է, որ պատկերները.

պարունակում է միայն մեկ հավելված կամ կատարում է միայն մեկ գործառույթ.
փոքր չափս, քանի որ մեծ պատկերները ավելի վատ են փոխանցվում ցանցով.
ունեն առողջության և պատրաստվածության վերջնական կետեր, որոնք Kubernetes-ը կարող է օգտագործել՝ անգործության դեպքում գործողություններ ձեռնարկելու համար.
օգտագործել կոնտեյներների համար հարմար օպերացիոն համակարգեր (օրինակ՝ Alpine կամ CoreOS), որոնք ավելի դիմացկուն են կազմաձևման սխալներին.
օգտագործեք բազմաստիճան կառուցումներ, որպեսզի կարողանաք տեղակայել միայն կազմված հավելվածները, այլ ոչ ուղեկցող աղբյուրները:

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

Նվազեցված ցանցի բեռը ամբողջ կլաստերի վրա:
Կոնտեյների գործարկման ժամանակի կրճատում:
Ձեր ամբողջ Docker ռեեստրի ավելի փոքր չափը:

4. Օգտագործեք DNS քեշ

Եթե խոսենք բարձր բեռների մասին, ապա առանց կլաստերի DNS համակարգը կարգավորելու, կյանքը բավականին անմխիթար է: Ժամանակին Kubernetes-ի մշակողները աջակցեցին իրենց kube-dns լուծումը: Այն ներդրվել է նաև մեր երկրում, բայց այս ծրագրաշարը առանձնապես չի կարգավորվել և չի տվել պահանջվող կատարումը, թեև, թվում է, խնդիրը պարզ է: Հետո հայտնվեցին coredns, որոնց մենք անցանք և չգիտեինք վիշտը, հետագայում այն դարձավ լռելյայն DNS ծառայություն K8-ներում։ Ինչ-որ պահի մենք աճեցինք մինչև 40 հազար ռ/վ դեպի DNS համակարգ, և այս լուծումը նույնպես բավարար չէր։ Բայց, հաջողակ պատահականությամբ, Nodelocaldns-ը դուրս եկավ, aka node local cache, aka NodeLocal DNSCache.

Ինչու ենք մենք օգտագործում այն: Linux-ի միջուկում կա մի սխալ, որը, երբ UDP-ի միջոցով conntrack NAT-ի միջոցով բազմակի մուտք է գործում, հանգեցնում է conntrack աղյուսակներին գրելու մրցավազքի, և NAT-ի միջոցով տրաֆիկի մի մասը կորչում է (Ծառայության միջոցով յուրաքանչյուր ուղևորություն NAT է): Nodelocaldns-ը լուծում է այս խնդիրը՝ ձերբազատվելով NAT-ից և թարմացնելով TCP կապը դեպի վերընթաց DNS-ին, ինչպես նաև տեղային քեշավորելով վերընթաց DNS հարցումները (ներառյալ կարճ 5 վայրկյան բացասական քեշը):

5. Հորիզոնական և ուղղահայաց մասշտաբները ավտոմատ կերպով չափեք

Կարո՞ղ եք վստահորեն ասել, որ ձեր բոլոր միկրոսերվիսները պատրաստ են բեռի երկու-երեք անգամ ավելացմանը: Ինչպե՞ս ճիշտ բաշխել ռեսուրսները ձեր հավելվածներին: Աշխատանքային ծանրաբեռնվածությունից ավելի աշխատած մի քանի պատիճ պահելը կարող է ավելորդ լինել, և դրանց հետ մեկտեղ պահելը վտանգի տակ է դնում ծառայության երթևեկության հանկարծակի աճը: Ոսկե միջինը օգնում է հասնել բազմապատկման հմայքին այնպիսի ծառայություններ, ինչպիսիք են Հորիզոնական Pod Autoscaler и Ուղղահայաց pod Autoscaler.

VPA թույլ է տալիս ավտոմատ կերպով բարձրացնել ձեր բեռնարկղերի հարցումները/սահմանաչափերը պատիճում՝ հիմնվելով իրական օգտագործման վրա: Ինչպե՞ս կարող է դա օգտակար լինել: Եթե դուք ունեք Pods, որոնք ինչ-ինչ պատճառներով չեն կարող չափավորվել հորիզոնական (ինչը լիովին հուսալի չէ), ապա կարող եք փորձել վստահել VPA-ին իր ռեսուրսները փոխելու համար: Դրա առանձնահատկությունն առաջարկությունների համակարգ է, որը հիմնված է մետրային սերվերի պատմական և ընթացիկ տվյալների վրա, այնպես որ, եթե դուք չեք ցանկանում ինքնաբերաբար փոխել հարցումները/սահմանները, կարող եք պարզապես վերահսկել ձեր կոնտեյների համար առաջարկվող ռեսուրսները և օպտիմիզացնել կարգավորումները՝ խնայելու պրոցեսորը և հիշողությունը: կլաստերի մեջ։

Պատկերը վերցված է՝ https://levelup.gitconnected.com/kubernetes-autoscaling-101-cluster-autoscaler-horizontal-pod-autoscaler-and-vertical-pod-2a441d9ad231

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

Օրինակ, ահա տիպիկ պատի կարգավորումները.

resources:
   requests:
     memory: 250Mi
     cpu: 200m
   limits:
     memory: 500Mi
     cpu: 350m

Առաջարկությունների շարժիչը որոշում է, որ ձեր հավելվածին անհրաժեշտ է 300 մ պրոցեսոր և 500 Mi՝ ճիշտ աշխատելու համար: Դուք կստանաք այս կարգավորումները.

resources:
   requests:
     memory: 500Mi
     cpu: 300m
   limits:
     memory: 1000Mi
     cpu: 525m

Ինչպես նշվեց վերևում, սա համամասնական մասշտաբ է՝ հիմնված մանիֆեստում հարցումների/սահմանների հարաբերակցության վրա.

Պրոցեսոր՝ 200 մ → 300 մ՝ հարաբերակցություն 1:1.75;
Հիշողություն՝ 250 Mi → 500 Mi: 1:2 հարաբերակցություն:

նկատմամբ HPA, ապա գործողության մեխանիզմն ավելի թափանցիկ է։ Շեմերը սահմանվում են այնպիսի չափումների համար, ինչպիսիք են պրոցեսորը և հիշողությունը, և եթե բոլոր կրկնօրինակների միջինը գերազանցում է շեմը, ապա հավելվածը մասշտաբվում է +1 կետով, մինչև արժեքը իջնի շեմից ցածր կամ մինչև կրկնօրինակների առավելագույն քանակի հասնելը:

Պատկերը վերցված է՝ https://levelup.gitconnected.com/kubernetes-autoscaling-101-cluster-autoscaler-horizontal-pod-autoscaler-and-vertical-pod-2a441d9ad231

Ի հավելումն սովորական չափումների, ինչպիսիք են պրոցեսորը և հիշողությունը, դուք կարող եք սահմանել շեմեր ձեր հատուկ Prometheus չափումների վրա և աշխատել դրանց հետ, եթե կարծում եք, որ սա ամենաճշգրիտ միջոցն է՝ որոշելու, թե երբ չափավորել ձեր հավելվածը: Հենց որ հավելվածը կայունանա նշված մետրային շեմից ցածր, HPA-ն կսկսի կրճատել պատյանները մինչև կրկնօրինակների նվազագույն թիվը կամ մինչև բեռը համապատասխանի նշված շեմին:

6. Մի մոռացեք Node Affinity-ի և Pod Affinity-ի մասին

Ոչ բոլոր հանգույցներն են աշխատում նույն սարքաշարի վրա, և ոչ բոլոր հանգույցները պետք է աշխատեն հաշվողական ինտենսիվ ծրագրեր: Kubernetes-ը թույլ է տալիս նշել հանգույցների և պատիճների մասնագիտացումը՝ օգտագործելով Հանգույցի մերձեցում и Pod Affinity.

Եթե դուք ունեք հանգույցներ, որոնք հարմար են հաշվողական ինտենսիվ գործողությունների համար, ապա առավելագույն արդյունավետության համար ավելի լավ է հավելվածները կապել համապատասխան հանգույցներին: Դա անելու համար օգտագործեք nodeSelector հանգույցի պիտակով:

Ենթադրենք, դուք ունեք երկու հանգույց CPUType=HIGHFREQ և մեծ քանակությամբ արագ միջուկներ, ևս մեկ MemoryType=HIGHMEMORY ավելի շատ հիշողություն և ավելի արագ կատարում: Ամենահեշտ ձևը հանգույցի տեղակայումն է HIGHFREQավելացնելով բաժինը spec այսպիսի ընտրիչ.

…
nodeSelector:
	CPUType: HIGHFREQ

Դա անելու ավելի ծախսատար և կոնկրետ միջոց օգտագործելն է nodeAffinity դաշտում affinity razdela spec. Երկու տարբերակ կա.

requiredDuringSchedulingIgnoredDuringExecutionկոշտ կարգավորում (ժամանակացույցը միայն հատուկ հանգույցների վրա կտեղակայի պատյաններ (և ոչ մի այլ տեղ));
preferredDuringSchedulingIgnoredDuringExecution: փափուկ կարգավորում (ժամանակացույցը կփորձի տեղակայվել կոնկրետ հանգույցներում, իսկ եթե չհաջողվի, կփորձի տեղակայվել հաջորդ հասանելի հանգույցում):

Դուք կարող եք նշել հատուկ շարահյուսություն հանգույցների պիտակները կառավարելու համար, օրինակ. In, NotIn, Exists, DoesNotExist, Gt կամ Lt. Այնուամենայնիվ, հիշեք, որ բարդ մեթոդները պիտակների երկար ցուցակներում կդանդաղեցնեն որոշումների կայացումը կրիտիկական իրավիճակներում: Այլ կերպ ասած, մի բարդացրեք:

Ինչպես նշվեց վերևում, Kubernetes-ը թույլ է տալիս սահմանել ընթացիկ պատերի կապը: Այսինքն՝ դուք կարող եք ստիպել, որ որոշակի պատյաններ աշխատեն այլ պատիճների հետ նույն հասանելիության գոտում (համապատասխան ամպերի համար) կամ հանգույցներում:

В podAffinity դաշտերը affinity razdela spec նույն դաշտերը հասանելի են, ինչ որ դեպքում nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution и preferredDuringSchedulingIgnoredDuringExecution. Միակ տարբերությունն այն է, որ matchExpressions կկապի պատյանները մի հանգույցի հետ, որն արդեն աշխատում է այդ պիտակով պատիճ:

More Kubernetes-ն առաջարկում է դաշտ podAntiAffinity, որը, ի հակադրություն, չի կապում պատիճը կոնկրետ պատիճներով հանգույցի հետ։

Արտահայտությունների մասին nodeAffinity Նույն խորհուրդը կարելի է տալ. աշխատեք կանոնները պահել պարզ և տրամաբանական, մի փորձեք ծանրաբեռնել պատիճը բարդ կանոնների հավաքածուով: Շատ հեշտ է ստեղծել կլաստերի պայմաններին չհամապատասխանող կանոն՝ լրացուցիչ բեռ դնելով ժամանակացույցի վրա և նսեմացնելով ընդհանուր կատարումը:

7. Տաքացումներ և հանդուրժողականություն

Ժամանակացույցը կառավարելու ևս մեկ տարբերակ կա: Եթե դուք ունեք մի մեծ կլաստեր՝ հարյուրավոր հանգույցներով և հազարավոր միկրոծառայություններով, ապա շատ դժվար է կանխել որոշակի հանգույցների տեղակայումը որոշակի հանգույցների կողմից:

Դրան օգնում է աղտոտման մեխանիզմը՝ արգելող կանոնները: Օրինակ, դուք կարող եք կանխել որոշ հանգույցների ներգործությունը որոշակի սցենարներում: Որոշակի հանգույցի վրա բիծ կիրառելու համար օգտագործեք տարբերակը taint kubectl-ում։ Նշեք բանալին և արժեքը, այնուհետև ներկեք նման NoSchedule կամ NoExecute:

$ kubectl taint nodes node10 node-role.kubernetes.io/ingress=true:NoSchedule

Հարկ է նաև նշել, որ ներկման մեխանիզմն ապահովում է երեք հիմնական էֆեկտ. NoSchedule, NoExecute и PreferNoSchedule.

NoSchedule նշանակում է, որ մինչև պատիճ ճշգրտման մեջ համապատասխան գրառում չկա tolerations, այն չի կարող տեղակայվել հանգույցում (այս օրինակում node10).
PreferNoSchedule - պարզեցված տարբերակ NoSchedule. Այս դեպքում ժամանակացույցը կփորձի չհատկացնել պատյաններ, որոնք չունեն համապատասխան գրառում: tolerations մեկ հանգույցի համար, բայց սա դժվար սահման չէ: Եթե կլաստերում ռեսուրսներ չկան, ապա պատիճները կսկսեն տեղակայվել այս հանգույցում:
NoExecute - այս էֆեկտը առաջացնում է պատիճների անհապաղ տարհանում, որոնք չունեն համապատասխան մուտք tolerations.

Հետաքրքիր է, որ այս վարքագիծը կարող է չեղարկվել՝ օգտագործելով հանդուրժողականության մեխանիզմը: Սա հարմար է, երբ կա «արգելված» հանգույց, և դրա վրա պետք է տեղադրել միայն ենթակառուցվածքային ծառայություններ: Ինչպե՞ս դա անել: Թույլ տվեք միայն այն պատյանները, որոնց համար կա համապատասխան հանդուրժողականություն:

Ահա թե ինչ տեսք կունենա պատիճը.

spec:
   tolerations:
     - key: "node-role.kubernetes.io/ingress"
        operator: "Equal"
        value: "true"
        effect: "NoSchedule"

Սա չի նշանակում, որ հաջորդ վերատեղակայման ժամանակ pod-ը կհարվածի հենց այս հանգույցին, սա Node Affinity մեխանիզմը չէ և nodeSelector. Բայց մի քանի առանձնահատկություններ համատեղելով՝ դուք կարող եք հասնել շատ ճկուն ժամանակացույցի կարգավորում:

8. Սահմանել Pod Deployment Priority

Միայն այն պատճառով, որ դուք կարգավորել եք pod-to-node կապերը, չի նշանակում, որ բոլոր պատյաններին պետք է վերաբերվել նույն առաջնահերթությամբ: Օրինակ, դուք կարող եք տեղադրել որոշ Pods մյուսներից առաջ:

Kubernetes-ն առաջարկում է Pod Priority-ը և Preemption-ը սահմանելու տարբեր եղանակներ: Պարամետրը բաղկացած է մի քանի մասից՝ օբյեկտ PriorityClass և դաշտերի նկարագրությունները priorityClassName պատիճ ճշգրտման մեջ: Դիտարկենք մի օրինակ.

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 99999
globalDefault: false
description: "This priority class should be used for very important pods only"

Մենք ստեղծում ենք PriorityClass, տվեք նրան անուն, նկարագրություն և արժեք։ Որքան բարձր value, այնքան բարձր է առաջնահերթությունը: Արժեքը կարող է լինել ցանկացած 32-բիթանոց ամբողջ թիվ 1-ից փոքր կամ հավասար: Ավելի բարձր արժեքները վերապահված են առաքելության համար կարևոր համակարգի պատյանների համար, որոնք սովորաբար չեն կարող կանխարգելվել: Վտարումը տեղի կունենա միայն այն դեպքում, եթե բարձր առաջնահերթություն ունեցող պատիճը շրջվելու տեղ չունենա, ապա որոշակի հանգույցից որոշ պատյաններ կտարհանվեն: Եթե այս մեխանիզմը չափազանց կոշտ է ձեզ համար, ապա կարող եք ավելացնել տարբերակը preemptionPolicy: Never, և այնուհետև չի լինի կանխարգելում, pod-ը կլինի առաջինը հերթում և կսպասի, որ ժամանակացույցը գտնի անվճար ռեսուրսներ դրա համար:

Հաջորդը, մենք ստեղծում ենք պատիճ, որում նշում ենք անունը priorityClassName:

apiVersion: v1
kind: Pod
metadata:
  name: static-web
  labels:
    role: myrole
 spec:
  containers:
    - name: web
      image: nginx
      ports:
        - name: web
          containerPort: 80
          protocol: TCP
  priorityClassName: high-priority

Կարող եք ստեղծել այնքան առաջնահերթ դասեր, որքան ցանկանում եք, չնայած խորհուրդ է տրվում չտարվել սրանով (ասենք՝ սահմանափակվեք ցածր, միջին և բարձր առաջնահերթությամբ):

Այսպիսով, անհրաժեշտության դեպքում, դուք կարող եք բարձրացնել կարևոր ծառայությունների տեղակայման արդյունավետությունը, ինչպիսիք են nginx-ingress-controller, coredns և այլն:

9. Օպտիմալացրեք ձեր ETCD կլաստերը

ETCD կարելի է անվանել ամբողջ կլաստերի ուղեղ: Շատ կարևոր է պահպանել այս տվյալների բազայի աշխատանքը բարձր մակարդակի վրա, քանի որ «Cube»-ում գործողությունների արագությունը կախված է դրանից: Բավականին ստանդարտ և միևնույն ժամանակ լավ լուծում կլինի գլխավոր հանգույցների վրա ETCD կլաստեր պահելը, որպեսզի նվազագույն ուշացում լինի kube-apiserver-ում: Եթե դա հնարավոր չէ, ապա տեղադրեք ETCD-ն հնարավորինս մոտ՝ մասնակիցների միջև լավ թողունակությամբ: Նաև ուշադրություն դարձրեք, թե ETCD-ից քանի հանգույց կարող է ընկնել առանց վնասելու կլաստերին:

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

Եթե մենք խոսում ենք ծառայության ստեղծման մասին, ապա կան մի քանի առաջարկություններ.

Ունեն լավ սարքավորում՝ ելնելով կլաստերի չափից (կարող եք կարդալ այստեղ).
Կարգավորեք մի քանի պարամետր, եթե դուք կլաստեր եք տարածել մի զույգ DC-ների կամ ձեր ցանցի և սկավառակների միջև, թողեք շատ ցանկալի (կարող եք կարդալ այստեղ).

Ամփոփում

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

Source: www.habr.com

Ինը Kubernetes կատարողական խորհուրդներ