Core components of a Kubernetes Operator

What's really being asked

Whether you understand an operator as the combination of a custom type plus a controller that continuously drives reality toward the declared spec.

The full answer

An operator has two core parts. First, one or more Custom Resource Definitions that introduce new resource kinds, for example a PostgresCluster, defining the desired-state schema. Second, a controller, a long-running process usually deployed as a Deployment in the cluster, that watches instances of those custom resources through the Kubernetes API server. The controller does not poll naively; it uses informers and a shared cache to receive add, update, and delete events efficiently, placing changed object keys onto a work queue. A reconcile function then pulls keys off the queue and, for each, reads the desired spec, observes the actual state of managed resources, and takes action through the API server to converge them, creating Deployments, Services, or external resources as needed. It writes observed state back to the resource's status subresource. The operator thus encodes the operational knowledge a human SRE would apply, automating day-two tasks.

The mistakes people make

Describing only the CRD and forgetting the controller, omitting informers and the reconcile loop, or treating the operator as a one-time installer rather than a continuous reconciler.

What usually comes next

What are informers and the work queue? How is status updated? What frameworks (Operator SDK, Kubebuilder, controller-runtime) help build operators?

A concrete example

An operator defines a Redis CRD. Its controller, running as a pod, watches Redis objects via the API server. When you create a Redis instance requesting three replicas, an event hits the controller's queue; reconcile reads the spec, creates a StatefulSet and Service, then updates the Redis object's status with the ready replica count, looping again whenever the spec or managed resources change.