Gennem årene har Pinterests 300 millioner brugere skabt mere end 200 milliarder pins på mere end 4 milliarder boards. For at betjene denne hær af brugere og enorme indholdsbase har portalen udviklet tusindvis af tjenester, lige fra mikrotjenester, der kan håndteres af nogle få CPU'er, til gigantiske monolitter, der kører på en hel flåde af virtuelle maskiner. Og så kom det øjeblik, hvor virksomhedens øjne faldt på k8'ere. Hvorfor så "kuben" godt ud på Pinterest? Du vil lære om dette fra vores oversættelse af en nylig artikel fra .
Så hundreder af millioner af brugere og hundreder af milliarder af pins. For at betjene denne hær af brugere og enorme indholdsbase har vi udviklet tusindvis af tjenester, lige fra mikrotjenester, der kan håndteres af nogle få CPU'er, til gigantiske monolitter, der kører på hele flåder af virtuelle maskiner. Derudover har vi en række rammer, der også kan kræve CPU, hukommelse eller I/O-adgang.
Ved at vedligeholde denne zoo af værktøjer står udviklingsteamet over for en række udfordringer:
- Der er ingen ensartet måde for ingeniører at drive et produktionsmiljø på. Statsløse services, Stateful services og projekter under aktiv udvikling er baseret på helt andre teknologistacke. Dette førte til oprettelsen af et helt uddannelseskursus for ingeniører og komplicerer også arbejdet for vores infrastrukturteam alvorligt.
- Udviklere med deres egen flåde af virtuelle maskiner skaber en enorm byrde for interne administratorer. Som følge heraf tager sådanne enkle handlinger som opdatering af OS eller AMI uger og måneder. Dette fører til øget arbejdsbyrde i tilsyneladende absolut hverdagssituationer.
- Vanskeligheder med at skabe globale infrastrukturstyringsværktøjer oven i eksisterende løsninger. Situationen kompliceres yderligere af det faktum, at det ikke er let at finde ejerne af virtuelle maskiner. Det vil sige, at vi ikke ved, om denne kapacitet sikkert kan udvindes til at operere i andre dele af vores infrastruktur.
Containerorkestreringssystemer er en måde at forene håndtering af arbejdsbyrder. De åbner døren til øget udviklingshastighed og forenkler infrastrukturstyringen, da alle ressourcer involveret i projektet styres af ét centraliseret system.
Figur 1: Infrastrukturprioriteter (pålidelighed, udviklerproduktivitet og effektivitet).
Cloud Management Platform-teamet hos Pinterest opdagede K8'er i 2017. I første halvdel af 2017 havde vi dokumenteret de fleste af vores produktionskapaciteter, inklusive API'et og alle vores webservere. Bagefter foretog vi en grundig vurdering af forskellige systemer til at orkestrere containerløsninger, bygge klynger og arbejde med dem. Mod slutningen af 2017 besluttede vi at bruge Kubernetes. Det var ret fleksibelt og bredt understøttet i udviklerfællesskabet.
Til dato har vi bygget vores egne cluster boot-værktøjer baseret på Kops og migreret eksisterende infrastrukturkomponenter såsom netværk, sikkerhed, metrikker, logning, identitetsstyring og trafik til Kubernetes. Vi implementerede også et arbejdsbelastningsmodelleringssystem for vores ressource, hvis kompleksitet er skjult for udviklere. Nu er vi fokuseret på at sikre klyngens stabilitet, skalere den og forbinde nye klienter.
Kubernetes: The Pinterest Way
At komme i gang med Kubernetes på Pinterest-skalaen som en platform, som vores ingeniører ville elske, kom med en masse udfordringer.
Som en stor virksomhed har vi investeret massivt i infrastrukturværktøjer. Eksempler omfatter sikkerhedsværktøjer, der håndterer certifikatbehandling og nøgledistribution, trafikkontrolkomponenter, serviceopdagelsessystemer, synlighedskomponenter og log- og metrikafsendelseskomponenter. Alt dette blev indsamlet af en grund: vi gik gennem den normale sti med forsøg og fejl, og derfor ønskede vi at integrere alt dette udstyr i den nye infrastruktur på Kubernetes i stedet for at genopfinde det gamle hjul på en ny platform. Denne tilgang forenklede overordnet migreringen, da al applikationsunderstøttelse allerede eksisterer og ikke skal oprettes fra bunden.
På den anden side er belastningsforudsigelsesmodellerne i selve Kubernetes (såsom implementeringer, jobs og Daemon-sæt) ikke nok til vores projekt. Disse brugervenlighedsproblemer er enorme barrierer for at flytte til Kubernetes. For eksempel har vi hørt tjenesteudviklere klage over manglende eller forkerte login-indstillinger. Vi stødte også på forkert brug af skabelonmotorer, da hundredvis af kopier blev oprettet med samme specifikation og opgave, hvilket resulterede i mareridtsfejlfindingsproblemer.
Det var også meget svært at vedligeholde forskellige versioner i samme klynge. Forestil dig kompleksiteten af kundesupport, hvis du skal arbejde samtidigt i flere versioner af det samme runtime-miljø med alle deres problemer, fejl og opdateringer.
Pinterest brugeregenskaber og controllere
For at gøre det nemmere for vores ingeniører at implementere Kubernetes og for at forenkle og fremskynde vores infrastruktur, har vi udviklet vores egne tilpassede ressourcedefinitioner (CRD'er).
CRD'er giver følgende funktionalitet:
- Kombination af forskellige indbyggede Kubernetes-ressourcer, så de fungerer som en enkelt arbejdsbyrde. For eksempel inkluderer PinterestService-ressourcen en implementering, en login-tjeneste og et konfigurationskort. Dette giver udviklere mulighed for ikke at bekymre sig om opsætning af DNS.
- Implementer nødvendig applikationssupport. Brugeren skal kun fokusere på containerspecifikationen i henhold til deres forretningslogik, mens CRD-controlleren implementerer alle de nødvendige init-containere, miljøvariabler og pod-specifikationer. Dette giver et fundamentalt andet niveau af komfort for udviklere.
- CRD-controllere administrerer også livscyklussen af native ressourcer og forbedrer fejlfindingstilgængeligheden. Dette omfatter afstemning af ønskede og faktiske specifikationer, opdatering af CRD-status og vedligeholdelse af hændelseslogfiler og mere. Uden CRD ville udviklere blive tvunget til at administrere flere ressourcer, hvilket kun ville øge sandsynligheden for fejl.
Her er et eksempel på en PinterestService og en intern ressource, der administreres af vores controller:
Som du kan se ovenfor, skal vi for at understøtte en brugerdefineret container integrere en init-container og flere tilføjelser for at give sikkerhed, synlighed og netværkstrafik. Derudover oprettede vi konfigurationskortskabeloner og implementerede understøttelse af PVC-skabeloner til batchjob, samt sporing af flere miljøvariabler for at spore identitet, ressourceforbrug og affaldsindsamling.
Det er svært at forestille sig, at udviklere ville ønske at skrive disse konfigurationsfiler i hånden uden CRD-understøttelse, endsige yderligere vedligeholde og fejlsøge konfigurationerne.
Workflow for applikationsimplementering
Billedet ovenfor viser, hvordan man implementerer en tilpasset Pinterest-ressource til en Kubernetes-klynge:
- Udviklere interagerer med vores Kubernetes-klynge gennem CLI og brugergrænsefladen.
- CLI/UI-værktøjerne henter workflow-konfigurationen YAML-filer og andre byggeegenskaber (samme versions-id) fra Artifactory og sender dem derefter til Job Submission Service. Dette trin sikrer, at kun produktionsversioner leveres til klyngen.
- JSS er en gateway til forskellige platforme, herunder Kubernetes. Her bliver brugeren autentificeret, kvoter udstedt og konfigurationen af vores CRD er delvist kontrolleret.
- Efter at have kontrolleret CRD'en på JSS-siden, sendes oplysningerne til k8s platformens API.
- Vores CRD-controller overvåger hændelser på alle brugerressourcer. Det konverterer CR'er til native k8s-ressourcer, tilføjer de nødvendige moduler, indstiller de passende miljøvariabler og udfører andet supportarbejde for at sikre, at containeriserede brugerapplikationer har tilstrækkelig infrastrukturunderstøttelse.
- CRD-controlleren sender derefter de modtagne data til Kubernetes API, så de kan behandles af planlæggeren og sættes i produktion.
Bemærk: Dette pre-release workflow af implementeringen blev oprettet til de første brugere af den nye k8s platform. Vi er i øjeblikket i gang med at forfine denne proces, så den kan integreres fuldt ud med vores nye CI/CD. Det betyder, at vi ikke kan fortælle dig alt relateret til Kubernetes. Vi ser frem til at dele vores erfaring og holdets fremskridt i denne retning i vores næste blogindlæg, "Opbygning af en CI/CD-platform til Pinterest."
Typer af særlige ressourcer
Baseret på Pinterests specifikke behov har vi udviklet følgende CRD'er, der passer til forskellige arbejdsgange:
- PinterestService er statsløse tjenester, der har kørt i lang tid. Mange af vores kernesystemer er baseret på et sæt af sådanne tjenester.
- PinterestJobSet modellerer fuld cyklus batchjob. Et almindeligt scenarie på Pinterest er, at flere job kører de samme containere parallelt, uanset andre lignende processer.
- PinterestCronJob er meget brugt i forbindelse med små periodiske belastninger. Dette er en indpakning til native cron-arbejde med Pinterest-understøttelsesmekanismer, der er ansvarlige for sikkerhed, trafik, logfiler og metrikker.
- PinterestDaemon inkluderer infrastruktur-dæmoner. Denne familie fortsætter med at vokse, efterhånden som vi tilføjer mere støtte til vores klynger.
- PinterestTrainingJob udvider til Tensorflow- og Pytorch-processer, hvilket giver det samme niveau af runtime-understøttelse som alle andre CRD'er. Da Pinterest aktivt bruger Tensorflow og andre maskinlæringssystemer, havde vi en grund til at bygge en separat CRD omkring dem.
Vi arbejder også på PinterestStatefulSet, som snart vil blive tilpasset til datavarehuse og andre stateful systemer.
Runtime support
Når en applikationspod kører på Kubernetes, modtager den automatisk et certifikat til at identificere sig selv. Dette certifikat bruges til at få adgang til hemmelig lagring eller til at kommunikere med andre tjenester via mTLS. I mellemtiden vil Container Init Configurator og Daemon downloade alle de nødvendige afhængigheder, før de kører den containeriserede applikation. Når alt er klar, vil trafiksidevognen og Daemon registrere modulets IP-adresse hos vores Zookeeper, så kunderne kan opdage det. Alt dette vil fungere, fordi netværksmodulet blev konfigureret før applikationen blev lanceret.
Ovenstående er typiske eksempler på runtime-understøttelse af arbejdsbelastninger. Andre typer arbejdsbelastninger kan kræve lidt anderledes support, men de kommer alle i form af sidevogne på pod-niveau, node-niveau eller virtuelle maskine-niveau Daemons. Vi sikrer, at alt dette er implementeret inden for administrationsinfrastrukturen og er konsistent på tværs af applikationer, hvilket i sidste ende reducerer byrden væsentligt med hensyn til teknisk arbejde og kundesupport.
Test og QA
Vi byggede en ende-til-ende-testpipeline oven på den eksisterende Kubernetes-testinfrastruktur. Disse test gælder for alle vores klynger. Vores pipeline gennemgik mange revisioner, før den blev en del af produktklyngen.
Ud over testsystemer har vi overvågnings- og alarmsystemer, der konstant overvåger status for systemkomponenter, ressourceforbrug og andre vigtige indikatorer, og som kun giver os besked, når menneskelig indgriben er nødvendig.
alternativer
Vi så på nogle alternativer til brugerdefinerede ressourcer, såsom mutationsadgangscontrollere og skabelonsystemer. Men de kommer alle med betydelige driftsmæssige udfordringer, så vi valgte CRD-ruten.
En mutationsadgangscontroller blev brugt til at introducere sidevogne, miljøvariabler og anden runtime-understøttelse. Det stod imidlertid over for forskellige problemer, såsom ressourcebinding og livscyklusstyring, hvor sådanne problemer ikke opstår i CRD.
Note: Skabelonsystemer såsom Helm-diagrammer er også meget brugt til at køre applikationer med lignende konfigurationer. Vores arbejdsapplikationer er dog for forskellige til at blive administreret ved hjælp af skabeloner. Også under kontinuerlig implementering vil der være for mange fejl ved brug af skabeloner.
Kommende arbejde
Vi har i øjeblikket at gøre med en blandet belastning på tværs af alle vores klynger. For at understøtte sådanne processer af forskellige typer og størrelser arbejder vi inden for følgende områder:
- En samling af klynger distribuerer store applikationer på tværs af forskellige klynger for skalerbarhed og stabilitet.
- Sikring af klyngestabilitet, skalerbarhed og synlighed for at skabe applikationsforbindelse og SLA'er.
- Håndtering af ressourcer og kvoter, så applikationer ikke kommer i konflikt med hinanden, og klyngens skala er kontrolleret fra vores side.
- En ny CI/CD-platform til understøttelse og implementering af applikationer på Kubernetes.
Kilde: www.habr.com