A Kubernetes Operator is a controller that manages an application or system on Kubernetes using custom operational logic.
Operators extend Kubernetes so it can manage more than basic stateless workloads.
They are commonly used for software that needs lifecycle management, such as databases, message queues, monitoring systems, and storage platforms.
Why operators exist
Kubernetes already knows how to keep generic resources in a desired state.
For example, a Kubernetes Pod can be restarted if it fails, and a Deployment can keep the requested number of replicas running.
Some applications need domain-specific actions that Kubernetes does not understand by default:
- Creating users or schemas
- Running backups
- Restoring from snapshots
- Performing safe upgrades
- Rebalancing cluster members
- Replacing failed nodes
- Managing certificates
An operator encodes this operational knowledge into software.
How it works
Operators usually combine:
- A Custom Resource Definition (CRD), which adds a new Kubernetes API type
- A controller, which watches resources and acts when the actual state differs from the desired state
For example, a database operator might let you create a resource like PostgresCluster.
The operator then creates and manages the Pods, Services, volumes, configuration, backups, and upgrade process needed for that database cluster.
Reconciliation
Operators use a reconciliation loop.
The operator repeatedly compares:
- Desired state: what the Kubernetes resources say should exist
- Actual state: what is currently running
When the two differ, the operator takes actions to move the system closer to the desired state.
This is the same basic control-loop idea used by Kubernetes itself.
Tradeoffs
Operators can reduce manual operational work, but they also add another moving part to the cluster.
Good operators make complex systems easier to run. Poor operators can hide complexity, introduce upgrade risk, or make failure modes harder to debug.