Nomad vs Kubernetes vs Docker Swarm: co wybrać?

Blog WebDisk · kategoria: Chmura publiczna · czas czytania: ~22 minuty

W skrócie:- To nie są trzy wersje tego samego narzędzia. Swarm jest funkcją silnika Dockera, którą już masz; Kubernetes chce być platformą i oddaje Ci do wyboru — oraz do utrzymania — sieć, magazyn i ruch wejściowy; Nomad ogranicza się do jednej roli: planisty zadań.- Największa przewaga Nomada nad Kubernetesem nie dotyczy kontenerów. To jedna binarka, jeden plik opisu wdrożenia i sterowniki, które uruchamiają też zwykłe procesy i aplikacje Javy — bez pakowania każdej z nich w obraz.- Wybieraj po koszcie utrzymania, nie po liście funkcji: do dziesięciu węzłów — Swarm; obciążenia mieszane i mały zespół platformowy — Nomad; duża skala i wymagania regulacyjne — Kubernetes. Cena Nomada: licencja BUSL 1.1 (licencjodawcą jest IBM) i koniec gałęzi ze wsparciem długoterminowym (LTS) 30 kwietnia 2027. >Nie pracujesz z terminalem? Pomiń bloki kodu — opis różnic, sekcja „Jak wybrać?” i część o ryzykach dają pełny obraz bez ani jednego polecenia.

Rozmowa o orkiestracji kontenerów zaczyna się dziś zwykle od zdania „no to bierzemy Kubernetesa”, a kończy pół roku później pytaniem, kto właściwie ma go utrzymywać. Między tymi dwoma momentami mieści się cała klasa decyzji, które łatwiej podjąć na początku niż odkręcić później: ile warstw naprawdę potrzebujesz, ile z nich ktoś w firmie będzie umiał naprawić o trzeciej w nocy i co się stanie, gdy autor narzędzia zmieni licencję.

Orkiestrator to program, który pilnuje, żeby zadeklarowana liczba kopii aplikacji działała na dostępnych serwerach: sam wybiera maszynę, przenosi zadanie po awarii węzła, wymienia wersję bez przerwy w działaniu i rejestruje, gdzie właśnie działa dana usługa. W praktyce wybór sprowadza się dziś do trzech narzędzi: Docker Swarm, HashiCorp Nomad i Kubernetes — z zastrzeżeniem, że tylko ostatni jest w ogóle mierzony w największych badaniach branżowych.

Ten artykuł pokazuje, czym różnią się nie funkcjami z tabelki, lecz filozofią — a potem schodzi na konkret: jak wygląda plik wdrożenia w Nomadzie, jak wydać nową wersję metodą kanarkową (jedna instancja nowej wersji obok starej, do sprawdzenia „na żywo”), jak uruchomić aplikację, której nie ma w żadnym obrazie, i gdzie Nomad realnie wygrywa z Kubernetesem, a gdzie równie realnie przegrywa. Piszemy ten tekst dla zespołów stojących przed wyborem po raz pierwszy i dla tych, które Kubernetesa już mają — a zaczynają podejrzewać, że do ich skali był to wybór o rozmiar za duży. Wszystkie liczby i daty pochodzą ze źródeł pierwotnych i są aktualne na koniec sierpnia 2026; tam, gdzie liczba pochodzi z materiału producenta, a nie z pomiaru, mówimy o tym wprost.

Czym Nomad, Kubernetes i Docker Swarm różnią się naprawdę?

Najczęstszy błąd w porównaniach polega na zestawianiu list funkcji. Różnica zaczyna się wcześniej — w tym, jak szeroko każde z narzędzi definiuje własną odpowiedzialność.

Kubernetes chce być platformą. Ma API na sieć, magazyn, polityki, ruch wejściowy i uprawnienia. Ale „wbudowane” znaczy tu zwykle „wbudowany interfejs plus zewnętrzna implementacja, którą sam wybierzesz i będziesz utrzymywać”. Sieci Kubernetes nie dostarcza — definiuje model, a realizują go wtyczki CNI (standard podłączania kontenerów do sieci). Magazyn to CSI (standard podłączania dysków). Ruch przychodzący to Ingress — interfejs zamrożony funkcjonalnie, którego następcą jest Gateway API. Jak dotkliwy potrafi być taki układ, pokazał rok 2026: ingress-nginx, najpopularniejszy kontroler ruchu wejściowego, został wycofany przez zespół sieciowy projektu wraz z łatkami bezpieczeństwa. Komponent, na którym stał ruch produkcyjny tysięcy firm, zmienił się pod nimi.

Nomad chce być tylko planistą — i mówi to wprost we własnej dokumentacji: Kubernetes celuje w komplet funkcji potrzebnych do uruchamiania aplikacji kontenerowych, Nomad skupia się na zarządzaniu klastrem i szeregowaniu zadań. Reszta jest delegowana: pełna warstwa usług do Consula, sekrety do Vaulta lub OpenBao (to osobne produkty tego samego producenta), sieć poza trybem hosta i mostka do CNI, magazyn do CSI, autoskalowanie do osobnego demona. To nie jest brak — to decyzja projektowa, która ma swoją cenę i swoją nagrodę.

Docker Swarm implementuje wszystko sam, ale zakres jest wąski. Bez instalowania czegokolwiek dodatkowego dostajesz zarządzanie klastrem z poziomu zwykłego CLI Dockera, deklaratywny opis usługi, skalowanie, sieć nakładkową (wirtualną sieć rozpiętą ponad realną siecią serwerów), wykrywanie usług przez DNS z równoważeniem ruchu, aktualizacje kroczące i — co warto docenić — wzajemne uwierzytelnianie TLS między węzłami włączone domyślnie, z certyfikatami odnawianymi co trzy miesiące. Nie dostajesz przestrzeni nazw ani kontroli dostępu opartej na rolach w samym silniku, autoskalowania ani dojrzałej obsługi magazynu.

Gdzie przebiega granica „jednej aplikacji” w każdym z tych narzędzi?

To rozróżnienie decyduje o tym, jak będziesz opisywać wdrożenia przez kolejne lata.

Docker Swarm — nie ma warstwy współlokowania (zadanie to jeden kontener); jednostką skalowania jest usługa (service); całość opisuje jeden plik Compose z N usług.
Nomad — współlokowanie i skalowanie to ta sama rzecz: grupa (group); całą aplikację opisuje jeden plik opisu zadania.
Kubernetes — współlokowanie to pod, skalowanie to Deployment (przez ReplicaSet); jedna aplikacja to zwykle 4–8 obiektów, często w kilku plikach.

Wynikają z tego trzy rzeczy, o których warto wiedzieć przed wyborem:

Swarm nie ma warstwy współlokowania. Kontener pomocniczy — pośrednik sieciowy, agent zbierający logi, eksporter metryk — jest w Swarmie osobną usługą, więc traci gwarancję wspólnej przestrzeni sieciowej i wspólnego wolumenu z aplikacją. To blokuje całą klasę architektur, a nie tylko psuje wygodę.
W Nomadzie grupa jest deklarowana wprost, w Kubernetesie pod powstaje przy okazji. W Kubernetesie opisujesz szablon w obiekcie Deployment i dostajesz pody, których sam nie tworzysz i których nie da się przenieść — można je tylko utworzyć na nowo. W Nomadzie piszesz grupę i wiesz, że to ona jest jednocześnie jednostką współlokowania i skalowania.
To, co w Kubernetesie jest osobnymi rodzajami obiektów, w Nomadzie jest jednym polem. type = "service" odpowiada Deploymentowi, type = "batch" — obiektowi Job, type = "system" — DaemonSetowi, a type = "sysbatch" — zadaniu jednorazowemu uruchamianemu raz na każdym pasującym węźle, na co w Kubernetesie nie ma wprost odpowiednika. Jeden plik, jedno pole, cztery zachowania.

Jest jeszcze różnica, którą dokumentacja Kubernetesa formułuje sama: Kubernetes nie jest orkiestratorem w sensie „zrób A, potem B”, lecz zbiorem niezależnych pętli sterowania dociągających stan bieżący do pożądanego. Konsekwencja jest bardzo praktyczna — nie ma jednego miejsca, w którym widać przebieg wdrożenia. W Nomadzie jest: nomad deployment status.

Czy Docker Swarm jest martwy? Nie ten, o którym myślisz

W sieci powtarza się zdanie „Swarm jest martwy”. Jest ono jednocześnie prawdziwe i fałszywe, bo dotyczy dwóch różnych bytów.

Docker Swarm „classic” — osobny produkt z 2014 roku, spinający wiele demonów Dockera — jest faktycznie zamknięty: repozytorium zarchiwizowano 1 lutego 2021, obraz na Docker Hubie ma etykietę „deprecated”, a obsługę usunięto z silnika w wersji 23.0. To o nim mówi większość krążących „ogłoszeń o wycofaniu”.

Swarm mode, czyli tryb wbudowany w Docker Engine od wersji 1.12, nie ma ogłoszonej daty końca wsparcia. Kod jest utrzymywany: repozytorium moby/swarmkit nie zostało zarchiwizowane, a commity na głównej gałęzi pochodzą z końca sierpnia 2026. Linia Docker Engine 29 przyniosła Swarmowi konkretne poprawki, w tym naprawę uszkodzeń migawek Raft przy dużym stanie klastra. Uczciwość wymaga jednak podania drugiej połowy: jedyny oficjalny komunikat Dockera na ten temat stoi na stronie „produkty wycofane i wygaszone” i brzmi, że tryb Swarm pozostaje sprawny, ale rozwój zwolnił na rzecz rozwiązań opartych na Kubernetesie.

Praktyczne granice Swarma warto znać, zanim się na niego postawi:

Nie ma autoskalowania. Zgłoszenie z propozycją poziomego skalowania usług leży otwarte w repozytorium od sierpnia 2017 — bez implementacji.
Obsługa magazynu przez CSI jest eksperymentalna: bez migawek, klonowania i rozszerzania wolumenów.
docker stack deploy korzysta ze starego formatu Compose w wersji 3, niezgodnego z aktualną specyfikacją Compose. Część kluczy jest po cichu pomijana — wdrożenie wypisuje ostrzeżenie i idzie dalej. „Działa mi w Compose” i „działa w stacku” to dwa różne zdania o tym samym pliku.
Sekrety są szyfrowane w spoczynku, configs już nie — i lądują wprost w systemie plików kontenera. Limit obu to 500 kB.
Zalecane maksimum to siedem węzłów zarządzających, a klaster N takich węzłów przeżywa utratę (N−1)/2 z nich. Żadnych progów skalowalności Swarm nie publikuje.
Jest też sygnał wart obserwowania przy planowaniu na najbliższe lata: na węźle z włączonym Swarmem nie da się dziś włączyć nftables, a nftables ma zostać domyślnym mechanizmem zapory w Dockerze — producent nie podaje jednak ani wersji, ani daty.

Wsparcie komercyjne oferuje Mirantis. We wpisie z lipca 2025 pada deklaracja obsługi Swarma „co najmniej do 2030 roku” w ramach MKE 3, natomiast opublikowana macierz cyklu życia sięga dziś marca 2028, a MKE 4 jest już produktem wyłącznie kubernetesowym. Te dwa źródła obejmują różne horyzonty, więc przy planowaniu wieloletnim datę końca wsparcia trzeba potwierdzić u dostawcy na piśmie.

Kiedy Swarm ma sens? Gdy masz od kilku do kilkunastu węzłów, jeden zespół, przewidywalny ruch i nikogo, kto miałby etatowo utrzymywać klaster. To ostatnie jest ważniejsze, niż się wydaje: klaster Kubernetes postawiony samodzielnie narzędziem kubeadm i nietykany przez rok po prostu przestanie działać, bo wygasną roczne certyfikaty warstwy zarządzającej — odnawia je dopiero aktualizacja. W usłudze zarządzanej robi to za Ciebie dostawca. Swarm w takich warunkach zestarzeje się wolniej. Zresztą dane samego Mirantisa — opublikowane w 2022 roku i powtórzone w 2024 słowo w słowo, bez ujawnionej metodologii — po przeliczeniu dają średnio około dziesięciu węzłów i stu kontenerów na klaster. Swarm w realnym świecie nie służy do budowania dużych klastrów, tylko wielu małych. To jego uczciwa nisza, nie porażka.

Ile naprawdę kosztuje Kubernetes, zanim wystawisz pierwszą aplikację?

Kubernetes jest dziś domyślnym wyborem i ma po temu twarde powody: licencja Apache 2.0, neutralne zarządzanie w ramach fundacji CNCF, największy ekosystem i usługi zarządzane u każdego dużego dostawcy. Według ankiety CNCF 82% użytkowników kontenerów uruchamia Kubernetesa w produkcji (uwaga na bazę: to odsetek użytkowników kontenerów, nie wszystkich organizacji).

Cena jest jednak policzalna i warto ją zobaczyć w liczbach, a nie w przymiotnikach:

Warstwa zarządzająca to osobne procesy: serwer API, baza etcd, planista, menedżer kontrolerów, a na węźle kubelet i środowisko uruchomieniowe kontenerów. Do tego CNI i CoreDNS, bez których klaster praktycznie nie działa.
Powierzchnia pojęciowa jest duża i policzalna: oficjalna referencja API wymienia 22 grupy API. Żeby wystawić jedną aplikację HTTP na produkcji, trzeba rozumieć pody, Deployment, ReplicaSet, Service, Ingress albo Gateway API, przestrzenie nazw, ConfigMap, Secret, PVC/PV/StorageClass, żądania i limity zasobów, trzy rodzaje sond, konto usługi z rolą i przypisaniem, polityki sieciowe — plus wybrać Helma albo Kustomize, CNI i CSI.
Aktualizacje są obowiązkiem, nie opcją. Wspierane są trzy ostatnie gałęzie (obecnie 1.37 „Garhwal”, wydana 26 sierpnia 2026), a okno wsparcia jednego wydania to około 14 miesięcy. Serwer API nie może przeskoczyć wydania — wersje podnosi się po kolei. Ile to kosztuje, najlepiej widać w cenniku: w Amazon EKS warstwa zarządzająca to 0,10 USD za klaster na godzinę, a przedłużone wsparcie starszej wersji — 0,60 USD, czyli sześciokrotnie więcej wyłącznie za to, że się nie aktualizuje.
Skala jest zmierzona i ogłoszona: do 110 podów na węzeł, do 5000 węzłów, do 150 000 podów. To zresztą przewaga, nie wada — dwa pozostałe narzędzia takich progów nie publikują. Warto tylko czytać je tak, jak są napisane: to granice pomiarowe, a dociśnięcie dwóch wymiarów naraz rozbije klaster znacznie wcześniej.

Częste nieporozumienie: k3s. Ta dystrybucja realnie obniża koszt instalacji i zużycie zasobów, ale nie obniża kosztu pojęciowego ani o jotę — to certyfikowany Kubernetes z tym samym API. Kto sięga po k3s, żeby „Kubernetes był prostszy”, rozwiązuje inny problem, niż ma. Jak wygląda dobre utrzymanie takiego klastra — aktualizacje, kopia bazy etcd, obserwowalność, dyżury — opisaliśmy osobno w artykule Wsparcie techniczne Kubernetes: postawić klaster to najłatwiejszy etap. O tym, jak koszt narzędzia przekłada się na zależność od jego autora, piszemy z kolei w artykule Vendor lock-in w chmurze publicznej.

Co dostajesz, gdy orkiestrator to jedna binarka?

Nomad jest pojedynczym programem napisanym w Go, który w zależności od konfiguracji pracuje jako serwer albo klient. Nie ma zewnętrznej bazy danych — spójność stanu zapewnia wbudowany algorytm konsensusu Raft (mechanizm, w którym serwery uzgadniają jedną wspólną wersję prawdy), więc nie ma tu odpowiednika etcd do backupowania, aktualizowania i strojenia. Produkcyjny region to trzy albo pięć serwerów: trzy przeżywają awarię jednego, pięć — dwóch. Chodzi o kworum, czyli większość, która musi się porozumieć, żeby klaster podejmował decyzje. Liczby klientów producent nie ogranicza żadnym publikowanym progiem.

Skalę zwiększa się przez dokładanie regionów, nie przez pogrubianie kworum. Regiony są w pełni niezależne — nie dzielą zadań, klientów ani stanu — a łączy je lekki protokół wymiany informacji między serwerami (gossip), dzięki czemu wywołanie API z parametrem regionu trafia do właściwego regionu samo. Z regionu autorytatywnego replikują się polityki dostępu, role, przestrzenie nazw, pule węzłów i limity. Dla porównania: w Kubernetesie wieloregionowość jest problemem architektury, nie konfiguracji — projekt KubeFed został zarchiwizowany, a grupa zajmująca się wieloma klastrami celowo dostarcza API bez implementacji referencyjnej.

Dwa zastrzeżenia, bez których ten obraz byłby reklamą:

Blok multiregion w opisie zadania wymaga wersji Enterprise i nie zapewnia automatycznego przełączenia awaryjnego między regionami. Federacja regionów to nie to samo co wysoka dostępność między lokalizacjami.
Dokumentacja Nomada mówi wprost: „Nomad is not secure-by-default” — Nomad nie jest domyślnie bezpieczny — a listy kontroli dostępu (ACL) są domyślnie wyłączone. Klaster postawiony „na szybko” i wystawiony bez ich włączenia to nie jest teoretyczne ryzyko.

Trzy słowa, które będą wracać

Zanim spojrzysz na pierwszy plik: trzy pojęcia po polsku chciałoby się nazwać tak samo — „zadaniem” — więc rozdzielmy je od razu.

job — cały opis aplikacji: jeden plik, jedna nazwa, jedna wersja. To jego się wdraża, wycofuje i zatrzymuje.
task — pojedynczy proces albo kontener wewnątrz joba.
alokacja (allocation) — jedna kopia grupy zadań uruchomiona na konkretnym kliencie, odpowiednik poda w Kubernetesie. Skalowanie do trzech instancji to trzy alokacje; awaria węzła to zniknięcie alokacji i utworzenie nowej gdzie indziej. Jeśli w poleceniu widzisz alloc, chodzi właśnie o to.

Nomad opisuje się w HCL (HashiCorp Configuration Language) — tym samym języku konfiguracji co Terraform: bloki zagnieżdżają się w nawiasach klamrowych, wcięcia nic nie znaczą, a sam język ma zmienne, wyrażenia i pętle. Poniżej kompletny plik: dwie instancje aplikacji webowej, limity zasobów, dynamiczny port, rejestracja usługi i kontrola stanu zdrowia.

job "webapp" {
  # type domyślnie = "service"; podajemy jawnie dla czytelności
  type = "service"
  datacenters = ["dc1"]

  group "web" {
    count = 2

    network {
      # port bez "static" = port dynamiczny przydzielony przez Nomada na hoście;
      # "to" mówi, na jaki port trafia ruch WEWNĄTRZ kontenera
      port "http" {
        to = 8080
      }
    }

    service {
      name = "webapp"

      # UWAGA: domyślna wartość to "consul". Bez tej linii Nomad próbuje
      # zarejestrować usługę w Consulu i job nie wystartuje, gdy Consula nie ma.
      provider = "nomad"

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

      check {
        # przy provider = "nomad" dozwolone są WYŁĄCZNIE typy "http" i "tcp".
        # Blok check dziedziczy port z serwisu - nie trzeba go powtarzać.
        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"] # lista ETYKIET portów z bloku network
      }

      resources {
        cpu = 200 # MHz - Nomad rezerwuje takt, nie ułamek rdzenia jak K8s
        memory = 256 # MB
      }
    }
  }
}

Cztery rzeczy, na których potyka się większość początkujących — warto je znać, zanim stracisz na nie wieczór:

provider domyślnie ma wartość "consul". Bez jawnego provider = "nomad" zadanie w klastrze bez Consula nie wystartuje. To najczęstszy błąd startowy.
Przy rejestracji natywnej dozwolone są wyłącznie kontrole http i tcp.
Porty deklaruje się wyłącznie w group -> network i wskazuje przez ports = [...] w konfiguracji zadania. Nomad wstrzykuje do zadania zmienne NOMAD_ADDR_<etykieta>, NOMAD_PORT_<etykieta> i NOMAD_IP_<etykieta>.
Natywny rejestr nie daje DNS-a. Przy provider = "nomad" nie istnieją nazwy w rodzaju webapp.service.consul; adres i port odczytuje się z API, z nomad service info albo z bloku template. Kto wpisze nazwę usługi jako nazwę hosta, dostanie błąd rozwiązywania nazwy i zwykle szuka go w zupełnie innym miejscu. To jedna z rzeczy, które dokłada Consul.

Warto też odkłamać dwa mity krążące w obie strony. „Nomad bez Consula nie działa” jest nieprawdą — natywne wykrywanie usług istnieje od wersji 1.3, a kontrole stanu do niego od 1.4. Ale „Nomad nie potrzebuje CNI” jest uproszczeniem — tryb sieci mostkowej wymaga wtyczek CNI na wszystkich klientach linuksowych.

Jak wydać nową wersję bez przestoju i bez budzenia człowieka?

Cały mechanizm bezpiecznego wydania mieści się w jednym bloku, który dokładasz do grupy:

update {
  max_parallel = 2 # ile alokacji wymienianych JEDNOCZEŚNIE (domyślnie 1)

  # skąd Nomad wie, że alokacja jest zdrowa:
  # "checks" - taski biegną I kontrole usługi są zielone (domyślne)
  # "task_states" - wystarczy, że taski wystartowały
  # "manual" - zdrowie oznacza operator przez API
  health_check = "checks"

  min_healthy_time = "30s" # jak długo ma być zdrowa, żeby uznać ją za dobrą
  healthy_deadline = "3m" # termin dla POJEDYNCZEJ alokacji
  progress_deadline = "10m" # termin POSTĘPU całego wdrożenia; musi być > healthy_deadline

  auto_revert = true # po nieudanym wdrożeniu wróć do ostatniej STABILNEJ wersji
  canary = 1 # ile kanarków postawić OBOK działającej wersji
  auto_promote = false # false = promocja ręcznie: nomad job promote webapp
}

Kanarek to jedna instancja nowej wersji uruchomiona obok starej. Nomad sam nie przełącza ruchu — rejestruje kanarka pod osobnymi etykietami (canary_tags) i czeka na Twoją decyzję; to Twoje proxy decyduje, czy i kiedy zacznie do niego kierować żądania. Do nomad job promote stara wersja pracuje nietknięta. auto_revert sprawia z kolei, że nieudane wydanie wraca samo do ostatniej działającej wersji, bez budzenia człowieka.

Jedna pułapka warta zapamiętania: health_check = "checks" bez zdefiniowanego bloku check oznacza wdrożenie, które nigdy nie potwierdzi zdrowia i padnie dopiero na progress_deadline. To najczęstsza przyczyna „wiszących” wdrożeń.

Czy orkiestrator uruchomi aplikację, której nie ma w obrazie kontenera?

Gdyby wskazać jedną rzecz, która odróżnia Nomada od obu pozostałych narzędzi na zasadzie „da się/nie da się”, byłaby nią architektura sterowników zadań (task drivers). W binarkę wbudowanych jest pięć: docker, exec, raw_exec, java i qemu — przy czym raw_exec uruchamia proces bez jakiejkolwiek izolacji i z tego powodu jest domyślnie wyłączony. Osobno instaluje się trzy kolejne oficjalne: exec2, podman i virt. Sterownik jest wtyczką — własny można napisać bez rekompilacji Nomada.

W praktyce znaczy to, że ten sam planista, te same uprawnienia i ten sam mechanizm wdrożeń obsługują kontener, zwykły proces, archiwum JAR i maszynę wirtualną. Poniżej starsza usługa uruchomiona jako goły proces — bez Dockera na hoście i bez budowania obrazu:

# FRAGMENT: blok task stoi zawsze wewnątrz job -> group -> task.
# Szkielet joba jest identyczny jak w przykładzie wyżej - zmienia się
# WYŁĄCZNIE driver i config (port "http" pochodzi z bloku network grupy).
task "api" {
  # izolowany fork/exec: chroot (proces widzi tylko wydzielony fragment
  # systemu plików) + przestrzenie nazw, ZERO Dockera na hoście
  driver = "exec"

  artifact {
    source = "https://przyklad.example/pobierz/moja-aplikacja-1.4.2"

    options {
      # checksum mieszka WEWNĄTRZ options. Zawsze weryfikuj - artifact pobiera po sieci.
      checksum = "sha256:0f5e...podmien-na-prawdziwa"
    }
  }

  config {
    command = "local/moja-aplikacja-1.4.2" # domyślny cel artifact to katalog local/
    args = ["--listen", "${NOMAD_ADDR_http}"]
  }

  resources {
    cpu = 300
    memory = 256
  }
}

Reszta pliku — job, group, network z portem dynamicznym i service z kontrolą stanu — wygląda dokładnie tak samo jak w pierwszym przykładzie; w tym jest cała pointa. Samego bloku task nie da się jednak wdrożyć osobno.

Aplikację Javy uruchamia się analogicznie — zmienia się wyłącznie sterownik i jego konfiguracja (jar_path, jvm_options). Sterownik exec2 idzie o krok dalej: izoluje proces natywnymi mechanizmami jądra (cgroups v2, Landlock), bez obrazu kontenera i bez chroota.

Jak wygląda to samo po drugiej stronie? W Kubernetesie model jest kontenerowy z definicji. Maszyna wirtualna wymaga projektu KubeVirt, czyli VM zapakowanej w poda — dodatkowej warstwy i dodatkowego systemu do utrzymania. Goła binarka w praktyce zawsze trafia do obrazu (choćby FROM scratch), co wymusza rejestr i potok budowania dla każdej aplikacji, także takiej, która jest jednym plikiem. W Swarmie zadanie to kontener Dockera i polecenie — lista kończy się w tym miejscu.

Jedno zastrzeżenie, bez którego byłaby to reklama: sterownik virt, uruchamiający pełne maszyny wirtualne przez libvirt, jest przez samego producenta oznaczony jako będący w aktywnym rozwoju i nieprzeznaczony na produkcję.

Jak wygląda zadanie nocne i agent na każdym węźle?

Dwa kolejne typy pokazują, jak dużo mieści się w jednym polu type.

Zadanie cykliczne — kopia bazy uruchamiana co noc:

job "nightly-db-dump" {
  # periodic działa WYŁĄCZNIE dla typów "batch" i "sysbatch"
  type = "batch"

  periodic {
    # "crons" to lista wyrażeń; pole "cron" (liczba pojedyncza) jest przestarzałe od 1.6.2
    crons = ["0 3 * * *"]
    prohibit_overlap = true # nie startuj, dopóki poprzedni przebieg trwa
    time_zone = "Europe/Warsaw" # domyślnie UTC
  }
  # ...
}

Dwie rzeczy, przez które ludzie tracą dane: wynik takiego zadania musi wyjść poza katalog alokacji, bo ten znika razem z nią — potrzebny jest wolumen hosta albo wypchnięcie kopii do magazynu obiektowego. I druga: istniejącego joba nie da się zmienić w cykliczny w miejscu — trzeba go zatrzymać z opcją -purge. O tym, czym kopia różni się od repliki, pisaliśmy szerzej w artykule Backup w chmurze: reguła 3-2-1, RPO/RTO i kopia, której nie skasuje ransomware.

Zadanie systemowe — jedna alokacja na każdym pasującym węźle, jak DaemonSet w Kubernetesie; nowe węzły dostają ją automatycznie po dołączeniu:

job "node-exporter" {
  type = "system" # w jobie "system" NIE ustawia się count

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

Różnica między wersjami, która potrafi zaskoczyć na wsparciu długoterminowym: wdrożenia dla zadań typu system istnieją dopiero od Nomada 1.11.0. Na gałęzi 1.10.x blok update nie zachowa się dla nich tak, jak sugeruje dokumentacja nowszych wydań.

Od jakich poleceń zaczyna się praca z Nomadem?

Najkrótsza droga do własnego eksperymentu to nomad agent -dev — jednowęzłowy klaster w pamięci, uruchamiany jednym poleceniem. Produkcyjny klaster to ten sam program, tylko z plikiem konfiguracyjnym i rolą serwera albo klienta.

# suchy przebieg u serwera: różnica wobec stanu bieżącego + wynik szeregowania.
# Kody wyjścia: 0 = nic się nie zmieni, 1 = będą zmiany, 255 = błąd
nomad job plan webapp.nomad.hcl

# wdrożenie
nomad job run webapp.nomad.hcl

# podgląd stanu joba i przebiegu wdrożenia (przy kanarkach: kolumny Promoted / Canaries)
nomad job status webapp
nomad deployment status -monitor <deployment-id>
nomad node status

# natywny rejestr usług - działa przy provider = "nomad", nie w Consulu
nomad service list
nomad alloc checks <alloc-id>

# logi konkretnej alokacji i całego joba
nomad alloc logs -f <alloc-id> server
nomad alloc logs -job webapp -tail -n 50

# promocja kanarka i wycofanie do wcześniejszej wersji
nomad job promote webapp
nomad job history -p webapp
nomad job revert webapp 3

Warto wiedzieć, że nomad job validate nie jest walidacją offline — polecenie wysyła zadanie do serwera, więc bez osiągalnego adresu klastra nie zadziała.

Kto realnie używa Nomada?

To pytanie wymaga ostrożnej odpowiedzi, bo publiczne referencje Nomada są w większości stare, a firma potrafi zmienić stack bez ogłoszenia. Poniżej wyłącznie wdrożenia opisane w źródłach pierwotnych — każde z rokiem publikacji, bo żadnego z nich nie należy czytać jako stanu na dziś:

Cloudflare (2020) — usługi konserwacyjne i zarządzanie restartami w każdym brzegowym centrum danych, pięć serwerów Nomada na lokalizację; wybór motywowany m.in. sterownikami do zwykłych binarek.
Internet Archive (2021) — ponad sto wdrożeń przeniesionych z Kubernetesa na Nomada z Consulem.
Q2 (2020) — bankowość internetowa: ponad 7000 jobów, ponad 40 000 zadań, 1500 maszyn wirtualnych, głównie we własnej serwerowni.
Lob (2022) — konsolidacja kilku platform na Nomadzie; wcześniejsze podejście do Kubernetesa zespół opisuje jako zarzucone.
Behavox (2023) — zarządzanie mikroserwisami; najświeższy publiczny opis przejścia na Nomada, jaki udało się znaleźć.

Uczciwość wymaga pokazania ruchu w drugą stronę, bo jest równie dobrze udokumentowany. SeatGeek opisał w listopadzie 2024 migrację z Nomada na Kubernetesa — przy przebudowie maszyn budujących w systemie CI średni czas oczekiwania spadł z 16 do 2 sekund. Fly.io w 2023 zastąpiło Nomada własnym orkiestratorem, podając trzy powody: upakowanie zadań pod minimalizację sprzętu tam, gdzie platforma potrzebowała zapasu; założenie o federacji regionów zamiast jednego globalnego klastra; oraz brak synchronicznego skalowania od zera na wskazanym serwerze.

Warto też znać kontekst wdrożeniowy jedynej publicznej referencji z potwierdzeniem młodszym niż rok. CircleCI opisuje w dokumentacji z maja 2026 domyślną architekturę samodzielnie hostowanego produktu CircleCI Server: serwery Nomada działają tam jako usługa wewnątrz klastra Kubernetes klienta — a od wersji 4.8 producent pozwala wynieść je na osobne maszyny wirtualne. To nie dyskwalifikuje żadnego z narzędzi; pokazuje, że w większych organizacjach oba bywają używane obok siebie, do różnych zadań.

W czym Nomad realnie wygrywa z Kubernetesem?

Koszt wejścia i utrzymania samego narzędzia. Jedna binarka w roli serwera lub klienta, wbudowany konsensus, brak osobnej bazy stanu z własnym cyklem wydań. Stan klastra i tak trzeba zabezpieczać kopiami, ale robi to ta sama binarka, a nie osobny system — z zastrzeżeniem, że automatyzacja tych kopii jest funkcją Enterprise.
Obciążenia niekontenerowe bez dokładania drugiego systemu. Ten sam planista, te same uprawnienia i te same wdrożenia dla kontenera, procesu, aplikacji Javy i — z zastrzeżeniem dojrzałości — maszyny wirtualnej.
Wieloregionowość jest problemem konfiguracji, nie architektury. Jeden punkt wejścia API i jeden token do zarządzania wieloma klastrami, replikacja polityk i przestrzeni nazw z regionu autorytatywnego. Z zastrzeżeniami sprzed kilku sekcji: stan nie replikuje się między regionami, a blok multiregion jest funkcją Enterprise.
Szablonowanie jest w samym języku, nie w nakładce nad nim. HCL2 ma zmienne, wyrażenia, funkcje i pętle. YAML ich nie ma — nie jest językiem, tylko formatem zapisu danych — stąd cała nadbudowa: Helm, Kustomize, jsonnet. Helm szablonuje YAML jako tekst, więc błąd wcięcia wychodzi dopiero po wyrenderowaniu. Zastrzeżenie: HCL2 rozwija się po stronie CLI operatora, a serwer dostaje już gotową strukturę — to nie jest mechanizm sekretów czasu wykonania (do tego służy blok template).
Mniej pojęć przed pierwszym produkcyjnym wdrożeniem — kilkanaście, i wszystkie mieszczą się w jednym pliku i jednym CLI.
Jedno miejsce, w którym widać wdrożenie. To brzmi błaho, dopóki nie trzeba komuś wytłumaczyć, dlaczego wdrożenie stanęło.

Czego natomiast nie napiszemy, choć krąży po sieci: że Nomad jest szybszy od Kubernetesa. Nie istnieje żaden niezależny test porównujący te narzędzia. Słynny wynik „dwa miliony kontenerów” pochodzi z benchmarku producenta z 2020 roku, w którym uruchamiano kontenery alpine z poleceniem sleep, z rezerwacją 30 MB pamięci, bez konfiguracji sieci i z wyłączonymi wdrożeniami. Mierzy on przepustowość planisty, a nie żywotność klastra pod ruchem produkcyjnym. Nie znaleźliśmy też żadnego wiarygodnego pomiaru zużycia pamięci przez agenta Nomada w źródle pierwotnym — wszystkie krążące liczby są nie do zweryfikowania, więc ich nie podajemy.

W czym Kubernetes realnie wygrywa z Nomadem?

Uczciwe porównanie musi mieć tę sekcję równie mocną co poprzednią.

Licencja i zarządzanie. Apache 2.0, fundacja CNCF, neutralność wobec dostawców. Nomad jest na licencji, która udostępnia kod, ale nie daje swobody open source — a licencjodawcą jest IBM.
Rzeczy, za które w Nomadzie się płaci, w Kubernetesie są w rdzeniu za darmo. Za płatną wersją Nomad Enterprise są między innymi: rejestrowanie zdarzeń audytowych, limity zasobów, polityki (Sentinel), automatyczne aktualizacje i kopie zapasowe, strefy nadmiarowości oraz wdrożenia wieloregionowe. To najczęściej pomijany koszt takiego porównania.
Ekosystem. Wzorzec „operator + własny typ zasobu” pozwala rozszerzać model danych klastra i obsługiwać go tymi samymi narzędziami. Nomad nie ma odpowiednika. Katalog Artifact Hub liczy ponad 21,5 tys. pakietów wszystkich rodzajów — nie tylko wykresów Helma, ale i operatorów czy wtyczek — a Nomad Pack, odpowiednik Helma, nigdy nie osiągnął wersji 1.0 (najnowsza to 0.4.2).
Bezpieczeństwo i wielodostępność w rdzeniu. Polityki sieciowe do mikrosegmentacji, kontrola dostępu oparta na rolach dla dowolnego typu zasobu, kontrola dopuszczenia obiektów. Odpowiednikiem polityk sieciowych po stronie Nomada są intencje Consula — czyli osobny produkt na tej samej licencji.
Dojrzała warstwa stanu. StatefulSet i operatory do baz danych, kolejek i pamięci podręcznych w układzie wysokiej dostępności. Dodatkowo: niektóre sterowniki CSI napisane pod Kubernetesa w Nomadzie nie zadziałają, bo używają wywołań specyficznych dla tej platformy.
Autoskalowanie w rdzeniu. Poziome autoskalowanie jest częścią warstwy zarządzającej. Nomad Autoscaler to osobny demon i osobna binarka, a jego najbardziej zaawansowana część — automatyczny dobór rozmiaru aplikacji — jest wyłącznie w wersji Enterprise.
Usługi zarządzane i rynek kompetencji. Zarządzanego Kubernetesa oferują wszyscy trzej hiperskalerzy, a program zgodności CNCF obejmuje ponad 90 certyfikowanych ofert; komplet pięciu kubernetesowych certyfikatów CNCF (tytuł Kubestronaut) ma ponad 3500 osób w ponad 100 krajach. Zarządzanego Nomada u hiperskalerów nie ma, a Nomad nie pojawił się nawet w kwestionariuszu ankiety Stack Overflow 2025 — co nie znaczy „zerowe użycie”, ale mówi coś o skali.

Czy Nomad jest bezpiecznym wyborem na pięć lat? Licencja, właściciel i koniec LTS

Ta sekcja jest osobno, bo dotyczy czegoś innego niż reszta: nie tego, co narzędzie potrafi, tylko na jak długo można na nim oprzeć plan.

Licencja. W sierpniu 2023 HashiCorp przeszedł z MPL 2.0 na Business Source License 1.1. Nomad jest na liście objętych produktów, a BUSL nie jest licencją uznawaną za open source przez OSI. Plik licencyjny w bieżącej gałęzi wskazuje jako licencjodawcę International Business Machines Corporation, datę zmiany licencji ustala na cztery lata od publikacji danej wersji, a licencją docelową jest MPL 2.0.

Co to znaczy w praktyce? Poniższe jest odczytem tekstu licencji, nie poradą prawną — a wiążącą wykładnię zakresu dodatkowego zezwolenia ustala licencjodawca. Z lektury wynika, że hostowanie i używanie objętego oprogramowania na wewnętrzne potrzeby organizacji nie jest traktowane jako oferta konkurencyjna, a ograniczenie celuje w odpłatne oferowanie Nomada osobom trzecim w sposób konkurencyjny wobec płatnej wersji producenta — a więc w scenariusze w rodzaju „zarządzany Nomad jako usługa” czy płatnego wsparcia sprzedawanego wokół samego Nomada. Gdzie dokładnie przebiega ta granica w Twoim modelu biznesowym, rozstrzygnie prawnik, nie artykuł.

Jedna pułapka, na którą łatwo się nadziać: nie da się „zostać na ostatniej wersji MPL”, wybierając gałąź 1.6.x. Ostatnim wydaniem bezspornie na MPL 2.0 jest 1.6.3 z 30 października 2023 — już od 1.6.4 pliki licencyjne w repozytorium wskazują BUSL.

Bez forka pod neutralną fundacją. Terraform doczekał się OpenTofu, Vault doczekał się OpenBao. Nomad nie ma odpowiednika. Jeśli warunki się zmienią, alternatywą nie jest fork, tylko migracja na inny orkiestrator — a to zupełnie inny rachunek.

Jeden właściciel, po przejęciu. Przejęcie HashiCorp przez IBM domknęło się 27 lutego 2025. Zmieniło się m.in. to, że licencjodawcą jest dziś IBM, wersjonowanie przeszło na model korporacyjny, a licencje Enterprise sprzedawane są kanałem IBM. Żadnego oświadczenia o przyszłości licencji Nomada nie ma — ani o zaostrzeniu, ani o powrocie do otwartego modelu. To brak informacji i tak należy go traktować.

Cykl wsparcia — najtwardszy argument przy planowaniu wieloletnim. Od wersji 2.0 Nomad porzucił wersjonowanie semantyczne. Najnowsze wydanie to 2.0.5 z 13 sierpnia 2026. I rzecz kluczowa: gałąź 1.10.x jest ostatnią z etykietą wsparcia długoterminowego i kończy je 30 kwietnia 2027. Wydania Community Edition od 2.0.0 mają dwuletnią politykę poprawek, a dłuższe okna — wsparcie przedłużone i przedłużone ciągłe — to płatne pakiety dla klientów Enterprise.

Jak wybrać? Reguła kciuka

Do około dziesięciu węzłów, jeden zespół, jedna aplikacja, przewidywalny ruch, brak etatu na platformę → Docker Swarm nie jest wstydem. Jest tańszy w każdym wymiarze, a klaster, którego nikt nie utrzymuje, zepsuje się szybciej, niż Swarm zdąży się zestarzeć.
Od kilkunastu do mniej więcej tysiąca węzłów, obciążenia mieszane — kontenery, binarki, aplikacje Javy — i mały zespół platformowy → Nomad daje tu najwięcej możliwości przy najmniejszej liczbie warstw do utrzymania: jeden proces do aktualizowania zamiast łańcucha komponentów. Warunek: świadoma zgoda na licencję BUSL i na to, że przy nietypowej integracji częściej trafisz na „napisz to sam” niż na gotowy operator.
Powyżej mniej więcej tysiąca węzłów, wiele odizolowanych zespołów lub klientów w jednym klastrze, wymagania regulacyjne, potrzeba ekosystemu i gotowych operatorów, plany rekrutacyjne → Kubernetes. Z etatem na utrzymanie platformy, nie z ułamkiem etatu.

I pytanie, które warto zadać przed każdą z tych trzech odpowiedzi: czy Twoje obciążenia w ogóle potrzebują orkiestracji? Aplikacja, która od lat spokojnie stoi na jednej maszynie wirtualnej, po przeniesieniu do orkiestratora dostaje przede wszystkim nowy zestaw rzeczy, które mogą się zepsuć. O tym, jak dzielą się odpowiedzialności między modelami usług chmurowych, piszemy w artykule Chmura jako usługa: IaaS, PaaS i SaaS na przykładach, a o tym, gdzie w chmurze ucieka budżet — w artykule Chmura publiczna w rozsądnej cenie.

Który orkiestrator uruchomisz w chmurze WebDisk?

W naszej chmurze publicznej masz dwie drogi i obie są otwarte niezależnie od tego, który orkiestrator wybierzesz.

Zarządzany klaster Kubernetes (WebDisk K8s) — usługa dostępna dla użytkowników WebDisk Cloud; klaster zamawiasz z poziomu panelu, a platforma zbudowana na Apache CloudStack zakłada go za Ciebie — z publiczną adresacją IPv4 i IPv6 oraz skalowaniem liczby węzłów. Szczegóły konfiguracji sieci i zakres automatycznego skalowania ustalamy przy zamówieniu. Dla zespołów, które chcą pełnej kontroli, zostaje droga własnego klastra na infrastrukturze IaaS: z providerem CloudStacka dla Terraforma albo z Cluster API w pełnym reżimie „infrastruktura jako kod”.

Nomad, Swarm albo cokolwiek innego na własnych maszynach. Jeżeli po lekturze tego artykułu uznasz, że Twojemu zespołowi bliżej do Nomada, nic nie stoi na przeszkodzie: wynajmujesz maszyny wirtualne i sieć w chmurze publicznej WebDisk, a orkiestrator instalujesz i utrzymujesz po swojej stronie — w wersji Community bez opłat, a ewentualną licencję Enterprise rozliczasz bezpośrednio z jego producentem. Nie oferujemy zarządzanego Nomada i nie zamierzamy tego obiecywać; usługą zarządzaną jest u nas Kubernetes, a przy przejściu ze środowisk Docker Swarm nasz zespół pomaga w doradztwie i planie migracji.

Niezależnie od wyboru zostaje ta sama, nudna lista obowiązków właściciela klastra: aktualizacje, kopie zapasowe stanu i danych aplikacji, monitoring i ktoś, kto odbierze alarm. Jak układamy warstwy zabezpieczeń pod tym wszystkim, opisujemy w artykule Ile warstw ma bezpieczeństwo Twoich plików.

Częste pytania

Czy Nomad może zastąpić Kubernetesa w Twojej organizacji? Może — jeśli potrzebujesz przede wszystkim planisty zadań, masz obciążenia mieszane i mały zespół platformowy. Nie zastąpi go tam, gdzie liczy się ekosystem operatorów, dojrzała obsługa aplikacji stanowych, mikrosegmentacja sieci w rdzeniu albo dostępność usługi zarządzanej u dostawcy chmury. Pytanie brzmi nie „które narzędzie jest lepsze”, tylko „ile platformy naprawdę potrzebujesz i kto ją utrzyma”.

Co dokładnie kończy się 30 kwietnia 2027? Wsparcie gałęzi Nomad 1.10.x — ostatniej oznaczonej jako długoterminowa (LTS). Po tej dacie poprawki, w tym poprawki bezpieczeństwa, nie trafiają już do tej linii; trzeba przejść na nowszą gałąź albo wykupić przedłużone wsparcie w wersji Enterprise. Nowsze wydania Community Edition mają dwuletnią politykę poprawek, ale żadne nie nosi już etykiety LTS.

Czy Docker Swarm jest jeszcze rozwijany? Tryb Swarm wbudowany w silnik Dockera — tak: repozytorium moby/swarmkit żyje, a wydania z 2026 roku zawierają poprawki dotyczące Swarma. Docker nie ogłosił daty końca wsparcia, ale też nie deklaruje rozwoju — pisze, że zwolnił on na rzecz rozwiązań opartych na Kubernetesie. Zamknięty jest natomiast Swarm „classic”, osobny produkt z 2014 roku, zarchiwizowany w 2021.

Czy Nomad wymaga Consula i Vaulta? Nie — natywne wykrywanie usług wystarczy do startu, choć nie daje DNS-a. Z Consulem Nomad robi istotnie więcej (nazwy domenowe, siatka usług, intencje sieciowe), a Nomad Variables nie są zamiennikiem Vaulta: klucz główny szyfrowania leży na serwerach, a mechanizm przewidziano do niewielkich fragmentów konfiguracji.

Od czego zacząć, żeby klaster Nomada nie był otwarty? Od włączenia list kontroli dostępu — są domyślnie wyłączone, a inicjuje je nomad acl bootstrap. To pierwsza rzecz do zrobienia po postawieniu serwerów, przed wystawieniem czegokolwiek na sieć. Sam klaster produkcyjny to trzy albo pięć serwerów na region.

Czy Nomad uruchomi aplikację, której nie ma w obrazie kontenera? Tak — to jego wyróżnik. Sterownik exec uruchamia zwykłą binarkę w izolacji, java — archiwum JAR bez budowania obrazu, a exec2 izoluje proces natywnymi mechanizmami jądra. Sterownik virt do pełnych maszyn wirtualnych istnieje, ale producent oznacza go jako nieprzeznaczony na produkcję.

Podsumowanie

Wybór między Swarmem, Nomadem a Kubernetesem to w gruncie rzeczy odpowiedź na jedno pytanie: ile platformy chcesz utrzymywać. Swarm daje najmniej i najmniej kosztuje; Kubernetes daje najwięcej i najwięcej wymaga, oferując w zamian neutralną licencję, ekosystem i rynek kompetencji; Nomad stoi pośrodku — jeden plik, jedna binarka, obciążenia także niekontenerowe — za cenę licencji, która nie jest otwarta, i gałęzi długoterminowej kończącej się w kwietniu 2027.

Żadna z tych odpowiedzi nie jest uniwersalnie lepsza; zła jest tylko decyzja podjęta bez policzenia kosztu utrzymania. Napisz do nas — pomożemy porównać warianty pod kątem kosztu utrzymania i zaplanować migrację, a dla klastrów Kubernetes także przejrzeć, jak są utrzymywane.

HashiCorp Nomad, Kubernetes i Docker Swarm: który orkiestrator wybrać i ile kosztuje jego utrzymanie