Ohar. itzul.: GitLab-en Kubernetes hartzea konpainiaren hazkuntzan laguntzen duen bi faktore nagusietako bat da. Hala ere, duela gutxi arte, GitLab.com lineako zerbitzuaren azpiegitura makina birtualetan eraiki zen, eta duela urtebete inguru hasi zen K8rako migrazioa, oraindik amaitu gabe dagoena. Pozik gaude GitLab SRE ingeniari baten berriki egindako artikulu baten itzulpena nola gertatzen den eta proiektuan parte hartzen duten ingeniariek zer ondorio ateratzen dituzten.
Duela urtebete inguru, gure azpiegitura dibisioak GitLab.com-en exekutatzen diren zerbitzu guztiak Kubernetesera migratzen ditu. Denbora horretan, zerbitzuak Kubernetesera eramateari ez ezik, trantsizio garaian inplementazio hibridoa kudeatzeari lotutako erronkak topatu genituen. Ikasi ditugun ikasgai baliotsuak artikulu honetan eztabaidatuko dira.
GitLab.com-en hasieratik, bere zerbitzariak hodeian ibiltzen ziren makina birtualetan. Makina birtual hauek Chefek kudeatzen ditu eta gure bidez instalatzen dira . aplikazioa eguneratu behar bada, zerbitzarien flota modu koordinatuan eta sekuentzial batean eguneratzean datza, CI kanalizazioa erabiliz. Metodo hau - motela eta pixka bat bada ere - GitLab.com-ek lineaz kanpoko erabiltzaileen instalazio eta konfigurazio praktika berberak erabiltzen dituela ziurtatzen du (autogestionatua) GitLab instalazioak gure Linux paketeak erabiliz.
Metodo hau erabiltzen dugu, oso garrantzitsua delako komunitateko kide arruntek GitLab-en kopiak instalatzean eta konfiguratzean jasaten dituzten atsekabe eta poz guztiak bizitzea. Ikuspegi honek denbora luzez ondo funtzionatu zuen, baina GitLab-en proiektuen kopurua 10 milioitik gorakoa izan zenean, konturatu ginen jada ez zituela gure eskalatzeko eta hedatzeko beharrizanak betetzen.
Kubernetes eta hodeian jatorrizko GitLab-erako lehen urratsak
Proiektua 2017an sortu zen GitLab hodeian inplementatzeko prestatzeko eta erabiltzaileek Kubernetes klusterretan GitLab instalatu ahal izateko. Orduan bagenekien GitLab Kubernetesera eramateak SaaS plataformaren eskalagarritasuna areagotuko zuela, inplementazioak sinplifikatuko zituela eta baliabide informatikoen eraginkortasuna hobetuko zuela. Aldi berean, gure aplikazioaren funtzio asko muntatutako NFS partizioen mende zeuden, eta horrek makina birtualen trantsizioa moteldu zuen.
Hodeiko jatorrizko eta Kubernetes-en aldeko bultzadari esker, gure ingeniariei trantsizio pixkanaka planifikatzeko aukera izan zuten, eta horretan, aplikazioak sareko biltegiratzearekiko zituen mendekotasun batzuk alde batera utzi genituen, funtzio berriak garatzen jarraitu genuen bitartean. 2019ko udan migrazioa planifikatzen hasi ginenetik, muga horietako asko konpondu dira, eta GitLab.com Kubernetesera migratzeko prozesua abian da!
GitLab.com-en ezaugarriak Kubernetes-en
GitLab.com-erako, aplikazioen trafiko guztia kudeatzen duen eskualdeko GKE kluster bakarra erabiltzen dugu. Migrazioaren (dagoeneko delikatua) konplexutasuna minimizatzeko, biltegiratze lokalean edo NFSan oinarritzen ez diren zerbitzuetan zentratzen gara. GitLab.com-ek Rails kode-oinarri monolitikoa erabiltzen du nagusiki, eta lan-kargaren ezaugarrietan oinarritutako trafikoa bideratzen dugu beren nodo multzoetan isolatuta dauden amaiera-puntu desberdinetara.
Frontendaren kasuan, mota hauek web, API, Git SSH/HTTPS eta Erregistrorako eskaerak banatzen dira. Backend-aren kasuan, ilaran dauden lanak hainbat ezaugarriren arabera banatzen ditugu , hainbat lan kargatarako Zerbitzu-mailako helburuak (SLO) ezartzeko aukera ematen diguna.
GitLab.com zerbitzu hauek guztiak aldatu gabeko GitLab Helm diagrama erabiliz konfiguratzen dira. Konfigurazioa azpidiagrametan egiten da, eta hori selektiboki gaitu ahal izango da pixkanaka zerbitzuak klusterera migratzen ditugun heinean. Nahiz eta gure egoera-zerbitzuetako batzuk migrazioan ez sartzea erabaki genuen, hala nola Redis, Postgres, GitLab Pages eta Gitaly, Kubernetes erabiltzeak Chef-ek gaur egun kudeatzen dituen VM kopurua errotik murrizteko aukera ematen digu.
Kubernetes Konfigurazioa Ikusgarritasuna eta Kudeaketa
Ezarpen guztiak GitLab-ek berak kudeatzen ditu. Horretarako, Terraform eta Helm-en oinarritutako hiru konfigurazio-proiektu erabiltzen dira. GitLab bera erabiltzen saiatzen gara posible den guztietan GitLab exekutatzeko, baina zeregin operatiboetarako GitLab instalazio bereizia dugu. Hau beharrezkoa da GitLab.com-en erabilgarritasunaren menpe ez zaudela ziurtatzeko GitLab.com-en inplementazioak eta eguneraketak egitean.
Kubernetes klusterraren kanalizazioak GitLab instalazio bereizi batean exekutatzen diren arren, helbide hauetan publikoki eskuragarri dauden kode-biltegien ispiluak daude:
- β GitLab.com konfigurazio-esparrua GitLab Helm diagramarako;
- - GitLab aplikazioarekin zuzenean lotuta ez dauden zerbitzuen konfigurazioak ditu. Besteak beste, erregistrorako eta klusterren jarraipena egiteko konfigurazioak, baita PlantUML bezalako tresna integratuak ere;
- β Terraform-en konfigurazioa Kubernetes eta ondare VM azpiegiturarako. Hemen klusterra exekutatzeko beharrezkoak diren baliabide guztiak konfiguratzen dituzu, kluster bera, nodo multzoak, zerbitzu-kontuak eta IP helbideen erreserbak barne.
Aldaketak egiten direnean ikuspegi publikoa erakusten da. SREk klusterrean aldaketak egin aurretik aztertzen duen desberdintasun zehatzerako esteka batekin.
SRErako, estekak GitLab instalazioan desberdintasun zehatz batera eramaten du, produkziorako eta sarbidea mugatuta dagoena. Horri esker, langileek eta komunitateak, proiektu operatibora sarbiderik gabe (SREentzat bakarrik irekita dagoena), proposatutako konfigurazio-aldaketak ikusteko aukera dute. Koderako GitLab instantzia publiko bat CI kanalizazioetarako instantzia pribatu batekin konbinatuz, lan-fluxu bakarra mantentzen dugu GitLab.com-ekiko independentzia bermatuz konfigurazio eguneratzeetarako.
Migrazioan aurkitu genuena
Mugimenduan zehar, Kubernetes-en migrazio eta inplementazio berrietan aplikatzen dugun esperientzia lortu zen.
1. Kostuak areagotzea erabilgarritasun guneen arteko trafikoaren ondorioz
Eguneko irteera-estatistikak (byte eguneko) Git biltegiaren flota GitLab.com-en
Google-k bere sarea eskualdetan banatzen du. Horiek, berriz, irisgarritasun guneetan (AZ) banatzen dira. Git hostinga datu kopuru handiekin lotuta dago, beraz, garrantzitsua da guretzat sarearen irteera kontrolatzea. Barne trafikorako, irteera doakoa da erabilgarritasun-eremu berean geratzen bada. Hau idazten den unean, gutxi gorabehera 100 TB datu hornitzen ari gara ohiko lanaldi batean (eta hori Git biltegietarako bakarrik da). Gure VM-n oinarritutako topologia zaharreko makina birtual berdinetan bizi ziren zerbitzuak Kubernetes-eko pod ezberdinetan exekutatzen dira orain. Horrek esan nahi du lehen VM-n tokikoa zen trafiko batzuk erabilgarritasun-eremuetatik kanpo joan daitezkeela.
Eskualdeko GKE klusterrek hainbat erabilgarritasun-eremu zabal ditzakezu erredundantziarako. Aukera aztertzen ari gara trafiko bolumen handiak sortzen dituzten zerbitzuetarako. Horrek irteera-kostuak murriztuko ditu kluster-mailako erredundantzia mantenduz.
2. Mugak, baliabide eskaerak eta eskalatzea
Produkzioaren trafikoa prozesatzen duen erreplika kopurua registry.gitlab.com webgunean. Trafiko gailurrak ~ 15:00 UTC-n.
Gure migrazio istorioa 2019ko abuztuan hasi zen, gure lehen zerbitzua, GitLab Container Registry, Kubernetesera migratu genuenean. Eginkizun kritikoa eta trafiko handiko zerbitzu hau aukera ona izan zen lehen migraziorako, kanpoko menpekotasun gutxi dituen estaturik gabeko aplikazioa delako. Topatu genuen lehen arazoa nodoetako memoria faltagatik desalojatutako pods ugari izan zen. Horregatik, eskaerak eta mugak aldatu behar izan ditugu.
Deskubritu zen memoria-kontsumoa denboran zehar handitzen den aplikazio baten kasuan, eskaeren balio baxuek (pod bakoitzaren memoria erreserbatuz) erabileraren muga gogor "eskuzabalarekin" saturazioa eragiten zutela. (saturazioa) nodoak eta kaleratze maila altua. Arazo honi aurre egiteko, izan zen . Honek presioa kendu zuen nodoei eta lekak nodoari presio gehiegirik egiten ez zion bizi-zikloa izatea bermatu zuen. Orain eskaera eta muga-balio eskuzabalekin (eta ia berdinekin) hasten ditugu migrazioak, behar den moduan egokituz.
3. Metrikak eta erregistroak
Azpiegitura dibisioa latentzia, errore-tasak eta instalatutako saturazioan zentratzen da (SLO) lotuta .
Azken urtean, azpiegituren dibisioko gertakari garrantzitsuenetako bat SLOekin monitorizatzeko eta lan egiteko hobekuntzak izan dira. SLOek migrazioan zehar gertutik kontrolatu genituen zerbitzu indibidualetarako helburuak ezarri ziguten. Baina behagarritasun hobetu hori izanda ere, ez da beti posible metrika eta alertak erabiliz arazoak berehala ikustea. Esaterako, latentzia eta errore-tasetan zentratuta, ez ditugu guztiz estaltzen migrazioan dagoen zerbitzu baten erabilera kasu guztiak.
Arazo hau ia berehala aurkitu zen lan-karga batzuk klusterera migratu ondoren. Bereziki zorrotz bihurtu zen eskaera kopurua txikia zen, baina konfigurazio-menpekotasun oso zehatzak zituzten funtzioak egiaztatu behar izan genituenean. Migrazioaren ikasgai nagusietako bat monitorizazioan neurketak ez ezik, erregistroak eta "buztan luzea" ere kontuan hartu beharra izan zen. (hau buruz da taulan - gutxi gorabehera. itzul.) akatsak. Orain migrazio bakoitzeko erregistro-kontsulten zerrenda zehatza sartzen dugu (erregistroko kontsultak) eta arazoak sortzen badira txanda batetik bestera pasa daitezkeen atzera egiteko prozedura argiak planifikatu.
VM azpiegitura zaharrean eta Kubernetesen oinarritutako azpiegitura berrian eskaera berdinak paraleloan hornitzeak erronka paregabea zuen. Igo-aldaketa-migrazioa ez bezala (aplikazioak azpiegitura berri batera transferitzea azkar; xehetasun gehiago irakur daitezke, adibidez, - gutxi gorabehera. itzul.), VM "zahar" eta Kubernetes-en lan paraleloak monitorizazio tresnak bi inguruneekin bateragarriak izatea eta neurketak ikuspegi bakarrean konbinatu ahal izatea eskatzen du. Garrantzitsua da aginte-panel eta erregistro-kontsulta berdinak erabiltzea trantsizio-aldian behagarritasun koherentea lortzeko.
4. Trafikoa kluster berri batera aldatzea
GitLab.com-entzat, zerbitzarien zati bat dedikatzen da . Canary Parkek gure barne-proiektuak balio du eta baita ere . Baina batez ere azpiegituran eta aplikazioan egindako aldaketak probatzeko diseinatuta dago. Migratutako lehen zerbitzua barneko trafiko kopuru mugatua onartuz hasi zen, eta metodo hau erabiltzen jarraitzen dugu SLOak betetzen direla ziurtatzeko trafiko guztia clusterra bidali aurretik.
Migrazioaren kasuan, horrek esan nahi du barne-proiektuetarako eskaerak Kubernetesera bidaltzen direla lehenik, eta gero pixkanaka gainontzeko trafikoa klusterera aldatzen dugu backendaren pisua aldatuz HAProxy bidez. VMtik Kubernetesera migratzean, argi geratu zen oso onuragarria zela azpiegitura zahar eta berriaren arteko trafikoa birbideratzeko modu erraz bat izatea eta, horren arabera, azpiegitura zaharra migrazioaren ondorengo lehen egunetan atzera egiteko prest edukitzea.
5. Lekaren erreserba ahalmenak eta horien erabilera
Ia berehala ondoko arazoa identifikatu zen: Erregistro zerbitzurako pod-ak azkar hasi ziren, baina Sidekiq-erako pod-ak abiarazteko . Sidekiq pod-en abiarazte-denbora luzea arazo bihurtu zen Kubernetes-era lan-kargak migratzen hasi ginenean, lanak azkar prozesatu eta azkar eskalatu behar zituzten langileentzat.
Kasu honetan, ikasgaia izan zen Kubernetes-en Horizontal Pod Autoscaler (HPA) trafikoaren hazkundea ondo kudeatzen duen arren, garrantzitsua dela lan-kargaren ezaugarriak kontuan hartzea eta ordezko ahalmena esleitzea podei (batez ere eskaria modu irregularrean banatuta dagoenean). Gure kasuan, lanpostuen bat-bateko gorakada izan zen, eta horrek eskalatze azkarra ekarri zuen, eta horrek CPU baliabideen saturazioa ekarri zuen nodoen multzoa eskalatzeko denbora izan baino lehen.
Beti dago kluster batetik ahalik eta gehien ateratzeko tentazioa, hala ere, hasiera batean errendimendu-arazoak aurkitu genituenez, orain pod-aurrekontu eskuzabal batekin hasi eta gero murrizten ari gara, SLOak gertutik zainduz. Sidekiq zerbitzurako pods abiarazteak nabarmen bizkortu du eta orain 40 segundo inguru behar ditu batez beste. GitLab.com-ek eta GitLab Helm taula ofizialarekin lan egiten duten autokudeatutako instalazioen erabiltzaileek irabazi zuten.
Ondorioa
Zerbitzu bakoitza migratu ondoren, poztu ginen Kubernetes ekoizpenean erabiltzeak dituen onurekin: aplikazioen inplementazio azkarra eta seguruagoa, eskalatzea eta baliabideen esleipen eraginkorragoa. Gainera, migrazioaren abantailak GitLab.com zerbitzutik haratago doaz. Helm grafiko ofizialaren hobekuntza bakoitzak bere erabiltzaileei mesede egiten die.
Espero dut gure Kubernetes migrazio-abenturen istorioa gustatu izana. Zerbitzu berri guztiak klusterera migratzen jarraitzen dugu. Informazio gehigarria honako argitalpen hauetan aurki daiteke:
- «»;
- «»;
- .
PS itzultzailetik
Irakurri ere gure blogean:
- «»;
- «»;
- «»;
- Β«'.
Iturria: www.habr.com