Kubernetes avontuur Dailymotion: skep infrastruktuur in die wolke + op die perseel

Kubernetes avontuur Dailymotion: skep infrastruktuur in die wolke + op die perseel

Let wel. vertaal.: Dailymotion is een van die wêreld se grootste videogasheerdienste en daarom 'n noemenswaardige Kubernetes-gebruiker. In hierdie materiaal deel die stelselargitek David Donchez die resultate van die skep van die maatskappy se produksieplatform gebaseer op K8s, wat begin het met 'n wolkinstallasie in GKE en geëindig het as 'n hibriede oplossing, wat voorsiening gemaak het vir beter reaksietye en besparings op infrastruktuurkoste.

Besluit om die Core API te herbou Dailymotion drie jaar gelede wou ons 'n meer doeltreffende manier ontwikkel om toepassings aan te bied en dit makliker te maak prosesse in ontwikkeling en produksie. Vir hierdie doel het ons besluit om 'n houer-orkestrasieplatform te gebruik en het natuurlik Kubernetes gekies.

Waarom is dit die moeite werd om u eie platform op Kubernetes te bou?

Produksievlak-API in 'n japtrap met Google Cloud

Somer 2016

Drie jaar gelede, onmiddellik nadat Dailymotion deur Vivendi, is ons ingenieurspanne gefokus op een globale doelwit: om 'n heeltemal nuwe Dailymotion-produk te skep.

Gebaseer op ons ontleding van houers, orkestrasie-oplossings en ons vorige ervaring, is ons oortuig dat Kubernetes die regte keuse is. Sommige ontwikkelaars het reeds 'n begrip van die basiese konsepte gehad en geweet hoe om dit te gebruik, wat 'n groot voordeel vir die transformasie van infrastruktuur was.

Vanuit 'n infrastruktuurperspektief was 'n kragtige en buigsame stelsel nodig om nuwe soorte wolk-inheemse toepassings te huisves. Ons het gekies om aan die begin van ons reis in die wolk te bly sodat ons met gemoedsrus die mees robuuste platform op die perseel moontlik kon bou. Ons het besluit om ons toepassings met behulp van Google Kubernetes Engine te ontplooi, hoewel ons geweet het dat ons vroeër of later na ons eie datasentrums sou beweeg en 'n hibriede strategie sou toepas.

Hoekom het jy GKE gekies?

Ons het hierdie keuse hoofsaaklik om tegniese redes gemaak. Boonop was dit nodig om vinnig infrastruktuur te verskaf wat aan die maatskappy se besigheidsbehoeftes voldoen. Ons het sekere vereistes gehad vir die aanbieding van toepassings, soos geografiese verspreiding, skaalbaarheid en fouttoleransie.

Kubernetes avontuur Dailymotion: skep infrastruktuur in die wolke + op die perseel
GKE-klusters in Dailymotion

Aangesien Dailymotion 'n videoplatform is wat wêreldwyd beskikbaar is, wou ons regtig die kwaliteit van die diens verbeter deur wagtyd te verminder (latency)... Voorheen ons API was slegs in Parys beskikbaar, wat suboptimaal was. Ek wou aansoeke kan aanbied nie net in Europa nie, maar ook in Asië en die VSA.

Hierdie sensitiwiteit vir latensie het beteken dat ernstige werk aan die platform se netwerkargitektuur gedoen moes word. Terwyl die meeste wolkdienste jou gedwing het om jou eie netwerk in elke streek te skep en dit dan deur 'n Skynprivaatnetwerk of 'n soort bestuurde diens te koppel, het Google Wolk jou in staat gestel om 'n volledig roubare enkele netwerk te skep wat alle Google-streke dek. Dit is 'n groot pluspunt in terme van werking en doeltreffendheid van die stelsel.

Boonop doen netwerkdienste en lasbalanseerders van Google Cloud uitstekende werk. Hulle laat jou eenvoudig toe om arbitrêre openbare IP-adresse van elke streek te gebruik, en die wonderlike BGP-protokol sorg vir die res (d.w.s. herlei gebruikers na die naaste groepering). Dit is duidelik dat, in die geval van 'n mislukking, verkeer outomaties na 'n ander streek gaan sonder enige menslike ingryping.

Kubernetes avontuur Dailymotion: skep infrastruktuur in die wolke + op die perseel
Monitering van Google Load Balancing

Ons platform maak ook baie gebruik van GPU's. Met Google Cloud kan u dit baie effektief direk in Kubernetes-klusters gebruik.

Destyds was die infrastruktuurspan hoofsaaklik gefokus op die nalatenskapstapel wat op fisiese bedieners ontplooi is. Dit is hoekom die gebruik van 'n bestuurde diens (insluitend Kubernetes-meesters) aan ons vereistes voldoen het en ons toegelaat het om spanne op te lei om met plaaslike groeperings te werk.

Gevolglik kon ons net 6 maande na die begin van die werk produksieverkeer op die Google Wolk-infrastruktuur begin ontvang.

Ten spyte van 'n aantal voordele, gaan werk met 'n wolkverskaffer egter gepaard met sekere koste, wat kan toeneem afhangende van die vrag. Dit is hoekom ons elke bestuurde diens wat ons gebruik het, noukeurig ontleed, in die hoop om dit in die toekoms op die perseel te implementeer. Trouens, die implementering van plaaslike klusters het aan die einde van 2016 begin en die hibriede strategie is terselfdertyd begin.

Bekendstelling van plaaslike houer orkestrasie platform Dailymotion

Herfs 2016

In toestande wanneer die hele stapel gereed was vir produksie, en werk op die API voortgesit, was dit tyd om op streekklusters te konsentreer.

Op daardie tydstip het gebruikers meer as 3 miljard video's elke maand gekyk. Natuurlik het ons al baie jare ons eie uitgebreide inhoudafleweringsnetwerk. Ons wou voordeel trek uit hierdie omstandighede en Kubernetes-klusters in bestaande datasentrums ontplooi.

Dailymotion se infrastruktuur het bestaan ​​uit meer as 2,5 duisend bedieners in ses datasentrums. Almal van hulle is gekonfigureer met behulp van Saltstack. Ons het begin om al die nodige resepte voor te berei vir die skep van meester- en werkknooppunte, sowel as 'n ens-groepering.

Kubernetes avontuur Dailymotion: skep infrastruktuur in die wolke + op die perseel

Netwerk deel

Ons netwerk is heeltemal herlei. Elke bediener adverteer sy IP op die netwerk met behulp van Exabgp. Ons het verskeie netwerkinproppe vergelyk en die enigste een wat aan al die behoeftes voldoen het (as gevolg van die L3-benadering wat gebruik is) was Calico. Dit pas perfek by die bestaande netwerkinfrastruktuurmodel.

Aangesien ons al die beskikbare infrastruktuurelemente wou gebruik, was die eerste ding wat ons moes doen om ons tuisgemaakte netwerkhulpmiddel (wat op alle bedieners gebruik word) uit te vind: gebruik dit om IP-adresreekse op die netwerk met Kubernetes-nodes te adverteer. Ons het Calico toegelaat om IP-adresse aan peule toe te ken, maar het dit nie en steeds nie vir BGP-sessies op netwerktoerusting gebruik nie. Trouens, roetering word deur Exabgp hanteer, wat die subnette wat deur Calico gebruik word, adverteer. Dit stel ons in staat om enige peul vanaf die interne netwerk te bereik (en veral vanaf lasbalanseerders).

Hoe ons inkomende verkeer bestuur

Om inkomende versoeke na die verlangde diens te herlei, is daar besluit om Ingress Controller te gebruik as gevolg van die integrasie daarvan met Kubernetes ingangsbronne.

Drie jaar gelede was nginx-ingress-controller die mees volwasse kontroleerder: Nginx bestaan ​​al lank en was bekend vir sy stabiliteit en werkverrigting.

In ons stelsel het ons besluit om die beheerders op toegewyde 10-Gigabit-lembedieners te plaas. Elke beheerder is gekoppel aan die kube-apibediener eindpunt van die ooreenstemmende groepering. Hierdie bedieners het ook Exabgp gebruik om openbare of private IP-adresse te adverteer. Ons netwerktopologie stel ons in staat om BGP vanaf hierdie beheerders te gebruik om alle verkeer direk na die peule te stuur sonder om 'n diens soos NodePort te gebruik. Hierdie benadering help om horisontale verkeer tussen nodusse te vermy en verbeter doeltreffendheid.

Kubernetes avontuur Dailymotion: skep infrastruktuur in die wolke + op die perseel
Verkeer beweging van die internet na peule

Noudat ons ons hibriede platform verstaan, kan ons dieper in die verkeersmigrasieproses self delf.

Migrasie van verkeer van Google Cloud na Dailymotion-infrastruktuur

Herfs 2018

Na byna twee jaar van bou, toets en instel, het ons uiteindelik 'n volledige Kubernetes-stapel gereed om 'n bietjie verkeer te aanvaar.

Kubernetes avontuur Dailymotion: skep infrastruktuur in die wolke + op die perseel

Die huidige roetestrategie is redelik eenvoudig, maar voldoende om in die behoeftes te voorsien. Benewens publieke IP's (op Google Cloud en Dailymotion), word AWS Route 53 gebruik om beleide op te stel en gebruikers na die groep van ons keuse te herlei.

Kubernetes avontuur Dailymotion: skep infrastruktuur in die wolke + op die perseel
Voorbeeld van roetebeleid wat Roete 53 gebruik

Met Google Wolk is dit maklik aangesien ons 'n enkele IP oor alle groepe deel en die gebruiker na die naaste GKE-groepering herlei word. Vir ons groepe is die tegnologie anders, aangesien hul IP's anders is.

Tydens die migrasie het ons probeer om streeksversoeke na die toepaslike groepe te herlei en die voordele van hierdie benadering geëvalueer.

Omdat ons GKE-klusters opgestel is om outomaties te skaal deur gebruik te maak van gepasmaakte statistieke, skaal hulle op/af op grond van inkomende verkeer.

In normale modus word alle streekverkeer na die plaaslike groepering gerig, en GKE dien as 'n reservaat in geval van probleme (gesondheidsondersoeke word deur Roete 53 uitgevoer).

...

In die toekoms wil ons roetebeleid ten volle outomatiseer om 'n outonome hibriede strategie te bereik wat voortdurend toeganklikheid vir gebruikers verbeter. Aan die positiewe kant is wolkkoste aansienlik verminder en API-reaksietye is selfs verminder. Ons vertrou die gevolglike wolkplatform en is gereed om meer verkeer na dit te herlei indien nodig.

PS van vertaler

Jy sal dalk ook belangstel in 'n ander onlangse Dailymotion-plasing oor Kubernetes. Dit is toegewy aan die ontplooiing van toepassings met Helm op baie Kubernetes-klusters en gepubliseer is sowat 'n maand gelede.

Lees ook op ons blog:

Bron: will.com

Voeg 'n opmerking