🥇Aventura Kubernetes Dailymotion: crearea infrastructurii în cloud + on-premises

Nota traducătorului.: Dailymotion — unul dintre cele mai mari servicii de găzduire video din lume și, prin urmare, un utilizator de seamă al Kubernetes. În acest material, arhitectul de sistem David Donchez împărtășește rezultatele creării platformei de producție a companiei bazată pe K8s, care a început cu o instalare în cloud în GKE și a culminat cu o soluție hibridă, ce a permis obținerea unor timpi de reacție mai buni și economii pe costurile de infrastructură.

În luarea deciziei de reconfigurare a API-ului principal Dailymotion cu trei ani în urmă, am dorit să dezvoltăm o modalitate mai eficientă de a găzdui aplicații și să simplificăm procesele din dezvoltare și producție. În acest scop, am decis să folosim o platformă de orchestrare a containerelor și, în mod natural, am ales Kubernetes.

De ce ar merita să creați o platformă proprie bazată pe Kubernetes?

API de nivel de producție în cel mai scurt timp cu ajutorul Google Cloud

Vara anului 2016

Trei ani în urmă, imediat după achiziția Dailymotion de către Vivendi, echipele noastre de inginerie s-au concentrat asupra unui singur obiectiv global: să creăm un produs complet nou pentru Dailymotion.

În urma analizei containerelor, soluțiilor de orchestrare și a experienței noastre anterioare, am realizat că Kubernetes este alegerea corectă. O parte dintre dezvoltatori deja aveau noțiuni de bază și știau cum să-l folosească, ceea ce a fost un avantaj imens pentru transformarea infrastructurii.

Din perspectiva infrastructurii, era nevoie de un sistem puternic și flexibil pentru a găzdui noi tipuri de aplicații cloud-native. Am preferat să rămânem în cloud la începutul călătoriei noastre, pentru a construi cu calm o platformă locală cât mai fiabilă. Am decis să desfășurăm aplicațiile prin Google Kubernetes Engine, deși știam că mai devreme sau mai târziu ne vom muta în propriile centre de date și vom aplica o strategie hibridă.

De ce am ales GKE?

Am făcut această alegere în principal din motive tehnice. În plus, era necesar să oferim rapid o infrastructură care să răspundă nevoilor de afaceri ale companiei. Aveam câteva cerințe pentru găzduirea aplicațiilor, cum ar fi distribuția geografică, scalabilitatea și disponibilitatea.

Clusterele GKE în Dailymotion

Fiindcă Dailymotion este o platformă video disponibilă în întreaga lume, ne-am dorit foarte mult să îmbunătățim calitatea serviciului, reducând timpul de așteptare (latency). Anterior API-ul nostru a fost disponibil doar în Paris, ceea ce era suboptim. Ar fi fost de dorit să avem posibilitatea de a plasa aplicații nu doar în Europa, ci și în Asia și SUA.

Această sensibilitate la întârziere a însemnat că trebuia să lucrăm serios la arhitectura rețelei platformei. În timp ce majoritatea serviciilor cloud obligau la crearea unei rețele proprii în fiecare regiune și apoi la conectarea lor prin VPN sau un serviciu gestionat, Google Cloud permitea crearea unei rețele complet ruteizabile unice, care acoperă toate regiunile Google. Aceasta este un mare avantaj în ceea ce privește operarea și eficiența sistemului.

În plus, serviciile de rețea și echilibratoarele de încărcare de la Google Cloud își fac treaba excelent. Ele permit pur și simplu utilizarea oricăror IP-uri publice din fiecare regiune, iar minunatul protocol BGP se va ocupa de tot restul (adică va redirecționa utilizatorii către cel mai apropiat cluster). Este evident că, în caz de defecțiune, traficul va merge automat în altă regiune fără nicio intervenție umană.

Monitorizarea echilibrării încărcărilor în Google

Platforma noastră folosește de asemenea intens procesoare grafice. Google Cloud permite utilizarea lor într-un mod foarte eficient chiar în clusterele Kubernetes.

În acel moment, echipa de infrastructură se concentra în principal pe vechiul stivă desfășurată pe servere fizice. De aceea, utilizarea unui serviciu gestionat (inclusiv componentele master ale Kubernetes) răspundea cerințelor noastre și le permitea echipelor să se familiarizeze cu clusterele locale.

Ca rezultat, am reușit să începem să primim trafic în producție pe infrastructura Google Cloud la doar 6 luni după începerea lucrării.

Cu toate acestea, în ciuda unei serii de avantaje, colaborarea cu un furnizor de cloud implică anumite costuri, care pot crește în funcție de încărcare. De aceea, am analizat cu atenție fiecare serviciu gestionat utilizat, planificând să le implementăm în viitor on-premises. De fapt, implementarea clusterelor locale a început la sfârșitul anului 2016 și atunci a fost inițiată strategia hibridă.

Lansarea platformei locale de orchestrare a containerelor Dailymotion

Toamna anului 2016

În condițiile în care întreaga stivă era gata pentru producție, iar munca la API continuă, a fost o vreme să ne concentrăm pe clusterele regionale.

În acel moment, utilizatorii vizionau lunar peste 3 miliarde de videoclipuri. Desigur, aveam în funcțiune de mai bine de un an o rețea de livrare de conținut bine dezvoltată. Am dorit să profităm de această ocazie pentru a implementa clustere Kubernetes în centrele noastre de date existente.

Infrastructura Dailymotion constă în peste 2,5 mii de servere în șase centre de date. Toate acestea sunt configurate cu ajutorul Saltstack. Am început să pregătim toate rețetele necesare pentru creare de noduri master și worker, precum și a clusterei etcd.

Partea de rețea

Rețeaua noastră este complet rutabilă. Fiecare server își anunță IP-ul în rețea prin Exabgp. Am comparat mai multe pluginuri de rețea și singurul care satisfăcea toate cerințele (datorită abordării utilizate la nivel L3) a fost Calico. S-a integrat perfect în modelul de rețea existent al infrastructurii.

Întrucât am dorit să utilizăm toate elementele disponibile ale infrastructurii, trebuia mai întâi să ne ocupăm de utilitarul nostru de rețea (utilizat pe toate serverele): să-l folosim pentru a anunța intervalele de adrese IP în rețeaua clusterele Kubernetes. Am permis Calico să aloce adresele IP pod-urilor, dar nu l-am folosit și nici nu-l folosim pentru sesiunile BGP pe echipamentele de rețea. De fapt, rutarea este realizată de Exabgp, care anunță subrețelele utilizate de Calico. Acest lucru ne permite să accesăm orice pod din rețeaua internă (în special de la load balancer-e).

Cum gestionăm traficul ingress

Pentru a redirecționa cererile de intrare către serviciul dorit, s-a decis să folosim Ingress Controller datorită integrării sale cu resursele ingress ale Kubernetes.

Acum trei ani, nginx-ingress-controller era cel mai matur controler: Nginx era folosit de mult timp și era cunoscut pentru stabilitatea și performanța sa.

În sistemul nostru, am decis să plasăm controlerele pe blade servere dedicate de 10 gigabiți. Fiecare controler era conectat la endpoint-ul kube-apiserver-ului corespunzător cluster-ului. Pe aceste servere a fost folosit Exabgp pentru a anunța adrese IP publice sau private. Topologia rețelei noastre permite utilizarea BGP din aceste controlere pentru rutarea întregului trafic direct către pod-uri, fără a folosi un serviciu de tip NodePort. Această abordare ajută la evitarea traficului orizontal între noduri și crește eficiența.

Traficul din internet către pod-uri

Acum că am înțeles platforma noastră hibridă, putem aprofunda procesul de migrație a traficului.

Migrarea traficului din Google Cloud în infrastructura Dailymotion

Toamna anului 2018

După aproape doi ani de creare, testare și configurare, am obținut în sfârșit un stack complet Kubernetes, gata să primească o parte din trafic.

Strategia actuală de rutare este destul de simplă, dar satisface nevoile. Pe lângă IP-urile publice (în Google Cloud și Dailymotion), se folosește AWS Route 53 pentru a defini politicile și a redirecționa utilizatorii către clusterul ales de noi.

Exemplu de politică de rutare utilizând Route 53

Din Google Cloud este simplu, deoarece folosim un singur IP pentru toate clusterele, iar utilizatorul este redirecționat către cel mai apropiat cluster GKE. Pentru clusterele noastre tehnologia este diferită, deoarece IP-urile lor sunt distincte.

În timpul migrației, ne-am străduit să redirecționăm cererile regionale către clusterele corespunzătoare și am evaluat beneficiile acestei abordări.

Având în vedere că GKE-urile noastre sunt configurate pentru scalare automată folosind metrici personalizate, acestea adaugă/reduc resursele în funcție de traficul entrant.

În mod normal, tot traficul regional este direcționat către clusterul local, iar GKE-ul servește ca rezervă în caz de probleme (health-check-uri realizate prin Route 53).

…

În viitor, ne dorim să automatizăm complet politicile de rutare pentru a obține o strategie hibridă autonomă care îmbunătățește constant disponibilitatea pentru utilizatori. Avantajele constau în reducerea semnificativă a costurilor pentru cloud și chiar în scurtarea timpului de răspuns API. Avem încredere în platforma cloud obținută și suntem pregătiți să redirecționăm mai mult trafic spre aceasta, dacă este necesar.

P.S. de la traducător

Poate v-a interesat și o altă publicație recentă Dailymotion despre Kubernetes. Aceasta este dedicată desfășurării aplicațiilor cu Helm pe mai multe clustere Kubernetes și a fost publicată aproximativ cu o lună în urmă.

Citiți și în blogul nostru: