Operational knowledge as code
An Operator is the combination of a CRD and a custom Controller. The term was coined by CoreOS in 2016 to describe the pattern of encoding human operational expertise into software that runs inside the cluster.
- The CRD defines the desired state for a complex application — for example, "I want a 3-node Postgres cluster running version 15.3 with 50Gi of storage."
- The Custom Controller is a piece of software (usually running as a Deployment inside the cluster) that watches for objects of that CRD type and knows how to make that desire a reality.
The controller runs a continuous reconciliation loop, identical in structure to the built-in Deployment or ReplicaSet controllers. On every iteration, it asks: "What does the user want? What does the cluster currently have? What do I need to do to close the gap?"
A mature Operator encodes the operational knowledge of an experienced site reliability engineer: how to take a consistent backup, how to promote a replica when the primary fails, how to perform a rolling upgrade without losing data. That knowledge, which previously lived in runbooks and the heads of senior engineers, becomes automated, testable, and version-controlled software.
What a custom resource looks like in practice
Once the Operator is installed, a developer can provision a full database cluster with a simple Database object — just the engine version, storage size, replica count, and a reference to a credentials Secret. The Operator's controller sees this object appear, reads the spec, and then creates the necessary StatefulSets, Services, PersistentVolumeClaims, and ConfigMaps to bring that database cluster to life. The developer never had to know any of those details.