Under åren har Pinterests 300 miljoner användare skapat mer än 200 miljarder pins på mer än 4 miljarder brädor. För att betjäna denna armé av användare och stora innehållsbas har portalen utvecklat tusentals tjänster, allt från mikrotjänster som kan hanteras av ett fåtal processorer, till gigantiska monoliter som körs på en hel flotta av virtuella maskiner. Och så kom ögonblicket då företagets blick föll på k8:or. Varför såg "kuben" bra ut på Pinterest? Du kommer att lära dig om detta från vår översättning av en ny artikel från .
Så, hundratals miljoner användare och hundratals miljarder pins. För att betjäna denna armé av användare och stora innehållsbas har vi utvecklat tusentals tjänster, allt från mikrotjänster som kan hanteras av ett fåtal processorer, till gigantiska monoliter som körs på hela flottor av virtuella maskiner. Dessutom har vi en mängd olika ramverk som också kan kräva CPU, minne eller I/O-åtkomst.
Utvecklingsteamet står inför ett antal utmaningar när de underhåller denna zoo av verktyg:
- Det finns inget enhetligt sätt för ingenjörer att driva en produktionsmiljö. Statslösa tjänster, Stateful tjänster och projekt under aktiv utveckling bygger på helt andra teknikstaplar. Detta ledde till skapandet av en hel utbildningskurs för ingenjörer och komplicerar också arbetet för vårt infrastrukturteam allvarligt.
- Utvecklare med sin egen flotta av virtuella maskiner skapar en enorm börda för interna administratörer. Som ett resultat tar sådana enkla operationer som att uppdatera OS eller AMI veckor och månader. Detta leder till ökad arbetsbelastning i till synes absolut vardagliga situationer.
- Svårigheter att skapa globala infrastrukturhanteringsverktyg ovanpå befintliga lösningar. Situationen kompliceras ytterligare av det faktum att det inte är lätt att hitta ägare till virtuella maskiner. Det vill säga vi vet inte om denna kapacitet säkert kan utvinnas för att fungera i andra delar av vår infrastruktur.
Containerorkestreringssystem är ett sätt att förena arbetsbelastningshantering. De öppnar dörren till ökad utvecklingshastighet och förenklar infrastrukturhanteringen, eftersom alla resurser som är involverade i projektet hanteras av ett centraliserat system.
Figur 1: Infrastrukturprioriteringar (tillförlitlighet, utvecklarproduktivitet och effektivitet).
Cloud Management Platform-teamet på Pinterest upptäckte K8s 2017. Under första halvåret 2017 hade vi dokumenterat de flesta av våra produktionsmöjligheter, inklusive API:et och alla våra webbservrar. Efteråt gjorde vi en grundlig utvärdering av olika system för att orkestrera containerlösningar, bygga kluster och arbeta med dem. Mot slutet av 2017 bestämde vi oss för att använda Kubernetes. Det var ganska flexibelt och fick ett brett stöd i utvecklargemenskapen.
Hittills har vi byggt våra egna klusterstartverktyg baserade på Kops och migrerat befintliga infrastrukturkomponenter som nätverk, säkerhet, mätvärden, loggning, identitetshantering och trafik till Kubernetes. Vi implementerade också ett arbetsbelastningsmodelleringssystem för vår resurs, vars komplexitet är dold för utvecklare. Nu är vi fokuserade på att säkerställa klustrets stabilitet, skala det och koppla ihop nya klienter.
Kubernetes: The Pinterest Way
Att komma igång med Kubernetes i Pinterests skala som en plattform som våra ingenjörer skulle älska kom med många utmaningar.
Som ett stort företag har vi investerat mycket i infrastrukturverktyg. Exempel inkluderar säkerhetsverktyg som hanterar certifikatbearbetning och nyckeldistribution, trafikkontrollkomponenter, tjänsteupptäcktssystem, synlighetskomponenter och komponenter för utsändning av logg och mätvärden. Allt detta samlades in av en anledning: vi gick igenom den normala vägen med försök och misstag, och därför ville vi integrera all denna utrustning i den nya infrastrukturen på Kubernetes istället för att återuppfinna det gamla hjulet på en ny plattform. Detta tillvägagångssätt förenklade överlag migreringen, eftersom allt applikationsstöd redan finns och inte behöver skapas från början.
Å andra sidan räcker inte lastprognosmodellerna i själva Kubernetes (såsom distributioner, jobb och Daemon-uppsättningar) för vårt projekt. Dessa användbarhetsproblem är enorma hinder för att flytta till Kubernetes. Vi har till exempel hört tjänsteutvecklare klaga på saknade eller felaktiga inloggningsinställningar. Vi stötte också på felaktig användning av mallmotorer, när hundratals kopior skapades med samma specifikation och uppgift, vilket resulterade i mardrömsfelsökningsproblem.
Det var också mycket svårt att behålla olika versioner i samma kluster. Föreställ dig komplexiteten i kundsupport om du behöver arbeta samtidigt i flera versioner av samma runtime-miljö, med alla deras problem, buggar och uppdateringar.
Pinterest användaregenskaper och kontroller
För att göra det enklare för våra ingenjörer att implementera Kubernetes, och för att förenkla och snabba upp vår infrastruktur, har vi utvecklat våra egna anpassade resursdefinitioner (CRD).
CRD:er tillhandahåller följande funktionalitet:
- Kombinera olika inbyggda Kubernetes-resurser så att de fungerar som en enda arbetsbelastning. Till exempel inkluderar PinterestService-resursen en distribution, en inloggningstjänst och en konfigurationskarta. Detta tillåter utvecklare att inte oroa sig för att ställa in DNS.
- Implementera nödvändigt applikationsstöd. Användaren behöver bara fokusera på behållarspecifikationen enligt sin affärslogik, medan CRD-styrenheten implementerar alla nödvändiga init-behållare, miljövariabler och pod-specifikationer. Detta ger en helt annan nivå av komfort för utvecklare.
- CRD-styrenheter hanterar också livscykeln för inbyggda resurser och förbättrar felsökningstillgängligheten. Detta inkluderar att stämma av önskade och faktiska specifikationer, uppdatering av CRD-status och underhåll av händelseloggar med mera. Utan CRD skulle utvecklare tvingas hantera flera resurser, vilket bara skulle öka sannolikheten för fel.
Här är ett exempel på en PinterestService och en intern resurs som hanteras av vår kontrollant:
Som du kan se ovan, för att stödja en anpassad behållare måste vi integrera en init-behållare och flera tillägg för att ge säkerhet, synlighet och nätverkstrafik. Dessutom skapade vi konfigurationskartmallar och implementerade stöd för PVC-mallar för batchjobb, samt spårning av flera miljövariabler för att spåra identitet, resursförbrukning och sophämtning.
Det är svårt att föreställa sig att utvecklare skulle vilja skriva dessa konfigurationsfiler för hand utan CRD-stöd, än mindre underhålla och felsöka konfigurationerna ytterligare.
Arbetsflöde för applikationsdistribution
Bilden ovan visar hur man distribuerar en anpassad Pinterest-resurs till ett Kubernetes-kluster:
- Utvecklare interagerar med vårt Kubernetes-kluster genom CLI och användargränssnitt.
- CLI/UI-verktygen hämtar YAML-filerna för arbetsflödeskonfigurationen och andra byggegenskaper (samma versions-ID) från Artifactory och skickar dem sedan till Job Submission Service. Detta steg säkerställer att endast produktionsversioner levereras till klustret.
- JSS är en gateway för olika plattformar, inklusive Kubernetes. Här autentiseras användaren, kvoter utfärdas och konfigurationen av vårt CRD kontrolleras delvis.
- Efter att ha kontrollerat CRD på JSS-sidan skickas informationen till k8s-plattformens API.
- Vår CRD-kontroller övervakar händelser på alla användarresurser. Den konverterar CR:er till inbyggda k8s-resurser, lägger till de nödvändiga modulerna, ställer in lämpliga miljövariabler och utför annat supportarbete för att säkerställa att användarapplikationer i containers har tillräckligt med infrastrukturstöd.
- CRD-styrenheten skickar sedan mottagen data till Kubernetes API så att den kan bearbetas av schemaläggaren och sättas i produktion.
Notera: Det här arbetsflödet för utgåvan av distributionen skapades för de första användarna av den nya k8s-plattformen. Vi håller för närvarande på att förfina denna process för att fullt ut integreras med vår nya CI/CD. Det betyder att vi inte kan berätta allt som har med Kubernetes att göra. Vi ser fram emot att dela vår erfarenhet och teamets framsteg i denna riktning i vårt nästa blogginlägg, "Att bygga en CI/CD-plattform för Pinterest."
Typer av specialresurser
Baserat på Pinterests specifika behov har vi utvecklat följande CRD:er för att passa olika arbetsflöden:
- PinterestService är tillståndslösa tjänster som har varit igång länge. Många av våra kärnsystem är baserade på en uppsättning sådana tjänster.
- PinterestJobSet modellerar helcykelbatchjobb. Ett vanligt scenario på Pinterest är att flera jobb kör samma behållare parallellt, oavsett andra liknande processer.
- PinterestCronJob används ofta i samband med små periodiska belastningar. Detta är ett omslag för inbyggt cron-arbete med Pinterest-stödmekanismer som är ansvariga för säkerhet, trafik, loggar och mätvärden.
- PinterestDaemon inkluderar infrastruktur Daemons. Den här familjen fortsätter att växa när vi lägger till mer stöd till våra kluster.
- PinterestTrainingJob sträcker sig till Tensorflow- och Pytorch-processer, vilket ger samma nivå av runtime-stöd som alla andra CRD:er. Eftersom Pinterest aktivt använder Tensorflow och andra maskininlärningssystem hade vi en anledning att bygga en separat CRD runt dem.
Vi arbetar även med PinterestStatefulSet, som snart kommer att anpassas för datalager och andra stateful system.
Runtime support
När en programpod körs på Kubernetes får den automatiskt ett certifikat för att identifiera sig själv. Detta certifikat används för att komma åt hemlig lagring eller för att kommunicera med andra tjänster via mTLS. Under tiden kommer Container Init Configurator och Daemon att ladda ner alla nödvändiga beroenden innan den containeriserade applikationen körs. När allt är klart kommer trafiksidovagnen och Daemon att registrera modulens IP-adress hos vår Zookeeper så att kunderna kan upptäcka den. Allt detta kommer att fungera eftersom nätverksmodulen konfigurerades innan applikationen startades.
Ovanstående är typiska exempel på runtime-stöd för arbetsbelastningar. Andra typer av arbetsbelastningar kan kräva något annorlunda stöd, men de kommer alla i form av sidovagnar på podnivå, nodnivå eller virtuell maskinnivå Daemons. Vi säkerställer att allt detta distribueras inom förvaltningsinfrastrukturen och är konsekvent över applikationer, vilket i slutändan avsevärt minskar bördan när det gäller tekniskt arbete och kundsupport.
Testning och QA
Vi byggde en end-to-end-testpipeline ovanpå den befintliga Kubernetes-testinfrastrukturen. Dessa tester gäller alla våra kluster. Vår pipeline gick igenom många revisioner innan den blev en del av produktklustret.
Utöver testsystem har vi övervaknings- och varningssystem som ständigt övervakar status för systemkomponenter, resursförbrukning och andra viktiga indikatorer, och meddelar oss endast när mänskligt ingripande är nödvändigt.
alternativ
Vi tittade på några alternativ till anpassade resurser, såsom kontrollanter för mutationsåtkomst och mallsystem. Men de kommer alla med betydande operativa utmaningar, så vi valde CRD-rutten.
En mutationstillträdeskontroller användes för att introducera sidovagnar, miljövariabler och annat körtidsstöd. Den stod dock inför olika problem, såsom resursbindning och livscykelhantering, där sådana problem inte uppstår i CRD.
Notera: Mallsystem som Helm-diagram används också i stor utsträckning för att köra applikationer med liknande konfigurationer. Våra arbetsapplikationer är dock för olika för att kunna hanteras med mallar. Även under kontinuerlig distribution kommer det att bli för många fel när mallar används.
Kommande arbete
Vi har för närvarande att göra med en blandad belastning över alla våra kluster. För att stödja sådana processer av olika typer och storlekar arbetar vi inom följande områden:
- En samling kluster distribuerar stora applikationer över olika kluster för skalbarhet och stabilitet.
- Säkerställer klusterstabilitet, skalbarhet och synlighet för att skapa applikationsanslutning och SLA.
- Hantera resurser och kvoter så att applikationer inte kommer i konflikt med varandra och omfattningen av klustret kontrolleras från vår sida.
- En ny CI/CD-plattform för att stödja och distribuera applikationer på Kubernetes.
Källa: will.com