Рой, куберне или мезо для пакетной обработки

Question

Мое приложение должно запускать множество контейнеров в качестве рабочих узлов (для выполнения различных заданий пакетной обработки), и я не очень заинтересован в поддержании веб-серверов или баз данных - просто короткие задания, которые могут занять от 1 секунды до 1 часа. Моя идея состоит в том, чтобы работать с облаком узлов, не беспокоясь о том, какая машина из этих узлов имеет доступные ресурсы для обработки моей работы (mesos довольно хорош в этом - как рекламировалось).

Я сейчас играю с DC/OS, и мне было интересно, если какие-либо другие технологии кластеризации предлагают эту функцию: given I need 1CPU, 2GB RAM and 2GB of disk - run X docker container against my nodes,

Мне нравится идея роя из-за того, что я очень хорошо знаком с самим докером и считаю, что его проще всего настроить и автоматизировать (увеличить или уменьшить). Мне нравится kubernetes (но без опыта), потому что он бесплатный, и я уверен, что так будет долго. Мне нравится DC/OS, потому что он много объединяет, но я не уверен в их будущих планах, и я привык к проектам, исключающим функции, чтобы включить их в план, который взимает с вас душу за x количество узлов.

о чем ты думаешь?

Answer 1

Kubernetes, Swarm и Mesos могут технически планировать работу для вас и обрабатывать ограниченные ресурсы для вас.

В отличие от двух других, Mesos был разработан в первую очередь для управления распределением, задачами и ресурсами на более низком уровне. Сосредоточение внимания на этих битах привело к большей мощности и гибкости, а также к большей сложности на более низком уровне. Вот почему существует DC/OS, чтобы предоставить вам набор микросервисных инструментов, которые хорошо работают в качестве платформы более высокого уровня.

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

DC/OS построен на Mesos и поставляется со встроенными планировщиками для заданий и служб, но в то же время позволяет вам при необходимости создавать свой собственный планировщик.

Kubernetes недавно также добавил поддержку пользовательских планировщиков, но он значительно менее зрел, чем реализация и экосистема Mesos, а также все еще вращается вокруг использования основных примитивов pods & replica set, которые могут расширять возможности или ограничивать, в зависимости от ваших потребностей.

Mesosphere недавно создала новую инфраструктуру dcos-commons, чтобы упростить создание планировщиков Mesos на основе JVM. Так что это может повысить вашу производительность на DC/OS. https://github.com/mesosphere/dcos-commons

Mesos & DC/OS также дает вам больше возможностей по контейнеризации. Вы можете использовать изображения Docker и контейнеры Docker, если хотите. Или вы можете использовать среду выполнения Mesos с образами Docker или без них, что дает вам больше гибкости в отношении рабочих нагрузок и упаковки.

DC/OS и Kubernetes также имеют менеджеры пакетов, которые могут быть полезны для установки таких зависимостей, как Spark, Kafka или Cassandra. Но DC/OS, как правило, имеют более надежные службы данных, поскольку они построены со своими собственными настраиваемыми планировщиками, тогда как экосистема Kubernetes имеет тенденцию усложнять управление жизненными циклами контейнеров Docker вокруг своих систем из-за позднего прибытия настраиваемых планировщиков. Docker также включает управление пакетами, если вы рассматриваете образы Docker как "пакеты". Разница в том, что DC/OS и Kubernetes упаковывают абстракции более высокого уровня (приложения и модули), которые могут включать в себя несколько контейнеров. Совсем недавно Docker добавил "стеки", которые являются абстракциями более высокого уровня, но я не думаю, что существует какой-либо внешний механизм хранилища или много управления пакетами вокруг них.

Swarm, безусловно, самый простой, но его оригинальный API был спроектирован так же, как и API-интерфейс узла, который отлично подходил для знакомства и адаптации, но скорее ограничивал как абстракцию более высокого уровня. С тех пор они эффективно переписали Swarm API и включили его в Docker-Engine как "Swarm-Mode". Такое связывание механизма оркестровки и среды выполнения контейнера упрощает установку и управление пользователем, а также сочетает в себе два предыдущих уровня абстракции. Таким образом, вместо того, чтобы просто зависеть от движков оркестровки, движок Docker теперь тоже конкурирует с ними, идя вразрез с философией Unix: делать что-то хорошо и создавать политический беспорядок в соответствующих сообществах с открытым исходным кодом. Twitter, хакерские новости и чаты переросли в разговоры о разветвлении Docker, что привело к тому, что K8s экспериментировали с альтернативами, DC/OS поддерживали образы Docker без использования механизма Docker и Docker извлекал контейнер.

Все они работают нормально. Выбор одного вида зависит от ваших потребностей. Я обычно рекомендую DC/OS, потому что он решает больший набор проблем и состоит из множества отдельных инструментов и уровней микросервиса, что позволяет вам поддерживать несколько вариантов использования, программируя для уровня, чем это имеет смысл. Раскрытие, но я работаю на Месосферу!;)