CRDs and the Operator pattern

WHAT THIS TESTS This checks whether you understand that Kubernetes extensibility reuses its own declarative API and control loop rather than special-casing logic.

A GOOD ANSWER COVERS A Custom Resource Definition registers a brand-new resource type with the kube-apiserver, so you can create, get, and watch objects of a custom Kind, for example a PostgresCluster, with full validation and RBAC, stored in etcd just like built-in objects. By itself a CRD is just schema and storage; it does nothing. The Operator pattern completes it by adding a custom controller that watches those custom resources and runs the same observe-diff-act reconciliation loop the built-in controllers use. The controller encodes domain-specific operational knowledge, how to provision, back up, fail over, and upgrade a complex application, turning a high-level declarative spec into the many lower-level actions a human operator would otherwise perform. This extends the platform to manage stateful systems declaratively without modifying Kubernetes core.

COMMON WRONG ANSWERS Thinking a CRD on its own performs actions. Believing Operators bypass the control loop or run outside Kubernetes conventions. Confusing CRDs with admission webhooks. Assuming you must fork Kubernetes to add behavior.

LIKELY FOLLOW-UPS What does the controller do that the CRD cannot? How does this reuse the reconciliation pattern? What is the difference from a Helm chart? How are custom resources validated?

ONE CONCRETE EXAMPLE A database Operator defines a PostgresCluster CRD. A user applies a manifest declaring three replicas with daily backups. The Operator's controller observes the new resource, then creates a StatefulSet, Services, and Secrets, configures replication, and schedules backups. If a replica fails or the user edits the spec to five replicas, the controller reconciles by adjusting the underlying objects, exactly mirroring how built-in controllers drive desired state.