Nomad, Kubernetes чи Docker Swarm: що обрати?

Блог WebDisk · категорія: Публічна хмара · час читання: ~22 хвилини

Коротко:- Це не три версії того самого інструмента. Swarm — це функція рушія Docker, яку ви вже маєте; Kubernetes хоче бути платформою і віддає вам на вибір — а також на утримання — мережу, сховище та вхідний трафік; Nomad обмежується однією роллю: планувальника завдань.- Найбільша перевага Nomad над Kubernetes не стосується контейнерів. Це одна бінарка, один файл опису розгортання і драйвери, які запускають також звичайні процеси та застосунки Java — без пакування кожного з них в образ.- Обирайте за вартістю утримання, а не за списком функцій: до десяти вузлів — Swarm; змішані навантаження та невелика платформна команда — Nomad; великий масштаб і регуляторні вимоги — Kubernetes. Ціна Nomad: ліцензія BUSL 1.1 (ліцензіаром є IBM) і кінець гілки з довгостроковою підтримкою (LTS) 30 квітня 2027 року. >Не працюєте з терміналом? Пропустіть блоки коду — опис відмінностей, розділ «Як обрати?» і частина про ризики дають повну картину без жодної команди.

Розмова про оркестрацію контейнерів починається сьогодні зазвичай із фрази «ну, тоді беремо Kubernetes», а закінчується через півроку запитанням, хто, власне, має його утримувати. Між цими двома моментами вміщується цілий клас рішень, які легше ухвалити на початку, ніж відкрутити пізніше: скільки шарів вам справді потрібно, скільки з них хтось у компанії зуміє полагодити о третій ночі і що станеться, коли автор інструмента змінить ліцензію.

Оркестратор — це програма, яка стежить, щоб задекларована кількість копій застосунку працювала на доступних серверах: вона сама обирає машину, переносить завдання після відмови вузла, змінює версію без перерви в роботі та реєструє, де саме зараз працює конкретна служба. На практиці вибір зводиться сьогодні до трьох інструментів: Docker Swarm, HashiCorp Nomad і Kubernetes — із застереженням, що лише останній узагалі вимірюється в найбільших галузевих дослідженнях.

Ця стаття показує, чим вони відрізняються не функціями з таблички, а філософією — а потім спускається до конкретики: який вигляд має файл розгортання в Nomad, як випустити нову версію канарковим методом (один екземпляр нової версії поруч зі старою, щоб перевірити «наживо»), як запустити застосунок, якого немає в жодному образі, і де Nomad реально виграє в Kubernetes, а де так само реально програє. Ми пишемо цей текст для команд, які стоять перед вибором уперше, і для тих, хто Kubernetes уже має — а починає підозрювати, що для їхнього масштабу це був вибір на розмір завеликий. Усі числа й дати походять із першоджерел і є актуальними на кінець серпня 2026 року; там, де число походить із матеріалу виробника, а не з вимірювання, ми кажемо про це прямо.

Чим Nomad, Kubernetes і Docker Swarm відрізняються насправді?

Найчастіша помилка в порівняннях полягає в зіставленні списків функцій. Різниця починається раніше — у тому, наскільки широко кожен із цих інструментів визначає власну відповідальність.

Kubernetes хоче бути платформою. Він має API для мережі, сховища, політик, вхідного трафіку та прав доступу. Але «вбудоване» означає тут зазвичай «вбудований інтерфейс плюс зовнішня реалізація, яку ви самі оберете й будете утримувати». Мережу Kubernetes не постачає — він визначає модель, а реалізують її плагіни CNI (стандарт підключення контейнерів до мережі). Сховище — це CSI (стандарт підключення дисків). Вхідний трафік — це Ingress, інтерфейс, функціонально заморожений, наступником якого є Gateway API. Наскільки дошкульним буває такий розподіл ролей, показав 2026 рік: ingress-nginx, найпопулярніший контролер вхідного трафіку, був виведений з обігу мережевою командою проєкту разом із патчами безпеки. Компонент, на якому стояв продакшн-трафік тисяч компаній, змінився під ними.

Nomad хоче бути лише планувальником — і каже це прямо у власній документації: Kubernetes цілиться в комплект функцій, потрібних для запуску контейнерних застосунків, а Nomad зосереджується на керуванні кластером і плануванні завдань. Решта делегується: повний шар служб — до Consul, секрети — до Vault або OpenBao (це окремі продукти того самого виробника), мережа поза режимом хоста й мосту — до CNI, сховище — до CSI, автомасштабування — до окремого демона. Це не брак — це проєктне рішення, яке має свою ціну і свою нагороду.

Docker Swarm реалізує все сам, але обсяг вузький. Без встановлення чогось додаткового ви отримуєте керування кластером із рівня звичайного CLI Docker, декларативний опис служби, масштабування, оверлейну мережу (віртуальну мережу, розтягнуту понад реальною мережею серверів), виявлення служб через DNS із балансуванням трафіку, покрокові оновлення і — що варто оцінити — взаємну автентифікацію TLS між вузлами, увімкнену за замовчуванням, із сертифікатами, які поновлюються кожні три місяці. Ви не отримуєте ані просторів імен, ані контролю доступу на основі ролей у самому рушії, ані автомасштабування, ані зрілої підтримки сховища.

Де проходить межа «одного застосунку» в кожному з цих інструментів?

Це розрізнення вирішує, як ви будете описувати розгортання протягом наступних років.

Docker Swarm — немає шару спільного розміщення (завдання — це один контейнер); одиницею масштабування є служба (service); усе описує один файл Compose з N служб.
Nomad — спільне розміщення й масштабування — це та сама річ: група (group); увесь застосунок описує один файл опису завдання.
Kubernetes — спільне розміщення — це pod, масштабування — це Deployment (через ReplicaSet); один застосунок — це зазвичай 4–8 об’єктів, часто в кількох файлах.

Із цього випливають три речі, про які варто знати перед вибором:

Swarm не має шару спільного розміщення. Допоміжний контейнер — мережевий посередник, агент, що збирає логи, експортер метрик — у Swarm є окремою службою, тож він втрачає гарантію спільного мережевого простору та спільного тому із застосунком. Це блокує цілий клас архітектур, а не лише псує зручність.
У Nomad група декларується прямо, у Kubernetes pod виникає мимохідь. У Kubernetes ви описуєте шаблон в об’єкті Deployment і отримуєте pod-и, яких самі не створюєте і яких не можна перенести — їх можна лише створити наново. У Nomad ви пишете групу і знаєте, що саме вона є водночас одиницею спільного розміщення й масштабування.
Те, що в Kubernetes є окремими видами об’єктів, у Nomad є одним полем. type = "service" відповідає Deployment, type = "batch" — об’єкту Job, type = "system" — DaemonSet, а type = "sysbatch" — одноразовому завданню, запущеному по разу на кожному відповідному вузлі, для чого в Kubernetes прямого відповідника немає. Один файл, одне поле, чотири поведінки.

Є ще відмінність, яку документація Kubernetes формулює сама: Kubernetes не є оркестратором у сенсі «зроби A, потім B», а є набором незалежних циклів керування, що підтягують поточний стан до бажаного. Наслідок дуже практичний — немає одного місця, в якому видно перебіг розгортання. У Nomad воно є: nomad deployment status.

Чи Docker Swarm мертвий? Не той, про який ви думаєте

У мережі повторюється фраза «Swarm мертвий». Вона водночас правдива і хибна, бо стосується двох різних сутностей.

Docker Swarm «classic» — окремий продукт 2014 року, який зв’язував багато демонів Docker, — справді закритий: репозиторій заархівовано 1 лютого 2021 року, образ на Docker Hub має мітку «deprecated», а підтримку прибрано з рушія у версії 23.0. Саме про нього говорить більшість «оголошень про виведення з обігу», що ходять мережею.

Swarm mode, тобто режим, вбудований у Docker Engine від версії 1.12, не має оголошеної дати кінця підтримки. Код супроводжується: репозиторій moby/swarmkit не заархівовано, а коміти в головній гілці датовані кінцем серпня 2026 року. Лінія Docker Engine 29 принесла Swarm конкретні виправлення, зокрема усунення пошкоджень знімків Raft за великого стану кластера. Проте чесність вимагає навести другу половину: єдине офіційне повідомлення Docker на цю тему стоїть на сторінці «продукти, виведені з обігу та згорнуті», і звучить так, що режим Swarm залишається справним, але розвиток уповільнився на користь рішень на базі Kubernetes.

Практичні межі Swarm варто знати, перш ніж на нього ставити:

Немає автомасштабування. Тікет із пропозицією горизонтального масштабування служб лежить відкритий у репозиторії з серпня 2017 року — без реалізації.
Підтримка сховища через CSI експериментальна: без знімків, клонування та розширення томів.
docker stack deploy користується старим форматом Compose версії 3, несумісним із чинною специфікацією Compose. Частина ключів мовчки пропускається — розгортання виводить попередження та йде далі. «У мене працює в Compose» і «працює в stack» — це два різні твердження про той самий файл.
Секрети шифруються в стані спокою, configs уже ні — і потрапляють просто у файлову систему контейнера. Ліміт обох — 500 кБ.
Рекомендований максимум — сім керуючих вузлів, а кластер із N таких вузлів переживає втрату (N−1)/2 з них. Жодних порогів масштабованості Swarm не публікує.
Є ще сигнал, вартий спостереження під час планування на найближчі роки: на вузлі з увімкненим Swarm сьогодні не вдасться увімкнути nftables, а nftables має стати типовим механізмом фаєрвола в Docker — проте виробник не подає ані версії, ані дати.

Комерційну підтримку пропонує Mirantis. У записі від липня 2025 року звучить декларація підтримки Swarm «щонайменше до 2030 року» в межах MKE 3, натомість опублікована матриця життєвого циклу сягає сьогодні березня 2028 року, а MKE 4 є вже виключно kubernetes-продуктом. Ці два джерела охоплюють різні горизонти, тож при багаторічному плануванні дату кінця підтримки треба підтвердити в постачальника письмово.

Коли Swarm має сенс? Коли у вас від кількох до кільканадцяти вузлів, одна команда, передбачуваний трафік і ніхто, хто утримував би кластер на повну ставку. Останнє важливіше, ніж здається: кластер Kubernetes, піднятий самостійно інструментом kubeadm і незайманий протягом року, просто перестане працювати, бо спливуть однорічні сертифікати керуючого шару — поновлює їх лише оновлення. У керованій послузі це робить за вас постачальник. Swarm за таких умов постаріє повільніше. Зрештою, дані самого Mirantis — опубліковані 2022 року і повторені 2024-го слово в слово, без розкритої методології — після перерахунку дають у середньому близько десяти вузлів і ста контейнерів на кластер. Swarm у реальному світі служить не для побудови великих кластерів, а багатьох малих. Це його чесна ніша, а не поразка.

Скільки насправді коштує Kubernetes, перш ніж ви виставите перший застосунок?

Kubernetes сьогодні є типовим вибором і має для цього тверді підстави: ліцензія Apache 2.0, нейтральне врядування в межах фундації CNCF, найбільша екосистема та керовані послуги в кожного великого постачальника. Згідно з опитуванням CNCF, 82% користувачів контейнерів запускають Kubernetes у продакшні (увага на базу: це частка користувачів контейнерів, а не всіх організацій).

Проте ціна є обчислюваною, і варто побачити її в числах, а не в прикметниках:

Керуючий шар — це окремі процеси: сервер API, база etcd, планувальник, менеджер контролерів, а на вузлі — kubelet і середовище виконання контейнерів. До того ж CNI і CoreDNS, без яких кластер практично не працює.
Понятійна поверхня велика й обчислювана: офіційний довідник API перелічує 22 групи API. Щоб виставити один HTTP-застосунок у продакшн, треба розуміти pod-и, Deployment, ReplicaSet, Service, Ingress або Gateway API, простори імен, ConfigMap, Secret, PVC/PV/StorageClass, запити та ліміти ресурсів, три види проб, сервісний обліковий запис із роллю та прив’язкою, мережеві політики — плюс обрати Helm або Kustomize, CNI і CSI.
Оновлення — це обов’язок, а не опція. Підтримуються три останні гілки (наразі 1.37 «Garhwal», випущена 26 серпня 2026 року), а вікно підтримки одного релізу — близько 14 місяців. Сервер API не може перестрибнути реліз — версії підіймають по черзі. Скільки це коштує, найкраще видно в прайсі: в Amazon EKS керуючий шар — це 0,10 USD за кластер на годину, а продовжена підтримка старішої версії — 0,60 USD, тобто вшестеро більше виключно за те, що ви не оновлюєтеся.
Масштаб виміряний і оголошений: до 110 pod-ів на вузол, до 5000 вузлів, до 150 000 pod-ів. Це, зрештою, перевага, а не вада — два інші інструменти таких порогів не публікують. Варто лише читати їх так, як вони написані: це вимірювальні межі, а притискання двох вимірів одночасно розвалить кластер значно раніше.

Часте непорозуміння: k3s. Цей дистрибутив реально знижує вартість встановлення та споживання ресурсів, але не знижує понятійної вартості ані на йоту — це сертифікований Kubernetes із тим самим API. Хто береться за k3s, щоб «Kubernetes був простішим», розв’язує іншу проблему, ніж має. Який вигляд має добре утримання такого кластера — оновлення, резервна копія бази etcd, спостережуваність, чергування — ми описали окремо у статті Технічна підтримка Kubernetes: підняти кластер — це найлегший етап. А про те, як вартість інструмента переходить у залежність від його автора, ми пишемо у статті Vendor lock-in у публічній хмарі.

Що ви отримуєте, коли оркестратор — це одна бінарка?

Nomad є єдиною програмою, написаною на Go, яка залежно від конфігурації працює як сервер або як клієнт. Немає зовнішньої бази даних — узгодженість стану забезпечує вбудований алгоритм консенсусу Raft (механізм, у якому сервери узгоджують одну спільну версію правди), тож тут немає відповідника etcd, який треба резервувати, оновлювати й налаштовувати. Продакшн-регіон — це три або п’ять серверів: три переживають відмову одного, п’ять — двох. Ідеться про кворум, тобто більшість, яка має домовитися, щоб кластер ухвалював рішення. Кількість клієнтів виробник не обмежує жодним опублікованим порогом.

Масштаб збільшують додаванням регіонів, а не потовщенням кворуму. Регіони цілком незалежні — вони не ділять ані завдань, ані клієнтів, ані стану — а поєднує їх легкий протокол обміну інформацією між серверами (gossip), завдяки чому виклик API з параметром регіону сам потрапляє до належного регіону. З авторитативного регіону реплікуються політики доступу, ролі, простори імен, пули вузлів і ліміти. Для порівняння: у Kubernetes багаторегіональність є проблемою архітектури, а не конфігурації — проєкт KubeFed заархівовано, а група, що займається багатьма кластерами, свідомо постачає API без референсної реалізації.

Два застереження, без яких ця картина була б рекламою:

Блок multiregion в описі завдання вимагає версії Enterprise і не забезпечує автоматичного аварійного перемикання між регіонами. Федерація регіонів — це не те саме, що висока доступність між локаціями.
Документація Nomad каже прямо: «Nomad is not secure-by-default» — Nomad не є безпечним за замовчуванням — а списки контролю доступу (ACL) вимкнені за замовчуванням. Кластер, піднятий «нашвидкуруч» і виставлений назовні без їх увімкнення, — це не теоретичний ризик.

Три слова, які повертатимуться

Перш ніж поглянете на перший файл: три поняття українською хотілося б назвати однаково — «завданням» — тож розділімо їх одразу.

job — увесь опис застосунку: один файл, одна назва, одна версія. Саме його розгортають, відкочують і зупиняють.
task — окремий процес або контейнер усередині job.
алокація (allocation) — одна копія групи завдань, запущена на конкретному клієнті, відповідник pod-а в Kubernetes. Масштабування до трьох екземплярів — це три алокації; відмова вузла — це зникнення алокації і створення нової в іншому місці. Якщо в команді бачите alloc, ідеться саме про це.

Nomad описують у HCL (HashiCorp Configuration Language) — тією самою мовою конфігурації, що й Terraform: блоки вкладаються у фігурні дужки, відступи нічого не означають, а сама мова має змінні, вирази й цикли. Нижче — повний файл: два екземпляри вебзастосунку, ліміти ресурсів, динамічний порт, реєстрація служби та перевірка стану.

job "webapp" {
  # type за замовчуванням = "service"; вказуємо явно для читабельності
  type = "service"
  datacenters = ["dc1"]

  group "web" {
    count = 2

    network {
      # порт без "static" = динамічний порт, виділений Nomad на хості;
      # "to" каже, на який порт потрапляє трафік УСЕРЕДИНІ контейнера
      port "http" {
        to = 8080
      }
    }

    service {
      name = "webapp"

      # УВАГА: значення за замовчуванням — "consul". Без цього рядка Nomad намагається
      # зареєструвати службу в Consul, і job не стартує, коли Consul відсутній.
      provider = "nomad"

      port = "http"
      tags = ["web", "public"]

      check {
        # при provider = "nomad" дозволені ВИКЛЮЧНО типи "http" і "tcp".
        # Блок check успадковує порт від сервісу - повторювати його не треба.
        type = "http"
        path = "/health"
        interval = "10s"
        timeout = "2s"
      }
    }

    task "server" {
      driver = "docker"

      config {
        image = "hashicorp/http-echo:1.0"
        args = ["-listen", ":8080", "-text", "hello from nomad"]
        ports = ["http"] # список МІТОК портів із блоку network
      }

      resources {
        cpu = 200 # MHz - Nomad резервує такт, а не частку ядра, як K8s
        memory = 256 # MB
      }
    }
  }
}

Чотири речі, на яких спотикається більшість початківців — варто знати їх, перш ніж втратите на них вечір:

provider за замовчуванням має значення "consul". Без явного provider = "nomad" завдання в кластері без Consul не стартує. Це найчастіша стартова помилка.
При нативній реєстрації дозволені виключно перевірки http і tcp.
Порти декларуються виключно в group -> network і вказуються через ports = [...] у конфігурації завдання. Nomad вставляє в завдання змінні NOMAD_ADDR_<мітка>, NOMAD_PORT_<мітка> і NOMAD_IP_<мітка>.
Нативний реєстр не дає DNS. При provider = "nomad" не існує імен на кшталт webapp.service.consul; адресу й порт зчитують з API, з nomad service info або з блоку template. Хто впише назву служби як ім’я хоста, отримає помилку розв’язання імені і зазвичай шукатиме її зовсім в іншому місці. Це одна з речей, які додає Consul.

Варто також спростувати два міфи, що ходять в обидва боки. «Nomad без Consul не працює» — це неправда: нативне виявлення служб існує від версії 1.3, а перевірки стану до нього — від 1.4. Але «Nomad не потребує CNI» — це спрощення: режим мостової мережі вимагає плагінів CNI на всіх клієнтах Linux.

Як випустити нову версію без простою і без будіння людини?

Увесь механізм безпечного випуску вміщується в одному блоці, який ви додаєте до групи:

update {
  max_parallel = 2 # скільки алокацій змінюється ОДНОЧАСНО (за замовчуванням 1)

  # звідки Nomad знає, що алокація здорова:
  # "checks" - таски працюють І перевірки служби зелені (за замовчуванням)
  # "task_states" - достатньо, щоб таски стартували
  # "manual" - здоров’я позначає оператор через API
  health_check = "checks"

  min_healthy_time = "30s" # як довго має бути здоровою, щоб визнати її доброю
  healthy_deadline = "3m" # термін для ОКРЕМОЇ алокації
  progress_deadline = "10m" # термін ПРОГРЕСУ всього розгортання; має бути > healthy_deadline

  auto_revert = true # після невдалого розгортання повернись до останньої СТАБІЛЬНОЇ версії
  canary = 1 # скільки канарок поставити ПОРУЧ із робочою версією
  auto_promote = false # false = промоція вручну: nomad job promote webapp
}

Канарка — це один екземпляр нової версії, запущений поруч зі старою. Nomad сам не перемикає трафік — він реєструє канарку під окремими мітками (canary_tags) і чекає на ваше рішення; це ваше проксі вирішує, чи і коли почне спрямовувати до неї запити. До nomad job promote стара версія працює недоторканою. auto_revert натомість робить так, що невдалий випуск сам повертається до останньої робочої версії, без будіння людини.

Одна пастка, варта запам’ятовування: health_check = "checks" без визначеного блоку check означає розгортання, яке ніколи не підтвердить здоров’я і впаде аж на progress_deadline. Це найчастіша причина «завислих» розгортань.

Чи запустить оркестратор застосунок, якого немає в образі контейнера?

Якби треба було вказати одну річ, яка відрізняє Nomad від обох інших інструментів за принципом «можна/не можна», нею була б архітектура драйверів завдань (task drivers). У бінарку вбудовано п’ять: docker, exec, raw_exec, java і qemu — причому raw_exec запускає процес без жодної ізоляції і з цієї причини вимкнений за замовчуванням. Окремо встановлюють ще три офіційні: exec2, podman і virt. Драйвер є плагіном — власний можна написати без перекомпіляції Nomad.

На практиці це означає, що той самий планувальник, ті самі права доступу і той самий механізм розгортань обслуговують контейнер, звичайний процес, JAR-архів і віртуальну машину. Нижче — старіша служба, запущена як голий процес: без Docker на хості й без збирання образу:

# ФРАГМЕНТ: блок task завжди стоїть усередині job -> group -> task.
# Каркас job ідентичний до прикладу вище - змінюються
# ВИКЛЮЧНО driver і config (порт "http" походить із блоку network групи).
task "api" {
  # ізольований fork/exec: chroot (процес бачить лише виділений фрагмент
  # файлової системи) + простори імен, НУЛЬ Docker на хості
  driver = "exec"

  artifact {
    source = "https://artifacts.example/download/my-app-1.4.2"

    options {
      # checksum живе УСЕРЕДИНІ options. Завжди перевіряйте - artifact завантажує з мережі.
      checksum = "sha256:0f5e...zaminyty-na-spravzhniu"
    }
  }

  config {
    command = "local/my-app-1.4.2" # типова ціль artifact - каталог local/
    args = ["--listen", "${NOMAD_ADDR_http}"]
  }

  resources {
    cpu = 300
    memory = 256
  }
}

Решта файлу — job, group, network з динамічним портом і service з перевіркою стану — має вигляд точно такий самий, як у першому прикладі; у цьому вся суть. Проте сам блок task не вдасться розгорнути окремо.

Застосунок Java запускають аналогічно — змінюється виключно драйвер і його конфігурація (jar_path, jvm_options). Драйвер exec2 іде на крок далі: він ізолює процес нативними механізмами ядра (cgroups v2, Landlock), без образу контейнера і без chroot.

Який вигляд це має з іншого боку? У Kubernetes модель контейнерна за визначенням. Віртуальна машина потребує проєкту KubeVirt, тобто VM, запакованої в pod, — додаткового шару й додаткової системи для утримання. Гола бінарка на практиці завжди потрапляє в образ (хоча б FROM scratch), що вимагає реєстру та конвеєра збірки для кожного застосунку, зокрема й такого, що є одним файлом. У Swarm завдання — це контейнер Docker і команда; список закінчується в цьому місці.

Одне застереження, без якого це була б реклама: драйвер virt, що запускає повні віртуальні машини через libvirt, позначений самим виробником як такий, що перебуває в активній розробці й не призначений для продакшну.

Який вигляд мають нічне завдання та агент на кожному вузлі?

Два наступні типи показують, як багато вміщується в одному полі type.

Періодичне завдання — копія бази, що запускається щоночі:

job "nightly-db-dump" {
  # periodic працює ВИКЛЮЧНО для типів "batch" і "sysbatch"
  type = "batch"

  periodic {
    # "crons" - це список виразів; поле "cron" (однина) застаріло від 1.6.2
    crons = ["0 3 * * *"]
    prohibit_overlap = true # не стартуй, доки триває попередній прохід
    time_zone = "Europe/Warsaw" # за замовчуванням UTC
  }
  # ...
}

Дві речі, через які люди втрачають дані: результат такого завдання має вийти за межі каталогу алокації, бо той зникає разом із нею — потрібен том хоста або виштовхування копії в об’єктне сховище. І друга: наявний job не вдасться змінити на періодичний на місці — його треба зупинити з опцією -purge. Про те, чим копія відрізняється від репліки, ми писали ширше у статті Резервне копіювання у хмарі: правило 3-2-1, RPO/RTO і копія, яку не зітре ransomware.

Системне завдання — одна алокація на кожному відповідному вузлі, як DaemonSet у Kubernetes; нові вузли дістають її автоматично після приєднання:

job "node-exporter" {
  type = "system" # у job типу "system" НЕ встановлюють count

  constraint {
    attribute = "${attr.kernel.name}"
    value = "linux"
  }
  # ...
}

Відмінність між версіями, яка може заскочити зненацька на довгостроковій підтримці: розгортання для завдань типу system існують лише від Nomad 1.11.0. У гілці 1.10.x блок update не поводитиметься для них так, як підказує документація новіших релізів.

З яких команд починається робота з Nomad?

Найкоротший шлях до власного експерименту — це nomad agent -dev, одновузловий кластер у пам’яті, що запускається однією командою. Продакшн-кластер — це та сама програма, лише з файлом конфігурації і роллю сервера або клієнта.

# сухий прогін на сервері: різниця щодо поточного стану + результат планування.
# Коди виходу: 0 = нічого не зміниться, 1 = будуть зміни, 255 = помилка
nomad job plan webapp.nomad.hcl

# розгортання
nomad job run webapp.nomad.hcl

# перегляд стану job і перебігу розгортання (при канарках: колонки Promoted / Canaries)
nomad job status webapp
nomad deployment status -monitor <deployment-id>
nomad node status

# нативний реєстр служб - працює при provider = "nomad", не в Consul
nomad service list
nomad alloc checks <alloc-id>

# логи конкретної алокації і всього job
nomad alloc logs -f <alloc-id> server
nomad alloc logs -job webapp -tail -n 50

# промоція канарки і відкат до попередньої версії
nomad job promote webapp
nomad job history -p webapp
nomad job revert webapp 3

Варто знати, що nomad job validate не є офлайн-валідацією — команда надсилає завдання на сервер, тож без доступної адреси кластера вона не спрацює.

Хто реально користується Nomad?

Це питання вимагає обережної відповіді, бо публічні референси Nomad здебільшого старі, а компанія може змінити стек без оголошення. Нижче — виключно впровадження, описані в першоджерелах, кожне з роком публікації, бо жодне з них не варто читати як стан на сьогодні:

Cloudflare (2020) — служби обслуговування та керування перезапусками в кожному крайовому дата-центрі, п’ять серверів Nomad на локацію; вибір мотивований, зокрема, драйверами для звичайних бінарок.
Internet Archive (2021) — понад сто розгортань, перенесених із Kubernetes на Nomad із Consul.
Q2 (2020) — інтернет-банкінг: понад 7000 job-ів, понад 40 000 завдань, 1500 віртуальних машин, переважно у власній серверній.
Lob (2022) — консолідація кількох платформ на Nomad; попередній підхід до Kubernetes команда описує як покинутий.
Behavox (2023) — керування мікросервісами; найсвіжіший публічний опис переходу на Nomad, який вдалося знайти.

Чесність вимагає показати рух у зворотний бік, бо він задокументований так само добре. SeatGeek описав у листопаді 2024 року міграцію з Nomad на Kubernetes — під час перебудови складальних машин у системі CI середній час очікування впав із 16 до 2 секунд. Fly.io 2023 року замінило Nomad власним оркестратором, назвавши три причини: щільне пакування завдань задля мінімізації обладнання там, де платформі був потрібен запас; припущення про федерацію регіонів замість одного глобального кластера; а також брак синхронного масштабування від нуля на вказаному сервері.

Варто також знати контекст упровадження єдиного публічного референсу з підтвердженням молодшим за рік. CircleCI описує в документації від травня 2026 року типову архітектуру самостійно хостованого продукту CircleCI Server: сервери Nomad працюють там як служба всередині клієнтського кластера Kubernetes — а від версії 4.8 виробник дозволяє винести їх на окремі віртуальні машини. Це не дискваліфікує жодного з інструментів; це показує, що у більших організаціях обидва інструменти використовують поруч, для різних завдань.

У чому Nomad реально виграє в Kubernetes?

Вартість входу й утримання самого інструмента. Одна бінарка в ролі сервера або клієнта, вбудований консенсус, відсутність окремої бази стану з власним циклом релізів. Стан кластера все одно треба захищати копіями, але робить це та сама бінарка, а не окрема система — із застереженням, що автоматизація цих копій є функцією Enterprise.
Неконтейнерні навантаження без додавання другої системи. Той самий планувальник, ті самі права доступу і ті самі розгортання для контейнера, процесу, застосунку Java і — із застереженням щодо зрілості — віртуальної машини.
Багаторегіональність є проблемою конфігурації, а не архітектури. Одна точка входу API і один токен для керування багатьма кластерами, реплікація політик і просторів імен з авторитативного регіону. Із застереженнями з попередніх розділів: стан не реплікується між регіонами, а блок multiregion є функцією Enterprise.
Шаблонізація є в самій мові, а не в надбудові над нею. HCL2 має змінні, вирази, функції і цикли. YAML їх не має — він не є мовою, лише форматом запису даних — звідси вся надбудова: Helm, Kustomize, jsonnet. Helm шаблонізує YAML як текст, тож помилка відступу виявляється аж після рендерингу. Застереження: HCL2 розгортається на боці CLI оператора, а сервер отримує вже готову структуру — це не механізм секретів часу виконання (для цього служить блок template).
Менше понять перед першим продакшн-розгортанням — кільканадцять, і всі вміщуються в одному файлі й одному CLI.
Одне місце, в якому видно розгортання. Це звучить дрібно, доки не доводиться комусь пояснювати, чому розгортання зупинилося.

Чого натомість ми не напишемо, хоч воно й ходить мережею: що Nomad швидший за Kubernetes. Не існує жодного незалежного тесту, який порівнював би ці інструменти. Славнозвісний результат «два мільйони контейнерів» походить із бенчмарку виробника 2020 року, у якому запускали контейнери alpine з командою sleep, із резервуванням 30 МБ пам’яті, без конфігурації мережі та з вимкненими розгортаннями. Він вимірює пропускну здатність планувальника, а не життєздатність кластера під продакшн-трафіком. Ми також не знайшли жодного достовірного вимірювання споживання пам’яті агентом Nomad у першоджерелі — усі числа, що ходять мережею, неможливо перевірити, тож ми їх не наводимо.

У чому Kubernetes реально виграє в Nomad?

Чесне порівняння мусить мати цей розділ так само сильним, як попередній.

Ліцензія і врядування. Apache 2.0, фундація CNCF, нейтральність щодо постачальників. Nomad має ліцензію, яка відкриває код, але не дає свободи open source, — а ліцензіаром є IBM.
Речі, за які в Nomad платять, у Kubernetes є в ядрі безкоштовно. За платною версією Nomad Enterprise стоять, зокрема: журналювання подій аудиту, ліміти ресурсів, політики (Sentinel), автоматичні оновлення та резервні копії, зони надлишковості, а також багаторегіональні розгортання. Це найчастіше пропущена вартість такого порівняння.
Екосистема. Патерн «оператор + власний тип ресурсу» дозволяє розширювати модель даних кластера і обслуговувати її тими самими інструментами. Nomad відповідника не має. Каталог Artifact Hub налічує понад 21,5 тис. пакетів усіх видів — не лише чартів Helm, а й операторів чи плагінів — а Nomad Pack, відповідник Helm, ніколи не досяг версії 1.0 (найновіша — 0.4.2).
Безпека і мультитенантність у ядрі. Мережеві політики для мікросегментації, контроль доступу на основі ролей для довільного типу ресурсу, контроль допуску об’єктів. Відповідником мережевих політик на боці Nomad є інтенції Consul — тобто окремий продукт на тій самій ліцензії.
Зрілий шар стану. StatefulSet і оператори для баз даних, черг і кешів у режимі високої доступності. До того ж: деякі драйвери CSI, написані під Kubernetes, у Nomad не запрацюють, бо вони використовують виклики, специфічні для цієї платформи.
Автомасштабування в ядрі. Горизонтальне автомасштабування є частиною керуючого шару. Nomad Autoscaler — це окремий демон і окрема бінарка, а найбільш просунута його частина, автоматичний добір розміру застосунку, є виключно у версії Enterprise.
Керовані послуги і ринок компетенцій. Керований Kubernetes пропонують усі три гіперскейлери, а програма відповідності CNCF охоплює понад 90 сертифікованих пропозицій; повний комплект п’яти kubernetes-сертифікатів CNCF (звання Kubestronaut) має понад 3500 осіб у понад 100 країнах. Керованого Nomad у гіперскейлерів немає, а Nomad не з’явився навіть в анкеті опитування Stack Overflow 2025 — що не означає «нульове використання», але дещо каже про масштаб.

Чи Nomad — безпечний вибір на п’ять років? Ліцензія, власник і кінець LTS

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

Ліцензія. У серпні 2023 року HashiCorp перейшов із MPL 2.0 на Business Source License 1.1. Nomad є у списку охоплених продуктів, а BUSL не є ліцензією, яку OSI визнає за open source. Файл ліцензії в поточній гілці вказує ліцензіаром International Business Machines Corporation, дату зміни ліцензії встановлює через чотири роки від публікації даної версії, а цільовою ліцензією є MPL 2.0.

Що це означає на практиці? Наведене нижче є прочитанням тексту ліцензії, а не юридичною порадою — а обов’язкове тлумачення обсягу додаткового дозволу встановлює ліцензіар. Із читання випливає, що хостинг і використання охопленого програмного забезпечення для внутрішніх потреб організації не трактується як конкурентна пропозиція, а обмеження цілиться в платне пропонування Nomad третім особам у спосіб, конкурентний щодо платної версії виробника, — тобто у сценарії на кшталт «керований Nomad як послуга» чи платної підтримки, яку продають довкола самого Nomad. Де саме проходить ця межа у вашій бізнес-моделі, вирішить юрист, а не стаття.

Одна пастка, на яку легко натрапити: не вдасться «залишитися на останній версії MPL», обравши гілку 1.6.x. Останнім релізом беззаперечно на MPL 2.0 є 1.6.3 від 30 жовтня 2023 року — уже від 1.6.4 файли ліцензії в репозиторії вказують BUSL.

Без форку під нейтральною фундацією. Terraform дочекався OpenTofu, Vault дочекався OpenBao. Nomad відповідника не має. Якщо умови зміняться, альтернативою буде не форк, а міграція на інший оркестратор — а це вже зовсім інший рахунок.

Один власник, після поглинання. Поглинання HashiCorp компанією IBM завершилося 27 лютого 2025 року. Змінилося, зокрема, те, що ліцензіаром сьогодні є IBM, версіонування перейшло на корпоративну модель, а ліцензії Enterprise продаються каналом IBM. Жодної заяви про майбутнє ліцензії Nomad немає — ані про посилення, ані про повернення до відкритої моделі. Це відсутність інформації, і саме так її треба трактувати.

Цикл підтримки — найтвердіший аргумент при багаторічному плануванні. Від версії 2.0 Nomad відмовився від семантичного версіонування. Найновіший реліз — це 2.0.5 від 13 серпня 2026 року. І річ ключова: гілка 1.10.x є останньою з міткою довгострокової підтримки і завершує її 30 квітня 2027 року. Релізи Community Edition від 2.0.0 мають дворічну політику виправлень, а довші вікна — продовжена підтримка і продовжена безперервна — це платні пакети для клієнтів Enterprise.

Як обрати? Емпіричне правило

До приблизно десяти вузлів, одна команда, один застосунок, передбачуваний трафік, відсутність окремої ставки на платформу → Docker Swarm — це не сором. Він дешевший у кожному вимірі, а кластер, якого ніхто не утримує, зіпсується швидше, ніж Swarm устигне постаріти.
Від кільканадцяти до приблизно тисячі вузлів, змішані навантаження — контейнери, бінарки, застосунки Java — і невелика платформна команда → Nomad дає тут найбільше можливостей за найменшої кількості шарів для утримання: один процес для оновлення замість ланцюга компонентів. Умова: свідома згода на ліцензію BUSL і на те, що за нетипової інтеграції ви частіше натрапите на «напиши це сам», ніж на готовий оператор.
Понад приблизно тисячу вузлів, багато ізольованих команд або клієнтів в одному кластері, регуляторні вимоги, потреба в екосистемі й готових операторах, плани найму → Kubernetes. Зі ставкою на утримання платформи, а не з часткою ставки.

І питання, яке варто поставити перед кожною з цих трьох відповідей: чи вашим навантаженням узагалі потрібна оркестрація? Застосунок, який роками спокійно стоїть на одній віртуальній машині, після перенесення в оркестратор отримує передусім новий набір речей, які можуть зламатися. Про те, як розподіляється відповідальність між моделями хмарних послуг, ми пишемо у статті Хмара як послуга: IaaS, PaaS і SaaS на прикладах, а про те, куди в хмарі втікає бюджет, — у статті Публічна хмара за розумною ціною.

Який оркестратор ви запустите у хмарі WebDisk?

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

Керований кластер Kubernetes (WebDisk K8s) — послуга, доступна користувачам WebDisk Cloud; кластер ви замовляєте з рівня панелі, а платформа, побудована на Apache CloudStack, створює його за вас — із публічною адресацією IPv4 та IPv6 і масштабуванням кількості вузлів. Деталі конфігурації мережі та обсяг автоматичного масштабування ми узгоджуємо при замовленні. Для команд, які хочуть повного контролю, залишається шлях власного кластера на інфраструктурі IaaS: із провайдером CloudStack для Terraform або з Cluster API в повному режимі «інфраструктура як код».

Nomad, Swarm або будь-що інше на власних машинах. Якщо після прочитання цієї статті ви вирішите, що вашій команді ближче до Nomad, ніщо не заважає: ви орендуєте віртуальні машини й мережу в публічній хмарі WebDisk, а оркестратор встановлюєте й утримуєте на своєму боці — у версії Community без оплат, а можливу ліцензію Enterprise розраховуєте безпосередньо з її виробником. Ми не пропонуємо керованого Nomad і не збираємося цього обіцяти; керованою послугою в нас є Kubernetes, а при переході із середовищ Docker Swarm наша команда допомагає консультаціями і планом міграції.

Незалежно від вибору залишається той самий, нудний перелік обов’язків власника кластера: оновлення, резервні копії стану й даних застосунків, моніторинг і хтось, хто прийме сигнал тривоги. Як ми складаємо шари захисту під усім цим, ми описуємо у статті Скільки шарів має безпека ваших файлів.

Часті запитання

Чи може Nomad замінити Kubernetes у вашій організації? Може — якщо вам потрібен передусім планувальник завдань, ви маєте змішані навантаження і невелику платформну команду. Не замінить його там, де важать екосистема операторів, зріла підтримка застосунків зі станом, мікросегментація мережі в ядрі або доступність керованої послуги в постачальника хмари. Питання звучить не «який інструмент кращий», а «скільки платформи вам справді потрібно і хто її утримуватиме».

Що саме закінчується 30 квітня 2027 року? Підтримка гілки Nomad 1.10.x — останньої, позначеної як довгострокова (LTS). Після цієї дати виправлення, зокрема виправлення безпеки, до цієї лінії вже не потрапляють; треба перейти на новішу гілку або викупити продовжену підтримку у версії Enterprise. Новіші релізи Community Edition мають дворічну політику виправлень, але жоден уже не має мітки LTS.

Чи Docker Swarm ще розвивають? Режим Swarm, вбудований у рушій Docker, — так: репозиторій moby/swarmkit живий, а релізи 2026 року містять виправлення, що стосуються Swarm. Docker не оголосив дати кінця підтримки, але й не декларує розвитку — пише, що той уповільнився на користь рішень на базі Kubernetes. Закритим натомість є Swarm «classic», окремий продукт 2014 року, заархівований 2021-го.

Чи потребує Nomad Consul і Vault? Ні — нативного виявлення служб достатньо для старту, хоча воно й не дає DNS. З Consul Nomad робить істотно більше (доменні імена, сервісна сітка, мережеві інтенції), а Nomad Variables не є замінником Vault: головний ключ шифрування лежить на серверах, а сам механізм передбачено для невеликих фрагментів конфігурації.

З чого почати, щоб кластер Nomad не був відкритим? З увімкнення списків контролю доступу — вони вимкнені за замовчуванням, а ініціює їх nomad acl bootstrap. Це перша річ, яку треба зробити після підняття серверів, перед виставленням чого-небудь у мережу. Сам продакшн-кластер — це три або п’ять серверів на регіон.

Чи запустить Nomad застосунок, якого немає в образі контейнера? Так — це його вирізняльна риса. Драйвер exec запускає звичайну бінарку в ізоляції, java — JAR-архів без збирання образу, а exec2 ізолює процес нативними механізмами ядра. Драйвер virt для повних віртуальних машин існує, але виробник позначає його як не призначений для продакшну.

Підсумок

Вибір між Swarm, Nomad і Kubernetes — це, по суті, відповідь на одне питання: скільки платформи ви хочете утримувати. Swarm дає найменше і найменше коштує; Kubernetes дає найбільше і найбільше вимагає, пропонуючи натомість нейтральну ліцензію, екосистему і ринок компетенцій; Nomad стоїть посередині — один файл, одна бінарка, навантаження також неконтейнерні — ціною ліцензії, яка не є відкритою, і довгострокової гілки, що завершується у квітні 2027 року.

Жодна з цих відповідей не є універсально кращою; поганим є лише рішення, ухвалене без підрахунку вартості утримання. Напишіть нам — ми допоможемо порівняти варіанти під кутом вартості утримання і спланувати міграцію, а для кластерів Kubernetes також переглянути, як вони утримуються.

HashiCorp Nomad, Kubernetes і Docker Swarm: який оркестратор обрати та скільки коштує його утримання