Забележка. превод: Dailymotion е една от най-големите услуги за видео хостинг в света и следователно забележителен потребител на Kubernetes. В този материал системният архитект Дейвид Дончез споделя резултатите от създаването на производствената платформа на компанията, базирана на K8s, която започна с облачна инсталация в GKE и завърши като хибридно решение, което позволи по-добро време за реакция и спестяване на инфраструктурни разходи.
Вземане на решение за възстановяване на основния API преди три години искахме да разработим по-ефективен начин за хостване на приложения и да го направим по-лесен . За тази цел решихме да използваме платформа за оркестриране на контейнери и естествено избрахме Kubernetes.
Защо си струва да създадете своя собствена платформа, базирана на Kubernetes?
API на производствено ниво за нула време с помощта на Google Cloud
Лято 2016
Преди три години, веднага след като Dailymotion беше закупен от , нашите инженерни екипи са фокусирани върху една глобална цел: да създадат изцяло нов продукт Dailymotion.
Въз основа на нашия анализ на контейнери, решения за оркестрация и нашия минал опит, ние сме убедени, че Kubernetes е правилният избор. Някои разработчици вече имаха разбиране за основните концепции и знаеха как да ги използват, което беше огромно предимство за трансформацията на инфраструктурата.
От гледна точка на инфраструктурата беше необходима мощна и гъвкава система за хостване на нови типове облачни приложения. Избрахме да останем в облака в началото на нашето пътуване, за да можем да изградим възможно най-стабилната локална платформа със спокойствие. Решихме да разположим нашите приложения с помощта на Google Kubernetes Engine, въпреки че знаехме, че рано или късно ще се преместим в нашите собствени центрове за данни и ще приложим хибридна стратегия.
Защо избрахте GKE?
Направихме този избор главно поради технически причини. Освен това беше необходимо бързо да се осигури инфраструктура, която да отговаря на бизнес нуждите на компанията. Имахме някои изисквания за хостинг приложения, като географско разпределение, мащабируемост и устойчивост на грешки.
GKE клъстери в Dailymotion
Тъй като Dailymotion е видео платформа, достъпна в цял свят, ние наистина искахме да подобрим качеството на услугата, като намалим времето за чакане (латентност). Преди това беше наличен само в Париж, което беше неоптимално. Исках да мога да хоствам приложения не само в Европа, но и в Азия и САЩ.
Тази чувствителност към латентност означаваше, че ще трябва да се направи сериозна работа върху мрежовата архитектура на платформата. Докато повечето облачни услуги ви принуждаваха да създадете своя собствена мрежа във всеки регион и след това да ги свържете чрез VPN или някакъв вид управлявана услуга, Google Cloud ви позволи да създадете напълно маршрутизирана единична мрежа, покриваща всички региони на Google. Това е голям плюс по отношение на работата и ефективността на системата.
Освен това мрежовите услуги и балансьорите на натоварването от Google Cloud вършат отлична работа. Те просто ви позволяват да използвате произволни публични IP адреси от всеки регион, а прекрасният BGP протокол се грижи за останалото (т.е. пренасочване на потребителите към най-близкия клъстер). Очевидно в случай на повреда трафикът автоматично ще премине към друг регион без човешка намеса.
Мониторинг на Google Load Balancing
Нашата платформа също използва интензивно GPU. Google Cloud ви позволява да ги използвате много ефективно директно в клъстерите на Kubernetes.
По това време инфраструктурният екип беше фокусиран основно върху наследения стек, разположен на физически сървъри. Ето защо използването на управлявана услуга (включително Kubernetes masters) изпълни изискванията ни и ни позволи да обучим екипи да работят с локални клъстери.
В резултат на това успяхме да започнем да получаваме производствен трафик в инфраструктурата на Google Cloud само 6 месеца след началото на работата.
Но въпреки редица предимства, работата с облачен доставчик е свързана с определени разходи, които могат да се увеличат в зависимост от натоварването. Ето защо внимателно анализирахме всяка управлявана услуга, която използвахме, надявайки се да ги внедрим на място в бъдеще. Всъщност внедряването на местни клъстери започна в края на 2016 г. и едновременно с това беше инициирана хибридната стратегия.
Стартиране на локална платформа за оркестриране на контейнери Dailymotion
Есента на 2016 г
В условия, когато целият стек е готов за производство и работи върху API , беше време да се концентрираме върху регионалните клъстери.
По това време потребителите са гледали повече от 3 милиарда видеоклипа всеки месец. Разбира се, ние разполагаме със собствена обширна мрежа за доставка на съдържание от много години. Искахме да се възползваме от това обстоятелство и да внедрим клъстери на Kubernetes в съществуващи центрове за данни.
Инфраструктурата на Dailymotion се състоеше от повече от 2,5 хиляди сървъра в шест центъра за данни. Всички те са конфигурирани с помощта на Saltstack. Започнахме да подготвяме всички необходими рецепти за създаване на главни и работни възли, както и клъстер etcd.
Мрежова част
Нашата мрежа е напълно маршрутизирана. Всеки сървър рекламира своето IP в мрежата с помощта на Exabgp. Сравнихме няколко мрежови плъгина и единственият, който задоволи всички нужди (поради използвания L3 подход) беше . Той се вписва перфектно в съществуващия модел на мрежова инфраструктура.
Тъй като искахме да използваме всички налични инфраструктурни елементи, първото нещо, което трябваше да направим, беше да измислим нашата собствена мрежова програма (използвана на всички сървъри): да я използваме за рекламиране на диапазони от IP адреси в мрежата с Kubernetes възли. Позволихме на Calico да присвоява IP адреси на модули, но не го използвахме и все още не го използваме за BGP сесии на мрежово оборудване. Всъщност маршрутизирането се управлява от Exabgp, който рекламира подмрежите, използвани от Calico. Това ни позволява да достигнем до всяка група от вътрешната мрежа (и по-специално от балансиращите на натоварването).
Как управляваме входящия трафик
За пренасочване на входящи заявки към желаната услуга беше решено да се използва Ingress Controller поради неговата интеграция с входните ресурси на Kubernetes.
Преди три години nginx-ingress-controller беше най-зрелият контролер: Nginx съществуваше от дълго време и беше известен със своята стабилност и производителност.
В нашата система решихме да поставим контролерите на специални 10-гигабитови блейд сървъри. Всеки контролер беше свързан към крайната точка на kube-apiserver на съответния клъстер. Тези сървъри също използват Exabgp за рекламиране на публични или частни IP адреси. Нашата мрежова топология ни позволява да използваме BGP от тези контролери, за да насочваме целия трафик директно към модулите, без да използваме услуга като NodePort. Този подход помага да се избегне хоризонталният трафик между възлите и подобрява ефективността.
Движение на трафик от интернет към подс
Сега, след като разбираме нашата хибридна платформа, можем да навлезем по-дълбоко в самия процес на миграция на трафика.
Мигриране на трафик от Google Cloud към Dailymotion инфраструктура
Есента на 2018 г
След почти две години изграждане, тестване и настройка най-накрая имаме пълен стек на Kubernetes, готов да приеме известен трафик.
Настоящата стратегия за маршрутизиране е доста проста, но достатъчна, за да отговори на нуждите. В допълнение към публичните IP адреси (в Google Cloud и Dailymotion), AWS Route 53 се използва за задаване на политики и пренасочване на потребителите към клъстера по наш избор.
Примерна политика за маршрутизиране, използваща Route 53
С Google Cloud това е лесно, тъй като споделяме един IP във всички клъстери и потребителят се пренасочва към най-близкия GKE клъстер. За нашите клъстери технологията е различна, тъй като техните IP адреси са различни.
По време на миграцията се опитахме да пренасочим регионалните заявки към подходящите клъстери и оценихме ползите от този подход.
Тъй като нашите GKE клъстери са конфигурирани за автоматично мащабиране с помощта на персонализирани показатели, те мащабират нагоре/надолу въз основа на входящия трафик.
В нормален режим целият регионален трафик се насочва към локалния клъстер, а GKE служи като резерв в случай на проблеми (здравните проверки се извършват от Route 53).
...
В бъдеще искаме да автоматизираме напълно политиките за маршрутизиране, за да постигнем автономна хибридна стратегия, която непрекъснато подобрява достъпността за потребителите. Положителната страна е, че разходите за облак са значително намалени и времето за отговор на API дори е намалено. Ние се доверяваме на получената облачна платформа и сме готови да пренасочим повече трафик към нея, ако е необходимо.
PS от преводача
Може също да се интересувате от друга скорошна публикация на Dailymotion за Kubernetes. Той е посветен на внедряването на приложения с Helm на много Kubernetes клъстери и преди около месец.
Прочетете също в нашия блог:
- «".
- «»;
- «»;
- «»;
- «»;
- «»;
- «»;
- «»;
- «»;
- «»;
- «".
Източник: www.habr.com