Docker Swarm VS Kubernetes — как бизнес выбирает оркестраторы

Kubernetes (K8s) по праву считается отраслевым стандартом управления контейнерами, но это вовсе не значит, что решение подходит каждому типу бизнеса. Порог входа в K8s высок, а преимущества не всегда очевидны. Гораздо эффективнее может быть использование альтернативных оркестраторов. OpenShift, Nomad или Apache Mesos при помощи дополнительных утилит умеют многое из того, что предлагает K8s. Эти решения на порядок проще в освоении и настройке, пусть и не обладают таким активным сообществом. Тогда почему их нельзя использовать везде? 

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

Наиболее близкую альтернативу Kubernetes сейчас, пожалуй, представляет Docker Swarm.

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

Как контейнеры появились (почти) везде

В 2013 году, на этапе бурного развития контейнеризации, Docker предлагал по сути революционное решение и как формат упаковки, и как среду выполнения контейнеров. В Docker-контейнер можно было упаковать все настройки, бинарные файлы, среду и библиотеки в изолированный контейнер. Это значительно ускоряло выпуск новых продуктов. Кроме этого, технология открывала возможность работать с контейнерами как в облаке, так и на домашнем железе.

Технология контейнеризации схожа с работой виртуальных машин (ВМ), но компании не стали делать выбор в пользу какого-то одного решения, а встали на путь использования лучших практик из обоих миров. 

Контейнеры оказались менее ресурсоемкими и не такими требовательными к оборудованию. Оказалось, что на одном железе можно запустить в 2-3 раза больше контейнеров, чем ВМ. При этом ВМ более надежны, поэтому их чаще используют для секьюрных компонентов.

Решение Docker было достаточно простым и открывало массу возможностей для работы с контейнерами. Полностью готовый к использованию контейнер можно было скачать из общей библиотеки и запустить у себя. 

По мере развития проекта, контейнеров будет становиться больше. Эффективно управлять сотней контейнеров уже сложно — это заметно влияет на клиентскую удовлетворенность продуктом. Расширение штата для поддержки такой громоздкой системы скорее полумера. Здесь на помощь приходят системы оркестрации. С их помощью контейнеры можно объединять в кластеры.

Для управления и кластеризации нод Docker предлагал использовать встроенный оркестратор Swarm.

В Docker Swarm контейнеры собираются из нод двух типов:

• Worker: нода-исполнитель контейнеров, которые возможно поднять в кластере.
• Manager: обеспечивает управление кластером. Как и worker, может выполнять запуск и работу контейнеров.

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

Docker Swarm VS Kubernetes

Сам факт сравнения K8s и Docker Swarm имеет место быть, хотя к управлению контейнерами они подходят скорее с противоположных сторон.

Нельзя отрицать, что коробочный Docker прост в установке, но со всем, что связано уже с администрированием контейнеров, K8s оказалось использовать проще и удобнее, поскольку это комплексный инструмент. 

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

Автомасштабирование

Автомасштабирование нужно не только в моменты пиковых нагрузок на инфраструктуру, чтобы никто не почувствовал задержку в работах сервисов. Автомасштабирование также позволяет экономить. Главное — вовремя выключать дополнительные ноды и перераспределять выделенные ресурсы, когда это перестает быть актуальным. 

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

Автомасштабирование в K8s опирается на потребление CPU и RAM, а также с недавнего времени с использованием кастомных метрик, и доступно на трех уровнях:

1. Горизонтальное автомасштабирование (HPA) отталкивается от выбранных значений и изменяет количество групп контейнеров (подов).
2. Вертикальное автомасштабирование (VPA) контролирует количество ресурсов, которые выделяются для уже запущенных контейнеров.
3. Автомасштабирование самого кластера и количества узлов внутри.

Безопасность

Вопрос безопасности для контейнеров всегда был дискуссионным. Самыми частотными проблемами можно считать ошибки в конфигурации. 

Когда кластер уже развернут, оба оркестратора могут использовать специальное решение Vault «поверх» встроенной системы секретов.

Каждый узел в Docker Swarm защищается аутентификацией и шифрованием TLS. Коммуникация между узлами чаще всего и является проблемной областью.

В Kubernetes активно развивается система настроек сетевых политик и использование пространств имен. В последних версиях K8s оркестратор консолидировал защиту на всех трех уровнях: control panel, worker node и Cluster network.

Технически защиту K8s вряд ли можно назвать надежнее, чем в Docker Swarm. Тем не менее в системе реализовано больше практик и «красных кнопок», которые подменяют и дублируют друг друга на случай проникновения.

Сетевая архитектура

Docker Swarm неплохо адаптирован для работы с оверлейными сетями. Система автоматически прописывает IP-адреса контейнеров при инициализации или обновлении. Для работы с нативными сетями есть практика дополнять функциональность оркестратора сетевыми плагинами, чтобы избежать потерь производительности. 

Откаты и обновления

В работе с распаковкой обновлений Docker Swarm и Kubernetes предлагают похожие алгоритмы последовательных апдейтов. Это позволяет быстро возвращаться к стабильным версиям, если при обновлении произошел сбой. 

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

Преимущество Kubernetes здесь в более гибкой настройке сценариев обновлений. Например, в K8s можно задать минимальное количество доступных реплик. Количество сценариев, которое могут учесть настройки K8s покрывает любую задачу из этой области. 

Кажется, что Kubernetes выигрывает во всех критических аспектах, но нельзя исключать из уравнения сложность его поднятия и обслуживания. Есть инструменты, которые частично облегчают работу с поддержкой и обновлениями, например, Kubespray, но нет гарантии, что этот процесс будет проходить органично. 

Как правило, для этого требуется полноценная команда DevOps инженеров, которую не всегда выгодно держать в штате и сложно собрать из-за уникальности компетенций. 

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

Как бизнес осваивает оркестраторы

В 2022 году можно говорить, что фаза активного противостояния Docker Swarm и Kubernetes завершилась несколько лет назад, когда K8s научился работать с CRI-O и обходиться без установки Docker на все узлы кластера. На сокращение сектора влияния Docker Swarm также повлияла продажа Enterprise Edition в 2019 году. Таким образом Docker Swarm потерял свой аналог шаблонизатора Helm, который использует K8s. 

Еще один фактор, который повлиял на расположение сил: с 31 января 2022 Docker перевел всех клиентов на модель подписок. Бесплатный тариф для личного пользования тоже есть, но для команд от 5 человек сейчас уже могут быть сложности с оплатой. 

Для каких компаний Docker Swarm будет оптимальным выбором

1. Для компаний, чье устройство пока не предполагает наличие команды DevOps-специалистов. К этой категории относятся многие стартапы, исключение составляют команды, которые работают с большими объемами данных и машинным обучением. Возможностей Docker Swarm для таких проектов может быть недостаточно.
2. Оркестратор чаще используют компании, которые могут прогнозировать сезонные всплески нагрузок и могут настроить сценарии масштабирования под конкретные даты. Например, бухгалтерия в периоды отчетности или туристические сервисы в сезон отпусков. Здесь многое зависит от масштабов компании и количества контейнеров, с которыми приходится работать, поскольку управлять ресурсами конкретных нод не так удобно, как контролировать их количество. С учетом отсутствия автомасштабирования в Swarm комфортным количеством узлов будет <1000.
3. Docker Swarm чаще используют команды, которые сами занимаются поддержкой инфраструктурных решений.

Если компания не работает с большим объемом рабочих нагрузок и они вполне укладываются в Docker API, плюс нет потребности пользоваться другим типом контейнеров — выбрать Docker Swarm в качестве оркестратора будет правильным решением. Гибкость настроек K8s для таких проектов будет только мешать и усложнять процессы релизов. 

Для каких компаний Kubernetes будет оптимальным выбором

Относительно недавно Gartner писали о том, что в 2022 году 75% компаний перейдут на контейнерные приложения. Их прогноз основывается на двух предпосылках, связанных с популяризацией K8s:

• Функциональность K8s можно адаптировать под любой проект — это универсальное решение для Enterprise-сегмента. Для многих компаний K8s — это решение «на вырост». Это забота о будущих процессах разработки, когда появится необходимость быстро масштабироваться.
• Модель управления Managed Kubernetes становится удобнее для обеих сторон. С одной стороны, это происходит, потому что K8s в облаке решает проблемы, связанные с настройкой и развертыванием. С другой, пользователи оплачивают только ресурсы, которые фактически использовали, и не несут эксплуатационные риски.

Правильнее всего было бы вынести за скобки фактор сложности управления K8s. Согласно исследованию Datadog, на западном рынке услугами Managed Kubernetes пользуются 90% компаний, работающих с решением. В качестве альтернативного источника данных можно привести данные Flexera: Enterprise-клиентами Managed Kubernetes оказались 637 из 750 респондентов. 

1. Интернет-магазины чувствительнее всего относятся к повышениям нагрузки. Управлять ресурсами таких площадок в период акций или сезонного спроса через Docker Swarm или Apache Mesos может быть просто невозможно и крайне болезненно как для продавцов, так и для покупателей.
2. K8s подходит для сервисов, которые активно используют машинное обучение и Big Data. Отлаженная работа оркестратора обеспечит высокий уровень доступности и консолидации данных и скажется на качественных ожиданиях от сервиса. О том, какие продукты используют Kubernetes можно посмотреть здесь.
3. Игровые приложения, работающие на сложной микросервисной архитектуре. Быстрое поднятие новых кластеров обеспечивает доступность серверов и стабильный обмен данными и сохранение прогресса вне зависимости от откатов.

Заключение

По-настоящему идентичных альтернатив K8s на сегодняшний день, пожалуй, не существует, но это нормально. Не каждый проект нуждается в таком мощном решении для оркестрации. 

Если проект не требует гибкой системы масштабирования и управления ресурсами, то выбрать более доступное решение окажется верным ходом. Стоимость доработок, которые будет необходимо внести для нетипичных задач окажется все равно ниже, чем управление инфраструктурой своими силами с помощью K8s.

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