Shën. përkth.: Dailymotion — një nga shërbimet më të mëdha në botën e hostimit të videove dhe prandaj një përdorues i dukshëm i Kubernetes. Në këtë material, arkitekti i sistemit David Donchez ndan përfundimet e krijimit të platformës prodhuese të kompanisë mbi bazën e K8s, e cila filloi me një instalim në re në GKE dhe përfundoi si një zgjidhje hibride, duke arritur kështu të përmirësojë kohën e reagimit dhe të kursejë në shpenzimet infrastrukturore.
Duke marrë parasysh vendimin për ri-organizimin e API-t kryesor tre vjet më parë, dëshironim të zhvillonim një mënyrë më efikase për të vendosur aplikacione dhe për të lehtësuar . Për këtë qëllim, ne vendosëm të përdornim platformën e orkestrimit të kontejnerëve dhe natyrshëm zgjodhëm Kubernetes.
Pse ia vlen të krijosh një platformë të vetën mbi bazën e Kubernetes?
API me nivel prodhimi në një kohë të shkurtër me ndihmën e Google Cloud
Verës 2016
Tre vjet më parë, menjëherë pas blerjes së Dailymotion nga , ekipet tona inxhinierike u përqendruan në një objektiv global: të krijonin një produkt krejtësisht të ri Dailymotion.
Pas analizës së kontejnerëve, zgjidhjeve për orkestrim dhe përvojës sonë të kaluar, u bindëm se Kubernetes ishte zgjedhja e duhur. Pjesa e zhvilluesve tashmë kishte njohuri për konceptet bazë dhe dinin si ta përdornin, që ishte një përparësi e madhe për transformimin infrastruktural.
Nga pikëpamja e infrastrukturës, ne kishim nevojë për një sistem të fuqishëm dhe fleksibël për vendosjen e llojeve të reja të aplikacioneve cloud-native. Ne preferuam të qëndronim në re në fillim të udhëtimit tonë, për të ndërtuar një platformë lokale sa më të besueshme. Aplikacionet tona vendosëm t'i shpërndanim përmes Google Kubernetes Engine, edhe pse e dinim se më vonë do të kalonim në qendrat tona të të dhënave dhe do të aplikonim një strategji hibride.
Pse zgjodhëm GKE?
Ne bëmë këtë zgjedhje kryesisht për arsye teknike. Gjithashtu, u desh të ofronim shpejt infrastrukturë që i përgjigjej nevojave të biznesit të kompanisë. Kishim disa kërkesa për vendosjen e aplikacioneve, siç janë shpërndarja gjeografike, shkallëzueshmëria dhe qëndrueshmëria ndaj dështimeve.
Klasteret GKE në Dailymotion
Duke qenë se Dailymotion është një platformë videosh, e accessible në të gjithë botën, ne dëshironim shumë të përmirësonim cilësinë e shërbimit duke ulur kohën e pritjes (latency). Më parë ishte të ishte në Paris, që nuk ishte optimal. Kishim dëshirë të vendosnim aplikacionet jo vetëm në Evropë, por edhe në Azi dhe Shtetet e Bashkuara.
Kjo ndjeshmëri ndaj vonesave nënkuptonte se do të duhej të punonim seriozisht mbi arkitekturën rrjetore të platformës. Ndërsa shumica e shërbimeve cloud e detyronin të krijonim rrjetin tonë në çdo rajon dhe pastaj t'i lidhim ato përmes VPN ose ndonjë shërbimi të menaxhuar, Google Cloud lejonte krijimin e një rrjeti të unifikuar të plotë, të routing-uar, që mbulon të gjitha rajonet e Google. Kjo është një avantazh i madh në aspektin e operimit dhe efikasitetit të sistemit.
Për më tepër, shërbimet rrjetore dhe balancuesit e ngarkesës nga Google Cloud funksionojnë shkëlqyer. Ato lejojnë thjesht përdorimin e adresave IP publike nga çdo rajon, dhe protokolli i shkëlqyer BGP kujdeset për gjithçka tjetër (dmth, drejton përdoruesit në klasterin më të afërt). Është e qartë se në rast të dështimit, trafik fillimisht do të derdhet automatikisht në një rajon tjetër pa ndonjë ndërhyrje të njeriut.
Monitorimi i balancimit të ngarkesës në Google
Platforma jonë gjithashtu aktivisht përfshin procesorët grafikë. Google Cloud lejon përdorimin e tyre shumë efikasish në klasteret Kubernetes.
Në atë kohë, ekipi i infrastrukturës kryesisht përqendrohej në teknologjinë e vjetër, të vendosur në serverat fizikë. Pikërisht për këtë arsye, përdorimi i shërbimeve të menaxhuara (përfshirë komponentët kryesorë të Kubernetes) përmbushte kërkesat tona dhe lejonte trajnimin e ekipeve për të punuar me klasteret lokale.
Si rezultat, arritëm të fillonim të merrnim trafik production në infrastrukturën Google Cloud vetëm 6 muaj pas fillimit të punës.
Megjithatë, përveç disa avantazheve, puna me një ofrues cloud vjen me disa kosto që mund të rriten në varësi të ngarkesës. Kjo është arsyeja pse ne kemi analizuar me kujdes çdo shërbim të menaxhuar që përdorim, duke llogaritur në të ardhmen për ta implementuar në ambientin tonë on-premises. Në të vërtetë, implementimi i klastereve lokale filloi në fund të vitit 2016 dhe po ashtu u iniciua një strategji hibride.
Lansimi i platformës lokale të orkestrimit të konteinerëve Dailymotion
Vjeshta e vitit 2016
Në kushtet kur e gjithë staku ishte i gatshëm për production, dhe puna mbi API-në , kishim të përqendrohemi në klasteret rajonale.
Në atë kohë, përdoruesit shihnin më shumë se 3 miliard video çdo muaj. Sigurisht, kishte disa vite që ndodhej në funksion një rrjet i gjerë të shpërndarjes së përmbajtjes. Ne donim të shfrytëzonim këtë rast dhe të vendosnim klastere Kubernetes në qendrat ekzistuese të të dhënave.
Infrastruktura e Dailymotion përfshinte më shumë se 2,5 mijë serverë në gjashtë qendra të të dhënave. Të gjithë ato konfigurohen me ndihmën e Saltstack. Filluam të përgatisnin të gjithë receta të nevojshme për të krijuar nodet master dhe worker, si dhe klasterin etcd.
Pjesa rrjetore
Rrjeti ynë është plotësisht i adresueshëm. Çdo server shpall IP-në e tij në rrjet me Exabgp. Ne e krahasuam disa plugina rrjetesh dhe i vetmi që përmbushte të gjitha nevojat (për shkak të qasjes së përdorur në nivelin L3) ishte . Ai u përshtat mjaft mirë me modelin ekzistues të rrjetit të infrastrukturës.
Duke qenë se dëshironim të përdorim të gjitha elementet ekzistuese të infrastrukturës, në radhë të parë duhej të merreshim me mjetin tonë rrjetor (të përdorur në të gjithë serverët): ta përdorim atë për të shpallur diapazonet e IP-adresave në rrjetet me node Kubernetes. Ne lejuam që Calico të caktojë IP-adresa pod-ve, por nuk e përdorëm dhe ende nuk e përdorim për seancat BGP në pajisjet rrjetore. Në të vërtetë, rrugëzimi është menaxhuar nga Exabgp, i cili shpall nënrrjetet që përdoren nga Calico. Kjo na lejon të arrijmë çdo pod nga rrjeti i brendshëm (dhe veçanërisht nga balancuesit e ngarkesës).
Si menaxhojmë trafikun ingress
Për të ridrejtuar kërkesat e ardhshme në shërbimin e duhur, vendosëm të përdorim Ingress Controller për shkak të integrimit të tij me burimet ingress të Kubernetes.
Të tre vjet më parë, nginx-ingress-controller ishte kontrolluesi më i zhvilluar: Nginx ishte përdorur prej shumë Kohësh dhe ishte i njohur për stabilitetin dhe performancën e tij.
Në sistemin tonë, ne vendosëm të vendosim kontrollorët në serverat blade të dedikuar 10-gigabit. Çdo kontrollor u lidh me endpoint-in kube-apiserver të grupit përkatës. Në këto serverë gjithashtu përdorej Exabgp për të njoftuar adresat IP publike ose private. Topologjia e rrjetit tonë lejon përdorimin e BGP nga këta kontrollorë për routimin e gjithë trafikut direkt në pod-et pa përdorimin e një shërbimi si NodePort. Ky qasje ndihmon për të evituar trafikun horizontal midis nyjeve dhe rrit efikasitetin.
Lëvizja e trafikut nga interneti drejt pod-eve
Tani që u shqyrtuam me platformën tonë hibride, mund të thellohemi në procesin e migrimit të trafikut.
Migrimi i trafikut nga Google Cloud në infrastrukturën e Dailymotion
Vjeshta e 2018-ës
Pas gati dy vitesh krijimi, testimi dhe konfiguroi, ne përfundimisht morëm një stack të plotë Kubernetes, gati për të pranuar një pjesë të trafikut.
Strategjia aktuale e routimit është mjaft e thjeshtë, por plotëson nevojat. Përveç adresave IP publike (në Google Cloud dhe Dailymotion), përdoret AWS Route 53 për të vendosur politika dhe për të redirektuar përdoruesit në grupin e zgjedhur prej nesh.
Shembulli i politikës së routimit duke përdorur Route 53
Me Google Cloud, kjo është e thjeshtë, pasi ne përdorim një IP të vetme për të gjithë grupet, dhe përdoruesi redirektohet në grupin GKE më të afërt. Për grupet tona teknologjia është e ndryshme, pasi adresat e tyre IP ndryshojnë.
Gjatë migrimit, përpiqeshim të redirektonim kërkesat rajonale nga përdoruesit në grupet përkatëse dhe vlerësuam përfitimet e këtij qasje.
Duke qenë se grupet tona GKE janë konfiguruar për shkathtësinë automatike duke përdorur Custom Metrics, ato rrisin/pakësojnë kapacitetin në përputhje me trafikun që hyjnë.
Në modalitetin normal, gjithë trafiku rajonal dërgohet në grupin lokal, ndërsa GKE shërben si rezervë në rast se ndodhin probleme (kontrollet e shëndetit realizohen nga Route 53).
…
Në të ardhmen, ne dëshirojmë të automatizojmë plotësisht politikat e rutimit për të arritur një strategji autonome hibrid që përmirëson vazhdimisht disponueshmërinë për përdoruesit. Si përfitim, shpenzimet për cloud u reduktuan ndjeshëm dhe arritëm madje të ulëm edhe kohën e reagimit të API-ve. Ne besojmë në platformën tonë të cloud e cila është e gatshme të drejtojë më shumë trafik kur të nevojitet.
P.S. nga përkthyesi
Mund të jeni të interesuar edhe për një publikim tjetër të fundit nga Dailymotion në lidhje me Kubernetes. Ai i kushtohet implementimit të aplikacioneve me Helm në shumë klasterë Kubernetes dhe para një muaji.
Lexoni gjithashtu në blogun tonë:
- «».
- «»;
- «»;
- «»;
- «»;
- «»;
- «»;
- «»;
- «»;
- «»;
- «».
Burimi: habr.com
