Nodyn. traws.: Mae mabwysiadu Kubernetes yn GitLab yn cael ei ystyried yn un o'r ddau brif ffactor sy'n cyfrannu at dwf y cwmni. Fodd bynnag, tan yn ddiweddar, adeiladwyd seilwaith gwasanaeth ar-lein GitLab.com ar beiriannau rhithwir, a dim ond tua blwyddyn yn ôl y dechreuodd ei ymfudiad i K8s, nad yw wedi'i gwblhau o hyd. Mae'n bleser gennym gyflwyno cyfieithiad o erthygl ddiweddar gan beiriannydd SRE GitLab am sut mae hyn yn digwydd a pha gasgliadau y mae'r peirianwyr sy'n cymryd rhan yn y prosiect yn eu gwneud.
Ers tua blwyddyn bellach, mae ein his-adran seilwaith wedi bod yn mudo'r holl wasanaethau sy'n rhedeg ar GitLab.com i Kubernetes. Yn ystod y cyfnod hwn, cawsom heriau yn ymwneud nid yn unig â symud gwasanaethau i Kubernetes, ond hefyd â rheoli'r defnydd hybrid yn ystod y cyfnod pontio. Bydd y gwersi gwerthfawr a ddysgwyd gennym yn cael eu trafod yn yr erthygl hon.
O ddechrau cyntaf GitLab.com, roedd ei weinyddion yn rhedeg yn y cwmwl ar beiriannau rhithwir. Mae'r peiriannau rhithwir hyn yn cael eu rheoli gan Chef a'u gosod gan ddefnyddio ein . rhag ofn bod angen diweddaru'r rhaglen, mae'n cynnwys diweddaru fflyd y gweinydd mewn modd cydlynol, dilyniannol gan ddefnyddio piblinell CI. Mae'r dull hwn - er ei fod yn araf ac ychydig - yn sicrhau bod GitLab.com yn defnyddio'r un arferion gosod a ffurfweddu â defnyddwyr all-lein (hunanreoli) Gosodiadau GitLab gan ddefnyddio ein pecynnau Linux ar gyfer hyn.
Rydym yn defnyddio'r dull hwn oherwydd ei bod yn hynod bwysig profi'r holl ofidiau a llawenydd y mae aelodau cyffredin o'r gymuned yn eu profi wrth osod a ffurfweddu eu copïau o GitLab. Gweithiodd y dull hwn yn dda am beth amser, ond pan aeth nifer y prosiectau ar GitLab dros 10 miliwn, sylweddolom nad oedd bellach yn bodloni ein hanghenion ar gyfer graddio a defnyddio.
Camau cyntaf i Kubernetes a GitLab brodorol cwmwl
Crëwyd y prosiect yn 2017 i baratoi GitLab ar gyfer defnyddio cwmwl, ac i alluogi defnyddwyr i osod GitLab ar glystyrau Kubernetes. Roeddem yn gwybod bryd hynny y byddai symud GitLab i Kubernetes yn cynyddu graddadwyedd platfform SaaS, yn symleiddio gosodiadau, ac yn gwella effeithlonrwydd adnoddau cyfrifiadurol. Ar yr un pryd, roedd llawer o swyddogaethau ein cais yn dibynnu ar raniadau NFS wedi'u gosod, a oedd yn arafu'r trawsnewidiad o beiriannau rhithwir.
Caniataodd y gwthio tuag at y cwmwl brodorol a Kubernetes i'n peirianwyr gynllunio trawsnewidiad graddol, pan wnaethom roi'r gorau i rai o ddibyniaethau'r cais ar storio rhwydwaith wrth barhau i ddatblygu nodweddion newydd. Ers i ni ddechrau cynllunio'r mudo yn haf 2019, mae llawer o'r cyfyngiadau hyn wedi'u datrys, ac mae'r broses o fudo GitLab.com i Kubernetes bellach wedi hen ddechrau!
Nodweddion GitLab.com yn Kubernetes
Ar gyfer GitLab.com, rydym yn defnyddio un clwstwr GKE rhanbarthol sy'n delio â'r holl draffig cymwysiadau. Er mwyn lleihau cymhlethdod y mudo (sydd eisoes yn anodd), rydym yn canolbwyntio ar wasanaethau nad ydynt yn dibynnu ar storfa leol neu NFS. Mae GitLab.com yn defnyddio cronfa god Rails monolithig yn bennaf, ac rydym yn cyfeirio traffig yn seiliedig ar nodweddion llwyth gwaith i wahanol bwyntiau terfyn sydd wedi'u hynysu i'w pyllau nodau eu hunain.
Yn achos y frontend, rhennir y mathau hyn yn geisiadau i'r we, API, Git SSH/HTTPS a'r Gofrestrfa. Yn achos y backend, rydym yn rhannu'r swyddi yn y ciw yn ôl nodweddion amrywiol yn dibynnu ar , sy'n ein galluogi i osod Amcanion Lefel Gwasanaeth (SLO) ar gyfer llwythi gwaith amrywiol.
Mae'r holl wasanaethau GitLab.com hyn wedi'u ffurfweddu gan ddefnyddio siart Helm GitLab heb ei addasu. Gwneir y cyfluniad mewn is-siartiau, y gellir eu galluogi'n ddetholus wrth i ni symud gwasanaethau'n raddol i'r clwstwr. Er i ni benderfynu peidio â chynnwys rhai o’n gwasanaethau gwladol yn y mudo, megis Redis, Postgres, GitLab Pages a Gitaly, mae defnyddio Kubernetes yn ein galluogi i leihau’n sylweddol nifer y VMs y mae’r Cogydd yn eu rheoli ar hyn o bryd.
Gwelededd a Rheolaeth Ffurfwedd Kubernetes
Mae pob lleoliad yn cael ei reoli gan GitLab ei hun. Ar gyfer hyn, defnyddir tri phrosiect cyfluniad yn seiliedig ar Terraform a Helm. Rydym yn ceisio defnyddio GitLab ei hun pryd bynnag y bo modd i redeg GitLab, ond ar gyfer tasgau gweithredol mae gennym osodiad GitLab ar wahân. Mae angen hyn i sicrhau nad ydych yn dibynnu ar argaeledd GitLab.com wrth berfformio gosodiadau a diweddariadau GitLab.com.
Er bod ein piblinellau ar gyfer clwstwr Kubernetes yn rhedeg ar osodiad GitLab ar wahân, mae yna ddrychau o'r storfeydd cod sydd ar gael yn gyhoeddus yn y cyfeiriadau canlynol:
- — Fframwaith cyfluniad GitLab.com ar gyfer siart Helm GitLab;
- - Yn cynnwys ffurfweddiadau ar gyfer gwasanaethau nad ydynt yn uniongyrchol gysylltiedig â chymhwysiad GitLab. Mae'r rhain yn cynnwys cyfluniadau ar gyfer logio a monitro clwstwr, yn ogystal ag offer integredig fel PlantUML;
- — Cyfluniad teras ar gyfer Kubernetes a seilwaith VM etifeddol. Yma rydych chi'n ffurfweddu'r holl adnoddau sydd eu hangen i redeg y clwstwr, gan gynnwys y clwstwr ei hun, cronfeydd nodau, cyfrifon gwasanaeth, ac archebion cyfeiriadau IP.
Dangosir golwg y cyhoedd pan wneir newidiadau. gyda dolen i'r gwahaniaeth manwl y mae ARhPh yn ei ddadansoddi cyn gwneud newidiadau i'r clwstwr.
Ar gyfer SRE, mae'r ddolen yn arwain at wahaniaeth manwl yn y gosodiad GitLab, a ddefnyddir ar gyfer cynhyrchu a mynediad cyfyngedig. Mae hyn yn galluogi gweithwyr a'r gymuned, heb fynediad i'r prosiect gweithredol (sydd ond yn agored i SREs), i weld newidiadau ffurfweddiad arfaethedig. Trwy gyfuno enghraifft GitLab cyhoeddus ar gyfer cod ag enghraifft breifat ar gyfer piblinellau CI, rydym yn cynnal un llif gwaith wrth sicrhau annibyniaeth ar GitLab.com ar gyfer diweddariadau cyfluniad.
Yr hyn a gawsom yn ystod yr ymfudiad
Yn ystod y symudiad, cafwyd profiad y byddwn yn ei gymhwyso i fudiadau a lleoliadau newydd yn Kubernetes.
1. Costau cynyddol oherwydd traffig rhwng parthau argaeledd
Ystadegau ymadael dyddiol (beit y dydd) ar gyfer fflyd cadwrfa Git ar GitLab.com
Mae Google yn rhannu ei rwydwaith yn ranbarthau. Rhennir y rheini, yn eu tro, yn barthau hygyrchedd (AZ). Mae hosting git yn gysylltiedig â llawer iawn o ddata, felly mae'n bwysig i ni reoli'r mynediad i'r rhwydwaith. Ar gyfer traffig mewnol, dim ond os yw'n aros o fewn yr un parth argaeledd y mae mynediad am ddim. O'r ysgrifennu hwn, rydym yn gwasanaethu tua 100 TB o ddata mewn diwrnod gwaith arferol (ac ar gyfer storfeydd Git yn unig y mae hynny). Mae gwasanaethau a oedd yn byw yn yr un peiriannau rhithwir yn ein hen dopoleg VM bellach yn rhedeg mewn gwahanol godiau Kubernetes. Mae hyn yn golygu y gallai rhywfaint o draffig a oedd gynt yn lleol i'r VM deithio y tu allan i'r parthau argaeledd.
Mae clystyrau GKE rhanbarthol yn caniatáu ichi rychwantu Parthau Argaeledd lluosog ar gyfer dileu swyddi. Rydym yn ystyried y posibilrwydd ar gyfer gwasanaethau sy'n cynhyrchu llawer iawn o draffig. Bydd hyn yn lleihau costau mynd allan tra'n cynnal diswyddiadau ar lefel clwstwr.
2. Terfynau, ceisiadau am adnoddau a graddio
Nifer y copïau sy'n prosesu traffig cynhyrchu ar registry.gitlab.com. Mae traffig ar ei uchaf am ~15:00 UTC.
Dechreuodd ein stori ymfudo ym mis Awst 2019, pan wnaethom symud ein gwasanaeth cyntaf, Cofrestrfa Cynhwysydd GitLab, i Kubernetes. Roedd y gwasanaeth traffig uchel hwn sy'n hanfodol i genhadaeth yn ddewis da ar gyfer y mudo cyntaf oherwydd ei fod yn gymhwysiad di-wladwriaeth gydag ychydig o ddibyniaethau allanol. Y broblem gyntaf y daethom ar ei thraws oedd nifer fawr o godennau wedi'u troi allan oherwydd diffyg cof ar y nodau. Oherwydd hyn, bu'n rhaid i ni newid ceisiadau a therfynau.
Darganfuwyd, yn achos cais lle mae defnydd cof yn cynyddu dros amser, bod gwerthoedd isel ar gyfer ceisiadau (cadw cof ar gyfer pob pod) ynghyd â therfyn caled “hael” ar ddefnydd yn arwain at dirlawnder (dirlawnder) nodau a lefel uchel o droi allan. I ddelio â'r broblem hon, yr oedd . Cymerodd hyn y pwysau oddi ar y nodau a sicrhau bod gan y codennau gylch bywyd nad oedd yn rhoi gormod o bwysau ar y nod. Nawr rydyn ni'n dechrau mudo gyda gwerthoedd ceisiadau a therfynau hael (a bron yn union yr un fath), gan eu haddasu yn ôl yr angen.
3. Metrigau a logiau
Mae'r is-adran seilwaith yn canolbwyntio ar hwyrni, cyfraddau gwallau a dirlawnder gyda gosod (SLO) yn gysylltiedig â .
Dros y flwyddyn ddiwethaf, un o'r digwyddiadau allweddol yn yr is-adran seilwaith fu gwelliannau wrth fonitro a gweithio gyda SLOs. Roedd SLO yn ein galluogi i osod nodau ar gyfer gwasanaethau unigol y buom yn eu monitro'n agos yn ystod y mudo. Ond hyd yn oed gyda'r arsylwi gwell hwn, nid yw bob amser yn bosibl gweld problemau ar unwaith gan ddefnyddio metrigau a rhybuddion. Er enghraifft, drwy ganolbwyntio ar gyfraddau hwyrni a gwallau, nid ydym yn ymdrin yn llawn â phob achos defnydd ar gyfer gwasanaeth sy'n symud.
Darganfuwyd y mater hwn bron yn syth ar ôl symud rhai llwythi gwaith i'r clwstwr. Daeth yn arbennig o ddifrifol pan fu'n rhaid i ni wirio swyddogaethau lle'r oedd nifer y ceisiadau'n fach, ond a oedd â dibyniaethau cyfluniad penodol iawn. Un o’r gwersi allweddol o’r mudo oedd yr angen i ystyried nid yn unig metrigau wrth fonitro, ond hefyd boncyffion a’r “gynffon hir” (mae hyn yn ymwneud ar y siart - tua. cyfieithu.) gwallau. Nawr ar gyfer pob mudo rydym yn cynnwys rhestr fanwl o ymholiadau log (cofnodi ymholiadau) a chynllunio gweithdrefnau dychwelyd clir y gellir eu trosglwyddo o un sifft i'r llall os bydd problemau'n codi.
Roedd gwasanaethu'r un ceisiadau ochr yn ochr â'r hen seilwaith VM a'r seilwaith newydd yn Kubernetes yn her unigryw. Yn wahanol i fudo lifft-a-shifft (trosglwyddo ceisiadau “fel y mae” yn gyflym i seilwaith newydd; gellir darllen mwy o fanylion, er enghraifft, - tua. cyfieithu.), mae gwaith cyfochrog ar "hen" VMs a Kubernetes yn ei gwneud yn ofynnol i offer monitro fod yn gydnaws â'r ddau amgylchedd ac yn gallu cyfuno metrigau i un olwg. Mae'n bwysig ein bod yn defnyddio'r un dangosfyrddau ac yn cofnodi ymholiadau er mwyn sicrhau ein bod yn gallu gweld yn gyson yn ystod y cyfnod pontio.
4. Newid traffig i glwstwr newydd
Ar gyfer GitLab.com, mae rhan o'r gweinyddwyr yn ymroddedig i . Mae Parc Canary yn gwasanaethu ein prosiectau mewnol a gall hefyd . Ond fe'i cynlluniwyd yn bennaf i brofi newidiadau a wneir i'r seilwaith a'r cymhwysiad. Dechreuodd y gwasanaeth mudol cyntaf trwy dderbyn swm cyfyngedig o draffig mewnol, ac rydym yn parhau i ddefnyddio'r dull hwn i sicrhau bod SLO yn cael eu bodloni cyn anfon yr holl draffig i'r clwstwr.
Yn achos mudo, mae hyn yn golygu bod ceisiadau i brosiectau mewnol yn cael eu hanfon at Kubernetes yn gyntaf, ac yna rydym yn newid gweddill y traffig i'r clwstwr yn raddol trwy newid y pwysau ar gyfer y backend trwy HAProxy. Yn ystod yr ymfudiad o VM i Kubernetes, daeth yn amlwg ei bod yn fuddiol iawn cael ffordd hawdd o ailgyfeirio traffig rhwng yr hen seilwaith a'r seilwaith newydd ac, yn unol â hynny, cadw'r hen seilwaith yn barod i'w ddychwelyd yn ystod y dyddiau cyntaf ar ôl y mudo.
5. Cadw cynhwysedd codennau a'u defnydd
Bron ar unwaith canfuwyd y broblem ganlynol: dechreuodd codennau ar gyfer gwasanaeth y Gofrestrfa yn gyflym, ond cymerodd lansio codennau ar gyfer Sidekiq hyd at . Daeth yr amser cychwyn hir ar gyfer codennau Sidekiq yn broblem pan ddechreuon ni symud llwythi gwaith i Kubernetes ar gyfer gweithwyr a oedd angen prosesu swyddi'n gyflym a graddfa'n gyflym.
Yn yr achos hwn, y wers oedd, er bod Autoscaler Pod Llorweddol Kubernetes (HPA) yn trin twf traffig yn dda, mae'n bwysig ystyried nodweddion y llwythi gwaith a dyrannu capasiti sbâr i'r codennau (yn enwedig pan fo'r galw wedi'i ddosbarthu'n anwastad). Yn ein hachos ni, bu ymchwydd sydyn mewn swyddi, gan arwain at raddio cyflym, a arweiniodd at ddirlawnder adnoddau CPU cyn inni gael amser i raddfa'r pwll nodau.
Mae yna demtasiwn bob amser i wasgu cymaint â phosibl allan o glwstwr, fodd bynnag, ar ôl dod ar draws problemau perfformiad i ddechrau, rydym bellach yn dechrau gyda chyllideb pod hael ac yn ei lleihau yn ddiweddarach, gan gadw llygad barcud ar SLOs. Mae lansio codennau ar gyfer y gwasanaeth Sidekiq wedi cyflymu'n sylweddol ac mae bellach yn cymryd tua 40 eiliad ar gyfartaledd. ennill GitLab.com a'n defnyddwyr gosodiadau hunan-reoli gan weithio gyda siart swyddogol GitLab Helm.
Casgliad
Ar ôl mudo pob gwasanaeth, roeddem yn llawenhau ar fanteision defnyddio Kubernetes wrth gynhyrchu: defnyddio cymwysiadau cyflymach a mwy diogel, graddio, a dyrannu adnoddau'n fwy effeithlon. Ar ben hynny, mae manteision mudo yn mynd y tu hwnt i wasanaeth GitLab.com. Mae pob gwelliant i'r siart Helm swyddogol o fudd i'w ddefnyddwyr.
Gobeithio ichi fwynhau stori ein hanturiaethau mudo Kubernetes. Rydym yn parhau i symud yr holl wasanaethau newydd i’r clwstwr. Ceir gwybodaeth ychwanegol yn y cyhoeddiadau canlynol:
- «";
- «";
- .
PS gan y cyfieithydd
Darllenwch hefyd ar ein blog:
- «";
- «";
- «";
- «'.
Ffynhonnell: hab.com