Kubernetes operators: what the model is and why it matters now
What the operator pattern in Kubernetes is, why it has become the central way to manage complex applications in a cluster, and what that means for architecture.
Kubernetes went from "an interesting Google experiment" to the de facto standard for container orchestration in roughly three years. But if you ask most managers what actually runs inside a cluster and why engineers argue about "operators" - there is no answer. That is fine: implementation details do not have to live in everyone's head. The operator model, though, is not an implementation detail. It is an architectural decision with organisational consequences.
I am writing this short explanation because in recent months conversations about Kubernetes in client projects keep running into exactly this question.
What an operator is
Kubernetes manages standard primitives well: run a container, restart on failure, distribute traffic. But many applications - databases, queues, distributed storage systems - have state, scaling logic, and maintenance procedures that do not fit into those standard primitives.
An operator is a program that extends Kubernetes with custom management logic for a specific application. It works as a controller: it watches the desired state, compares it to the real state, and takes actions to align them. The difference from simply "running a container" is that an operator understands the semantics of the application - what "backup," "failover," and "rolling upgrade" mean for that particular product.
Why this matters for architectural decisions
When a team decides to deploy something like Kafka or PostgreSQL inside a Kubernetes cluster, the next question is how to manage its lifecycle. Without an operator, that means manual work or a collection of scripts. With an operator, it means declarative configuration that the cluster applies on its own.
That changes several things at once:
- Operational load. The operator handles routine tasks that would otherwise require an on-call engineer with knowledge of that specific application.
- Reproducibility. Infrastructure is described in code rather than in wiki instructions that go stale.
- Dependency on third-party solutions. Operators are written by vendors, communities, and teams themselves. Quality varies considerably.
What this means for the team
Moving to the operator model is not just a technical choice. It is a decision about who maintains the infrastructure and how. If the team does not have people who understand both Kubernetes and the specific application, an operator can become a black box that nobody knows how to repair.
I have seen projects where operators cut operational load in half. I have also seen projects where they created a new class of incidents because nobody read what the operator does to data during a version upgrade.
OperatorHub is a useful entry point
Since late 2018, OperatorHub.io has been running as a catalogue of operators for popular applications. It is a useful starting point to understand what already exists and how mature the available solutions are.
Before choosing an operator, I recommend answering three questions: who maintains it, how it handles upgrades that could cause data loss, and whether someone on the team can read its source code when needed.
In short
The operator model is the answer to "how do I manage a complex stateful application inside Kubernetes." It is a sound architectural idea with real operational consequences. The right time to adopt it is when the team actually understands what is inside - not because "everyone is doing it."