Ինչպես Kubernetes-ում pod առաջնահերթությունները պատճառ դարձան Grafana Labs-ի աշխատանքի դադարեցման

Նշում. թարգմ.Ձեր ուշադրությանն ենք ներկայացնում տեխնիկական մանրամասներ Grafana-ի ստեղծողների կողմից սպասարկվող ամպային ծառայության վերջին խափանման պատճառների մասին: Սա դասական օրինակ է այն բանի, թե ինչպես ենթակառուցվածքի որակը բարելավելու համար նախատեսված նոր և թվացյալ չափազանց օգտակար հատկանիշը կարող է վնաս պատճառել, եթե չապահովեք դրա կիրառման բազմաթիվ նրբերանգները արտադրության իրականության մեջ: Հիանալի է, երբ հայտնվում են նման նյութեր, որոնք թույլ են տալիս սովորել ոչ միայն քո սխալներից: Մանրամասները այս տեքստի թարգմանության մեջ են՝ Grafana Labs-ի արտադրանքի փոխնախագահից:

Ինչպես Kubernetes-ում pod առաջնահերթությունները պատճառ դարձան Grafana Labs-ի աշխատանքի դադարեցման

Ուրբաթ օրը՝ հուլիսի 19-ին, Grafana Cloud-ում Hosted Prometheus ծառայությունը դադարեց գործել մոտ 30 րոպեով: Ես ներողություն եմ խնդրում բոլոր հաճախորդներից, որոնք տուժել են խափանումից: Մեր գործն է տրամադրել ձեզ անհրաժեշտ մոնիտորինգի գործիքները, և մենք հասկանում ենք, որ դրանց հասանելի չլինելը կարող է ավելի բարդացնել ձեր կյանքը: Մենք չափազանց լուրջ ենք վերաբերվում այս միջադեպին։ Այս գրությունը բացատրում է, թե ինչ է տեղի ունեցել, ինչպես ենք մենք արձագանքել և ինչ ենք անում, որպեսզի դա չկրկնվի:

նախապատմությանը

Grafana Cloud Hosted Prometheus ծառայությունը հիմնված է Ծառի կեղեվ — CNCF նախագիծ՝ ստեղծելու հորիզոնական մասշտաբային, բարձր հասանելի, բազմաբնակարանային Prometheus ծառայություն: Cortex ճարտարապետությունը բաղկացած է առանձին միկրոծառայությունների մի շարքից, որոնցից յուրաքանչյուրը կատարում է իր գործառույթը՝ կրկնօրինակում, պահեստավորում, հարցումներ և այլն։ Cortex-ը գտնվում է ակտիվ մշակման փուլում և մշտապես ավելացնում է նոր հնարավորություններ և բարելավում կատարումը: Մենք կանոնավոր կերպով տեղադրում ենք Cortex-ի նոր թողարկումները կլաստերներում, որպեսզի հաճախորդները կարողանան օգտվել այս հնարավորություններից. բարեբախտաբար, Cortex-ը կարող է թարմացվել առանց ընդհատումների:

Անխափան թարմացումների համար Ingester Cortex ծառայությունը թարմացման գործընթացում պահանջում է լրացուցիչ Ingester կրկնօրինակ: (Նշում. թարգմ.: Ինգեստեր - Cortex-ի հիմնական բաղադրիչը: Նրա խնդիրն է հավաքել նմուշների մշտական ​​հոսք, խմբավորել դրանք Պրոմեթևսի կտորների մեջ և պահել դրանք տվյալների բազայում, ինչպիսիք են DynamoDB, BigTable կամ Cassandra: Սա թույլ է տալիս հին ներծծողներին փոխանցել ընթացիկ տվյալները նոր ընդունողներին: Հարկ է նշել, որ ingesters-ը ռեսուրս պահանջող է: Որպեսզի դրանք աշխատեն, դուք պետք է ունենաք 4 միջուկ և 15 ԳԲ հիշողություն մեկ պատիճ, այսինքն. Հիմնական մեքենայի մշակման հզորության և հիշողության 25%-ը մեր Kubernetes կլաստերների դեպքում: Ընդհանուր առմամբ, մենք սովորաբար շատ ավելի շատ չօգտագործված ռեսուրսներ ունենք կլաստերում, քան 4 միջուկը և 15 ԳԲ հիշողությունը, այնպես որ մենք կարող ենք հեշտությամբ պտտել այս լրացուցիչ ներծծողները թարմացումների ժամանակ:

Այնուամենայնիվ, հաճախ է պատահում, որ նորմալ շահագործման ժամանակ մեքենաներից ոչ մեկը չունի չօգտագործված ռեսուրսների այս 25%-ը: Այո, մենք չենք էլ ձգտում. պրոցեսորը և հիշողությունը միշտ օգտակար կլինեն այլ գործընթացների համար: Այս խնդիրը լուծելու համար մենք որոշեցինք օգտագործել Kubernetes Pod-ի առաջնահերթություններ. Գաղափարն այն է, որ Ingesters-ին տալ ավելի բարձր առաջնահերթություն, քան այլ (քաղաքացիություն չունեցող) միկրոծառայությունները: Երբ մենք պետք է գործարկենք լրացուցիչ (N+1) ինգեստեր, մենք ժամանակավորապես տեղափոխում ենք այլ, ավելի փոքր պատյաններ: Այս պատյանները փոխանցվում են այլ մեքենաների անվճար ռեսուրսներին՝ թողնելով բավական մեծ «անցք»՝ լրացուցիչ ինգեստեր գործարկելու համար:

Հինգշաբթի օրը՝ հուլիսի 18-ին, մենք առաջնահերթության չորս նոր մակարդակներ ներկայացրինք մեր կլաստերների համար. քննադատական, բարձր, միջին и ցածր. Նրանք փորձարկվել են ներքին կլաստերի վրա՝ առանց հաճախորդների տրաֆիկի մոտ մեկ շաբաթ: Լռելյայնորեն ստացվել են առանց նշված առաջնահերթության պատյաններ միջին առաջնահերթություն, դասը սահմանվել է Ingesters-ի համար բարձր առաջնահերթություն։ Քննադատական վերապահված էր մոնիտորինգի համար (Prometheus, Alertmanager, node-exporter, kube-state-metrics և այլն): Մեր կազմաձևը բաց է, և դուք կարող եք դիտել PR-ը այստեղ.

Դժբախտ պատահար

Ուրբաթ օրը՝ հուլիսի 19-ին, ինժեներներից մեկը գործարկեց նոր նվիրված Cortex կլաստերը մեծ հաճախորդի համար: Այս կլաստերի կազմաձևումը չի ներառում նոր փոկերի առաջնահերթություններ, ուստի բոլոր նոր բլոկներին տրվել է լռելյայն առաջնահերթություն. միջին.

Kubernetes կլաստերը չուներ բավարար ռեսուրսներ նոր Cortex կլաստերի համար, և գոյություն ունեցող արտադրական Cortex կլաստերը չի թարմացվել (ingesters մնացել են առանց высокого առաջնահերթություն): Քանի որ նոր կլաստերի Ingesters-ը լռելյայն ուներ միջին առաջնահերթություն, և արտադրության մեջ առկա պատիճներն ընդհանրապես առանց առաջնահերթության էին աշխատում, նոր կլաստերի սնուցիչները փոխարինեցին գոյություն ունեցող Cortex արտադրական կլաստերից ներծծողներին:

ReplicaSet-ը վտարված Ingester-ի համար արտադրական կլաստերում հայտնաբերել է վտարված պատիճը և ստեղծել նորը` պահպանելու նշված թվով պատճենները: Նոր պատիճը նշանակվել է լռելյայն միջին առաջնահերթությունը, և արտադրության մեկ այլ «հին» Ինգեստեր կորցրեց իր ռեսուրսները: Արդյունքն եղավ ձնահոսքի գործընթաց, ինչը հանգեցրեց Ingester-ից բոլոր պատիճների տեղահանմանը Cortex արտադրական կլաստերների համար:

Ներառող սարքերը պետական ​​են և պահպանում են նախորդ 12 ժամվա տվյալները: Սա թույլ է տալիս մեզ ավելի արդյունավետ սեղմել դրանք, նախքան դրանք երկարաժամկետ պահեստավորման մեջ գրելը: Դրան հասնելու համար Cortex-ը բաժանում է տվյալները շարքերի վրա՝ օգտագործելով բաշխված հեշ աղյուսակը (DHT) և կրկնօրինակում է յուրաքանչյուր շարքը երեք ինգեստերների վրա՝ օգտագործելով Dynamo ոճի քվորումի հետևողականությունը: Cortex-ը տվյալներ չի գրում ինգեստերներին, որոնք անջատված են: Այսպիսով, երբ մեծ թվով ընդունողներ դուրս են գալիս DHT-ից, Cortex-ը չի կարող ապահովել մուտքերի բավարար կրկնօրինակում, և դրանք խափանում են:

Հայտնաբերում և վերականգնում

Պրոմեթևսի նոր ծանուցումներ՝ հիմնված «սխալ բյուջեի» վրա (սխալների վրա հիմնված բյուջե — մանրամասները կհայտնվեն ապագա հոդվածում) սկսեց ահազանգել անջատման մեկնարկից 4 րոպե անց: Մոտավորապես մոտ հինգ րոպեների ընթացքում մենք որոշ ախտորոշումներ կատարեցինք և մեծացրինք Kubernetes-ի հիմքում ընկած կլաստերը՝ ընդունելու ինչպես նոր, այնպես էլ գոյություն ունեցող արտադրական կլաստերները:

Եվս հինգ րոպե անց հին ինգեստերները հաջողությամբ գրեցին իրենց տվյալները, նորերը գործարկվեցին, և Cortex կլաստերները նորից հասանելի դարձան:

Եվս 10 րոպե ծախսվել է Cortex-ի դիմաց գտնվող նույնականացման հակադարձ պրոքսիներից սխալները ախտորոշելու և ուղղելու համար: OOM-ի սխալները առաջացել են QPS-ի տասնապատիկ աճից (կարծում ենք՝ հաճախորդի Prometheus սերվերների չափազանց ագրեսիվ հարցումների պատճառով):

Հետեւանքները

Ընդհանուր պարապուրդը կազմել է 26 րոպե: Ոչ մի տվյալ չի կորել: Ներառողները հաջողությամբ բեռնել են հիշողության մեջ եղած բոլոր տվյալները երկարաժամկետ պահեստում: Անջատման ընթացքում հաճախորդի Prometheus սերվերները բուֆերացված ջնջվել են (հեռավոր) ձայնագրություններ օգտագործելով նոր API remote_write հիմնված WAL-ի վրա (հեղինակած Կալում Ստյան Grafana Labs-ից) և կրկնեց ձախողված գրառումները վթարից հետո:

Ինչպես Kubernetes-ում pod առաջնահերթությունները պատճառ դարձան Grafana Labs-ի աշխատանքի դադարեցման
Արտադրական կլաստերի գրման գործողություններ

Արդյունքները

Կարևոր է դասեր քաղել այս միջադեպից և անհրաժեշտ քայլեր ձեռնարկել դրա կրկնությունից խուսափելու համար։

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

Մենք կավելացնենք վերահսկողության լրացուցիչ մակարդակ ցանկացած լրացուցիչ օբյեկտների տեղակայման վրա, որոնց կոնֆիգուրացիաները գլոբալ են կլաստերի համար: Այսուհետ նման փոփոխությունները գնահատվելու են բоավելի շատ մարդ. Բացի այդ, վթարի պատճառ դարձած փոփոխությունը չափազանց աննշան է համարվել առանձին նախագծի փաստաթղթի համար. այն քննարկվել է միայն GitHub-ի հարցում: Այսուհետ կոնֆիգուրացիաների բոլոր նման փոփոխությունները կուղեկցվեն համապատասխան նախագծային փաստաթղթերով:

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

Անհաջողությունը նաև որոշ դրական հետևանքներ ունեցավ՝ ստանալով անհրաժեշտ ռեսուրսները՝ Cortex-ը ավտոմատ կերպով վերականգնվեց առանց լրացուցիչ միջամտության։ Մենք նաև արժեքավոր փորձ ձեռք բերեցինք աշխատելու հետ Գրաֆանա Լոկի - տեղեկամատյանների համախմբման մեր նոր համակարգը, որն օգնեց ապահովել, որ բոլոր սնուցողներն իրենց ճիշտ պահեն ձախողման ժամանակ և դրանից հետո:

PS թարգմանչից

Կարդացեք նաև մեր բլոգում.

Source: www.habr.com

Добавить комментарий