Минимальное сравнение swarm\kubernetes\mesos\nomad\rancher

В прошлой статье мы разобрались зачем нужны оркестраторы, теперь осталось понять какой их них лучше подходит под наши задачи.

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

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

Вступительное описание

Swarm

Разработан докером в отчаянной попытке не вылететь из мира контейнеров, который он же и создал. По субъективным ощущениям это второй по популярности оркестратор.

Mesos

Изначально оркестратор для java vm. Сейчас работает и с контейнерами. Монстр-убийца, супергибкий, легко писать свои модули для всяких странных штук. Поверх месоса можно иметь разные шедулеры (в том числе и самописные). Шедулеры занимаются тем, что запускают контейнеры. Самые популярные шедулеры — Marathon и Aurora.

Kubernetes

Написан гуглом, похож на оркестратор, который использует гугл внутри компании, но не он. Очень популярный.

Nomad

Оркестратор от hashicorp для тех, кто подсел на хашикорповский стек. Работает не только с docker, большой упор сделан на поддержку серьезных сетапов и мультидатацентр.

Rancher

Красивый GUI, оркестрация контейнеров для новичков. Работает на своём движке Cattle, поддерживает работу поверх swarm\kubernetes\mesos, правда, с ограничениями.

Сеть

Лучше всего сеть в докере работает в режиме --net=host, но в оркестраторах, из-за необходимости запускать множество приложений на одном хосте, этот вариант не прокатывает.

Swarm

Нативная сеть в swarm не очень хорошая тест от percona и ещё один тест, хотя для бытовых задач в принципе хватает. Сети создаются достаточно просто.
Из необычного и удобного — возможность делать docker run в сеть в которой крутятся инстансы swarm.

Mesos

По умолчанию определённой сети нет: новые контейнеры не получают свой ip адрес, а регистрируются в zookeeper на каком-то порту, после чего любой желающий может к ним обратиться напрямую или через разные балансеры. Летом 16-го года разработчики таки впилили Container Network Interface (CNI) для Mesos, который позволяет каждому контейнеру получать свой ip адрес при помощи использования разных виртуальных сетей типа calico или weave.

Kubernetes

Работает с виртуальными сетями и поддерживает (ещё бы) сетку от GCE. Как мне показалось, поддерживает самое большое количество разных сетевых решений. Чаще всего поднимают flannel, но в последнее время набирает популярность Romana. В общем, на любой вкус и цвет.

Nomad

По умолчанию просто запускает контейнеры и регистрирует их в consul, но можно настроить на работу вместе с weave. Дискавери по умолчанию работает как в mesos, только с consul вместо zookeeper. Удивительно, правда?

Rancher

Своя сеть, достаточно медленная. Тест 1, тест 2.

Вывод по сети

Мне больше всего понравились сети в кубернетисе. В качестве альтернативы при нагруженной сети можно использовать прямое дискавери в стиле netflix вместе с mesos\nomad. В любом случае, стоит присмотреться и решить, что вам не нужно.
Если вам не нужна высоконагруженная сеть, из которой вы будете выжимать все соки, то подойдёт любой вариант. Если не хотите лишних уровней абстракции и готовы потратить время на переделывание готовых приложений — добро пожаловать в mesos\nomad клуб.

Деплой и запуск

Swarm

Атомарная единица в swarm — это сервис. Сервис представляет собой контейнер с параметрами запуска, такими как сеть и команда. Сервисы можно объединять в стеки — yaml файлы, описывающие группу сервисов. Также начиная с версии 1.13 сервисы можно деплоить прямо из compose файла, что достаточно удобно и быстро.

Mesos

Атомарная единица в месосе — это... хм, зависит от шедулера. Фактически это приводит нас к тому, что при наличии напильника можно сделать вообще что угодно. Мне в своё время понравился пример создания шедулера для kafka консьюмеров. В принципе не могу представить аналогичное решение для любого другого оркестратора.

Mesos: marathon

Можно работать как с отдельными контейнерами, так и с подами — групой контейнеров, которые используют какой-то один ресурс. Например, диск. Ребята из mesosphere предполагают, что поды будут использоваться только как переходной вариант между легаси и микросервисами. Наивные. Впрочем, для обычной группировки они предлагают application groups.

Mesos: aurora

Аврора оперирует только сервисами — это контейнер, который надо держать запущенным и рестартовать, если он упал.

Kubernetes

Атомом в кубернетесе является Pod — контейнер или набор контейнеров, которые будут запущены обязательно на одной ноде. Под описывает, что будет запущено, а для запуска есть несколько разных механизмов. Сейчас рекомендуется использовать Deployments, которые управляют всеми остальными компонентами типа replica sets.

Отдельно стоит отметить возможность создавать daemon sets — обещание, что под будет запущен на каждой ноде в кластере и stateful set – обещание что под по возможности будет пытаться перезапуститься на той же ноде, где был запущен изначально и будет имеет постоянное имя (что является хостнеймом для конечного приложения).

В совокупности с init контейнерами и helm кубернетис может использоваться почти для чего угодно. С другой стороны, большое количество ручек и наименований (в том числе и некоторые legacy штуки) сбивают с толку, и кривая вхождения в kubernetes достаточно кривая.

Nomad

Номад оперирует job-ами, которые представляют собой группы задач, которые должны быть запущены на одном инстансе. Задача может быть как сервисом, так и обычной задачей.
Сами файлы очень простые в написании, тут здорово помогают фирменные доки от hashicorp. Не знаю, кто их пишет, но 5+ за документацию. Лучшей документации для новичков просто не может быть.
Из минусов — нет никакой возможности запустить задачи в какой-то последовательности в рамках одного деплоя. Люди, которым это необходимо, извращаются при помощи общих переменных окружения. Вот уже действительно «голь на выдумки хитра».

Rancher

Ранчер оперирует сервисами, из которых можно собрать стэки. Всё очень похоже на swarm и даже есть импорт docker-compose файлов через UI. Если надо, то можно сделать так, чтобы сервисы запускались на одной и той же ноде через Sidekick связь.

Вывод по деплою и запуску

Самый простой вариант сейчас — это запустить swarm и создавать сервисы из docker-compose файла. Никаких новых знаний. Зато в rancher можно просто накликать контейнеры из UI, что определённо будет плюсом для людей, которые вообще не знакомы с докером.

Если располагать по простоте, то я бы поделил места так:

  1. Rancher (если вам надо просто накликать сервисы)
  2. Swarm (сразу сели и поехали)
  3. Nomad (простая документация, простые концепты)
  4. Kubernetes (куча ручек, но можно накрутить много разных штук)
  5. Mesos (может быть и простым, но можно вообще сделать самописную убер пушку)

Диски

Swarm

Если вам нужно хранить информацию на диске, то в swarm по умолчанию можно использовать либо диск с инстанса, либо volume контейнер. Если между запусками вам надо сохранять информацию, которую сгенерировал контейнер, то рекомендуется использовать что-то вроде ceph для этого или какой-то nfs. Для разных cloud провайдеров докер разработал и менеджит cloudstor — плагин, который мапит диск к контейнеру. То есть даже если контейнер будет перезапущен на другой ноде, он сможет получить доступ к своим данным.

Также можно использовать разные плагины типа flocker, которые делают примерно то же самое.

Mesos

Точно так же, как и в swarm, можно использовать volume контейнер или писать сразу на локальный диск. Есть PoC для работы с flocker, но разработчики пишут, что это ещё не production-ready решение, хотя вот тут CTO ClusterHQ советует его использовать.
Аналогично неплохо работает с разными nfs или ceph. Есть возможность работы с персистентными дисками типа как в StatefulSets от kubernetes (спасибо @shirkevich за дополнение)

Kubernetes

То же, что и выше, + отлично работает с облачными провайдерами самостоятельно. Самый большой выбор способов работы с волюмами.
Дополнительно стоит отметить, что в случае с StatefulSets они до последнего момента будут пытаться стартовать на той же ноде, на которой были запущенны первоначально. Что делает их достаточно удобным механизмом для хранения всяких кешей, без использования плагинов. Хорошая практика для баз данных использовать StatefulSet + мапинг диска из облака.

Nomad

Сейчас в номаде нет персистентных дисков. Вот тут длинный тред с 2015 года. В конце треда разработчики пообещали крутую возможность работы с дисками в версии 0.6, а в версии 0.5 они добавили возможность пробрасывать\использовать докер волюмы и докер плагины. Сейчас 0.5 ещё rc2, но у вас, в далёком будущем, она может уже быть. Так что, в принципе, не так много отличий от swarm.

upd. в чатике Ievgen Khmelenko обратил внимание, что в 0.5.5 версии, которая зарезилилась 14 марта уже есть поддержка докер драйверов для волюмов.

Rancher

По умолчанию Rancher работает с дисками через Convoy, который поддерживает Device Mapper, VFS\NFS и Amazon EBS. В любом случае, есть интеграция с flocker, что расширяет возможности ранчера, хоть и уменьшает его ценность как «всё из коробки» продукта.

Выводы по дискам

Лучше всего, как мне кажется, для приложений, которые так или иначе работают с диском, подходит kubernetes. Можно настроить почти как угодно. Всё остальное идёт практически нос к носу, можно только выделить аутсайдера в виде Nomad. Хотя у него дела однозначно поправятся после релизов 0.5\0.6. Я бы не рекомендовал поднимать базы данных в любом из оркестраторов, если у вас нет какой-то дополнительной необходимости в этом. Дополнительный уровень абстракции и множество плагинов-компонентов могут привнести много боли в ежедневную работу с БД.

Мультидатацентр

Swarm

Заявляется работа в режиме нескольких датацентров и есть разные лейблы, которыми можно помечать ноды из разных ДЦ, после чего достаточно негибко можно цеплять сервисы к этим нодам. Федерация происходит посредством сторонних сервисов.

Mesos

Федерации и мультидатацентра из коробки нет. Есть отдельное решение от huawei на основе этого proposal. У huawei работает, но если честно, очень мало инфы.

Kubernetes

Имеет встроенную федерацию. Вот тут неплохая статья на эту тему.

Nomad

Имеет встроенную поддержку всего что только можно. Ребята этим очень гордятся. По их словам, у них самое стабильное решение.

Rancher

Хоть из UI и можно управлять несколькими серверами в разных датацентрах, на этом всё и заканчивается. Ожидаемо самое слабое решение.

Разное

Kubernetes

Куб, как самый популярный оркестратор, имеет множество финтифлюшек и дополнений.

Helm

Helm это менеджер приложений для kubernetes. Используется для того, чтобы после\до запуска контейнера сделать там какие-то дела вроде «добавить в кластер». В месосе такую задачу пришлось бы решать кастомным шедулером, а в других оркестраторах — каким-то хитрым стартовым скриптом.

Serverless

Для kubernetes есть множество плагинов для serverless: FUNKTION, Kubeless, Fission. Для mesos это решается только кастомным шедуллером. Для остальных участников этой специальной олимпиады я не знаю таких решений.

Mesos

Фреймворки

В Mesos очень просто написать свой фреймворк. Есть обвязки для разных языков. Мне, например, очень нравится обвязка для golang.

Big data

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

Rancher

Отличное UI и супермаркет приложений.

Выводы

Как ни странно, у меня в голове всё уложилось и мне наконец-то удалось дописать эту статью. Если бы у меня попросили совета по выбору оркестратора сейчас, я бы отвечал так:

Если вам не нужен оркестратор — не используйте никакой. Любой оркестратор — это дополнительный уровень абстракции, требующий поддержки и знаний.

Если вы разработчик, которому надо, чтобы всё быстро завелось и работало для какого-то PoC, то смело используйте Rancher. Он очень простой в установке, имеет приятный UI и так далее.

Если у вас непритязательный вкус, много stateless приложений и немного statefull, то используйте swarm или nomad. На стороне nomad очень хорошая и понятная документация и хорошо продуманный механизм кросс датацентров.
На стороне swarm встроенные оверлейные сети и простое создание сервисов. К тому же, он уже есть на ваших нодах.

Если вы хотите миксовать statefull/stateless сервисы, запускать лямбды в своём кластере и творить всякие непотребства, стоит обратить внимание на kubernetes. Из минусов — высокий порог входа, множество internal вещей, немного запутанная документация. Из плюсов — всё остальное.

Если сеть — это ваш corner case, то смотрите на nomad\mesos.

Если у вас есть бигдата, то скорее всего у вас уже есть mesos.

Если вы хотите делать что-то вот вообще своё, или у вас много legacy и\или интерпрайза, который надо запускать каким-то своим индийским путём, то mesos с кастомными шедуллерами отличный вариант.

Спасибо. Сори, что без картинок.