If you've ever felt that Kubebuilder and the operator-framework were overkill for what you actually needed — a straightforward controller that watches some resources and reacts — you're not alone. That frustration has been quietly simmering in the Go community for years, and it's exactly the gap that spotahome/kooper tries to fill.
With 544 stars and a recent commit pushing support for Kubernetes 1.36, Kooper isn't trending in the viral sense. But if you're in the market for a lightweight operator framework, it's worth your time to understand what it actually offers — and what it doesn't.
What it actually does
Kooper is a Go library that gives you the scaffolding to build Kubernetes controllers and operators. At its core, the model is deliberately simple: a Retriever lists and watches resources, a Handler processes events, and a Controller wires them together into a feedback loop. That's it. There's no code generation, no opinionated project structure, no admission webhook scaffolding. Kooper doesn't try to be your entire platform — it just handles the controller loop so you don't have to reinvent it every time.
The library ships with built-in support for Prometheus metrics, optional leader election, and helpers for working with standard Kubernetes resources and CRDs. The v2 release (which you should be using — import it as github.com/spotahome/kooper/v2) was a ground-up simplification. The old v0 had separate concepts for operators and controllers; v2 collapses them into one thing. CRD management was moved outside the library entirely. The Delete event was removed because it wasn't reliable. These are decisions that prioritize correctness over feature density, and they show.
Why it matters right now
The operator ecosystem is dominated by two heavyweights: Kubebuilder (backed by Google) and the operator-framework (Red Hat). Both are powerful. Both come with opinionated conventions, generated code, and enough boilerplate to make you feel like you're building a framework instead of an application. For teams that need admission webhooks, RBAC manifest generation, and CRD clients auto-generated — those tools are excellent.
But not every team needs all of that. If you're building a controller that watches deployments and syncs state to an external system, you don't need Kubebuilder's entire opinionated stack. Kooper occupies the space between "writing a controller from scratch with the client-go library" and "committing to a full framework." It's the Go-router-to-Rails analogy applied to Kubernetes tooling: small composable components, not a monolithic framework.
The timing matters too. Kubernetes is shipping new versions fast — 1.33, 1.35, 1.36 in the last year alone. Many small libraries get left behind when dependencies shift. Kooper's maintainer has been keeping up, which signals commitment even if the contributor base is thin.
What stands out
A few things genuinely impressed me about Kooper:
-
The Retriever/Handler pattern is clean. You define how to list and watch resources, define what happens when events fire, and the controller handles the rest. It's easy to explain to a new team member. The example in the README — a controller that logs pod events — is under 30 lines of meaningful code.
-
Middleware-friendly interfaces. Both
RetrieverandHandlerare interfaces, which means you can wrap them with metrics, logging, or custom behavior using the decorator pattern. This is the kind of extensibility that doesn't require plugins or complex configuration. -
Metrics are built in but not forced. Prometheus integration comes out of the box, but you're not locked into it. If you prefer a different metrics backend, the interface lets you swap it.
-
Leader election is optional. You can run multiple replicas of your controller without worrying about split-brain scenarios, but you're not forced into it if you don't need it.
-
It keeps Kubernetes compatibility current. The maintainer added support for k8s 1.33, 1.35, and 1.36 within the last year. For a solo-maintained project, that's a real signal.
Who should use it — and who shouldn't
You should consider Kooper if: you're building a focused controller or operator, you prefer Go's philosophy of small composable tools over opinionated frameworks, you want to avoid the code-generation overhead of Kubebuilder, and you're comfortable making your own decisions about CRD management, RBAC, and admission webhooks.
You should not use Kooper if: you need a full-featured operator ecosystem with auto-generated CRD clients, admission webhooks, and RBAC manifests out of the box. If your team relies heavily on those conventions, Kubebuilder or operator-sdk will save you more time than Kooper will. Also, if you need a large community behind your dependency — Kooper has one primary maintainer. That's not a dealbreaker, but it's a fact.
The honest concerns
Let me be direct. The biggest concern with Kooper is its contributor base. Slok has 297 commits out of 350 total. This is essentially a one-person project. The library works well today, the maintainer is responsive, and the recent commits show active development — but if that person burns out or moves on, the project's trajectory could stall. The 544-star count suggests it's not widely adopted enough to attract a large contingent of contributors organically.
The 9 open issues are manageable, but there's no visible community governance or contribution guide that suggests a path for new maintainers to emerge. The go.mod file listing Go 1.26.0 is also a bit unusual — that version doesn't exist yet, which could indicate the module path or tooling setup needs attention.
There's also the question of whether the "simplicity over optimization" philosophy will hold up at scale. Kooper gives each controller its own internal resource cache rather than sharing one. That's great for correctness and debugging, but it could become a performance concern if you're running dozens of controllers in a single process. Something to benchmark before committing.
The verdict
Kooper is a solid, well-maintained library for teams that want to build Kubernetes controllers without the weight of Kubebuilder. It does what it promises — nothing more, nothing less. The code is readable, the API is small, and the examples are practical.
I'd recommend it for: greenfield projects where you want control over your stack, teams already comfortable with Kubernetes internals, and anyone who's been burned by framework overhead before. I'd hesitate to recommend it for: teams that need a broad operator ecosystem or who are uncomfortable with single-maintainer dependencies.
If you're evaluating it, clone the repo, run the examples, and try building a small controller. It'll take less time than setting up a Kubebuilder project, and you'll know within an hour whether it fits your workflow.
Repository: github.com/spotahome/kooper