CRDs and operators
Extending the API — custom resources, controllers, and when an operator is worth the operational cost.
Kubernetes is extensible on purpose. CRDs add new object kinds; operators reconcile those kinds toward real systems.
CustomResourceDefinitions
A CRD registers a schema and API group/version. Clients (kubectl, GitOps) treat CRs like built-ins once installed. Versioning and conversion matter — breaking CRD schemas without a plan strands live objects.
Controllers and operators
An operator watches CRs and acts (create StatefulSets, configure Kafka, manage backups). Good operators encode domain runbooks. Bad operators are opaque binaries that fight you during incidents.
When to adopt
Use an operator when the lifecycle is complex and the vendor/community maintains it seriously (databases, message buses, certs). Avoid installing every OperatorHub curiosity — each CRD is another control loop to upgrade and debug.
Platform responsibilities
- pin operator versions
- monitor operator health and queue depth
- document which CRs product teams may create
- backup CR state if it is authoritative
Anti-patterns
- CRDs with no schema validation
- operators that require cluster-admin forever
- storing irreplaceable business state only in status fields nobody backs up
Extensions should reduce toil. If they increase mystery, you bought the wrong abstraction.