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

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

Принимая решение о перестройке основного API Dailymotion три года назад, мы хотели разработать более эффективный способ размещения приложений и облегчить процессы в разработке и production. Для этой цели мы решили использовать платформу оркестрации контейнеров и естественным образом выбрали Kubernetes.

Почему стоит создавать собственную платформу на базе Kubernetes?

API production-уровня в кратчайшие сроки с помощью Google Cloud

Лето 2016-го

Три года назад, сразу после покупки Dailymotion компанией Vivendi, наши инженерные команды сфокусировались на одной глобальной цели: создать совершенно новый продукт Dailymotion.

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

С точки зрения инфраструктуры требовалась мощная и гибкая система для размещения новых типов облачных (cloud-native) приложений. Мы предпочли остаться в облаке в начале нашего путешествия, чтобы спокойно построить максимально надежную локальную платформу. Свои приложения решили развертывать с помощью Google Kubernetes Engine, хотя знали, что рано или поздно перейдем на собственные ЦОД и применим гибридную стратегию.

Почему выбрали GKE?

Мы сделали этот выбор главным образом по техническим соображениям. Кроме того, требовалось быстро предоставить инфраструктуру, отвечающую нуждам бизнеса компании. У нас были некоторые требования к размещению приложений, такие как географическая распределенность, масштабируемость и отказоустойчивость.

Кластеры GKE в Dailymotion

Поскольку Dailymotion — видеоплатформа, доступная по всему миру, мы очень хотели повысить качество сервиса, сократив время ожидания (latency). Ранее наш API был доступен только в Париже, что было неоптимально. Хотелось иметь возможность размещать приложения не только в Европе, но и в Азии, и в США.

Эта чувствительность к задержкам означала, что придется серьезно поработать над сетевой архитектурой платформы. В то время как большинство облачных сервисов вынуждали создавать свою сеть в каждом регионе и потом связывать их через 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) оказался 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-кластеров и была опубликована около месяца назад.

Читайте также в нашем блоге:

Источник: habr.com