Docker Swarm vs Kubernetes

Docker Swarm і Kubernetes вирішують схожу задачу: підтримують задану кількість контейнерів, розподіляють їх між вузлами, перезапускають після збою та оновлюють без одночасної зупинки всіх реплік. Але однакова мета не означає однакову ціну експлуатації. Swarm вбудований у Docker Engine і швидко запускається на кількох серверах. Kubernetes складається з окремого control plane, API та набору контролерів, зате дає значно ширшу модель для мережі, storage, політик, autoscaling і розширення платформи.

Практичний вибір не варто робити за популярністю або кількістю YAML. Потрібно порівняти реальний workload: скільки сервісів працює, як часто вони оновлюються, чи потрібні кілька команд і середовищ, які вимоги до відмовостійкості, де зберігаються дані та хто обслуговуватиме control plane. У цій статті розгорнемо однаковий вебсервіс у двох оркестраторах, виконаємо scaling, rolling update і rollback, а потім розберемо експлуатаційні відмінності.

Обидва варіанти потребують дисципліни навколо образів, секретів, журналів, backup і спостережуваності. Оркестратор не виправить контейнер без health check, образ із тегом `latest` або базу даних без перевіреного відновлення. Якщо платформа має регулярно приймати зміни, її архітектуру доречно розглядати разом із DevOps-супроводом інфраструктури, а не як одноразове встановлення кластера.

Від яких вимог починати порівняння

Спочатку опишіть не бажаний інструмент, а обмеження системи. Для невеликої команди це можуть бути три Linux-сервери, до десяти stateless-сервісів, один зовнішній load balancer і кілька оновлень на місяць. Тут простота Swarm має вимірювану цінність: Docker Engine вже містить потрібні команди, overlay network, service discovery, secrets і routing mesh. Адміністратор підтримує менше компонентів і швидше розбирається з інцидентом.

Інший сценарій — десятки сервісів, кілька середовищ, окремі команди, autoscaling, NetworkPolicy, оператори баз даних, різні StorageClass, admission policies та GitOps. Тут Kubernetes складніший на старті, але його API дає спільну модель для всіх цих вимог. Екосистема не просто додає інструменти: вона дозволяє описати правила платформи як декларативні ресурси й застосовувати їх однаково.

Окремо оцініть control plane. У production Swarm один manager є точкою ризику для керування. Запущені tasks можуть продовжити роботу після його втрати, але без quorum кластер не зможе нормально змінювати desired state і переплановувати навантаження. Для стійкої схеми потрібна непарна кількість manager nodes, зазвичай три. Kubernetes також потребує високодоступного control plane та etcd, якщо це не managed-сервіс провайдера.

Перед рішенням запишіть відповіді на такі запитання:

- хто оновлює кластер і реагує на проблеми control plane; - чи потрібні автоматичне горизонтальне масштабування та складні placement rules; - чи є stateful workloads і яким способом відновлюються їхні дані; - чи потрібна ізоляція команд через namespaces, RBAC і policy engine; - скільки інтеграцій мають monitoring, ingress, secrets і delivery pipeline; - чи планується перенос між хмарою, bare metal і локальними серверами.

Цей список швидко показує, чи економія на стартовій складності залишиться перевагою через рік.

Практичний запуск сервісу в Docker Swarm

На першому manager встановіть Docker Engine, відкрийте між вузлами потрібні порти та ініціалізуйте swarm на стабільній внутрішній адресі. Не використовуйте випадковий interface: інші вузли повинні завжди досягати advertise address.

export MANAGER_IP="10.20.0.10"

docker swarm init --advertise-addr "$MANAGER_IP"
docker node ls
docker swarm join-token worker
docker swarm join-token manager

Команди join містять секретний token. Передавайте їх захищеним каналом і ротувайте після підозри на витік. Для production додайте ще два manager nodes, а worker-вузли приєднайте з worker token. Щоб застосунки не займали ресурси control plane, переведіть managers у стан `drain` після появи достатньої кількості workers:

docker node update --availability drain manager-1
docker node update --availability drain manager-2
docker node update --availability drain manager-3
docker node ls

Створіть overlay network і service з трьома репліками. Фіксуйте образ за незмінним digest у production; тег нижче залишений читабельним для прикладу.

docker network create --driver overlay --attachable frontend

docker service create \
  --name web \
  --network frontend \
  --replicas 3 \
  --publish published=8080,target=80 \
  --limit-cpu 0.50 \
  --limit-memory 256M \
  --update-parallelism 1 \
  --update-delay 10s \
  --update-failure-action rollback \
  nginx:1.27-alpine

docker service ls
docker service ps web
curl -I "http://${MANAGER_IP}:8080"

Routing mesh приймає published port на вузлах swarm і спрямовує запит до task. Для передбачуваного зовнішнього трафіку все одно потрібні DNS, TLS і load balancer із health checks. Вбудована маршрутизація не замінює продуманий ingress-контур.

Scaling і rolling update виконуються однією командою:

docker service scale web=5

docker service update \
  --image nginx:1.28-alpine \
  --update-parallelism 1 \
  --update-delay 10s \
  web

docker service ps web

Якщо нова версія не проходить перевірки, поверніть попередню конфігурацію:

docker service update --rollback web
docker service ps web

Swarm secrets створюються окремо й надаються лише потрібному service. Контейнер отримує секрет як файл у `/run/secrets`, а не як частину image:

printf '%s' 'REPLACE_WITH_SECRET' | docker secret create api_token -
docker service update --secret-add api_token web
docker secret ls

Для багатокомпонентного застосунку використовуйте `docker stack deploy` і version-controlled Compose-файл. Однак bind mount прив’язує task до конкретного host path. Для stateful data потрібні placement constraints, спільний storage або driver, backup і перевірений сценарій переносу task на інший вузол.

Той самий сценарій у Kubernetes

Kubernetes розділяє workload і мережеву точку доступу. Deployment керує ReplicaSet і Pod, а Service надає стабільну адресу. Перед виконанням перевірте context, щоб випадково не змінити інший кластер:

kubectl config current-context
kubectl get nodes -o wide
kubectl create namespace orchestrator-demo

Збережіть Deployment і Service у `web.yaml`. Readiness probe не дозволяє спрямовувати traffic на неготовий Pod, а resource requests дають scheduler дані для розміщення.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  namespace: orchestrator-demo
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0
      maxSurge: 1
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: nginx
          image: nginx:1.27-alpine
          ports:
            - containerPort: 80
          resources:
            requests:
              cpu: 100m
              memory: 64Mi
            limits:
              cpu: 500m
              memory: 256Mi
          readinessProbe:
            httpGet:
              path: /
              port: 80
            initialDelaySeconds: 3
            periodSeconds: 5
---
apiVersion: v1
kind: Service
metadata:
  name: web
  namespace: orchestrator-demo
spec:
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 80
  type: ClusterIP

Застосуйте manifest і перевірте rollout:

kubectl apply -f web.yaml
kubectl -n orchestrator-demo rollout status deployment/web
kubectl -n orchestrator-demo get deployment,pods,service
kubectl -n orchestrator-demo port-forward service/web 8080:80

Для зовнішнього доступу додайте Ingress або Gateway API відповідно до встановленого controller. `ClusterIP` навмисно не відкриває NodePort на всіх вузлах. Масштабування, оновлення й rollback виглядають так:

kubectl -n orchestrator-demo scale deployment/web --replicas=5

kubectl -n orchestrator-demo set image \
  deployment/web nginx=nginx:1.28-alpine

kubectl -n orchestrator-demo rollout status deployment/web
kubectl -n orchestrator-demo rollout history deployment/web

kubectl -n orchestrator-demo rollout undo deployment/web
kubectl -n orchestrator-demo rollout status deployment/web

Secret можна створити без запису значення у YAML. Проте base64 у Kubernetes Secret не є шифруванням: потрібні encryption at rest для etcd, обмежений RBAC і, за потреби, зовнішній secret manager.

kubectl -n orchestrator-demo create secret generic api-token \
  --from-literal=token='REPLACE_WITH_SECRET'

kubectl -n orchestrator-demo get secret api-token

Для production зберігайте manifests або Helm chart у Git і застосовуйте через контрольований CI/CD pipeline. Імперативні команди з прикладу зручні для навчання, але не повинні залишатися єдиним джерелом desired state.

Мережа, storage, scaling та щоденна експлуатація

Swarm дає overlay network, internal DNS і routing mesh без окремого CNI. Для кількох сервісів це суттєво скорочує час запуску. Kubernetes вимагає network plugin і ingress-рішення, зате підтримує NetworkPolicy, кілька класів ingress, Gateway API, service mesh та ширші інтеграції з cloud load balancer. Якщо потрібна сегментація east-west traffic, можливості Kubernetes зазвичай точніші.

У Swarm replicated service і global service покривають основні схеми розміщення. Constraints та preferences дозволяють враховувати labels вузлів. Kubernetes має Deployment, StatefulSet, DaemonSet, Job і CronJob, affinity, anti-affinity, taints, topology spread, priorities та disruption budgets. Це збільшує кількість понять, але дозволяє описати поведінку різних workload без зовнішніх скриптів.

Persistent data потребує окремого проєктування в обох системах. Swarm volume може бути локальним до вузла, тому автоматично перенесений task не обов’язково побачить старі дані. Kubernetes абстрагує storage через PersistentVolume, PersistentVolumeClaim, StorageClass і CSI. Це спрощує інтеграцію з провайдерами, але не скасовує backup, snapshot consistency та перевірку restore. Для Kubernetes-кластера корисно заздалегідь пройти практичне встановлення Kubernetes на Ubuntu 24.04, щоб розуміти control plane до переносу застосунків.

Autoscaling є помітною межею. Swarm не має вбудованого аналога HorizontalPodAutoscaler, який змінює replicas за метриками. Це можна реалізувати зовнішньою автоматизацією, але її доведеться підтримувати самостійно. Kubernetes має HPA API, інтеграцію з metrics pipeline та ширші механізми node autoscaling у відповідному середовищі.

Спостережуваність не виникає автоматично. В обох випадках потрібні централізовані metrics, logs, alerts і трасування. Для Swarm перевіряйте manager quorum, nodes, services, tasks і overlay network. Для Kubernetes — control plane, nodes, pending Pods, workloads, events, API latency, storage і controllers. Складніша система має більше точок відмови, тому Kubernetes без monitoring може бути менш передбачуваним, ніж добре обслуговуваний Swarm.

Типові помилки під час вибору та міграції

Перша помилка — оцінювати лише швидкість першого deploy. Swarm майже завжди виглядає простішим у короткому тесті, але рішення має враховувати наступні кілька років: нові середовища, policy, autoscaling, кількість сервісів і доступність фахівців. Kubernetes не варто впроваджувати лише «на майбутнє», якщо команда не має вимог, які окупають його експлуатаційну складність.

Друга помилка — порівнювати Docker Compose із Kubernetes і забувати про Swarm services. Compose на одному host не забезпечує quorum, scheduler і rescheduling між серверами. Водночас `docker stack deploy` не підтримує кожну нову можливість локального Compose однаково, тому файл потрібно перевіряти саме в Swarm.

Третя помилка — переносити stateful container так само, як stateless web. Репліка бази даних не стає кластером тільки через `replicas: 3`. Потрібні storage topology, consensus самої бази, backups, порядок старту і тест аварійного відновлення. Оркестратор керує процесами, але не винаходить консистентність даних.

Четверта помилка — використовувати один manager у production Swarm або один control-plane node у самостійно керованому Kubernetes без прийнятого ризику. Втрата quorum змінює поведінку scheduler і операцій керування. Перевіряйте відмову вузла на тестовому середовищі, а не вірте лише діаграмі архітектури.

П’ята помилка — мігрувати manifest механічно. Swarm secret і Kubernetes Secret мають різні моделі; routing mesh не дорівнює Ingress; volume driver не дорівнює CSI StorageClass; healthcheck image не завжди правильно перетворюється на readiness і liveness probes. Міграція повинна включати тест traffic, update, rollback, node drain, backup і restore.

Висновок

Docker Swarm доречний, коли потрібен зрозумілий кластер поверх Docker Engine, кількість сервісів невелика, вимоги до policy й autoscaling обмежені, а головна цінність — низька операційна складність. Він підтримує desired state, replicated і global services, overlay network, secrets, rolling update та rollback. За наявності трьох managers, backup Raft і зовнішнього monitoring це може бути надійна платформа для конкретного класу задач.

Kubernetes варто обирати, коли платформа має рости за кількістю workload і команд, потрібні namespaces, RBAC, NetworkPolicy, autoscaling, оператори, різні storage-профілі, GitOps або переносимість між провайдерами. Його перевага не в тому, що він запускає контейнер краще, а в багатій API-моделі та екосистемі для керування складною інфраструктурою.

Найкращий спосіб ухвалити рішення — зробити короткий proof of concept на реальному сервісі. Для кожного варіанта виміряйте час підготовки кластера, deploy, update, rollback, заміни вузла, відновлення даних і діагностики збою. Додайте в оцінку щомісячні години супроводу, а не лише вартість серверів.

Якщо Swarm уже стабільно виконує вимоги, міграція заради тренду створить ризик без гарантованого результату. Якщо зовнішні скрипти навколо Swarm постійно реалізують autoscaling, policy, ingress і складне розміщення, це сигнал оцінити Kubernetes. Вибір має зменшувати сумарну складність системи для конкретної команди, а не переносити її з orchestration layer у ручні процедури.