Kubernetes eventyr Dailymotion: lage infrastruktur i skyene + lokalt

Kubernetes eventyr Dailymotion: lage infrastruktur i skyene + lokalt

Merk. overs.: Dailymotion er en av verdens største videovertstjenester og derfor en bemerkelsesverdig Kubernetes-bruker. I dette materialet deler systemarkitekten David Donchez resultatene av å lage selskapets produksjonsplattform basert på K8s, som begynte med en skyinstallasjon i GKE og endte som en hybridløsning, som muliggjorde bedre responstider og besparelser på infrastrukturkostnader.

Bestemmer seg for å gjenoppbygge Core API Dailymotion for tre år siden ønsket vi å utvikle en mer effektiv måte å være vert for applikasjoner på og gjøre det enklere prosesser i utvikling og produksjon. Til dette formålet bestemte vi oss for å bruke en containerorkestreringsplattform og valgte naturligvis Kubernetes.

Hvorfor er det verdt å bygge din egen plattform basert på Kubernetes?

Produksjonsnivå API på kort tid ved å bruke Google Cloud

Sommeren 2016

For tre år siden, umiddelbart etter at Dailymotion ble kjøpt av Vivendi, våre ingeniørteam er fokusert på ett globalt mål: å skape et helt nytt Dailymotion-produkt.

Basert på vår analyse av containere, orkestreringsløsninger og vår tidligere erfaring, er vi overbevist om at Kubernetes er det riktige valget. Noen utviklere hadde allerede en forståelse av de grunnleggende konseptene og visste hvordan de skulle bruke det, noe som var en stor fordel for infrastrukturtransformasjonen.

Fra et infrastrukturperspektiv var det nødvendig med et kraftig og fleksibelt system for å være vert for nye typer skybaserte applikasjoner. Vi valgte å holde oss i skyen i begynnelsen av reisen vår, slik at vi kunne bygge den mest robuste lokale plattformen med ro i sinnet. Vi bestemte oss for å distribuere applikasjonene våre ved hjelp av Google Kubernetes Engine, selv om vi visste at vi før eller siden ville flytte til våre egne datasentre og bruke en hybridstrategi.

Hvorfor valgte du GKE?

Vi tok dette valget hovedsakelig av tekniske årsaker. I tillegg var det nødvendig å raskt skaffe infrastruktur som dekker selskapets forretningsbehov. Vi hadde noen krav til hosting av applikasjoner, som geografisk fordeling, skalerbarhet og feiltoleranse.

Kubernetes eventyr Dailymotion: lage infrastruktur i skyene + lokalt
GKE-klynger i Dailymotion

Siden Dailymotion er en videoplattform tilgjengelig over hele verden, ønsket vi virkelig å forbedre kvaliteten på tjenesten ved å redusere ventetiden (ventetid). Tidligere vårt API var bare tilgjengelig i Paris, noe som var suboptimalt. Jeg ønsket å være vertskap for applikasjoner ikke bare i Europa, men også i Asia og USA.

Denne følsomheten for latens betydde at det måtte gjøres seriøst arbeid med plattformens nettverksarkitektur. Mens de fleste skytjenester tvang deg til å opprette ditt eget nettverk i hver region og deretter koble dem til via en VPN eller en slags administrert tjeneste, tillot Google Cloud deg å lage et fullt rutebart enkeltnettverk som dekker alle Google-regioner. Dette er et stort pluss med tanke på drift og effektivitet av systemet.

I tillegg gjør nettverkstjenester og lastbalansere fra Google Cloud en utmerket jobb. De lar deg ganske enkelt bruke vilkårlige offentlige IP-adresser fra hver region, og den fantastiske BGP-protokollen tar seg av resten (dvs. omdirigerer brukere til nærmeste klynge). Åpenbart, i tilfelle en feil, vil trafikken automatisk gå til en annen region uten menneskelig innblanding.

Kubernetes eventyr Dailymotion: lage infrastruktur i skyene + lokalt
Overvåker Google Load Balancing

Plattformen vår bruker også mye GPUer. Google Cloud lar deg bruke dem veldig effektivt direkte i Kubernetes-klynger.

På den tiden var infrastrukturteamet først og fremst fokusert på den eldre stabelen som ble distribuert på fysiske servere. Det er grunnen til at bruk av en administrert tjeneste (inkludert Kubernetes-mastere) oppfylte kravene våre og tillot oss å trene team til å jobbe med lokale klynger.

Som et resultat kunne vi begynne å motta produksjonstrafikk på Google Cloud-infrastrukturen bare 6 måneder etter at arbeidet startet.

Men til tross for en rekke fordeler, er det å jobbe med en skyleverandør forbundet med visse kostnader, som kan øke avhengig av belastningen. Det er derfor vi nøye analyserte hver administrerte tjeneste vi brukte, i håp om å implementere dem lokalt i fremtiden. Faktisk startet implementeringen av lokale klynger i slutten av 2016 og hybridstrategien ble igangsatt samtidig.

Lansering av lokal containerorkestreringsplattform Dailymotion

Høsten 2016

I forhold da hele stabelen var klar for produksjon, og arbeid på API fortsatte, var det på tide å konsentrere seg om regionale klynger.

På den tiden så brukerne mer enn 3 milliarder videoer hver måned. Selvfølgelig har vi hatt vårt eget omfattende innholdsleveringsnettverk i mange år. Vi ønsket å dra nytte av denne omstendigheten og distribuere Kubernetes-klynger i eksisterende datasentre.

Dailymotions infrastruktur besto av mer enn 2,5 tusen servere fordelt på seks datasentre. Alle er konfigurert med Saltstack. Vi begynte å forberede alle nødvendige oppskrifter for å lage master- og arbeidernoder, samt en etcd-klynge.

Kubernetes eventyr Dailymotion: lage infrastruktur i skyene + lokalt

Nettverksdel

Nettverket vårt er fullstendig rutet. Hver server annonserer sin IP på nettverket ved hjelp av Exabgp. Vi sammenlignet flere nettverksplugins, og den eneste som tilfredsstilte alle behovene (på grunn av L3-tilnærmingen som ble brukt) var Calico. Den passer perfekt inn i den eksisterende nettverksinfrastrukturmodellen.

Siden vi ønsket å bruke alle tilgjengelige infrastrukturelementer, var det første vi måtte gjøre å finne ut vårt hjemmelagde nettverksverktøy (brukt på alle servere): bruk det til å annonsere IP-adresseområder på nettverket med Kubernetes-noder. Vi tillot Calico å tildele IP-adresser til pods, men brukte det ikke og brukte det fortsatt ikke til BGP-økter på nettverksutstyr. Ruting håndteres faktisk av Exabgp, som annonserer subnettene som brukes av Calico. Dette lar oss nå enhver pod fra det interne nettverket (og spesielt fra lastbalansere).

Hvordan vi håndterer inngående trafikk

For å omdirigere innkommende forespørsler til ønsket tjeneste, ble det besluttet å bruke Ingress Controller på grunn av integrasjonen med Kubernetes inngående ressurser.

For tre år siden var nginx-ingress-controller den mest modne kontrolleren: Nginx hadde eksistert i lang tid og var kjent for sin stabilitet og ytelse.

I systemet vårt bestemte vi oss for å plassere kontrollerene på dedikerte 10-Gigabit bladservere. Hver kontroller ble koblet til kube-apiserver-endepunktet til den tilsvarende klyngen. Disse serverne brukte også Exabgp til å annonsere offentlige eller private IP-adresser. Nettverkstopologien vår lar oss bruke BGP fra disse kontrollerene for å rute all trafikk direkte til podene uten å bruke en tjeneste som NodePort. Denne tilnærmingen bidrar til å unngå horisontal trafikk mellom noder og forbedrer effektiviteten.

Kubernetes eventyr Dailymotion: lage infrastruktur i skyene + lokalt
Trafikkbevegelse fra Internett til pods

Nå som vi forstår hybridplattformen vår, kan vi gå dypere inn i selve trafikkmigrasjonsprosessen.

Migrering av trafikk fra Google Cloud til Dailymotion-infrastruktur

Høsten 2018

Etter nesten to år med bygging, testing og tuning har vi endelig en full Kubernetes-stabel klar til å ta imot litt trafikk.

Kubernetes eventyr Dailymotion: lage infrastruktur i skyene + lokalt

Den nåværende rutingstrategien er ganske enkel, men tilstrekkelig til å møte behovene. I tillegg til offentlige IP-er (på Google Cloud og Dailymotion), brukes AWS Route 53 til å angi retningslinjer og omdirigere brukere til den klyngen vi velger.

Kubernetes eventyr Dailymotion: lage infrastruktur i skyene + lokalt
Eksempel på rutingpolicy som bruker rute 53

Med Google Cloud er dette enkelt siden vi deler én enkelt IP på tvers av alle klynger og brukeren blir omdirigert til nærmeste GKE-klynge. For våre klynger er teknologien annerledes, siden deres IP-er er forskjellige.

Under migreringen forsøkte vi å omdirigere regionale forespørsler til de riktige klyngene og evaluerte fordelene med denne tilnærmingen.

Fordi GKE-klyngene våre er konfigurert til å automatisk skalere ved hjelp av egendefinerte beregninger, skalerer de opp/ned basert på innkommende trafikk.

I normal modus blir all regional trafikk dirigert til den lokale klyngen, og GKE fungerer som reserve ved problemer (helsesjekker utføres av rute 53).

...

I fremtiden ønsker vi å fullautomatisere rutingpolicyer for å oppnå en autonom hybridstrategi som kontinuerlig forbedrer tilgjengeligheten for brukere. På plussiden har skykostnadene blitt betydelig redusert og API-responstidene har til og med blitt redusert. Vi stoler på den resulterende skyplattformen og er klare til å omdirigere mer trafikk til den om nødvendig.

PS fra oversetter

Du kan også være interessert i et annet nylig Dailymotion-innlegg om Kubernetes. Den er dedikert til distribusjon av applikasjoner med Helm på mange Kubernetes-klynger og ble publisert for omtrent en måned siden.

Les også på bloggen vår:

Kilde: www.habr.com

Legg til en kommentar