Nomad, Kubernetes oder Docker Swarm: Was wählen?

WebDisk Blog · Kategorie: Public Cloud · Lesezeit: ~22 Minuten

Kurz gefasst:- Das sind nicht drei Varianten desselben Werkzeugs. Swarm ist eine Funktion der Docker-Engine, die Sie ohnehin schon haben; Kubernetes will eine Plattform sein und überlässt Ihnen die Wahl – und den Betrieb – von Netzwerk, Storage und eingehendem Datenverkehr; Nomad beschränkt sich auf eine einzige Rolle: die des Task-Schedulers.- Der größte Vorteil von Nomad gegenüber Kubernetes betrifft nicht Container. Es sind eine einzige Binärdatei, eine einzige Datei mit der Deployment-Beschreibung und Treiber, die auch gewöhnliche Prozesse und Java-Anwendungen starten – ohne jede einzelne davon in ein Image zu verpacken.- Entscheiden Sie nach den Betriebskosten, nicht nach der Funktionsliste: bis zu zehn Knoten – Swarm; gemischte Workloads und ein kleines Plattformteam – Nomad; große Skalierung und regulatorische Anforderungen – Kubernetes. Der Preis von Nomad: die Lizenz BUSL 1.1 (Lizenzgeber ist IBM) und das Ende des Branches mit Langzeit-Support (LTS) am 30. April 2027. >Sie arbeiten nicht mit dem Terminal? Überspringen Sie die Codeblöcke – die Beschreibung der Unterschiede, der Abschnitt „Wie wählen?“ und der Teil über die Risiken ergeben ein vollständiges Bild ohne einen einzigen Befehl.

Ein Gespräch über Container-Orchestrierung beginnt heute meist mit dem Satz „Dann nehmen wir eben Kubernetes“ und endet ein halbes Jahr später mit der Frage, wer das Ganze eigentlich betreiben soll. Zwischen diesen beiden Momenten liegt eine ganze Klasse von Entscheidungen, die sich am Anfang leichter treffen als später korrigieren lassen: wie viele Schichten Sie wirklich brauchen, wie viele davon jemand im Unternehmen um drei Uhr nachts reparieren kann und was passiert, wenn der Hersteller des Werkzeugs die Lizenz ändert.

Ein Orchestrator ist ein Programm, das dafür sorgt, dass die deklarierte Anzahl an Kopien einer Anwendung auf den verfügbaren Servern läuft: Er wählt selbst die Maschine aus, verschiebt eine Aufgabe nach einem Knotenausfall, tauscht die Version ohne Betriebsunterbrechung aus und registriert, wo ein bestimmter Dienst gerade läuft. In der Praxis läuft die Wahl heute auf drei Werkzeuge hinaus: Docker Swarm, HashiCorp Nomad und Kubernetes – mit dem Vorbehalt, dass überhaupt nur das letzte in den größten Branchenstudien gemessen wird.

Dieser Artikel zeigt, worin sie sich unterscheiden – nicht in Funktionen aus einer Tabelle, sondern in der Philosophie – und wird dann konkret: wie eine Deployment-Datei in Nomad aussieht, wie man eine neue Version per Canary-Verfahren ausliefert (eine Instanz der neuen Version neben der alten, zur Prüfung „im Livebetrieb“), wie man eine Anwendung startet, die in keinem Image liegt, und wo Nomad gegenüber Kubernetes tatsächlich gewinnt und wo es ebenso tatsächlich verliert. Wir schreiben diesen Text für Teams, die zum ersten Mal vor dieser Wahl stehen, und für jene, die Kubernetes bereits haben – und langsam den Verdacht schöpfen, dass es für ihre Größenordnung eine Nummer zu groß war. Alle Zahlen und Daten stammen aus Primärquellen und sind auf dem Stand von Ende August 2026; wo eine Zahl aus Herstellermaterial und nicht aus einer Messung stammt, sagen wir das ausdrücklich.

Worin unterscheiden sich Nomad, Kubernetes und Docker Swarm wirklich?

Der häufigste Fehler in Vergleichen besteht darin, Funktionslisten gegenüberzustellen. Der Unterschied beginnt früher – nämlich darin, wie weit jedes dieser Werkzeuge seine eigene Zuständigkeit definiert.

Kubernetes will eine Plattform sein. Es hat APIs für Netzwerk, Storage, Richtlinien, eingehenden Datenverkehr und Berechtigungen. Aber „eingebaut“ heißt hier meist „eingebaute Schnittstelle plus externe Implementierung, die Sie selbst auswählen und betreiben werden“. Das Netzwerk liefert Kubernetes nicht – es definiert ein Modell, umgesetzt wird es von CNI-Plugins (dem Standard zum Anbinden von Containern an das Netzwerk). Storage ist CSI (der Standard zum Anbinden von Laufwerken). Eingehender Datenverkehr ist Ingress – eine funktional eingefrorene Schnittstelle, deren Nachfolger die Gateway API ist. Wie schmerzhaft eine solche Konstruktion sein kann, zeigte das Jahr 2026: ingress-nginx, der populärste Ingress-Controller, wurde vom Netzwerkteam des Projekts samt Sicherheits-Patches eingestellt. Eine Komponente, die den Produktivverkehr tausender Unternehmen trug, veränderte sich unter deren Füßen.

Nomad will nur ein Scheduler sein – und sagt das in der eigenen Dokumentation ausdrücklich: Kubernetes zielt auf den kompletten Funktionsumfang zum Betrieb containerisierter Anwendungen, Nomad konzentriert sich auf Cluster-Verwaltung und Task-Scheduling. Der Rest ist delegiert: die vollständige Service-Schicht an Consul, Secrets an Vault oder OpenBao (das sind eigenständige Produkte desselben Herstellers), das Netzwerk jenseits von Host- und Bridge-Modus an CNI, der Storage an CSI, das Autoscaling an einen separaten Daemon. Das ist kein Mangel – es ist eine Designentscheidung, die ihren Preis und ihren Lohn hat.

Docker Swarm implementiert alles selbst, aber der Umfang ist schmal. Ohne irgendetwas zusätzlich zu installieren, bekommen Sie Cluster-Verwaltung über die gewöhnliche Docker-CLI, eine deklarative Dienstbeschreibung, Skalierung, ein Overlay-Netzwerk (ein virtuelles Netz, das über dem realen Servernetz aufgespannt ist), Service Discovery per DNS mit Lastverteilung, rollierende Updates und – was Anerkennung verdient – gegenseitige TLS-Authentifizierung zwischen den Knoten, standardmäßig eingeschaltet, mit Zertifikaten, die alle drei Monate erneuert werden. Sie bekommen keine Namespaces und keine rollenbasierte Zugriffskontrolle in der Engine selbst, kein Autoscaling und keine ausgereifte Storage-Unterstützung.

Wo verläuft die Grenze „einer Anwendung“ in jedem dieser Werkzeuge?

Diese Unterscheidung entscheidet darüber, wie Sie Ihre Deployments über die kommenden Jahre beschreiben werden.

Docker Swarm – es gibt keine Co-Location-Schicht (eine Aufgabe ist ein Container); die Skalierungseinheit ist der Dienst (service); das Ganze wird in einer einzigen Compose-Datei mit N Diensten beschrieben.
Nomad – Co-Location und Skalierung sind dasselbe: die Gruppe (group); die gesamte Anwendung wird in einer einzigen Job-Datei beschrieben.
Kubernetes – Co-Location ist der Pod, Skalierung ist das Deployment (über ein ReplicaSet); eine Anwendung besteht in der Regel aus 4–8 Objekten, oft in mehreren Dateien.

Daraus folgen drei Dinge, die man vor der Wahl kennen sollte:

Swarm hat keine Co-Location-Schicht. Ein Hilfscontainer – ein Netzwerk-Proxy, ein Agent zum Einsammeln von Logs, ein Metrik-Exporter – ist in Swarm ein eigener Dienst und verliert damit die Garantie eines gemeinsamen Netzwerk-Namespace und eines gemeinsamen Volumes mit der Anwendung. Das blockiert eine ganze Klasse von Architekturen und beeinträchtigt nicht bloß den Komfort.
In Nomad wird die Gruppe ausdrücklich deklariert, in Kubernetes entsteht der Pod nebenbei. In Kubernetes beschreiben Sie eine Vorlage im Deployment-Objekt und bekommen Pods, die Sie nicht selbst erzeugen und die sich nicht verschieben lassen – man kann sie nur neu erstellen. In Nomad schreiben Sie eine Gruppe und wissen, dass genau sie zugleich die Einheit der Co-Location und der Skalierung ist.
Was in Kubernetes verschiedene Objektarten sind, ist in Nomad ein einziges Feld. type = "service" entspricht dem Deployment, type = "batch" dem Job-Objekt, type = "system" dem DaemonSet und type = "sysbatch" einer einmaligen Aufgabe, die genau einmal auf jedem passenden Knoten läuft – wofür es in Kubernetes keine direkte Entsprechung gibt. Eine Datei, ein Feld, vier Verhaltensweisen.

Es gibt noch einen Unterschied, den die Kubernetes-Dokumentation selbst formuliert: Kubernetes ist kein Orchestrator im Sinne von „mach A, dann B“, sondern eine Sammlung unabhängiger Regelschleifen, die den Ist-Zustand an den Soll-Zustand heranführen. Die Konsequenz ist sehr praktisch – es gibt keinen einzigen Ort, an dem der Verlauf eines Deployments sichtbar ist. In Nomad gibt es ihn: nomad deployment status.

Ist Docker Swarm tot? Nicht der, an den Sie denken

Im Netz wiederholt sich der Satz „Swarm ist tot“. Er ist zugleich wahr und falsch, weil er zwei verschiedene Dinge betrifft.

Docker Swarm „classic“ – ein eigenständiges Produkt aus dem Jahr 2014, das mehrere Docker-Daemons zusammenspannte – ist tatsächlich eingestellt: Das Repository wurde am 1. Februar 2021 archiviert, das Image auf Docker Hub trägt das Label „deprecated“, und die Unterstützung wurde in Version 23.0 aus der Engine entfernt. Von ihm handelt der Großteil der kursierenden „Ankündigungen zur Einstellung“.

Der Swarm mode, also der seit Version 1.12 in die Docker Engine eingebaute Modus, hat kein angekündigtes Support-Ende. Der Code wird gepflegt: Das Repository moby/swarmkit wurde nicht archiviert, und die Commits im Hauptbranch stammen von Ende August 2026. Die Release-Linie Docker Engine 29 brachte Swarm konkrete Verbesserungen, darunter die Behebung beschädigter Raft-Snapshots bei großem Cluster-Zustand. Fairness verlangt jedoch, die zweite Hälfte zu nennen: Die einzige offizielle Verlautbarung von Docker zu diesem Thema steht auf der Seite „eingestellte und abgekündigte Produkte“ und lautet, dass der Swarm mode funktionsfähig bleibt, die Entwicklung sich aber zugunsten kubernetesbasierter Lösungen verlangsamt hat.

Die praktischen Grenzen von Swarm sollte man kennen, bevor man auf ihn setzt:

Es gibt kein Autoscaling. Ein Ticket mit dem Vorschlag horizontaler Dienstskalierung liegt seit August 2017 offen im Repository – ohne Implementierung.
Die Storage-Unterstützung über CSI ist experimentell: ohne Snapshots, Klonen und Vergrößern von Volumes.
docker stack deploy nutzt das alte Compose-Format in Version 3, das mit der aktuellen Compose-Spezifikation nicht kompatibel ist. Ein Teil der Schlüssel wird stillschweigend übergangen – das Deployment gibt eine Warnung aus und läuft weiter. „Bei mir läuft es in Compose“ und „es läuft im Stack“ sind zwei verschiedene Aussagen über dieselbe Datei.
Secrets werden im Ruhezustand verschlüsselt, configs dagegen nicht – und landen direkt im Dateisystem des Containers. Das Limit beträgt für beide 500 kB.
Empfohlen sind maximal sieben Manager-Knoten, und ein Cluster aus N solchen Knoten übersteht den Ausfall von (N−1)/2 davon. Skalierbarkeitsgrenzen veröffentlicht Swarm keine.
Es gibt zudem ein Signal, das man bei der Planung für die nächsten Jahre beobachten sollte: Auf einem Knoten mit aktiviertem Swarm lässt sich heute nftables nicht aktivieren, und nftables soll zum Standard-Firewall-Mechanismus in Docker werden – der Hersteller nennt jedoch weder eine Version noch ein Datum.

Kommerziellen Support bietet Mirantis. In einem Beitrag vom Juli 2025 fällt die Zusage, Swarm im Rahmen von MKE 3 „mindestens bis 2030“ zu unterstützen, während die veröffentlichte Lebenszyklus-Matrix heute bis März 2028 reicht und MKE 4 bereits ein reines Kubernetes-Produkt ist. Diese beiden Quellen decken unterschiedliche Horizonte ab, deshalb muss man das Support-Enddatum bei mehrjähriger Planung schriftlich beim Anbieter bestätigen lassen.

Wann ergibt Swarm Sinn? Wenn Sie einige bis etwa ein Dutzend Knoten haben, ein Team, vorhersehbaren Verkehr und niemanden, der hauptamtlich das Cluster betreiben würde. Letzteres ist wichtiger, als es scheint: Ein eigenhändig mit kubeadm aufgesetztes Kubernetes-Cluster, das ein Jahr lang unangetastet bleibt, hört schlicht auf zu funktionieren, weil die einjährigen Zertifikate der Control Plane ablaufen – erneuert werden sie erst durch ein Update. In einem Managed Service erledigt das der Anbieter für Sie. Swarm altert unter solchen Bedingungen langsamer. Im Übrigen ergeben die Zahlen von Mirantis selbst – 2022 veröffentlicht und 2024 wortgleich wiederholt, ohne offengelegte Methodik – umgerechnet im Durchschnitt etwa zehn Knoten und hundert Container pro Cluster. Swarm dient in der realen Welt nicht dazu, große Cluster zu bauen, sondern viele kleine. Das ist seine ehrliche Nische, kein Scheitern.

Was kostet Kubernetes wirklich, bevor Sie die erste Anwendung ausliefern?

Kubernetes ist heute die Standardwahl und hat dafür harte Gründe: die Lizenz Apache 2.0, eine neutrale Governance im Rahmen der CNCF, das größte Ökosystem und Managed Services bei jedem großen Anbieter. Laut einer CNCF-Umfrage betreiben 82 % der Container-Nutzer Kubernetes in Produktion (Vorsicht bei der Bezugsgröße: Das ist der Anteil der Container-Nutzer, nicht aller Organisationen).

Der Preis ist jedoch berechenbar, und man sollte ihn in Zahlen sehen, nicht in Adjektiven:

Die Control Plane besteht aus separaten Prozessen: API-Server, etcd-Datenbank, Scheduler, Controller-Manager, und auf dem Knoten kubelet sowie die Container-Laufzeitumgebung. Dazu CNI und CoreDNS, ohne die ein Cluster praktisch nicht funktioniert.
Die begriffliche Oberfläche ist groß und zählbar: Die offizielle API-Referenz führt 22 API-Gruppen auf. Um eine einzige HTTP-Anwendung in Produktion bereitzustellen, muss man Pods, Deployment, ReplicaSet, Service, Ingress oder Gateway API, Namespaces, ConfigMap, Secret, PVC/PV/StorageClass, Ressourcenanforderungen und -limits, drei Arten von Probes, ein ServiceAccount mit Rolle und Rollenbindung sowie Netzwerkrichtlinien verstehen – und zusätzlich Helm oder Kustomize, CNI und CSI auswählen.
Updates sind eine Pflicht, keine Option. Unterstützt werden die drei jüngsten Branches (derzeit 1.37 „Garhwal“, veröffentlicht am 26. August 2026), und das Support-Fenster einer Version beträgt rund 14 Monate. Der API-Server darf keine Version überspringen – man zieht sie nacheinander hoch. Was das kostet, sieht man am besten in der Preisliste: In Amazon EKS kostet die Control Plane 0,10 USD pro Cluster und Stunde, der erweiterte Support einer älteren Version dagegen 0,60 USD – also das Sechsfache, allein dafür, dass nicht aktualisiert wird.
Die Skalierung ist gemessen und veröffentlicht: bis zu 110 Pods pro Knoten, bis zu 5.000 Knoten, bis zu 150.000 Pods. Das ist im Übrigen ein Vorteil, kein Nachteil – die beiden anderen Werkzeuge veröffentlichen solche Grenzwerte nicht. Man sollte sie nur so lesen, wie sie geschrieben sind: Es sind Messgrenzen, und wer zwei Dimensionen gleichzeitig ausreizt, bringt das Cluster deutlich früher zu Fall.

Ein häufiges Missverständnis: k3s. Diese Distribution senkt tatsächlich die Installationskosten und den Ressourcenverbrauch, aber sie senkt die begrifflichen Kosten nicht um ein Jota – es ist zertifiziertes Kubernetes mit derselben API. Wer zu k3s greift, damit „Kubernetes einfacher wird“, löst ein anderes Problem als das, das er hat. Wie ein guter Betrieb eines solchen Clusters aussieht – Updates, Sicherung der etcd-Datenbank, Observability, Rufbereitschaft – haben wir gesondert im Artikel Technischer Kubernetes-Support: Das Cluster aufzusetzen ist die leichteste Etappe beschrieben. Wie die Kosten eines Werkzeugs in eine Abhängigkeit von seinem Hersteller umschlagen, behandeln wir wiederum im Artikel Vendor-Lock-in in der Public Cloud.

Was bekommen Sie, wenn der Orchestrator eine einzige Binärdatei ist?

Nomad ist ein einzelnes, in Go geschriebenes Programm, das je nach Konfiguration als Server oder als Client arbeitet. Es gibt keine externe Datenbank – für die Konsistenz des Zustands sorgt der eingebaute Konsensalgorithmus Raft (ein Mechanismus, in dem sich die Server auf eine gemeinsame Version der Wahrheit einigen), es gibt also keine Entsprechung zu etcd, die man sichern, aktualisieren und tunen müsste. Eine Produktionsregion besteht aus drei oder fünf Servern: drei überstehen den Ausfall eines Servers, fünf den von zweien. Es geht um das Quorum, also die Mehrheit, die sich verständigen muss, damit das Cluster Entscheidungen trifft. Für die Zahl der Clients veröffentlicht der Hersteller keinen Grenzwert.

Die Skalierung erhöht man durch das Hinzufügen von Regionen, nicht durch das Aufblähen des Quorums. Die Regionen sind vollständig unabhängig – sie teilen weder Jobs noch Clients noch Zustand – und werden durch ein leichtgewichtiges Protokoll zum Informationsaustausch zwischen den Servern (Gossip) verbunden, sodass ein API-Aufruf mit Regionsparameter von selbst in der richtigen Region landet. Aus der autoritativen Region replizieren sich Zugriffsrichtlinien, Rollen, Namespaces, Knotenpools und Limits. Zum Vergleich: In Kubernetes ist Mehrregionsbetrieb ein Architektur- und kein Konfigurationsproblem – das Projekt KubeFed wurde archiviert, und die Gruppe, die sich mit mehreren Clustern befasst, liefert bewusst eine API ohne Referenzimplementierung.

Zwei Vorbehalte, ohne die dieses Bild Werbung wäre:

Der Block multiregion in der Job-Beschreibung erfordert die Enterprise-Version und stellt kein automatisches Failover zwischen Regionen bereit. Eine Föderation von Regionen ist nicht dasselbe wie Hochverfügbarkeit zwischen Standorten.
Die Nomad-Dokumentation sagt es unumwunden: „Nomad is not secure-by-default“ – Nomad ist nicht standardmäßig sicher – und die Zugriffskontrolllisten (ACL) sind standardmäßig deaktiviert. Ein „auf die Schnelle“ aufgesetztes und ohne deren Aktivierung exponiertes Cluster ist kein theoretisches Risiko.

Drei Begriffe, die immer wieder auftauchen

Bevor Sie auf die erste Datei schauen: Drei Begriffe würde man auf Deutsch am liebsten mit demselben Wort bezeichnen – „Aufgabe“ – trennen wir sie also gleich zu Beginn.

job – die gesamte Anwendungsbeschreibung: eine Datei, ein Name, eine Version. Ihn rollt man aus, nimmt ihn zurück und stoppt ihn.
task – ein einzelner Prozess oder Container innerhalb eines job.
Allocation – eine Kopie der Task-Gruppe, die auf einem konkreten Client läuft, das Gegenstück zum Pod in Kubernetes. Eine Skalierung auf drei Instanzen sind drei Allocations; ein Knotenausfall bedeutet das Verschwinden einer Allocation und das Anlegen einer neuen anderswo. Wenn Sie in einem Befehl alloc sehen, ist genau das gemeint.

Nomad beschreibt man in HCL (HashiCorp Configuration Language) – derselben Konfigurationssprache wie Terraform: Blöcke werden in geschweiften Klammern verschachtelt, Einrückungen bedeuten nichts, und die Sprache selbst hat Variablen, Ausdrücke und Schleifen. Nachfolgend die vollständige Datei: zwei Instanzen einer Webanwendung, Ressourcenlimits, ein dynamischer Port, die Registrierung des Dienstes und ein Health-Check.

job "webapp" {
  # type ist standardmäßig "service"; hier explizit zur besseren Lesbarkeit
  type = "service"
  datacenters = ["dc1"]

  group "web" {
    count = 2

    network {
      # Port ohne "static" = dynamischer Port, den Nomad auf dem Host vergibt;
      # "to" sagt, auf welchen Port der Verkehr INNERHALB des Containers trifft
      port "http" {
        to = 8080
      }
    }

    service {
      name = "webapp"

      # ACHTUNG: Der Standardwert ist "consul". Ohne diese Zeile versucht Nomad,
      # den Dienst in Consul zu registrieren, und der Job startet ohne Consul nicht.
      provider = "nomad"

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

      check {
        # bei provider = "nomad" sind AUSSCHLIESSLICH die Typen "http" und "tcp" erlaubt.
        # Der check-Block erbt den Port vom Service - er muss nicht wiederholt werden.
        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"] # Liste der Port-LABELS aus dem network-Block
      }

      resources {
        cpu = 200 # MHz - Nomad reserviert Takt, nicht einen Bruchteil eines Kerns wie K8s
        memory = 256 # MB
      }
    }
  }
}

Vier Dinge, über die die meisten Einsteiger stolpern – man sollte sie kennen, bevor man einen Abend an sie verliert:

provider hat standardmäßig den Wert "consul". Ohne ein explizites provider = "nomad" startet der Job in einem Cluster ohne Consul nicht. Das ist der häufigste Anfangsfehler.
Bei nativer Registrierung sind ausschließlich die Checks http und tcp erlaubt.
Ports werden ausschließlich in group -> network deklariert und über ports = [...] in der Task-Konfiguration referenziert. Nomad injiziert in den Task die Variablen NOMAD_ADDR_<Label>, NOMAD_PORT_<Label> und NOMAD_IP_<Label>.
Die native Registry liefert kein DNS. Bei provider = "nomad" existieren keine Namen der Art webapp.service.consul; Adresse und Port liest man aus der API, aus nomad service info oder aus dem template-Block aus. Wer den Dienstnamen als Hostnamen einträgt, bekommt einen Namensauflösungsfehler und sucht ihn meist an einer ganz anderen Stelle. Das ist eines der Dinge, die Consul beisteuert.

Zwei Mythen, die in beide Richtungen kursieren, sollte man ebenfalls richtigstellen. „Nomad funktioniert ohne Consul nicht“ ist falsch – native Service Discovery gibt es seit Version 1.3 und die zugehörigen Health-Checks seit 1.4. Aber „Nomad braucht kein CNI“ ist eine Vereinfachung – der Bridge-Netzwerkmodus erfordert CNI-Plugins auf allen Linux-Clients.

Wie liefern Sie eine neue Version ohne Ausfallzeit und ohne nächtlichen Weckruf aus?

Der gesamte Mechanismus einer sicheren Auslieferung passt in einen einzigen Block, den Sie der Gruppe hinzufügen:

update {
  max_parallel = 2 # wie viele Allocations GLEICHZEITIG getauscht werden (Standard 1)

  # woran Nomad erkennt, dass eine Allocation gesund ist:
  # "checks" - Tasks laufen UND die Service-Checks sind grün (Standard)
  # "task_states" - es genügt, dass die Tasks gestartet sind
  # "manual" - Gesundheit meldet der Operator über die API
  health_check = "checks"

  min_healthy_time = "30s" # wie lange sie gesund sein muss, um als gut zu gelten
  healthy_deadline = "3m" # Frist für eine EINZELNE Allocation
  progress_deadline = "10m" # FORTSCHRITTS-Frist des gesamten Deployments; muss > healthy_deadline sein

  auto_revert = true # nach einem fehlgeschlagenen Deployment zurück zur letzten STABILEN Version
  canary = 1 # wie viele Canaries NEBEN der laufenden Version gestartet werden
  auto_promote = false # false = Promotion von Hand: nomad job promote webapp
}

Ein Canary ist eine Instanz der neuen Version, die neben der alten läuft. Nomad schaltet den Verkehr nicht selbst um – es registriert den Canary unter separaten Labels (canary_tags) und wartet auf Ihre Entscheidung; Ihr Proxy entscheidet, ob und wann er Anfragen dorthin lenkt. Bis zum nomad job promote arbeitet die alte Version unangetastet weiter. auto_revert wiederum sorgt dafür, dass eine misslungene Auslieferung von selbst zur letzten funktionierenden Version zurückkehrt, ohne dass jemand geweckt werden muss.

Eine Falle, die man sich merken sollte: health_check = "checks" ohne definierten check-Block bedeutet ein Deployment, das die Gesundheit nie bestätigt und erst am progress_deadline scheitert. Das ist die häufigste Ursache „hängender“ Deployments.

Startet der Orchestrator eine Anwendung, die in keinem Container-Image liegt?

Wenn man eine einzige Sache benennen sollte, die Nomad nach dem Prinzip „geht/geht nicht“ von den beiden anderen Werkzeugen unterscheidet, dann wäre es die Architektur der Task-Driver. In die Binärdatei sind fünf davon eingebaut: docker, exec, raw_exec, java und qemu – wobei raw_exec einen Prozess ohne jede Isolation startet und aus diesem Grund standardmäßig deaktiviert ist. Drei weitere offizielle werden separat installiert: exec2, podman und virt. Ein Treiber ist ein Plugin – einen eigenen kann man schreiben, ohne Nomad neu zu kompilieren.

In der Praxis heißt das, dass derselbe Scheduler, dieselben Berechtigungen und derselbe Deployment-Mechanismus einen Container, einen gewöhnlichen Prozess, ein JAR-Archiv und eine virtuelle Maschine bedienen. Nachfolgend ein älterer Dienst, gestartet als nackter Prozess – ohne Docker auf dem Host und ohne Image-Build:

# AUSSCHNITT: Der task-Block steht immer innerhalb von job -> group -> task.
# Das Job-Gerüst ist identisch mit dem Beispiel oben - es ändern sich
# AUSSCHLIESSLICH driver und config (Port "http" stammt aus dem network-Block der Gruppe).
task "api" {
  # isolierter fork/exec: chroot (der Prozess sieht nur einen abgetrennten Teil
  # des Dateisystems) + Namespaces, KEIN Docker auf dem Host
  driver = "exec"

  artifact {
    source = "https://artefakte.example/download/meine-app-1.4.2"

    options {
      # checksum steht INNERHALB von options. Immer prüfen - artifact lädt über das Netz.
      checksum = "sha256:0f5e...durch-echte-ersetzen"
    }
  }

  config {
    command = "local/meine-app-1.4.2" # Standardziel von artifact ist das Verzeichnis local/
    args = ["--listen", "${NOMAD_ADDR_http}"]
  }

  resources {
    cpu = 300
    memory = 256
  }
}

Der Rest der Datei – job, group, network mit dynamischem Port und service mit Health-Check – sieht genauso aus wie im ersten Beispiel; darin liegt die ganze Pointe. Den task-Block allein kann man allerdings nicht separat ausrollen.

Eine Java-Anwendung startet man analog – es ändern sich nur der Treiber und dessen Konfiguration (jar_path, jvm_options). Der Treiber exec2 geht einen Schritt weiter: Er isoliert den Prozess mit nativen Kernel-Mechanismen (cgroups v2, Landlock), ohne Container-Image und ohne chroot.

Wie sieht dasselbe auf der anderen Seite aus? In Kubernetes ist das Modell per Definition containerbasiert. Eine virtuelle Maschine erfordert das Projekt KubeVirt, also eine in einen Pod verpackte VM – eine zusätzliche Schicht und ein zusätzliches System, das betrieben werden will. Eine nackte Binärdatei landet in der Praxis immer in einem Image (und sei es FROM scratch), was eine Registry und eine Build-Pipeline für jede Anwendung erzwingt, auch für eine, die aus einer einzigen Datei besteht. In Swarm ist eine Aufgabe ein Docker-Container und ein Befehl – an dieser Stelle endet die Liste.

Ein Vorbehalt, ohne den dies Werbung wäre: Der Treiber virt, der vollständige virtuelle Maschinen über libvirt betreibt, ist vom Hersteller selbst als in aktiver Entwicklung befindlich und nicht für den Produktionseinsatz bestimmt gekennzeichnet.

Wie sehen ein nächtlicher Job und ein Agent auf jedem Knoten aus?

Zwei weitere Typen zeigen, wie viel in ein einziges Feld type passt.

Ein zyklischer Job – eine jede Nacht laufende Datenbanksicherung:

job "nightly-db-dump" {
  # periodic funktioniert AUSSCHLIESSLICH für die Typen "batch" und "sysbatch"
  type = "batch"

  periodic {
    # "crons" ist eine Liste von Ausdrücken; das Feld "cron" (Einzahl) ist seit 1.6.2 veraltet
    crons = ["0 3 * * *"]
    prohibit_overlap = true # nicht starten, solange der vorherige Durchlauf läuft
    time_zone = "Europe/Warsaw" # standardmäßig UTC
  }
  # ...
}

Zwei Dinge, wegen derer Menschen Daten verlieren: Das Ergebnis eines solchen Jobs muss das Allocation-Verzeichnis verlassen, denn dieses verschwindet mit ihr – nötig ist ein Host-Volume oder das Wegschieben der Kopie in einen Objektspeicher. Und das zweite: Einen bestehenden job kann man nicht an Ort und Stelle in einen zyklischen umwandeln – man muss ihn mit der Option -purge stoppen. Worin sich eine Sicherung von einer Replik unterscheidet, haben wir ausführlicher im Artikel Backup in der Cloud: die 3-2-1-Regel, RPO/RTO und die Kopie, die Ransomware nicht löscht beschrieben.

Ein Systemjob – eine Allocation auf jedem passenden Knoten, wie ein DaemonSet in Kubernetes; neue Knoten erhalten sie nach dem Beitritt automatisch:

job "node-exporter" {
  type = "system" # in einem "system"-Job wird count NICHT gesetzt

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

Ein Versionsunterschied, der beim Langzeit-Support überraschen kann: Deployments für Jobs des Typs system gibt es erst ab Nomad 1.11.0. Im Branch 1.10.x verhält sich der update-Block für sie nicht so, wie es die Dokumentation neuerer Versionen nahelegt.

Mit welchen Befehlen beginnt die Arbeit mit Nomad?

Der kürzeste Weg zum eigenen Experiment ist nomad agent -dev – ein Ein-Knoten-Cluster im Arbeitsspeicher, mit einem einzigen Befehl gestartet. Ein Produktionscluster ist dasselbe Programm, nur mit einer Konfigurationsdatei und der Rolle Server oder Client.

# Trockenlauf auf dem Server: Diff zum aktuellen Stand + Ergebnis des Schedulings.
# Exit-Codes: 0 = nichts ändert sich, 1 = es wird Änderungen geben, 255 = Fehler
nomad job plan webapp.nomad.hcl

# Deployment
nomad job run webapp.nomad.hcl

# Status des Jobs und Verlauf des Deployments (bei Canaries: Spalten Promoted / Canaries)
nomad job status webapp
nomad deployment status -monitor <deployment-id>
nomad node status

# native Service-Registry - funktioniert bei provider = "nomad", nicht in Consul
nomad service list
nomad alloc checks <alloc-id>

# Logs einer konkreten Allocation und des gesamten Jobs
nomad alloc logs -f <alloc-id> server
nomad alloc logs -job webapp -tail -n 50

# Promotion des Canary und Rollback auf eine frühere Version
nomad job promote webapp
nomad job history -p webapp
nomad job revert webapp 3

Wissenswert ist, dass nomad job validate keine Offline-Validierung ist – der Befehl schickt den Job an den Server, ohne erreichbare Cluster-Adresse funktioniert er also nicht.

Wer setzt Nomad tatsächlich ein?

Diese Frage verlangt eine vorsichtige Antwort, denn die öffentlichen Nomad-Referenzen sind größtenteils alt, und ein Unternehmen kann seinen Stack ohne Ankündigung wechseln. Nachfolgend ausschließlich Einsätze, die in Primärquellen beschrieben sind – jeder mit dem Jahr der Veröffentlichung, denn keiner davon ist als heutiger Stand zu lesen:

Cloudflare (2020) – Wartungsdienste und Verwaltung von Neustarts in jedem Edge-Rechenzentrum, fünf Nomad-Server pro Standort; die Wahl war unter anderem durch die Treiber für gewöhnliche Binärdateien motiviert.
Internet Archive (2021) – über hundert Deployments, von Kubernetes auf Nomad mit Consul migriert.
Q2 (2020) – Online-Banking: über 7.000 Jobs, über 40.000 Tasks, 1.500 virtuelle Maschinen, überwiegend im eigenen Rechenzentrum.
Lob (2022) – Konsolidierung mehrerer Plattformen auf Nomad; den früheren Anlauf mit Kubernetes beschreibt das Team als aufgegeben.
Behavox (2023) – Verwaltung von Microservices; die aktuellste öffentliche Beschreibung eines Wechsels zu Nomad, die sich finden ließ.

Fairness verlangt, auch die Gegenbewegung zu zeigen, denn sie ist ebenso gut dokumentiert. SeatGeek beschrieb im November 2024 die Migration von Nomad zu Kubernetes – beim Umbau der Build-Maschinen im CI-System sank die durchschnittliche Wartezeit von 16 auf 2 Sekunden. Fly.io ersetzte Nomad 2023 durch einen eigenen Orchestrator und nannte drei Gründe: das Packen von Aufgaben zur Minimierung der Hardware dort, wo die Plattform Reserve brauchte; die Annahme einer Föderation von Regionen statt eines einzigen globalen Clusters; sowie das Fehlen einer synchronen Skalierung von null auf einem bestimmten Server.

Man sollte auch den Einsatzkontext der einzigen öffentlichen Referenz mit einer Bestätigung kennen, die jünger als ein Jahr ist. CircleCI beschreibt in seiner Dokumentation vom Mai 2026 die Standardarchitektur des selbst gehosteten Produkts CircleCI Server: Die Nomad-Server laufen dort als Dienst innerhalb des Kubernetes-Clusters des Kunden – und ab Version 4.8 erlaubt der Hersteller, sie auf separate virtuelle Maschinen auszulagern. Das disqualifiziert keines der beiden Werkzeuge; es zeigt, dass in größeren Organisationen beide nebeneinander für unterschiedliche Aufgaben eingesetzt werden.

Worin ist Nomad Kubernetes tatsächlich überlegen?

Einstiegs- und Betriebskosten des Werkzeugs selbst. Eine Binärdatei in der Rolle Server oder Client, eingebauter Konsens, keine separate Zustandsdatenbank mit eigenem Release-Zyklus. Den Cluster-Zustand muss man ohnehin per Sicherung absichern, aber das erledigt dieselbe Binärdatei und kein separates System – mit dem Vorbehalt, dass die Automatisierung dieser Sicherungen eine Enterprise-Funktion ist.
Nicht-containerisierte Workloads, ohne ein zweites System hinzuzufügen. Derselbe Scheduler, dieselben Berechtigungen und dieselben Deployments für einen Container, einen Prozess, eine Java-Anwendung und – mit dem Vorbehalt der Reife – eine virtuelle Maschine.
Mehrregionsbetrieb ist ein Konfigurations- und kein Architekturproblem. Ein API-Einstiegspunkt und ein Token zur Verwaltung mehrerer Cluster, Replikation von Richtlinien und Namespaces aus der autoritativen Region. Mit den Vorbehalten aus den vorherigen Abschnitten: Der Zustand repliziert sich nicht zwischen Regionen, und der Block multiregion ist eine Enterprise-Funktion.
Templating steckt in der Sprache selbst, nicht in einem Aufsatz darüber. HCL2 hat Variablen, Ausdrücke, Funktionen und Schleifen. YAML hat sie nicht – es ist keine Sprache, sondern ein reines Datenformat – daher der ganze Überbau: Helm, Kustomize, jsonnet. Helm templatet YAML als Text, ein Einrückungsfehler zeigt sich also erst nach dem Rendern. Vorbehalt: HCL2 wird auf der Seite der Operator-CLI ausgewertet, der Server bekommt bereits eine fertige Struktur – das ist kein Mechanismus für Secrets zur Laufzeit (dafür dient der Block template).
Weniger Begriffe vor dem ersten Produktions-Deployment – gut ein Dutzend, und alle passen in eine Datei und eine CLI.
Ein Ort, an dem das Deployment sichtbar ist. Das klingt banal, bis man jemandem erklären muss, warum ein Deployment stehen geblieben ist.

Was wir dagegen nicht schreiben werden, obwohl es im Netz kursiert: dass Nomad schneller sei als Kubernetes. Es existiert kein unabhängiger Test, der diese Werkzeuge vergleicht. Das berühmte Ergebnis „zwei Millionen Container“ stammt aus einem Hersteller-Benchmark von 2020, in dem alpine-Container mit dem Befehl sleep gestartet wurden, mit einer Reservierung von 30 MB Arbeitsspeicher, ohne Netzwerkkonfiguration und mit deaktivierten Deployments. Er misst den Durchsatz des Schedulers, nicht die Lebensfähigkeit eines Clusters unter Produktivlast. Wir haben auch keine glaubwürdige Messung des Arbeitsspeicherverbrauchs des Nomad-Agenten in einer Primärquelle gefunden – alle kursierenden Zahlen sind nicht überprüfbar, deshalb nennen wir sie nicht.

Worin ist Kubernetes Nomad tatsächlich überlegen?

Ein fairer Vergleich muss diesen Abschnitt ebenso stark ausfallen lassen wie den vorherigen.

Lizenz und Governance. Apache 2.0, die CNCF, Neutralität gegenüber Anbietern. Nomad steht unter einer Lizenz, die den Code offenlegt, aber keine Open-Source-Freiheit gewährt – und Lizenzgeber ist IBM.
Was in Nomad kostenpflichtig ist, ist in Kubernetes im Kern kostenlos enthalten. Hinter der kostenpflichtigen Version Nomad Enterprise stehen unter anderem: Audit-Logging, Ressourcenkontingente, Richtlinien (Sentinel), automatische Updates und Sicherungen, Redundanzzonen sowie Multiregion-Deployments. Das ist der am häufigsten übergangene Kostenblock eines solchen Vergleichs.
Ökosystem. Das Muster „Operator + eigener Ressourcentyp“ erlaubt es, das Datenmodell des Clusters zu erweitern und es mit denselben Werkzeugen zu bedienen. Nomad hat dafür keine Entsprechung. Der Katalog Artifact Hub zählt über 21.500 Pakete aller Arten – nicht nur Helm-Charts, sondern auch Operatoren und Plugins – und Nomad Pack, das Gegenstück zu Helm, hat nie Version 1.0 erreicht (die neueste ist 0.4.2).
Sicherheit und Mandantenfähigkeit im Kern. Netzwerkrichtlinien zur Mikrosegmentierung, rollenbasierte Zugriffskontrolle für beliebige Ressourcentypen, Admission Control für Objekte. Das Gegenstück zu den Netzwerkrichtlinien ist auf Nomad-Seite Consuls Intentions – also ein separates Produkt unter derselben Lizenz.
Ausgereifte Zustandsschicht. StatefulSet und Operatoren für Datenbanken, Queues und Caches in hochverfügbarer Anordnung. Zusätzlich: Manche für Kubernetes geschriebenen CSI-Treiber funktionieren in Nomad nicht, weil sie plattformspezifische Aufrufe verwenden.
Autoscaling im Kern. Horizontales Autoscaling ist Teil der Control Plane. Der Nomad Autoscaler ist ein separater Daemon und eine separate Binärdatei, und seinen fortgeschrittensten Teil – die automatische Dimensionierung von Anwendungen – gibt es ausschließlich in der Enterprise-Version.
Managed Services und Arbeitsmarkt. Managed Kubernetes bieten alle drei Hyperscaler an, und das CNCF-Konformitätsprogramm umfasst über 90 zertifizierte Angebote; den vollständigen Satz der fünf Kubernetes-Zertifikate der CNCF (Titel Kubestronaut) besitzen über 3.500 Personen in mehr als 100 Ländern. Managed Nomad gibt es bei den Hyperscalern nicht, und Nomad tauchte nicht einmal im Fragebogen der Stack-Overflow-Umfrage 2025 auf – was nicht „null Nutzung“ heißt, aber etwas über die Größenordnung aussagt.

Ist Nomad eine sichere Wahl für fünf Jahre? Lizenz, Eigentümer und das Ende des LTS

Dieser Abschnitt steht gesondert, weil er etwas anderes betrifft als der Rest: nicht das, was das Werkzeug kann, sondern wie lange man einen Plan darauf stützen kann.

Lizenz. Im August 2023 wechselte HashiCorp von MPL 2.0 zur Business Source License 1.1. Nomad steht auf der Liste der betroffenen Produkte, und die BUSL ist keine von der OSI als Open Source anerkannte Lizenz. Die Lizenzdatei im aktuellen Branch nennt als Lizenzgeber die International Business Machines Corporation, legt das Datum des Lizenzwechsels auf vier Jahre nach Veröffentlichung der jeweiligen Version fest, und die Ziellizenz ist MPL 2.0.

Was heißt das in der Praxis? Das Folgende ist eine Lektüre des Lizenztextes, keine Rechtsberatung – und die verbindliche Auslegung des Umfangs der zusätzlichen Erlaubnis legt der Lizenzgeber fest. Aus der Lektüre ergibt sich, dass das Hosten und Nutzen der betroffenen Software für interne Zwecke einer Organisation nicht als konkurrierendes Angebot gilt und die Beschränkung auf das entgeltliche Anbieten von Nomad an Dritte in einer Weise zielt, die mit der kostenpflichtigen Version des Herstellers konkurriert – also auf Szenarien wie „Managed Nomad as a Service“ oder kostenpflichtigen Support, der rund um Nomad selbst verkauft wird. Wo genau diese Grenze in Ihrem Geschäftsmodell verläuft, entscheidet ein Jurist und kein Artikel.

Eine Falle, in die man leicht tappt: Man kann nicht „auf der letzten MPL-Version bleiben“, indem man den Branch 1.6.x wählt. Die letzte unstrittig unter MPL 2.0 stehende Version ist 1.6.3 vom 30. Oktober 2023 – bereits ab 1.6.4 verweisen die Lizenzdateien im Repository auf die BUSL.

Kein Fork unter einer neutralen Stiftung. Terraform bekam OpenTofu, Vault bekam OpenBao. Nomad hat keine Entsprechung. Wenn sich die Bedingungen ändern, ist die Alternative kein Fork, sondern die Migration auf einen anderen Orchestrator – und das ist eine völlig andere Rechnung.

Ein Eigentümer, nach der Übernahme. Die Übernahme von HashiCorp durch IBM wurde am 27. Februar 2025 abgeschlossen. Geändert hat sich unter anderem, dass heute IBM Lizenzgeber ist, die Versionierung auf ein Unternehmensmodell umgestellt wurde und Enterprise-Lizenzen über den IBM-Kanal verkauft werden. Eine Erklärung zur Zukunft der Nomad-Lizenz gibt es nicht – weder zu einer Verschärfung noch zu einer Rückkehr zum offenen Modell. Das ist ein Mangel an Information, und so sollte man ihn auch behandeln.

Der Support-Zyklus – das härteste Argument bei mehrjähriger Planung. Ab Version 2.0 hat Nomad die semantische Versionierung aufgegeben. Die neueste Version ist 2.0.5 vom 13. August 2026. Und das Entscheidende: Der Branch 1.10.x ist der letzte mit dem Etikett Langzeit-Support, und dieser Support endet am 30. April 2027. Die Versionen der Community Edition ab 2.0.0 haben eine zweijährige Patch-Politik, und längere Fenster – erweiterter und dauerhaft erweiterter Support – sind kostenpflichtige Pakete für Enterprise-Kunden.

Wie wählen? Eine Faustregel

Bis etwa zehn Knoten, ein Team, eine Anwendung, vorhersehbarer Verkehr, keine Stelle für die Plattform → Docker Swarm ist keine Schande. Er ist in jeder Dimension günstiger, und ein Cluster, das niemand betreibt, geht schneller kaputt, als Swarm altern kann.
Von gut einem Dutzend bis etwa tausend Knoten, gemischte Workloads – Container, Binärdateien, Java-Anwendungen – und ein kleines Plattformteam → Nomad bietet hier die meisten Möglichkeiten bei der geringsten Zahl zu betreibender Schichten: ein Prozess, der zu aktualisieren ist, statt einer Kette von Komponenten. Bedingung: die bewusste Zustimmung zur BUSL-Lizenz und dazu, dass Sie bei einer ungewöhnlichen Integration häufiger auf „schreib es selbst“ stoßen als auf einen fertigen Operator.
Oberhalb von etwa tausend Knoten, viele voneinander isolierte Teams oder Kunden in einem Cluster, regulatorische Anforderungen, Bedarf an einem Ökosystem und fertigen Operatoren, Einstellungspläne → Kubernetes. Mit einer vollen Stelle für den Plattformbetrieb, nicht mit einem Bruchteil davon.

Und eine Frage, die man vor jeder dieser drei Antworten stellen sollte: Brauchen Ihre Workloads überhaupt Orchestrierung? Eine Anwendung, die seit Jahren ruhig auf einer virtuellen Maschine läuft, bekommt nach dem Umzug in einen Orchestrator vor allem einen neuen Satz an Dingen, die kaputtgehen können. Wie sich die Verantwortlichkeiten zwischen den Cloud-Servicemodellen aufteilen, beschreiben wir im Artikel Cloud als Service: IaaS, PaaS und SaaS an Beispielen, und wohin in der Cloud das Budget entweicht, im Artikel Public Cloud zu einem vernünftigen Preis.

Welchen Orchestrator betreiben Sie in der WebDisk Cloud?

In unserer Public Cloud haben Sie zwei Wege, und beide stehen offen, unabhängig davon, welchen Orchestrator Sie wählen.

Ein verwaltetes Kubernetes-Cluster (WebDisk K8s) – ein Dienst, der Nutzern von WebDisk Cloud zur Verfügung steht; das Cluster bestellen Sie über das Panel, und die auf Apache CloudStack aufgebaute Plattform legt es für Sie an – mit öffentlicher IPv4- und IPv6-Adressierung sowie Skalierung der Knotenzahl. Die Einzelheiten der Netzwerkkonfiguration und den Umfang der automatischen Skalierung legen wir bei der Bestellung fest. Für Teams, die volle Kontrolle wollen, bleibt der Weg eines eigenen Clusters auf IaaS-Infrastruktur: mit dem CloudStack-Provider für Terraform oder mit der Cluster API im vollen Regime „Infrastructure as Code“.

Nomad, Swarm oder etwas ganz anderes auf eigenen Maschinen. Wenn Sie nach der Lektüre dieses Artikels zu dem Schluss kommen, dass Ihrem Team Nomad näher liegt, steht dem nichts im Weg: Sie mieten virtuelle Maschinen und Netzwerk in der Public Cloud von WebDisk, und den Orchestrator installieren und betreiben Sie auf Ihrer Seite – in der Community-Version ohne Gebühren, eine etwaige Enterprise-Lizenz rechnen Sie direkt mit deren Hersteller ab. Wir bieten kein verwaltetes Nomad an und werden das auch nicht versprechen; als Managed Service haben wir Kubernetes, und beim Wechsel von Docker-Swarm-Umgebungen unterstützt unser Team mit Beratung und einem Migrationsplan.

Unabhängig von der Wahl bleibt dieselbe, langweilige Pflichtenliste eines Cluster-Eigentümers: Updates, Sicherungen des Zustands und der Anwendungsdaten, Monitoring und jemand, der den Alarm entgegennimmt. Wie wir die Sicherheitsschichten darunter aufbauen, beschreiben wir im Artikel Wie viele Schichten hat die Sicherheit Ihrer Dateien.

Häufige Fragen

Kann Nomad Kubernetes in Ihrer Organisation ersetzen? Es kann – wenn Sie vor allem einen Task-Scheduler brauchen, gemischte Workloads und ein kleines Plattformteam haben. Es ersetzt Kubernetes dort nicht, wo das Ökosystem an Operatoren, eine ausgereifte Unterstützung zustandsbehafteter Anwendungen, Mikrosegmentierung des Netzwerks im Kern oder die Verfügbarkeit eines Managed Service beim Cloud-Anbieter zählen. Die Frage lautet nicht „welches Werkzeug ist besser“, sondern „wie viel Plattform brauchen Sie wirklich und wer betreibt sie“.

Was genau endet am 30. April 2027? Der Support des Branches Nomad 1.10.x – des letzten, der als langfristig (LTS) gekennzeichnet ist. Nach diesem Datum gelangen Patches, auch Sicherheits-Patches, nicht mehr in diese Linie; man muss auf einen neueren Branch wechseln oder erweiterten Support in der Enterprise-Version kaufen. Neuere Versionen der Community Edition haben eine zweijährige Patch-Politik, aber keine trägt noch das LTS-Etikett.

Wird Docker Swarm noch weiterentwickelt? Der in die Docker-Engine eingebaute Swarm mode – ja: Das Repository moby/swarmkit lebt, und die Releases aus dem Jahr 2026 enthalten Swarm betreffende Korrekturen. Docker hat kein Support-Enddatum angekündigt, erklärt aber auch keine Weiterentwicklung – man schreibt, sie habe sich zugunsten kubernetesbasierter Lösungen verlangsamt. Eingestellt ist dagegen Swarm „classic“, ein eigenständiges Produkt aus dem Jahr 2014, 2021 archiviert.

Braucht Nomad Consul und Vault? Nein – die native Service Discovery genügt für den Start, auch wenn sie kein DNS liefert. Mit Consul kann Nomad wesentlich mehr (Domainnamen, Service Mesh, Netzwerk-Intentions), und Nomad Variables sind kein Ersatz für Vault: Der Hauptverschlüsselungsschlüssel liegt auf den Servern, und der Mechanismus ist für kleine Konfigurationsfragmente vorgesehen.

Womit anfangen, damit ein Nomad-Cluster nicht offen steht? Mit dem Aktivieren der Zugriffskontrolllisten – sie sind standardmäßig deaktiviert und werden mit nomad acl bootstrap initialisiert. Das ist das Erste, was nach dem Aufsetzen der Server zu tun ist, bevor irgendetwas ins Netz gestellt wird. Das Produktionscluster selbst besteht aus drei oder fünf Servern pro Region.

Startet Nomad eine Anwendung, die in keinem Container-Image liegt? Ja – das ist sein Alleinstellungsmerkmal. Der Treiber exec startet eine gewöhnliche Binärdatei in Isolation, java ein JAR-Archiv ohne Image-Build, und exec2 isoliert den Prozess mit nativen Kernel-Mechanismen. Den Treiber virt für vollständige virtuelle Maschinen gibt es, aber der Hersteller kennzeichnet ihn als nicht für den Produktionseinsatz bestimmt.

Fazit

Die Wahl zwischen Swarm, Nomad und Kubernetes ist im Grunde die Antwort auf eine einzige Frage: wie viel Plattform Sie betreiben wollen. Swarm gibt am wenigsten und kostet am wenigsten; Kubernetes gibt am meisten und verlangt am meisten, bietet dafür aber eine neutrale Lizenz, ein Ökosystem und einen Arbeitsmarkt; Nomad steht dazwischen – eine Datei, eine Binärdatei, auch nicht-containerisierte Workloads – zum Preis einer Lizenz, die nicht offen ist, und eines Langzeit-Branches, der im April 2027 endet.

Keine dieser Antworten ist universell besser; schlecht ist nur eine Entscheidung, die ohne Berechnung der Betriebskosten getroffen wird. Schreiben Sie uns – wir helfen, die Varianten unter dem Gesichtspunkt der Betriebskosten zu vergleichen und eine Migration zu planen, und bei Kubernetes-Clustern auch zu prüfen, wie sie betrieben werden.

HashiCorp Nomad, Kubernetes oder Docker Swarm: Welcher Orchestrator passt zu Ihnen – und was kostet der Betrieb?