Kubernetes vs Docker Swam
Обе эти технологии контейнеризации сегодня очень популярны, но у каждой есть как плюсы, так и минусы. Об этом — в нашей статье.
Docker Swarm
Docker Swarm — известный встроенный инструмент кластеризации, работающий «из коробки». Этот инструмент характеризуется простотой как в настройке, так и в применении. Но, к сожалению, с учётом современных реалий можно сказать, что он недостаточно гибок.
Итак, плюсы Docker Swarm: — быстрая и простая настройка: поднять рабочий кластер Swarm можно в кратчайшие сроки; — инструменты совместимы с Docker, а многие команды Docker CLI станут работать и в Swarm.
Что касается минусов, то это недостаточная функциональность, связанная с тем, что возможности ограничены Docker API. Можно сказать, что Swarm способен делать только то, что ему позволяют делать возможности Docker.
Тем не менее Swarm — отличное решение для небольших проектов, при реализации которых гибкость Kubernetes избыточна.
Kubernetes
Это «универсальный солдат» по созданию распределённых систем. По сути, Kubernetes представляет собой сложную систему с широкими возможностями, а такую систему непросто настроить самому.
Итак, плюсы: — Kubernetes — это мощный инструмент, имеющий много возможностей. С его помощью можно создавать действительно сложные распределённые системы; — Кубер не зависит от Докера и умеет работать с различными системами контейнеризации. Однако на деле чаще всего применяется именно Docker и его контейнеры.
Теперь кратко о минусах: — Кубер сложен в настройках. Что там скрывать — вам потребуются довольно глубокие знания. Будьте готовы потратить время на инсталляцию и настройку; — чтобы управлять Kubernetes, надо будет использовать отдельный набор инструментов и команд, которые несовместимы с Docker CLI.
Зато Кубер лучше подходит для крупных проектов, где требуется гибкая настройка всей инфраструктуры.
Пример не в пользу Docker Swarm
Чтобы не быть голословными, рассуждая о повышенных возможностях Kubernetes, приведём простой пример. Дело в том, что Кубер позволяет решать некоторые задачи, неподсильные Docker Swarm. Например, автомасштабирование (система автоматически подстраивает имеющуюся мощность под нагрузку). При автомасштабировании в кластер в автоматическом режиме добавляются/удаляются ноды или в существующих нодах выделяется больше/меньше ресурсов в зависимости от решаемых задач.
В Кубере автомасштабирование можно настроить. Цена вопроса — написать конфигурационный файл и выполнить настройки. В результате вы получите вполне рабочую и стабильную систему. Если же вы разворачиваете кластер в облачном сервисе, где поддерживается автомасштабирование, то на настройку и вовсе уйдёт пару минут (вот один из примеров).
Что касается Docker Swarm, то он делать это «из коробки» не умеет. Но если быть до конца честными, то в теории и на практике вы всё же можете построить автомасштабируемую систему, используя Swarm. Но для этого понадобится вручную писать скрипты либо программы, которые станут отслеживать нагрузку, принимать решения, посылать команды в Swarm. Конечно, можно обратиться к сторонним разработкам, тому же Orbiter, но и его возможности ограничены, не говоря уже о том, что это очередная дополнительная надстройка над Swarm.
А если вам надо решить не только задачу автомасштабирования, но и массу других? Придётся надстраивать кучу инструментов над Swarm, а потом всё это поддерживать и тестировать при обновлениях... Как говорится, комментарии излишни. А в Kubernetes все эти сложности спрятаны внутри, поэтому всё работает стабильнее.
Так что же выбрать? Резюмируем
Вывод можно описать тезисно и в двух пунктах: 1. Docker Swarm — стандартная система оркестрации Docker, способная решать базовые задачи. Swarm прост в настройке и инсталляции, но недостаточно гибок. Применение: небольшие компании, небольшие проекты. 2. Kubernetes — это мощная система оркестрации, позволяющая создавать масштабные распределённые системы. Сложнее и в установке, и в настройке, то есть разобраться в этой системе сможет не каждый. Но эту сложность нивелирует использование готовых облачных сервисов. Применение: большие компании и крупные проекты, где требуется повышенная гибкость.
Статья написана по материалам блога mcs.mail.ru.
