Hæ Habr!
Við erum fulltrúar Exness vettvangsteymis. Áður skrifuðu samstarfsmenn okkar grein um . Í dag viljum við deila reynslu okkar af því að flytja þjónustu til Kubernetes.
Til að byrja með bjóðum við þér nokkrar tölur til að fá betri skilning á því sem verður rætt:
- Þróunardeildin okkar samanstendur af 100+ fólki, þar á meðal meira en 10 mismunandi teymi með sjálfbært QA, DevOps og Scrum ferla. Þróunarstafla - Python, PHP, C++, Java og Golang.
- Stærð prófunar- og framleiðsluumhverfisins er um 2000 gámar hvor. Þeir eru að keyra Rancher v1.6 á eigin sýndarvæðingu og undir VMware.
Hvatning
Eins og þeir segja, ekkert endist að eilífu og Rancher tilkynnti að stuðningur við útgáfu 1.6 væri lokið fyrir nokkuð löngu síðan. Já, á meira en þremur árum höfum við lært hvernig á að undirbúa það og leysa vandamál sem upp koma, en oftar og oftar stöndum við frammi fyrir vandamálum sem aldrei verður leiðrétt. Rancher 1.6 er einnig með kerfi til að gefa út réttindi, þar sem þú getur annað hvort gert nánast allt eða ekkert.
Þrátt fyrir að sérsniðin sýndarvæðing hafi veitt meiri stjórn á gagnageymslu og öryggi þeirra, lagði hún á rekstrarkostnað sem erfitt var að sætta sig við miðað við stöðugan vöxt fyrirtækisins, fjölda verkefna og kröfur til þeirra.
Við vildum fylgja IaC stöðlum og, ef nauðsyn krefur, fá afkastagetu fljótt, á hvaða landfræðilegu stað sem er og án sölulás, og einnig getað yfirgefið það fljótt.
Fyrstu skrefin
Í fyrsta lagi vildum við treysta á nútímatækni og lausnir sem myndu gera teymum kleift að hafa hraðari þróunarferil og lágmarka rekstrarkostnað við samskipti við vettvanginn sem veitir kraft.
Auðvitað, það fyrsta sem okkur datt í hug var Kubernetes, en við urðum ekki spennt og gerðum smá könnun til að sjá hvort það væri rétti kosturinn. Við metum aðeins opnar lausnir og í ósanngjarnri baráttu vann Kubernetes skilyrðislaust.
Næst kom spurningin um að velja tæki til að búa til klasa. Við bárum saman vinsælustu lausnirnar: kops, kubespray, kubeadm.
Til að byrja með fannst okkur kubeadm vera of flókin leið, frekar eins og einhvers konar uppfinningamaður „hjóla“ og kopar höfðu ekki nægan sveigjanleika.
Og sigurvegarinn var:
Við byrjuðum að gera tilraunir með okkar eigin sýndarvæðingu og AWS og reyndum að endurskapa eitthvað sem er nokkurn veginn svipað fyrra auðlindastjórnunarmynstri okkar, þar sem allir deildu sama „þyrpingunni“. Og nú höfum við fyrsta þyrpinguna okkar af 10 litlum sýndarvélum, nokkrar þeirra eru staðsettar í AWS. Við byrjuðum að reyna að flytja lið þangað, allt virtist vera „allt í lagi“ og hægt var að klára söguna, en...
Fyrstu vandamálin
Ansible er það sem kubespray er byggt á, það er ekki tól sem gerir þér kleift að fylgja IaC: Þegar hnútar voru teknir í notkun eða teknir úr notkun fór stöðugt eitthvað úrskeiðis og einhvers konar inngrip var krafist, og þegar mismunandi stýrikerfi voru notuð, hegðaði leikbókin öðruvísi. . Eftir því sem teymum og hnútum fjölgaði í þyrpingunni fórum við að taka eftir því að það tók lengri og lengri tíma að klára leikbókina og þar af leiðandi var metið okkar 3,5 klukkustundir, hvað með þitt? 🙂
Og það virðist sem kubespray sé bara Ansible og allt er ljóst við fyrstu sýn, en:
Í upphafi ferðalagsins var verkefnið að ræsa getu eingöngu í AWS og á sýndarvæðingu, en svo, eins og oft vill verða, breyttust kröfurnar.
Í ljósi þessa varð ljóst að gamla mynstur okkar að sameina auðlindir í eitt hljómsveitarkerfi hentaði ekki - þar sem klasarnir eru mjög fjarlægir og eru stjórnaðir af mismunandi veitendum.
Frekari meira. Þegar öll teymi vinna innan sama þyrpingarinnar gætu ýmsar þjónustur með rangt uppsettar NodeSelectors flogið til „erlends“ gestgjafa annars liðs og nýtt auðlindir þar, og ef taug var sett á þá komu stöðugar beiðnir um að ein eða önnur þjónusta virkaði ekki, ekki dreift rétt vegna mannlegs þáttar. Annað vandamál var að reikna út kostnaðinn, sérstaklega með tilliti til vandamálanna við að dreifa þjónustu milli hnúta.
Sérstök saga var útgáfa réttinda til starfsmanna: hvert lið vildi vera „í höfuðið“ í klasanum og stjórna honum algjörlega, sem gæti valdið algjöru hruni, þar sem teymin eru í grundvallaratriðum óháð hvert öðru.
Hvað á að gera?
Með hliðsjón af ofangreindu og óskum teymanna um að vera sjálfstæðari komumst við að einföldum niðurstöðum: eitt lið - einn þyrping.
Svo við fengum annan:
Og svo þriðji klasinn:
Þá fórum við að hugsa: Segjum að liðin okkar verði með fleiri en einn hóp eftir eitt ár? Á mismunandi landsvæðum, til dæmis, eða undir stjórn mismunandi veitenda? Og sumir þeirra vilja geta sent tímabundinn þyrping fljótt fyrir sum próf.
Full Kubernetes myndi koma! Þetta er einhvers konar MultiKubernetes, kemur í ljós.
Á sama tíma munum við öll þurfa einhvern veginn að viðhalda öllum þessum klösum, geta auðveldlega stjórnað aðgangi að þeim, auk þess að búa til nýja og taka gamla úr notkun án handvirkrar íhlutunar.
Nokkur tími er liðinn frá upphafi ferðalags okkar í heimi Kubernetes og við ákváðum að endurskoða tiltækar lausnir. Það kom í ljós að það er þegar til á markaðnum - Rancher 2.2.
Á fyrsta stigi rannsóknar okkar hafði Rancher Labs þegar gert fyrstu útgáfu af útgáfu 2, en þó að hægt væri að hækka hana mjög fljótt með því að ræsa gám án utanaðkomandi ósjálfstæðis með nokkrum breytum eða nota opinbera HELM myndritið, virtist það gróft. til okkar, og við vissum ekki hvort við gætum treyst á þessa ákvörðun hvort hún verði þróuð eða fljótt hætt. Cluster = smellir hugmyndafræðin í HÍ sjálfu hentaði okkur heldur ekki, og við vildum ekki bindast RKE, þar sem það er frekar þröngt einbeitt verkfæri.
Útgáfa Rancher 2.2 var nú þegar með virkara útliti og, ásamt þeim fyrri, hafði fullt af áhugaverðum eiginleikum úr kassanum, svo sem samþættingu við marga utanaðkomandi veitendur, einn dreifingarstað réttinda og kubeconfig skrár, opna kubectl mynd með réttindum þínum í notendaviðmótinu, hreiðrað nafnasvæði aka verkefni.
Það var líka samfélag þegar stofnað í kringum Rancher 2 og veitandi sem heitir HashiCorp Terraform var stofnaður til að stjórna því, sem hjálpaði okkur að setja allt saman.
Hvað gerðist
Fyrir vikið enduðum við með einn lítinn klasa sem keyrir Rancher, aðgengilegan öllum öðrum klasa, auk margra klasa tengdum honum, aðgangur að hverjum þeirra er hægt að veita eins einfaldlega og að bæta notanda við ldap skrána, óháð því. hvar það er staðsett og hvaða auðlindir það notar.
Með því að nota gitlab-ci og Terraform var búið til kerfi sem gerir þér kleift að búa til þyrping af hvaða uppsetningu sem er í skýjaveitum eða okkar eigin innviði og tengja þá við Rancher. Allt er þetta gert í IaC stíl, þar sem hverjum klasa er lýst af geymslu og ástand hans er útfært. Á sama tíma eru flestar einingar tengdar frá ytri geymslum þannig að allt sem er eftir er að senda breytur eða lýsa sérsniðnu uppsetningunni þinni fyrir tilvik, sem hjálpar til við að draga úr hlutfalli endurtekningar kóða.
Auðvitað er ferð okkar hvergi nærri lokið og enn eru mörg áhugaverð verkefni framundan, eins og einn vinnustaður með logs og mælikvarða á hvaða klasa sem er, þjónustunet, gitops til að stjórna álagi í fjölklasa og margt fleira. Við vonum að þér finnist reynsla okkar áhugaverð!
Greinin var skrifuð af A. Antipov, A. Ganush, Platform Engineers.
Heimild: www.habr.com