Tra la jaroj, la 300 milionoj da uzantoj de Pinterest kreis pli ol 200 miliardojn da pingloj sur pli ol 4 miliardoj da tabuloj. Por servi ĉi tiun armeon de uzantoj kaj vastan enhavon, la portalo evoluigis milojn da servoj, kiuj iras de mikroservoj, kiuj povas esti pritraktitaj de kelkaj CPU-oj, ĝis gigantaj monolitoj, kiuj funkcias per tuta aro de virtualaj maŝinoj. Kaj tiam venis la momento, kiam la okuloj de la kompanio falis sur k8s. Kial la "kubo" aspektis bone en Pinterest? Pri tio vi lernos el nia traduko de lastatempa artikolo el .
Do, centoj da milionoj da uzantoj kaj centoj da miliardoj da pingloj. Por servi ĉi tiun armeon de uzantoj kaj vastan enhavon, ni evoluigis milojn da servoj, kiuj iras de mikroservoj, kiuj povas esti pritraktitaj de kelkaj CPU-oj, ĝis gigantaj monolitoj, kiuj funkcias per tutaj aroj de virtualaj maŝinoj. Krome, ni havas diversajn kadrojn, kiuj ankaŭ povas postuli CPU, memoron aŭ I/O-aliron.
Prizorgante ĉi tiun zoon de iloj, la evolua teamo alfrontas kelkajn defiojn:
- Ne ekzistas unuforma maniero por inĝenieroj prizorgi produktadmedion. Sennaciaj servoj, Ŝtataj servoj kaj projektoj sub aktiva disvolviĝo baziĝas sur tute malsamaj teknologiaj stakoj. Ĉi tio kaŭzis la kreadon de tuta trejna kurso por inĝenieroj, kaj ankaŭ serioze malfaciligas la laboron de nia infrastruktura teamo.
- Programistoj kun sia propra aro de virtualaj maŝinoj kreas grandegan ŝarĝon por internaj administrantoj. Kiel rezulto, tiaj simplaj operacioj kiel ĝisdatigi la OS aŭ AMI daŭras semajnojn kaj monatojn. Ĉi tio kondukas al pliigita laborkvanto en ŝajne absolute ĉiutagaj situacioj.
- Malfacilaĵoj en kreado de tutmondaj infrastrukturaj administradiloj aldone al ekzistantaj solvoj. La situacio estas pli komplikita pro la fakto, ke trovi la posedantojn de virtualaj maŝinoj ne estas facila. Tio estas, ni ne scias ĉu ĉi tiu kapablo povas esti sekure ĉerpita por funkcii en aliaj partoj de nia infrastrukturo.
Ujajn instrumentadsistemojn estas maniero unuigi laborŝarĝan administradon. Ili malfermas la pordon al pliigita evolurapideco kaj simpligas infrastrukturan administradon, ĉar ĉiuj rimedoj implikitaj en la projekto estas administritaj per unu centralizita sistemo.
Figuro 1: Infrastrukturaj prioritatoj (fidindeco, programisto-produktiveco kaj efikeco).
La teamo de Cloud Management Platform ĉe Pinterest malkovris K8s en 2017. Antaŭ la unua duono de 2017, ni dokumentis la plej multajn el niaj produktadkapabloj, inkluzive de la API kaj ĉiuj niaj retserviloj. Poste, ni faris ĝisfundan taksadon de diversaj sistemoj por reĝisori ujajn solvojn, konstrui aretojn kaj labori kun ili. Al la fino de 2017, ni decidis uzi Kubernetes. Ĝi estis sufiĉe fleksebla kaj vaste subtenata en la programista komunumo.
Ĝis nun, ni konstruis niajn proprajn grupajn lanĉajn ilojn bazitajn sur Kops kaj migris ekzistantajn infrastrukturajn komponantojn kiel ekzemple retoj, sekureco, metrikoj, arbodehakado, identecadministrado kaj trafiko al Kubernetes. Ni ankaŭ efektivigis laborŝarĝan modelan sistemon por nia rimedo, kies komplekseco estas kaŝita de programistoj. Nun ni koncentriĝas pri certigi la stabilecon de la areto, grimpi ĝin kaj konekti novajn klientojn.
Kubernetes: La Pinterest Vojo
Komenci kun Kubernetes laŭ la skalo de Pinterest kiel platformo, kiun niaj inĝenieroj amus, venis kun multaj defioj.
Kiel granda kompanio, ni multe investis en infrastrukturaj iloj. Ekzemploj inkluzivas sekurecajn ilojn, kiuj pritraktas atestilpretigon kaj ŝlosilan distribuon, trafikkontrolajn komponentojn, servo-malkovrosistemojn, videbleckomponentojn, kaj ŝtipojn kaj metrikajn forsendajn komponentojn. Ĉio ĉi estis kolektita pro kialo: ni iris tra la normala vojo de provo kaj eraro, kaj tial ni volis integri ĉi tiun tutan ekipaĵon en la novan infrastrukturon de Kubernetes anstataŭ reinventi la malnovan radon sur nova platformo. Ĉi tiu aliro ĝenerale simpligis la migradon, ĉar la tuta aplika subteno jam ekzistas kaj ne bezonas esti kreita de nulo.
Aliflanke, la ŝarĝoprognozaj modeloj en Kubernetes mem (kiel ekzemple deplojoj, laborpostenoj kaj Daemon-aroj) ne sufiĉas por nia projekto. Ĉi tiuj problemoj pri uzebleco estas grandegaj baroj por translokiĝi al Kubernetes. Ekzemple, ni aŭdis programistojn pri servo plendi pri mankantaj aŭ malĝustaj ensalutaj agordoj. Ni ankaŭ renkontis malĝustan uzon de ŝablonmotoroj, kiam centoj da kopioj estis kreitaj kun la sama specifo kaj tasko, kio rezultigis koŝmarajn elpurigajn problemojn.
Estis ankaŭ tre malfacile konservi malsamajn versiojn en la sama areto. Imagu la kompleksecon de klienta subteno se vi bezonas labori samtempe en pluraj versioj de la sama rultempa medio, kun ĉiuj iliaj problemoj, cimoj kaj ĝisdatigoj.
Pinterest Uzanto Propraĵoj kaj Regiloj
Por faciligi al niaj inĝenieroj efektivigi Kubernetes, kaj simpligi kaj akceli nian infrastrukturon, ni evoluigis niajn proprajn kutimajn rimeddifinojn (CRD).
CRDoj disponigas la sekvan funkciecon:
- Kombinante malsamajn indiĝenajn Kubernetes-resursojn por ke ili funkciu kiel ununura laborkvanto. Ekzemple, la rimedo PinterestService inkluzivas deplojon, ensaluta servon kaj agordan mapon. Ĉi tio permesas al programistoj ne zorgi pri agordo de DNS.
- Efektivigu necesan aplikan subtenon. La uzanto devas koncentriĝi nur pri la ujspecifo laŭ sia komerca logiko, dum la CRD-regilo efektivigas ĉiujn necesajn init-ujojn, mediovariablojn kaj podspecifojn. Ĉi tio provizas fundamente malsaman nivelon de komforto por programistoj.
- CRD-regiloj ankaŭ administras la vivociklon de indiĝenaj resursoj kaj plibonigas sencimigan haveblecon. Ĉi tio inkluzivas akordigi deziratajn kaj realajn specifojn, ĝisdatigi CRD-statuson kaj konservi evento-programojn, kaj pli. Sen CRD, programistoj estus devigitaj administri plurajn rimedojn, kiuj nur pliigus la probablecon de eraro.
Jen ekzemplo de PinterestService kaj interna rimedo, kiu estas administrita de nia regilo:
Kiel vi povas vidi supre, por subteni kutiman ujon ni devas integri init-ujon kaj plurajn aldonaĵojn por provizi sekurecon, videblecon kaj retan trafikon. Krome, ni kreis agordajn mapŝablonojn kaj efektivigis subtenon por PVC-ŝablonoj por bataj laboroj, same kiel spuradon de multoblaj mediaj variabloj por spuri identecon, konsumon de rimedoj kaj rubkolekton.
Estas malfacile imagi, ke programistoj volus skribi ĉi tiujn agordajn dosierojn mane sen CRD-subteno, des malpli plu konservi kaj sencimigi la agordojn.
Aplika disfalda laborfluo
La supra bildo montras kiel disfaldi Pinterest-adaptitan rimedon al Kubernetes-grupo:
- Programistoj interagas kun nia Kubernetes-grupo per la CLI kaj uzantinterfaco.
- La CLI/UI-iloj reakiras la laborfluan agordajn YAML-dosierojn kaj aliajn konstruajn proprietojn (sama versio-identigilo) de Artifactory kaj poste sendas ilin al la Job Submission Service. Ĉi tiu paŝo certigas, ke nur produktadversioj estas liveritaj al la areto.
- JSS estas enirejo por diversaj platformoj, inkluzive de Kubernetes. Ĉi tie la uzanto estas aŭtentikigita, kvotoj estas eldonitaj kaj la agordo de nia CRD estas parte kontrolita.
- Post kontroli la CRD ĉe la JSS-flanko, la informoj estas senditaj al la k8s-platformo API.
- Nia CRD-regilo monitoras eventojn pri ĉiuj uzantresursoj. Ĝi konvertas CR-ojn en indiĝenajn k8s-resursojn, aldonas la necesajn modulojn, starigas la taŭgajn medio-variablojn kaj plenumas aliajn subtenajn laborojn por certigi, ke kontenerigitaj uzantaj aplikaĵoj havas sufiĉan infrastrukturan subtenon.
- La CRD-regilo tiam pasas la ricevitajn datumojn al la Kubernetes API por ke ĝi estu prilaborita de la planisto kaj metita en produktadon.
Примечание: Ĉi tiu antaŭ-liberiga laborfluo de la deplojo estis kreita por la unuaj uzantoj de la nova k8s-platformo. Ni estas nuntempe en la procezo rafini ĉi tiun procezon por plene integriĝi kun nia nova CI/KD. Ĉi tio signifas, ke ni ne povas diri al vi ĉion rilate al Kubernetes. Ni antaŭĝojas konigi nian sperton kaj la progreson de la teamo en ĉi tiu direkto en nia sekva bloga afiŝo, "Konstruante CI/KD-platformon por Pinterest."
Specoj de specialaj rimedoj
Surbaze de la specifaj bezonoj de Pinterest, ni evoluigis la sekvajn CRD-ojn por konveni al malsamaj laborfluoj:
- PinterestService estas sennaciaj servoj, kiuj funkcias delonge. Multaj el niaj kernaj sistemoj baziĝas sur aro de tiaj servoj.
- PinterestJobSet modeligas plenciklajn arajn laborojn. Ofta scenaro ĉe Pinterest estas, ke pluraj laboroj funkcias paralele la samajn ujojn, sendepende de aliaj similaj procezoj.
- PinterestCronJob estas vaste uzata kune kun malgrandaj periodaj ŝarĝoj. Ĉi tio estas envolvaĵo por denaska cron-laboro kun Pinterest-subtenaj mekanismoj, kiuj respondecas pri sekureco, trafiko, protokoloj kaj metrikoj.
- PinterestDaemon inkluzivas infrastrukturajn Daemonojn. Ĉi tiu familio daŭre kreskas dum ni aldonas pli da subteno al niaj aretoj.
- PinterestTrainingJob etendiĝas al Tensorflow kaj Pytorch-procezoj, provizante la saman nivelon de rultempa subteno kiel ĉiuj aliaj CRD-oj. Ĉar Pinterest aktive uzas Tensorflow kaj aliajn maŝinlernajn sistemojn, ni havis kialon konstrui apartan CRD ĉirkaŭ ili.
Ni ankaŭ laboras pri PinterestStatefulSet, kiu baldaŭ estos adaptita por datumstokejoj kaj aliaj ŝtataj sistemoj.
Runtime subteno
Kiam aplikaĵo funkcias sur Kubernetes, ĝi aŭtomate ricevas atestilon por identigi sin. Ĉi tiu atestilo estas uzata por aliri sekretan stokadon aŭ por komuniki kun aliaj servoj per mTLS. Dume, la Konfiguratoro de Initiko de Ujo kaj Demono elŝutos ĉiujn necesajn dependecojn antaŭ ol ruli la konteneritan aplikaĵon. Kiam ĉio estas preta, la trafika kromĉaro kaj Daemon registros la IP-adreson de la modulo ĉe nia Zookeeper por ke klientoj povu malkovri ĝin. Ĉio ĉi funkcios ĉar la reto-modulo estis agordita antaŭ ol la aplikaĵo estis lanĉita.
Ĉi-supraj estas tipaj ekzemploj de rultempa subteno por laborŝarĝoj. Aliaj specoj de laborŝarĝoj povas postuli iomete malsaman subtenon, sed ili ĉiuj venas en la formo de pod-nivelaj kromĉaroj, nod-nivelaj aŭ virtualaj maŝin-nivelaj Demonoj. Ni certigas, ke ĉio ĉi estas deplojita ene de la administra infrastrukturo kaj estas konsekvenca tra aplikaĵoj, kio finfine signife reduktas la ŝarĝon laŭ teknika laboro kaj klienta subteno.
Testado kaj QA
Ni konstruis fin-al-finan testan dukton aldone al la ekzistanta testa infrastrukturo de Kubernetes. Ĉi tiuj provoj validas por ĉiuj niaj aretoj. Nia dukto trapasis multajn reviziojn antaŭ ol ĝi fariĝis parto de la produkta grupo.
Krom testaj sistemoj, ni havas monitorajn kaj atentajn sistemojn, kiuj konstante kontrolas la staton de sistemaj komponantoj, konsumon de rimedoj kaj aliajn gravajn indikilojn, sciigante nin nur kiam homa interveno estas necesa.
Alternativoj
Ni rigardis kelkajn alternativojn al kutimaj rimedoj, kiel mutaciaj alirregiloj kaj ŝablonsistemoj. Tamen, ili ĉiuj venas kun gravaj funkciaj defioj, do ni elektis la CRD-itineron.
Mutacia agnoskregilo kutimis enkonduki kromĉarojn, mediovariablojn, kaj alian rultempan subtenon. Tamen, ĝi renkontis diversajn problemojn, kiel ekzemple rimedligado kaj vivcikloadministrado, kie tiaj problemoj ne ekestas en CRD.
Notu: Ŝablosistemoj kiel ekzemple Helm-diagramoj ankaŭ estas vaste uzataj por ruli aplikojn kun similaj agordoj. Tamen niaj labor-aplikoj estas tro diversaj por esti administritaj per ŝablonoj. Ankaŭ dum kontinua deplojo estos tro da eraroj dum uzo de ŝablonoj.
Venonta laboro
Ni nuntempe traktas miksitan ŝarĝon tra ĉiuj niaj aretoj. Por subteni tiajn procezojn de malsamaj tipoj kaj grandecoj, ni laboras en la sekvaj areoj:
- Kolekto de aretoj distribuas grandajn aplikojn tra malsamaj aretoj por skaleblo kaj stabileco.
- Certigante aretstabilecon, skaleblon kaj videblecon por krei aplikan konekteblecon kaj SLAojn.
- Administri rimedojn kaj kvotojn tiel ke aplikoj ne konfliktu unu kun la alia, kaj la skalo de la areto estas kontrolita niaflanke.
- Nova CI/KD-platformo por subteni kaj disfaldi aplikaĵojn sur Kubernetes.
fonto: www.habr.com