k3s против Docker Swarm: что выгоднее и когда

MAATRIX

Обе технологии делают одно: раскладывают контейнеры по серверам, держат заданное число реплик и переживают падение ноды. Разница видна не в списке возможностей, а в цифрах — сколько памяти уходит на пустой кластер и что происходит через пять минут после смерти сервера. Разберём, k3s или Docker Swarm выгоднее, по замерам, текстам ошибок и таймингам отказа.

Коротко: k3s или Docker Swarm под вашу задачу

Вердикт таблицей — не «что круче», а что вам обслуживать руками.

Водораздел не в функциях, а в сложности, которую вы соглашаетесь содержать. У Swarm низкий пол — он уже стоит на сервере вместе с Docker и почти ничего не ест, — но и низкий потолок: дальше «разложить сервисы по нодам и обновить без простоя» он не умеет ничего нового. У k3s пол выше на полгигабайта памяти, зато потолок упирается уже не в оркестратор. При одном сервере хватит Docker Compose для продакшена.

Живы ли оба проекта в 2026 году

Docker Swarm — режим оркестрации, встроенный в Docker Engine (тот самый swarm mode, а не мёртвый standalone-продукт 2015 года). Что у вас сейчас, покажут docker version --format '{{.Server.Version}}' (на актуальной ветке 28.x) и docker info --format '{{.Swarm.LocalNodeState}}' — inactive до инициализации, active после. Честно: Swarm поддерживается, но не развивается, коммиты в swarmkit последних лет — зависимости и CVE. Не «умирает», а «застыл», и для инфраструктуры это не всегда минус.

k3s — сертифицированный CNCF дистрибутив Kubernetes от SUSE: один бинарник на ~70 МБ, внутри containerd, CoreDNS, Traefik и балансировщик. Релизы трижды в год, версии вида v1.33.4+k3s1. Обратная сторона живости — депрекейт API: раз в год-полтора читаешь changelog перед обновлением, иначе манифест, работавший два года, ответит no matches for kind "Ingress" in version "extensions/v1beta1". Это плата за экосистему: Helm-чарт есть почти для всего, оператор для Postgres — тоже, а для Swarm вы всё это напишете руками.

Сколько ресурсов съедает сам оркестратор

Самая недооценённая строка. Цифры со стенда — чистая Ubuntu 24.04, 2 vCPU / 4 ГБ, ни одного своего контейнера:

systemctl show docker -p MemoryCurrent
MemoryCurrent=91234304
systemctl show k3s -p MemoryCurrent
MemoryCurrent=584056832

Docker со Swarm — около 87 МБ, плюс сервис containerd ещё 40–50 МБ: итого 130–140 МБ на пустом кластере. k3s — около 557 МБ. Отключение Traefik и metrics-server опускает его до ~430 МБ, ниже не уйдёт: kube-apiserver и kube-controller-manager — не украшения.

Swarm поднимается двумя командами: curl -fsSL https://get.docker.com | sh и docker swarm init --advertise-addr 185.203.11.42. Флаг пропускать нельзя — на VPS с приватной и публичной сетью получите это:

Error response from daemon: could not choose an IP address to advertise since this system has multiple addresses on different interfaces (10.0.0.5 on eth1 and 185.203.11.42 on eth0) - specify one with --advertise-addr

Вторая грабля именно арендованных серверов: overlay-сеть Swarm использует VXLAN на 4789/udp, а часть провайдеров гоняет на этом порту свою внутреннюю фабрику. Симптом — кластер собирается, сервисы стартуют, но контейнеры на разных нодах не видят друг друга. Лечится только при инициализации, флагом --data-path-port 7789. Установка k3s — в отдельном руководстве.

Compose-стек против манифестов: где вы потеряете время

Swarm обещает: «у вас уже есть compose-файл, просто задеплойте его». Правда это процентов на семьдесят — docker stack deploy -c docker-compose.yml myapp молча выбрасывает часть ключей, сообщая об этом один раз:

Ignoring unsupported options: build, restart

Ignoring deprecated options:

container_name: Setting the container name is not supported.

Что перестаёт работать при переходе с docker compose up:

• build: — стек не собирает образы, нужен реестр: Docker Hub, ghcr.io или свой приватный registry. Иначе на второй ноде задача упадёт с No such image: myapp:1.0, и покажет это только docker service ps --no-trunc myapp_web.
• restart: — заменяется на deploy.restart_policy.
• depends_on: — игнорируется: порядок запуска не гарантирован, приложение обязано пережить отсутствие базы.
• container_name:, links:, network_mode: — не поддерживаются, а размещение и масштаб переезжают в секцию deploy:.

У k3s другая цена: тот же nginx с доступом снаружи — три объекта (Deployment, Service, Ingress) и около 60 строк YAML вместо восьми. kompose convert -f docker-compose.yml разложит стек на манифесты, но тома, переменные из .env и healthcheck переносит приблизительно. Зато дальше идёт то, чего у Swarm нет: helm install, операторы, автоприменение YAML из /var/lib/rancher/k3s/server/manifests/. И деталь первого дня: k3s не видит образы из docker build. Либо реестр, либо docker save myapp:1.0 | k3s ctr images import -.

Секреты. Здесь Swarm строже: docker secret create db_pass - кладёт значение в зашифрованный на диске Raft-лог и монтирует файлом в /run/secrets/db_pass. Объект Secret в Kubernetes по умолчанию лежит в базе обычным base64, то есть не зашифрован; в k3s шифрование включает флаг --secrets-encryption.

Сеть, публикация портов и TLS

У Swarm есть routing mesh: опубликованный порт открывается на каждой ноде, и запрос на любую из них через IPVS доедет до нужного контейнера. Удобно ровно до первого инцидента — и таких два.

Первая — теряется IP клиента: в логах nginx вы увидите не посетителя, а внутренний адрес вроде 10.0.0.2, и правила по IP с лимитами превращаются в тыкву. Обход — публиковать порт с mode: host в развёрнутой форме секции ports.

Вторая — ufw такие порты не закрывает. Docker пишет свои правила в netfilter раньше пользовательских, и порт остаётся открыт всему интернету при включённом фаерволе. Для swarm-публикаций правило вставляют в DOCKER-INGRESS, и оно не переживает перезагрузку — сохраняйте через iptables-persistent:

iptables -I DOCKER-INGRESS 1 -p tcp --dport 8080 ! -s 203.0.113.7 -j DROP

TLS в Swarm из коробки нет, обычно ставят Traefik. Важная деталь 2026 года: в Traefik v3 опции providers.docker.swarmMode больше не существует, для Swarm заведён отдельный провайдер providers.swarm. Конфиги трёхлетней давности не заведутся, а ошибка невнятная — провайдер не найдёт ни одного сервиса. У k3s Ingress уже внутри: Traefik v3 на 80 и 443 через ServiceLB, сертификаты от cert-manager.

Отказ ноды: кворум, тайминги и данные

Самый неожиданный результат: по умолчанию Swarm восстанавливается быстрее. Замер на двух одинаковых стендах из трёх нод, жёсткое выключение ноды с репликой:

• Swarm. Через 15–20 секунд без heartbeat docker node ls показывает Down, задача сразу пересоздаётся на живой ноде. До состояния Running — около 25 секунд.
• k3s без настройки. Нода уходит в NotReady через 40–50 секунд (node-monitor-grace-period), затем получает taint node.kubernetes.io/unreachable:NoExecute, а у подов терпение по умолчанию tolerationSeconds: 300. Под пересоздаётся примерно через 5 минут 45 секунд, всё это время вися в Terminating.

Терпение настраивается, и на боевом кластере это делают сразу, в /etc/rancher/k3s/config.yaml:

kube-apiserver-arg:
  - "default-not-ready-toleration-seconds=30"
  - "default-unreachable-toleration-seconds=30"
kube-controller-manager-arg:
  - "node-monitor-grace-period=20s"

После этого замена укладывается в минуту, но по умолчанию — почти шесть. И отдельно честно: поды из StatefulSet не переезжают вообще, Kubernetes не отличает «нода умерла» от «потеряла связь» и ждёт вашего kubectl delete pod --force.

Кворум. У обоих управляющие ноды держат Raft-подобный консенсус: нечётное число, три штуки переживают потерю одной. В Swarm потеря кворума выглядит так:

Error response from daemon: rpc error: code = Unknown desc = The swarm does not have a leader. It's possible that too few managers are online. Make sure more than half of the managers are online.

Контейнеры продолжают работать, ломается управление; лечится docker swarm init --force-new-cluster на выжившем менеджере. У k3s кворум появляется лишь при встроенном etcd (--cluster-init и три сервера), по умолчанию состояние в SQLite — одна точка отказа. И etcd чувствителен к RTT: выше 20–30 мс идут etcdserver: request timed out, так что тройку держат в одной локации.

Данные — паритет, и не в лучшую сторону. Named volume в Swarm привязан к ноде: переехавшая задача найдёт пустой том, и выход один — прибить сервис через placement.constraints. У k3s то же с local-path-provisioner, но есть путь наружу: helm install longhorn даёт реплицируемые тома.

Откат — место, где Swarm выигрывает: автовозврат на прошлую версию включает флаг --update-failure-action rollback, ручной — docker service rollback myapp_web. В Kubernetes kubectl rollout status deploy/web вернёт error: deployment "web" exceeded its progress deadline, деплой встанет, а откатывать придётся самому.

Какой сервер взять под k3s или Swarm в MAATRIX

Конфигурация зависит от выбора, и разница ощутимая.

Минимум честно. Для Swarm это 2 ГБ на ноду: демон занимает 140 МБ, остальное ваше. Для k3s минимум в 1 ГБ — ловушка: control-plane заберёт 550–600 МБ, и первая же сборка закончится OOMKilled с кодом выхода 137. Рабочий минимум — 2 ГБ на стенд и 4 ГБ на боевое (сколько RAM нужно для k3s).

Комфортный вариант. Три ноды по 2 vCPU / 4 ГБ под Swarm и один узел 4 vCPU / 8 ГБ под k3s стоят примерно одинаково, так что выбирайте по первой таблице, а не по цене. Диск только NVMe: и SQLite, и etcd упираются в задержку fsync, на медленном хранилище API-сервер сыплет таймаутами. Приватной сети между площадками нет — стройте кластер поверх WireGuard.

Локация — UK, Лондон. Причина инженерная: кластер круглосуточно тянет образы с Docker Hub, ghcr.io и quay.io, чарты с artifacthub, пакеты с npm и PyPI. С российских адресов часть реестров отвечает 403 или работает через раз, и чинить вы будете не приложение, а доступ к зеркалам. Британская площадка ходит везде без ухищрений, Let's Encrypt проходит HTTP-01 без сюрпризов, пинг до европейских точек обмена — 10–20 мс. FR — то же для континентальной Европы и GDPR, US — если в кластере есть обращения к зарубежным AI-API, RU — под 152-ФЗ.

Оплата — картами российских банков, по СБП, криптовалютой или токеном MAAT. Не уверены, какой оркестратор брать, — напишите, сколько у вас сервисов и сколько людей будет их обслуживать: чаще решает второе число. Смежное: Docker Swarm на VPS, ошибки Docker Swarm.

Частые вопросы