Kubernetes eventyr Dailymotion: skabe infrastruktur i skyerne + on-premises

Kubernetes eventyr Dailymotion: skabe infrastruktur i skyerne + on-premises

Bemærk. overs.: Dailymotion er en af ​​verdens største videohostingtjenester og derfor en bemærkelsesværdig Kubernetes-bruger. I dette materiale deler systemarkitekten David Donchez resultaterne af at skabe virksomhedens produktionsplatform baseret på K8s, som begyndte med en cloud-installation i GKE og endte som en hybridløsning, der gav mulighed for bedre svartider og besparelser på infrastrukturomkostninger.

Beslutter at genopbygge Core API Dailymotion for tre år siden ønskede vi at udvikle en mere effektiv måde at hoste applikationer på og gøre det nemmere processer i udvikling og produktion. Til dette formål besluttede vi at bruge en containerorkestreringsplatform og valgte naturligvis Kubernetes.

Hvorfor er det værd at bygge din egen platform baseret på Kubernetes?

API på produktionsniveau på ingen tid ved hjælp af Google Cloud

Sommer 2016

For tre år siden, umiddelbart efter Dailymotion blev købt af Vivendi, er vores ingeniørteam fokuseret på ét globalt mål: at skabe et helt nyt Dailymotion-produkt.

Baseret på vores analyse af containere, orkestreringsløsninger og vores tidligere erfaringer er vi overbeviste om, at Kubernetes er det rigtige valg. Nogle udviklere havde allerede en forståelse af de grundlæggende begreber og vidste, hvordan de skulle bruge det, hvilket var en stor fordel for infrastrukturtransformationen.

Fra et infrastrukturperspektiv var et kraftfuldt og fleksibelt system påkrævet til at være vært for nye typer cloud-native applikationer. Vi valgte at blive i skyen i begyndelsen af ​​vores rejse, så vi med ro i sindet kunne bygge den mest robuste on-premise platform som muligt. Vi besluttede at implementere vores applikationer ved hjælp af Google Kubernetes Engine, selvom vi vidste, at vi før eller siden ville flytte til vores egne datacentre og anvende en hybridstrategi.

Hvorfor valgte du GKE?

Vi traf dette valg primært af tekniske årsager. Derudover var det nødvendigt hurtigt at levere infrastruktur, der imødekommer virksomhedens forretningsbehov. Vi havde nogle krav til hosting af applikationer, såsom geografisk fordeling, skalerbarhed og fejltolerance.

Kubernetes eventyr Dailymotion: skabe infrastruktur i skyerne + on-premises
GKE-klynger i Dailymotion

Da Dailymotion er en videoplatform tilgængelig over hele verden, ønskede vi virkelig at forbedre kvaliteten af ​​tjenesten ved at reducere ventetiden (reaktionstid). Tidligere vores API var kun tilgængelig i Paris, hvilket var suboptimalt. Jeg ønskede at være i stand til at være vært for applikationer ikke kun i Europa, men også i Asien og USA.

Denne følsomhed over for latency betød, at der skulle arbejdes seriøst med platformens netværksarkitektur. Mens de fleste cloud-tjenester tvang dig til at oprette dit eget netværk i hver region og derefter forbinde dem via en VPN eller en form for administreret tjeneste, tillod Google Cloud dig at oprette et fuldt routbart enkelt netværk, der dækker alle Google-regioner. Dette er et stort plus i forhold til drift og effektivitet af systemet.

Derudover gør netværkstjenester og load balancere fra Google Cloud et fremragende stykke arbejde. De giver dig simpelthen mulighed for at bruge vilkårlige offentlige IP-adresser fra hver region, og den vidunderlige BGP-protokol tager sig af resten (dvs. omdirigerer brugere til den nærmeste klynge). I tilfælde af en fejl vil trafikken naturligvis automatisk gå til en anden region uden menneskelig indblanding.

Kubernetes eventyr Dailymotion: skabe infrastruktur i skyerne + on-premises
Overvågning af Google Load Balancing

Vores platform gør også stor brug af GPU'er. Google Cloud giver dig mulighed for at bruge dem meget effektivt direkte i Kubernetes-klynger.

På det tidspunkt var infrastrukturteamet primært fokuseret på den gamle stak, der blev installeret på fysiske servere. Det er derfor, at brugen af ​​en administreret tjeneste (inklusive Kubernetes-mastere) opfyldte vores krav og gjorde det muligt for os at træne teams til at arbejde med lokale klynger.

Som et resultat var vi i stand til at begynde at modtage produktionstrafik på Google Cloud-infrastrukturen kun 6 måneder efter arbejdets start.

Men på trods af en række fordele er arbejdet med en cloud-udbyder forbundet med visse omkostninger, som kan stige afhængigt af belastningen. Derfor analyserede vi omhyggeligt hver administreret service, vi brugte, i håb om at implementere dem på stedet i fremtiden. Faktisk begyndte implementeringen af ​​lokale klynger i slutningen af ​​2016, og hybridstrategien blev samtidig igangsat.

Lancering af lokal containerorkestreringsplatform Dailymotion

Efterår 2016

Under forhold, hvor hele stakken var klar til produktion, og arbejde på API fortsatte, var det tid til at koncentrere sig om regionale klynger.

På det tidspunkt så brugerne mere end 3 milliarder videoer hver måned. Selvfølgelig har vi haft vores eget omfattende Content Delivery Network i mange år. Vi ønskede at drage fordel af denne omstændighed og implementere Kubernetes-klynger i eksisterende datacentre.

Dailymotions infrastruktur bestod af mere end 2,5 tusinde servere fordelt på seks datacentre. Alle er konfigureret ved hjælp af Saltstack. Vi begyndte at forberede alle de nødvendige opskrifter til at skabe master- og arbejderknudepunkter samt en etcd-klynge.

Kubernetes eventyr Dailymotion: skabe infrastruktur i skyerne + on-premises

Netværksdel

Vores netværk er fuldstændig dirigeret. Hver server annoncerer sin IP på netværket ved hjælp af Exabgp. Vi sammenlignede flere netværksplugins, og den eneste, der opfyldte alle behovene (på grund af den anvendte L3-tilgang) var Calico. Det passer perfekt ind i den eksisterende netværksinfrastrukturmodel.

Da vi ønskede at bruge alle de tilgængelige infrastrukturelementer, var den første ting, vi skulle gøre, at finde ud af vores hjemmelavede netværksværktøj (brugt på alle servere): Brug det til at annoncere IP-adresseområder på netværket med Kubernetes-noder. Vi tillod Calico at tildele IP-adresser til pods, men vi brugte det ikke og brugte det stadig ikke til BGP-sessioner på netværksudstyr. Faktisk håndteres routing af Exabgp, som annoncerer de undernet, der bruges af Calico. Dette giver os mulighed for at nå enhver pod fra det interne netværk (og især fra load balancers).

Hvordan vi styrer indgående trafik

For at omdirigere indgående anmodninger til den ønskede tjeneste, blev det besluttet at bruge Ingress Controller på grund af dets integration med Kubernetes indgående ressourcer.

For tre år siden var nginx-ingress-controller den mest modne controller: Nginx havde eksisteret i lang tid og var kendt for sin stabilitet og ydeevne.

I vores system besluttede vi at placere controllerne på dedikerede 10-Gigabit blade-servere. Hver controller var forbundet til kube-apiserver-slutpunktet for den tilsvarende klynge. Disse servere brugte også Exabgp til at annoncere offentlige eller private IP-adresser. Vores netværkstopologi giver os mulighed for at bruge BGP fra disse controllere til at dirigere al trafik direkte til pods uden at bruge en tjeneste som NodePort. Denne tilgang hjælper med at undgå horisontal trafik mellem knudepunkter og forbedrer effektiviteten.

Kubernetes eventyr Dailymotion: skabe infrastruktur i skyerne + on-premises
Trafikbevægelse fra internettet til pods

Nu hvor vi forstår vores hybride platform, kan vi dykke dybere ned i selve trafikmigreringsprocessen.

Migrering af trafik fra Google Cloud til Dailymotion-infrastruktur

Efterår 2018

Efter næsten to års bygning, test og tuning har vi endelig en fuld Kubernetes-stack klar til at acceptere noget trafik.

Kubernetes eventyr Dailymotion: skabe infrastruktur i skyerne + on-premises

Den nuværende routingstrategi er ret enkel, men tilstrækkelig til at opfylde behovene. Ud over offentlige IP'er (på Google Cloud og Dailymotion) bruges AWS Route 53 til at indstille politikker og omdirigere brugere til den klynge, vi vælger.

Kubernetes eventyr Dailymotion: skabe infrastruktur i skyerne + on-premises
Eksempel på routingpolitik ved hjælp af rute 53

Med Google Cloud er dette nemt, da vi deler en enkelt IP på tværs af alle klynger, og brugeren omdirigeres til den nærmeste GKE-klynge. For vores klynger er teknologien anderledes, da deres IP'er er forskellige.

Under migreringen forsøgte vi at omdirigere regionale anmodninger til de relevante klynger og evaluerede fordelene ved denne tilgang.

Fordi vores GKE-klynger er konfigureret til at autoskalere ved hjælp af tilpassede metrics, skalerer de op/ned baseret på indgående trafik.

I normal tilstand ledes al regional trafik til den lokale klynge, og GKE fungerer som reserve i tilfælde af problemer (sundhedstjek udføres af rute 53).

...

I fremtiden ønsker vi fuldt ud at automatisere routingpolitikker for at opnå en autonom hybridstrategi, der løbende forbedrer tilgængeligheden for brugerne. På den positive side er cloud-omkostningerne reduceret betydeligt, og API-svartider er endda blevet reduceret. Vi stoler på den resulterende cloud-platform og er klar til at omdirigere mere trafik til den, hvis det er nødvendigt.

PS fra oversætteren

Du er måske også interesseret i et andet nyligt Dailymotion-indlæg om Kubernetes. Det er dedikeret til udrulning af applikationer med Helm på mange Kubernetes-klynger og blev offentliggjort omkring en måned siden.

Læs også på vores blog:

Kilde: www.habr.com

Tilføj en kommentar