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

Question

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

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

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

1. Kubernetes против Mesos:

   Эта ссылка

   What's the difference between Apache's Mesos and Google's Kubernetes

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

2. Kubernetes против Core-OS флота:

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

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

Answer 1

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

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

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

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

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

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

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

Answer 2

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

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

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

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

Answer 3

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

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

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

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

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

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

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

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

Answer 4

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

Fleet docs сказать, что «флот больше не активно развивается или поддерживается CoreOS» и ссылается на Container orchestration: Moving from fleet to Kubernetes. Флот был удален из контейнера Linux (formerly known as CoreOS Linux) и заменен кубелетом Кубернете (агентом). Это совпало с корпоративным стержнем, предлагающим Tectonic (дистрибутив Kubernetes) в качестве основного продукта.