K8s vs Nomad

Orchestration.

Overview

Kubernetes and Nomad are the two leading container orchestrators, optimising for different things. Kubernetes brings feature breadth (huge ecosystem, every cloud, every CRD anyone could want); Nomad brings simpler operation (single binary, mixed workload support, lower operational overhead). The right answer depends on whether feature breadth or operational simplicity dominates the team's constraints.

• Kubernetes: feature breadth. Massive ecosystem, every cloud, CRDs and operators for every common system. Default for organisations that need any feature anyone has built.
• Nomad: simpler operation. Single binary, mixed workloads (containers, VMs, raw exec, Java), lower operational overhead. Default for smaller teams that do not need every Kubernetes feature.
• Operational fit per team. Existing tooling and team Kubernetes expertise bias the choice. Kubernetes muscle transfers from prior production work; Nomad muscle transfers from HashiCorp-heavy stacks.
• Per-cluster choice. Different workloads may pick differently. Document the rationale per cluster rather than enforcing one orchestrator across all of them.

The approach

Workload-driven choice, per-team operational fit considered, documented rationale per cluster. The discipline is making the orchestrator choice once with a written reason rather than re-deriving it per cluster owner.

• Workload-driven. Orchestrator per workload. Reality drives the answer.
• Kubernetes for feature breadth. Workloads that need service mesh, GitOps operators, or specific CRDs. Default for orgs already invested in the ecosystem.
• Nomad for simpler ops. Smaller teams, mixed workloads, HashiCorp-stack alignment. Default when operational simplicity dominates.
• Operational fit plus documented rationale. Team workflow considered; per-cluster rationale captured. Future migrations have a paper trail.

Why this compounds

The right orchestrator choice compounds across years. Cluster patterns and team expertise align with the orchestrator; cross-cluster tooling (deploy automation, observability, secrets) gets built once and reused. By year two the orchestrator choice is automatic per workload.

• Better operational fit. Orchestrator matches team. Velocity stays high.
• Workload-driven decisions. Replaces tribal preference with documented rationale. Quality of choice improves.
• Better operational reliability. Right orchestrator means the team operates it confidently. Incident MTTR drops.
• Year-one investment, year-two habit. First orchestrator choice is the investment; subsequent clusters inherit the patterns.