Tere, Habr!
Tutvustame Exnessi ettevõtte platvormi meeskonda. Varasemalt on meie kolleegid kirjutanud artikli . Täna soovime jagada kogemusi teenuste migreerimisel Kubernetesesse.
Alustuseks pakume teile veidi numbreid, et paremini mõista, millest jutt käib:
- Meie arendusosakonnas on üle 100 inimese, sealhulgas rohkem kui 10 erinevat meeskonda iseseisvate QA, DevOps ja Scrum protsessidega. Arendustehnoloogia — Python, PHP, C++, Java ja Golang.
- Katsesüsteem ja tootmiskeskkond — umbes 2000 konteinerit kummaski. Need on halduses Rancher v1.6 oma virtualiseerimise ja VMware'i all.
Motivatsioon
Nagu öeldakse, ei ole miski igavene kuu all, ja Rancher on juba ammu kuulutanud välja versiooni 1.6 toe lõpetamise. Jah, me oleme üle kolme aasta õppinud sellega toime tulema ja probleeme lahendama, kuid üha enam sattusime probleemide kätte, mida kunagi ei lahendata. Samuti on Rancher 1.6-l jäik õiguste süsteem, kus saad kas peaaegu kõike või mitte midagi.
Oma virtualiseerimine andis küll suuremat kontrolli andmete ja nende turvalisuse üle, kuid tõi kaasa kulud, millega oli raske leppida ettevõtte pideva kasvu, projektide arvu ja nende nõudmiste tõttu.
Me soovisime järgida IaC standarditele ja vajadusel kiiresti ressursse saada igas geograafias ning ilma müügi piiranguteta, samuti kiiresti need tagasi anda.
Esimesed sammud
Esiteks soovisime toetuda kaasaegsetele tehnoloogiatele ja lahendustele, mis võimaldaksid meeskondadel kiiremini arendada ning miinimumini vähendada toimingute kulusid platvormiga, mis ressursse pakub.
Muidugi tuli meelde Kubernetes, kuid me ei hakanud kiirustama ja viisime läbi väikese uurimuse oma valiku õigustamiseks. Hindasime ainult avatud lähtekoodiga lahendusi ja ausa mõõduvõtuga võitis Kubernetes.
Järgmine küsimus oli tööriistade valik klastrite loomiseks. Võrdlesime kõige populaarsemaid lahendusi: kops, kubespray, kubeadm.
Kubeadm tundus alguseks liiga keeruline lahendus, pigem nagu jalgratta leiutamine, ja kopsil puudus paindlikkus.
Nii et võitjaks osutus:
Alustasime katsetusi oma virtualiseerimises ja AWS-is, püüdes luua meie eelmise ressursihaldusmustri sarnase mudeli, kus kõik kasutavad ühte ja sama "klastri". Ja nii tekkis meil esimene kümne väikese virtuaalmasinad, paar neist asub AWS-is. Hakkasime proovima meeskondi sinna migreerida, tundus nagu kõik läks "hästi", ja jutust oleks võinud lõppeda, kuid …
Esimesed probleemid
Ansible — millele kubespray põhineb, ei ole see tööriist, mis võimaldaks järgida IaC: nodede sisse- ja väljaviimisel tekkis pidevalt probleeme, mis vajasid sekkumist, ja erinevate OS-ide kasutamisel käitus playbook erinevalt. Meeskondade ja klastrisse kuuluvate node'ide arvu suurenedes märkasime, et playbooki täitmine kestab üha kauem, meie rekord on 3,5 tundi, aga teie oma? 🙂
Ja näiliselt on kubespray lihtsalt Ansible ja kõik on esmapilgul arusaadav, kuid:
Teel olid eesmärgid käivitada ressursse ainult AWS-is ja virtualiseerimises, kuid nagu see sageli juhtub, nõudmised muutusid.
Selle valguses sai selgeks, et meie vana mustri ühendamiseks ei sobinud enam süsteemil, kus klastri halduses on erinevad teenusepakkujad.
Edasi — veelgi enam. Kui kõik meeskonnad töötavad ühe klastriga, võisid vale NodeSelectori seadistusega erinevad teenused sattuda «õõnsale» hostile teise meeskonna all ja seal ressursse kasutada, ning taint'i seadmisel tekivad pidevad kaebused, et üks või teine teenus ei tööta, ei jaotu õigesti inimfaktori tõttu. Veel üks probleem oli kulude arvutamine, eriti arvestades teenuste jaotamisega seotud probleeme node'ide vahel.
Erinev lugu oli töötajatele õiguste jagamine: iga meeskond soovis olla «esirinnas» klastris ja seda täielikult juhtida, mis võis põhjustada täieliku kaose, kuna meeskonnad olid enamasti üksteisest sõltumatud.
Kuidas edasi?
Arvestades eeltoodut ja meeskondade soove olla iseseisvamad, jõudsime lihtsale järeldusele: üks meeskond — üks klaster.
Nii sündis meie teine:
Ja seejärel ka kolmas klaster:
Siin hakkasime mõtlema: oletame, et aasta pärast on meie meeskondadel rohkem kui üks klaster? Erinevates geograafilistes piirkondades, näiteks, või erinevate teenusepakkujate hallata? Ja keegi neist tahaks kiiresti käivitada ajutise klastrite jaoks mõningaid teste.
Kübertõepoolest! See on nagu MultiKubernetes, tuleb välja.
Samuti peame kõikide nende klastrite hoolduseks olema mingil viisil võimelised, omama lihtsat juurdepääsu haldamise võimalust ning looma uusi ja vanade kasutusest väljavõtmise ilma käsitsi sekkumiseta.
Alates meie teekonna algusest Kubernetes'e maailmas on möödunud mõnda aega ja oleme otsustanud uurida olemasolevaid lahendusi uuesti. Selgus, et turul on see juba olemas — Rancher 2.2.
Uuringute esimeses etapis oli Rancher Labs juba välja andnud esimese versiooni 2, kuid kuigi seda sai väga kiiresti käivitada, käivitades konteineri ilma väliste sõltuvusteta paariparameetriga või kasutades ametlikku HELM Chart'i, tundus see meile toore ja me ei teadnud, kas saame sellele lahendusele loota, kas seda arendatakse edasi või jäetakse kiiresti tähelepanuta. Isegi klaster = klikkimine UI-s paradigma ei sobinud meile, ja me ei tahtnud RKE'le toetuda, kuna see on üsna kitsalt suunatud tööriist.
Versioon Rancher 2.2 oli juba palju toimivam ja koos eelnevaga omas hulgaliselt huvitavaid võimalusi karbist välja, nagu integratsioon paljude välistesse teenusepakkujatesse, õiguste ja kubeconfig failide ühtne jaotamispunkt, kubectl piltide käivitamine sinu õigustega UI-s, ja sissekanded ehk projektid.
Rancher 2 ümber oli samuti moodustunud kogukond ja loomise kaudu HashiCorp Terraform'i teenusepakkuja, mis aitas meil kõik ühte koondada.
Mis välja tuli
Kokkuvõttes saime ühe väikese klastri, kus on käivitatud Rancher, mis on kergesti juurdepääsetav kõigile teistele klastritele, samuti paljudele seotud klastritele, millele juurdepääsu saab anda sama lihtsalt, kui lisada kasutaja ldap katalooge, sõltumata tema asukohast ja kasutatava ressursi teenusepakkujast.
Gitlab-ci ja Terraform'i abil loodi süsteem, mis võimaldab luua klastrit igasuguste konfiguratsioonidena pilveteenusepakkujates või meie enda infrastruktuuris ja ühendada need Rancher'iga. Kõik see tehti IaC stiilis, kus iga klaster on kirjeldatud repositooriumiga ja selle olek on versiooni muutunud. Enamik mooduleid ühendatakse välistest repositooriumidest, nii et tuleb lihtsalt edastada muutujad või kirjeldada oma kohandatud konfiguratsiooni instantside jaoks, mis aitab vähendada koodi kordumise protsenti.
Loomulikult ei ole meie teekond veel kaugeltki lõppenud ja ees on veel palju huvitavaid ülesandeid, nagu logide ja mõõtmehalduse ühtne punkt kõigi klastrite jaoks, teenuse mesh, gitops koormuse haldamiseks multi-klastris ja palju muud. Loodame, et meie kogemus on teile huvitav!
Artikli kirjutasid A. Antipov, A. Ganush, Platform Engineers.
Allikas: habr.com
