Kubernetes Operator

Updated October 6, 20263 min read

In short

A Kubernetes operator is a custom controller that runs in the cluster and manages a complex application, such as a database, the way a human expert would.

What is a Kubernetes operator?

Kubernetes knows how to keep generic things running, such as three copies of a pod, but not how to run a particular database: how to set up replication, take backups, upgrade without losing data or promote a replica when the primary fails. An operator packages that knowledge as software. The pattern was introduced by CoreOS in 2016, and today there are operators for PostgreSQL, Kafka, Elasticsearch, Prometheus and many other systems.

An operator has two parts. A custom resource definition (CRD) adds a new kind of object to the Kubernetes API, for example a PostgreSQL cluster, which users create with YAML like any built-in object. A controller, a program running in the cluster, watches those objects and runs a reconciliation loop: it compares the desired state in each object's spec with what actually exists, takes steps to close the gap, such as creating pods, volumes and services or starting a failover, and writes the result to the object's status.

An operator is like a specialist who lives in the cluster and never sleeps: you say what you want, such as a three-node database with daily backups, and it does the routine work a database administrator would otherwise do by hand. Operators are usually written in Go with Kubebuilder or the Operator SDK, both built on the controller-runtime library, and frameworks exist for Java, Python and other languages. OperatorHub.io lists many published operators.

Operators are often confused with Helm charts. A Helm chart templates and installs a set of Kubernetes objects, which covers day one, the installation; an operator keeps running afterwards and handles day two, the ongoing work of upgrades, backups, scaling and recovery from failures. The two are often combined, since many operators are themselves installed with a Helm chart. Every operator is a controller, but not every controller is an operator: the name is used for controllers that manage one specific application through custom resources.

Key takeaways

An operator turns the operational knowledge for one application into software.
It combines a custom resource definition with a controller running in the cluster.
The controller's reconciliation loop moves the actual state towards the desired state.
Operators handle day-two work: upgrades, backups, scaling and failover.
Helm installs an application; an operator keeps managing it.

Example

Asking an operator for a PostgreSQL clusteryaml

# A custom resource: the CloudNativePG operator turns it into a PostgreSQL cluster
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: orders-db
spec:
  instances: 3      # one primary and two replicas; the operator handles failover
  storage:
    size: 20Gi

# kubectl apply -f orders-db.yaml
# kubectl get cluster orders-db   -> status reported by the operator

Readers ask

What is the difference between a Kubernetes operator and a Helm chart?

A Helm chart installs or upgrades a set of Kubernetes objects when you run it. An operator runs continuously in the cluster and keeps managing the application, reacting to failures and handling tasks such as backups and version upgrades.

Do I need to write my own operator?

Usually not. Mature operators exist for most popular databases, message brokers and monitoring tools. Writing one makes sense when a team runs its own complex, stateful software on Kubernetes and wants to automate how it is operated.

What is a custom resource in Kubernetes?

An object of a type that isn't built into Kubernetes, added to the API by a custom resource definition. Once the definition is installed, you can create, list and delete these objects with kubectl, just like pods or deployments.

Sources

Spotted a mistake or something missing on this page?Suggest an edit