Hei Habr!
Rydym yn cynrychioli tîm platfform Exness. Yn flaenorol, mae ein cydweithwyr eisoes wedi ysgrifennu erthygl am . Heddiw rydym am rannu ein profiad o fudo gwasanaethau i Kubernetes.
I ddechrau, rydym yn cynnig rhai rhifau i chi i gael gwell dealltwriaeth o'r hyn a drafodir:
- Mae ein hadran ddatblygu yn cynnwys 100+ o bobl, gan gynnwys mwy na 10 tîm gwahanol gyda phrosesau QA, DevOps a Scrum hunangynhaliol. Pentwr datblygu - Python, PHP, C++, Java a Golang.
- Mae maint yr amgylcheddau prawf a chynhyrchu tua 2000 o gynwysyddion yr un. Maent yn rhedeg Rancher v1.6 ar eu rhithwiroli eu hunain ac o dan VMware.
Cymhelliant
Fel y dywedant, nid oes dim yn para am byth, a chyhoeddodd Rancher ddiwedd y gefnogaeth i fersiwn 1.6 gryn amser yn ôl. Ydym, mewn mwy na thair blynedd rydym wedi dysgu sut i'w baratoi a datrys problemau sy'n codi, ond yn amlach rydym yn wynebu problemau na fyddant byth yn cael eu cywiro. Mae gan Rancher 1.6 hefyd system ossified ar gyfer cyhoeddi hawliau, lle gallwch naill ai wneud bron popeth neu ddim byd.
Er bod rhithwiroli perchnogol yn darparu mwy o reolaeth dros storio data a'i ddiogelwch, gosododd gostau gweithredu a oedd yn anodd eu derbyn o ystyried twf cyson y cwmni, nifer y prosiectau a'r gofynion ar eu cyfer.
Roeddem am ddilyn safonau IaC ac, os oedd angen, cael capasiti yn gyflym, mewn unrhyw leoliad daearyddol a heb glo gwerthwr, a hefyd yn gallu rhoi'r gorau iddo yn gyflym.
Camau Cyntaf
Yn gyntaf oll, roeddem am ddibynnu ar dechnolegau ac atebion modern a fyddai'n caniatáu i dimau gael cylch datblygu cyflymach a lleihau costau gweithredol ar gyfer rhyngweithio â'r platfform sy'n darparu pŵer.
Wrth gwrs, y peth cyntaf a ddaeth i'n meddwl oedd Kubernetes, ond ni wnaethom gyffroi a gwneud ychydig o ymchwil i weld ai hwn oedd y dewis cywir. Dim ond atebion ffynhonnell agored y gwnaethom eu gwerthuso, ac mewn brwydr annheg, enillodd Kubernetes yn ddiamod.
Nesaf daeth y cwestiwn o ddewis offeryn ar gyfer creu clystyrau. Gwnaethom gymharu'r atebion mwyaf poblogaidd: kops, kubespray, kubeadm.
I ddechrau, roedd kubeadm yn ymddangos i ni yn llwybr rhy gymhleth, yn debyg i fath o ddyfeisiwr “beic,” ac nid oedd gan kops ddigon o hyblygrwydd.
A'r enillydd oedd:
Dechreuon ni arbrofi gyda'n rhithwiroli a'n AWS ein hunain, gan geisio ail-greu rhywbeth tebyg yn fras i'n patrwm rheoli adnoddau blaenorol, lle roedd pawb yn rhannu'r un “clwstwr.” Ac yn awr mae gennym ein clwstwr cyntaf o 10 peiriant rhithwir bach, y mae cwpl ohonynt wedi'u lleoli yn AWS. Dechreuon ni geisio mudo timau yno, roedd popeth yn ymddangos yn “dda”, ac roedd modd gorffen y stori, ond...
Problemau Cyntaf
Ansible yw'r hyn y mae kubespray wedi'i adeiladu arno, nid yw'n offeryn sy'n eich galluogi i ddilyn IaC: wrth gomisiynu/datgomisiynu nodau, aeth rhywbeth o'i le yn gyson ac roedd angen rhyw fath o ymyriad, ac wrth ddefnyddio gwahanol OSes, roedd y llyfr chwarae yn ymddwyn yn wahanol ac yn wahanol . Wrth i nifer y timau a nodau yn y clwstwr dyfu, dechreuom sylwi bod y llyfr chwarae yn cymryd mwy o amser a hirach i'w gwblhau, ac o ganlyniad, ein record oedd 3,5 awr, beth am eich un chi? 🙂
Ac mae'n ymddangos bod kubespray yn Ansible yn unig, ac mae popeth yn glir ar yr olwg gyntaf, ond:
Ar ddechrau'r daith, y dasg oedd lansio galluoedd yn AWS yn unig ac ar rithwiroli, ond yna, fel sy'n digwydd yn aml, newidiodd y gofynion.
Yn wyneb hyn, daeth yn amlwg nad oedd ein hen batrwm o gyfuno adnoddau mewn un system gerddorfaol yn addas – yn yr achos lle mae’r clystyrau’n anghysbell iawn ac yn cael eu rheoli gan wahanol ddarparwyr.
Mwy pellach. Pan fydd pob tîm yn gweithio o fewn yr un clwstwr, gallai gwasanaethau amrywiol gyda NodeSelectors wedi'u gosod yn anghywir hedfan i westeiwr “tramor” tîm arall a defnyddio adnoddau yno, ac os gosodwyd llygredigaeth, roedd ceisiadau cyson nad oedd un gwasanaeth neu'r llall yn gweithio, heb ei ddosbarthu'n gywir oherwydd ffactor dynol. Problem arall oedd cyfrifo'r gost, yn enwedig o ystyried y problemau wrth ddosbarthu gwasanaethau ar draws nodau.
Stori ar wahân oedd cyhoeddi hawliau i weithwyr: roedd pob tîm eisiau bod "ar ben" y clwstwr a'i reoli'n llwyr, a allai achosi cwymp llwyr, gan fod y timau yn y bôn yn annibynnol ar ei gilydd.
Beth i'w wneud?
Gan ystyried yr uchod a dymuniadau'r timau i fod yn fwy annibynnol, daethom i gasgliad syml: un tîm - un clwstwr.
Felly cawsom ail un:
Ac yna'r trydydd clwstwr:
Yna fe ddechreuon ni feddwl: gadewch i ni ddweud y bydd gan ein timau fwy nag un clwstwr mewn blwyddyn? Mewn ardaloedd daearyddol gwahanol, er enghraifft, neu o dan reolaeth darparwyr gwahanol? A bydd rhai ohonyn nhw eisiau gallu defnyddio clwstwr dros dro yn gyflym ar gyfer rhai profion.
Byddai Kubernetes llawn yn dod! Mae hwn yn rhyw fath o MultiKubernetes, mae'n troi allan.
Ar yr un pryd, bydd angen i ni i gyd rywsut gynnal yr holl glystyrau hyn, gallu rheoli mynediad atynt yn hawdd, yn ogystal â chreu rhai newydd a dadgomisiynu hen rai heb ymyrraeth â llaw.
Mae peth amser wedi mynd heibio ers dechrau ein taith ym myd Kubernetes, a phenderfynom ail-edrych ar yr atebion sydd ar gael. Mae'n troi allan ei fod eisoes yn bodoli ar y farchnad - Rancher 2.2.
Ar gam cyntaf ein hymchwil, roedd Rancher Labs eisoes wedi gwneud y datganiad cyntaf o fersiwn 2, ond er y gellid ei godi'n gyflym iawn trwy lansio cynhwysydd heb ddibyniaethau allanol gyda chwpl o baramedrau neu ddefnyddio'r Siart HELM swyddogol, roedd yn ymddangos yn amrwd i ni, ac nid oeddem yn gwybod a allem ddibynnu ar y penderfyniad hwn a fydd yn cael ei ddatblygu neu ei adael yn gyflym. Nid oedd y patrwm clwstwr = cliciau yn yr UI ei hun ychwaith yn addas i ni, ac nid oeddem am ddod yn gysylltiedig ag RKE, gan ei fod yn offeryn â ffocws eithaf cul.
Roedd gan Fersiwn Rancher 2.2 ymddangosiad mwy ymarferol eisoes ac, ynghyd â'r rhai blaenorol, roedd ganddo griw o nodweddion diddorol allan o'r bocs, megis integreiddio â llawer o ddarparwyr allanol, un pwynt dosbarthu hawliau a ffeiliau kubeconfig, lansio kubectl delwedd gyda'ch hawliau yn y UI, gofodau enwau nythu aka prosiectau.
Roedd yna hefyd gymuned eisoes wedi'i ffurfio o amgylch Rancher 2, a chrëwyd darparwr o'r enw HashiCorp Terraform i'w reoli, a helpodd ni i roi popeth at ei gilydd.
Beth ddigwyddodd
O ganlyniad, daeth un clwstwr bach i ben yn rhedeg Rancher, sy'n hygyrch i bob clwstwr arall, yn ogystal â llawer o glystyrau sy'n gysylltiedig ag ef, a gellir caniatáu mynediad i unrhyw un ohonynt mor syml ag ychwanegu defnyddiwr i'r cyfeiriadur ldap, waeth beth fo'i ble mae wedi'i leoli ac adnoddau pa ddarparwr y mae'n eu defnyddio.
Gan ddefnyddio gitlab-ci a Terraform, crëwyd system sy'n eich galluogi i greu clwstwr o unrhyw ffurfweddiad mewn darparwyr cwmwl neu ein seilwaith ein hunain a'u cysylltu â Rancher. Gwneir hyn i gyd yn arddull IaC, lle mae pob clwstwr yn cael ei ddisgrifio gan ystorfa, a'i gyflwr yn cael ei fersiwn. Ar yr un pryd, mae'r rhan fwyaf o fodiwlau wedi'u cysylltu o ystorfeydd allanol fel mai'r cyfan sy'n weddill yw pasio newidynnau neu ddisgrifio'ch ffurfweddiad arferol er enghraifft, sy'n helpu i leihau canran yr ailadrodd cod.
Wrth gwrs, mae ein taith ymhell o fod ar ben ac mae llawer o dasgau diddorol o'n blaenau o hyd, megis un pwynt gwaith gyda boncyffion a metrigau o unrhyw glystyrau, rhwyll gwasanaeth, gitops ar gyfer rheoli llwythi mewn aml-glwstwr a llawer mwy. Gobeithio y bydd ein profiad yn ddiddorol i chi!
Ysgrifennwyd yr erthygl gan A. Antipov, A. Ganush, Platform Engineers.
Ffynhonnell: hab.com