Kubernetes abentura Dailymotion: hodeietan azpiegiturak sortzea + lokalean

Kubernetes abentura Dailymotion: hodeietan azpiegiturak sortzea + lokalean

Ohar. itzul.: Dailymotion munduko bideo-ostalaritza zerbitzu handienetako bat da eta, beraz, Kubernetesen erabiltzaile nabarmena. Material honetan, David Donchez sistema-arkitektoak K8etan oinarritutako konpainiaren produkzio-plataforma sortzearen emaitzak partekatzen ditu, GKEn hodei-instalazio batekin hasi eta soluzio hibrido gisa amaitu zena, erantzun denbora hobeak eta azpiegituren kostuetan aurreztea ahalbidetu duena.

Core APIa berreraikitzea erabakitzea Dailymotion duela hiru urte, aplikazioak ostatatzeko eta errazteko modu eraginkorragoa garatu nahi genuen garapen eta produkzio prozesuak. Horretarako, edukiontzien orkestrazio plataforma bat erabiltzea erabaki genuen eta Kubernetes aukeratu genuen.

Zergatik merezi du zure plataforma propioa eraikitzea Kubernetesen oinarrituta?

Produkzio-mailako APIa denbora gutxian Google Cloud erabiliz

2016ko uda

Duela hiru urte, Dailymotion erosi eta berehala Vivendi, gure ingeniaritza-taldeak helburu global batean oinarritzen dira: Dailymotion produktu guztiz berria sortzea.

Edukiontzien, orkestrazio soluzioen eta iraganeko esperientzian oinarrituta, Kubernetes aukera egokia dela sinetsita gaude. Garatzaile batzuek jada bazekiten oinarrizko kontzeptuak eta erabiltzen bazekiten, eta hori abantaila handia izan zen azpiegituraren eraldaketarako.

Azpiegituren ikuspuntutik, sistema indartsu eta malgu bat behar zen hodeiko jatorrizko aplikazio mota berriak hartzeko. Gure bidaiaren hasieran hodeian geratzea aukeratu genuen, lasaitasun osoz ahalik eta plataformarik sendoena eraiki ahal izateko. Gure aplikazioak Google Kubernetes Engine erabiliz zabaltzea erabaki genuen, nahiz eta bagenekien lehenago edo beranduago gure datu-zentroetara pasako ginela eta estrategia hibrido bat aplikatuko ginela.

Zergatik aukeratu zenuen GKE?

Aukera hau arrazoi teknikoengatik egin dugu batez ere. Horrez gain, enpresaren negozio-beharrei erantzuteko azpiegitura azkar eskaintzea beharrezkoa zen. Aplikazioak ostatatzeko baldintza batzuk genituen, hala nola banaketa geografikoa, eskalagarritasuna eta akatsen tolerantzia.

Kubernetes abentura Dailymotion: hodeietan azpiegiturak sortzea + lokalean
GKE klusterrak Dailymotion-en

Dailymotion mundu osoan eskuragarri dagoen bideo-plataforma denez, zerbitzuaren kalitatea hobetu nahi genuen itxaron denbora murriztuz. (latentzia)... Aurretik gure APIa Parisen bakarrik zegoen eskuragarri, hau ez zen optimoa. Europan ez ezik, Asian eta AEBetan ere jaso ahal izan nahi nituen.

Latentziarekiko sentikortasun horrek plataformaren sare-arkitekturan lan serioa egin behar zela esan nahi zuen. Hodeiko zerbitzu gehienek eskualde bakoitzean zure sarea sortzera behartzen zintuzten eta gero VPN baten bidez edo kudeatutako zerbitzuren baten bidez konektatzera behartu zintuzten arren, Google Cloud-ek sare bakar guztiz bideragarria sortzea ahalbidetu zuen Google eskualde guztiak hartzen dituena. Hau abantaila handia da sistemaren funtzionamenduari eta eraginkortasunari dagokionez.

Gainera, sareko zerbitzuek eta Google Cloud-eko karga-orekatzaileek lan bikaina egiten dute. Besterik gabe, eskualde bakoitzeko IP helbide publiko arbitrarioak erabiltzeko aukera ematen dute, eta BGP protokolo zoragarriak gainontzekoaz arduratzen da (hau da, erabiltzaileak gertueneko klusterera birbideratzen ditu). Jakina, hutsegiterik gertatuz gero, trafikoa automatikoki beste eskualde batera joango da gizakiaren esku-hartzerik gabe.

Kubernetes abentura Dailymotion: hodeietan azpiegiturak sortzea + lokalean
Google Load Balancing monitorizatzea

Gure plataformak GPUak ere asko erabiltzen ditu. Google Cloud-ek modu eraginkorrean erabiltzeko aukera ematen dizu zuzenean Kubernetes klusterretan.

Garai hartan, azpiegitura taldea zerbitzari fisikoetan inplementatutako ondare pilara zentratu zen batez ere. Horregatik, zerbitzu kudeatu bat erabiltzeak (Kubernetes masterrak barne) gure eskakizunak betetzen zituen eta taldeak tokiko klusterrekin lan egiteko aukera eman zigun.

Ondorioz, Google Cloud azpiegituran ekoizpen-trafikoa jasotzen hasi ginen lanak hasi eta 6 hilabetera.

Hala ere, abantaila ugari izan arren, hodeiko hornitzaile batekin lan egitea kostu batzuekin lotzen da, eta kargaren arabera handitu daitezke. Horregatik, arreta handiz aztertu genuen erabili genuen kudeatutako zerbitzu bakoitza, etorkizunean lokalean ezartzeko asmoz. Izan ere, 2016 amaieran hasi zen tokiko klusterren ezarpena eta aldi berean estrategia hibridoa hasi zen.

Dailymotion tokiko edukiontzien orkestrazio plataforma abian jartzea

2016ko udazkena

Pila osoa produkziorako prest zegoen baldintzetan eta APIan lan egin jarraitu zuen, eskualdeko klusterretan kontzentratzeko garaia zen.

Garai hartan, erabiltzaileek hilero 3 milioi bideo baino gehiago ikusten zituzten. Jakina, urte asko daramatzagu edukia emateko sare zabala. Egoera hau aprobetxatu eta Kubernetes klusterrak zabaldu nahi genituen lehendik zeuden datu-zentroetan.

Dailymotion-en azpiegiturak 2,5 mila zerbitzari baino gehiago zituen sei datu-zentrotan. Horiek guztiak Saltstack erabiliz konfiguratuta daude. Nodo maisuak eta langileak sortzeko beharrezko errezeta guztiak prestatzen hasi ginen, baita etcd cluster bat ere.

Kubernetes abentura Dailymotion: hodeietan azpiegiturak sortzea + lokalean

Sarearen zatia

Gure sarea guztiz bideratuta dago. Zerbitzari bakoitzak bere IP iragartzen du sarean Exabgp erabiliz. Hainbat sareko plugin alderatu genituen eta behar guztiak asetzen zituen bakarra (erabilitako L3 ikuspegia dela eta) izan zen. Calico. Lehendik dagoen sare-azpiegituren ereduan ezin hobeto egokitzen da.

Eskuragarri dauden azpiegitura-elementu guztiak erabili nahi genituenez, egin behar genuen lehenengo gauza gure etxeko sare-erabilgarritasuna irudikatzea izan zen (zerbitzari guztietan erabiltzen dena): erabili sarean Kubernetes nodoekin IP helbide-barrutiak iragartzeko. Calicori IP helbideak podei esleitzeko baimena eman genion, baina ez zuen erabiltzen sareko ekipoetako BGP saioetarako eta oraindik ez dugu erabili. Izan ere, bideratzea Exabgp-ek kudeatzen du, Calicok erabiltzen dituen azpisareak iragartzen dituena. Horri esker, barne saretik (eta bereziki karga-orekatzaileetatik) edozein podetara iristen gara.

Sarrerako trafikoa nola kudeatzen dugun

Jasotako eskaerak nahi den zerbitzura birbideratzeko, Ingress Controller erabiltzea erabaki zen Kubernetes-en sarrerako baliabideekin integratuta dagoelako.

Duela hiru urte, nginx-ingress-controller kontrolagailu helduena zen: Nginx aspalditik zegoen eta bere egonkortasunagatik eta errendimenduagatik ezaguna zen.

Gure sisteman, kontrolagailuak 10 Gigabit blade zerbitzari dedikatuetan jartzea erabaki genuen. Kontrolagailu bakoitza dagokion klusterraren kube-apiserver amaierako puntura konektatu zen. Zerbitzari hauek Exabgp ere erabiltzen zuten IP helbide publiko edo pribatuak iragartzeko. Gure sarearen topologiak kontrolagailu hauetatik BGP erabiltzeko aukera ematen digu trafiko guztia zuzenean podetara bideratzeko, NodePort bezalako zerbitzurik erabili gabe. Ikuspegi honek nodoen arteko trafiko horizontala saihesten laguntzen du eta eraginkortasuna hobetzen du.

Kubernetes abentura Dailymotion: hodeietan azpiegiturak sortzea + lokalean
Trafiko mugimendua Internetetik podetara

Orain gure plataforma hibridoa ulertzen dugunean, trafikoaren migrazio prozesuan bertan sakondu dezakegu.

Trafikoa Google Cloud-etik Dailymotion azpiegiturara migratzea

2018ko udazkena

Ia bi urte eraikitzen, probatzen eta sintonizatzen egon ondoren, azkenean Kubernetes pila osoa dugu trafiko pixka bat onartzeko prest.

Kubernetes abentura Dailymotion: hodeietan azpiegiturak sortzea + lokalean

Egungo bideratze estrategia nahiko sinplea da, baina beharrei erantzuteko nahikoa. IP publikoez gain (Google Cloud eta Dailymotion-en), AWS Route 53 erabiltzen da politikak ezartzeko eta erabiltzaileak gure aukeratutako klusterera birbideratzeko.

Kubernetes abentura Dailymotion: hodeietan azpiegiturak sortzea + lokalean
Bideratze-politika adibidea Route 53 erabiliz

Google Cloud-ekin erraza da IP bakarra partekatzen baitugu kluster guztietan eta erabiltzailea hurbilen dagoen GKE klusterera birbideratzen baita. Gure klusterrentzat teknologia ezberdina da, haien IPak desberdinak baitira.

Migrazioan zehar, eskualdeko eskaerak kluster egokietara birbideratu nahi izan ditugu eta ikuspegi honen onurak ebaluatu ditugu.

Gure GKE klusterrak neurri pertsonalizatuak erabiliz automatikoki eskalatzeko konfiguratuta daudenez, igoera edo behera egiten dute sarrerako trafikoaren arabera.

Modu arruntean, eskualdeko trafiko guztia tokiko klusterera bideratzen da, eta GKE-k erreserba gisa balio du arazoen kasuan (osasun-kontrolak Route 53-k egiten ditu).

...

Etorkizunean, bideratze-politikak guztiz automatizatu nahi ditugu, erabiltzaileen irisgarritasuna etengabe hobetzen duen estrategia hibrido autonomo bat lortzeko. Alde onean, hodeiaren kostuak nabarmen murriztu dira eta APIen erantzun-denborak ere murriztu dira. Sortzen den hodeiko plataformarekin fidatzen gara eta behar izanez gero bertara trafiko gehiago birbideratzeko prest gaude.

PS itzultzailetik

Baliteke Kubernetes-i buruzko azken Dailymotion-en beste argitalpen bat ere interesatuko zaizu. Helm-ekin aplikazioak hedatzera zuzenduta dago Kubernetes kluster askotan eta argitaratu zen duela hilabete inguru.

Irakurri ere gure blogean:

Iturria: www.habr.com

Gehitu iruzkin berria