Հե՜յ Հաբր։
Մենք ներկայացնում ենք Exness հարթակի թիմը: Նախկինում մեր գործընկերներն արդեն հոդված էին գրել այդ մասին . Այսօր մենք ցանկանում ենք կիսվել Kubernetes ծառայությունների միգրացիայի մեր փորձով:
Սկզբից մենք ձեզ առաջարկում ենք որոշ թվեր՝ ավելի լավ հասկանալու համար, թե ինչ է քննարկվելու.
- Մեր զարգացման բաժինը բաղկացած է 100+ մարդկանցից, ներառյալ ավելի քան 10 տարբեր թիմեր՝ ինքնաբավ QA, DevOps և Scrum գործընթացներով: Մշակման կույտ - Python, PHP, C++, Java և Golang:
- Փորձարկման և արտադրական միջավայրերի չափը կազմում է մոտ 2000 տարա: Նրանք աշխատում են Rancher v1.6-ով սեփական վիրտուալիզացիայի վրա և VMware-ի ներքո:
Մոտիվացիա
Ինչպես ասում են, ոչինչ հավերժ չէ, և Rancher-ը վաղուց հայտարարեց 1.6 տարբերակի աջակցության ավարտի մասին։ Այո, ավելի քան երեք տարվա ընթացքում մենք սովորել ենք այն պատրաստել և լուծել ծագած խնդիրները, բայց ավելի ու ավելի հաճախ ենք բախվում խնդիրների, որոնք երբեք չեն շտկվի։ Rancher 1.6-ն ունի նաև իրավունքների թողարկման ոսկրացված համակարգ, որտեղ կարող եք կամ գրեթե ամեն ինչ անել, կամ ոչինչ:
Չնայած սեփականության վիրտուալիզացիան ապահովում էր տվյալների պահպանման և դրա անվտանգության ավելի մեծ վերահսկողություն, այն պարտադրում էր գործառնական ծախսեր, որոնք դժվար էր ընդունել՝ հաշվի առնելով ընկերության մշտական աճը, նախագծերի քանակը և դրանց պահանջները:
Մենք ցանկանում էինք հետևել IaC ստանդարտներին և, անհրաժեշտության դեպքում, արագ հզորություն ձեռք բերել ցանկացած աշխարհագրական վայրում և առանց վաճառողի կողպեքի, ինչպես նաև կարողանալ արագ հրաժարվել դրանից:
Առաջին քայլեր
Առաջին հերթին, մենք ցանկանում էինք ապավինել ժամանակակից տեխնոլոգիաներին և լուծումներին, որոնք թիմերին թույլ կտան ունենալ ավելի արագ զարգացման ցիկլ և նվազագույնի հասցնել գործառնական ծախսերը էներգիա ապահովող հարթակի հետ փոխգործակցության համար:
Իհարկե, առաջին բանը, որ եկավ մեր մտքով, Kubernetes-ն էր, բայց մենք չհուզվեցինք և մի փոքր հետազոտություն արեցինք՝ պարզելու, թե արդյոք դա ճիշտ ընտրություն էր: Մենք գնահատեցինք միայն բաց աղբյուրների լուծումները, և անարդար ճակատամարտում Kubernetes-ը անվերապահորեն հաղթեց:
Հաջորդը եկավ կլաստերների ստեղծման գործիք ընտրելու հարցը: Մենք համեմատեցինք ամենահայտնի լուծումները՝ կոպս, կուբեսփրեյ, կուբեադմ:
Սկսելու համար, kubeadm-ը մեզ թվում էր, որ չափազանց բարդ ճանապարհ էր, ավելի շուտ, որպես «հեծանիվ» գյուտարարի, և կոպները բավարար ճկունություն չունեին:
Իսկ հաղթող ճանաչվեց.
Մենք սկսեցինք փորձարկել մեր սեփական վիրտուալացման և AWS-ի հետ՝ փորձելով վերստեղծել ռեսուրսների կառավարման մեր նախորդ օրինակին մոտավորապես նման մի բան, որտեղ բոլորը կիսում էին նույն «կլաստերը»: Եվ հիմա մենք ունենք 10 փոքր վիրտուալ մեքենաներից բաղկացած մեր առաջին կլաստերը, որոնցից մի քանիսը գտնվում են AWS-ում: Մենք սկսեցինք թիմեր տեղափոխել այնտեղ, ամեն ինչ կարծես «լավ» էր, և պատմությունը կարող էր ավարտվել, բայց…
Առաջին խնդիրները
Ansible-ն այն է, ինչի վրա կառուցված է kubespray-ը, այն գործիք չէ, որը թույլ է տալիս հետևել IaC-ին. հանգույցների գործարկում/շահագործումից հանելիս ինչ-որ բան անընդհատ սխալվում էր և ինչ-որ միջամտություն էր պահանջվում, իսկ տարբեր ՕՀ-ներ օգտագործելիս խաղագիրքը այլ կերպ էր վարվում: այլ կերպ: . Քանի որ թիմերի և հանգույցների թիվը աճում էր կլաստերում, մենք սկսեցինք նկատել, որ խաղագիրքն ավելի ու ավելի երկար է տևում ավարտելու համար, և արդյունքում մեր ռեկորդը 3,5 ժամ էր, իսկ ձերը: 🙂
Եվ թվում է, թե kubespray-ը պարզապես Ansible է, և ամեն ինչ պարզ է առաջին հայացքից, բայց.
Ճանապարհորդության սկզբում խնդիրն էր գործարկել հզորությունները միայն AWS-ում և վիրտուալիզացիայի վրա, բայց հետո, ինչպես հաճախ է պատահում, պահանջները փոխվեցին:
Այս լույսի ներքո պարզ դարձավ, որ ռեսուրսները մեկ նվագախմբային համակարգի մեջ միավորելու մեր հին օրինաչափությունը հարմար չէր. այն դեպքում, երբ կլաստերները շատ հեռավոր են և կառավարվում են տարբեր մատակարարների կողմից:
Ավելին, ավելին: Երբ բոլոր թիմերը աշխատում են նույն կլաստերի մեջ, սխալ տեղադրված NodeSelectors-ով տարբեր ծառայություններ կարող են թռչել մեկ այլ թիմի «օտար» հոսթ և օգտագործել այնտեղ ռեսուրսները, և եթե խաթարվածություն է սահմանվել, անընդհատ պահանջներ են եղել, որ այս կամ այն ծառայությունը չի աշխատում, մարդկային գործոնի պատճառով ճիշտ չի բաշխվում։ Մեկ այլ խնդիր էր ծախսերի հաշվարկը, հատկապես հաշվի առնելով հանգույցների միջև ծառայությունների բաշխման խնդիրները:
Առանձին պատմություն էր աշխատակիցներին իրավունքների տրամադրումը. յուրաքանչյուր թիմ ցանկանում էր լինել կլաստերի «գլխավոր» և ամբողջությամբ կառավարել այն, ինչը կարող էր լիակատար փլուզման պատճառ դառնալ, քանի որ թիմերը հիմնականում անկախ են միմյանցից:
Ինչ անել?
Հաշվի առնելով վերը նշվածը և թիմերի՝ ավելի անկախ լինելու ցանկությունը, մենք մի պարզ եզրակացություն արեցինք՝ մեկ թիմ՝ մեկ կլաստեր։
Այսպիսով, մենք ստացանք երկրորդը.
Եվ հետո երրորդ կլաստերը.
Հետո սկսեցինք մտածել՝ ասենք, որ մեկ տարի հետո մեր թիմերը մեկից ավելի կլաստեր կունենա՞ն։ Տարբեր աշխարհագրական տարածքներում, օրինակ, թե՞ տարբեր պրովայդերների հսկողության տակ։ Եվ նրանցից ոմանք կցանկանան, որ կարողանան արագ տեղակայել ժամանակավոր կլաստեր որոշ թեստերի համար:
Full Kubernetes-ը կգա: Սա մի տեսակ MultiKubernetes է, պարզվում է:
Միևնույն ժամանակ, մենք բոլորս պետք է ինչ-որ կերպ պահպանենք այս բոլոր կլաստերները, կարողանանք հեշտությամբ կառավարել դրանց հասանելիությունը, ինչպես նաև ստեղծել նորերը և հանել հինները առանց ձեռքի միջամտության:
Որոշ ժամանակ է անցել Kubernetes աշխարհում մեր ճանապարհորդության սկզբից, և մենք որոշեցինք վերանայել առկա լուծումները: Պարզվեց, որ այն արդեն կա շուկայում՝ Rancher 2.2:
Մեր հետազոտության առաջին փուլում Rancher Labs-ն արդեն արել էր 2-րդ տարբերակի առաջին թողարկումը, բայց թեև այն կարող էր շատ արագ բարձրացնել՝ մի քանի պարամետրով առանց արտաքին կախվածության կոնտեյներ գործարկելու կամ պաշտոնական HELM աղյուսակը օգտագործելու միջոցով, այն թվում էր կոպիտ: մեզ, և մենք չգիտեինք, թե արդյոք կարող ենք հիմնվել այս որոշման վրա՝ այն կմշակվի, թե արագ կհրաժարվի: Կլաստեր = սեղմումների պարադիգմը ինքնին UI-ում նույնպես մեզ չէր համապատասխանում, և մենք չէինք ուզում կապված լինել RKE-ի հետ, քանի որ այն բավականին նեղ կենտրոնացված գործիք է:
Rancher 2.2 տարբերակն արդեն ուներ ավելի գործունակ տեսք և, նախորդների հետ միասին, ուներ մի շարք հետաքրքիր առանձնահատկություններ, ինչպիսիք են բազմաթիվ արտաքին մատակարարների հետ ինտեգրում, իրավունքների բաշխման մեկ կետ և kubeconfig ֆայլեր, գործարկում kubectl: պատկեր՝ ձեր իրավունքներով UI-ում, ներդրված անվանատարածքներ, որոնք կոչվում են նախագծեր:
Կար նաև Rancher 2-ի շուրջ արդեն ձևավորված համայնք, և HashiCorp Terraform անունով մատակարարը ստեղծվել է այն կառավարելու համար, որն օգնեց մեզ ամեն ինչ հավաքել:
Ինչ է պատահել
Արդյունքում, մենք ստացանք մեկ փոքր կլաստեր, որն աշխատում է Rancher-ով, որը հասանելի է բոլոր մյուս կլաստերներին, ինչպես նաև դրան միացված բազմաթիվ կլաստերներ, որոնցից որևէ մեկին հասանելիություն կարող է տրվել այնպես, ինչպես օգտատեր ավելացնելը ldap գրացուցակում, անկախ նրանից որտեղ է այն գտնվում և որ մատակարարի ռեսուրսներն է օգտագործում:
Gitlab-ci-ի և Terraform-ի միջոցով ստեղծվել է մի համակարգ, որը թույլ է տալիս ստեղծել ցանկացած կոնֆիգուրացիայի կլաստեր ամպային պրովայդերներում կամ մեր սեփական ենթակառուցվածքում և միացնել դրանք Rancher-ին: Այս ամենն արվում է IaC ոճով, որտեղ յուրաքանչյուր կլաստեր նկարագրվում է պահեստով, և դրա վիճակը՝ տարբերակված։ Միևնույն ժամանակ, մոդուլների մեծ մասը միացված է արտաքին պահոցներից, այնպես որ մնում է միայն փոփոխականներ փոխանցել կամ նկարագրել ձեր հատուկ կոնֆիգուրացիան օրինակների համար, ինչը օգնում է նվազեցնել կոդերի կրկնության տոկոսը:
Իհարկե, մեր ճանապարհորդությունը հեռու է ավարտվելուց, և դեռ շատ հետաքրքիր առաջադրանքներ կան առջևում, ինչպիսիք են ցանկացած կլաստերների տեղեկամատյանների և չափումների հետ աշխատանքի մեկ կետ, սպասարկման ցանց, բազմակլաստերում բեռների կառավարման գիթոպներ և շատ ավելին: Հուսով ենք, որ ձեզ հետաքրքիր կլինի մեր փորձը:
Հոդվածը գրել են Ա. Անտիպովը, Ա. Գանուշը, Պլատֆորմի ինժեներները։
Source: www.habr.com