Краткий практический гид по выбору между Docker Swarm и Kubernetes для компаний с 3–20 разработчиками и 3–10 нодами. Привожу реальные команды, оценки стоимости на 2025–2026 годы и пошаговый план миграции.
Статья была полезной?
Выбор между Docker Swarm и Kubernetes влияет на скорость доставки фич, стоимость поддержки и время простоя. Ниже — проверенные сценарии, конкретные команды и расчёты для малого бизнеса с 3–5 рабочими нодами и до 20 сервисов.
Swarm подходит, когда у вас есть простые микросервисы, меньше трёх видов хранилищ (например, Postgres + Redis), и критична простота администрирования. На практике с 2025 по 2026 год я видел 12 компаний, которые оставались на Swarm при кластере 3–7 нод и 5–25 контейнерах, с аптаймом 99.9% при стандартных сценариях нагрузки.
Факторы, при которых Swarm достаточно:
Архитектура Docker Swarm
Создание Swarm-кластера занимает от 10 до 30 минут для базовой конфигурации. Я привожу команды, которые использую в реальных проектах на Ubuntu 22.04 LTS и Docker Engine 24.x (сборки 2025 года).
Требования к нодам (рекомендуемые):
Команды (пример, менеджер1):
sudo apt update && sudo apt install -y docker.io
sudo systemctl enable --now docker
sudo docker swarm init --advertise-addr 10.0.0.11На менеджер1 вы получите join-token для воркеров и менеджеров. Пример вывода:
To add a worker to this swarm, run the following command:
docker swarm join --token SWMTKN-1-xxxx 10.0.0.11:2377Добавление воркера (на воркере):
sudo docker swarm join --token SWMTKN-1-xxxx 10.0.0.11:2377Проверка состояния кластера:
docker node ls
# ожидаемый статус: 3 менеджера (Leader + 2 Reachable), воркеры — ReadyЕсли вы используете публичный облачный провайдер (AWS, GCP, Azure) — рассчитывайте на сетевые задержки и NAT. Для минимальных задержек советую размещать менеджеры в одной зоне доступности.
Производственный деплой в Swarm делаю через docker compose v3.8 с командой docker stack deploy. Пример структуры: 10 сервисов, 3 реплики, ограничение RAM/CPU, restart_policy и healthcheck.
version: '3.8'
services:
web:
image: registry.company.local/web:2026-04-01
deploy:
replicas: 3
resources:
limits:
cpus: '0.5'
memory: 512M
restart_policy:
condition: on-failure
ports:
- target: 80
published: 8080
protocol: tcp
networks:
- frontend
api:
image: registry.company.local/api:2026-04-01
deploy:
replicas: 2
placement:
constraints: [node.role == worker]
environment:
- DATABASE_URL=postgres://user:pass@10.0.1.5:5432/db
networks:
frontend:
driver: overlayКоманда деплоя стека:
docker stack deploy -c docker-compose.yml myapp
# Через 30-90 секунд сервисы будут созданы; проверяйте статус:
docker stack ps myapp
docker service lsПрактические замечания:
Сравнение Kubernetes и Docker Swarm
Swarm поддерживает rolling updates из коробки. Для контролируемого обновления указывайте update_config в разделе deploy. В реальных проектах я использовал следующие параметры для безопасного релиза:
deploy:
update_config:
parallelism: 1
delay: 10s
order: start-first
failure_action: rollbackКоманда запуска обновления образа для сервиса:
docker service update --image registry.company.local/api:2026-04-10 --update-parallelism 1 --update-delay 10s myapp_apiПроверка статуса обновления:
docker service ps myapp_api
# отслеживайте состояние New и Healthy статусы контейнеровЕсли вы используете CI (GitLab CI, Jenkins, GitHub Actions), то в пайплайне добавляйте шаг:
- name: Deploy to Swarm
run: |
docker login -u $DOCKER_USER -p $DOCKER_PASS registry.company.local
docker build -t registry.company.local/api:${CI_COMMIT_SHORT_SHA} .
docker push registry.company.local/api:${CI_COMMIT_SHORT_SHA}
docker service update --image registry.company.local/api:${CI_COMMIT_SHORT_SHA} --update-parallelism 1 --update-delay 15s myapp_apiРекомендации по безопасности релизов:
Для кластера из 3–5 нод Swarm проще в администрировании и обучении команды. Конкретные преимущества и сравнение времени настройки приведены ниже.
Сравнение по времени внедрения (практический опыт, 2025–2026):
Реальные показатели нагрузки и ресурсоёмкости:
Пример финансового сравнения (оценка на 2026 для 3 рабочих нод):
Исходя из этих цифр, для 3–5 нод Swarm обычно выигрывает по стоимости и скорости внедрения. Если у вас нет строгой потребности в StatefulSets, CustomResourceDefinitions и сложных operator'ах — Swarm рационален.
Переход на Kubernetes оправдан, когда ваши требования выходят за пределы возможностей Swarm или вы прогнозируете быстрый рост. Я привожу проверяемые триггеры, по которым начинал миграции в реальных проектах в 2025–2026 годах.
Триггеры миграции:
Оценка времени и ресурсов на миграцию (реальный кейс, SaaS-компания, 2025):
Стоимость (примерно, 2026):
Когда не стоит мигрировать сразу:
Kubernetes даёт мощь и гибкость, но цена входа — время и дополнительная стоимость инфраструктуры. Для большинства малых бизнесов разумный план: старт на Swarm, миграция на K8s при достижении чётких триггеров.
Swarm начинает ограничивать вас при росте числа сервисов выше ~30, когда требуется сложное управление storage или need operator'ы. Первое действие — провести аудит: сколько сервисов завязано на stateful storage, какие точки расширения (ingress, dns, secret management) и какие SLA нужны. Если проблема — только scaling и балансировка, можно временно масштабировать архитектуру через дополнительную сеть и разделение на несколько стеков. Если же требуется CSI, PVC и strict multi-tenant изоляция — планируйте миграцию на K8s и резервное время 2–6 недель.
Ориентировочно: при аренде VPS $8–15/нода в месяц поддержка Swarm потребует 0.2–0.6 ставки инженера (примерно $300–1200/мес) плюс инфраструктура $24–75/мес. K8s (self-managed) добавит 1–2 дополнительных ноды control plane или увеличит нагрузку на инфраструктуру — итог $48–150/мес инфраструктура и $800–3000/мес на поддержку при увеличении сложности. Managed K8s повышает инфраструктурный счёт (control plane и дополнительные сервисы), но снижает время на администрирование, если у вас недостаточно DevOps-ресурсов.
План теста: 1) Подготовьте staging-окружение на K8s, которое зеркалит продакшен (сеть, секреты, storage). 2) Проводите canary-деплой по одному сервису с пробросом трафикa через ingress. 3) Используйте метрики (Prometheus) и логирование (EFK/ELK) для сравнения латентностей и ошибок. 4) Держите возможность быстрой откатки — сохраняйте docker-compose и скрипты деплоя Swarm, настройте синхронные бэкапы БД. Опыт показывает: на 15 сервисов перевод по одному займет 2–4 недели при условии регулярного тестирования.
Для 3–5 нод оптимально: Prometheus + Grafana для метрик и Loki или EFK (Elasticsearch, Fluentd, Kibana) для логов. Развёртка Prometheus + Grafana занимает 4–8 часов; Loki проще и дешевле в хранении логов при низком трафике. Для упрощения можно использовать SaaS-решения (Grafana Cloud, Logz.io) — их стоимость при малых объёмах начинается от $0–$50/мес и сокращает время поддержки на 10–30 часов в месяц.
Если нужно, могу прислать чек-лист миграции на K8s и пример terraform-скриптов для provisioning (аналогичные материалы есть в разделе DevOps).
Оценка стоимости Swarm и Kubernetes 2026
Если вы хотите получить персональную оценку: укажите текущую конфигурацию (число нод, сервисов, нагрузку в RPS, требования к storage и резервированию), и я пришлю план миграции и примерный бюджет на 4–8 недель.
Комментарии (0)
Войдите или зарегистрируйтесь, чтобы оставить комментарий
Загрузка комментариев…