Äau Habr!
MÄs pÄrstÄvam Exness platformas komandu. IepriekÅ” mÅ«su kolÄÄ£i jau rakstÄ«ja rakstu par . Å odien mÄs vÄlamies dalÄ«ties pieredzÄ par pakalpojumu migrÄÅ”anu uz Kubernetes.
SÄkumÄ mÄs piedÄvÄjam dažus skaitļus, lai labÄk izprastu, kas tiks apspriests:
- MÅ«su attÄ«stÄ«bas nodaÄ¼Ä ir vairÄk nekÄ 100 cilvÄku, tostarp vairÄk nekÄ 10 dažÄdas komandas ar paÅ”pietiekamiem QA, DevOps un Scrum procesiem. IzstrÄdes kaudze - Python, PHP, C++, Java un Golang.
- Testa un ražoÅ”anas vides lielums ir aptuveni 2000 konteineru katrÄ. ViÅi izmanto Rancher v1.6 savÄ virtualizÄcijÄ un VMware.
MotivÄcija
KÄ saka, nekas neturpinÄs mūžīgi, un Rancher jau diezgan sen paziÅoja par 1.6 versijas atbalsta beigÄm. JÄ, vairÄk nekÄ trÄ«s gadu laikÄ esam iemÄcÄ«juÅ”ies to sagatavot un risinÄt raduÅ”Äs problÄmas, taÄu arvien biežÄk saskaramies ar problÄmÄm, kuras nekad netiks labotas. Rancher 1.6 ir arÄ« pÄrkaulota tiesÄ«bu izsniegÅ”anas sistÄma, kurÄ jÅ«s varat darÄ«t gandrÄ«z visu vai neko.
Lai gan patentÄtÄ virtualizÄcija nodroÅ”inÄja lielÄku kontroli pÄr datu glabÄÅ”anu un tÄs droŔību, tÄ radÄ«ja darbÄ«bas izmaksas, kuras bija grÅ«ti pieÅemt, Åemot vÄrÄ pastÄvÄ«go uzÅÄmuma izaugsmi, projektu skaitu un prasÄ«bas tiem.
MÄs vÄlÄjÄmies ievÄrot IaC standartus un, ja nepiecieÅ”ams, iegÅ«t jaudu Ätri, jebkurÄ Ä£eogrÄfiskÄ vietÄ un bez pÄrdevÄja bloÄ·ÄÅ”anas, kÄ arÄ« spÄt Ätri no tÄs atteikties.
Pirmie soļi
PirmkÄrt, mÄs vÄlÄjÄmies paļauties uz modernÄm tehnoloÄ£ijÄm un risinÄjumiem, kas ļautu komandÄm veikt ÄtrÄku izstrÄdes ciklu un samazinÄt darbÄ«bas izmaksas, mijiedarbojoties ar platformu, kas nodroÅ”ina jaudu.
Protams, pirmais, kas mums ienÄca prÄtÄ, bija Kubernetes, taÄu mÄs nesajÅ«sminÄjÄmies un veicÄm nelielu izpÄti, lai noskaidrotu, vai tÄ ir pareizÄ izvÄle. MÄs izvÄrtÄjÄm tikai atvÄrtÄ pirmkoda risinÄjumus, un negodÄ«gÄ cÄ«ÅÄ Kubernetes bez ierunÄm uzvarÄja.
TÄlÄk sekoja jautÄjums par klasteru izveides rÄ«ka izvÄli. SalÄ«dzinÄjÄm populÄrÄkos risinÄjumus: kops, kubespray, kubeadm.
IesÄkumam kubeadm mums Ŕķita pÄrÄk sarežģīts ceļŔ, drÄ«zÄk kÄ sava veida āvelosipÄdaā izgudrotÄjs, un kops nepietika elastÄ«bas.
Un uzvarÄtÄjs bija:
MÄs sÄkÄm eksperimentÄt ar savu virtualizÄciju un AWS, mÄÄ£inot atjaunot kaut ko aptuveni lÄ«dzÄ«gu mÅ«su iepriekÅ”Äjam resursu pÄrvaldÄ«bas modelim, kurÄ visi koplietoja vienu un to paÅ”u "klasteri". Un tagad mums ir pirmais 10 mazu virtuÄlo maŔīnu klasteris, no kurÄm dažas atrodas AWS. MÄs sÄkÄm mÄÄ£inÄt migrÄt komandas, viss likÄs "labi", un stÄstu varÄja pabeigt, bet...
PirmÄs problÄmas
Ansible ir tas, uz kura ir veidots kubespray, tas nav rÄ«ks, kas ļauj sekot IaC: nododot ekspluatÄcijÄ/izslÄdzot mezglus, pastÄvÄ«gi kaut kas nogÄja greizi un bija nepiecieÅ”ama kaut kÄda iejaukÅ”anÄs, un, izmantojot dažÄdas OS, rokasgrÄmata izturÄjÄs atŔķirÄ«gi. savÄdÄk . Pieaugot klastera komandu un mezglu skaitam, mÄs sÄkÄm pamanÄ«t, ka rokasgrÄmatas aizpildÄ«Å”ana aizÅem arvien ilgÄku laiku, un rezultÄtÄ mÅ«su rekords bija 3,5 stundas, kÄ ar jÅ«su? š
Un Ŕķiet, ka kubespray ir tikai Ansible, un viss ir skaidrs no pirmÄ acu uzmetiena, bet:
Ceļojuma sÄkumÄ uzdevums bija palaist jaudas tikai AWS un virtualizÄcijÄ, bet pÄc tam, kÄ tas bieži notiek, prasÄ«bas mainÄ«jÄs.
Å
emot to vÄrÄ, kļuva skaidrs, ka mÅ«su vecais modelis apvienot resursus vienÄ orÄ·estrÄÅ”anas sistÄmÄ nebija piemÄrots gadÄ«jumÄ, ja klasteri atrodas ļoti attÄlinÄti un tos pÄrvalda dažÄdi pakalpojumu sniedzÄji.
TÄlÄk vairÄk. Kad visas komandas strÄdÄ vienÄ klasterÄ«, dažÄdi servisi ar nepareizi uzstÄdÄ«tiem NodeSelectors varÄja aizlidot uz citas komandas āÄrzemjuā saimniekdatoru un tur izmantot resursus, un, ja tika uzlikts piesÄrÅojums, nepÄrtraukti skanÄja pieprasÄ«jumi, ka viens vai otrs pakalpojums nedarbojas, nav pareizi izplatÄ«ts cilvÄka faktora dÄļ. VÄl viena problÄma bija izmaksu aprÄÄ·inÄÅ”ana, Ä«paÅ”i Åemot vÄrÄ problÄmas, kas saistÄ«tas ar pakalpojumu sadali pa mezgliem.
AtseviŔķs stÄsts bija par tiesÄ«bu izsniegÅ”anu darbiniekiem: katra komanda vÄlÄjÄs bÅ«t klastera āgalvenÄā un pilnÄ«bÄ to pÄrvaldÄ«t, kas var izraisÄ«t pilnÄ«gu sabrukumu, jo komandas bÅ«tÄ«bÄ ir viena no otras neatkarÄ«gas.
Ko darīt?
Å emot vÄrÄ iepriekÅ” minÄto un komandu vÄlmes bÅ«t neatkarÄ«gÄkÄm, izdarÄ«jÄm vienkÄrÅ”u secinÄjumu: viena komanda - viens klasteris.
TÄtad mums ir otrs:
Un tad treŔais klasteris:
Tad sÄkÄm domÄt: teiksim, ka pÄc gada mÅ«su komandÄm bÅ«s vairÄk par vienu klasteru? PiemÄram, dažÄdos Ä£eogrÄfiskos apgabalos vai dažÄdu pakalpojumu sniedzÄju kontrolÄ? Un daži no viÅiem vÄlÄsies Ätri izvietot pagaidu kopu dažiem testiem.
Pilnas Kubernetes nÄktu! Tas ir sava veida MultiKubernetes, izrÄdÄs.
TajÄ paÅ”Ä laikÄ mums visiem bÅ«s kaut kÄdÄ veidÄ jÄuztur visas Ŕīs kopas, jÄspÄj viegli pÄrvaldÄ«t piekļuvi tiem, kÄ arÄ« izveidot jaunas un likvidÄt vecÄs bez manuÄlas iejaukÅ”anÄs.
Ir pagÄjis kÄds laiks kopÅ” mÅ«su ceļojuma sÄkuma Kubernetes pasaulÄ, un mÄs nolÄmÄm vÄlreiz pÄrbaudÄ«t pieejamos risinÄjumus. IzrÄdÄ«jÄs, ka tas jau pastÄv tirgÅ« - Rancher 2.2.
MÅ«su pÄtÄ«juma pirmajÄ posmÄ Rancher Labs jau bija izlaidusi pirmo versiju 2, taÄu, lai gan to varÄja ļoti Ätri palielinÄt, palaižot konteineru bez ÄrÄjÄm atkarÄ«bÄm ar pÄris parametriem vai izmantojot oficiÄlo HELM diagrammu, tas Ŕķita rupji. mums, un mÄs nezinÄjÄm, vai varam paļauties uz Å”o lÄmumu, vai tas tiks izstrÄdÄts vai Ätri atteikts. ArÄ« klastera = klikŔķu paradigma paÅ”Ä lietotÄja saskarnÄ mums nederÄja, un mÄs negribÄjÄm bÅ«t saistÄ«ti ar RKE, jo tas ir diezgan Å”auri fokusÄts rÄ«ks.
Versijai Rancher 2.2 jau bija funkcionÄlÄks izskats, un kopÄ ar iepriekÅ”ÄjÄm tai bija vairÄkas interesantas funkcijas, piemÄram, integrÄcija ar daudziem ÄrÄjiem pakalpojumu sniedzÄjiem, viens tiesÄ«bu un kubeconfig failu izplatÄ«Å”anas punkts, kubectl palaiÅ”ana. attÄls ar jÅ«su tiesÄ«bÄm lietotÄja saskarnÄ, ligzdotÄs nosaukumvietas jeb projekti.
Ap Rancher 2 jau bija izveidota arÄ« kopiena, un tÄs pÄrvaldÄ«bai tika izveidots pakalpojumu sniedzÄjs ar nosaukumu HashiCorp Terraform, kas mums palÄ«dzÄja visu apvienot.
Kas notika
RezultÄtÄ mÄs nonÄcÄm pie viena maza klastera, kurÄ darbojas Rancher, kas ir pieejams visiem pÄrÄjiem klasteriem, kÄ arÄ« daudziem ar to saistÄ«tiem klasteriem, no kuriem jebkuram piekļuvi var pieŔķirt vienkÄrÅ”i kÄ lietotÄja pievienoÅ”anu ldap direktorijam neatkarÄ«gi no kur tas atrodas un kura pakalpojumu sniedzÄja resursus tas izmanto.
Izmantojot gitlab-ci un Terraform, tika izveidota sistÄma, kas ļauj izveidot jebkuras konfigurÄcijas klasteru mÄkoÅpakalpojumos vai mÅ«su paÅ”u infrastruktÅ«rÄ un savienot tos ar Rancher. Tas viss tiek darÄ«ts IaC stilÄ, kur katru klasteru apraksta repozitorijs, un tÄ stÄvoklis tiek versÄts. TajÄ paÅ”Ä laikÄ lielÄkÄ daļa moduļu ir savienoti no ÄrÄjÄm krÄtuvÄm, tÄpÄc atliek tikai nodot mainÄ«gos vai aprakstÄ«t jÅ«su pielÄgoto konfigurÄciju gadÄ«jumiem, kas palÄ«dz samazinÄt koda atkÄrtoÅ”anÄs procentuÄlo daudzumu.
Protams, mÅ«su ceļojums ne tuvu nav beidzies, un priekÅ”Ä vÄl ir daudz interesantu uzdevumu, piemÄram, viens darba punkts ar žurnÄliem un jebkuru klasteru metriku, servisa tÄ«kls, gitopi kravu pÄrvaldÄ«bai vairÄkos klasteros un daudz kas cits. MÄs ceram, ka mÅ«su pieredze jums liksies interesanta!
Rakstu sarakstījuŔi A. Antipovs, A. GanuŔs, platformas inženieri.
Avots: www.habr.com