Märge. tõlge: Dailymotion on üks maailma suurimaid videomajutusteenuseid ja seetõttu märkimisväärne Kubernetese kasutaja. Süsteemiarhitekt David Donchez jagab selles materjalis ettevõtte K8s-il põhineva tootmisplatvormi loomise tulemusi, mis algas GKE-s pilveinstallatsiooniga ja lõppes hübriidlahendusena, mis võimaldas paremat reageerimisaega ja säästa infrastruktuurikulusid.
Põhi-API uuesti ülesehitamise otsustamine kolm aastat tagasi soovisime välja töötada tõhusama viisi rakenduste majutamiseks ja selle lihtsamaks muutmiseks . Sel eesmärgil otsustasime kasutada konteinerite orkestreerimisplatvormi ja valisime loomulikult Kubernetese.
Miks tasub Kubernetese baasil oma platvorm ehitada?
Tootmistaseme API kiiresti, kasutades Google Cloudi
2016. aasta suvi
Kolm aastat tagasi, vahetult pärast seda, kui Dailymotioni ostis , on meie insenerimeeskonnad keskendunud ühele ülemaailmsele eesmärgile: luua täiesti uus Dailymotioni toode.
Meie konteinerite analüüsi, orkestreerimislahenduste ja varasema kogemuse põhjal oleme veendunud, et Kubernetes on õige valik. Mõned arendajad teadsid juba põhikontseptsioone ja teadsid, kuidas seda kasutada, mis oli infrastruktuuri ümberkujundamisel tohutu eelis.
Infrastruktuuri vaatenurgast oli uut tüüpi pilvepõhiste rakenduste majutamiseks vaja võimsat ja paindlikku süsteemi. Otsustasime oma teekonna alguses pilves püsida, et saaksime südamerahuga luua võimalikult tugeva kohapealse platvormi. Otsustasime oma rakendused juurutada Google Kubernetes Engine'i abil, kuigi teadsime, et varem või hiljem kolime oma andmekeskustesse ja rakendame hübriidstrateegiat.
Miks valisite GKE?
Selle valiku tegime peamiselt tehnilistel põhjustel. Lisaks oli vaja kiiresti luua infrastruktuur, mis vastab ettevõtte ärivajadustele. Meil olid rakenduste hostimisele mõned nõuded, nagu geograafiline jaotus, mastaapsus ja tõrketaluvus.
GKE klastrid Dailymotionis
Kuna Dailymotion on üle maailma saadaval olev videoplatvorm, tahtsime tõesti parandada teenuse kvaliteeti ooteaega lühendades (latentsus)... Varem oli saadaval ainult Pariisis, mis ei olnud optimaalne. Tahtsin, et saaksin majutada rakendusi mitte ainult Euroopas, vaid ka Aasias ja USA-s.
See tundlikkus latentsusaja suhtes tähendas, et platvormi võrguarhitektuuri kallal tuleb teha tõsist tööd. Kui enamik pilveteenuseid sundis teid looma igas piirkonnas oma võrgu ja seejärel ühendama need VPN-i või mõne hallatava teenuse kaudu, siis Google Cloud võimaldas teil luua täielikult marsruutitava ühtse võrgu, mis katab kõiki Google'i piirkondi. See on suur pluss süsteemi toimimise ja tõhususe seisukohalt.
Lisaks teevad Google Cloudi võrguteenused ja koormuse tasakaalustajad suurepärast tööd. Need võimaldavad teil lihtsalt kasutada suvalisi avalikke IP-aadresse igast piirkonnast ja imeline BGP-protokoll hoolitseb ülejäänu eest (st suunab kasutajad lähimasse klastrisse). Ilmselgelt läheb liiklus rikke korral automaatselt teise piirkonda ilma inimese sekkumiseta.
Google Load Balancingi jälgimine
Meie platvorm kasutab ka palju GPU-sid. Google Cloud võimaldab teil neid väga tõhusalt kasutada otse Kubernetese klastrites.
Sel ajal keskendus infrastruktuuri meeskond peamiselt füüsilistes serverites kasutatavale pärandpinule. Seetõttu vastas hallatava teenuse kasutamine (sh Kubernetese meistrid) meie nõuetele ja võimaldas meil koolitada meeskondi kohalike klastritega töötamiseks.
Selle tulemusel saime hakata Google Cloudi infrastruktuuri tootmisliiklust vastu võtma vaid 6 kuud pärast töö algust.
Vaatamata mitmetele eelistele on pilveteenuse pakkujaga töötamine seotud teatud kuludega, mis võivad sõltuvalt koormusest suureneda. Seetõttu analüüsisime hoolikalt iga hallatavat teenust, mida kasutasime, lootes neid tulevikus kohapeal rakendada. Tegelikult algas kohalike klastrite juurutamine 2016. aasta lõpus ja samal ajal algatati hübriidstrateegia.
Kohaliku konteinerite orkestreerimisplatvormi Dailymotion käivitamine
2016. aasta sügis
Tingimustes, kui kogu virn oli tootmiseks valmis ja API-ga töötama , oli aeg keskenduda piirkondlikele klastritele.
Sel ajal vaatasid kasutajad iga kuu rohkem kui 3 miljardit videot. Loomulikult on meil juba aastaid olnud oma ulatuslik sisuedastusvõrgustik. Tahtsime seda asjaolu ära kasutada ja olemasolevates andmekeskustes Kubernetese klastreid juurutada.
Dailymotioni infrastruktuur koosnes enam kui 2,5 tuhandest serverist kuues andmekeskuses. Kõik need on konfigureeritud Saltstacki abil. Hakkasime ette valmistama kõiki vajalikke retsepte pea- ja töötajasõlmede ning etcd klastri loomiseks.
Võrguosa
Meie võrk on täielikult marsruuditud. Iga server reklaamib oma IP-d võrgus Exabgp abil. Võrdlesime mitut võrgupluginat ja ainus, mis rahuldas kõik vajadused (kasutatud L3 lähenemise tõttu). . See sobib suurepäraselt olemasoleva võrgu infrastruktuuri mudeliga.
Kuna soovisime kasutada kõiki saadaolevaid taristuelemente, tuli esimese asjana välja mõelda oma kodune võrguutiliit (kasutatakse kõigis serverites): kasutada seda Kubernetese sõlmedega võrgus IP-aadressivahemike reklaamimiseks. Lubasime Calicol määrata kaustadele IP-aadresse, kuid ei kasutanud ega kasuta seda endiselt võrguseadmete BGP-seansside jaoks. Tegelikult tegeleb marsruutimisega Exabgp, mis reklaamib Calico kasutatavaid alamvõrke. See võimaldab meil sisevõrgust (ja eelkõige koormuse tasakaalustajatest) jõuda mis tahes kaustani.
Kuidas me sisendliiklust haldame
Sissetulevate päringute soovitud teenusesse suunamiseks otsustati kasutada sissepääsukontrollerit, kuna see on integreeritud Kubernetese sisenemisressurssidega.
Kolm aastat tagasi oli nginx-ingress-controller kõige küpsem kontroller: Nginx oli olnud juba pikka aega ja oli tuntud oma stabiilsuse ja jõudluse poolest.
Otsustasime oma süsteemis paigutada kontrollerid spetsiaalsetele 10-gigabitistele teraserveritele. Iga kontroller oli ühendatud vastava klastri kube-apiserveri lõpp-punktiga. Need serverid kasutasid ka avalike või privaatsete IP-aadresside reklaamimiseks Exabgp-d. Meie võrgutopoloogia võimaldab meil kasutada nende kontrollerite BGP-d, et suunata kogu liiklus otse kaustadesse, ilma teenust nagu NodePort kasutamata. See lähenemisviis aitab vältida horisontaalset liiklust sõlmede vahel ja suurendab tõhusust.
Liikluse liikumine Internetist kaunadesse
Nüüd, kui mõistame oma hübriidplatvormi, saame süveneda liikluse migratsiooniprotsessi endasse.
Liikluse üleviimine Google Cloudist Dailymotioni infrastruktuuri
2018. aasta sügis
Pärast peaaegu kaheaastast ehitamist, testimist ja häälestamist on meil lõpuks täielik Kubernetese virn, mis on valmis liiklust vastu võtma.
Praegune marsruutimisstrateegia on üsna lihtne, kuid piisav vajaduste rahuldamiseks. Lisaks avalikele IP-dele (Google Cloudis ja Dailymotionis) kasutatakse AWS Route 53 reeglite määramiseks ja kasutajate ümbersuunamiseks meie valitud klastrisse.
Marsruutimise poliitika näide marsruudil 53
Google Cloudiga on see lihtne, kuna jagame kõigis klastrites ühte IP-d ja kasutaja suunatakse lähimasse GKE klastrisse. Meie klastrite jaoks on tehnoloogia erinev, kuna nende IP-d on erinevad.
Üleviimise ajal püüdsime suunata piirkondlikud päringud ümber sobivatesse klastritesse ja hindasime selle lähenemisviisi eeliseid.
Kuna meie GKE klastrid on konfigureeritud kohandatud mõõdikute abil automaatselt skaleerima, suurendatakse/vähendatakse neid sissetuleva liikluse põhjal.
Tavarežiimis suunatakse kogu regionaalne liiklus kohalikku klastrisse ja GKE toimib probleemide korral reservina (tervisekontrolli teostab marsruut 53).
...
Tulevikus tahame täielikult automatiseerida marsruutimispoliitikad, et saavutada autonoomne hübriidstrateegia, mis parandab pidevalt kasutajate juurdepääsetavust. Positiivne on see, et pilvekulud on oluliselt vähenenud ja API reageerimisaeg on isegi vähenenud. Usaldame tekkivat pilveplatvormi ja oleme vajadusel valmis rohkem liiklust sellele ümber suunama.
PS tõlkijalt
Teid võib huvitada ka teine hiljutine Dailymotioni postitus Kubernetese kohta. See on pühendatud rakenduste juurutamisele koos Helmiga paljudes Kubernetese klastrites ja umbes kuu aega tagasi.
Loe ka meie blogist:
- «'.
- «";
- «";
- «";
- «";
- «";
- «";
- «";
- «";
- «";
- «'.
Allikas: www.habr.com