🥇Kubernetes приключения на Dailymotion: създаване на инфраструктура в облака + on-premises

Прим. прев.: Dailymotion — една от най-големите платформи за хостинг на видео в света и съответно значителен потребител на Kubernetes. В този материал системният архитект David Donchez споделя резултатите от създаването на производствена платформа на компанията на базата на K8s, която започна като облачна инсталация в GKE и завърши като хибридно решение, което позволи да се постигне по-добро време за реакция и да се спестят инфраструктурни разходи.

Взимайки решение за преструктуриране на основния API Dailymotion преди три години, ние искахме да разработим по-ефективен начин за разполагане на приложения и да улесним процесите в разработката и производствената среда. С целта да постигнем това, решихме да използваме платформата за оркестрация на контейнери и естествено избрахме Kubernetes.

Защо си струва да създадете собствена платформа на базата на Kubernetes?

API на производствено ниво в най-кратки срокове с помощта на Google Cloud

Летото на 2016 г.

Преди три години, веднага след закупуването на Dailymotion от Vivendi, нашите инженерни екипи се фокусираха върху една глобална цел: да създадат напълно нов продукт на Dailymotion.

След анализа на контейнерите, решенията за оркестрация и нашия предишен опит, ние се уверихме, че Kubernetes е правилният избор. Част от разработчиците вече имаха представа за основните концепции и знаеха как да го използват, което беше огромно предимство за инфраструктурната трансформация.

От гледна точка на инфраструктурата, беше необходима мощна и гъвкава система за разполагане на нови типове облачни приложения. Предпочетохме да останем в облака в началото на нашето пътуване, за да изградим максимално надеждна локална платформа. Решихме да разгръщаме своите приложения с помощта на Google Kubernetes Engine, въпреки че знаехме, че рано или късно ще преминем към собствени ЦОД и ще приложим хибридна стратегия.

Защо избрахме GKE?

Направихме този избор главно по технически съображения. Освен това беше необходимо бързо да предоставим инфраструктура, отговаряща на нуждите на бизнеса на компанията. Имахме някои изисквания за разполагане на приложения, като географска разпределеност, мащабируемост и отказоустойчивост.

Клъстери GKE в Dailymotion

Тъй като Dailymotion е видеоплатформа, достъпна по целия свят, много искахме да повишим качеството на услугата, като намалим времето за изчакване (latency). По-рано нашия API беше достъпен само в Париж, което не беше оптимално. Искахме да можем да разполагаме приложения не само в Европа, но и в Азия и САЩ.

Тази чувствителност към закъсненията означаваше, че ще трябва да работим сериозно върху мрежовата архитектура на платформата. Докато повечето облачни услуги изискваха изграждане на собствена мрежа във всеки регион и след това свързването им чрез VPN или някаква управлявана услуга, Google Cloud позволяваше да се създаде напълно маршрутизируема едина мрежа, обхващаща всички региони на Google. Това е голямо предимство по отношение на експлоатацията и ефективността на системата.

Освен това мрежовите услуги и балансировачите на натоварването от Google Cloud се справят отлично с работата си. Те просто позволяват използването на произволни публични IP адреси от всеки регион, а страхотният протокол BGP се грижи за всичко останало (т.е. пренасочва потребителите към най-близкия клъстер). Очевидно е, че в случай на повреда, трафикът автоматично ще премине в друг регион без никакво човешко вмешателство.

Наблюдение на балансирането на натоварванията в Google

Нашата платформа също активно използва графични процесори. Google Cloud позволява изключително ефективно използване на тях директно в клъстерите Kubernetes.

В същото време инфраструктурният екип предимно се фокусираше върху стария стек, внедрен на физически сървъри. Затова използването на управлявана услуга (включително основни компоненти на Kubernetes) отговаряше на нашите изисквания и позволяваше на екипите да овладеят работата с локалните клъстери.

В резултат на това успяхме да започнем да приемаме продукционен трафик на инфраструктурата на Google Cloud само шест месеца след началото на работата.

Но въпреки редица предимства, работата с облачен доставчик носи със себе си определени разходи, които могат да нарастват в зависимост от натоварването. Ето защо внимателно анализирахме всяка използвана управлявана услуга, планирайки в бъдеще да ги реализираме локално. Всъщност внедряването на локални клъстери започна в края на 2016 година и тогава беше инициирана хибридна стратегия.

Стартиране на локална платформа за оркестрация на контейнери Dailymotion

Есента на 2016 г.

В условията, при които целият стек беше готов за продукция, а работата по API продължи, дойде време да се концентрираме върху регионалните клъстери.

По онова време потребителите ежемесечно преглеждаха над 3 млрд. видеоклипове. Разбира се, вече не една година функционираше наша разширена Content Delivery Network. Искахме да се възползваме от това и да развернем Kubernetes клъстери в съществуващите ЦОД.

Инфраструктурата на Dailymotion се състои от над 2,5 хил. сървъра в шест дата центрове. Всички те се конфигурират с помощта на Saltstack. Започнахме да подготвяме всички необходими рецепти за създаване на master- и worker-узли, както и кластер etcd.

Мрежова част

Нашата мрежа е напълно маршрутизируема. Всеки сървър обявява своя IP в мрежата с помощта на Exabgp. Сравнихме няколко мрежови плагина и единственият, който удовлетворяваше всички изисквания (поради използвания подход на ниво L3), беше Calico. Той се вписа отлично в съществуващата мрежова модел на инфраструктурата.

Тъй като искахме да използваме всички налични елементи от инфраструктурата, най-напред трябваше да се разберем с нашето домашно направено мрежово приложение (използвано на всички сървъри): да го използваме за обявяване на диапазони от 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. Доверяваме се на получената облачна платформа и сме готови, ако е необходимо, да пренасочим повече трафик към нея.

P.S. от преводача

Възможно е да се заинтересувате и от друга наскоро публикувана статия в Dailymotion за Kubernetes. Тя е посветена на разгръщането на приложения с Helm на множество Kubernetes клъстери и беше публикувана преди около месец.

Прочетете също в нашия блог: