Hoi Habr!
Wy fertsjintwurdigje it Exness-platfoarmteam. Earder skreaunen ús kollega's al in artikel oer . Hjoed wolle wy ús ûnderfining diele mei it migrearjen fan tsjinsten nei Kubernetes.
Om te begjinnen biede wy jo wat sifers foar in better begryp fan wat sil wurde besprutsen:
- Us ûntwikkeling ôfdieling bestiet út 100+ minsken, ynklusyf mear as 10 ferskillende teams mei sels-genôch QA, DevOps en Scrum prosessen. Untwikkelingsstapel - Python, PHP, C++, Java en Golang.
- De grutte fan 'e test- en produksjeomjouwing is elk sawat 2000 konteners. Se rinne Rancher v1.6 op har eigen virtualisaasje en ûnder VMware.
Motivaasje
Lykas se sizze, duorret neat foar altyd, en Rancher kundige it ein fan stipe foar ferzje 1.6 frij lang lyn oan. Ja, yn mear as trije jier hawwe wy leard hoe't wy it tariede en problemen oplosse dy't ûntsteane, mar hieltyd faker wurde wy konfrontearre mei problemen dy't nea korrizjearre wurde. Rancher 1.6 hat ek in ossified systeem foar it útjaan fan rjochten, wêr't jo hast alles of neat kinne dwaan.
Hoewol't proprietêre virtualisaasje in gruttere kontrôle levere oer gegevensopslach en har feiligens, lei it bedriuwskosten op dy't lestich te akseptearjen wiene, sjoen de konstante groei fan it bedriuw, it oantal projekten en easken foar har.
Wy woenen IaC-standerts folgje en, as it nedich wie, fluch kapasiteit krije, op elke geografyske lokaasje en sûnder in ferkeaperslot, en ek yn steat wêze om it fluch te ferlitten.
earste stappen
Alderearst woenen wy fertrouwe op moderne technologyen en oplossingen dy't teams in flugger ûntwikkelingssyklus kinne hawwe en operasjonele kosten minimalisearje foar ynteraksje mei it platfoarm dat macht leveret.
Fansels wie it earste ding dat ús yn 't sin kaam Kubernetes, mar wy waarden net optein en diene in bytsje ûndersyk om te sjen oft it de goede kar wie. Wy evaluearren allinich opensource-oplossingen, en yn in ûnearlike striid wûn Kubernetes sûnder betingst.
Dêrnei kaam de fraach fan it kiezen fan in ark foar it meitsjen fan klusters. Wy fergelike de meast populêre oplossingen: kops, kubespray, kubeadm.
Om te begjinnen, kubeadm like ús in te yngewikkeld paad, earder as in soarte fan útfiner fan in "fyts", en kops hie net genôch fleksibiliteit.
En de winner wie:
Wy begûnen te eksperimintearjen mei ús eigen virtualisaasje en AWS, en besochten iets opnij te meitsjen dat sawat gelyk is oan ús eardere boarnebehearpatroan, wêr't elkenien itselde "kluster" dielde. En no hawwe wy ús earste kluster fan 10 lytse firtuele masines, wêrfan in pear yn AWS lizze. Wy begûnen te besykjen teams dêr te migrearjen, alles like "goed" te wêzen en it ferhaal koe ôfmakke wurde, mar ...
Earste problemen
Ansible is wêrop kubespray is boud, it is gjin ark wêrmei jo IaC folgje kinne: by it ynskeakeljen / ûntsluten fan knooppunten gie der hieltyd wat mis en wie in soarte fan yntervinsje nedich, en by it brûken fan ferskate OS's, gedraacht it playbook oars. oars . Doe't it oantal teams en knooppunten yn it kluster groeide, begûnen wy te merken dat it spielboek langer en langer duorre om te foltôgjen, en as gefolch wie ús rekord 3,5 oeren, hoe sit it mei dy? 🙂
En it liket as kubespray is gewoan Ansible, en alles is dúdlik op it earste each, mar:
Oan it begjin fan 'e reis wie de taak om kapasiteiten allinich yn AWS en op virtualisaasje te lansearjen, mar dan, lykas faaks bart, feroare de easken.
Yn it ljocht fan dit waard dúdlik dat ús âlde patroan fan it kombinearjen fan boarnen yn ien orkestraasjesysteem net geskikt wie - yn it gefal wêr't de klusters heul op ôfstân lizze en wurde beheard troch ferskate oanbieders.
Fierder mear. As alle teams wurkje binnen deselde kluster, ferskate tsjinsten mei ferkeard ynstallearre NodeSelectors koenen fleane nei de "bûtenlânske" host fan in oar team en benutte middels dêr, en as taint waard ynsteld, der wiene konstante fersiken dat ien of oare tsjinst wurke net, net korrekt ferdield fanwege minsklike faktor. In oar probleem wie it berekkenjen fan de kosten, benammen sjoen de problemen by it fersprieden fan tsjinsten oer knooppunten.
In apart ferhaal wie it útjaan fan rjochten oan meiwurkers: elk team woe "oan 'e kop" fan it kluster stean en it folslein beheare, wat in folsleine ynstoarting feroarsaakje koe, om't de teams yn prinsipe ûnôfhinklik fan elkoar binne.
Hoe moat it wêze?
Mei it each op it boppesteande en de winsken fan de teams om selsstanniger te wêzen, makken wy in ienfâldige konklúzje: ien team - ien kluster.
Sa krigen wy in twadde:
En dan de tredde kluster:
Doe begûnen wy te tinken: litte we sizze dat ús teams oer in jier mear as ien kluster hawwe? Yn ferskate geografyske gebieten, bygelyks, of ûnder de kontrôle fan ferskate oanbieders? En guon fan harren wolle fluch in tydlik kluster kinne ynsette foar guon tests.
Folsleine Kubernetes soe komme! Dit is in soarte fan MultiKubernetes, docht bliken.
Tagelyk sille wy allegear op ien of oare manier al dizze klusters moatte behâlde, de tagong ta har maklik kinne beheare, en ek nije oanmeitsje en âlde útskeakelje sûnder manuele yntervinsje.
Guon tiid is ferrûn sûnt it begjin fan ús reis yn 'e wrâld fan Kubernetes, en wy besletten de beskikbere oplossingen opnij te ûndersiikjen. It die bliken dat it al op 'e merke bestiet - Rancher 2.2.
Yn 'e earste faze fan ús ûndersyk hie Rancher Labs de earste release fan ferzje 2 al makke, mar hoewol it heul rap koe wurde ferhege troch in kontener te lansearjen sûnder eksterne ôfhinklikens mei in pear parameters of it brûken fan de offisjele HELM Chart, like it rûch oan ús, en wy wisten net oft wy koenen fertrouwe op dit beslút oft it sil wurde ûntwikkele of gau ferlitten. It kluster = klikken paradigma yn 'e UI sels paste ús ek net, en wy woenen net bûn wurde oan RKE, om't it in nochal smel rjochte ark is.
Ferzje Rancher 2.2 hie al in mear wurkber uterlik en hie tegearre mei de foargeande in protte nijsgjirrige funksjes út 'e doaze, lykas yntegraasje mei in protte eksterne providers, ien punt fan distribúsje fan rjochten en kubeconfig-bestannen, it starten fan in kubectl ôfbylding mei jo rjochten yn 'e UI, geneste nammeromten aka projekten.
D'r wie ek in mienskip al foarme om Rancher 2, en in provider neamd HashiCorp Terraform waard makke om it te behearjen, wat ús holp alles byinoar te setten.
Wat is der bart
As gefolch hawwe wy ien lyts kluster dat Rancher draait, tagonklik foar alle oare klusters, lykas ek in protte klusters dy't dêrmei ferbûn binne, tagong ta elk dêrfan kin wurde ferliend sa ienfâldich as it tafoegjen fan in brûker oan 'e ldap-map, nettsjinsteande wêr't it leit en hokker boarnen fan provider it brûkt.
Mei help fan gitlab-ci en Terraform is in systeem makke wêrmei jo in kluster meitsje kinne fan elke konfiguraasje yn wolkproviders as ús eigen ynfrastruktuer en se ferbine mei Rancher. Dit alles wurdt dien yn 'e IaC-styl, wêr't elk kluster wurdt beskreaun troch in repository, en syn steat is ferzje. Tagelyk binne de measte modules ferbûn fan eksterne repositories, sadat alles wat oerbliuwt is om fariabelen troch te jaan of jo oanpaste konfiguraasje foar eksimplaren te beskriuwen, wat helpt om it persintaazje koade werhelling te ferminderjen.
Fansels is ús reis noch lang net foarby en d'r binne noch in protte nijsgjirrige taken foarút, lykas ien wurkpunt mei logs en metriken fan alle klusters, servicemesh, gitops foar it behearen fan loads yn in multicluster en folle mear. Wy hoopje dat jo ús ûnderfining ynteressant fine!
It artikel waard skreaun troch A. Antipov, A. Ganush, Platform Engineers.
Boarne: www.habr.com