Operator Pattern

The Operator pattern extends Kubernetes to manage complex, application-specific operations automatically. An Operator captures the knowledge a human administrator would use to run a piece of software, such as a database, and packages it as software that runs inside the cluster.

How It Works

An Operator combines two elements: a Custom Resource Definition (CRD), which adds a new resource type to the Kubernetes API (for example, a PostgresCluster), and a custom controller that watches those resources. The controller runs a continuous reconciliation loop: it observes the desired state declared in the custom resource, compares it with the actual state, and takes actions to converge them.

This lets an Operator handle day-two operations that generic controllers cannot: provisioning, configuration, version upgrades, scaling, backups, restores, and failover. Operators often manage StatefulSets, Services, and Secrets on the user's behalf.

Why It Matters

Stateful and clustered systems carry deep operational complexity that simple manifests or a Helm chart cannot fully express. The Operator pattern automates this expertise, reducing manual toil and the risk of human error during sensitive operations like upgrades or recovery.

This pattern is the foundation of much of the Kubernetes ecosystem; managed databases, message queues, and observability stacks are commonly delivered as Operators. The trade-off is that an Operator is itself software that must be trusted, maintained, and secured.

Related Terms

An Operator runs custom controllers on the control plane, often manages StatefulSets and Deployments, and complements a Helm chart for application lifecycle management.