Hej Habr!
Ne përfaqësojmë ekipin e platformës Exness. Më parë, kolegët tanë kanë shkruar tashmë një artikull për . Sot ne duam të ndajmë përvojën tonë të shërbimeve të migrimit në Kubernetes.
Për të filluar, ne ju ofrojmë disa numra për të kuptuar më mirë atë që do të diskutohet:
- Departamenti ynë i zhvillimit përbëhet nga 100+ njerëz, duke përfshirë më shumë se 10 ekipe të ndryshme me procese të vetë-mjaftueshme QA, DevOps dhe Scrum. Stack i zhvillimit - Python, PHP, C++, Java dhe Golang.
- Madhësia e mjediseve të testimit dhe prodhimit është rreth 2000 kontejnerë secili. Ata po ekzekutojnë Rancher v1.6 në virtualizimin e tyre dhe nën VMware.
motivimi
Siç thonë ata, asgjë nuk zgjat përgjithmonë, dhe Rancher njoftoi fundin e mbështetjes për versionin 1.6 shumë kohë më parë. Po, në më shumë se tre vjet kemi mësuar se si ta përgatisim dhe të zgjidhim problemet që dalin, por gjithnjë e më shpesh përballemi me probleme që nuk korrigjohen kurrë. Rancher 1.6 ka gjithashtu një sistem të osifikuar për lëshimin e të drejtave, ku mund të bëni pothuajse gjithçka ose asgjë.
Megjithëse virtualizimi i pronarit siguronte kontroll më të madh mbi ruajtjen e të dhënave dhe sigurinë e tij, ai imponoi kosto operative që ishin të vështira për t'u pranuar duke pasur parasysh rritjen e vazhdueshme të kompanisë, numrin e projekteve dhe kërkesat për to.
Ne donim të ndiqnim standardet IaC dhe, nëse është e nevojshme, të merrnim kapacitet shpejt, në çdo vendndodhje gjeografike dhe pa një bllokim shitësi, dhe gjithashtu të mund ta braktisnim atë shpejt.
Hapat e parë
Para së gjithash, ne donim të mbështeteshim në teknologjitë dhe zgjidhjet moderne që do t'i lejonin ekipet të kishin një cikël më të shpejtë zhvillimi dhe të minimizonin kostot operacionale për ndërveprim me platformën që ofron energji.
Sigurisht, gjëja e parë që na erdhi në mendje ishte Kubernetes, por ne nuk u emocionuam dhe bëmë një kërkim të vogël për të parë nëse ishte zgjedhja e duhur. Ne vlerësuam vetëm zgjidhjet me burim të hapur dhe në një betejë të padrejtë, Kubernetes fitoi pa kushte.
Më pas erdhi çështja e zgjedhjes së një mjeti për krijimin e grupimeve. Ne krahasuam zgjidhjet më të njohura: kops, kubespray, kubeadm.
Si fillim, kubeadm na dukej si një shteg shumë i ndërlikuar, më tepër si një lloj shpikësi i një "biçiklete" dhe kops nuk kishin fleksibilitet të mjaftueshëm.
Dhe fituesi ishte:
Ne filluam të eksperimentonim me virtualizimin tonë dhe AWS, duke u përpjekur të rikrijonim diçka afërsisht të ngjashme me modelin tonë të mëparshëm të menaxhimit të burimeve, ku të gjithë ndanin të njëjtin "grup". Dhe tani kemi grupin tonë të parë me 10 makina të vogla virtuale, disa prej të cilave ndodhen në AWS. Filluam të përpiqeshim të migronim ekipet atje, gjithçka dukej se ishte "mirë" dhe historia mund të përfundonte, por ...
Problemet e para
Ansible është ajo mbi të cilën është ndërtuar kubespray, nuk është një mjet që të lejon të ndjekësh IaC: kur vë në punë/çaktivizosh nyjet, diçka nuk shkonte vazhdimisht dhe kërkohej një lloj ndërhyrjeje, dhe kur përdoreshin OS të ndryshme, libri i lojërave sillej ndryshe. ndryshe . Ndërsa numri i ekipeve dhe nyjeve në grup u rrit, filluam të vëmë re se librit të lojërave po merrte më shumë dhe më shumë kohë për t'u plotësuar, dhe si rezultat, rekordi ynë ishte 3,5 orë, po i yti? 🙂
Dhe duket sikur kubespray është thjesht Ansible, dhe gjithçka është e qartë në shikim të parë, por:
Në fillim të udhëtimit, detyra ishte të lëshoheshin kapacitete vetëm në AWS dhe në virtualizim, por më pas, siç ndodh shpesh, kërkesat ndryshuan.
Në dritën e kësaj, u bë e qartë se modeli ynë i vjetër i kombinimit të burimeve në një sistem orkestrimi nuk ishte i përshtatshëm - në rastin kur grupet janë shumë të largëta dhe menaxhohen nga ofrues të ndryshëm.
Më tej më shumë. Kur të gjitha ekipet punojnë brenda të njëjtit grup, shërbime të ndryshme me NodeSelectors të instaluar gabimisht mund të fluturojnë drejt hostit "të huaj" të një ekipi tjetër dhe të përdorin burimet atje, dhe nëse vendosej njolla, kishte kërkesa të vazhdueshme që një ose një shërbim tjetër nuk po funksiononte. nuk shpërndahet si duhet për shkak të faktorit njerëzor. Një problem tjetër ishte llogaritja e kostos, veçanërisht duke pasur parasysh problemet në shpërndarjen e shërbimeve nëpër nyje.
Një histori më vete ishte dhënia e të drejtave për punonjësit: secili ekip dëshironte të ishte "në krye" të grupit dhe ta menaxhonte plotësisht atë, gjë që mund të shkaktonte një kolaps të plotë, pasi ekipet në thelb janë të pavarura nga njëri-tjetri.
Çfarë duhet të bëni?
Duke marrë parasysh sa më sipër dhe dëshirat e ekipeve për të qenë më të pavarur, ne bëmë një përfundim të thjeshtë: një ekip - një grup.
Pra, ne kemi një të dytë:
Dhe pastaj grupi i tretë:
Më pas filluam të mendonim: le të themi që në një vit ekipet tona do të kenë më shumë se një grup? Në zona të ndryshme gjeografike, për shembull, apo nën kontrollin e ofruesve të ndryshëm? Dhe disa prej tyre do të duan të jenë në gjendje të vendosin shpejt një grup të përkohshëm për disa teste.
Kubernetet e plota do të vinin! Ky është një lloj MultiKubernetes, rezulton.
Në të njëjtën kohë, ne të gjithë do të duhet të ruajmë disi të gjitha këto grupime, të jemi në gjendje të menaxhojmë lehtësisht aksesin në to, si dhe të krijojmë të reja dhe të çaktivizojmë të vjetrat pa ndërhyrje manuale.
Ka kaluar ca kohë që nga fillimi i udhëtimit tonë në botën e Kubernetes dhe vendosëm të rishqyrtojmë zgjidhjet e disponueshme. Doli se tashmë ekziston në treg - Rancher 2.2.
Në fazën e parë të kërkimit tonë, Rancher Labs kishte bërë tashmë lëshimin e parë të versionit 2, por megjithëse mund të ngrihej shumë shpejt duke hedhur në treg një kontejner pa varësi të jashtme me disa parametra ose duke përdorur grafikun zyrtar të HELM-it, ai dukej i papërpunuar. tek ne dhe nuk e dinim nëse mund të mbështeteshim në këtë vendim nëse do të zhvillohet apo do të braktiset shpejt. Paradigma e grupit = klikimeve në vetë UI gjithashtu nuk na përshtatet, dhe ne nuk donim të lidheshim me RKE, pasi është një mjet mjaft i fokusuar.
Versioni Rancher 2.2 kishte tashmë një pamje më të zbatueshme dhe, së bashku me ato të mëparshmet, kishte një sërë veçorish interesante jashtë kutisë, si integrimi me shumë ofrues të jashtëm, një pikë e vetme e shpërndarjes së të drejtave dhe skedarët kubeconfig, lëshimi i një kubectl imazh me të drejtat tuaja në UI, hapësira emrash të ndërlidhura të quajtura projekte.
Kishte gjithashtu një komunitet të formuar tashmë rreth Rancher 2, dhe një ofrues i quajtur HashiCorp Terraform u krijua për ta menaxhuar atë, i cili na ndihmoi të bashkonim gjithçka.
Cfare ndodhi
Si rezultat, ne përfunduam me një grup të vogël që ekzekuton Rancher, i aksesueshëm për të gjitha grupimet e tjera, si dhe shumë grupime të lidhura me të, qasja në cilindo prej të cilave mund të jepet po aq thjesht sa shtimi i një përdoruesi në drejtorinë ldap, pavarësisht nga ku ndodhet dhe burimet e cilit ofrues përdor.
Duke përdorur gitlab-ci dhe Terraform, u krijua një sistem që ju lejon të krijoni një grup të çdo konfigurimi në ofruesit e cloud ose infrastrukturën tonë dhe t'i lidhni ato me Rancher. E gjithë kjo bëhet në stilin IaC, ku çdo grup përshkruhet nga një depo dhe gjendja e tij është e versionuar. Në të njëjtën kohë, shumica e moduleve janë të lidhura nga depo të jashtme, kështu që gjithçka që mbetet është të kalojnë variablat ose të përshkruajnë konfigurimin tuaj personal për shembuj, gjë që ndihmon në uljen e përqindjes së përsëritjes së kodit.
Sigurisht, udhëtimi ynë është larg përfundimit dhe ka ende shumë detyra interesante përpara, të tilla si një pikë e vetme pune me regjistrat dhe metrikat e çdo grupi, rrjetë shërbimi, gitops për menaxhimin e ngarkesave në një multicluster dhe shumë më tepër. Shpresojmë që përvoja jonë t'ju duket interesante!
Artikulli është shkruar nga A. Antipov, A. Ganush, Inxhinierët e Platformës.
Burimi: www.habr.com