Tere Habr!
Me esindame Exnessi platvormi meeskonda. Varem on meie kolleegid juba kirjutanud artikli . Täna tahame jagada oma kogemusi teenuste Kubernetesesse üleviimisest.
Alustuseks pakume teile mõningaid numbreid, et paremini mõista, mida arutatakse:
- Meie arendusosakond koosneb 100+ inimesest, sealhulgas enam kui 10 erinevast meeskonnast, kellel on isemajandavad QA, DevOps ja Scrumi protsessid. Arenduspinn – Python, PHP, C++, Java ja Golang.
- Testimis- ja tootmiskeskkondade suurus on umbes 2000 konteinerit. Nad kasutavad Rancheri versiooni 1.6 oma virtualiseerimisel ja VMware all.
Motivatsioon
Nagu öeldakse, ei kesta miski igavesti ja Rancher teatas versiooni 1.6 toe lõppemisest üsna kaua aega tagasi. Jah, enam kui kolme aastaga oleme õppinud seda ette valmistama ja tekkivaid probleeme lahendama, kuid üha sagedamini seisame silmitsi probleemidega, mida ei saa kunagi parandada. Rancher 1.6-l on ka luustunud süsteem õiguste väljastamiseks, kus saab teha peaaegu kõike või mitte midagi.
Kuigi patenteeritud virtualiseerimine andis suurema kontrolli andmete salvestamise ja selle turvalisuse üle, tõi see kaasa tegevuskulusid, mida oli ettevõtte pidevat kasvu, projektide arvu ja neile esitatavaid nõudeid arvestades raske aktsepteerida.
Tahtsime järgida IaC standardeid ja vajadusel hankida võimsust kiiresti, igas geograafilises asukohas ja ilma müüjalukuta ning sellest ka kiiresti loobuda.
Esimesed sammud
Esiteks soovisime toetuda kaasaegsetele tehnoloogiatele ja lahendustele, mis võimaldaksid meeskondadel kiiremat arendustsüklit ja minimeerida tegevuskulusid võimsust pakkuva platvormiga suhtlemisel.
Muidugi, esimene asi, mis meile pähe tuli, oli Kubernetes, kuid me ei erutunud ja uurisime veidi, kas see on õige valik. Hindasime ainult avatud lähtekoodiga lahendusi ja ebaausas lahingus võitis tingimusteta Kubernetes.
Edasi tuli klastrite loomise tööriista valimise küsimus. Võrdlesime populaarsemaid lahendusi: kops, kubespray, kubeadm.
Alustuseks tundus kubeadm meile liiga keeruline rada, pigem omamoodi “jalgratta” leiutaja ja kopsidel polnud piisavalt paindlikkust.
Ja võitjaks osutus:
Hakkasime eksperimenteerima oma virtualiseerimise ja AWS-iga, püüdes uuesti luua midagi, mis on ligikaudu sarnane meie eelmise ressursihaldusmustriga, kus kõik jagasid sama "klastrit". Ja nüüd on meil esimene 10 väikesest virtuaalmasinast koosnev klaster, millest paar asuvad AWS-is. Hakkasime proovima meeskondi sinna migreerida, kõik tundus olevat “hea” ja loo võiks lõpetada, aga...
Esimesed probleemid
Ansible on see, millele kubespray on üles ehitatud, see ei ole tööriist, mis võimaldab teil IaC-d jälgida: sõlmede kasutuselevõtmisel/dekomisjoneerimisel läks pidevalt midagi valesti ja oli vaja mingit sekkumist ning erinevate OS-ide kasutamisel käitus mänguraamat erinevalt. erinevalt . Klastris olevate meeskondade ja sõlmede arvu kasvades hakkasime märkama, et mänguraamatu valmimine võtab aina kauem aega ja selle tulemusel oli meie rekord 3,5 tundi, aga teie oma? 🙂
Ja tundub, et kubespray on lihtsalt Ansible ja kõik on esmapilgul selge, kuid:
Teekonna alguses oli ülesandeks võimsuste käivitamine ainult AWS-is ja virtualiseerimisel, kuid siis, nagu sageli juhtub, nõuded muutusid.
Selle valguses selgus, et meie vana muster ühendada ressursse üheks orkestreerimissüsteemiks ei sobi – juhul, kui klastrid on väga kauged ja neid haldavad erinevad pakkujad.
Edasi veel. Kui kõik meeskonnad töötavad samas klastris, võisid erinevad teenused valesti paigaldatud NodeSelectoritega lennata teise meeskonna “võõrasse” hosti ja kasutada seal ressursse ning kui rikuti, siis tuli pidevalt päringuid, et üks või teine teenus ei tööta, inimfaktori tõttu ei jaotata õigesti. Teine probleem oli kulude arvutamine, eriti kui arvestada probleeme teenuste jaotamisel sõlmede vahel.
Omaette lugu oli töötajatele õiguste andmisega: iga meeskond soovis olla klastri "eesotsas" ja seda täielikult juhtida, mis võib põhjustada täieliku kokkuvarisemise, kuna meeskonnad on põhimõtteliselt üksteisest sõltumatud.
Mida teha?
Võttes arvesse eelnevat ja meeskondade soove olla iseseisvamad, tegime lihtsa järelduse: üks meeskond - üks klaster.
Nii et saime teise:
Ja siis kolmas klaster:
Siis hakkasime mõtlema: oletame, et aasta pärast on meie meeskondadel rohkem kui üks klast? Näiteks erinevates geograafilistes piirkondades või erinevate pakkujate kontrolli all? Ja mõned neist soovivad mõne testi jaoks kiiresti juurutada ajutise klastri.
Täitsa Kubernetes tuleks! Selgub, et see on mingi MultiKubernetes.
Samal ajal peame kõik neid klastreid kuidagi hooldama, suutma neile hõlpsalt juurdepääsu hallata, samuti uusi klastreid looma ja vanu ilma käsitsi sekkumiseta dekomisjoneerima.
Meie teekonna algusest Kubernetese maailmas on möödas mõnda aega ja otsustasime saadaolevad lahendused uuesti üle vaadata. Selgus, et see on turul juba olemas – Rancher 2.2.
Meie uurimistöö esimeses etapis oli Rancher Labs juba teinud versiooni 2 esimese väljalaske, kuid kuigi seda sai väga kiiresti tõsta, käivitades paari parameetriga väliste sõltuvusteta konteineri või kasutades ametlikku HELM-i diagrammi, tundus see toores. meile ja me ei teadnud, kas saame sellele otsusele tugineda, kas see arendatakse välja või loobutakse kiiresti. Meile ei sobinud ka kasutajaliidese enda klastri = kliki paradigma ja me ei tahtnud end siduda RKE-ga, kuna see on üsna kitsa fookusega tööriist.
Versioon Rancher 2.2 oli juba töötavama välimusega ja sisaldas koos eelmistega hunnik huvitavaid funktsioone, nagu integratsioon paljude väliste pakkujatega, õiguste ja kubeconfig-failide üks levitamispunkt, kubectli käivitamine pilt teie õigustega kasutajaliideses, pesastatud nimeruumid ehk projektid.
Rancher 2 ümber oli ka juba moodustatud kogukond ja selle haldamiseks loodi pakkuja nimega HashiCorp Terraform, mis aitas meil kõik kokku panna.
Mis juhtus
Selle tulemusel jõudsime ühe väikese klastrini, kus töötab Rancher, mis on juurdepääsetav kõikidele teistele klastritele, aga ka paljudele sellega ühendatud klastritele, millest igaühele juurdepääsu saab anda sama lihtsalt kui kasutaja lisamine ldap kataloogi, olenemata kus see asub ja millise teenusepakkuja ressursse see kasutab.
Gitlab-ci ja Terraformi abil loodi süsteem, mis võimaldab luua pilvepakkujates või meie enda infrastruktuuris mis tahes konfiguratsiooni klastri ja ühendada need Rancheriga. Kõik see toimub IaC stiilis, kus iga klastrit kirjeldab hoidla ja selle olek on versioonistatud. Samal ajal ühendatakse enamik mooduleid välistest hoidlatest, nii et jääb üle vaid muutujaid edastada või oma eksemplaride kohandatud konfiguratsiooni kirjeldada, mis aitab vähendada koodi korduste protsenti.
Muidugi pole meie teekond veel kaugeltki lõppenud ja ees on veel palju huvitavaid ülesandeid, nagu üks tööpunkt mis tahes klastrite logide ja mõõdikutega, teenindusvõrk, gitopsid koormate haldamiseks multiklastris ja palju muud. Loodame, et meie kogemus on teile huvitav!
Artikli kirjutasid A. Antipov, A. Ganush, Platform Engineers.
Allikas: www.habr.com