Urte hauetan, Pinterest-en 300 milioi erabiltzailek 200 milioi pin baino gehiago sortu dituzte 4 milioi taula baino gehiagotan. Erabiltzaileen armada eta eduki-oinarri zabal honen zerbitzurako, atariak milaka zerbitzu garatu ditu, CPU gutxi batzuek kudeatu ditzaketen mikrozerbitzuetatik hasi eta makina birtualen flota oso batean exekutatzen diren monolito erraldoietaraino. Eta orduan iritsi zen konpainiaren begirada k8etan erori zen momentua. Zergatik itxura ona zuen "kuboak" Pinterest-en? Horri buruz berriki egindako artikulu baten itzulpenetik ikasiko duzu .
Beraz, ehunka milioi erabiltzaile eta ehunka mila milioi pin. Erabiltzaileen armada eta eduki-oinarri zabal honen zerbitzurako, milaka zerbitzu garatu ditugu, CPU gutxi batzuek kudeatu ditzaketen mikrozerbitzuetatik hasi eta makina birtualen flota osoetan exekutatzen diren monolito erraldoietaraino. Horrez gain, CPU, memoria edo I/O sarbidea ere behar dezaketen esparru ugari ditugu.
Tresna-zoo hau mantentzen, garapen-taldeak hainbat erronka ditu:
- Ez dago ingeniariek produkzio-ingurune bat exekutatzeko modu uniformerik. Estaturik gabeko zerbitzuak, Stateful zerbitzuak eta garapen aktiboan dauden proiektuak teknologia pila guztiz desberdinetan oinarritzen dira. Horrek ingeniarientzako prestakuntza-ikastaro oso bat sortzea ekarri zuen, eta gure azpiegitura taldearen lana ere larri zailtzen du.
- Makina birtualen flota propioa duten garatzaileek zama handia sortzen dute barne administratzaileengan. Ondorioz, OS edo AMI eguneratzea bezalako eragiketa sinpleek asteak eta hilabeteak behar dituzte. Horrek lan karga handitzea dakar itxuraz erabat eguneroko egoeretan.
- Lehendik dauden soluzioen gainean azpiegiturak kudeatzeko tresna globalak sortzeko zailtasunak. Egoera are gehiago zaildu da makina birtualen jabeak aurkitzea erraza ez delako. Hau da, ez dakigu gaitasun hori modu seguruan atera daitekeen gure azpiegituren beste zati batzuetan jarduteko.
Edukiontzien orkestrazio sistemak lan-kargaren kudeaketa bateratzeko modu bat dira. Garapen-abiadura handitzeko ateak irekitzen dituzte eta azpiegituren kudeaketa sinplifikatzen dute, proiektuan parte hartzen duten baliabide guztiak sistema zentralizatu batek kudeatzen baititu.
1. irudia: Azpiegituren lehentasunak (fidagarritasuna, garatzaileen produktibitatea eta eraginkortasuna).
Pinterest-eko Cloud Management Platform taldeak K8ak aurkitu zituen 2017an. 2017ko lehen seihilekoan, gure ekoizpen-gaitasun gehienak dokumentatu genituen, APIa eta gure web zerbitzari guztiak barne. Ondoren, edukiontzien soluzioak orkestratzeko, klusterrak eraikitzeko eta haiekin lan egiteko hainbat sistemen ebaluazio sakona egin genuen. 2017 amaiera aldera, Kubernetes erabiltzea erabaki genuen. Nahiko malgua eta asko onartzen zen garatzaileen komunitatean.
Orain arte, Kops-en oinarritutako cluster-a abiarazteko tresnak eraiki ditugu eta lehendik dauden azpiegitura osagaiak migratu ditugu, hala nola sareak, segurtasuna, neurketak, erregistroa, identitatearen kudeaketa eta trafikoa Kubernetesera. Gure baliabiderako lan-karga modelatzeko sistema bat ere ezarri dugu, eta horren konplexutasuna garatzaileei ezkutatuta dago. Orain klusterraren egonkortasuna ziurtatzera, eskalatzera eta bezero berriak konektatzera bideratzen gara.
Kubernetes: Pinterest bidea
Kubernetes-ekin hastea Pinterest-en eskalan, gure ingeniariei gustatuko litzaiekeen plataforma gisa, erronka asko ekarri zizkion.
Enpresa handi gisa, inbertsio handia egin dugu azpiegitura tresnetan. Adibidez, ziurtagirien prozesaketa eta gakoen banaketa kudeatzen dituzten segurtasun-tresnak, trafikoa kontrolatzeko osagaiak, zerbitzuen aurkikuntza-sistemak, ikusgarritasun-osagaiak eta erregistro- eta metrikak bidaltzeko osagaiak daude. Hori guztia arrazoi batengatik bildu zen: saiakeraren bide arruntetik joan ginen, eta, horregatik, ekipo hori guztia Kuberneteseko azpiegitura berrian txertatu nahi genuen gurpil zaharra plataforma berri batean berrasmatu beharrean. Ikuspegi honek, oro har, migrazioa sinplifikatu zuen, aplikazioen euskarria dagoeneko existitzen baita eta ez baita hutsetik sortu behar.
Bestalde, Kubernetesen bertan karga aurreikusteko ereduak (hala nola inplementazioak, lanak eta Daemon multzoak) ez dira nahikoak gure proiekturako. Erabilgarritasun arazo hauek Kubernetesera mugitzeko oztopo handiak dira. Esaterako, zerbitzu-garatzaileei kexa egin diegu saio-hasierako ezarpenak falta direla edo okerrak direlako. Txantiloi-motorren erabilera okerra ere topatu dugu, ehunka kopia zehaztapen eta zeregin berdinekin sortu zirenean, eta horrek amesgaiztoko arazketa-arazoak eragin zituen.
Gainera, oso zaila zen kluster berean bertsio desberdinak mantentzea. Imajinatu bezeroarentzako laguntzaren konplexutasuna aldi berean exekuzio-ingurune bereko hainbat bertsiotan lan egin behar baduzu, arazo, akats eta eguneratze guztiekin.
Pinterest erabiltzaileen propietateak eta kontrolatzaileak
Gure ingeniariei Kubernetes inplementatzea errazteko eta gure azpiegitura sinplifikatzeko eta bizkortzeko, gure baliabideen definizio pertsonalizatuak (CRD) garatu ditugu.
CRDek funtzionalitate hauek eskaintzen dituzte:
- Kubernetes-en jatorrizko baliabide desberdinak konbinatuz, lan-karga bakar gisa funtziona dezaten. Adibidez, PinterestService baliabideak inplementazio bat, saioa hasteko zerbitzu bat eta konfigurazio mapa bat ditu. Horri esker, garatzaileak ez dira kezkatu DNS konfiguratzeaz.
- Beharrezko aplikazio-laguntza ezartzea. Erabiltzaileak edukiontziaren zehaztapenean soilik zentratu behar du bere negozio-logikaren arabera, CRD kontrolatzaileak beharrezko abiarazte-edukiontzi, ingurune-aldagai eta pod-zehaztapen guztiak ezartzen dituen bitartean. Horrek erosotasun maila desberdina eskaintzen die garatzaileei.
- CRD kontrolagailuek jatorrizko baliabideen bizi-zikloa ere kudeatzen dute eta arazketa erabilgarritasuna hobetzen dute. Horrek nahi diren eta benetako zehaztapenak bateratzea, CRD egoera eguneratzea eta gertaeren erregistroak mantentzea eta abar barne hartzen ditu. CRD gabe, garatzaileak baliabide anitz kudeatzera behartuta egongo lirateke, eta horrek akatsen probabilitatea areagotuko luke.
Hona hemen gure kontroladoreak kudeatzen duen PinterestService eta barne baliabide baten adibide bat:
Goian ikus dezakezun bezala, edukiontzi pertsonalizatu bat onartzeko init edukiontzi bat eta hainbat gehigarri integratu behar ditugu segurtasuna, ikusgarritasuna eta sareko trafikoa emateko. Horrez gain, konfigurazio-mapen txantiloiak sortu ditugu eta PVC txantiloietarako euskarria ezarri dugu batch-lanetarako, baita ingurune-aldagai anitzen jarraipena ere identitatea, baliabide-kontsumoa eta zabor-bilketaren jarraipena egiteko.
Zaila da imajinatzea garatzaileek konfigurazio-fitxategi hauek eskuz idatzi nahi dituztela CRD laguntzarik gabe, are gutxiago konfigurazioak mantendu eta arazketa.
Aplikazioak zabaltzeko lan-fluxua
Goiko irudiak erakusten du nola zabaldu Pinterest baliabide pertsonalizatu bat Kubernetes kluster batean:
- Garatzaileek gure Kubernetes klusterrekin elkarreragiten dute CLI eta erabiltzailearen interfazearen bidez.
- CLI/UI tresnek lan-fluxuaren konfigurazio YAML fitxategiak eta beste eraikuntza-propietate batzuk (bertsio-ID bera) berreskuratzen dituzte Artifactory-tik eta, ondoren, Lanpostuak Bidaltzeko Zerbitzura bidaltzen dituzte. Urrats honek klusterera produkzio-bertsioak soilik entregatzen direla ziurtatzen du.
- JSS hainbat plataformetarako atea da, Kubernetes barne. Hemen erabiltzailea autentifikatzen da, kuotak igortzen dira eta gure CRDren konfigurazioa partzialki egiaztatzen da.
- JSS aldean CRD egiaztatu ondoren, informazioa k8s plataformako APIra bidaltzen da.
- Gure CRD kontrolagailuak erabiltzaileen baliabide guztietan gertaerak kontrolatzen ditu. CRak k8s baliabide natibo bihurtzen ditu, beharrezko moduluak gehitzen ditu, ingurune-aldagai egokiak ezartzen ditu eta bestelako laguntza-lanak egiten ditu edukiontzidun erabiltzaileen aplikazioek azpiegitura-laguntza nahikoa dutela ziurtatzeko.
- Ondoren, CRD kontrolatzaileak jasotako datuak Kubernetes APIra pasatzen ditu, programatzaileak prozesatu eta ekoizpenean jarri ditzan.
Kontuan izan: Inplementazioaren aurretiko lan-fluxu hau k8s plataforma berriaren lehen erabiltzaileentzat sortu zen. Momentu honetan, prozesu hau hobetzen ari gara gure CI/CD berriarekin guztiz integratzeko. Horrek esan nahi du ezin dizugula esan Kubernetesekin lotutako guztia. Gure esperientzia eta taldearen aurrerapena norabide horretan partekatzea espero dugu gure hurrengo blogean, "Pinterest-erako CI/CD plataforma eraikitzen".
Baliabide berezi motak
Pinterest-en behar espezifikoetan oinarrituta, honako CRD hauek garatu ditugu lan-fluxu ezberdinetara egokitzeko:
- PinterestService denbora luzez exekutatzen ari diren estaturik gabeko zerbitzuak dira. Gure oinarrizko sistema asko zerbitzu multzo batean oinarritzen dira.
- PinterestJobSet-ek ziklo osoko sorta-lanak modelatzen ditu. Pinterest-en ohiko agertoki bat da hainbat lan ontzi berdinak paraleloan exekutatzen dituztela, antzeko beste prozesu batzuk gorabehera.
- PinterestCronJob oso erabilia da aldizkako karga txikiekin batera. Segurtasun, trafiko, erregistro eta neurketez arduratzen diren Pinterest laguntza-mekanismoekin egindako cron lanerako bilgarri bat da.
- PinterestDaemon-ek azpiegitura-daemonak biltzen ditu. Familia honek hazten jarraitzen du gure klusterrei laguntza gehiago gehitzen diegunean.
- PinterestTrainingJob Tensorflow eta Pytorch prozesuetara hedatzen da, beste CRD guztien exekuzio-denborako laguntza maila bera eskaintzen du. Pinterest-ek Tensorflow eta ikaskuntza automatikoko beste sistema batzuk aktiboki erabiltzen dituenez, arrazoi bat genuen haien inguruan CRD bereizi bat eraikitzeko.
PinterestStatefulSet-en ere lan egiten ari gara, laster datu biltegietarako eta beste egoera sistema batzuetarako egokituko dena.
Runtime laguntza
Aplikazio-pod bat Kubernetes-en exekutatzen denean, automatikoki ziurtagiri bat jasotzen du bere burua identifikatzeko. Ziurtagiri hau biltegiratze sekretua sartzeko edo beste zerbitzu batzuekin mTLS bidez komunikatzeko erabiltzen da. Bien bitartean, Container Init Configurator eta Daemon-ek beharrezko mendekotasun guztiak deskargatuko dituzte edukiontzidun aplikazioa exekutatu aurretik. Dena prest dagoenean, trafikoaren sidecar-ak eta Daemon-ek moduluaren IP helbidea erregistratuko dute gure Zookeeper-en bezeroek ezagutu dezaten. Horrek guztiak funtzionatuko du sareko modulua aplikazioa abiarazi aurretik konfiguratuta zegoelako.
Goiko hauek lan-kargak exekutatzeko euskarriaren adibide tipikoak dira. Beste lan-karga mota batzuek laguntza apur bat desberdina behar dute, baina denak pod-mailako sidecars, nodo-mailako edo makina birtualeko deabruen moduan datoz. Hori guztia kudeaketa-azpiegituren barruan hedatzen dela eta aplikazio guztietan koherentea dela ziurtatzen dugu, eta horrek, azken finean, lan teknikoari eta bezeroen laguntzari dagokionez zama nabarmen murrizten du.
Probak eta QA
Kubernetesen proba-azpiegituren gainean muturreko proba kanalizazioa eraiki dugu. Proba hauek gure kluster guztietan aplikatzen dira. Gure kanalizazioak hainbat berrikuspen izan zituen produktuen multzoan sartu aurretik.
Proba-sistemez gain, sistemaren osagaien egoera, baliabide-kontsumoa eta beste adierazle garrantzitsu batzuen egoera etengabe kontrolatzen duten monitorizazio- eta alerta-sistemak ditugu, giza esku-hartzea beharrezkoa denean soilik jakinarazten baitigute.
alternatibak
Baliabide pertsonalizatuen alternatiba batzuk aztertu ditugu, hala nola mutazioen sarbide-kontrolatzaileak eta txantiloi-sistemak. Hala ere, guztiak erronka operatibo esanguratsuekin datoz, beraz, CRD bidea aukeratu dugu.
Onarpen-kontrolatzaile mutazionala erabili zen sidecar-ak, ingurune-aldagaiak eta beste exekuzio-denborako laguntza batzuk sartzeko. Hala ere, hainbat arazo izan zituen, hala nola baliabideen lotura eta bizi-zikloaren kudeaketa, non CRDn halako arazoak sortzen ez diren.
Oharra: Helm diagramak bezalako txantiloi-sistemak ere asko erabiltzen dira antzeko konfigurazioekin aplikazioak exekutatzeko. Hala ere, gure lan-aplikazioak anitzegiak dira txantiloiak erabiliz kudeatzeko. Etengabeko hedapenean ere akats gehiegi egongo dira txantiloiak erabiltzean.
Datorren lana
Gaur egun, gure kluster guztietan karga misto batekin ari gara. Mota eta tamaina ezberdinetako horrelako prozesuei laguntzeko, arlo hauetan lan egiten dugu:
- Kluster-bilduma batek kluster desberdinetan aplikazio handiak banatzen ditu eskalagarritasun eta egonkortasunerako.
- Klusterren egonkortasuna, eskalagarritasuna eta ikusgarritasuna bermatzea aplikazioen konektibitatea eta SLAak sortzeko.
- Baliabideak eta kuotak kudeatzea, aplikazioak elkarren artean gatazkarik egon ez dadin, eta klusterraren eskala gure aldetik kontrolatuta dago.
- Kubernetes-en aplikazioak laguntzeko eta hedatzeko CI/CD plataforma berri bat.
Iturria: www.habr.com