Я относительно новичок во всем этом, но у меня проблемы с получением четкой картины среди перечисленных технологий.
Хотя все они пытаются решить разные проблемы, но у них тоже есть что-то общее. Я хотел бы понять, что является общим и чем отличается. Вполне вероятно, что комбинация немногих подойдет, если так, то каковы они?
Я перечисляю некоторые из них вместе с вопросами, но было бы здорово, если бы кто-то перечислил их все подробно и ответил на вопросы.
Кубернетес против Месоса:
Эта ссылка
дает хорошее представление о различиях, но я не могу понять, почему Kubernetes должен работать поверх Mesos. Это больше связано с объединением двух решений с открытым исходным кодом?
Kubernetes против Core-OS Fleet:
Если я использую kubernetes, требуется ли автопарк?
Как Docker-Swarm вписывается во все вышеперечисленное?
Ответы:
Раскрытие информации: я ведущий инженер по Kubernetes
Я думаю, что Mesos и Kubernetes в значительной степени нацелены на решение схожих проблем запуска кластеризованных приложений, у них разная история и разные подходы к решению проблемы.
Mesos сосредотачивает свою энергию на очень общем планировании и подключении нескольких различных планировщиков. Это означает, что он позволяет таким системам, как Hadoop и Marathon, сосуществовать в одной среде планирования. Месос менее ориентирован на запуск контейнеров. Мезос существовал до широкого интереса к контейнерам и был переработан по частям для поддержки контейнеров.
Напротив, 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/docker/issues/8781
Надеюсь, это поможет! Присоединяйтесь к нам на IRC @ # google-Containers, если вы хотите больше говорить.
источник
Я думаю, что самый простой ответ заключается в том, что нет простого ответа. Быстрое повышение мощности контейнеров, и в частности Docker, оставило вакуум мощности для «планирования и организации контейнеров», что бы это ни значило. В действительности это означает, что у вас есть ряд технологий, которые могут работать в гармонии на некоторых уровнях, но с определенными аспектами в конкуренции. Например, Kubernetes можно использовать в качестве единого окна для развертывания и управления контейнерами в вычислительном кластере (как это изначально было разработано Google), но он также может располагаться поверх Fleet, используя уровень устойчивости, который Fleet предоставляет в CoreOS.
Поскольку этот вид Google утверждает, что Kubernetes не является полным решением для масштабирования контейнерных контейнеров, но является хорошим утверждением для начала. Точно так же на некоторой стадии вы ожидаете, что Apache Mesos сможет работать с Kubernetes, но не с Marathon, поскольку Marathon выполняет ту же роль, что и Kubernetes. Где-то, я думаю, я читал, что это может стать частью того же усилия, но я могу ошибаться в этом - это действительно о стратегическом направлении Мезосферы и соответствующем принятии принципов Кубернетеса.
В ключевой заметке DockerCon Соломон Хайкс предположил, что Swarm будет уровнем, который может обеспечить общий интерфейс для многих структур оркестровки и планирования. Из того, что я вижу, Swarm разработан для обеспечения плавного рабочего процесса развертывания Docker, работающего с некоторыми существующими инфраструктурами рабочего процесса контейнера, такими как Deis, но достаточно гибкого, чтобы уступить место «тяжелому» развертыванию и управлению ресурсами, таким как Mesos.
Надеюсь, это поможет - это может быть огромный пост. Я думаю, что ключ в том, что это молодые, развивающиеся сервисы, которые, вероятно, объединятся и станут функционально совместимыми, но нам нужно переждать следующие 12 месяцев, чтобы посмотреть, как они будут развиваться. Есть некоторые очень умные люди по этой проблеме, поэтому будущее выглядит очень светлым.
источник
Насколько я понимаю
Месос, Кубернетес и Флот пытаются решить очень похожую проблему. Идея состоит в том, что вы абстрагируете все свое оборудование от разработчиков, а «инструмент управления кластером» разберется с вами. Затем все, что вам нужно сделать, это передать контейнер кластеру, дать ему некоторую информацию (сохранить его работоспособным постоянно, увеличить масштаб, если X случится и т. Д.), И менеджер кластера сделает это возможным.
В Mesos он выполняет все функции управления кластером, но не включает планировщик. Планировщик - это бит, который говорит: «Хорошо, для этого процесса требуется 2 процессора и 512 МБ ОЗУ, и у меня есть машина с этим свободным, так что я буду запускать его на этой машине. Для Mesos есть несколько планировщиков плагинов: Marathon и Chronos, и вы можете написать свой собственный. Это дает вам много возможностей для распределения ресурсов, масштабирования кластеров и т. Д.
Флот и Kubernetes, кажется, абстрагируются от подобных деталей (поэтому вам не нужно писать свой собственный планировщик). Это означает, что вы должны определить свои задачи и представить их в формате / порядке, определенном Fleet или Kubernetes, а затем они возьмут на себя и запланируют задачи (контейнеры) для вас.
Поэтому я предполагаю: использование Mesos может означать немного больше работы при написании вашего собственного планировщика, но потенциально обеспечивает большую гибкость при необходимости.
Я думаю, что идея запуска Kubernetes поверх Mesos заключается в том, что Kubernetes действует как планировщик для Mesos. Лично я не уверен, какую пользу это дает от запуска одного или другого самостоятельно, хотя (надеюсь, кто-то прыгнет и объяснит!)
Как сказал MikeB ... это первые дни, и это все для захвата (следите также за ECS Amazon), так что есть много конкурирующих стандартов и много совпадений!
-edit- Я не упомянул рой Докер, так как на самом деле у меня нет большого опыта с ним.
источник
Для тех, кто приходит к этому после 2017 года, флот устарел. Не используйте его больше.
Документы о флоте говорят, что «флот больше не активно развивается и не поддерживается CoreOS» и связаны с оркестровкой контейнеров: переход от флота к Kubernetes . Fleet был удален из Container Linux ( ранее известный как CoreOS Linux ) и заменен Kubernetes kubelet (агент). Это совпало с корпоративной опорой на предложение Tectonic (дистрибутив Kubernetes) в качестве основного продукта.
источник