Hey Habr!
Em tîmê platforma Exness temsîl dikin. Berê, hevkarên me berê gotarek li ser nivîsandin . Îro em dixwazin ezmûna xwe ya karûbarên koçberiyê ji Kubernetes re parve bikin.
Ji bo destpêkê, em ji we re hin hejmaran pêşkêş dikin ku ji bo çêtir têgihîştina tiştên ku dê bêne nîqaş kirin:
- Beşa me ya pêşkeftinê ji 100+ kesan pêk tê, di nav de zêdetirî 10 tîmên cihêreng ên xwedan pêvajoyên QA, DevOps û Scrum hene. Stack Pêşveçûnê - Python, PHP, C++, Java û Golang.
- Mezinahiya hawîrdorên ceribandin û hilberînê her yek bi qasî 2000 konteyneran e. Ew Rancher v1.6 li ser virtualîzasyona xwe û di bin VMware de dimeşînin.
Motivation
Wekî ku ew dibêjin, tiştek herheyî dom nake, û Rancher ji demek dirêj ve dawiya piştevaniya guhertoya 1.6 ragihand. Erê, di sê salan de em fêr bûn ku çawa wê amade bikin û pirsgirêkên ku derdikevin çareser bikin, lê her ku diçe em bi pirsgirêkên ku qet nayên rast kirin re rû bi rû dimînin. Rancher 1.6 di heman demê de ji bo belavkirina mafan jî pergalek ossified heye, ku hûn dikarin hema her tiştî bikin an jî tiştek nekin.
Her çend virtualbûna xwedan kontrolek mezintir li ser hilanîna daneyan û ewlehiya wê peyda kir, lê lêçûnên xebitandinê yên ku ji ber mezinbûna domdar a pargîdanî, hejmara proje û hewcedariyên wan dijwar bûn qebûl kirin.
Me xwest ku standardên IaC-ê bişopînin û, ger hewce be, kapasîteyê zû, li her cîhek erdnîgarî û bêyî kilîtek firoşkar bi dest bixin, û di heman demê de em karibin zû dev jê berdin.
gavên pêşîn
Berî her tiştî, me dixwest ku xwe bispêrin teknolojiyên nûjen û çareseriyên ku dê rê bidin tîmê ku xwedan çerxek pêşkeftinek bileztir bin û lêçûnên xebitandinê ji bo danûstendina bi platforma ku hêzê peyda dike kêm bikin.
Bê guman, yekem tiştê ku hat hişê me Kubernetes bû, lê me heyecan nekir û lêkolînek piçûk kir ku em bibînin ka ew bijareya rast e. Me tenê çareseriyên çavkaniya vekirî nirxand, û di şerekî neheq de, Kubernetes bê şert û merc bi ser ket.
Piştre pirsa hilbijartina amûrek ji bo afirandina koman hat. Me çareseriyên herî populer berhev kir: kops, kubespray, kubeadm.
Ji bo destpêkê, kubeadm ji me re rêyek pir tevlihev xuya bû, bêtir wekî celebek dahênerek "bisîkletek" bû, û kopên têra xwe nermbûn tune.
Û serketî bû:
Me dest bi ceribandina virtualîzasyona xwe û AWS-ê kir, hewl da ku tiştek mîna şêwaza rêveberiya çavkaniyên xwe ya berê ji nû ve biafirînin, ku tê de her kes heman "klûbek" bikar tîne. Û naha me koma xwe ya yekem heye, 10 yên piçûk. makîneyên virtual, çend ji wan li AWS-ê ne. Me dest bi hewildana veguhestina tîman bo wir kir, û xuya bû ku her tişt baş diçe, û çîrok dikaribû biqede, lê…
Pirsgirêkên Yekem
Ansible ew e ku kubespray li ser hatî çêkirin, ew ne amûrek e ku destûrê dide te ku hûn IaC-ê bişopînin: dema ku girêkan bi kar tînin/xebitandin, tiştek bi domdarî xelet diçû û cûreyek destwerdanê hewce bû, û dema ku OS-yên cihêreng bikar tînin, pirtûka lîstikê bi rengek cûda tevdigere . Her ku hejmara tîm û girêkên di komê de mezin bû, me dest pê kir ku em pê hesiyan ku pirtûka lîstikê dirêjtir û dirêjtir temam dibe, û di encamê de, rekora me 3,5 demjimêr bû, gelo ya we çi ye? 🙂
Û wusa dixuye ku kubespray tenê Ansible ye, û her tişt di nihêrîna pêşîn de zelal e, lê:
Di destpêka rêwîtiyê de, peywir ev bû ku kapasîteyên tenê di AWS û li ser virtualbûnê de bidin destpêkirin, lê dûv re, wekî ku pir caran diqewime, hewcedarî hatin guhertin.
Di ronahiya vê de, eşkere bû ku şêwaza meya kevn a berhevkirina çavkaniyan di yek pergala orkestrasyonê de ne guncaw bû - di rewşa ku kom pir dûr in û ji hêla pêşkêşkerên cihêreng ve têne rêve kirin.
Bêtir bêtir. Dema ku hemî tîm di nav heman komê de dixebitin, karûbarên cihêreng ên bi NodeSelectors-ên ku bi xeletî hatine saz kirin dikarin bifirin mêvandarê "biyanî" tîmek din û çavkaniyan li wir bikar bînin, û heke xelet hate danîn, daxwazên domdar hebûn ku yek an karûbarek din nexebite. ji ber faktora mirovî rast nayê belavkirin. Pirsgirêkek din jî hesabkirina lêçûn bû, nemaze ku pirsgirêkên di belavkirina karûbaran de li ser nokan têne hesibandin.
Çîrokek cihêreng belavkirina mafên karmendan bû: her tîm dixwest ku "li serê" komê be û bi tevahî wê birêve bibe, ku dikare bibe sedema hilweşînek tam, ji ber ku tîm bi bingehîn ji hev serbixwe ne.
Çawa be?
Li ber çavê jor û xwestekên tîmên ku bêtir serbixwe bin, me encamek hêsan çêkir: yek tîm - yek kom.
Ji ber vê yekê me ya duyemîn peyda kir:
Û paşê koma sêyemîn:
Dûv re me dest bi fikirînê kir: em bibêjin ku di salekê de tîmên me dê ji yek komê zêdetir bibin? Mînakî, li deverên cûda yên erdnîgarî, an di bin kontrola pêşkêşkerên cihêreng de? Û hin ji wan dê bixwazin ku ji bo hin ceribandinan zû zû komek demkî bicîh bikin.
Kubernetes tijî dê werin! Ev celebek MultiKubernetes e, derket holê.
Di heman demê de, em ê hemî hewce ne ku bi rengekî van koman biparêzin, karibin bi hêsanî gihîştina wan bi rê ve bibin, û her weha yên nû biafirînin û yên kevin bêyî destwerdana destan hilweşînin.
Demek ji destpêka rêwîtiya me ya li cîhana Kubernetes re derbas bû, û me biryar da ku em çareseriyên berdest ji nû ve lêkolîn bikin. Derket holê ku ew jixwe li sûkê heye - Rancher 2.2.
Di qonaxa yekem a lêkolîna me de, Rancher Labs jixwe serbestberdana yekem a guhertoya 2-ê çêkiribû, lê her çend ew bi destpêkirina konteynirek bê girêdanên derveyî bi çend parameteran an jî bi karanîna nexşeya fermî ya HELM-ê ve pir zû were hildan, ew xav xuya bû. ji me re, û me nizanibû ku em dikarin xwe bispêrin vê biryarê gelo ew ê were pêşve xistin an zû were berdan. Paradîgmaya komê = klîk di UI bixwe de jî ne li gorî me ye, û me nexwest ku em bi RKE ve girêdayî bin, ji ber ku ew amûrek hûrgulî ye.
Guhertoya Rancher 2.2 jixwe xwedan xuyangek bikêrtir bû û, digel yên berê, xwedan komek taybetmendiyên balkêş ên derveyî bû, wek entegrasyona bi gelek pêşkêşkerên derveyî re, yek xala belavkirina mafan û pelên kubeconfig, destpêkirina kubectl. wêneyê bi mafên xwe yên di UI-yê de, projeyên navên navên hêlînkirî.
Di heman demê de civakek ku berê li dora Rancher 2-ê hatî damezrandin jî hebû, û pêşkêşvanek bi navê HashiCorp Terraform hate afirandin ku wê birêve bibe, ku alîkariya me kir ku her tiştî li hev bikin.
Çi qewimî
Wekî encamek, me bi komek piçûk a ku Rancher-ê dimeşîne, ku ji hemî komên din re tê gihîştin, û her weha gelek komikên pê ve girêdayî ye, bi dawî bû. ew li ku derê ye û çavkaniyên pêşkêşkerê ku ew bikar tîne.
Bi karanîna gitlab-ci û Terraform, pergalek hate afirandin ku dihêle hûn di pêşkêşkerên ewr an binesaziya xwe de komek ji her veavakirinê biafirînin û wan bi Rancher ve girêdin. Hemî ev di şêwaza IaC de têne kirin, ku her kom ji hêla depoyek ve tête diyar kirin, û rewşa wê tête guherto kirin. Di heman demê de, pir modul ji depoyên derveyî ve têne girêdan da ku ya ku dimîne ev e ku meriv guhêrbaran derbas bike an ji bo nimûneyan veavakirina xweya xwerû diyar bike, ku ev jî dibe alîkar ku rêjeya dubarekirina kodê kêm bike.
Bê guman, rêwîtiya me ji qedandinê dûr e û hîn jî gelek karên balkêş li pêş in, wek xalek xebatê ya bi têketin û metrîkên her komê, tevna karûbarê, gitops ji bo birêvebirina barkêşan di pirklusterê de û hêj bêtir. Em hêvî dikin ku hûn ezmûna me balkêş bibînin!
Gotar ji hêla A. Antipov, A. Ganush, Endezyarên Platformê ve hatî nivîsandin.
Source: www.habr.com
