February 21, 2026
CRDs extend the Kubernetes API with your own resource types. Once you create a CRD, you can kubectl get, kubectl apply, and kubectl delete instances of your custom type just like built-in resources. The custom resources are stored in etcd alongside native Kubernetes objects, benefit from the same RBAC, and participate in the same API machinery.
CRDs make sense when you need to represent application-specific concepts inside Kubernetes:
February 21, 2026
Operators are custom controllers that manage CRDs. They encode operational knowledge – the kind of tasks a human operator would perform – into software that runs inside the cluster. An operator watches for changes to its custom resources and reconciles the actual state to match the desired state, creating, updating, or deleting child resources as needed.
The Operator Framework defines five maturity levels:
| Level | Capability | Example |
|---|---|---|
| 1 | Basic install | Helm operator deploys the application |
| 2 | Seamless upgrades | Operator handles version migrations |
| 3 | Full lifecycle | Backup, restore, failure recovery |
| 4 | Deep insights | Exposes metrics, fires alerts, generates dashboards |
| 5 | Auto-pilot | Auto-scaling, auto-healing, auto-tuning without human input |
Most custom operators target Level 2-3. Levels 4-5 are typically reached by mature projects like the Prometheus Operator or Rook/Ceph.