Ես ստեղծել եմ Kube Eagle-ը՝ Պրոմեթևսի արտահանող: Պարզվեց, որ դա հիանալի բան է, որն օգնում է ձեզ ավելի լավ հասկանալ փոքր և միջին կլաստերների ռեսուրսները: Ի վերջո, ես խնայեցի հարյուրավոր դոլարներ, քանի որ ընտրեցի ճիշտ մեքենաների տեսակները և կազմաձևեցի կիրառական ռեսուրսների սահմանաչափերը աշխատանքային ծանրաբեռնվածության համար:
Ես ձեզ կասեմ առավելությունների մասին , բայց նախ կբացատրեմ, թե ինչն է առաջացրել աղմուկը և ինչու էր անհրաժեշտ բարձրակարգ մոնիտորինգ։
Ես կառավարեցի 4–50 հանգույցների մի քանի կլաստերներ: Յուրաքանչյուր կլաստեր պարունակում է մինչև 200 միկրոծառայություններ և հավելվածներ: Գոյություն ունեցող ապարատն ավելի լավ օգտագործելու համար տեղակայումների մեծ մասը կազմաձևված էր պայթող RAM և CPU ռեսուրսներով: Այս կերպ, pods-ը կարող է անհրաժեշտության դեպքում վերցնել առկա ռեսուրսները և միևնույն ժամանակ չխանգարել այս հանգույցի այլ հավելվածներին: Դե, հիանալի չէ՞:
Եվ չնայած կլաստերը սպառում էր համեմատաբար քիչ պրոցեսոր (8%) և օպերատիվ հիշողություն (40%), մենք անընդհատ խնդիրներ ունեինք՝ կապված փոդերի կանխարգելման հետ, երբ նրանք փորձում էին ավելի շատ հիշողություն հատկացնել, քան հասանելի էր հանգույցում: Այն ժամանակ մենք ունեինք միայն մեկ վահանակ Kubernetes-ի ռեսուրսների մոնիտորինգի համար: Սրա նման:
Grafana-ի վահանակը միայն cAdvisor-ի չափանիշներով
Նման վահանակի դեպքում խնդիր չէ տեսնել հանգույցներ, որոնք ուտում են շատ հիշողություն և պրոցեսոր: Խնդիրը պարզելն է, թե որն է պատճառը: Պլոկները տեղում պահելու համար, իհարկե, կարելի է ստեղծել երաշխավորված ռեսուրսներ բոլոր պատյանների վրա (պահանջվող ռեսուրսները հավասար են սահմանաչափին): Բայց սա սարքավորումների ամենախելացի օգտագործումը չէ: Կլաստերն ուներ մի քանի հարյուր գիգաբայթ հիշողություն, մինչդեռ որոշ հանգույցներ սոված էին, իսկ մյուսների մոտ մնացել էր 4-10 ԳԲ պահուստ:
Պարզվում է, որ Kubernetes-ի ժամանակացույցը անհավասարաչափ է բաշխել աշխատանքային բեռները հասանելի ռեսուրսների վրա: Kubernetes-ի ժամանակացույցը հաշվի է առնում տարբեր կոնֆիգուրացիաներ՝ կապվածություն, խայտառակություն և հանդուրժողականության կանոններ, հանգույցների ընտրիչներ, որոնք կարող են սահմանափակել առկա հանգույցները: Բայց իմ դեպքում նման բան չկար, և պատիճները պլանավորվում էին կախված յուրաքանչյուր հանգույցի պահանջվող ռեսուրսներից:
Պոդի համար ընտրվել է այն հանգույցը, որն ունի ամենաշատ ազատ ռեսուրսները և բավարարում է հարցումների պայմանները: Մենք պարզեցինք, որ հանգույցների վրա պահանջվող ռեսուրսները չեն համընկնում իրական օգտագործման հետ, և հենց այստեղ օգնության հասան Kube Eagle-ը և նրա ռեսուրսների մոնիտորինգի հնարավորությունները:
Ես ունեմ գրեթե բոլոր Kubernetes կլաստերները, որոնք վերահսկվում են միայն и . Node Exporter-ը վիճակագրություն է տրամադրում I/O-ի և սկավառակի, պրոցեսորի և RAM-ի օգտագործման վերաբերյալ, մինչդեռ Kube State Metrics-ը ցույց է տալիս Kubernetes օբյեկտների չափումները, ինչպիսիք են հարցումները և պրոցեսորի և հիշողության ռեսուրսների սահմանափակումները:
Մենք պետք է համատեղենք օգտագործման չափումները Grafana-ի հարցումների և սահմանափակումների չափումների հետ, այնուհետև մենք կստանանք խնդրի մասին ամբողջ տեղեկատվությունը: Սա պարզ է թվում, բայց երկու գործիքներն իրականում այլ կերպ են անվանում պիտակները, և որոշ չափումներ ընդհանրապես չունեն մետատվյալների պիտակներ: Kube Eagle-ն ամեն ինչ ինքն է անում, և վահանակն ունի հետևյալ տեսքը.
Մեզ հաջողվեց լուծել ռեսուրսների հետ կապված բազմաթիվ խնդիրներ և խնայել սարքավորումները.
- Որոշ ծրագրավորողներ չգիտեին, թե որքան ռեսուրսներ են անհրաժեշտ միկրոծառայությունների համար (կամ պարզապես չեն անհանգստացրել): Մենք ոչ մի կերպ չենք կարողացել գտնել ռեսուրսների սխալ հարցումներ. դրա համար մենք պետք է իմանանք սպառումը գումարած հարցումները և սահմանափակումները: Այժմ նրանք տեսնում են Պրոմեթևսի չափումները, վերահսկում են իրական օգտագործումը և կարգավորում հարցումներն ու սահմանափակումները:
- JVM հավելվածները վերցնում են այնքան RAM, որքան կարող են: Աղբահանը հիշողություն է թողարկում միայն այն դեպքում, երբ օգտագործվում է ավելի քան 75%: Եվ քանի որ ծառայությունների մեծ մասն ունի պայթող հիշողություն, այն միշտ զբաղված է եղել JVM-ի կողմից: Հետևաբար, Java-ի այս բոլոր ծառայությունները սպասվածից շատ ավելի շատ RAM էին սպառում:
- Որոշ հավելվածներ պահանջում էին չափազանց շատ հիշողություն, և Kubernetes-ի ժամանակացույցը այս հանգույցները չէր տալիս այլ հավելվածների, չնայած իրականում դրանք ավելի ազատ էին, քան մյուս հանգույցները: Մի ծրագրավորող պատահաբար լրացուցիչ թվանշան ավելացրեց հարցումին և վերցրեց RAM-ի մեծ կտոր՝ 20 ԳԲ-ի փոխարեն: Ոչ ոք չնկատեց: Հավելվածն ուներ 2 կրկնօրինակ, հետևաբար 3 հանգույց է տուժել:
- Մենք մտցրեցինք ռեսուրսների սահմանաչափեր, վերապլանավորեցինք պատիճները ճիշտ հարցումներով և ստացանք սարքաշարի օգտագործման իդեալական հավասարակշռություն բոլոր հանգույցներում: Մի երկու հանգույց կարող էին ընդհանրապես փակվել։ Եվ հետո մենք տեսանք, որ մենք սխալ մեքենաներ ունեինք (CPU կողմնորոշված, ոչ թե հիշողություն ուղղված): Մենք փոխեցինք տեսակը և ջնջեցինք ևս մի քանի հանգույց։
Արդյունքները
Կլաստերում պայթող ռեսուրսների դեպքում դուք ավելի արդյունավետ եք օգտագործում հասանելի սարքաշարը, սակայն Kubernetes-ի ժամանակացույցը պլանավորում է բլոկները՝ հիմնվելով ռեսուրսների հարցումների վրա, և դա հղի է: Մեկ քարով երկու թռչուն սպանելու համար. խնդիրներից խուսափելու և ռեսուրսները լիարժեք օգտագործելու համար հարկավոր է լավ մոնիտորինգ: Ահա թե ինչու այն օգտակար կլինի (Prometheus արտահանող և Grafana վահանակ):
Source: www.habr.com