Use kubectl when…
- A small set of operators owns submission and debugging.
- Users are comfortable with kubeconfig, RBAC, and Job manifests.
- You do not need a shared HTTP API, portal, or tenant-facing lifecycle UI.
- Policy can live entirely in cluster RBAC and admission webhooks you already trust.
In that world, kubectl (and GitOps applying the same objects) is simpler than introducing another control plane. Adding Hammrly would be ceremony.
kubectl stops being enough when…
- Many tenants need to submit work without receiving broad cluster credentials.
- You want a stable application API (JWT, OpenAPI, status URLs)—not “here is a YAML template.”
- Interactive sessions and batch Jobs should share one authenticated path and one audit-friendly lifecycle.
- Fair sharing and queueing belong in Kueue, but humans still need a front door that does not require kube APIs.
Giving every researcher a kubeconfig that can create Jobs is operationally expensive: credential
sprawl, accidental privilege, and a support surface that is the Kubernetes API itself. That is a
platform problem, not a missing alias for kubectl apply.
How Hammrly relates
Hammrly keeps kubectl where it belongs—with operators—while tenants talk to a gateway and query API. The cluster still runs Jobs; users do not need to speak Kubernetes to request capacity.
kubectl is the right screwdriver. It is the wrong self-service desk.