Նշում. թարգմ.Kubernetes-ի ընդունումը GitLab-ում համարվում է ընկերության աճին նպաստող երկու հիմնական գործոններից մեկը: Այնուամենայնիվ, մինչև վերջերս GitLab.com առցանց ծառայության ենթակառուցվածքը կառուցված էր վիրտուալ մեքենաների վրա, և ընդամենը մոտ մեկ տարի առաջ սկսվեց դրա միգրացիան դեպի K8, որը դեռ ավարտված չէ։ Մենք ուրախ ենք ներկայացնել GitLab SRE-ի ինժեների վերջին հոդվածի թարգմանությունը այն մասին, թե ինչպես է դա տեղի ունենում և ինչ եզրակացություններ են անում նախագծին մասնակցող ինժեներները:
Մոտ մեկ տարի է, ինչ մեր ենթակառուցվածքի բաժինը տեղափոխում է GitLab.com-ում աշխատող բոլոր ծառայությունները Kubernetes: Այս ընթացքում մենք բախվեցինք մարտահրավերների՝ կապված ոչ միայն ծառայությունների Kubernetes տեղափոխման, այլ նաև անցման ընթացքում հիբրիդային տեղակայման կառավարման հետ: Մեր սովորած արժեքավոր դասերը կքննարկվեն այս հոդվածում։
GitLab.com-ի հենց սկզբից նրա սերվերները աշխատում էին ամպի մեջ՝ վիրտուալ մեքենաների վրա: Այս վիրտուալ մեքենաները կառավարվում են խոհարարի կողմից և տեղադրվում են մեր կողմից . այն դեպքում, երբ հավելվածը պետք է թարմացվի, այն բաղկացած է պարզապես սերվերի նավատորմի համակարգված, հաջորդական եղանակով թարմացումից՝ օգտագործելով CI խողովակաշար: Այս մեթոդը, թեև դանդաղ և մի փոքր - Ապահովում է, որ GitLab.com-ն օգտագործում է տեղադրման և կազմաձևման նույն պրակտիկան, ինչպես անցանց օգտվողները (ինքնակառավարվող) GitLab-ի տեղադրումներ՝ օգտագործելով մեր Linux փաթեթները դրա համար:
Մենք օգտագործում ենք այս մեթոդը, քանի որ չափազանց կարևոր է զգալ բոլոր վիշտերն ու ուրախությունները, որոնք զգում են համայնքի սովորական անդամները GitLab-ի իրենց պատճենները տեղադրելիս և կազմաձևելիս: Այս մոտեցումը որոշ ժամանակ լավ աշխատեց, բայց երբ GitLab-ի նախագծերի թիվը գերազանցեց 10 միլիոնը, մենք հասկացանք, որ այն այլևս չի բավարարում մասշտաբի և տեղակայման մեր կարիքները:
Առաջին քայլերը դեպի Kubernetes և ամպային GitLab
Նախագիծը ստեղծվել է 2017թ պատրաստել GitLab-ը ամպի տեղակայման համար և հնարավորություն տալ օգտվողներին տեղադրել GitLab-ը Kubernetes կլաստերներում: Այն ժամանակ մենք գիտեինք, որ GitLab-ը Kubernetes տեղափոխելը կբարձրացնի SaaS հարթակի մասշտաբայնությունը, կհեշտացնի տեղակայումը և կբարելավի հաշվողական ռեսուրսների արդյունավետությունը: Միևնույն ժամանակ, մեր հավելվածի գործառույթներից շատերը կախված էին մոնտաժված NFS միջնորմներից, որոնք դանդաղեցնում էին անցումը վիրտուալ մեքենաներից:
Ամպային մայրենի և Kubernetes-ի նկատմամբ մղումը թույլ տվեց մեր ինժեներներին պլանավորել աստիճանական անցում, որի ընթացքում մենք հրաժարվեցինք հավելվածի որոշ կախվածություններից ցանցային պահեստից՝ շարունակելով զարգացնել նոր հնարավորություններ: Քանի որ մենք սկսեցինք ծրագրել միգրացիան 2019 թվականի ամռանը, այս սահմանափակումներից շատերը լուծվել են, և GitLab.com-ը Kubernetes տեղափոխելու գործընթացը այժմ լավ ընթացքի մեջ է:
GitLab.com-ի առանձնահատկությունները Kubernetes-ում
GitLab.com-ի համար մենք օգտագործում ենք մեկ տարածաշրջանային GKE կլաստեր, որը կարգավորում է հավելվածների ամբողջ տրաֆիկը: Որպեսզի նվազագույնի հասցնենք (արդեն բարդ) միգրացիայի բարդությունը, մենք կենտրոնանում ենք ծառայությունների վրա, որոնք չեն ապավինում տեղական պահեստին կամ NFS-ին: GitLab.com-ն օգտագործում է հիմնականում միաձույլ Rails կոդերի բազան, և մենք երթևեկությունն ուղղորդում ենք աշխատանքի ծանրաբեռնվածության բնութագրերի հիման վրա դեպի տարբեր վերջնակետեր, որոնք մեկուսացված են իրենց սեփական հանգույցների լողավազաններում:
Frontend-ի դեպքում այս տեսակները բաժանվում են վեբ, API, Git SSH/HTTPS և Registry հարցումների: Հետին պլանի դեպքում մենք հերթի աշխատանքները բաժանում ենք ըստ տարբեր բնութագրերի՝ կախված նրանից , որոնք թույլ են տալիս մեզ սահմանել ծառայության մակարդակի նպատակներ (SLOs) տարբեր ծանրաբեռնվածությունների համար:
GitLab.com-ի այս բոլոր ծառայությունները կազմաձևված են՝ օգտագործելով չփոփոխված GitLab Helm աղյուսակը: Կազմաձևումն իրականացվում է ենթագծապատկերներով, որոնք կարող են ընտրովի միացվել, երբ մենք աստիճանաբար ծառայություններ տեղափոխում ենք կլաստեր: Թեև մենք որոշեցինք չներառել մեր պետական ծառայություններից մի քանիսը, ինչպիսիք են Redis-ը, Postgres-ը, GitLab Pages-ը և Gitaly-ն, Kubernetes-ի օգտագործումը թույլ է տալիս մեզ արմատապես նվազեցնել VM-ների թիվը, որոնք ներկայումս կառավարում է Chef-ը:
Kubernetes-ի կազմաձևման տեսանելիություն և կառավարում
Բոլոր կարգավորումները կառավարվում են հենց GitLab-ի կողմից: Դրա համար օգտագործվում են Terraform-ի և Helm-ի վրա հիմնված երեք կոնֆիգուրացիայի նախագիծ: Մենք փորձում ենք օգտագործել GitLab-ն ինքնին, երբ հնարավոր է GitLab-ը գործարկելու համար, բայց գործառնական առաջադրանքների համար մենք ունենք առանձին GitLab տեղադրում: Սա անհրաժեշտ է, որպեսզի համոզվեք, որ դուք կախված չեք GitLab.com-ի հասանելիությունից GitLab.com-ի տեղակայումներ և թարմացումներ կատարելիս:
Չնայած Kubernetes կլաստերի մեր խողովակաշարերն աշխատում են GitLab-ի առանձին տեղադրմամբ, կան կոդի պահոցների հայելիներ, որոնք հանրությանը հասանելի են հետևյալ հասցեներում.
- — GitLab.com կազմաձևման շրջանակը GitLab Helm աղյուսակի համար;
- - Պարունակում է կոնֆիգուրացիաներ ծառայությունների համար, որոնք ուղղակիորեն կապված չեն GitLab հավելվածի հետ: Դրանք ներառում են լոգերի և կլաստերի մոնիտորինգի կոնֆիգուրացիաներ, ինչպես նաև ինտեգրված գործիքներ, ինչպիսիք են PlantUML;
- — Terraform կոնֆիգուրացիա Kubernetes-ի և VM-ի հին ենթակառուցվածքի համար: Այստեղ դուք կարգավորում եք կլաստերը գործարկելու համար անհրաժեշտ բոլոր ռեսուրսները, ներառյալ կլաստերը, հանգույցների լողավազանները, ծառայության հաշիվները և IP հասցեների ամրագրումները:
Փոփոխություններ կատարելիս ցուցադրվում է հանրային դիտում: Հղմամբ դեպի մանրամասն տարբերություն, որը SRE-ն վերլուծում է կլաստերում փոփոխություններ կատարելուց առաջ:
SRE-ի համար հղումը հանգեցնում է GitLab-ի տեղադրման մանրամասն տարբերության, որն օգտագործվում է արտադրության համար և մուտքը սահմանափակ է: Սա թույլ է տալիս աշխատակիցներին և համայնքին, առանց գործառնական նախագծի (որը բաց է միայն SRE-ների համար) մուտք գործելու, դիտելու առաջարկվող կազմաձևման փոփոխությունները: Համատեղելով հանրային GitLab օրինակը կոդի համար մասնավոր օրինակի հետ CI խողովակաշարերի համար՝ մենք պահպանում ենք մեկ աշխատանքային հոսք՝ միաժամանակ ապահովելով GitLab.com-ից անկախությունը կազմաձևման թարմացումների համար:
Ինչ պարզեցինք գաղթի ժամանակ
Տեղափոխման ընթացքում փորձ է ձեռք բերվել, որ մենք կիրառում ենք նոր միգրացիաներ և տեղակայումներ Kubernetes-ում:
1. Հասանելիության գոտիների միջև երթևեկության պատճառով ծախսերի ավելացում
Օրական արտահոսքի վիճակագրություն (օրական բայթ) Git պահեստային նավատորմի համար GitLab.com-ում
Google-ը իր ցանցը բաժանում է տարածաշրջանների։ Դրանք իրենց հերթին բաժանվում են մատչելիության գոտիների (ԱԶ): Git հոստինգը կապված է մեծ քանակությամբ տվյալների հետ, ուստի մեզ համար կարևոր է վերահսկել ցանցի արտահոսքը: Ներքին երթևեկության համար ելքը անվճար է միայն այն դեպքում, եթե այն մնում է նույն հասանելիության գոտում: Այս գրելու պահին մենք սպասարկում ենք մոտավորապես 100 ՏԲ տվյալ սովորական աշխատանքային օրվա ընթացքում (և դա միայն Git պահեստների համար է): Ծառայությունները, որոնք գտնվում էին նույն վիրտուալ մեքենաներում մեր հին VM-ի վրա հիմնված տոպոլոգիայում, այժմ աշխատում են տարբեր Kubernetes pods-ում: Սա նշանակում է, որ որոշ երթևեկություն, որը նախկինում տեղական էր VM-ի համար, կարող է երթևեկել հասանելիության գոտիներից դուրս:
Տարածաշրջանային GKE կլաստերները թույլ են տալիս ընդգրկել բազմաթիվ Հասանելիության գոտիներ՝ ավելորդության համար: Մենք դիտարկում ենք հնարավորությունը ծառայությունների համար, որոնք առաջացնում են մեծ քանակությամբ տրաֆիկ: Սա կնվազեցնի արտագնա ծախսերը՝ միաժամանակ պահպանելով կլաստերի մակարդակի ավելորդությունը:
2. Սահմանափակումներ, ռեսուրսների հարցումներ և մասշտաբներ
registry.gitlab.com-ում կրկնօրինակների մշակման արտադրական տրաֆիկի քանակը: Երթևեկությունը բարձրանում է ժամը ~15:00 UTC:
Մեր միգրացիայի պատմությունը սկսվեց 2019 թվականի օգոստոսին, երբ մենք տեղափոխեցինք մեր առաջին ծառայությունը՝ GitLab Container Registry, Kubernetes: Այս առաքելության համար կարևոր, բարձր երթևեկության ծառայությունը լավ ընտրություն էր առաջին միգրացիայի համար, քանի որ այն քաղաքացիություն չունեցող ծրագիր է՝ քիչ արտաքին կախվածություններով: Առաջին խնդիրը, որին հանդիպեցինք, վտարված պատիճների մեծ քանակությունն էր՝ հանգույցների վրա հիշողության բացակայության պատճառով: Սրա պատճառով մենք ստիպված եղանք փոխել հարցումներն ու սահմանափակումները:
Հայտնաբերվել է, որ հավելվածի դեպքում, որտեղ հիշողության սպառումը ժամանակի ընթացքում ավելանում է, հարցումների ցածր արժեքները (յուրաքանչյուր պատի համար հիշողության պահպանում) զուգորդված օգտագործման «առատաձեռն» կոշտ սահմանափակումով հանգեցրել են հագեցվածության։ (հագեցվածություն) հանգույցներ և վտարման բարձր մակարդակ: Այս խնդրի հետ առնչվելու համար դա եղել է . Սա նվազեցրեց ճնշումը հանգույցներից և ապահովեց, որ պատիճներն ունեն կյանքի ցիկլ, որը չափազանց մեծ ճնշում չի գործադրում հանգույցի վրա: Այժմ մենք սկսում ենք միգրացիաները առատաձեռն (և գրեթե նույնական) հարցումների և սահմանային արժեքներով՝ անհրաժեշտության դեպքում դրանք ճշգրտելով:
3. Չափումներ և տեղեկամատյաններ
Ենթակառուցվածքի ստորաբաժանումը կենտրոնանում է հետաձգման, սխալի մակարդակի և տեղադրվածով հագեցվածության վրա (SLO) կապված է .
Անցած տարվա ընթացքում ենթակառուցվածքների ստորաբաժանման հիմնական իրադարձություններից մեկը եղել է ԱՊՕ-ների մոնիտորինգի և աշխատանքի բարելավումը: SLO-ները մեզ թույլ տվեցին նպատակներ դնել առանձին ծառայությունների համար, որոնք մենք ուշադիր հետևում էինք միգրացիայի ընթացքում: Բայց նույնիսկ այս բարելավված դիտելիության դեպքում միշտ չէ, որ հնարավոր է անհապաղ խնդիրներ տեսնել չափումների և ազդանշանների օգտագործմամբ: Օրինակ՝ կենտրոնանալով հետաձգման և սխալի մակարդակի վրա՝ մենք ամբողջությամբ չենք լուսաբանում միգրացիայի ենթարկվող ծառայության օգտագործման բոլոր դեպքերը:
Այս խնդիրը հայտնաբերվեց գրեթե անմիջապես այն բանից հետո, երբ որոշ ծանրաբեռնվածություններ տեղափոխվեցին կլաստեր: Այն հատկապես սուր դարձավ, երբ մենք պետք է ստուգեինք գործառույթները, որոնց համար հարցումների թիվը փոքր էր, բայց որոնք ունեին շատ կոնկրետ կոնֆիգուրացիայի կախվածություն: Միգրացիայի հիմնական դասերից մեկն այն էր, որ անհրաժեշտ է հաշվի առնել ոչ միայն չափումները, այլև տեղեկամատյանները և «երկար պոչը»: (խոսքը վերաբերում է գծապատկերում - մոտ. թարգմ.) սխալներ. Այժմ յուրաքանչյուր միգրացիայի համար մենք ներառում ենք մատյանների հարցումների մանրամասն ցուցակ (մատյան հարցումներ) և պլանավորել հստակ հետադարձ ընթացակարգեր, որոնք կարող են տեղափոխվել մի հերթափոխից մյուսը, եթե խնդիրներ առաջանան:
Հին VM ենթակառուցվածքի և Kubernetes-ի վրա հիմնված նոր ենթակառուցվածքի վրա նույն պահանջները զուգահեռ մատուցելը յուրահատուկ մարտահրավեր էր: Ի տարբերություն վերելակի և հերթափոխի միգրացիայի (հավելվածների արագ փոխանցում «ինչպես կա» նոր ենթակառուցվածք; ավելի մանրամասն կարելի է կարդալ, օրինակ. - մոտ. թարգմ.), «հին» VM-ների և Kubernetes-ի վրա զուգահեռ աշխատանքը պահանջում է, որ մոնիտորինգի գործիքները համատեղելի լինեն երկու միջավայրերի հետ և կարողանան միավորել չափումները մեկ դիտման մեջ: Կարևոր է, որ մենք օգտագործենք նույն վահանակները և գրանցամատյանների հարցումները՝ անցումային ժամանակահատվածում հետևողական դիտարկելիության հասնելու համար:
4. Երթևեկության անցում նոր կլաստերի
GitLab.com-ի համար սերվերների մի մասը նվիրված է . Canary Park-ը սպասարկում է մեր ներքին նախագծերը և կարող է նաև . Բայց այն հիմնականում նախատեսված է ենթակառուցվածքում և հավելվածում կատարված փոփոխությունները փորձարկելու համար: Առաջին տեղափոխված ծառայությունը սկսվեց ընդունելով ներքին տրաֆիկի սահմանափակ քանակություն, և մենք շարունակում ենք օգտագործել այս մեթոդը՝ ապահովելու SLO-ների բավարարումը նախքան ամբողջ տրաֆիկը կլաստեր ուղարկելը:
Միգրացիայի դեպքում դա նշանակում է, որ ներքին նախագծերի հարցումները նախ ուղարկվում են Kubernetes-ին, այնուհետև մենք աստիճանաբար տեղափոխում ենք մնացած տրաֆիկը դեպի կլաստեր՝ փոխելով կշիռը backend-ի համար HAProxy-ի միջոցով: VM-ից Kubernetes տեղափոխման ժամանակ պարզ դարձավ, որ շատ ձեռնտու էր հին և նոր ենթակառուցվածքների միջև երթևեկությունը վերահղելու հեշտ միջոց ունենալը և, համապատասխանաբար, միգրացիայից հետո առաջին մի քանի օրվա ընթացքում հին ենթակառուցվածքը պատրաստ պահելու համար:
5. Պզուկների պահուստային հզորությունները և դրանց օգտագործումը
Գրեթե անմիջապես հայտնաբերվեց հետևյալ խնդիրը. ռեգիստրի ծառայության բլոկները արագ գործարկվեցին, բայց Sidekiq-ի համար պատյանների գործարկումը տևեց մինչև . Sidekiq pods-ի երկար գործարկման ժամանակը խնդիր դարձավ, երբ մենք սկսեցինք աշխատանքային ծանրաբեռնվածությունը տեղափոխել Kubernetes այն աշխատողների համար, ովքեր պետք է արագ մշակեին աշխատանքները և արագ մասշտաբային:
Այս դեպքում դասն այն էր, որ թեև Kubernetes-ի Horizontal Pod Autoscaler-ը (HPA) լավ է կառավարում երթևեկության աճը, կարևոր է հաշվի առնել աշխատանքային ծանրաբեռնվածության բնութագրերը և տեղաբաշխել պահեստային հզորությունը (հատկապես երբ պահանջարկը անհավասարաչափ է բաշխված): Մեր դեպքում աշխատատեղերի անսպասելի աճ եղավ, ինչը հանգեցրեց արագ մասշտաբի, ինչը հանգեցրեց պրոցեսորի ռեսուրսների հագեցվածությանը, նախքան մենք ժամանակ կհասցնեինք մեծացնել հանգույցի լողավազանը:
Միշտ կա կլաստերից որքան հնարավոր է շատ քամելու գայթակղություն, սակայն, ի սկզբանե հանդիպելով կատարողականի հետ կապված խնդիրների, մենք այժմ սկսում ենք առատաձեռն pod բյուջեից և կրճատում այն ավելի ուշ՝ ուշադիր հետևելով SLO-ներին: «Սիդեկիք» ծառայության համար պոդիների գործարկումը զգալիորեն արագացել է և այժմ միջինը տևում է մոտ 40 վայրկյան: հաղթեց և՛ GitLab.com-ը, և՛ մեր ինքնակառավարվող տեղադրումների մեր օգտվողները, որոնք աշխատում էին պաշտոնական GitLab Helm աղյուսակի հետ:
Ամփոփում
Յուրաքանչյուր ծառայություն տեղափոխելուց հետո մենք ուրախացանք Kubernetes-ի արտադրության մեջ օգտագործելու առավելություններից՝ հավելվածների ավելի արագ և անվտանգ տեղակայում, մասշտաբացում և ռեսուրսների ավելի արդյունավետ բաշխում: Ավելին, միգրացիայի առավելությունները դուրս են գալիս GitLab.com ծառայության շրջանակներից: Պաշտոնական Helm աղյուսակի յուրաքանչյուր բարելավում օգուտ է տալիս իր օգտագործողներին:
Հուսով եմ, որ ձեզ դուր է եկել մեր Kubernetes միգրացիոն արկածների պատմությունը: Մենք շարունակում ենք բոլոր նոր ծառայությունները տեղափոխել կլաստեր: Հավելյալ տեղեկություններ կարելի է գտնել հետևյալ հրապարակումներում.
- «";
- «";
- .
PS թարգմանչից
Կարդացեք նաև մեր բլոգում.
- «";
- «";
- «";
- «.
Source: www.habr.com