I løpet av årene har Pinterests 300 millioner brukere laget mer enn 200 milliarder pins på mer enn 4 milliarder brett. For å betjene denne hæren av brukere og enorme innholdsbase, har portalen utviklet tusenvis av tjenester, alt fra mikrotjenester som kan håndteres av noen få CPUer, til gigantiske monolitter som kjører på en hel flåte av virtuelle maskiner. Og så kom øyeblikket da selskapets øyne falt på k8s. Hvorfor så "kuben" bra ut på Pinterest? Du vil lære om dette fra vår oversettelse av en nylig artikkel fra .
Så hundrevis av millioner brukere og hundrevis av milliarder pins. For å betjene denne hæren av brukere og enorme innholdsbase, har vi utviklet tusenvis av tjenester, alt fra mikrotjenester som kan håndteres av noen få CPUer, til gigantiske monolitter som kjører på hele flåter av virtuelle maskiner. I tillegg har vi en rekke rammeverk som også kan kreve CPU, minne eller I/O-tilgang.
Ved å vedlikeholde denne dyrehagen av verktøy, står utviklingsteamet overfor en rekke utfordringer:
- Det er ingen enhetlig måte for ingeniører å drive et produksjonsmiljø på. Statsløse tjenester, Stateful tjenester og prosjekter under aktiv utvikling er basert på helt andre teknologistabler. Dette førte til opprettelsen av et helt kurs for ingeniører, og kompliserer også arbeidet til vårt infrastrukturteam alvorlig.
- Utviklere med sin egen flåte av virtuelle maskiner skaper en enorm byrde for interne administratorer. Som et resultat tar slike enkle operasjoner som å oppdatere OS eller AMI uker og måneder. Dette fører til økt arbeidsbelastning i tilsynelatende absolutt hverdagslige situasjoner.
- Vanskeligheter med å lage globale infrastrukturstyringsverktøy på toppen av eksisterende løsninger. Situasjonen kompliseres ytterligere av det faktum at det ikke er lett å finne eierne av virtuelle maskiner. Det vil si at vi ikke vet om denne kapasiteten trygt kan utvinnes for å operere i andre deler av vår infrastruktur.
Containerorkestreringssystemer er en måte å forene administrasjon av arbeidsbelastninger på. De åpner døren for økt utviklingshastighet og forenkler infrastrukturforvaltningen, siden alle ressursene som er involvert i prosjektet administreres av ett sentralisert system.
Figur 1: Infrastrukturprioriteringer (pålitelighet, utviklerproduktivitet og effektivitet).
Cloud Management Platform-teamet på Pinterest oppdaget K8s i 2017. I første halvdel av 2017 hadde vi dokumentert det meste av produksjonsmulighetene våre, inkludert API og alle webserverne våre. I etterkant har vi gjennomført en grundig vurdering av ulike systemer for å orkestrere containerløsninger, bygge klynger og jobbe med dem. Mot slutten av 2017 bestemte vi oss for å bruke Kubernetes. Det var ganske fleksibelt og bredt støttet i utviklermiljøet.
Til dags dato har vi bygget våre egne klyngeoppstartsverktøy basert på Kops og migrert eksisterende infrastrukturkomponenter som nettverk, sikkerhet, metrikk, logging, identitetsadministrasjon og trafikk til Kubernetes. Vi implementerte også et arbeidsbelastningsmodelleringssystem for ressursen vår, hvis kompleksitet er skjult for utviklere. Nå er vi fokusert på å sikre stabiliteten til klyngen, skalere den og koble til nye klienter.
Kubernetes: The Pinterest Way
Å komme i gang med Kubernetes på Pinterest-skalaen som en plattform som ingeniørene våre ville elske kom med mange utfordringer.
Som et stort selskap har vi investert mye i infrastrukturverktøy. Eksempler inkluderer sikkerhetsverktøy som håndterer sertifikatbehandling og nøkkeldistribusjon, trafikkkontrollkomponenter, tjenesteoppdagelsessystemer, synlighetskomponenter og logg- og beregningskomponenter. Alt dette ble samlet inn av en grunn: vi gikk gjennom den vanlige veien med prøving og feiling, og derfor ønsket vi å integrere alt dette utstyret i den nye infrastrukturen på Kubernetes i stedet for å finne opp det gamle hjulet på nytt på en ny plattform. Denne tilnærmingen forenklet generelt migreringen, siden all applikasjonsstøtte allerede eksisterer og ikke trenger å lages fra bunnen av.
På den annen side er ikke belastningsprognosemodellene i selve Kubernetes (som utrullinger, jobber og Daemon-sett) nok for prosjektet vårt. Disse brukervennlighetsproblemene er enorme barrierer for å flytte til Kubernetes. For eksempel har vi hørt tjenesteutviklere klage over manglende eller feilaktige påloggingsinnstillinger. Vi møtte også feil bruk av malmotorer, da hundrevis av kopier ble laget med samme spesifikasjon og oppgave, noe som resulterte i marerittfeilsøkingsproblemer.
Det var også svært vanskelig å opprettholde forskjellige versjoner i samme klynge. Se for deg kompleksiteten til kundestøtte hvis du trenger å jobbe samtidig i flere versjoner av det samme kjøremiljøet, med alle deres problemer, feil og oppdateringer.
Pinterest brukeregenskaper og kontroller
For å gjøre det enklere for våre ingeniører å implementere Kubernetes, og for å forenkle og øke hastigheten på infrastrukturen vår, har vi utviklet våre egne tilpassede ressursdefinisjoner (CRDs).
CRD-er gir følgende funksjonalitet:
- Kombinere ulike opprinnelige Kubernetes-ressurser slik at de fungerer som én enkelt arbeidsbelastning. For eksempel inkluderer PinterestService-ressursen en distribusjon, en påloggingstjeneste og et konfigurasjonskart. Dette lar utviklere ikke bekymre seg for å sette opp DNS.
- Implementere nødvendig applikasjonsstøtte. Brukeren trenger kun å fokusere på containerspesifikasjonen i henhold til deres forretningslogikk, mens CRD-kontrolleren implementerer alle nødvendige init-beholdere, miljøvariabler og pod-spesifikasjoner. Dette gir et fundamentalt annet komfortnivå for utviklere.
- CRD-kontrollere administrerer også livssyklusen til opprinnelige ressurser og forbedrer feilsøkingstilgjengeligheten. Dette inkluderer avstemming av ønskede og faktiske spesifikasjoner, oppdatering av CRD-status og vedlikehold av hendelseslogger og mer. Uten CRD ville utviklere blitt tvunget til å administrere flere ressurser, noe som bare ville øke sannsynligheten for feil.
Her er et eksempel på en PinterestService og en intern ressurs som administreres av vår kontroller:
Som du kan se ovenfor, for å støtte en tilpasset beholder må vi integrere en init-beholder og flere tillegg for å gi sikkerhet, synlighet og nettverkstrafikk. I tillegg laget vi konfigurasjonskartmaler og implementerte støtte for PVC-maler for batchjobber, samt sporing av flere miljøvariabler for å spore identitet, ressursforbruk og søppelinnsamling.
Det er vanskelig å forestille seg at utviklere vil skrive disse konfigurasjonsfilene for hånd uten CRD-støtte, enn si å vedlikeholde og feilsøke konfigurasjonene ytterligere.
Arbeidsflyt for applikasjonsdistribusjon
Bildet ovenfor viser hvordan du distribuerer en egendefinert Pinterest-ressurs til en Kubernetes-klynge:
- Utviklere samhandler med Kubernetes-klyngen vår gjennom CLI og brukergrensesnitt.
- CLI/UI-verktøyene henter YAML-filene for arbeidsflytkonfigurasjon og andre byggeegenskaper (samme versjons-ID) fra Artifactory og sender dem deretter til Job Submission Service. Dette trinnet sikrer at kun produksjonsversjoner leveres til klyngen.
- JSS er en inngangsport for ulike plattformer, inkludert Kubernetes. Her blir brukeren autentisert, kvoter utstedt og konfigurasjonen av vår CRD blir delvis kontrollert.
- Etter å ha sjekket CRD på JSS-siden, sendes informasjonen til k8s-plattformens API.
- Vår CRD-kontroller overvåker hendelser på alle brukerressurser. Den konverterer CR-er til innfødte k8s-ressurser, legger til de nødvendige modulene, setter de riktige miljøvariablene og utfører annet støttearbeid for å sikre at containeriserte brukerapplikasjoner har tilstrekkelig infrastrukturstøtte.
- CRD-kontrolleren sender deretter de mottatte dataene til Kubernetes API slik at de kan behandles av planleggeren og settes i produksjon.
Note: Denne pre-release arbeidsflyten av distribusjonen ble opprettet for de første brukerne av den nye k8s-plattformen. Vi er for tiden i ferd med å forbedre denne prosessen for å integreres fullt ut med vår nye CI/CD. Dette betyr at vi ikke kan fortelle deg alt relatert til Kubernetes. Vi ser frem til å dele vår erfaring og teamets fremgang i denne retningen i vårt neste blogginnlegg, "Bygge en CI/CD-plattform for Pinterest."
Typer spesielle ressurser
Basert på Pinterests spesifikke behov har vi utviklet følgende CRD-er for å passe til ulike arbeidsflyter:
- PinterestService er statsløse tjenester som har kjørt i lang tid. Mange av våre kjernesystemer er basert på et sett med slike tjenester.
- PinterestJobSet modellerer batchjobber med full syklus. Et vanlig scenario på Pinterest er at flere jobber kjører de samme beholderne parallelt, uavhengig av andre lignende prosesser.
- PinterestCronJob er mye brukt i forbindelse med små periodiske belastninger. Dette er en innpakning for innfødt cron-arbeid med Pinterest-støttemekanismer som er ansvarlige for sikkerhet, trafikk, logger og beregninger.
- PinterestDaemon inkluderer infrastrukturdemoner. Denne familien fortsetter å vokse etter hvert som vi legger til mer støtte til klyngene våre.
- PinterestTrainingJob strekker seg til Tensorflow- og Pytorch-prosesser, og gir samme nivå av kjøretidsstøtte som alle andre CRD-er. Siden Pinterest aktivt bruker Tensorflow og andre maskinlæringssystemer, hadde vi en grunn til å bygge en egen CRD rundt dem.
Vi jobber også med PinterestStatefulSet, som snart skal tilpasses datavarehus og andre stateful systemer.
Kjøretidsstøtte
Når en applikasjonspod kjører på Kubernetes, mottar den automatisk et sertifikat for å identifisere seg selv. Dette sertifikatet brukes til å få tilgang til hemmelig lagring eller for å kommunisere med andre tjenester via mTLS. I mellomtiden vil Container Init Configurator og Daemon laste ned alle nødvendige avhengigheter før du kjører den containeriserte applikasjonen. Når alt er klart, vil trafikksidevognen og Daemon registrere modulens IP-adresse hos vår Zookeeper slik at kundene kan oppdage den. Alt dette vil fungere fordi nettverksmodulen ble konfigurert før applikasjonen ble lansert.
Ovennevnte er typiske eksempler på kjøretidsstøtte for arbeidsbelastninger. Andre typer arbeidsbelastninger kan kreve litt annen støtte, men de kommer alle i form av sidevogner på pod-nivå, node-nivå eller virtuelle maskin-nivå Daemons. Vi sikrer at alt dette er distribuert innenfor administrasjonsinfrastrukturen og er konsistent på tvers av applikasjoner, noe som til slutt reduserer byrden betydelig når det gjelder teknisk arbeid og kundestøtte.
Testing og QA
Vi bygde en ende-til-ende-testpipeline på toppen av den eksisterende Kubernetes-testinfrastrukturen. Disse testene gjelder for alle våre klynger. Vår pipeline gikk gjennom mange revisjoner før den ble en del av produktklyngen.
I tillegg til testsystemer har vi overvåkings- og varslingssystemer som kontinuerlig overvåker status for systemkomponenter, ressursforbruk og andre viktige indikatorer, og varsler oss kun når menneskelig inngripen er nødvendig.
alternativer
Vi så på noen alternativer til tilpassede ressurser, for eksempel mutasjonstilgangskontrollere og malsystemer. Imidlertid har de alle betydelige operasjonelle utfordringer, så vi valgte CRD-ruten.
En mutasjonsadgangskontroller ble brukt til å introdusere sidevogner, miljøvariabler og annen kjøretidsstøtte. Den sto imidlertid overfor ulike problemer, som ressursbinding og livssyklusstyring, der slike problemer ikke oppstår i CRD.
Merk: Malsystemer som Helm-diagram er også mye brukt for å kjøre applikasjoner med lignende konfigurasjoner. Arbeidsapplikasjonene våre er imidlertid for forskjellige til å kunne administreres ved hjelp av maler. Også under kontinuerlig distribusjon vil det være for mange feil ved bruk av maler.
Kommende arbeid
Vi har for tiden å gjøre med en blandet belastning på tvers av alle våre klynger. For å støtte slike prosesser av ulike typer og størrelser jobber vi innenfor følgende områder:
- En samling av klynger distribuerer store applikasjoner på tvers av forskjellige klynger for skalerbarhet og stabilitet.
- Sikre klyngestabilitet, skalerbarhet og synlighet for å skape applikasjonstilkobling og SLAer.
- Forvalte ressurser og kvoter slik at applikasjoner ikke kommer i konflikt med hverandre, og omfanget av klyngen kontrolleres fra vår side.
- En ny CI/CD-plattform for å støtte og distribuere applikasjoner på Kubernetes.
Kilde: www.habr.com