Kubernetes Operator

An Operator is a software extension to Kubernetes that uses custom resources to manage an application and its components, following the same control loop principle as built-in controllers.

How it works

An Operator has two parts: a Custom Resource Definition (CRD) that adds a new object type to the API, and a controller that watches those objects. The controller compares the desired state in the custom resource with the actual state of the cluster, then acts to close the gap. This is called reconciliation, and it repeats continuously.

The pattern captures what a human operator knows about a service: how to deploy it, back it up, upgrade it and react to problems. The Kubernetes documentation lists tasks such as deploying an application on demand, taking and restoring backups, handling upgrades and choosing a leader. The pattern was described by CoreOS. An operator usually runs as a Deployment outside the control plane.

A practical example

The Kubernetes documentation uses a hypothetical SampleDB resource. Creating one makes the operator set up PersistentVolumeClaims, a StatefulSet and a configuration Job. Users then work with the resource directly:

kubectl get SampleDB
kubectl edit SampleDB/example-database

Real operators follow the same shape. The Prometheus Operator, for instance, manages Prometheus instances through custom resources, as in the Prometheus Operator deployment guide.

Common mistakes

• Installing an operator without reviewing its maturity, maintenance and the permissions it requests through RBAC.
• Skipping backups because the operator “handles” them. Test restores yourself.
• Upgrading the operator and the CRDs carelessly. CRD changes affect existing resources.
• Writing a custom operator for something a Helm chart or simple Deployment would handle.
• Ignoring the operator’s own availability and monitoring.

When to use it and when not to

Operators fit stateful or complex systems with significant operational knowledge to automate, such as databases and message brokers. They are less suitable for simple stateless services, where a Helm chart is easier to maintain. If you must write one, the documentation lists frameworks including kubebuilder and the Operator Framework, plus libraries for several languages, so Go is not the only option.

See also

• Kubernetes
• StatefulSet
• ArgoCD
• Helm Chart
• Kubernetes consulting