it-swarm.com.ru

Docker-Swarm, Kubernetes, Mesos & Core-OS Fleet

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

Хотя все они пытаются решить разные проблемы, но у них тоже есть что-то общее. Я хотел бы понять, что является общим и чем отличается. Вполне вероятно, что комбинация немногих подойдет, если да, то каковы они?

Я перечисляю некоторые из них вместе с вопросами, но было бы здорово, если бы кто-то перечислил все из них подробно и ответил на вопросы.

  1. Кубернетес против Месоса:

    Эта ссылка

    В чем разница между Apache's Mesos и Google Kubernetes

    дает хорошее представление о различиях, но я не могу понять, почему Kubernetes должен работать на вершине Mesos. Это больше связано с объединением двух решений с открытым исходным кодом?

  2. Kubernetes против Core-OS Fleet:

    Если я использую kubernetes, требуется ли автопарк?

  3. Как Docker-Swarm вписывается во все вышеперечисленное?

144
B_B

Раскрытие информации: я ведущий инженер по Kubernetes

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

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

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

Fleet - распределитель задач нижнего уровня. Это полезно для начальной загрузки кластерной системы, например, CoreOS использует ее для распределения агентов и двоичных файлов kubernetes на компьютеры в кластере, чтобы включить кластер kubernetes. На самом деле он не предназначен для решения тех же проблем разработки распределенных приложений, скорее думайте о нем как о systemd/init.d/upstart для вашего кластера. Это не требуется, если вы запускаете kubernetes, вы можете использовать другие инструменты (например, Salt, Puppet, Ansible, Chef, ...), чтобы выполнить то же двоичное распределение.

Swarm - это попытка Docker расширить существующий Docker API, чтобы кластер машин выглядел как единый Docker API. По сути, наш опыт работы в Google и других местах показывает, что API-интерфейс узла недостаточен для API-интерфейса кластера. Вы можете увидеть множество обсуждений по этому вопросу здесь: https://github.com/docker/docker/pull/8859 и здесь: https://github.com/docker/ Докер/вопросы/8781

Надеюсь, это поможет! Присоединяйтесь к нам в IRC @ # google-container, если хотите больше поговорить.

143
brendan

Я думаю, что самый простой ответ заключается в том, что нет простого ответа. Swift повышает мощность контейнеров, и, в частности, Docker оставил вакуум мощности для "планирования и оркестровки контейнеров", что бы это ни значило. В действительности это означает, что у вас есть ряд технологий, которые могут работать в гармонии на некоторых уровнях, но с определенными аспектами в конкуренции. Например, Kubernetes можно использовать в качестве единого окна для развертывания и управления контейнерами в вычислительном кластере (как это изначально было разработано в Google), но он также может располагаться поверх Fleet, используя уровень устойчивости, который Fleet предоставляет в CoreOS.

Как говорится в этом видеопрограмме Google Kubernetes не является полным решением для масштабирования контейнеров, но является хорошим утверждением для начала. Точно так же на некотором этапе вы ожидаете, что Apache Mesos сможет работать с Kubernetes, но не с Marathon, поскольку Marathon выполняет ту же роль, что и Kubernetes. Где-то, я думаю, я читал, что это может стать частью того же усилия, но я могу ошибаться в этом - это действительно о стратегическом направлении Мезосферы и соответствующем принятии принципов Кубернетеса.

В ключевой ноте DockerCon Соломон Хайкс предположил, что Swarm будет уровнем, который может обеспечить общий интерфейс для многих структур оркестровки и планирования. Из того, что я вижу, Swarm разработан для обеспечения плавного рабочего процесса развертывания Docker, работающего с некоторыми существующими инфраструктурами рабочего процесса контейнера, такими как Deis, но достаточно гибкого, чтобы уступить место "тяжелому" развертыванию и управлению ресурсами, таким как Mesos.

Надеюсь, это поможет - это может быть огромный пост. Я думаю, что ключ в том, что это молодые, развивающиеся сервисы, которые, вероятно, объединятся и станут функционально совместимыми, но нам нужно переждать следующие 12 месяцев, чтобы посмотреть, как они будут развиваться. Есть некоторые очень умные люди по этой проблеме, поэтому будущее выглядит очень светлым.

30
MikeB

Насколько я понимаю

Месос, Кубернетес и Флот пытаются решить очень похожую проблему. Идея состоит в том, что вы абстрагируете все свое оборудование от разработчиков, а "инструмент управления кластером" разберется с вами. Тогда все, что вам нужно сделать, это передать контейнер кластеру, дать ему некоторую информацию (сохранить его работоспособным постоянно, увеличить масштаб, если X случится и т.д.), И менеджер кластера сделает это возможным.

В Mesos он выполняет все функции управления кластером, но не включает планировщик. Планировщик - это бит, который говорит: "Хорошо, для этого процесса нужны 2 процессора и 512 МБ ОЗУ, и у меня есть машина с этим свободным, так что я буду запускать его на этой машине. Для Mesos есть несколько планировщиков плагинов: Marathon и Chronos, и вы можете написать свой собственный. Это дает вам много возможностей для распределения ресурсов, масштабирования кластеров и т.д.

Флот и Kubernetes, кажется, абстрагируются от подобных деталей (поэтому вам не нужно писать свой собственный планировщик). Это означает, что вы должны определить свои задачи и представить их в формате/порядке, определенном Fleet или Kubernetes, а затем они возьмут на себя и запланируют задачи (контейнеры) для вас.

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

Я думаю, что идея запуска Kubernetes поверх Mesos заключается в том, что Kubernetes действует как планировщик для Mesos. Лично я не уверен, какие преимущества это дает, если запускать один или другой сам по себе (надеюсь, кто-то прыгнет и объяснит!)

Как сказал MikeB ... это первые дни, и это все для захвата (следите за ECS Amazon), так что есть много конкурирующих стандартов и много совпадений!

-edit- Я не упомянул рой Докер, потому что у меня нет особого опыта с ним.

20
user2851943

Для тех, кто приходит к этому после 2017 года, флот не рекомендуется Не используйте его больше.

Fleet docs скажем "флот больше не активно разрабатывается и не поддерживается CoreOS" и ссылка на Контейнерная оркестровка: переход от флота к Kubernetes . Fleet был удален из Container Linux ( ранее известный как CoreOS Linux ) и заменен Kubernetes kubelet (агент). Это совпало с корпоративной опорой предлагать Tectonic (дистрибутив Kubernetes) в качестве основного продукта.

5
jpweber