Sveiki, Habr!
Atstovaujame Exness platformos komandai. Anksčiau mūsų kolegos jau rašė straipsnį apie . Šiandien norime pasidalinti savo patirtimi apie paslaugų perkėlimą į Kubernetes.
Norėdami geriau suprasti, kas bus aptarta, pirmiausia siūlome keletą skaičių:
- Mūsų plėtros skyrių sudaro daugiau nei 100 žmonių, įskaitant daugiau nei 10 skirtingų komandų, turinčių savarankiškus kokybės užtikrinimo, „DevOps“ ir „Scrum“ procesus. Kūrimo krūva – Python, PHP, C++, Java ir Golang.
- Testavimo ir gamybos aplinkos dydis yra apie 2000 konteinerių. Jie naudoja „Rancher v1.6“ savo virtualizacijoje ir „VMware“.
Motyvacija
Kaip sakoma, niekas netrunka amžinai, o apie 1.6 versijos palaikymo pabaigą Rancher paskelbė gana seniai. Taip, per daugiau nei trejus metus išmokome tam pasiruošti ir spręsti iškilusias problemas, tačiau vis dažniau susiduriame su problemomis, kurių niekada nepavyks ištaisyti. Rancher 1.6 taip pat turi sukaulėjusią teisių išdavimo sistemą, kurioje galite daryti beveik viską arba nieko.
Nors patentuota virtualizacija užtikrino didesnę duomenų saugojimo ir jų saugumo kontrolę, dėl to buvo sunku priimti veiklos sąnaudas, atsižvelgiant į nuolatinį įmonės augimą, projektų skaičių ir jiems keliamus reikalavimus.
Norėjome laikytis IaC standartų ir, jei reikia, greitai gauti pajėgumų bet kurioje geografinėje vietoje ir be tiekėjo užrakto, taip pat greitai jų atsisakyti.
Pirmieji žingsniai
Visų pirma, norėjome pasikliauti moderniomis technologijomis ir sprendimais, kurie leistų komandoms turėti greitesnį kūrimo ciklą ir sumažinti veiklos sąnaudas sąveikaujant su galią teikiančia platforma.
Žinoma, pirmas dalykas, kuris mums atėjo į galvą, buvo Kubernetes, bet mes nesijaudinome ir šiek tiek patyrėme, ar tai buvo teisingas pasirinkimas. Vertinome tik atvirojo kodo sprendimus ir nesąžiningoje kovoje Kubernetes besąlygiškai laimėjo.
Toliau iškilo klasterių kūrimo įrankio pasirinkimo klausimas. Palyginome populiariausius sprendimus: kops, kubespray, kubeadm.
Iš pradžių kubeadm mums atrodė pernelyg sudėtingas kelias, veikiau kaip savotiškas „dviračio“ išradėjas, o kopsams neužteko lankstumo.
O nugalėtoju tapo:
Pradėjome eksperimentuoti su savo virtualizavimu ir AWS, bandydami atkurti kažką panašaus į ankstesnį išteklių valdymo modelį, kai visi dalinosi tuo pačiu „klasteriu“. Ir dabar turime pirmąjį 10 mažų virtualių mašinų grupę, iš kurių kelios yra AWS. Pradėjome bandyti ten migruoti komandas, viskas atrodė „gerai“, ir istorija galėjo būti baigta, bet...
Pirmosios problemos
Ansible yra tai, ant ko yra sukurtas kubespray, tai nėra įrankis, leidžiantis sekti IaC: paleidžiant / išjungiant mazgus nuolat kažkas negerai ir reikėjo kažkokio įsikišimo, o naudojant skirtingas OS, žaidimo knyga elgėsi skirtingai. kitaip . Didėjant grupių ir mazgų skaičiui klasteryje, pradėjome pastebėti, kad plano pildymas užtrunka vis ilgiau ir dėl to mūsų rekordas buvo 3,5 valandos, o kaip jūsų? 🙂
Ir atrodo, kad kubespray yra tik Ansible, ir viskas aišku iš pirmo žvilgsnio, bet:
Kelionės pradžioje užduotis buvo paleisti pajėgumus tik AWS ir virtualizuojant, tačiau vėliau, kaip dažnai nutinka, reikalavimai pasikeitė.
Atsižvelgiant į tai, tapo aišku, kad mūsų senasis išteklių sujungimo į vieną orkestravimo sistemą modelis netinka – tuo atveju, kai klasteriai yra labai nutolę ir juos valdo skirtingi tiekėjai.
Toliau daugiau. Kai visos komandos dirba tame pačiame klasteryje, įvairios paslaugos su neteisingai įdiegtais NodeSelectors galėjo nuskristi į „užsienį“ kitos komandos šeimininką ir ten panaudoti resursus, o jei užsiteršdavo, būdavo nuolatiniai prašymai, kad viena ar kita paslauga neveikia, neteisingai paskirstytas dėl žmogiškojo faktoriaus. Kita problema buvo išlaidų apskaičiavimas, ypač atsižvelgiant į paslaugų paskirstymo tarp mazgų problemas.
Atskira istorija buvo teisių išdavimas darbuotojams: kiekviena komanda norėjo būti klasterio „priešakyje“ ir visiškai jį valdyti, o tai gali sukelti visišką žlugimą, nes komandos iš esmės yra nepriklausomos viena nuo kitos.
Ką daryti?
Atsižvelgdami į tai, kas išdėstyta aukščiau, ir į komandų norus būti savarankiškesnėms, padarėme paprastą išvadą: viena komanda – vienas klasteris.
Taigi gavome antrą:
Ir tada trečias klasteris:
Tada pradėjome galvoti: tarkime, kad po metų mūsų komandos turės ne vieną klasterį? Pavyzdžiui, skirtingose geografinėse vietovėse ar kontroliuojant skirtingiems paslaugų teikėjams? Ir kai kurie iš jų norės greitai įdiegti laikiną grupę kai kuriems bandymams.
Ateitų pilnos Kubernetes! Pasirodo, tai kažkoks MultiKubernetes.
Tuo pačiu metu mes visi turėsime kažkaip išlaikyti visus šiuos klasterius, turėti galimybę lengvai valdyti prieigą prie jų, taip pat kurti naujus ir nutraukti senus be rankinio įsikišimo.
Praėjo šiek tiek laiko nuo mūsų kelionės Kubernetes pasaulyje pradžios, todėl nusprendėme iš naujo išnagrinėti galimus sprendimus. Paaiškėjo, kad jis jau egzistuoja rinkoje – Rancher 2.2.
Pirmajame mūsų tyrimo etape „Rancher Labs“ jau buvo išleidusi pirmąją 2 versijos versiją, tačiau nors ją buvo galima labai greitai pakelti paleidus konteinerį be išorinių priklausomybių su keliais parametrais arba naudojant oficialią HELM diagramą, tai atrodė neapdorota. mums, ir mes nežinojome, ar galime šiuo sprendimu pasikliauti, ar jis bus plėtojamas, ar greitai jo bus atsisakyta. Cluster = clicks paradigma pačioje vartotojo sąsajoje mums taip pat netiko, ir mes nenorėjome būti susieti su RKE, nes tai yra gana siaurai orientuotas įrankis.
„Rancher 2.2“ versija jau buvo labiau veikianti ir, kartu su ankstesnėmis, turėjo daugybę įdomių funkcijų, tokių kaip integracija su daugeliu išorinių tiekėjų, vienas teisių ir kubeconfig failų platinimo taškas, kubectl paleidimas. vaizdas su jūsų teisėmis vartotojo sąsajoje, įdėtosios vardų erdvės, dar žinomos kaip projektai.
Taip pat aplink Rancher 2 jau buvo susiformavusi bendruomenė, o jai valdyti buvo sukurtas teikėjas pavadinimu HashiCorp Terraform, kuris padėjo mums viską sujungti.
Kas nutiko
Dėl to gavome vieną mažą klasterį, kuriame veikia „Rancher“, prieinama visoms kitoms klasterių, taip pat daug prie jo prijungtų klasterių. Prieiga prie bet kurios iš jų gali būti suteikta tiesiog įtraukiant vartotoją į ldap katalogą, nepaisant kur jis yra ir kokio teikėjo išteklius naudoja.
Naudojant gitlab-ci ir Terraform, buvo sukurta sistema, leidžianti sukurti bet kokios konfigūracijos klasterį debesų tiekėjų ar mūsų pačių infrastruktūroje ir prijungti juos prie Rancher. Visa tai daroma IaC stiliumi, kur kiekvienas klasteris aprašomas saugykloje, o jo būsena yra versija. Tuo pačiu metu dauguma modulių prijungiami iš išorinių saugyklų, todėl belieka perduoti kintamuosius arba aprašyti pasirinktinę konfigūraciją, kuri padeda sumažinti kodo pasikartojimo procentą.
Žinoma, mūsų kelionė dar toli gražu nesibaigė ir laukia dar daug įdomių užduočių, tokių kaip vienas darbo taškas su bet kokių grupių žurnalais ir metrika, paslaugų tinklelis, gitopai, skirti valdyti krovinius daugialypėje grupėje ir daug daugiau. Tikimės, kad mūsų patirtis bus įdomi!
Straipsnį parašė A. Antipovas, A. Ganušas, platformos inžinieriai.
Šaltinis: www.habr.com