4 min read

Nomad vs Kubernetes: An Honest Comparison After Running Both

I've run workloads on both. Here's what the benchmarks don't tell you — operational complexity, failure modes, and when each one is actually the right choice.

infrastructure nomad systems

There’s a genre of “Kubernetes vs Nomad” post that goes: Nomad is simpler, Kubernetes is more powerful, choose based on team size. That advice is true as far as it goes. But after running both in anger — Kubernetes at a previous job, Nomad for my own infrastructure — I want to give you something more concrete.

What Nomad actually is

Nomad is a workload orchestrator. It schedules jobs onto nodes. A job can be a Docker container, a raw binary, a Java JAR, a QEMU VM, or a batch process. That’s it.

Networking, service discovery, secrets management, and observability are not Nomad’s problem. You wire those in yourself, typically:

  • Consul for service discovery and health checking
  • Vault for secrets
  • Traefik or Fabio for ingress
  • Prometheus + Grafana for metrics

The HashiCorp stack is designed to work together, but each piece is optional. You can use Nomad with a third-party secrets manager or without a service mesh.

Kubernetes bundles analogues to all of these inside one API surface. That’s both its strength and the source of most of its operational pain.

The job file vs the YAML labyrinth

Here’s a Nomad job file for a simple HTTP service:

jobs/blog.nomadhcl
job "blog" {
  datacenters = ["dc1"]
  type        = "service"

  group "web" {
    count = 2

    network {
      port "http" { to = 8080 }
    }

    service {
      name = "blog"
      port = "http"
      check {
        type     = "http"
        path     = "/"
        interval = "10s"
        timeout  = "2s"
      }
    }

    task "server" {
      driver = "docker"
      config {
        image = "patrickchodev/blog:latest"
        ports = ["http"]
      }
      resources {
        cpu    = 256
        memory = 128
      }
    }
  }
}

The equivalent Kubernetes setup is a Deployment + Service + (optionally) an Ingress + a HorizontalPodAutoscaler. Each is a separate YAML file. The Deployment alone is ~40 lines of YAML before you add resource limits, probes, and environment variables.

I’m not dunking on Kubernetes YAML — you get used to it, and tools like Helm exist for a reason. But the Nomad job file’s compactness is genuinely nice for small-to-medium setups.

Where Kubernetes is objectively better

Ecosystem. The Kubernetes ecosystem in 2025 is enormous. Cert-manager, ExternalDNS, Argo CD, Crossplane, Karpenter, KEDA — if you need something, there’s a Kubernetes operator for it. Nomad’s ecosystem is real but smaller.

Stateful workloads. StatefulSets + PersistentVolumeClaims + CSI drivers give you a fairly robust story for running databases on Kubernetes. Nomad has CSI support but the operational experience is noticeably rougher at the edges.

Multi-cluster and multi-cloud. Tools like Flux, Argo CD, and Cluster API are mature. Nomad’s federation story is functional but less polished.

RBAC and multi-tenancy. Kubernetes namespaces with RBAC give you reasonably strong isolation for multi-tenant environments. Nomad namespaces exist but are less granular.

Where Nomad is objectively better

Operational simplicity. A Nomad cluster is three or five nomad server processes and N client agents. That’s it. No etcd to operate separately, no controller-manager, no scheduler, no API server, no cloud-controller-manager. When something goes wrong, the blast radius is smaller and the failure mode is more legible.

Non-container workloads. If you need to schedule bare binaries, raw systemd units, or QEMU VMs alongside Docker containers in the same cluster, Nomad handles this natively. Kubernetes is container-only by design (yes, KubeVirt exists, but it’s a whole additional system).

Resource efficiency. A production-ready Kubernetes control plane needs ~3 masters × ~4 CPU / 8 GB RAM. A Nomad server cluster needs ~3 servers × ~0.5 CPU / 512 MB RAM. For small teams running their own infrastructure, this is a real cost difference.

Upgrade experience. Nomad rolling upgrades are straightforward. Kubernetes minor-version upgrades have historically been anxiety-inducing, especially with managed providers that lag behind upstream. This has improved but the reputation is earned.

My actual setup

For this blog and my personal projects, I run a 3-node Nomad + Consul cluster on three small VMs. Total cost: ~$18/month. The whole thing is defined in ~600 lines of HCL and Terraform.

The job file for this blog deploys with:

nomad job run jobs/blog.nomad

Rolling deployments, health checks, automatic restarts on failure — all included. If I pushed a broken image, Nomad would detect the health check failure and roll back within 30 seconds.

When to choose which

Choose Kubernetes if:

  • Your team already knows it
  • You need a mature operator ecosystem (cert-manager, Argo CD, etc.)
  • You’re deploying on managed Kubernetes (EKS, GKE, AKS) and don’t want to operate the control plane
  • You have genuinely complex stateful workload requirements

Choose Nomad if:

  • You operate your own infrastructure and want to minimise control-plane complexity
  • You need to schedule non-container workloads
  • Your team is small (< 10 engineers) and Kubernetes’ API surface is more overhead than value
  • You’re already in the HashiCorp ecosystem (Vault, Consul, Terraform)

The honest answer is that Kubernetes has won the market and the tooling ecosystem reflects that. If you’re joining a new team or starting a company that might scale, defaulting to Kubernetes is the pragmatic choice.

But if you’re a solo developer or a small team who actually has to operate the thing — Nomad is a serious contender, and it’s worth at least one afternoon of experimentation.

By PatrickChoDev

You might also like