Kubernetes adventure Dailymotion: paggawa ng imprastraktura sa cloud + on-premises

Kubernetes adventure Dailymotion: paggawa ng imprastraktura sa cloud + on-premises

Tandaan. transl.: Ang Dailymotion ay isa sa pinakamalaking serbisyo sa pagho-host ng video sa buong mundo at samakatuwid ay isang kilalang gumagamit ng Kubernetes. Sa materyal na ito, ibinahagi ng arkitekto ng system na si David Donchez ang mga resulta ng paglikha ng platform ng produksyon ng kumpanya batay sa K8s, na nagsimula sa pag-install ng cloud sa GKE at nagtapos bilang isang hybrid na solusyon, na nagbigay-daan para sa mas mahusay na mga oras ng pagtugon at pagtitipid sa mga gastos sa imprastraktura.

Pagpapasyang Buuin muli ang Core API Dailymotion tatlong taon na ang nakalipas, gusto naming bumuo ng isang mas mahusay na paraan upang mag-host ng mga application at gawing mas madali ito proseso sa pag-unlad at produksyon. Para sa layuning ito, nagpasya kaming gumamit ng container orchestration platform at natural na pinili ang Kubernetes.

Bakit sulit na bumuo ng sarili mong platform batay sa Kubernetes?

Ang antas ng produksiyon ng API sa walang oras gamit ang Google Cloud

Tag-init 2016

Tatlong taon na ang nakalipas, kaagad pagkatapos na mabili ang Dailymotion ni Vivendi, ang aming mga engineering team ay nakatuon sa isang pandaigdigang layunin: upang lumikha ng isang ganap na bagong produkto ng Dailymotion.

Batay sa aming pagsusuri sa mga lalagyan, mga solusyon sa orkestra, at aming nakaraang karanasan, kumbinsido kami na ang Kubernetes ang tamang pagpipilian. Ang ilang mga developer ay mayroon nang pag-unawa sa mga pangunahing konsepto at alam kung paano ito gamitin, na isang malaking kalamangan para sa pagbabago ng imprastraktura.

Mula sa pananaw sa imprastraktura, isang malakas at nababaluktot na sistema ang kailangan para mag-host ng mga bagong uri ng cloud-native na application. Pinili naming manatili sa cloud sa simula ng aming paglalakbay upang makabuo kami ng pinakamatatag na on-premise na platform na posible nang may kapayapaan ng isip. Nagpasya kaming i-deploy ang aming mga application gamit ang Google Kubernetes Engine, bagama't alam namin na maaga o huli ay lilipat kami sa aming sariling mga data center at maglalapat ng hybrid na diskarte.

Bakit GKE ang pinili mo?

Ginawa namin ang pagpipiliang ito pangunahin para sa mga teknikal na kadahilanan. Sa karagdagan, ito ay kinakailangan upang mabilis na magbigay ng imprastraktura na nakakatugon sa mga pangangailangan ng negosyo ng kumpanya. Mayroon kaming ilang kinakailangan para sa pagho-host ng mga application, tulad ng heograpikal na pamamahagi, scalability at fault tolerance.

Kubernetes adventure Dailymotion: paggawa ng imprastraktura sa cloud + on-premises
Mga kumpol ng GKE sa Dailymotion

Dahil ang Dailymotion ay isang video platform na available sa buong mundo, talagang gusto naming pagbutihin ang kalidad ng serbisyo sa pamamagitan ng pagbabawas ng oras ng paghihintay (latency). dati ang aming API ay available lang sa Paris, na suboptimal. Nais kong makapag-host ng mga aplikasyon hindi lamang sa Europa, kundi pati na rin sa Asya at USA.

Ang pagiging sensitibo sa latency na ito ay nangangahulugan na ang seryosong gawain ay kailangang gawin sa arkitektura ng network ng platform. Bagama't pinilit ka ng karamihan sa mga serbisyo ng cloud na gumawa ng sarili mong network sa bawat rehiyon at pagkatapos ay ikonekta ang mga ito sa pamamagitan ng VPN o ilang uri ng pinamamahalaang serbisyo, pinahintulutan ka ng Google Cloud na lumikha ng ganap na naruruta na solong network na sumasaklaw sa lahat ng mga rehiyon ng Google. Ito ay isang malaking plus sa mga tuntunin ng pagpapatakbo at kahusayan ng system.

Bilang karagdagan, ang mga serbisyo sa network at mga balanse ng pag-load mula sa Google Cloud ay mahusay na gumagana. Pinapahintulutan ka lang nilang gumamit ng di-makatwirang mga pampublikong IP address mula sa bawat rehiyon, at ang kahanga-hangang BGP protocol ay nangangalaga sa iba (ibig sabihin, pag-redirect ng mga user sa pinakamalapit na kumpol). Malinaw, sa kaganapan ng isang pagkabigo, ang trapiko ay awtomatikong pupunta sa ibang rehiyon nang walang anumang interbensyon ng tao.

Kubernetes adventure Dailymotion: paggawa ng imprastraktura sa cloud + on-premises
Pagsubaybay sa Google Load Balancing

Ginagamit din ng aming platform ang mga GPU. Binibigyang-daan ka ng Google Cloud na gamitin ang mga ito nang direkta nang direkta sa mga cluster ng Kubernetes.

Noong panahong iyon, ang koponan ng imprastraktura ay pangunahing nakatuon sa legacy stack na naka-deploy sa mga pisikal na server. Iyon ang dahilan kung bakit ang paggamit ng pinamamahalaang serbisyo (kabilang ang mga Kubernetes masters) ay nakatugon sa aming mga kinakailangan at nagbigay-daan sa amin na sanayin ang mga team na makipagtulungan sa mga lokal na cluster.

Bilang resulta, nagsimula kaming makatanggap ng trapiko sa produksyon sa imprastraktura ng Google Cloud 6 na buwan lamang pagkatapos ng pagsisimula ng trabaho.

Gayunpaman, sa kabila ng ilang mga pakinabang, ang pakikipagtulungan sa isang cloud provider ay nauugnay sa ilang mga gastos, na maaaring tumaas depende sa pagkarga. Iyon ang dahilan kung bakit maingat naming sinuri ang bawat pinamamahalaang serbisyo na ginamit namin, umaasang maipapatupad ang mga ito sa mga nasasakupan sa hinaharap. Sa katunayan, ang pagpapatupad ng mga lokal na kumpol ay nagsimula sa katapusan ng 2016 at ang hybrid na diskarte ay sinimulan sa parehong oras.

Paglunsad ng lokal na container orchestration platform Dailymotion

Taglagas 2016

Sa mga kondisyon kung kailan handa na ang buong stack para sa produksyon, at gumana sa API patuloy, oras na para mag-concentrate sa mga regional cluster.

Sa oras na iyon, ang mga user ay nanonood ng higit sa 3 bilyong video bawat buwan. Siyempre, mayroon kaming sariling malawak na Network ng Paghahatid ng Nilalaman sa loob ng maraming taon. Gusto naming samantalahin ang sitwasyong ito at mag-deploy ng mga Kubernetes cluster sa mga kasalukuyang data center.

Ang imprastraktura ng Dailymotion ay binubuo ng higit sa 2,5 libong mga server sa anim na data center. Lahat ng mga ito ay na-configure gamit ang Saltstack. Sinimulan naming ihanda ang lahat ng kinakailangang mga recipe para sa paglikha ng mga master at worker node, pati na rin ang isang etcd cluster.

Kubernetes adventure Dailymotion: paggawa ng imprastraktura sa cloud + on-premises

Bahagi ng network

Ang aming network ay ganap na naruta. Ang bawat server ay nag-a-advertise ng IP nito sa network gamit ang Exabgp. Inihambing namin ang ilang mga plugin ng network at ang tanging nakakatugon sa lahat ng mga pangangailangan (dahil sa L3 na diskarte na ginamit) ay kalenkor. Tamang-tama ito sa kasalukuyang modelo ng imprastraktura ng network.

Dahil gusto naming gamitin ang lahat ng available na elemento ng imprastraktura, ang unang bagay na kailangan naming gawin ay alamin ang aming home-grown network utility (ginagamit sa lahat ng server): gamitin ito upang mag-advertise ng mga saklaw ng IP address sa network na may mga Kubernetes node. Pinayagan namin ang Calico na magtalaga ng mga IP address sa mga pod, ngunit hindi at hindi pa rin ito ginagamit para sa mga session ng BGP sa network equipment. Sa katunayan, ang pagruruta ay pinangangasiwaan ng Exabgp, na nag-a-advertise ng mga subnet na ginagamit ng Calico. Nagbibigay-daan ito sa amin na maabot ang anumang pod mula sa panloob na network (at partikular na mula sa mga load balancer).

Paano namin pinamamahalaan ang trapiko sa pagpasok

Upang i-redirect ang mga papasok na kahilingan sa nais na serbisyo, napagpasyahan na gamitin ang Ingress Controller dahil sa pagsasama nito sa mga mapagkukunan ng pagpasok ng Kubernetes.

Tatlong taon na ang nakalilipas, ang nginx-ingress-controller ay ang pinaka-mature na controller: Ang Nginx ay nasa loob ng mahabang panahon at kilala sa katatagan at pagganap nito.

Sa aming system, nagpasya kaming ilagay ang mga controller sa nakalaang 10-Gigabit blade server. Ang bawat controller ay konektado sa kube-apiserver endpoint ng kaukulang kumpol. Ginamit din ng mga server na ito ang Exabgp upang mag-advertise ng mga pampubliko o pribadong IP address. Ang aming network topology ay nagbibigay-daan sa amin na gumamit ng BGP mula sa mga controllers na ito upang direktang iruta ang lahat ng trapiko sa mga pod nang hindi gumagamit ng serbisyo tulad ng NodePort. Nakakatulong ang diskarteng ito na maiwasan ang pahalang na trapiko sa pagitan ng mga node at pagpapabuti ng kahusayan.

Kubernetes adventure Dailymotion: paggawa ng imprastraktura sa cloud + on-premises
Ang paggalaw ng trapiko mula sa Internet patungo sa mga pod

Ngayong nauunawaan na namin ang aming hybrid na platform, maaari na naming suriin nang mas malalim ang mismong proseso ng paglipat ng trapiko.

Paglipat ng trapiko mula sa Google Cloud patungo sa imprastraktura ng Dailymotion

Taglagas 2018

Pagkatapos ng halos dalawang taon ng pagbuo, pagsubok, at pag-tune, sa wakas ay mayroon na kaming buong Kubernetes stack na handang tumanggap ng ilang trapiko.

Kubernetes adventure Dailymotion: paggawa ng imprastraktura sa cloud + on-premises

Ang kasalukuyang diskarte sa pagruruta ay medyo simple, ngunit sapat upang matugunan ang mga pangangailangan. Bilang karagdagan sa mga pampublikong IP (sa Google Cloud at Dailymotion), ang AWS Route 53 ay ginagamit upang magtakda ng mga patakaran at mag-redirect ng mga user sa cluster na aming pinili.

Kubernetes adventure Dailymotion: paggawa ng imprastraktura sa cloud + on-premises
Halimbawa ng patakaran sa pagruruta gamit ang Ruta 53

Sa Google Cloud, madali ito dahil nagbabahagi kami ng iisang IP sa lahat ng cluster at nire-redirect ang user sa pinakamalapit na cluster ng GKE. Para sa aming mga kumpol ang teknolohiya ay iba, dahil ang kanilang mga IP ay iba.

Sa panahon ng paglipat, hinangad naming i-redirect ang mga kahilingan sa rehiyon sa naaangkop na mga cluster at sinuri ang mga benepisyo ng diskarteng ito.

Dahil naka-configure ang aming mga cluster ng GKE na mag-autoscale gamit ang Custom na Sukatan, pinapataas/pababa ng mga ito batay sa papasok na trapiko.

Sa normal na mode, ang lahat ng trapiko sa rehiyon ay nakadirekta sa lokal na cluster, at ang GKE ay nagsisilbing reserba kung sakaling magkaroon ng mga problema (ang mga pagsusuri sa kalusugan ay isinasagawa sa pamamagitan ng Ruta 53).

...

Sa hinaharap, gusto naming ganap na i-automate ang mga patakaran sa pagruruta upang makamit ang isang autonomous na hybrid na diskarte na patuloy na nagpapahusay sa pagiging naa-access para sa mga user. Sa karagdagan, ang mga gastos sa cloud ay nabawasan nang malaki at ang mga oras ng pagtugon ng API ay nabawasan pa nga. Pinagkakatiwalaan namin ang nagreresultang cloud platform at handa kaming mag-redirect ng mas maraming trapiko dito kung kinakailangan.

PS mula sa tagasalin

Maaaring interesado ka rin sa isa pang kamakailang post sa Dailymotion tungkol sa Kubernetes. Nakatuon ito sa pag-deploy ng mga application na may Helm sa maraming kumpol ng Kubernetes at ay nai-publish halos isang buwan na ang nakalipas.

Basahin din sa aming blog:

Pinagmulan: www.habr.com

Magdagdag ng komento