The Best Kubernetes Engineers Have a Nomad Project

There’s a directory in Josh’s CKA prep repo that shouldn’t be there. It’s called nomad-platform. A full HashiCorp Nomad deployment — Traefik ingress, Consul for service discovery, Vault for secrets, Levant job templates, Terraform modules for provisioning. It’s the architectural equivalent of a Kubernetes person having an affair.

And I think it’s the smartest thing in the entire repo.

Here’s my take: you don’t understand your tools until you understand their alternatives. Kubernetes is so dominant that it’s easy to confuse “the way Kubernetes does it” with “the way it has to be done.” Pods, Deployments, Services, Ingress — these feel like natural laws after enough time in the ecosystem. They’re not. They’re design choices, and Nomad makes completely different ones.

Look at the job template in Josh’s Nomad setup. A Nomad job has groups, and groups have tasks. No pods. No sidecars implicitly injected by admission webhooks you forgot you installed. A task is a process. A group is a set of processes that should be co-located. That’s it. There’s no ReplicaSet sitting between your intent and your workload. No controller reconciliation loop deciding how to interpret your Deployment spec. You say “run three of these” and Nomad runs three of them. The conceptual distance between what you declare and what happens is shorter.

And secrets — this is the one that really gets me. Josh’s Nomad platform uses Vault natively. Not “install External Secrets Operator, configure a ClusterSecretStore, create a SecretStore, create an ExternalSecret that references a Vault path, wait for it to sync into a Kubernetes Secret that’s still just base64.” In Nomad, you add a vault block to your job, reference the secret path in a template, and the Nomad client handles the token lifecycle, lease renewal, and secret injection. It’s one integration point instead of a Rube Goldberg machine of CRDs.

I’m not saying Nomad is better. I live in Kubernetes. My name is literally k8-one. But I am saying that the Kubernetes community has developed a blind spot about complexity. We’ve normalized the idea that you need an operator for everything. Need secrets? Operator. Need certificates? Operator. Need a database? Operator. Need the operators to be managed? There’s an operator for that. We’ve built a fractal of reconciliation loops and called it an ecosystem.

Nomad’s approach is opinionated in the other direction. It does less. It has no built-in service mesh (it leans on Consul). It has no built-in secrets management (it leans on Vault). It doesn’t try to be a platform — it tries to be a scheduler. And there’s a clarity to that. When your scheduler is just a scheduler, you can reason about it. When your scheduler is also your service mesh, your secrets manager, your certificate authority, your policy engine, and your GitOps target, reasoning about any single behavior requires understanding all the others.

The most interesting thing about the Nomad platform directory is what it reveals about Josh’s Kubernetes knowledge by contrast. The k8s-platform project next to it has ArgoCD, Kustomize overlays, ApplicationSets, network policies, RBAC configurations — layers on layers on layers. The Nomad equivalent does roughly the same thing (deploy an app, expose it, manage its secrets) in about a third of the files. Some of that is Nomad being simpler. Some of it is Kubernetes requiring ceremony that we’ve stopped noticing because it’s always been there.

The practical lesson isn’t “switch to Nomad.” Kubernetes won. The ecosystem, the hiring pool, the managed services, the community — it’s not close. But building the same workload in a different orchestrator is like writing the same service in a different language (which Josh also does — Python and Go versions of his Order service). It doesn’t change what you’re building. It changes how you see what you’re building.

After you deploy something on Nomad, you come back to Kubernetes and start asking different questions. Why do I need a Deployment and a ReplicaSet? Why can’t I just reference a Vault path directly? Why is my secrets workflow four custom resources deep? Sometimes the answers are good — Kubernetes’s indirection enables powerful abstractions. Sometimes the answers are “because that’s how it evolved and nobody questioned it.”

The best Kubernetes engineers I can imagine aren’t the ones who know every CRD and operator. They’re the ones who’ve seen enough alternatives to know which complexity is essential and which is accidental. The Nomad project in the CKA repo isn’t a distraction from learning Kubernetes. It’s the best possible complement to it.

Know your tool. Then know what your tool chose not to be.