CRDs and the Operator pattern
extending Kubernetes declaratively.
CRDs add new API object types, an Operator pairs a CRD with a controller that runs a reconciliation loop encoding domain operational knowledge.
What's really being asked
This checks whether you understand that Kubernetes extensibility reuses its own declarative API and control loop rather than special-casing logic.
The full answer
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.
The mistakes people make
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.
What usually comes next
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?
A 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.
Interview question
Why is a CRD alone insufficient to manage a complex application like a database?
- a.A CRD automatically provisions storage by default
- b.A CRD only defines and stores a new resource type; a controller is needed to act on it via a reconciliation loopCorrect
- c.CRDs cannot be stored in etcd
- d.CRDs are deprecated in modern Kubernetes
Why? this is the answer
A CRD adds schema and storage but takes no action; the Operator's controller watches the resource and reconciles real objects. CRDs are stored in etcd (C) and remain fully supported (D).
Just read this? Test yourself on what you have been reading.
Read the original → kubernetes.io
- #kubernetes
- #crd
- #operator
- #controllers
- #extensibility
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on kubernetes — each one lists the topics its interview covers.
See open roles