Notă. transl.: Dailymotion este unul dintre cele mai mari servicii de găzduire video din lume și, prin urmare, un utilizator remarcabil 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 s-a încheiat ca o soluție hibridă, care a permis timpi de răspuns mai buni și economii la costurile de infrastructură.
Decizia de a reconstrui API-ul de bază în urmă cu trei ani, am vrut să dezvoltăm o modalitate mai eficientă de a găzdui aplicații și de a le face mai ușor . În acest scop, am decis să folosim o platformă de orchestrare a containerelor și, în mod firesc, am ales Kubernetes.
De ce merită să vă construiți propria platformă bazată pe Kubernetes?
API la nivel de producție în cel mai scurt timp folosind Google Cloud
Vara 2016
În urmă cu trei ani, imediat după ce Dailymotion a fost achiziționat de , echipele noastre de ingineri se concentrează pe un obiectiv global: crearea unui produs Dailymotion complet nou.
Pe baza analizei noastre a containerelor, a soluțiilor de orchestrare și a experienței noastre anterioare, suntem convinși că Kubernetes este alegerea potrivită. Unii dezvoltatori aveau deja o înțelegere a conceptelor de bază și știau cum să le folosească, ceea ce a reprezentat un avantaj imens pentru transformarea infrastructurii.
Din perspectiva infrastructurii, era necesar un sistem puternic și flexibil pentru a găzdui noi tipuri de aplicații native din cloud. Am ales să rămânem în cloud la începutul călătoriei noastre, astfel încât să putem construi cea mai robustă platformă on-premise posibilă cu liniște sufletească. Am decis să ne implementăm aplicațiile folosind 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 ați ales GKE?
Am făcut această alegere în principal din motive tehnice. În plus, a fost necesară furnizarea rapidă a infrastructurii care să răspundă nevoilor de afaceri ale companiei. Aveam anumite cerințe pentru găzduirea aplicațiilor, cum ar fi distribuția geografică, scalabilitatea și toleranța la erori.
Clustere GKE în Dailymotion
Deoarece Dailymotion este o platformă video disponibilă în întreaga lume, ne-am dorit cu adevărat să îmbunătățim calitatea serviciului prin reducerea timpului de așteptare (latenta). Mai devreme era disponibil doar la Paris, ceea ce era suboptim. Mi-am dorit să pot găzdui aplicații nu doar în Europa, ci și în Asia și SUA.
Această sensibilitate la latență a însemnat că ar trebui făcută o muncă serioasă asupra arhitecturii de rețea a platformei. În timp ce majoritatea serviciilor cloud v-au forțat să vă creați propria rețea în fiecare regiune și apoi să le conectați printr-un VPN sau un fel de serviciu gestionat, Google Cloud v-a permis să creați o rețea unică complet rutabilă care să acopere toate regiunile Google. Acesta este un mare plus în ceea ce privește funcționarea și eficiența sistemului.
În plus, serviciile de rețea și balansoarele de încărcare de la Google Cloud fac o treabă excelentă. Pur și simplu vă permit să utilizați adrese IP publice arbitrare din fiecare regiune, iar minunatul protocol BGP se ocupă de restul (adică redirecționarea utilizatorilor către cel mai apropiat cluster). Evident, în cazul unei defecțiuni, traficul va merge automat în altă regiune fără nicio intervenție umană.
Monitorizare Google Load Balancing
Platforma noastră folosește, de asemenea, GPU-urile. Google Cloud vă permite să le utilizați foarte eficient direct în clusterele Kubernetes.
La acea vreme, echipa de infrastructură se concentra în primul rând pe stiva moștenită implementată pe servere fizice. De aceea, utilizarea unui serviciu gestionat (inclusiv master Kubernetes) a îndeplinit cerințele noastre și ne-a permis să pregătim echipe pentru a lucra cu clustere locale.
Drept urmare, am putut începe să primim trafic de producție pe infrastructura Google Cloud la doar 6 luni de la începerea lucrărilor.
Cu toate acestea, în ciuda o serie de avantaje, lucrul cu un furnizor de cloud este asociat cu anumite costuri, care pot crește în funcție de sarcină. De aceea, am analizat cu atenție fiecare serviciu administrat pe care l-am folosit, sperând să le implementăm la nivel local în viitor. De altfel, implementarea clusterelor locale a început la sfârșitul anului 2016 și, în același timp, a fost inițiată strategia hibridă.
Lansarea platformei locale de orchestrare a containerelor Dailymotion
Toamna 2016
În condițiile în care întreaga stivă era gata pentru producție și lucrați la API , era timpul să ne concentrăm asupra clusterelor regionale.
La acel moment, utilizatorii urmăreau peste 3 miliarde de videoclipuri în fiecare lună. Desigur, de mulți ani avem propria noastră rețea extinsă de livrare de conținut. Am vrut să profităm de această circumstanță și să implementăm clustere Kubernetes în centrele de date existente.
Infrastructura Dailymotion a constat din peste 2,5 mii de servere în șase centre de date. Toate sunt configurate folosind Saltstack. Am început să pregătim toate rețetele necesare pentru crearea nodurilor master și worker, precum și a unui cluster etcd.
Partea de rețea
Rețeaua noastră este complet direcționată. Fiecare server își face publicitate IP-ul în rețea folosind Exabgp. Am comparat mai multe plugin-uri de rețea și singurul care a satisfăcut toate nevoile (datorită abordării L3 folosită) a fost . Se încadrează perfect în modelul de infrastructură de rețea existent.
Deoarece am vrut să folosim toate elementele de infrastructură disponibile, primul lucru pe care a trebuit să-l facem a fost să ne dăm seama de utilitatea noastră de rețea (folosită pe toate serverele): să-l folosim pentru a face publicitate intervalelor de adrese IP în rețea cu noduri Kubernetes. Am permis lui Calico să atribuie adrese IP pod-urilor, dar nu le-am folosit și încă nu le folosim pentru sesiuni BGP pe echipamente de rețea. De fapt, rutarea este gestionată de Exabgp, care face publicitate subrețelelor utilizate de Calico. Acest lucru ne permite să ajungem la orice pod din rețeaua internă (și în special de la echilibrarea încărcăturii).
Cum gestionăm traficul de intrare
Pentru a redirecționa cererile primite către serviciul dorit, s-a decis să se utilizeze Ingress Controller datorită integrării sale cu resursele de intrare Kubernetes.
În urmă cu trei ani, nginx-ingress-controller era cel mai matur controler: Nginx exista de mult timp și era cunoscut pentru stabilitatea și performanța sa.
În sistemul nostru, am decis să plasăm controlerele pe servere blade dedicate de 10 Gigabit. Fiecare controler a fost conectat la punctul final kube-apiserver al clusterului corespunzător. Aceste servere au folosit și Exabgp pentru a face publicitate adreselor IP publice sau private. Topologia noastră de rețea ne permite să folosim BGP de la aceste controlere pentru a direcționa tot traficul direct către poduri fără a folosi un serviciu precum NodePort. Această abordare ajută la evitarea traficului orizontal între noduri și îmbunătățește eficiența.
Mișcarea traficului de pe internet la poduri
Acum că înțelegem platforma noastră hibridă, putem aprofunda procesul de migrare a traficului în sine.
Migrarea traficului de la Google Cloud la infrastructura Dailymotion
Toamna 2018
După aproape doi ani de construire, testare și reglare, avem în sfârșit un stack complet Kubernetes gata să accepte puțin trafic.
Strategia actuală de rutare este destul de simplă, dar suficientă pentru a răspunde nevoilor. Pe lângă IP-urile publice (pe Google Cloud și Dailymotion), AWS Route 53 este folosit pentru a seta politici și a redirecționa utilizatorii către clusterul ales de noi.
Exemplu de politică de rutare folosind Route 53
Cu Google Cloud, acest lucru este ușor, deoarece partajăm un singur IP în 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 diferite.
În timpul migrației, am căutat să redirecționăm cererile regionale către clusterele corespunzătoare și am evaluat beneficiile acestei abordări.
Deoarece clusterele noastre GKE sunt configurate pentru scalare automată utilizând valori personalizate, acestea cresc/descrește în funcție de traficul de intrare.
În modul normal, tot traficul regional este direcționat către clusterul local, iar GKE servește drept rezervă în caz de probleme (verificările de sănătate sunt efectuate de Route 53).
...
În viitor, dorim să automatizăm complet politicile de rutare pentru a realiza o strategie hibridă autonomă care îmbunătățește continuu accesibilitatea pentru utilizatori. În plus, costurile cloud au fost reduse semnificativ, iar timpii de răspuns API au fost chiar redusi. Avem încredere în platforma cloud rezultată și suntem gata să redirecționăm mai mult trafic către aceasta dacă este necesar.
PS de la traducator
S-ar putea să fiți interesat și de o altă postare recentă din Dailymotion despre Kubernetes. Este dedicat implementării de aplicații cu Helm pe multe clustere Kubernetes și acum o luna.
Citește și pe blogul nostru:
- «".
- «»;
- «»;
- «»;
- «»;
- «»;
- «»;
- «»;
- «»;
- «»;
- «".
Sursa: www.habr.com