🥇K8S Multicluster Journey

Përshëndetje, Habr!

Ne paraqesim ekipin e platformës së kompanisë Exness. Më parë kolegët tanë kishin shkruar një artikull për Imazhe të gatshme për prodhim për k8s. Sot dëshirojmë të ndajmë përvojën e migrimit të shërbimeve në Kubernetes.

Fillimisht, ju propozojmë disa shifra për të kuptuar më mirë se për çfarë do të flasim:

Departamenti ynë i zhvillimit përbëhet nga mbi 100 persona, mes të cilëve më shumë se 10 grupe të ndryshme me procese të vetëqëndrueshme QA, DevOps dhe Scrum. Staku i zhvillimit është Python, PHP, C++, Java dhe Golang.
Madhësia e mjedisit të testimit dhe produktit është rreth 2000 konteinerë në secilin. Ato menaxhohen nga Rancher v1.6 në virtualizimin e saj dhe nën VMware.

Motivimi

Siç thuhet, asgjë nuk është e përhershme nën hënë, dhe Rancher ka shpallur tashmë përfundimin e mbështetjes për versionin 1.6. Po, ne mësuam ta përgatisim dhe të zgjidhim problemet që lindën për më shumë se tre vjet, por gjithnjë e më shpesh hasëm probleme që kurrë nuk do të zgjidhen. Gjithashtu, Rancher 1.6 ka një sistem të ngurtë për dhënien e të drejtave, ku mund të kesh pothuajse gjithçka ose asgjë.

Virtualizimi ynë, edhe pse ofronte më shumë kontroll mbi ruajtjen dhe sigurinë e të dhënave, impononte shpenzime operative me të cilat ishte e vështirë të pajtoheshim për shkak të rritjes së vazhdueshme të kompanisë, numrit të projekteve dhe kërkesave për to.

Na shqetësonte që të ndjekim standardet IaC dhe, sipas nevojës, të marrim kapacitete shpejt, në çdo lokacion gjeografik dhe pa varësi nga ofruesi, si dhe të kemi mundësinë të heqim dorë shpejt nga to.

Hapat e parë

Në radhë të parë, doja të mbështetem në teknologjitë dhe zgjidhjet moderne, që do t’i mundësonin grupeve një cikël më të shpejtë zhvillimi dhe të minimizonin shpenzimet operative në bashkëveprimin me një platformë që ofron kapacitete.

Sigurisht, e para gjë që na shkoi në mendje ishte Kubernetes, por ne nuk u nxituam dhe bëmë një hulumtim të vogël mbi saktësinë e zgjedhjes. Ne vlerësonim vetëm zgjidhjet opensource, dhe në një garë të padrejtë, Kubernetes fitoi pa asnjë dyshim.

Më pas erdhi çështja e zgjedhjes së mjetit për krijimin e klasterëve. Kemi krahasuar zgjidhjet më të njohura: kops, kubespray, kubeadm.

Në fillim, kubeadm na dukej një rrugë shumë e komplikuar, ndoshta si ndonjë shpikës i "bicikletës", ndërsa kopsit i mungonte fleksibiliteti.

Dhe fituesi doli:

Filluam të bëjmë eksperimente në virtualizimin tonë dhe AWS, duke u përpjekur të ricreiym një model të ngjashëm menaxhimi të burimeve, ku të gjithë përdorin të njëjtin "klaster". Dhe kështu u krijua klasteri ynë i parë me 10 të vegjël makinave virtuale, disa nga të cilët ndodhen në AWS. Filluam të provonim të migronim aty ekipet, duke menduar se gjithçka ishte "mirë", dhe fabula mund të përfundonte këtu, por…

Problemet e Para

Ansible — ajo mbi të cilën është ndërtuar kubespray, nuk është ai mjet që lejon të ndjekësh IaC: kur nxirrje/meti nodet nga operimi, gjithmonë gjendej ndonjë gjë që shkonte keq dhe kërkonte ndonjë ndërhyrje, dhe kur përdorim sisteme të ndryshme operative, playbook-u sillet ndryshe. Me rritjen e numrit të ekipeve dhe nodave në klaster, vëmë re se playbook-u merr më shumë kohë, deri në 3.5 orë, e tuaja sa është? 🙂

Dhe duket se kubespray është thjesht Ansible, dhe gjithçka është e qartë në pamje të parë, por:

Në fillim, qëllimi ishte të nisim kapacitetet vetëm në AWS dhe në virtualizim, por, siç ndodh shpesh, kërkesat ndryshuan.

Në këtë kontekst, u bë e qartë se modeli ynë i vjetër i bashkimit të burimeve në një sistem orkestrimi nuk përputhej — në rastin kur klasterët ishin shumë të largët dhe nën menaxhimin e ofruesve të ndryshëm.

Më tej, situata bëhej më e komplikuar. Kur të gjitha ekipet punojnë brenda një klasteri, shërbime të ndryshme me NodeSelector të vendosur gabimisht mund të ikin në një host tjetër të ekipit dhe të shfrytëzojnë burimet atje, dhe në rastin e vendosjes së taint — shfaqeshin kërkesa të vazhdueshme se një shërbim ose tjetër nuk funksiononte ose nuk shpërndahej siç duhet për shkak të faktorëve njerëzorë. Një tjetër problem është llogaritja e kostos, veçanërisht duke marrë parasysh problemet në shpërndarjen e shërbimeve në nodat.

Një histori e veçantë ishte dhënia e të drejtave për punonjësit: çdo ekip dëshironte të ishte "në krye" të klasterit dhe ta menaxhonte atë plotësisht, e cila mund të shkaktonte një kolaps të plotë, sepse ekipet kryesisht ishin të pavarura nga njëri-tjetri.

Çfarë të bëjmë?

Duke pasur parasysh të gjitha këto dhe dëshirat e ekipeve për të qenë më të pavarur, arritëm në një përfundim të thjeshtë: një ekip — një klaster.

Kështu u krijua klasteri ynë i dytë:

Dhe më vonë edhe klasteri i tretë:

Këtu filluam të mendojmë: le të themi se pas një viti ekipet tona do të kenë më shumë se një klaster? Në zona të ndryshme gjeografike, për shembull, ose nën menaxhimin e ofruesve të ndryshëm? Disa nga ata mund të duan të kenë mundësinë për të ndërprerë shpejt një klaster të përkohshëm për ndonjë test.

I gjithë Kubernetes do të ndodhte! Ky është një lloj MultiKubernetes, në dukje.

Megjithatë, të gjithë ne do të duhet ndonjëherë të mbështesim të gjitha këto klasterë, të kemi mundësinë të menaxhojmë lehtësisht qasjen ndaj tyre, dhe gjithashtu të krijojmë të reja dhe të çaktivizojmë të vjetra pa ndërhyrje manuale.

Ka kaluar një kohë që nga fillimi i rrugëtimit tonë në botën e Kubernetes dhe vendosëm të bëjmë një rishikim të zgjidhjeve që janë në dispozicion. Doli se në treg ka tashmë një zgjidhje — Rancher 2.2.

Në fazën e parë të hetimeve tona, Rancher Labs kishin bërë publikimin e parë të versions 2, por pavarësisht se mund të ngrihej shumë shpejt, duke filluar një kontejner pa varësi të jashtme me disa parametra ose duke përdorur HELM Chart zyrtare, na dukej e paqëndrueshme, dhe nuk dinim nëse mund të mbështeteshim në këtë zgjidhje, nëse do të zhvillohej apo do të braktisej shpejt. Paradigma e vetme klaster = klikime në UI gjithashtu nuk na përshtatej, dhe nuk donim të lidheshim me RKE, sepse është një mjet mjaft i orientuar ngushtë.

Versioni Rancher 2.2 kishte një pamje më operacionale dhe, së bashku me të kaluarën, ofronte një sërë mundësish interesante të gatshme si integrimi me shumë ofrues të jashtëm, një pikë unike shpërndarjeje për autorizime dhe skedarë kubeconfig, nisjen e imazhit kubectl me të drejtat tuaja në UI, dhe hapësira të brendshme aka projekte.

Gjithashtu, rreth Rancher 2 ishte formuar një komunitet, dhe u krijua një ofrues HashiCorp Terraform për menaxhimin e tij, i cili na ndihmoi të bashkojmë gjithçka.

Çfarë rezultati u arrit

Si rezultat, kemi një klaster të vogël, ku është ngritur Rancher, i disponueshëm për të gjithë klasterët e tjerë, si dhe shumë klasterë të lidhur me të, qasje në çdo njëri prej të cilëve mund të jepet po aq lehtë sa shtimi i një përdoruesi në katalogun ldap, pa marrë parasysh ku ndodhet dhe burimet e cilit ofrues përdor.

Me ndihmën e gitlab-ci dhe Terraform u krijua një sistem që lejon krijimin e një klasteri të çdo konfiguracioni në ofruesit e cloud ose në infrastrukturën tonë, dhe t'i lidhim ato me Rancher. Gjithçka u realizua në stilin IaC, ku çdo klaster është përshkruar nga një depo dhe gjendja e tij është versionuar. Në këtë mënyrë, shumica e moduleve lidhen nga depo të jashtme, duke lënë vetëm të kaloni variablat ose të përshkruani konfigurimin tuaj të personalizuar për instancat, e cila ndihmon në uljen e përqindjes së përsëritjes së kodit.

Sigurisht, udhëtimi ynë nuk ka përfunduar dhe përpara ka ende shumë sfida interesante si një pikë e vetme për punimin me logët dhe metrikat e klasterëve të ndryshëm, mesh shërbimi, gitops për menaxhimin e ngarkesave në multiklaster dhe shumë të tjera. Shpresojmë se do t'ju interesojë përvoja jonë!