{"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\/sv\/blog\/administrirovanie\/kubernetes-priklyuchenie-dailymotion-sozdanie-infrastruktury-v-oblakah-on-premises","title":{"rendered":"Kubernetes-\u00e4ventyret Dailymotion: att bygga infrastruktur i molnet + on-premises","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Kubernetes-\u00e4ventyret
\n
\nObs. \u00f6vers.<\/b>: Dailymotion \u2014 en av v\u00e4rldens st\u00f6rsta videohotellstj\u00e4nster och en framtr\u00e4dande anv\u00e4ndare av Kubernetes. I detta material delar systemarkitekten David Donchez med sig av resultaten fr\u00e5n f\u00f6retagets produktion plattform som skapades p\u00e5 K8s, vilken b\u00f6rjade som en molninstallation i GKE och avslutades som en hybridl\u00f6sning, vilket m\u00f6jliggjorde b\u00e4ttre svarstider och minskade infrastrukuturskostnader.<\/i><\/p>\n

N\u00e4r vi beslutade oss f\u00f6r att bygga om huvud-API:et Dailymotion<\/a><\/noindex> f\u00f6r tre \u00e5r sedan, ville vi utveckla ett mer effektivt s\u00e4tt att distribuera applikationer och f\u00f6renkla processerna i utveckling och produktion.<\/a><\/noindex>F\u00f6r detta \u00e4ndam\u00e5l valde vi att anv\u00e4nda en containerorkestreringsplattform och valde naturligtvis Kubernetes.<\/p>\n

Varf\u00f6r skapa en egen plattform baserad p\u00e5 Kubernetes?<\/a><\/noindex><\/p>\n

Produktion-API p\u00e5 kort tid med hj\u00e4lp av Google Cloud<\/h2>\n

<\/p>\n

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

\nTre \u00e5r sedan, direkt efter k\u00f6pet av Dailymotion av Vivendi<\/a><\/noindex>, fokuserade v\u00e5ra ingenj\u00f6rsteam p\u00e5 ett enda globalt m\u00e5l: att skapa en helt ny produkt f\u00f6r Dailymotion.<\/p>\n

Efter att ha analyserat containrar, orkestreringsl\u00f6sningar och v\u00e5r tidigare erfarenhet var vi \u00f6vertygade om att Kubernetes var r\u00e4tt val. En del av v\u00e5ra utvecklare hade redan f\u00f6rst\u00e5else f\u00f6r de grundl\u00e4ggande koncepten och visste hur man anv\u00e4nder det, vilket var en stor f\u00f6rdel f\u00f6r den infrastrukturella transformationen.<\/p>\n

Fr\u00e5n infrastrukturen sett kr\u00e4vdes ett kraftfullt och flexibelt system f\u00f6r att k\u00f6ra nya typer av molnbaserade applikationer. Vi valde att stanna kvar i molnet i b\u00f6rjan av v\u00e5r resa f\u00f6r att snabbt bygga en s\u00e5 p\u00e5litlig lokal plattform som m\u00f6jligt. Vi best\u00e4mde oss f\u00f6r att distribuera v\u00e5ra applikationer med Google Kubernetes Engine, \u00e4ven om vi visste att vi f\u00f6rr eller senare skulle flytta till v\u00e5ra egna datacenter och till\u00e4mpa en hybridstrategi.<\/p>\n

Varf\u00f6r valde vi GKE?<\/h3>\n

\nVi gjorde detta val fr\u00e4mst av tekniska sk\u00e4l. Dessutom kr\u00e4vdes det att vi snabbt skulle kunna tillhandah\u00e5lla infrastruktur som svarade mot f\u00f6retagets behov. Vi hade vissa krav p\u00e5 applikationsdisposition, s\u00e5som geografisk spridning, skalbarhet och felresistens.<\/p>\n

\"Kubernetes-\u00e4ventyret
\nGKE-kluster p\u00e5 Dailymotion<\/i><\/p>\n

Eftersom Dailymotion \u00e4r en videoplattform tillg\u00e4nglig \u00f6ver hela v\u00e4rlden ville vi verkligen f\u00f6rb\u00e4ttra servicen genom att minska v\u00e4ntetiderna. (latency)<\/i>. Tidigare v\u00e5r API<\/a><\/noindex> var tillg\u00e4nglig endast i Paris, vilket var suboptimalt. Det skulle vara bra att kunna placera applikationer inte bara i Europa utan \u00e4ven i Asien och USA.<\/p>\n

Denna k\u00e4nslighet f\u00f6r f\u00f6rdr\u00f6jningar innebar att vi var tvungna att arbeta h\u00e5rt med plattformens n\u00e4tverksarkitektur. Medan de flesta molntj\u00e4nster kr\u00e4vde att man skapade sitt eget n\u00e4tverk i varje region och sedan kopplade ihop dem via VPN eller en s\u00e5dan hanterad tj\u00e4nst, till\u00e4t Google Cloud att skapa ett helt routbart enhetligt n\u00e4tverk som t\u00e4cker alla Google-regioner. Detta \u00e4r en stor f\u00f6rdel n\u00e4r det g\u00e4ller drifts\u00e4ttning och systemets effektivitet.<\/p>\n

Dessutom fungerar n\u00e4tverkstj\u00e4nster och lastbalanserare fr\u00e5n Google Cloud utm\u00e4rkt. De l\u00e5ter helt enkelt anv\u00e4nda valfria offentliga IP-adresser fr\u00e5n varje region, och den fantastiska BGP-protokoll ser efter allt annat (d.v.s. dirigerar anv\u00e4ndare till n\u00e4rmaste kluster). Det \u00e4r uppenbart att vid ett fel kommer trafiken automatiskt att fl\u00f6da till en annan region utan m\u00e4nsklig inblandning.<\/p>\n

\"Kubernetes-\u00e4ventyret
\n\u00d6vervakning av lastbalansering i Google<\/i><\/p>\n

V\u00e5r plattform anv\u00e4nder ocks\u00e5 grafiska processorer aktivt. Google Cloud m\u00f6jligg\u00f6r en mycket effektiv anv\u00e4ndning av dem direkt i Kubernetes-kluster.<\/p>\n

Under tiden koncentrerade sig infrastrukturteamet huvudsakligen p\u00e5 den gamla stacken som var distribuerad p\u00e5 fysiska servrar. Det var d\u00e4rf\u00f6r anv\u00e4ndandet av hanterade tj\u00e4nster (inklusive Kubernetes-m\u00e4starkomponenterna) uppfyllde v\u00e5ra krav och gjorde det m\u00f6jligt att utbilda teamen i att arbeta med lokala kluster.<\/p>\n

Som ett resultat kunde vi b\u00f6rja ta emot produktions trafik p\u00e5 Google Clouds infrastruktur bara sex m\u00e5nader efter att arbetet inleddes.<\/p>\n

Men trots en rad f\u00f6rdelar \u00e4r arbetet med en molnleverant\u00f6r f\u00f6renat med vissa kostnader som kan \u00f6ka beroende p\u00e5 belastningen. Det \u00e4r d\u00e4rf\u00f6r vi noga analyserade varje hanterad tj\u00e4nst vi anv\u00e4nde, med avsikt att i framtiden implementera dem lokalt. Faktum \u00e4r att implementeringen av lokala kluster b\u00f6rjade i slutet av 2016, och en hybridstrategi initierades vid samma tidpunkt.<\/p>\n

Lansering av Dailymotions lokala plattform f\u00f6r containerorkestrering<\/h2>\n

<\/p>\n

H\u00f6sten 2016<\/p><\/blockquote>\n

\nUnder de omst\u00e4ndigheter n\u00e4r hela stacken var redo f\u00f6r produktion och arbetet med API:n p\u00e5gick<\/a><\/noindex>, det var en tid f\u00f6r att fokusera p\u00e5 regionala kluster.<\/p>\n

Vid den tiden visade anv\u00e4ndarna varje m\u00e5nad mer \u00e4n 3 miljarder videor. Sj\u00e4lvklart hade vi redan haft ett omfattande Content Delivery Network i drift i flera \u00e5r. Vi ville utnyttja detta och rulla ut Kubernetes-kluster i de befintliga datacenter.<\/p>\n

Dailymotion-infrastrukturen bestod av mer \u00e4n 2 500 servrar i sex datacenter. Alla konfigureras med Saltstack. Vi b\u00f6rjade f\u00f6rbereda alla n\u00f6dv\u00e4ndiga recept f\u00f6r att skapa master- och worker-noder, samt etcd-kluster.<\/p>\n

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

N\u00e4tverksdel<\/h3>\n

\nV\u00e5rt n\u00e4tverk \u00e4r helt routbart. Varje server annonserar sin IP i n\u00e4tverket med hj\u00e4lp av Exabgp. Vi j\u00e4mf\u00f6rde flera n\u00e4tverksplugin och det enda som uppfyllde alla krav (p\u00e5 grund av den anv\u00e4nda L3-approachen) var Calico<\/a><\/noindex>. Den passade perfekt in i den befintliga n\u00e4tverksmodellen f\u00f6r infrastrukturen.<\/p>\n

Eftersom vi ville anv\u00e4nda alla tillg\u00e4ngliga infrastrukturkomponenter var det f\u00f6rst och fr\u00e4mst n\u00f6dv\u00e4ndigt att reda ut v\u00e5r egen n\u00e4tverksverktyg (som anv\u00e4nds p\u00e5 alla servrar): att anv\u00e4nda den f\u00f6r att annonsera IP-adressintervall i n\u00e4tverket med Kubernetes-noder. Vi till\u00e4t Calico att tilldela IP-adresser till poddar, men vi har inte anv\u00e4nt den och anv\u00e4nder den fortfarande inte f\u00f6r BGP-sessioner p\u00e5 n\u00e4tverksutrustningen. Faktum \u00e4r att routing sk\u00f6ts av Exabgp, som annonserar subn\u00e4t som anv\u00e4nds av Calico. Detta g\u00f6r att vi kan n\u00e5 varje pod fr\u00e5n det interna n\u00e4tverket (och specifikt fr\u00e5n lastbalanserare).<\/p>\n

Hur vi hanterar ingress-trafik<\/h3>\n

\nF\u00f6r att omdirigera inkommande f\u00f6rfr\u00e5gningar till r\u00e4tt tj\u00e4nst beslutades det att anv\u00e4nda Ingress Controller p\u00e5 grund av dess integrering med ingress-resurser i Kubernetes.<\/p>\n

F\u00f6r tre \u00e5r sedan var nginx-ingress-controller den mest mogna kontrollern: Nginx hade anv\u00e4nts l\u00e4nge och var k\u00e4nt f\u00f6r sin stabilitet och prestanda.<\/p>\n

I v\u00e5rt system beslutade vi att placera kontrollerna p\u00e5 dedikerade 10-gigabit blade-servrar. Varje kontroller ansl\u00f6t sig till endpointen kube-apiserver f\u00f6r den aktuella klustret. P\u00e5 dessa servrar anv\u00e4ndes ocks\u00e5 Exabgp f\u00f6r att annonsera offentliga eller privata IP-adresser. Topologin i v\u00e5rt n\u00e4tverk m\u00f6jligg\u00f6r anv\u00e4ndning av BGP fr\u00e5n dessa kontroller f\u00f6r att routa all trafik direkt till poddar utan att anv\u00e4nda tj\u00e4nster som NodePort. Denna metod hj\u00e4lper till att undvika horisontell trafik mellan noder och \u00f6kar effektiviteten.<\/p>\n

\"Kubernetes-\u00e4ventyret
\nTrafiken som fl\u00f6dar fr\u00e5n internet till poddar<\/i><\/p>\n

Nu n\u00e4r vi har f\u00f6rst\u00e5tt v\u00e5r hybridplattform kan vi f\u00f6rdjupa oss i sj\u00e4lva trafikmigreringsprocessen.<\/p>\n

Trafikmigration fr\u00e5n Google Cloud till Dailymotion-infrastrukturen<\/h2>\n

<\/p>\n

H\u00f6sten 2018<\/p><\/blockquote>\n

\nEfter n\u00e4stan tv\u00e5 \u00e5rs skapande, testande och konfigurering har vi \u00e4ntligen f\u00e5tt en fullst\u00e4ndig Kubernetes-stack redo att ta emot en del av trafiken.<\/p>\n

\"Kubernetes-\u00e4ventyret
\n
\nDen nuvarande routingstrategin \u00e4r ganska enkel, men tillfredsst\u00e4ller fullt ut behoven. F\u00f6rutom offentliga IP-adresser (i Google Cloud och Dailymotion) anv\u00e4nds AWS Route 53 f\u00f6r att definiera policyer och omdirigera anv\u00e4ndarna till klustret vi v\u00e4ljer.<\/p>\n

\"Kubernetes-\u00e4ventyret
\nExempel p\u00e5 routingpolicy med Route 53<\/i><\/p>\n

Fr\u00e5n Google Cloud \u00e4r det enkelt, eftersom vi anv\u00e4nder en enhetlig IP f\u00f6r alla kluster, och anv\u00e4ndaren omdirigeras till det n\u00e4rmaste GKE-klustret. F\u00f6r v\u00e5ra kluster \u00e4r teknologin annorlunda, eftersom deras IP-adresser skiljer sig.<\/p>\n

Under migreringen str\u00e4vade vi efter att omdirigera regionala f\u00f6rfr\u00e5gningar till motsvarande kluster och v\u00e4rderade f\u00f6rdelarna med detta tillv\u00e4gag\u00e5ngss\u00e4tt.<\/p>\n

Eftersom v\u00e5ra GKE-kluster \u00e4r konfigurerade f\u00f6r automatisk skalning med hj\u00e4lp av Custom Metrics, \u00f6kar\/minskar de kapaciteten beroende p\u00e5 inkommande trafik.<\/p>\n

I normall\u00e4ge dirigeras all regional trafik till den lokala klustret, medan GKE fungerar som en reserv vid eventuella problem (h\u00e4lsokontroller genomf\u00f6rs av Route 53).<\/p>\n

\u2026<\/h2>\n

\nI framtiden vill vi helt automatisera routingpolitiken f\u00f6r att uppn\u00e5 en autonom hybridstrategi som st\u00e4ndigt f\u00f6rb\u00e4ttrar tillg\u00e4ngligheten f\u00f6r anv\u00e4ndarna. F\u00f6rdelarna \u00e4r att kostnaderna f\u00f6r molnet har minskat avsev\u00e4rt och vi har \u00e4ven lyckats korta ner API-responstiderna. Vi litar p\u00e5 den resulterande molnplattformen och \u00e4r redo att vid behov omdirigera mer trafik till den.<\/p>\n

P.S. fr\u00e5n \u00f6vers\u00e4ttaren<\/h2>\n

\nKanske \u00e4r du ocks\u00e5 intresserad av en annan nyligen publicerad artikel p\u00e5 Dailymotion om Kubernetes. Den handlar om att distribuera applikationer med Helm p\u00e5 flera Kubernetes-kluster och publicerats<\/a><\/noindex> f\u00f6r ungef\u00e4r en m\u00e5nad sedan.<\/p>\n

L\u00e4s \u00e4ven i v\u00e5r blogg:<\/p>\n