Docker Swarm Mode vs Kubernetes: честное сравнение после года в проде

Где-то с середины прошлого года нас регулярно спрашивают: «Swarm или Kubernetes?» Вопрос понятный - оба инструмента живые, оба активно обновляются, оба претендуют на одну нишу. У нас к апрелю 2017-го накопилось достаточно реального опыта чтобы ответить без воды.

Коротко: однозначного ответа нет, но для большинства наших клиентов в SMB-сегменте Swarm проще и этого достаточно. Дальше - почему.

Что у нас реально было

На сопровождении несколько объектов с Docker Swarm Mode - работает с момента выхода Docker 1.12 в прошлом году, то есть около года боевой эксплуатации. Типичный стек: 3-5 нод, несколько сервисов, overlay-сеть, stack-файлы в GitLab CI.

Параллельно с конца 2016-го ведём пилот на Kubernetes - сначала 1.5, теперь перешли на 1.6 после недавнего релиза. Два объекта, один из них уже можно назвать продакшном с осторожностью.

Сравниваем именно то что видели руками, без пересказа документации.

Где Swarm выигрывает

Порог входа. Docker Swarm Mode - это буквально docker swarm init и docker swarm join. Всё. Нет отдельного бинаря, нет kubeadm с его вопросами про сетевой плагин, нет отдельного etcd который надо мониторить. Для команды из двух-трёх человек без выделенного DevOps это принципиально - они могут разобраться сами за день.

Совместимость с docker-compose. Stack-файлы в Swarm - это почти тот же docker-compose.yml с минимальными добавками (deploy: блок). Если у команды уже есть compose-файл для локальной разработки, перенести его в Swarm - час работы. Kubernetes требует переписать всё: Deployment, Service, ConfigMap, Ingress - отдельными манифестами с другим синтаксисом.

Операционная простота. Обновить сервис в Swarm: docker service update --image myapp:v2 myapp. Rolling update с настройкой update_config. Откат: docker service rollback myapp. Это можно объяснить разработчику за десять минут. В Kubernetes тот же сценарий требует понимания что такое Deployment, ReplicaSet и как они связаны.

Меньше движущихся частей. Нет etcd как отдельного компонента (Swarm использует Raft внутри самого демона), нет kube-apiserver, kube-scheduler, kube-controller-manager - всё это части одного docker-демона. Меньше компонентов - меньше точек отказа для мониторинга и поддержки.

Где Kubernetes убедительнее

Экосистема. Это, честно, главный аргумент в пользу K8s. Helm с готовыми chart-ами для всего что нужно, операторы для баз данных, плагины для хранилищ, интеграции с облачными провайдерами - этого у Swarm практически нет. Если нужен готовый кластер Prometheus с Grafana - в K8s это helm install, в Swarm - руками.

RBAC и мультитенантность. В Kubernetes 1.6 RBAC стал дефолтом, и это серьёзно. Namespace-изоляция, тонкая настройка прав на уровне ресурсов, аудит-логи с чёткими причинами отказа - всё это есть и работает. Swarm предлагает только разделение по stack-ам без нормальных механизмов изоляции прав.

StatefulSets для stateful-нагрузки. Как мы писали в посте про 1.5, это реальный инструмент для баз данных в кластере. В Swarm stateful-сервисы с persistent storage - боль. Официальный ответ «используйте volume plugins» на практике означает «разбирайтесь сами».

Богаче примитивы. DaemonSet (запустить ровно по одному поду на каждой ноде), Jobs, CronJobs, readiness/liveness пробы с тонкой настройкой - в Swarm аналогов нет или они значительно слабее.

Что реально решает выбор

Мы смотрим на несколько вопросов когда приходит новый клиент:

• Размер команды и уровень DevOps. Один человек, который «занимается серверами» и знает Linux на уровне sysadmin - Swarm. Есть выделенный DevOps или SRE с опытом - можно смотреть на K8s.
• Сколько сервисов и какова сложность. До десяти сервисов без сложной межсервисной логики - Swarm справляется. Микросервисная архитектура, несколько команд, изоляция окружений - K8s начинает окупать сложность.
• Нужны ли stateful-нагрузки в кластере. Если да, и это не Redis-кеш а что-то серьёзное - K8s с StatefulSets убедительнее.
• Горизонт проекта. Swarm быстрее запустить, быстрее передать клиенту без нас. K8s требует операционной зрелости - либо от команды клиента, либо это остаётся на сопровождении у нас.

Честный вывод

Docker Swarm Mode выигрывает в простоте, и эта простота - не слабость, а осознанное решение. Для большинства SMB-клиентов с которыми мы работаем, три-пять сервисов и команда без глубокой DevOps-экспертизы, Swarm закрывает задачи без лишней операционной нагрузки.

Kubernetes берём когда задача требует того что Swarm не умеет: изоляция команд, сложная stateful-нагрузка, большая экосистема инструментов. Или когда клиент сам хочет K8s и готов к сопутствующей сложности.

Одно замечание в сторону Docker Inc.: разделение на CE и EE которое они объявили в феврале выглядит как попытка монетизировать Swarm через EE. Если они продолжат вкладываться в Swarm в рамках EE и обделять CE - баланс может сдвинуться. Пока что CE достаточно для большинства наших сценариев, но за этим стоит следить.