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


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

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

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

  1. Kubernetes против Мэсос:

    этой ссылке

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

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

  2. Kubernetes vs Core-OS Fleet:

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

  3. Как Докер-Рой вписывается во все вышесказанное?

4 138

4 ответа:

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

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

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

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

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

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-контейнеры, если вы хотите поговорить больше.

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

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

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

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

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

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

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

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

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

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

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

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

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

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