Դեռևս 2016 թվականին մենք Բուֆերում ենք և այժմ մոտ 60 հանգույց (AWS-ում) և 1500 կոնտեյներ աշխատում են մեր k8s կլաստերի վրա, որոնք կառավարվում են . Այնուամենայնիվ, մենք փորձի և սխալի միջոցով անցանք միկրոսերվիսներին, և նույնիսկ k8-ի հետ մի քանի տարի աշխատելուց հետո մենք դեռ բախվում ենք նոր խնդիրների: Այս գրառման մեջ մենք կխոսենք պրոցեսորի սահմանափակումներըԻնչու՞ մենք կարծում էինք, որ դրանք լավ պրակտիկա են, և ինչու նրանք ի վերջո այնքան էլ լավ չեն եղել:
Պրոցեսորի սահմանափակումներ և շնչափողություն
Ինչպես Kubernetes-ի շատ այլ օգտվողներ, . Առանց նման պարամետրի, հանգույցի կոնտեյներները կարող են վերցնել պրոցեսորի ողջ հզորությունը, որն իր հերթին առաջացնում է կարևոր Kubernetes գործընթացներ (օրինակ. kubelet) կդադարի պատասխանել հարցումներին: Այսպիսով, CPU-ի սահմանաչափերը ձեր հանգույցները պաշտպանելու լավ միջոց է:
Պրոցեսորի սահմանաչափերը սահմանում են կոնտեյների առավելագույն պրոցեսորի ժամանակը, որը այն կարող է օգտագործել որոշակի ժամանակահատվածի համար (կանխադրվածը 100 մվ է), և կոնտեյները երբեք չի գերազանցի այս սահմանը: Kubernetes-ում համար շնչափող կոնտեյներ և կանխել դրա սահմանը գերազանցելը, օգտագործվում է հատուկ գործիք , սակայն պրոցեսորի արհեստական այս սահմանափակումները վերջանում են, որ վնասում են կատարողականությունը և մեծացնում ձեր կոնտեյների արձագանքման ժամանակը:
Ի՞նչ կարող է պատահել, եթե մենք պրոցեսորի սահմանաչափեր չսահմանենք:
Ցավոք, մենք ինքներս ստիպված եղանք դիմակայել այս խնդրին։ Յուրաքանչյուր հանգույց ունի բեռնարկղերի կառավարման համար պատասխանատու գործընթաց kubelet, և նա դադարեց պատասխանել խնդրանքներին։ Հանգույցը, երբ դա տեղի ունենա, կմտնի վիճակ NotReady, և դրանից բեռնարկղերը կվերահղվեն այլ տեղ և կստեղծեն նույն խնդիրները նոր հանգույցների վրա: Իդեալական սցենար չէ, մեղմ ասած:
Շնչառության և արձագանքման խնդրի դրսևորում
Բեռնարկղերի հետագծման հիմնական չափանիշն է trottling, այն ցույց է տալիս, թե քանի անգամ է ձեր բեռնարկղը խեղդվել: Մենք հետաքրքրությամբ նկատեցինք որոշ բեռնարկղերում շնչահեղձության առկայությունը՝ անկախ նրանից՝ պրոցեսորի ծանրաբեռնվածությունը ծայրահեղ էր, թե ոչ։ Որպես օրինակ, եկեք նայենք մեր հիմնական API-ներից մեկին.
Ինչպես տեսնում եք ստորև, մենք սահմանել ենք սահմանը 800m (0.8 կամ 80% հիմնական) և առավելագույն արժեքները լավագույն դեպքում հասնում են 200m (20% միջուկ): Թվում է, թե մինչև ծառայությունը խափանելը մենք դեռ ունենք շատ պրոցեսորային հզորություն, սակայն...
Դուք կարող եք նկատել, որ նույնիսկ այն դեպքում, երբ պրոցեսորի ծանրաբեռնվածությունը ցածր է նշված սահմաններից, զգալիորեն ցածր է, դեռևս առաջանում է շնչափողություն:
Հանդիպելով դրա հետ՝ մենք շուտով հայտնաբերեցինք մի քանի ռեսուրսներ (, , ) նվազման հետևանքով ծառայությունների կատարողականի և արձագանքման ժամանակի անկման մասին:
Ինչու՞ ենք մենք շնչափողություն տեսնում պրոցեսորի ցածր բեռնվածության դեպքում: Կարճ տարբերակը հետևյալն է. «Լինուքսի միջուկում վրիպակ կա, որն առաջացնում է պրոցեսորի որոշակի սահմանափակումներով բեռնարկղերի անհարկի խափանում»: Եթե ձեզ հետաքրքրում է խնդրի բնույթը, կարող եք կարդալ շնորհանդեսը ( и տարբերակներ) Դեյվ Չիլուկի կողմից:
CPU-ի սահմանափակումների վերացում (ծայրահեղ զգուշությամբ)
Երկար քննարկումներից հետո մենք որոշեցինք հեռացնել պրոցեսորի սահմանափակումները բոլոր ծառայություններից, որոնք ուղղակիորեն կամ անուղղակիորեն ազդում էին մեր օգտատերերի կարևոր գործառույթների վրա:
Որոշումը հեշտ չէր, քանի որ մենք բարձր ենք գնահատում մեր կլաստերի կայունությունը: Նախկինում մենք արդեն փորձարկել ենք մեր կլաստերի անկայունությունը, իսկ հետո ծառայությունները սպառել են չափազանց շատ ռեսուրսներ և դանդաղեցրել իրենց ամբողջ հանգույցի աշխատանքը։ Այժմ ամեն ինչ մի փոքր այլ էր. մենք հստակ պատկերացում ունեինք, թե ինչ ենք ակնկալում մեր կլաստերներից, ինչպես նաև լավ ռազմավարություն ունեինք նախատեսվող փոփոխություններն իրականացնելու համար։
Գործարար նամակագրություն հրատապ հարցի շուրջ.
Ինչպե՞ս պաշտպանել ձեր հանգույցները, երբ սահմանափակումները հանվում են:
«Անսահմանափակ» ծառայությունների մեկուսացում.
Նախկինում մենք արդեն տեսել ենք, որ որոշ հանգույցներ վիճակ են ստանում notReady, հիմնականում այն ծառայությունների պատճառով, որոնք սպառում են չափազանց շատ ռեսուրսներ:
Մենք որոշեցինք նման ծառայությունները տեղադրել առանձին («պիտակավորված») հանգույցներում, որպեսզի դրանք չխանգարեն «հարակից» ծառայություններին: Արդյունքում՝ նշելով որոշ հանգույցներ և ավելացնելով հանդուրժողականության պարամետրը «չկապված» ծառայություններին, մենք հասանք ավելի մեծ վերահսկողության կլաստերի վրա, և մեզ համար ավելի հեշտ դարձավ հանգույցների հետ կապված խնդիրները հայտնաբերելը: Նմանատիպ գործընթացներ ինքներդ իրականացնելու համար կարող եք ծանոթանալ .
Ճիշտ պրոցեսորի և հիշողության հարցում նշանակելը.
Մեր ամենամեծ մտավախությունն այն էր, որ գործընթացը կխլի չափազանց շատ ռեսուրսներ, և հանգույցը կդադարի պատասխանել հարցումներին: Քանի որ այժմ (շնորհիվ Datadog-ի) մենք կարող էինք հստակորեն վերահսկել մեր կլաստերի բոլոր ծառայությունները, ես վերլուծեցի նրանց մի քանի ամիսների աշխատանքը, որոնք մենք նախատեսում էինք նշել որպես «անկապ»: Ես պարզապես սահմանել եմ CPU-ի առավելագույն օգտագործումը 20% մարժայով և այդպիսով հանգույցում տեղ եմ հատկացրել այն դեպքում, երբ k8s-ը փորձում է այլ ծառայություններ վերագրել հանգույցին:
Ինչպես տեսնում եք գրաֆիկում, պրոցեսորի առավելագույն ծանրաբեռնվածությունը հասել է 242m CPU միջուկներ (0.242 պրոցեսորային միջուկներ): Պրոցեսորի հարցման համար բավական է վերցնել այս արժեքից մի փոքր ավելի մեծ թիվ: Խնդրում ենք նկատի ունենալ, որ քանի որ ծառայությունները կենտրոնացած են օգտագործողի վրա, առավելագույն բեռնվածության արժեքները համընկնում են տրաֆիկի հետ:
Նույնն արեք հիշողության օգտագործման և հարցումների դեպքում, և voila. դուք բոլորդ պատրաստ եք: Ավելի մեծ անվտանգության համար կարող եք ավելացնել հորիզոնական pod autoscaling: Այսպիսով, ամեն անգամ, երբ ռեսուրսների ծանրաբեռնվածությունը մեծ է, autoscaling-ը կստեղծի նոր pods, և kubernetes-ը դրանք կբաշխի ազատ տարածություն ունեցող հանգույցներին: Այն դեպքում, երբ բուն կլաստերում տեղ չմնա, դուք կարող եք ինքներդ ձեզ նախազգուշացնել կամ կարգավորել նոր հանգույցների ավելացումը դրանց ավտոմատ մասշտաբավորման միջոցով:
Մինուսներից հարկ է նշել, որ պարտվել ենք ««, այսինքն. մեկ հանգույցի վրա աշխատող բեռնարկղերի քանակը: Մենք կարող ենք նաև ունենալ շատ «հանգստություններ» ցածր երթևեկության խտության դեպքում, և կա նաև հավանականություն, որ դուք կհասնեք պրոցեսորի բարձր բեռնվածության, բայց վերջինիս հարցում պետք է օգնեն ավտոմասկալային հանգույցները:
Արդյունքները
Ես ուրախ եմ հրապարակել վերջին մի քանի շաբաթների փորձերի այս հիանալի արդյունքները. մենք արդեն տեսել ենք զգալի բարելավումներ՝ ի պատասխան բոլոր փոփոխված ծառայությունների.
Մենք հասել ենք լավագույն արդյունքների մեր գլխավոր էջում (), այնտեղ ծառայությունն արագացել է քսաներկու անգամ!
Արդյո՞ք Linux միջուկի սխալը շտկվել է:
Այո, բաշխումների տարբերակը 4.19 և ավելի բարձր:
Այնուամենայնիվ, կարդալուց հետո 2020 թվականի սեպտեմբերի երկրորդի համար մենք դեռևս հանդիպում ենք Linux-ի որոշ նախագծերի մասին, որոնք ունեն նմանատիպ սխալ: Կարծում եմ, որ Linux-ի որոշ բաշխումներ դեռևս ունեն այս սխալը և պարզապես աշխատում են այն շտկելու վրա:
Եթե ձեր բաշխման տարբերակը 4.19-ից ցածր է, ես խորհուրդ կտայի թարմացնել վերջինը, բայց ամեն դեպքում դուք պետք է փորձեք հեռացնել պրոցեսորի սահմանափակումները և տեսնել, թե արդյոք կլանումը պահպանվում է: Ստորև կարող եք տեսնել Kubernetes կառավարման ծառայությունների և Linux բաշխումների մասնակի ցանկը.
- Debian. ուղղում ինտեգրված բաշխման վերջին տարբերակին, և բավականին թարմ տեսք ունի () Որոշ նախորդ տարբերակները նույնպես կարող են շտկվել:
- Ubuntu. ուղղում ինտեգրված վերջին տարբերակին
- EKS-ը դեռ ուղղում ունի . Եթե ձեր տարբերակը սրանից ցածր է, դուք պետք է թարմացնեք AMI-ն:
- կոպս: у
kops 1.18+Հիմնական հյուրընկալող պատկերը կլինի Ubuntu 20.04-ը: Եթե ձեր kops-ի տարբերակը ավելի հին է, գուցե ստիպված լինեք սպասել ուղղման: Մենք ինքներս հիմա սպասում ենք։ - GKE (Google Cloud). Ուղղել ինտեգրված , սակայն կան խափանումների հետ կապված խնդիրներ .
Ի՞նչ անել, եթե շտկումը շտկեց շնչափողի խնդիրը:
Ես վստահ չեմ, որ խնդիրը լիովին լուծված է: Երբ ֆիքսով հասնենք միջուկի տարբերակին, ես կփորձարկեմ կլաստերը և կթարմացնեմ գրառումը: Եթե որևէ մեկն արդեն թարմացրել է, ես կցանկանայի կարդալ ձեր արդյունքները:
Ամփոփում
- Եթե դուք աշխատում եք Docker կոնտեյներների հետ Linux-ի ներքո (անկախ Kubernetes-ից, Mesos-ից, Swarm-ից կամ այլոց), ձեր կոնտեյներները կարող են կորցնել աշխատանքը՝ շնչահեղձության պատճառով.
- Փորձեք թարմացնել ձեր բաշխման վերջին տարբերակին՝ հուսալով, որ սխալն արդեն շտկվել է.
- Պրոցեսորի սահմանաչափերի հեռացումը կլուծի խնդիրը, բայց սա վտանգավոր տեխնիկա է, որը պետք է օգտագործվի ծայրահեղ զգուշությամբ (ավելի լավ է նախ թարմացնել միջուկը և համեմատել արդյունքները);
- Եթե դուք հանել եք պրոցեսորի սահմանափակումները, ուշադիր հետևեք ձեր պրոցեսորի և հիշողության օգտագործմանը և համոզվեք, որ ձեր պրոցեսորի ռեսուրսները գերազանցում են ձեր սպառումը.
- Անվտանգ տարբերակ կլինի ավտոմատ մասշտաբով պատիճները՝ սարքաշարի մեծ ծանրաբեռնվածության դեպքում ստեղծելու համար նոր պատյաններ, որպեսզի kubernetes-ը դրանք վերագրի ազատ հանգույցներին:
Հուսով եմ, որ այս գրառումը կօգնի ձեզ բարելավել ձեր կոնտեյներային համակարգերի աշխատանքը:
PS հեղինակը նամակագրում է ընթերցողների և մեկնաբանների հետ (անգլերեն):
Source: www.habr.com