// the find
kudobuilder/kudo
Kubernetes Universal Declarative Operator (KUDO)
KUDO lets you write Kubernetes operators in YAML instead of Go, using a plan/task/step model to describe deploy, upgrade, backup, and restore workflows declaratively. It was designed for stateful workloads like Kafka and ZooKeeper where operator logic maps cleanly to sequential phases. D2iQ backed it as an alternative to the operator-sdk ecosystem.
The plan/step/task model is a genuinely good fit for stateful app lifecycle management — deploy, upgrade, rollback, and backup map naturally to named plans with ordered steps, which is cleaner than hand-rolling the same state machine in Go. The package manager and kubectl plugin make distributing and installing operators feel like a first-class workflow, not an afterthought. The KEP process (30+ design docs in /keps) shows real engineering discipline — the feature decisions are documented and reasoned, not just accumulated. The diagnostics bundle command that collects cluster state for debugging is exactly the kind of operational tooling most operator projects never bother to ship.
The project is functionally dead — last commit August 2023, no releases since then, and D2iQ has clearly moved on. Adopting this today means owning it yourself. The 'no code' promise collapses quickly: templates are Go templates, and any operator logic beyond the happy path ends up as complex template expressions that are harder to debug than actual Go code. The model has no answer for operators that need to react to external state, watch arbitrary resources, or implement admission webhooks — you hit the ceiling fast and there's no escape hatch short of forking the controller. Operator Framework / controller-runtime has won the ecosystem battle decisively; the tooling, community answers, and compatible libraries all assume that stack, not KUDO.