Notu. transl.: Dailymotion estas unu el la plej grandaj videogastigaj servoj en la mondo kaj tial fama uzanto de Kubernetes. En ĉi tiu materialo, sistemarkitekto David Donchez dividas la rezultojn de kreado de la produktadplatformo de la firmao bazita sur K8s, kiu komenciĝis kun nuba instalado en GKE kaj finiĝis kiel hibrida solvo, kio permesis pli bonajn respondtempojn kaj ŝparojn sur infrastrukturkostoj.
Decidante Rekonstrui la Kernan API antaŭ tri jaroj, ni volis evoluigi pli efikan manieron gastigi aplikojn kaj faciligi ĝin . Por ĉi tiu celo, ni decidis uzi ujan orkestran platformon kaj nature elektis Kubernetes.
Kial valoras konstrui vian propran platformon bazitan sur Kubernetes?
Produkt-nivela API baldaŭ uzante Google Cloud
Somero 2016
Antaŭ tri jaroj, tuj post kiam Dailymotion estis aĉetita de , niaj inĝenieraj teamoj estas koncentritaj al unu tutmonda celo: krei tute novan Dailymotion-produkton.
Surbaze de nia analizo de ujoj, orkestraj solvoj kaj nia pasinta sperto, ni estas konvinkitaj, ke Kubernetes estas la ĝusta elekto. Iuj programistoj jam komprenis la bazajn konceptojn kaj sciis kiel uzi ĝin, kio estis grandega avantaĝo por la infrastruktura transformo.
De infrastruktura perspektivo, potenca kaj fleksebla sistemo estis postulata por gastigi novajn specojn de nub-indiĝenaj aplikoj. Ni elektis resti en la nubo komence de nia vojaĝo por ke ni povu konstrui la plej fortikan surlokan platformon ebla kun trankvilo. Ni decidis disfaldi niajn aplikaĵojn per Google Kubernetes Engine, kvankam ni sciis, ke pli aŭ malpli frue ni translokiĝos al niaj propraj datumcentroj kaj aplikos hibridan strategion.
Kial vi elektis GKE?
Ni faris ĉi tiun elekton ĉefe pro teknikaj kialoj. Krome, necesis rapide provizi infrastrukturon, kiu kontentigas la komercajn bezonojn de la kompanio. Ni havis kelkajn postulojn por gastigado de aplikoj, kiel geografia distribuo, skaleblo kaj misfunkciado.
GKE-aretoj en Dailymotion
Ĉar Dailymotion estas videoplatformo disponebla tutmonde, ni vere volis plibonigi la kvaliton de la servo reduktante atendan tempon. (latenteco). Antaŭe estis nur havebla en Parizo, kio estis suboptimuma. Mi volis povi gastigi aplikojn ne nur en Eŭropo, sed ankaŭ en Azio kaj Usono.
Ĉi tiu sentemo al latenteco signifis, ke serioza laboro devus esti farita sur la reto-arkitekturo de la platformo. Dum la plej multaj nubaj servoj devigis vin krei vian propran reton en ĉiu regiono kaj poste konekti ilin per VPN aŭ ia administrita servo, Google Cloud permesis al vi krei plene enrutigan ununuran reton kovrantan ĉiujn Guglo-regionojn. Ĉi tio estas granda pluso laŭ funkciado kaj efikeco de la sistemo.
Krome, retaj servoj kaj ŝarĝbalanciloj de Google Cloud faras bonegan laboron. Ili simple permesas vin uzi arbitrajn publikajn IP-adresojn de ĉiu regiono, kaj la mirinda BGP-protokolo prizorgas la reston (t.e. alidirektante uzantojn al la plej proksima areto). Evidente, okaze de malsukceso, trafiko aŭtomate iros al alia regiono sen ia homa interveno.
Monitorado de Google Load Balancing
Nia platformo ankaŭ multe uzas GPUojn. Google Cloud permesas vin uzi ilin tre efike rekte en Kubernetes-grupoj.
Tiutempe, la infrastruktura teamo estis ĉefe koncentrita sur la hereda stako deplojita sur fizikaj serviloj. Tial uzi administritan servon (inkluzive de Kubernetes-majstroj) plenumis niajn postulojn kaj permesis al ni trejni teamojn por labori kun lokaj aretoj.
Kiel rezulto, ni povis komenci ricevi produktan trafikon sur la infrastrukturo de Google Cloud nur 6 monatojn post la komenco de laboro.
Tamen, malgraŭ kelkaj avantaĝoj, labori kun nuba provizanto estas asociita kun certaj kostoj, kiuj povas pliiĝi depende de la ŝarĝo. Tial ni zorge analizis ĉiun administritan servon, kiun ni uzis, esperante efektivigi ilin surloke estonte. Fakte, la efektivigo de lokaj aretoj komenciĝis fine de 2016 kaj la hibrida strategio estis komencita samtempe.
Lanĉo de loka ujo instrumentadplatformo Dailymotion
Aŭtuno 2016
En kondiĉoj kiam la tuta stako estis preta por produktado, kaj laboro sur la API , estis tempo koncentriĝi pri regionaj aretoj.
En tiu tempo, uzantoj spektis pli ol 3 miliardojn da videoj ĉiumonate. Kompreneble, ni havas nian propran ampleksan Enhavan Liveran Reton dum multaj jaroj. Ni volis utiligi ĉi tiun cirkonstancon kaj deploji Kubernetes-aretojn en ekzistantaj datumcentroj.
La infrastrukturo de Dailymotion konsistis el pli ol 2,5 mil serviloj en ses datumcentroj. Ĉiuj ili estas agorditaj per Saltstack. Ni komencis prepari ĉiujn necesajn receptojn por krei majstrajn kaj laboristajn nodojn, kaj ankaŭ ktpd-grupon.
Reta parto
Nia reto estas tute direktita. Ĉiu servilo reklamas sian IP en la reto uzante Exabgp. Ni komparis plurajn retajn kromaĵojn kaj la sola, kiu kontentigis ĉiujn bezonojn (pro la L3 aliro uzata) estis . Ĝi perfekte persvadas en la ekzistantan retan infrastrukturan modelon.
Ĉar ni volis uzi ĉiujn disponeblajn infrastrukturajn elementojn, la unua afero, kiun ni devis fari, estis eltrovi nian hejman retan utilecon (uzatan ĉe ĉiuj serviloj): uzu ĝin por reklami IP-adresintervalojn en la reto per Kubernetes-nodoj. Ni permesis al Calico asigni IP-adresojn al podoj, sed ne uzis kaj ankoraŭ ne uzis ĝin por BGP-sesioj sur retaj ekipaĵoj. Fakte, vojigo estas pritraktita de Exabgp, kiu reklamas la subretojn uzatajn de Calico. Ĉi tio ebligas al ni atingi ajnan pod de la interna reto (kaj precipe de ŝarĝbalanciloj).
Kiel ni administras enirtrafikon
Por redirekti envenantajn petojn al la dezirata servo, oni decidis uzi Ingress Controller pro ĝia integriĝo kun Kubernetes enirresursoj.
Antaŭ tri jaroj, nginx-ingress-controller estis la plej matura regilo: Nginx ekzistis delonge kaj estis konata pro sia stabileco kaj efikeco.
En nia sistemo, ni decidis meti la regilojn sur dediĉitaj 10-Gigabit-klingaj serviloj. Ĉiu regilo estis ligita al la kube-apiserver finpunkto de la ekvivalenta areto. Ĉi tiuj serviloj ankaŭ uzis Exabgp por reklami publikajn aŭ privatajn IP-adresojn. Nia reto-topologio permesas al ni uzi BGP de ĉi tiuj regiloj por direkti la tutan trafikon rekte al la podoj sen uzi servon kiel NodePort. Ĉi tiu aliro helpas eviti horizontalan trafikon inter nodoj kaj plibonigas efikecon.
Trafika movado de la Interreto al podoj
Nun kiam ni komprenas nian hibridan platformon, ni povas pliprofundiĝi en la trafikan migradprocezon mem.
Migrado de trafiko de Google Cloud al Dailymotion-infrastrukturo
Aŭtuno 2018
Post preskaŭ du jaroj da konstruado, testado kaj agordado, ni finfine havas plenan Kubernetes-stakon pretan akcepti iom da trafiko.
La nuna vojstrategio estas sufiĉe simpla, sed sufiĉa por renkonti la bezonojn. Krom publikaj IP-oj (en Google Cloud kaj Dailymotion), AWS Route 53 estas uzata por agordi politikojn kaj redirekti uzantojn al la grupo de nia elekto.
Ekzempla vojpolitiko uzante Itineron 53
Kun Google Cloud ĉi tio estas facila ĉar ni dividas ununuran IP tra ĉiuj aretoj kaj la uzanto estas redirektita al la plej proksima GKE-areto. Por niaj aretoj la teknologio estas malsama, ĉar iliaj IP-oj estas malsamaj.
Dum la migrado, ni serĉis redirekti regionajn petojn al la taŭgaj aretoj kaj taksis la avantaĝojn de ĉi tiu aliro.
Ĉar niaj GKE-grupoj estas agorditaj por aŭtomate skali per Propraj Metrikoj, ili skaliĝas supren/malsupren surbaze de envenanta trafiko.
En normala reĝimo, la tuta regiona trafiko estas direktita al la loka areto, kaj GKE funkcias kiel rezervo en kazo de problemoj (sankontroloj estas faritaj per Itinero 53).
...
En la estonteco, ni volas plene aŭtomatigi vojajn politikojn por atingi aŭtonomian hibridan strategion, kiu kontinue plibonigas alireblecon por uzantoj. Aldone, nubaj kostoj estis signife reduktitaj kaj API-respondtempoj eĉ reduktiĝis. Ni fidas la rezultan nuban platformon kaj pretas redirekti pli da trafiko al ĝi se necese.
PS de tradukisto
Vi povus ankaŭ interesiĝi pri alia lastatempa Dailymotion-afiŝo pri Kubernetes. Ĝi estas dediĉita al la deplojo de aplikoj kun Helm sur multaj Kubernetes-aretoj kaj antaŭ ĉirkaŭ unu monato.
Legu ankaŭ en nia blogo:
- «".
- «»;
- «»;
- «»;
- «»;
- «»;
- «»;
- «»;
- «»;
- «»;
- «".
fonto: www.habr.com