Заўв. перав.: Dailymotion - адзін з найбуйнейшых у свеце сэрвісаў хостынгу відэа і таму прыкметны карыстальнік Kubernetes. У гэтым матэрыяле сістэмны архітэктар David Donchez дзеліцца вынікамі стварэння production-платформы кампаніі на базе K8s, якая пачыналася з хмарнай усталёўкі ў GKE і скончылася як гібрыднае рашэнне, што дазволіла дамагчыся лепшага часу рэакцыі і зэканоміць на інфраструктурных выдатках.
Прымаючы рашэнне аб перабудове асноўнага API тры гады таму, мы хацелі распрацаваць больш эфектыўны спосаб размяшчэння прыкладанняў і аблегчыць . Для гэтай мэты мы вырашылі выкарыстоўваць платформу аркестрацыі кантэйнераў і натуральнай выявай абралі Kubernetes.
Чаму варта ствараць уласную платформу на базе Kubernetes?
API production-ўзроўню ў найкарацейшыя тэрміны з дапамогай Google Cloud
Лета 2016-га
Тры гады таму, адразу пасля пакупкі Dailymotion кампаніяй , нашы інжынерныя каманды сфакусаваліся на адной глабальнай мэты: стварыць зусім новы прадукт Dailymotion.
Па выніках аналізу кантэйнераў, рашэнняў для аркестрацыі і нашаму мінуламу досведу мы пераканаліся, што Kubernetes - правільны выбар. Частка распрацоўшчыкаў ужо мела ўяўленне аб базавых канцэпцыях і ведала, як яго выкарыстоўваць, што было вялікай перавагай для інфраструктурнай трансфармацыі.
З пункту гледжання інфраструктуры патрабавалася магутная і гнуткая сістэма для размяшчэння новых тыпаў хмарных (cloud-native) прыкладанняў. Мы аддалі перавагу застацца ў воблаку ў пачатку нашага падарожжа, каб спакойна пабудаваць максімальна надзейную лакальную платформу. Свае прыкладанні вырашылі разгортваць з дапамогай Google Kubernetes Engine, хоць ведалі, што рана ці позна пяройдзем на ўласныя ЦАД і прымянім гібрыдную стратэгію.
Чаму выбралі GKE?
Мы зрабілі гэты выбар галоўным чынам з тэхнічных меркаванняў. Акрамя таго, патрабавалася хутка падаць інфраструктуру, якая адпавядае патрэбам бізнэсу кампаніі. У нас былі некаторыя патрабаванні да размяшчэння прыкладанняў, такія як геаграфічная размеркаванасць, маштабаванасць і адмоваўстойлівасць.
Кластары GKE у Dailymotion
Паколькі Dailymotion – відэаплатформа, даступная па ўсім свеце, мы вельмі хацелі павысіць якасць сэрвісу, скараціўшы час чакання. (latency). Раней быў даступны толькі ў Парыжы, што было неаптымальна. Жадалася мець магчымасць размяшчаць прыкладанні не толькі ў Еўропе, але і ў Азіі, і ў ЗША.
Гэтая адчувальнасць да затрымак азначала, што давядзецца сур'ёзна папрацаваць над сеткавай архітэктурай платформы. У той час як большасць хмарных сэрвісаў змушалі ствараць сваю сетку ў кожным рэгіёне і потым звязваць іх праз VPN або нейкі кіраваны сэрвіс, Google Cloud дазваляў стварыць цалкам маршрутызаваную адзіную сетку, якая ахоплівае ўсе рэгіёны Google. Гэта вялікі плюс у сэнсе эксплуатацыі і эфектыўнасці сістэмы.
Акрамя таго, са сваёй працай выдатна спраўляюцца сеткавыя сэрвісы і балансавальнікі нагрузкі ад Google Cloud. Яны проста дазваляюць выкарыстоўваць адвольныя агульнадаступныя IP-адрасы з кожнага рэгіёна, а выдатны пратакол BGP паклапоціцца пра ўсё астатняе (г.зн. перанакіруе карыстальнікаў да бліжэйшага кластара). Відавочна, што ў выпадку збою трафік будзе аўтаматычна ісці ў іншы рэгіён без умяшання чалавека.
Маніторынг балансавання нагрузак у Google
Наша платформа таксама актыўна задзейнічае графічныя працэсары. Google Cloud дазваляе вельмі эфектыўна выкарыстоўваць іх проста ў кластарах Kubernetes.
У той час інфраструктурная каманда пераважна канцэнтравалася на старым стэку, разгорнутым на фізічных серверах. Менавіта таму выкарыстанне кіраванага сэрвісу (уключаючы майстар-кампаненты Kubernetes) адпавядала нашым патрабаванням і дазваляла навучыць каманды працы з лакальнымі кластарамі.
У выніку мы змаглі пачаць прымаць production-трафік на інфраструктуры Google Cloud усяго праз 6 месяцаў пасля пачатку працы.
Аднак нягледзячы на шэраг пераваг, праца з хмарным правайдэрам спалучаная з вызначанымі выдаткамі, якія могуць павялічвацца ў залежнасці ад нагрузкі. Вось чаму мы ўважліва аналізавалі кожны выкарыстоўваны кіраваны сэрвіс, разлічваючы ў будучыні рэалізаваць іх у сябе on-premises. Насамрэч укараненне лакальных кластараў пачалося ў канцы 2016 года і тады ж была ініцыяваная гібрыдная стратэгія.
Запуск лакальнай платформы аркестрацыі кантэйнераў Dailymotion
Восень 2016-га
Ва ўмовах, калі ўвесь стэк быў гатовы да production, а праца над API , быў час сканцэнтравацца на рэгіянальных кластарах.
На той момант карыстачы штомесяц праглядалі больш за 3 млрд відэаролікаў. Вядома, у нас ужо не адзін год функцыянавала ўласная разгалінаваная Content Delivery Network. Мы хацелі скарыстацца гэтай акалічнасцю і разгарнуць кластары Kubernetes у існуючых ЦАДах.
Інфраструктура Dailymotion налічвала больш за 2,5 тыс. сервераў у шасці дата-цэнтрах. Усе яны канфігуруюцца з дапамогай Saltstack. Мы пачалі рыхтаваць усе неабходныя рэцэпты для стварэння майстар-і worker-вузлоў, а таксама кластара etcd.
Сеткавая частка
Наша сетка цалкам маршрутызаваная. Кожны сервер анансуе свой IP у сетцы з дапамогай Exabgp. Мы параўналі некалькі сеткавых убудоў і адзіным якія задавальняюць усім запатрабаванням (з-за выкарыстоўванага падыходу на ўзроўні L3) апынуўся . Ён цудоўна ўпісаўся ў існуючую сеткавую мадэль інфраструктуры.
Паколькі жадалася выкарыстаць усе наяўныя элементы інфраструктуры, першым чынам трэба было разабрацца з нашай дамарослай сеткавай утылітай (выкарыстоўванай на ўсіх серверах): скарыстацца ёй для анансавання дыяпазонаў IP-адрасоў у сетцы з Kubernetes-вузламі. Мы дазволілі Calico прысвойваць IP-адрасы pod'ам, але не выкарыстоўвалі яго і да гэтага часу не выкарыстоўваем для BGP-сесій на сеткавым абсталяванні. Па факце маршрутызацыяй займаецца Exabgp, які анансуе падсеткі, якія выкарыстоўваюцца Calico. Гэта дазваляе нам дастукацца да любога pod'у з унутранай сеткі (і ў прыватнасці ад балансавальнікаў нагрузкі).
Як мы кіруем ingress-трафікам
Для перанакіравання ўваходзячых запытаў на патрэбны сэрвіс было вырашана выкарыстоўваць Ingress Controller з-за яго інтэграцыі з ingress-рэсурсамі Kubernetes.
Тры гады таму nginx-ingress-controller быў найболей спелым кантролерам: Nginx выкарыстоўваўся ўжо даўно і быў вядомы сваёй стабільнасцю і прадукцыйнасцю.
У сваёй сістэме мы вырашылі размясціць кантролеры на выдзеленых 10-гігабітных блейд-серверах. Кожны кантролер падлучаўся да endpoint'у kube-apiserver які адпавядае кластара. На гэтых серверах таксама выкарыстоўваўся Exabgp для анансавання публічных ці прыватных IP-адрасоў. Тапалогія нашай сеткі дазваляе выкарыстоўваць BGP з гэтых кантролераў для маршрутызацыі ўсяго трафіку непасрэдна на pod'ы без выкарыстання сэрвісу тыпу NodePort. Такі падыход дапамагае пазбегнуць гарызантальнага трафіку паміж вузламі і павялічвае эфектыўнасць.
Рух трафіку з інтэрнэту да pod'
Цяпер, калі разабраліся з нашай гібрыднай платформай, можна паглыбіцца ў сам працэс міграцыі трафіку.
Міграцыя трафіку з Google Cloud у інфраструктуру Dailymotion
Восень 2018-га
Пасля амаль двух гадоў стварэння, тэсціравання і налады мы, нарэшце, атрымалі поўны стэк Kubernetes, гатовы прыняць частку трафіку.
Бягучая стратэгія маршрутызацыі даволі простая, але цалкам задавальняе запатрабаванням. Апроч агульнадаступных IP (у Google Cloud і Dailymotion) выкарыстоўваецца AWS Route 53 для задання палітык і перанакіраванні карыстальнікаў да кластара па нашым выбары.
Прыклад палітыкі маршрутызацыі з выкарыстаннем Route 53
З Google Cloud гэта проста, паколькі мы задзейнічаем адзіны IP для ўсіх кластараў, а карыстач перанакіроўваецца да найблізкага кластара GKE. Для нашых кластараў тэхналогія іншая, паколькі іх IP адрозніваюцца.
У час міграцыі мы імкнуліся да перанакіравання рэгіянальных запытаў на адпаведныя кластары і ацэньвалі перавагі такога падыходу.
Паколькі нашы GKE-кластары сканфігураваны на аўтаматычнае маштабаванне з дапамогай Custom Metrics, яны нарошчваюць/скарачаюць магутнасці ў залежнасці ад уваходнага трафіку.
У нармальным рэжыме ўвесь рэгіянальны трафік накіроўваецца на лакальны кластар, а GKE служыць рэзервам на выпадак узнікнення праблем (health-check'і праводзяцца Route 53).
...
У будучыні мы хочам поўнасцю аўтаматызаваць палітыкі маршрутызацыі, каб атрымаць аўтаномную гібрыдную стратэгію, якая пастаянна паляпшае даступнасць для карыстальнікаў. Што да плюсаў: значна скараціліся выдаткі на воблака і атрымалася нават скараціць час рэакцыі API. Мы давяраем атрыманай хмарнай платформе і гатовыя пры неабходнасці перанакіраваць на яе больш трафіку.
PS ад перакладчыка
Магчыма, вас яшчэ зацікавіць іншая нядаўняя публікацыя Dailymotion пра Kubernetes. Яна прысвечана дэплою прыкладанняў з Helm на мностве Kubernetes-кластэраў і каля месяца таму.
Чытайце таксама ў нашым блогу:
- «.
- «»;
- «»;
- «»;
- «»;
- «»;
- «»;
- «»;
- «»;
- «»;
- «.
Крыніца: habr.com