Истории успеха Kubernetes в production. Часть 6: BlaBlaCar

Истории успеха Kubernetes в production. Часть 6: BlaBlaCar

Основанный в 2006 году BlaBlaCar считается крупнейшим в мире онлайн-сервисом поиска автомобильных попутчиков (ridesharing). Появившись во Франции, сервис прошёл активную экспансию в Европе, с 2014 года стал доступен в России и Украине, а позже добрался до стран Латинской Америки и Азии. Рост популярности онлайн-сервисов неизбежно связан с развитием стоящей за ними ИТ-инфраструктуры, и, как легко догадаться из названия статьи, сегодняшние потребности BlaBlaCar реализуются благодаря Kubernetes. К чему же пришли ИТ-инженеры компании?

Предыстория

В феврале 2016 года в блоге BlaBlaCar опубликовали заметку с рассказом о своём пути к контейнерам. Вся инфраструктура компании изначально строилась на своих серверах (bare metal), которые со временем (по мере роста вычислительных ресурсов) были сведены к нескольким типовым конфигурациям.

Для управления всеми программными службами на этих серверах долгое время использовался Chef с налаженным рабочим процессом, включающим в себя code review, тестирование и т.п. Для изоляции сервисов, не являющихся особенно требовательными к производительности (для нужд тестирования, pre-production и других), — кластер на основе VMware. Проблемы с ним описывались как сложность автоматизации, недостаточная производительность (по сравнению с bare metal) и высокая стоимость (когда речь идёт о большом количестве узлов). Тогда-то в BlaBlaCar и решили, не рассматривая другие «классические» варианты виртуализации, сразу перейти на контейнеры. В качестве дополнительного фактора в пользу контейнеров приводится возможность быстрого выделения ресурсов.

2015—2016: переход на контейнеры

В качестве контейнерного решения в BlaBlaCar выбрали… нет, не Docker, а rkt. Причиной тому стало «осознание существовавших в то время ограничений продукта, которые были очень важны для использования в production». И так уж совпало, что во время их экспериментов с контейнерами проект CoreOS анонсировал свою разработку — исполняемую среду для контейнеров rkt (известную тогда как Rocket).

Незадолго до этого инженеры BlaBlaCar успели полюбить операционную систему CoreOS (впоследствии именно на ней и остановились в качестве основной для контейнерной инфраструктуры), поэтому решили попробовать новый продукт того же проекта. И результат им понравился: «Мы были удивлены стабильности rkt даже в самых ранних её версиях, а все важные нужные нам функции были оперативно добавлены командой CoreOS».

Примечание: BlaBlaCar и на сегодняшний день остаётся в числе не таких уж многочисленных именитых пользователей rkt в production. Их официальный список можно найти на сайте CoreOS.

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

  • быстрая сборка;
  • простота понимания для новых сотрудников;
  • минимально возможная репликация кода;
  • шаблоны, применяющиеся при запуске контейнера;
  • хорошая интеграция с rkt.

Общая схема работы dgr представляется следующим образом:

А непосредственное использование утилиты демонстрируется так:

Для оркестровки требовалось самое простое решение (не было времени на эксперименты с большими системами), поэтому выбор пал на стандартный инструмент всё того же CoreOS — fleet. В помощь к нему, для автоматизированного создания всех systemd units (на основе имеющегося в файловой системе описания окружений и сервисов в них), была разработана утилита GGN (green-garden).

Итог этапа в BlaBlaCar — переход от идеи использования контейнеров до запуска в них более 90 % production-сервисов за 7 месяцев. Большое желание продолжать использовать Chef — надёжный инструмент, в работу с которым инженеры вложили много времени, — пришлось скорректировать с пониманием, что «классические инструменты управления конфигурациями не подходят для сборки контейнеров и управления ими».

2016—2017: актуальная инфраструктура и переход на Kubernetes

Обновлённые сведения об инфраструктуре компании появились совсем недавно — в конце прошлого месяца — в публикации «The Expendables — Backends High Availability at BlaBlaCar» от инженера BlaBlaCar. За минувшие почти 2 года в компании пришли к концепции «расходников» (expendables) в инфраструктуре, которая схожа с известной историей про скот и домашних животных (cattle vs. pets).

Общая суть сводится к тому, что каждый компонент инфраструктуры должен быть готов к рестарту в любой момент времени и не влиять при этом на работу приложений. Очевидно, что особая сложность при реализации такого подхода появляется у администраторов СУБД, так что вдвойне примечательно, что об опыте BlaBlaCar рассказывает соответствующий специалист — Maxime Fouilleul, занимающий позицию Database Engineer.

Итак, актуальная инфраструктура компании имеет следующий вид:

Все ACIs (Application Container Images) и PODs создаются и собираются с помощью уже упомянутой разработки компании — dgr. После сборки в системе непрерывной интеграции PODs попадают в центральный реестр и готовы к использованию. Для их запуска на серверах применяется специальный стек, названный Distributed Units System и основанный на fleet и etcd. Его предназначение — распределённый запуск обычных systemd units по всему дата-центру, как будто это происходит на локальной машине. Для указания целевого хоста в unit-файл добавляются специальные метаданные — например, это актуально для MySQL, инсталляция которой привязывается к конкретному серверу.

Примечание: СУБД в BlaBlaCar начиналась с асинхронной репликации в MySQL, однако — из-за сложностей восстановления при падении мастера (т.к. это единая точка отказа) и необходимости отслеживать задержку репликации в приложениях (иначе неконсистентные данные) — со временем перешли на синхронную репликацию на базе кластера Galera. На сегодняшний день в production используют MariaDB и Galera: такой вариант позволяет рассматривать все узлы с MySQL одинаковыми «расходниками», что актуально для экосистемы, построенной на контейнерах.

Наконец, для генерации и деплоя systemd units в компании используют другую (уже упомянутую) свою разработку — ggn. А сейчас инженеры работают над стандартизацией оркестровки своих PODs на базе Kubernetes.

Service discovery

Задачу обнаружения сервисов (service discovery) в BlaBlaCar по праву считают одним из ключей для построения отказоустойчивой и масштабируемой инфраструктуры. Чтобы добиться этого, в компании переписали на язык Go специализированный фреймворк от Airbnb — SmartStack. В его основе — два компонента:

  • go-nerve — утилита для отслеживания состояния сервисов, запускающая различные проверки (по протоколам TCP и HTTP, системными вызовами, исполнением SQL-команд и т.п.) и сообщающая об их результатах в соответствующие системы; запускается на каждом экземпляре сервиса (более 2000 в BlaBlaCar) и передаёт состояние в хранилище Apache ZooKeeper;
  • go-synapse — механизм непосредственного обнаружения сервисов, наблюдающий за сервисами (отслеживает значения ключей, хранимых в ZooKeeper) и обновляющий их состояние в маршрутизаторе (на базе HAProxy).

Nerve для MySQL ( env/prod-dc1/services/mysql-main/attributes/nerve.yml ):

Результат в ZooKeeper:

И настройки в Synapse ( env/prod-dc1/services/tripsearch/attributes/synapse.yml ):

Kubernetes в BlaBlaCar. Enjoliver

Согласно интервью от апреля 2017 года, внедрение Kubernetes в BlaBlaCar происходило постепенно, и первые компоненты в production запустили «3 месяца назад». Однако, несмотря на неоднократные упоминания Kubernetes в инфраструктуре, подробностей о его устройстве в имеющихся статьях не так много. Пролить свет на этот вопрос помогает ещё один проект BlaBlaCar на GitHub — Enjoliver.

Enjoliver (от франц. слова «приукрасить») описывается как инструмент для «деплоя и поддержки годного к употреблению кластера Kubernetes». Свою публичную историю он ведёт с октября 2016 года, а основной его исходный код (включая его Engine и API) написан на Python. В качестве исполняемой среды для контейнеров в Enjoliver применяется, как все уже догадались, rkt от CoreOS, а также в кластере задействованы CoreOS Container Linux, Fleet, CNI и Vault. Общая архитектура представляется следующим образом:

Авторы выделяют четыре главных области работы/развития Enjoliver:

  1. конфигурация ролей кластера Kubernetes (control plane и узлы);
  2. топология обнаружения сервисов, планирование ролей в Kubernetes и поддержка жизненного цикла кластера — за это отвечает Enjoliver Engine;
  3. e2e-тестирование Enjoliver;
  4. применение Kubernetes для целей разработки, включающее в себя готовые примеры использования Helm / Tiller, Heapster, Kubernetes Dashboard, Prometheus, Vault UI, CronJobs для бэкапов etcd.

Наконец, дополнительные сведения о применении Kubernetes в BlaBlaCar стали доступны из case study, написанного со слов инженера по инфраструктуре компании (Simon Lallemand) и опубликованного на сайте Kubernetes. В частности, там сообщается о следующем:

📎📎📎📎📎📎📎📎📎📎