Хабрахабр

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

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

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

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

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

Лето 2016-го

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

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

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

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

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


Кластеры GKE в Dailymotion

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

В то время как большинство облачных сервисов вынуждали создавать свою сеть в каждом регионе и потом связывать их через VPN или некий управляемый сервис, Google Cloud позволял создать полностью маршрутизируемую единую сеть, охватывающую все регионы Google. Эта чувствительность к задержкам означала, что придется серьезно поработать над сетевой архитектурой платформы. Это большой плюс в смысле эксплуатации и эффективности системы.

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


Мониторинг балансировки нагрузок в Google

Google Cloud позволяет весьма эффективно использовать их прямо в кластерах Kubernetes. Наша платформа также активно задействует графические процессоры.

Именно поэтому использование управляемого сервиса (включая мастер-компоненты Kubernetes) отвечало нашим требованиям и позволяло обучить команды работе с локальными кластерами. В то время инфраструктурная команда преимущественно концентрировалась на старом стеке, развернутом на физических серверах.

В результате мы смогли начать принимать production-трафик на инфраструктуре Google Cloud всего через 6 месяцев после начала работы.

Вот почему мы внимательно анализировали каждый используемый управляемый сервис, рассчитывая в будущем реализовать их у себя on-premises. Однако несмотря на ряд преимуществ, работа с облачным провайдером сопряжена с определенными затратами, которые могут увеличиваться в зависимости от нагрузки. На самом деле внедрение локальных кластеров началось в конце 2016 года и тогда же была инициирована гибридная стратегия.

Запуск локальной платформы оркестрации контейнеров Dailymotion

Осень 2016-го

В условиях, когда весь стек был готов к production, а работа над API продолжалась, было время сконцентрироваться на региональных кластерах.

Конечно, у нас уже не один год функционировала собственная разветвленная Content Delivery Network. На тот момент пользователи ежемесячно просматривали более 3 млрд видеороликов. Мы хотели воспользоваться этим обстоятельством и развернуть кластеры Kubernetes в существующих ЦОДах.

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

Сетевая часть

Наша сеть полностью маршрутизируемая. Каждый сервер анонсирует свой IP в сети с помощью Exabgp. Мы сравнили несколько сетевых плагинов и единственным удовлетворяющим всем потребностям (из-за используемого подхода на уровне L3) оказался Calico. Он прекрасно вписался в существующую сетевую модель инфраструктуры.

Мы позволили Calico присваивать IP-адреса pod'ам, но не использовали его и до сих пор не используем для BGP-сессий на сетевом оборудовании. Поскольку хотелось использовать все имеющиеся элементы инфраструктуры, прежде всего предстояло разобраться с нашей доморощенной сетевой утилитой (используемой на всех серверах): воспользоваться ей для анонсирования диапазонов IP-адресов в сети с Kubernetes-узлами. Это позволяет нам достучаться к любому pod'у из внутренней сети (и в частности от балансировщиков нагрузки). По факту маршрутизацией занимается Exabgp, который анонсирует подсети, используемые Calico.

Как мы управляем ingress-трафиком

Для перенаправления входящих запросов на нужный сервис было решено использовать Ingress Controller из-за его интеграции с ingress-ресурсами Kubernetes.

Три года назад nginx-ingress-controller был наиболее зрелым контроллером: Nginx использовался уже давно и был известен своей стабильностью и производительностью.

Каждый контроллер подключался к endpoint'у kube-apiserver соответствующего кластера. В своей системе мы решили разместить контроллеры на выделенных 10-гигабитных блейд-серверах. Топология нашей сети позволяет использовать BGP из этих контроллеров для маршрутизации всего трафика непосредственно на pod'ы без использования сервиса типа NodePort. На этих серверах также использовался Exabgp для анонсирования публичных или частных IP-адресов. Такой подход помогает избежать горизонтального трафика между узлами и повышает эффективность.


Движение трафика из интернета к pod'ам

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

Миграция трафика из Google Cloud в инфраструктуру Dailymotion

Осень 2018-го

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

Помимо общедоступных IP (в Google Cloud и Dailymotion) используется AWS Route 53 для задания политик и перенаправления пользователей к кластеру по нашему выбору. Текущая стратегия маршрутизации довольно проста, но вполне удовлетворяет потребностям.


Пример политики маршрутизации с использованием Route 53

Для наших кластеров технология другая, поскольку их IP отличаются. С Google Cloud это просто, поскольку мы задействуем единый IP для всех кластеров, а пользователь перенаправляется к ближайшему кластеру GKE.

Во время миграции мы стремились к перенаправлению региональных запросов на соответствующие кластеры и оценивали преимущества такого подхода.

Поскольку наши GKE-кластеры сконфигурированы на автоматическое масштабирование с помощью Custom Metrics, они наращивают/сокращают мощности в зависимости от входящего трафика.

В нормальном режиме весь региональный трафик направляется на локальный кластер, а GKE служит резервом на случай возникновения проблем (health-check'и проводятся Route 53).

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

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

Возможно, вас еще заинтересует другая недавняя публикация Dailymotion про Kubernetes. Она посвящёна деплою приложений с Helm на множестве Kubernetes-кластеров и была опубликована около месяца назад.

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть