Operators and CRDs

A CustomResourceDefinition extends the Kubernetes API with a new resource type; an operator is the controller that watches instances of it and reconciles reality toward what's declared. Together they let you express operational knowledge — "how to safely upgrade this database," "how to provision this cloud resource" — as a Kubernetes-native API instead of a runbook a human executes by hand. That's real leverage, and it's also a commitment: you're now maintaining a piece of distributed systems software, not a script.

The value of an operator is entirely in how well it encodes the operational knowledge a human would otherwise apply manually — a thin operator that just creates a Deployment isn't worth the complexity. Build an operator only when the reconciliation logic is genuinely nontrivial, not because CRDs feel more "cloud native" than a ConfigMap.

1. Design the CRD schema as a stable public API

A CRD's spec is a contract every consumer (humans, GitOps tooling, other controllers) writes against. Changing field names or semantics after adoption is a breaking change exactly like an external API's, and Kubernetes gives you real tools for this — use them, don't wing the schema.