Прим. прев.: 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) отговаряше на нашите изисквания и ни позволяваше да обучим екипите да работят с локални клъстери.
В резултат на това успяхме да започнем да приемаме продукционен трафик на инфраструктурата на Google Cloud само 6 месеца след началото на работата.
Но въпреки редица предимства, работата с облачен доставчик е свързана с определени разходи, които могат да нарастват в зависимост от натоварването. Ето защо внимателно анализирахме всяка използвана управлявана услуга, планирайки в бъдеще да ги реализираме на място. Всъщност внедряването на локални клъстери започна в края на 2016 г., когато също така беше иницирана хибридна стратегия.
Стартиране на локална платформа за оркестрация на контейнери Dailymotion
Есента на 2016 г.
В условия, при които целият стек беше готов за продукция, а работата по API , имаше време да се концентрираме върху регионалните клъстери.
По това време потребителите ежемесечно преглеждаха над 3 милиарда видеоклипове. Разбира се, вече години наред функционираше собствена разширена мрежа за доставка на съдържание. Искахме да се възползваме от тази обстановка и да разгръщаме Kubernetes клъстери в съществуващите ни ЦОД.
Инфраструктурата на Dailymotion включваше над 2500 сървъра в шест дата центъра. Всички те се конфигурират с помощта на Saltstack. Започнахме да подготвяме всички необходими рецепти за създаването на master и worker възли, както и на клъстера etcd.
Мрежовата част
Нашата мрежа е напълно маршрутизируема. Всеки сървър анонсира своя IP в мрежата с помощта на Exabgp. Сравнихме няколко мрежови плагина и единственият, който отговаряше на всички задоволителни нужди (поради използвания подход на ниво L3), беше . Той прекрасно се вписа в съществуващата мрежова модел на инфраструктурата.
Тъй като искахме да използваме всички налични елементи от инфраструктурата, първо трябваше да разберем нашата местна мрежова утилита (използвана на всички сървъри): да се възползваме от нея за анонсиране на диапазоните на IP адресите в мрежата с Kubernetes възлите. Позволихме на Calico да присвоява IP адреси на pod’овете, но не я използвахме и все още не използваме за BGP сесиите на мрежовото оборудване. Всъщност, маршрутизацията се извършва от Exabgp, който анонсира подсетите, използвани от Calico. Това ни позволява да достигнем до всеки pod от вътрешната мрежа (в частност от балансировачите на натоварването).
Как управляваме ingress трафика
За пренасочване на входящите заявки към нужната услуга решихме да използваме Ingress Controller поради неговата интеграция с ingress ресурсите на Kubernetes.
Три години назад nginx-ingress-controller беше най-зрелият контролер: Nginx се използваше отдавна и беше известен с устойчивостта и производителността си.
В нашата система решихме да разположим контролери на специализирани 10-гигабитни blade-сървъри. Всеки контролер се свързваше с 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 клъстери и преди около месец.
Прочетете също в нашия блог:
- «».
- «»;
- «»;
- «»;
- «»;
- «»;
- «»;
- «»;
- «»;
- «»;
- «».
Източник: habr.com
