{"id":36484,"date":"2019-10-31T22:11:54","date_gmt":"2019-10-31T19:11:54","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kubernetes-priklyuchenie-dailymotion-sozdanie-infrastruktury-v-oblakah-on-premises\/"},"modified":"2019-10-31T22:11:54","modified_gmt":"2019-10-31T19:11:54","slug":"kubernetes-priklyuchenie-dailymotion-sozdanie-infrastruktury-v-oblakah-on-premises","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/kubernetes-priklyuchenie-dailymotion-sozdanie-infrastruktury-v-oblakah-on-premises","title":{"rendered":"Kubernetes-eventyret Dailymotion: opbygning af infrastruktur i skyen + on-premises","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Kubernetes-eventyret
\n
\nBem. overs.<\/b>: Dailymotion \u2014 en af verdens st\u00f8rste videotjenester og derfor en bem\u00e6rkelsesv\u00e6rdig bruger af Kubernetes. I dette materiale deler systemarkitekten David Donchez konklusionerne fra opbygningen af virksomhedens produktionsplatform baseret p\u00e5 K8s, som startede med en cloudinstallation i GKE og endte som en hybridl\u00f8sning, der muligg\u00f8r bedre svartider og reducerede infrastrukturomkostninger.<\/i><\/p>\n

N\u00e5r man tr\u00e6ffer beslutning om at ombygge den prim\u00e6re API Dailymotion<\/a><\/noindex> for tre \u00e5r siden, \u00f8nskede vi at udvikle en mere effektiv m\u00e5de at implementere applikationer og lette processerne i udvikling og produktion<\/a><\/noindex>. Til dette form\u00e5l besluttede vi at anvende en containerorkestreringsplatform og valgte naturligvis Kubernetes.<\/p>\n

Hvorfor b\u00f8r man opbygge sin egen platform baseret p\u00e5 Kubernetes?<\/a><\/noindex><\/p>\n

Produktionsniveau API p\u00e5 kort tid med Google Cloud<\/h2>\n

<\/p>\n

Sommeren 2016<\/p><\/blockquote>\n

\nFor tre \u00e5r siden, lige efter at Dailymotion blev k\u00f8bt af Vivendi<\/a><\/noindex>, fokuserede vores ingeni\u00f8rteams p\u00e5 et globalt m\u00e5l: At skabe et helt nyt Dailymotion produkt.<\/p>\n

Efter at have analyseret containere, l\u00f8sninger til orkestrering og vores tidligere erfaringer, var vi sikre p\u00e5, at Kubernetes var det rigtige valg. Nogle udviklere havde allerede kendskab til grundl\u00e6ggende koncepter og vidste, hvordan man brugte det, hvilket var en stor fordel for infrastrukturtransformationen.<\/p>\n

Fra et infrastruktursynspunkt kr\u00e6vedes der et kraftfuldt og fleksibelt system til implementering af nye typer cloud-native applikationer. Vi valgte at forblive i skyen i begyndelsen af vores rejse for fredeligt at bygge en s\u00e5 p\u00e5lidelig lokal platform som muligt. Vi besluttede at deploye vores applikationer med Google Kubernetes Engine, selvom vi vidste, at vi f\u00f8r eller senere ville g\u00e5 over til vores egne datacentre og anvende en hybrid strategi.<\/p>\n

Hvorfor valgte vi GKE?<\/h3>\n

\nVi traf dette valg hovedsageligt af tekniske \u00e5rsager. Desuden var der behov for hurtigt at levere infrastruktur, der im\u00f8dekom virksomhedens behov. Vi havde nogle krav til implementeringen af applikationer, s\u00e5som geografisk distribution, skalerbarhed og fejlfindingskapacitet.<\/p>\n

\"Kubernetes-eventyret
\nGKE-klynger i Dailymotion<\/i><\/p>\n

Da Dailymotion er en videotjeneste, der er tilg\u00e6ngelig over hele verden, \u00f8nskede vi meget at forbedre servicekvaliteten ved at reducere ventetiden (latency)<\/i>. Tidligere vores API<\/a><\/noindex> var tilg\u00e6ngelig kun i Paris, hvilket var suboptimalt. Vi \u00f8nskede at kunne placere applikationer ikke kun i Europa, men ogs\u00e5 i Asien og USA.<\/p>\n

Denne f\u00f8lsomhed over for forsinkelser bet\u00f8d, at vi m\u00e5tte arbejde grundigt p\u00e5 platformens netv\u00e6rksarkitektur. Mens de fleste cloud-tjenester tvang os til at oprette vores netv\u00e6rk i hver region og derefter forbinde dem via VPN eller en eller anden administreret tjeneste, gjorde Google Cloud det muligt at oprette et helt routabelt enkelt netv\u00e6rk, der d\u00e6kkede alle Google-regioner. Dette er et stort plus i forhold til drift og effektivitet af systemet.<\/p>\n

Desuden fungerer netv\u00e6rkstjenesterne og belastningsbalancerne fra Google Cloud fremragende. De giver muligheden for at bruge vilk\u00e5rlige offentlige IP-adresser fra hver region, og den fantastiske BGP-protokol h\u00e5ndterer resten (dvs. omdirigerer brugerne til den n\u00e6rmeste klynge). Det er tydeligt, at i tilf\u00e6lde af fejl vil trafikken automatisk g\u00e5 til en anden region uden menneskelig indblanding.<\/p>\n

\"Kubernetes-eventyret
\nOverv\u00e5gning af belastningsbalancering i Google<\/i><\/p>\n

Vores platform bruger ogs\u00e5 GPU'er aktivt. Google Cloud g\u00f8r det muligt at udnytte dem meget effektivt direkte i Kubernetes-klynger.<\/p>\n

I mellemtiden koncentrerede infrastrukturteamet sig prim\u00e6rt om den gamle stak, der var implementeret p\u00e5 fysiske servere. Derfor opfyldte brugen af en administreret tjeneste (herunder masterkomponenter fra Kubernetes) vores krav og gjorde det muligt at tr\u00e6ne teamene i at arbejde med lokale klynger.<\/p>\n

Som et resultat kunne vi begynde at modtage production-trafik p\u00e5 Google Cloud-infrastrukturen blot seks m\u00e5neder efter projektets start.<\/p>\n

Men p\u00e5 trods af en r\u00e6kke fordele medf\u00f8rer arbejdet med en cloud-udbyder visse omkostninger, der kan stige afh\u00e6ngigt af belastningen. Derfor analyserede vi omhyggeligt hver administreret tjeneste, vi brugte, for at planl\u00e6gge at implementere dem on-premises i fremtiden. Faktisk begyndte implementeringen af lokale klynger i slutningen af 2016, og en hybridstrategi blev ogs\u00e5 initieret dengang.<\/p>\n

Lancering af Dailymotion's lokale containerorkestreringsplatform<\/h2>\n

<\/p>\n

Efter\u00e5ret 2016<\/p><\/blockquote>\n

\nUnder betingelser, hvor hele stakken var klar til produktion, mens arbejdet med API'et fortsatte<\/a><\/noindex>, der var tid til at fokusere p\u00e5 regionale klynger.<\/p>\n

P\u00e5 det tidspunkt s\u00e5 brugerne mere end 3 milliarder videoer hver m\u00e5ned. Selvf\u00f8lgelig havde vi allerede haft vores egen omfattende Content Delivery Network i flere \u00e5r. Vi \u00f8nskede at udnytte denne situation og implementere Kubernetes-klynger i de eksisterende datacentre.<\/p>\n

Dailymotion's infrastruktur bestod af mere end 2.500 servere i seks datacentre. Alle konfigureres ved hj\u00e6lp af Saltstack. Vi begyndte at forberede alle n\u00f8dvendige opskrifter til at oprette master- og worker-noder samt etcd-klyngen.<\/p>\n

\"Kubernetes-eventyret
\n<\/p>\n

Netv\u00e6rksdelen<\/h3>\n

\nVores netv\u00e6rk er fuldt routable. Hver server annoncerer sin IP i netv\u00e6rket ved hj\u00e6lp af Exabgp. Vi sammenlignede flere netv\u00e6rksplugins, og den eneste, der opfyldte alle behov (p\u00e5 grund af den L3-tilgang, der blev anvendt), var Calico<\/a><\/noindex>. Den passede perfekt ind i den eksisterende netv\u00e6rksmodel for infrastrukturen.<\/p>\n

Da vi \u00f8nskede at anvende alle de eksisterende infrastrukturelementer, var det f\u00f8rst og fremmest n\u00f8dvendigt at forst\u00e5 vores egen netv\u00e6rksv\u00e6rkt\u00f8j (anvendt p\u00e5 alle servere): at bruge det til at annoncere IP-adresseomr\u00e5der i netv\u00e6rket med Kubernetes-noder. Vi lod Calico tildele IP-adresser til pods, men brugte ikke det til BGP-sessioner p\u00e5 netv\u00e6rksudstyret hverken dengang eller nu. Faktisk h\u00e5ndterer Exabgp routingen, som annoncerer de undernet, der bruges af Calico. Dette g\u00f8r det muligt for os at tilg\u00e5 enhver pod fra det interne netv\u00e6rk (is\u00e6r fra belastningsbalancerne).<\/p>\n

S\u00e5dan h\u00e5ndterer vi ingress-trafikken<\/h3>\n

\nFor at omdirigere indkommende anmodninger til den rigtige tjeneste besluttede vi at bruge Ingress Controller p\u00e5 grund af dens integration med Kubernetes-ingress-resurserne.<\/p>\n

For tre \u00e5r siden var nginx-ingress-controller den mest modne controller: Nginx havde v\u00e6ret brugt i lang tid og var kendt for sin stabilitet og ydeevne.<\/p>\n

I vores system valgte vi at placere controllerne p\u00e5 dedikerede 10-gigabit blade-servere. Hver controller blev tilsluttet endpoint'en kube-apiserver for den tilsvarende klynge. P\u00e5 disse servere blev Exabgp ogs\u00e5 brugt til at annoncere offentlige eller private IP-adresser. Topologien i vores netv\u00e6rk muligg\u00f8r brug af BGP fra disse controllere til at routinge al trafik direkte til pods uden at bruge en service s\u00e5som NodePort. Denne tilgang hj\u00e6lper med at undg\u00e5 horisontal trafik mellem noderne og \u00f8ger effektiviteten.<\/p>\n

\"Kubernetes-eventyret
\nTrafikstr\u00f8m fra internettet til pods<\/i><\/p>\n

Nu hvor vi har f\u00e5et styr p\u00e5 vores hybride platform, kan vi dykke dybere ned i selve migreringsprocessen af trafikken.<\/p>\n

Migration af trafik fra Google Cloud til Dailymotion-infrastrukturen<\/h2>\n

<\/p>\n

Efter\u00e5r 2018<\/p><\/blockquote>\n

\nEfter n\u00e6sten to \u00e5rs udvikling, testning og konfiguration har vi endelig f\u00e5et en komplet Kubernetes-stack klar til at tage imod en del af trafikken.<\/p>\n

\"Kubernetes-eventyret
\n
\nDen aktuelle rute-strategi er ganske simpel, men tilfredsstiller behovene. Udover offentlige IP'er (i Google Cloud og Dailymotion) anvendes AWS Route 53 til at definere politikker og omdirigere brugerne til den klynge, vi v\u00e6lger.<\/p>\n

\"Kubernetes-eventyret
\nEksempel p\u00e5 en rute-politik med brug af Route 53<\/i><\/p>\n

Fra Google Cloud er det enkelt, da vi bruger en enkelt IP for alle klynger, og brugeren bliver omdirigeret til den n\u00e6rmeste GKE-klynge. For vores klynger er teknologien anderledes, da deres IP'er er forskellige.<\/p>\n

Under migreringen str\u00e6bte vi efter at omdirigere regionale foresp\u00f8rgsler til de relevante klynger og vurderede fordelene ved denne tilgang.<\/p>\n

Da vores GKE-klynger er konfigureret til automatisk skalering ved hj\u00e6lp af Custom Metrics, \u00f8ger\/reducerer de kapaciteten afh\u00e6ngigt af den indkommende trafik.<\/p>\n

I normal drift sendes al regional trafik til den lokale klynge, mens GKE fungerer som backup i tilf\u00e6lde af problemer (health-checks udf\u00f8res af Route 53).<\/p>\n

\u2026<\/h2>\n

\nI fremtiden \u00f8nsker vi at automatisere routingpolitikkerne fuldst\u00e6ndigt for at opn\u00e5 en autonom hybridstrategi, der konstant forbedrer tilg\u00e6ngeligheden for brugerne. N\u00e5r det kommer til fordelene: omkostningerne til skyen er blevet betydeligt reduceret, og vi har endda v\u00e6ret i stand til at reducere API-responstiden. Vi har tillid til den resulterende cloud-platform og er klar til at omdirigere mere trafik til den efter behov.<\/p>\n

P.S. fra overs\u00e6tteren<\/h2>\n

\nDu kunne ogs\u00e5 v\u00e6re interesseret i en anden nylig Dailymotion-udgivelse om Kubernetes. Den omhandler implementering af applikationer med Helm p\u00e5 flere Kubernetes-klynger, og den blev offentliggjort<\/a><\/noindex> for omkring en m\u00e5ned siden.<\/p>\n

L\u00e6s ogs\u00e5 p\u00e5 vores blog:<\/p>\n