You have three services and a team of two engineers and you chose Kubernetes. That decision will cost you more than you expect — not in dollars, but in operational drag that compounds every week.
This is not an argument that Kubernetes is bad. It is an argument that it is frequently the wrong tool for the scale at which it gets adopted, and that Nomad deserves serious consideration before you commit to the K8s complexity budget.
What Kubernetes Actually Is
Kubernetes is an operating system for distributed infrastructure. It gives you a rich, extensible platform with its own resource model, API, networking layer, storage abstraction, RBAC system, admission control, custom resource definitions, and an ecosystem of controllers that extend it in every direction.
That richness is valuable at scale. A platform engineering team managing hundreds of services across multiple clusters needs exactly what Kubernetes provides. The control plane’s complexity is a reasonable price for the capability it unlocks.
For a team of two running five services on three nodes, it is paying a tax that buys nothing.
The control plane alone requires at least three nodes for high availability. Add etcd, the API server, the scheduler, the controller manager, CoreDNS, kube-proxy, a CNI plugin, a CSI driver, and an ingress controller — and you have a substantial operational surface area before you have deployed a single application workload.
What Nomad Actually Is
Nomad is a workload scheduler. You tell it what to run, how many instances to run, what resources to allocate, and where constraints apply. It handles placement, rescheduling on failure, rolling updates, and health checking. That is the core of what most teams actually need from an orchestrator.
The architecture is a single binary. Clients and servers run the same binary with different configuration. High availability uses embedded Raft consensus — three server nodes is sufficient and recommended, but a single-server setup works fine for development and small production deployments.
There is no separate control plane to manage. No etcd cluster to operate. No CNI plugin selection to agonize over. The operational surface area is dramatically smaller.
Where Each Tool Wins
Kubernetes is the right call when you have a dedicated platform engineering team whose job is the infrastructure itself, when you are running 50 or more services that need fine-grained placement and scheduling, when you are on a managed control plane like EKS, GKE, or AKS where the operational complexity is someone else’s problem, or when you need specific ecosystem integrations — Istio for service mesh, ArgoCD for GitOps, Crossplane for infrastructure provisioning — that are built for the Kubernetes resource model.
Nomad is the right call when your team is one to five engineers who need to ship product, not manage infrastructure, when you are running fewer than 20 services, when your workloads are mixed — some containerized, some legacy binaries, some virtual machines — when you are self-hosting on Proxmox, bare metal, or a small cloud environment, or when you want zero-downtime rolling deploys without a YAML engineering practice.
The Multi-Runtime Advantage
One underappreciated capability of Nomad is genuine multi-runtime support. The task driver model allows Nomad to schedule Docker containers, containerd workloads, QEMU virtual machines, raw binaries via exec, and Java applications via the Java driver — all through the same scheduler and job specification format.
Kubernetes schedules containers. If you have workloads that are not containerized — legacy applications, GPU workloads that run better in VMs, or services that require direct hardware access — you either containerize them or you manage them outside Kubernetes entirely.
Nomad handles the mixed case natively. A single Nomad cluster can run your containerized API alongside a VM-based database alongside a raw binary data processor, all scheduled and monitored through the same interface.
The ry-ops Setup
ry-ops runs on Nomad deployed on Proxmox virtual machines. The Nomad server is a single binary running on three lightweight VMs for HA. Application workloads run as Docker containers scheduled by Nomad. Consul handles service discovery and health checking.
Setup from scratch took an afternoon. The ongoing operational overhead is close to zero. There is no control plane to patch, no CNI plugin version to track, no webhook admission configuration to maintain.
This setup would not scale to hundreds of services or a large engineering organization. It is not designed to. It is designed to run the actual workloads that ry-ops needs to run, with the minimum infrastructure complexity required to do so reliably.
The Principle
Complexity is a debt you pay every day. Every abstraction layer you adopt has a carrying cost in operational knowledge, upgrade cycles, debugging surface area, and cognitive overhead for every engineer who touches the system.
Kubernetes is worth that cost at the scale it was designed for. At small scale, you pay the debt without collecting the return.
Evaluate your actual requirements before adopting the industry default. How many services are you running? What is your team size? Do you have mixed workload types? Do you need the Kubernetes ecosystem specifically, or do you need reliable workload orchestration?
If the answer to that last question is the latter, Nomad is worth the hour it takes to stand up a test cluster and see how it feels.
Frequently Asked Questions
How many servers does Nomad require for high availability compared to Kubernetes?
Nomad achieves high availability with three server nodes using embedded Raft consensus, and can even run on a single server for non-critical workloads. Kubernetes requires at least three control plane nodes plus separate etcd nodes, a CNI plugin, CoreDNS, kube-proxy, and an ingress controller before any application workload is deployed.
What does Nomad not provide that Kubernetes does?
Nomad does not include built-in service mesh, pod-level networking abstractions, native persistent volume management, or the rich ecosystem of Custom Resource Definitions (CRDs) and controllers that Kubernetes offers. Teams needing those capabilities at scale should treat Kubernetes complexity as a justified cost rather than overhead.
At what team or service scale does Kubernetes become the right choice over Nomad?
Kubernetes becomes the justifiable default when a platform engineering team manages hundreds of services across multiple clusters, where the extensibility of CRDs, RBAC granularity, and a large controller ecosystem offset the control plane’s operational cost. For teams of two running five services on three nodes, that complexity budget buys nothing.
Can Nomad and Kubernetes be used together in the same infrastructure?
Yes — Nomad can coexist with Kubernetes in a mixed environment, often scheduling non-containerized workloads (batch jobs, binaries, Java applications) alongside clusters where Kubernetes manages containerized services. This hybrid approach lets teams apply the right scheduler to each workload type rather than forcing everything into K8s.
