Oor die jare het Pinterest se 300 miljoen gebruikers meer as 200 miljard penne op meer as 4 miljard borde geskep. Om hierdie leër van gebruikers en groot inhoudbasis te dien, het die portaal duisende dienste ontwikkel, wat wissel van mikrodienste wat deur 'n paar SVE's hanteer kan word, tot reuse-monoliete wat op 'n hele vloot virtuele masjiene loop. En toe kom die oomblik toe die maatskappy se oë op k8's val. Hoekom het die "kubus" goed gelyk op Pinterest? Jy sal hieroor leer uit ons vertaling van 'n onlangse artikel van .
Dus, honderde miljoene gebruikers en honderde biljoene penne. Om hierdie leër van gebruikers en groot inhoudbasis te dien, het ons duisende dienste ontwikkel, wat wissel van mikrodienste wat deur 'n paar SVE's hanteer kan word, tot reuse-monoliete wat op hele vloot virtuele masjiene loop. Daarbenewens het ons 'n verskeidenheid raamwerke wat ook SVE-, geheue- of I/O-toegang kan vereis.
Met die instandhouding van hierdie dieretuin van gereedskap staar die ontwikkelingspan 'n aantal uitdagings in die gesig:
- Daar is geen eenvormige manier vir ingenieurs om 'n produksie-omgewing te bestuur nie. Staatlose dienste, Stateful dienste en projekte onder aktiewe ontwikkeling is gebaseer op heeltemal verskillende tegnologiestapels. Dit het gelei tot die skepping van 'n hele opleidingskursus vir ingenieurs, en bemoeilik ook die werk van ons infrastruktuurspan ernstig.
- Ontwikkelaars met hul eie vloot virtuele masjiene skep 'n groot las op interne administrateurs. Gevolglik neem sulke eenvoudige bewerkings soos die opdatering van die OS of AMI weke en maande. Dit lei tot verhoogde werklading in oënskynlik absoluut alledaagse situasies.
- Probleme met die skep van globale infrastruktuurbestuurnutsmiddels bo en behalwe bestaande oplossings. Die situasie word verder gekompliseer deur die feit dat dit nie maklik is om die eienaars van virtuele masjiene te vind nie. Dit wil sê, ons weet nie of hierdie kapasiteit veilig onttrek kan word om in ander dele van ons infrastruktuur te werk nie.
Houer-orkestrasiestelsels is 'n manier om werkladingsbestuur te verenig. Hulle maak die deur oop vir verhoogde ontwikkelingspoed en vereenvoudig infrastruktuurbestuur, aangesien alle hulpbronne betrokke by die projek deur een gesentraliseerde stelsel bestuur word.
Figuur 1: Infrastruktuurprioriteite (betroubaarheid, ontwikkelaarproduktiwiteit en doeltreffendheid).
Die Cloud Management Platform-span by Pinterest het K8's in 2017 ontdek. Teen die eerste helfte van 2017 het ons die meeste van ons produksievermoëns gedokumenteer, insluitend die API en al ons webbedieners. Daarna het ons 'n deeglike assessering van verskeie stelsels gedoen om houeroplossings te orkestreer, groepe te bou en daarmee te werk. Teen die einde van 2017 het ons besluit om Kubernetes te gebruik. Dit was redelik buigsaam en wyd ondersteun in die ontwikkelaargemeenskap.
Tot op hede het ons ons eie kluster-selflaainutsmiddels gebou wat op Kops gebaseer is en bestaande infrastruktuurkomponente soos netwerk, sekuriteit, metrieke, logboekregistrasie, identiteitsbestuur en verkeer na Kubernetes migreer. Ons het ook 'n werklading-modelleringstelsel vir ons hulpbron geïmplementeer, waarvan die kompleksiteit vir ontwikkelaars versteek is. Nou is ons daarop gefokus om die stabiliteit van die groepering te verseker, dit te skaal en nuwe kliënte te verbind.
Kubernetes: The Pinterest Way
Om met Kubernetes aan die gang te kom op die skaal van Pinterest as 'n platform wat ons ingenieurs graag sou wou hê, het baie uitdagings gepaard gegaan.
As 'n groot maatskappy het ons baie in infrastruktuurgereedskap belê. Voorbeelde sluit in sekuriteitnutsmiddels wat sertifikaatverwerking en sleutelverspreiding, verkeersbeheerkomponente, diensontdekkingstelsels, sigbaarheidskomponente en log- en statistiekversendingskomponente hanteer. Dit alles is vir 'n rede ingesamel: ons het deur die normale pad van probeer en fout gegaan, en daarom wou ons al hierdie toerusting in die nuwe infrastruktuur op Kubernetes integreer in plaas daarvan om die ou wiel op 'n nuwe platform te herontdek. Hierdie benadering het oor die algemeen die migrasie vereenvoudig, aangesien al die toepassingsondersteuning reeds bestaan en nie van nuuts af geskep hoef te word nie.
Aan die ander kant is die vragvoorspellingsmodelle in Kubernetes self (soos ontplooiings, werksgeleenthede en Daemon-stelle) nie genoeg vir ons projek nie. Hierdie bruikbaarheidskwessies is groot struikelblokke om na Kubernetes te beweeg. Ons het byvoorbeeld gehoor dat diensontwikkelaars kla oor ontbrekende of verkeerde aanmeldinstellings. Ons het ook verkeerde gebruik van sjabloonenjins teëgekom toe honderde kopieë met dieselfde spesifikasie en taak geskep is, wat gelei het tot nagmerrie-ontfoutingsprobleme.
Dit was ook baie moeilik om verskillende weergawes in dieselfde groepie te onderhou. Stel jou die kompleksiteit van kliëntediens voor as jy gelyktydig moet werk in verskeie weergawes van dieselfde looptyd-omgewing, met al hul probleme, foute en opdaterings.
Pinterest-gebruiker-eienskappe en beheerders
Om dit vir ons ingenieurs makliker te maak om Kubernetes te implementeer, en om ons infrastruktuur te vereenvoudig en te bespoedig, het ons ons eie persoonlike hulpbrondefinisies (CRD's) ontwikkel.
CRD's bied die volgende funksionaliteit:
- Die kombinasie van verskillende inheemse Kubernetes-bronne sodat hulle as 'n enkele werklading werk. Byvoorbeeld, die PinterestService-hulpbron sluit 'n ontplooiing, 'n aanmelddiens en 'n konfigurasiekaart in. Dit laat ontwikkelaars toe om nie bekommerd te wees oor die opstel van DNS nie.
- Implementeer die nodige toepassingsondersteuning. Die gebruiker hoef slegs op die houerspesifikasie te fokus volgens hul besigheidslogika, terwyl die CRD-beheerder al die nodige inithouers, omgewingsveranderlikes en peulspesifikasies implementeer. Dit bied 'n fundamenteel verskillende vlak van gemak vir ontwikkelaars.
- CRD-beheerders bestuur ook die lewensiklus van inheemse hulpbronne en verbeter ontfoutbeskikbaarheid. Dit sluit in die versoening van verlangde en werklike spesifikasies, die opdatering van CRD-status en die instandhouding van gebeurtenislogboeke, en meer. Sonder CRD sal ontwikkelaars gedwing word om veelvuldige hulpbronne te bestuur, wat net die waarskynlikheid van foute sal verhoog.
Hier is 'n voorbeeld van 'n PinterestService en 'n interne hulpbron wat deur ons beheerder bestuur word:
Soos u hierbo kan sien, moet ons 'n inithouer en verskeie byvoegings integreer om 'n pasgemaakte houer te ondersteun om sekuriteit, sigbaarheid en netwerkverkeer te verskaf. Daarbenewens het ons konfigurasiekaartsjablone geskep en ondersteuning vir PVC-sjablone vir bondeltake geïmplementeer, sowel as die dop van verskeie omgewingsveranderlikes om identiteit, hulpbronverbruik en vullisversameling na te spoor.
Dit is moeilik om te dink dat ontwikkelaars hierdie konfigurasielêers met die hand sal wil skryf sonder CRD-ondersteuning, wat nog te sê verder in stand te hou en die konfigurasies te ontfout.
Aansoek ontplooiing werkvloei
Die prent hierbo wys hoe om 'n pasgemaakte Pinterest-hulpbron na 'n Kubernetes-kluster te ontplooi:
- Ontwikkelaars het interaksie met ons Kubernetes-groepering deur die CLI en gebruikerskoppelvlak.
- Die CLI/UI-nutsmiddels haal die werkvloeikonfigurasie YAML-lêers en ander bou-eienskappe (dieselfde weergawe-ID) van Artifactory af en dien dit dan by die Job Submission Service in. Hierdie stap verseker dat slegs produksieweergawes aan die groepie gelewer word.
- JSS is 'n poort vir verskeie platforms, insluitend Kubernetes. Hier word die gebruiker geverifieer, kwotas uitgereik en die opstelling van ons CRD word gedeeltelik nagegaan.
- Nadat die CRD aan die JSS-kant nagegaan is, word die inligting na die k8s platform API gestuur.
- Ons CRD-beheerder monitor gebeure op alle gebruikershulpbronne. Dit omskep CR's in inheemse k8s-hulpbronne, voeg die nodige modules by, stel die toepaslike omgewingsveranderlikes in, en voer ander ondersteuningswerk uit om te verseker dat gebruikerstoepassings in containers voldoende infrastruktuurondersteuning het.
- Die CRD-beheerder gee dan die ontvangde data aan die Kubernetes API deur sodat dit deur die skeduleerder verwerk en in produksie geplaas kan word.
Let daarop: Hierdie voorvrystelling-werkvloei van die ontplooiing is geskep vir die eerste gebruikers van die nuwe k8s-platform. Ons is tans besig om hierdie proses te verfyn om ten volle met ons nuwe CI/CD te integreer. Dit beteken dat ons jou nie alles kan vertel wat met Kubernetes verband hou nie. Ons sien daarna uit om ons ervaring en die span se vordering in hierdie rigting te deel in ons volgende blogplasing, "Bou 'n CI/CD-platform vir Pinterest."
Tipes spesiale hulpbronne
Gebaseer op Pinterest se spesifieke behoeftes, het ons die volgende CRD's ontwikkel om by verskillende werkstrome te pas:
- PinterestService is staatlose dienste wat al lank aan die gang is. Baie van ons kernstelsels is gebaseer op 'n stel sulke dienste.
- PinterestJobSet modelle volsiklus bondeltake. 'n Algemene scenario op Pinterest is dat verskeie take dieselfde houers parallel laat loop, ongeag ander soortgelyke prosesse.
- PinterestCronJob word wyd gebruik in samewerking met klein periodieke vragte. Dit is 'n omhulsel vir inheemse cron-werk met Pinterest-ondersteuningsmeganismes wat verantwoordelik is vir sekuriteit, verkeer, logs en statistieke.
- PinterestDaemon sluit infrastruktuur Daemons in. Hierdie gesin groei steeds namate ons meer ondersteuning by ons groepe voeg.
- PinterestTrainingJob strek tot Tensorflow- en Pytorch-prosesse, wat dieselfde vlak van looptydondersteuning bied as alle ander CRD's. Aangesien Pinterest Tensorflow en ander masjienleerstelsels aktief gebruik, het ons 'n rede gehad om 'n aparte CRD rondom hulle te bou.
Ons werk ook aan PinterestStatefulSet, wat binnekort aangepas sal word vir datapakhuise en ander statige stelsels.
Runtime ondersteuning
Wanneer 'n toepassingpod op Kubernetes loop, ontvang dit outomaties 'n sertifikaat om homself te identifiseer. Hierdie sertifikaat word gebruik om toegang tot geheime berging te verkry of om met ander dienste via mTLS te kommunikeer. Intussen sal die Container Init Configurator en Daemon al die nodige afhanklikhede aflaai voordat die houertoepassing uitgevoer word. Wanneer alles gereed is, sal die verkeerssyspan en Daemon die module se IP-adres by ons dieretuinwagter registreer sodat kliënte dit kan ontdek. Dit alles sal werk omdat die netwerkmodule gekonfigureer is voordat die toepassing van stapel gestuur is.
Bogenoemde is tipiese voorbeelde van runtime-ondersteuning vir werkladings. Ander tipes werkladings kan effens verskillende ondersteuning vereis, maar hulle kom almal in die vorm van peulvlak-syspan, nodusvlak of virtuele masjienvlak Daemons. Ons verseker dat dit alles binne die bestuursinfrastruktuur ontplooi word en konsekwent oor toepassings heen is, wat uiteindelik die las in terme van tegniese werk en kliëntediens aansienlik verminder.
Toetsing en QA
Ons het 'n end-tot-end-toetspyplyn bo-op die bestaande Kubernetes-toetsinfrastruktuur gebou. Hierdie toetse is van toepassing op al ons groepe. Ons pyplyn het deur baie hersienings gegaan voordat dit deel van die produkgroepering geword het.
Benewens toetsstelsels het ons monitering- en waarskuwingstelsels wat voortdurend die status van stelselkomponente, hulpbronverbruik en ander belangrike aanwysers monitor, wat ons slegs in kennis stel wanneer menslike ingryping nodig is.
alternatiewe
Ons het na 'n paar alternatiewe vir pasgemaakte hulpbronne gekyk, soos mutasietoegangsbeheerders en sjabloonstelsels. Hulle kom egter almal met aansienlike operasionele uitdagings, so ons het die CRD-roete gekies.
'n Mutasietoelatingsbeheerder is gebruik om syspan, omgewingsveranderlikes en ander looptydondersteuning bekend te stel. Dit het egter verskeie probleme ondervind, soos hulpbronbinding en lewensiklusbestuur, waar sulke probleme nie in CRD voorkom nie.
Let wel: Sjabloonstelsels soos Helm-kaarte word ook wyd gebruik om toepassings met soortgelyke konfigurasies te laat loop. Ons werktoepassings is egter te divers om met behulp van sjablone bestuur te word. Ook tydens deurlopende ontplooiing sal daar te veel foute wees wanneer sjablone gebruik word.
Opkomende werk
Ons het tans te doen met 'n gemengde vrag oor al ons groepe. Om sulke prosesse van verskillende tipes en groottes te ondersteun, werk ons in die volgende areas:
- 'n Versameling groepe versprei groot toepassings oor verskillende groepe vir skaalbaarheid en stabiliteit.
- Versekering van groepstabiliteit, skaalbaarheid en sigbaarheid om toepassingskonnektiwiteit en SLA's te skep.
- Die bestuur van hulpbronne en kwotas sodat toepassings nie met mekaar bots nie, en die omvang van die groepering van ons kant beheer word.
- 'n Nuwe CI/CD-platform vir die ondersteuning en ontplooiing van toepassings op Kubernetes.
Bron: will.com