Прим. перев.: 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) відповідало нашим вимогам і дозволяло навчити команди роботі з локальними кластерами.
В результаті ми змогли почати приймати 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) виявився . Він чудово вписався у існуючу мережеву модель інфраструктури.
Оскільки хотілося використовувати всі наявні елементи інфраструктури, передусім треба було розібратися з нашою доморощеною мережевою утилітою (яка використовується на всіх серверах): скористатися нею для анонсування діапазонів 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. Ми довіряємо хмарній платформі, що вийшла, і готові при необхідності перенаправити на неї більше трафіку.
PS від перекладача
Можливо, вас ще зацікавить інша нещодавня публікація Dailymotion про Kubernetes. Вона присвячена деплою додатків з Helm на множині Kubernetes-кластерів і близько місяця тому.
Читайте також у нашому блозі:
- «».
- «»;
- «»;
- «»;
- «»;
- «»;
- «»;
- «»;
- «»;
- «»;
- «».
Джерело: habr.com