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

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

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

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

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

Fleet - это распределитель задач нижнего уровня. Это полезно для начальной загрузки кластерной системы, например, CoreOS использует ее для распространения агентов кубернетов и двоичных файлов на машины в кластере, чтобы включить кластер кубернетов. На самом деле он не предназначен для решения тех же проблем разработки распределенных приложений, подумайте о нем как о 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/docker/issues/8781

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

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

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

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

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

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

Mesos, Kubernetes и Fleet пытаются решить очень похожую проблему. Идея состоит в том, что вы абстрагируете все свое оборудование от разработчиков, а «инструмент управления кластером» разбирает все это за вас. Затем все, что вам нужно сделать, это предоставить контейнер кластеру, дать ему некоторую информацию (держать его в рабочем состоянии постоянно, увеличивать масштаб, если произойдет X и т. Д.), И диспетчер кластера сделает это.

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

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

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

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

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

-edit- Я не упомянул Docker Swarm, так как у меня нет большого опыта работы с ним.

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

Управление контейнерами: переход от флота к Kubernetes. Fleet был удален из Container Linux (ранее известный как CoreOS Linux) и заменен Kubernetes кубелет (агент). Это совпало с корпоративным поворотом к предложению Tectonic (дистрибутив Kubernetes) в качестве основного продукта.