How do Custom Resource Definitions differ from built-in controllers

Comparing Custom Resource Definitions (CRDs) directly to built-in controllers requires distinguishing between the API Schema (the data structure) and the Control Logic (the reconciliation loop).

A CRD is a definition of a data structure, whereas a built-in controller is the active process that manages data. To make a valid comparison, we must look at how the Built-in Resource + Built-in Controller model differs from the CRD + Custom Controller (Operator) model.

1. The Fundamental Distinction: Logic vs. Schema

Built-in Controllers (The Logic) Built-in controllers are the "brain" functions hard-coded into the Kubernetes control plane. They are compiled into the kube-controller-manager binary,.

• Role: They contain the business logic to manage native resources like Pods, Deployments, and Nodes.
• Behavior: They watch the state of the cluster and continuously drive the current state toward the desired state defined in native API objects,.

Custom Resource Definitions (The Schema) A CRD is strictly an API extension mechanism. It allows you to define a new type of resource (a new "Kind") in the API server, but it does not provide the logic to make that resource do anything.

• Role: It tells the API server how to store and validate a new type of object (e.g., a Database object),.
• Behavior: On its own, a CRD is just a data bucket. If you create a Custom Resource without a controller, the object simply sits in etcd. To make it functional, you must write and deploy a Custom Controller (often called an Operator),.

2. Architectural Differences

The following table breaks down the architectural differences between the native control plane and the extended control plane:

Feature	Built-in Controllers	CRD + Custom Controller
Origin	Part of the core Kubernetes project code. Defined and maintained by the community.	Defined by users or third-party vendors to extend the cluster's capabilities.
Deployment	Compiled into the kube-controller-manager binary. Runs as a single process in the control plane.	The CRD is registered via the API. The Custom Controller usually runs as a separate Deployment (Pod) in the cluster,.
API Availability	Available in every standard Kubernetes installation (e.g., apps/v1).	Must be dynamically registered. Can appear and disappear from a running cluster.
Data Validation	Validation is hard-coded in the API server source code (though moving toward declarative validation).	Validation is defined declaratively using OpenAPI v3 schemas or CEL (Common Expression Language) rules within the CRD manifest,.
Updates	Updated only when the Kubernetes cluster version is upgraded.	Can be updated, patched, or removed independently of the cluster version.

3. The "Operator" Pattern

The true equivalent to a built-in controller in the custom resource world is the Operator. An Operator is a software extension that makes use of CRDs to manage applications and their components.

• Built-in: You create a Deployment (native resource). The DeploymentController (native logic) sees it and creates ReplicaSets.
• Operator: You create a SampleDB (Custom Resource). A custom controller (Operator logic running in a Pod) sees it and creates the necessary StatefulSets, Services, and PersistentVolumes to run the database,.

4. When to use which?

Use Built-in Controllers/Resources when:

• You need standard behaviors like running stateless containers (Deployment), stateful applications (StatefulSet), or batch jobs (Job).
• You want maximum stability and support, as these APIs are subject to strict deprecation policies and are tested with every Kubernetes release.

Use CRDs + Custom Controllers when:

• Domain Specificity: You need to encode specific domain knowledge (like how to backup a MySQL database) into the API.
• Abstraction: You want to provide a higher-level abstraction to developers (e.g., a WebSite resource) that generates complex underlying primitives (Services, Ingress, Deployments) automatically.
• GitOps: You want to store the configuration of third-party infrastructure or applications in the same repository as your Kubernetes manifests.

In summary, built-in controllers represent the core logic of Kubernetes orchestration, while CRDs provide the flexibility to extend the Kubernetes API surface area to store new data types, which are then acted upon by custom controllers.