Kubernetes · Orchestration under pressure
What is a Kubernetes Operator and when should you build one?
Short answer
An Operator packages a CRD with a controller that encodes operational knowledge, such as backups, failover and upgrades. Build one when day-two operations are complex and repeatable.
Operators extend Kubernetes with custom resources and a reconciliation loop. Instead of a human running runbooks, the controller observes the custom resource and the cluster, then acts to reach the declared state. Mature operators also handle upgrades, scaling, backups and failure recovery.
- Use an operator when the workload needs domain-specific day-two automation
- A CRD alone is not an operator; it needs a controller
- Operators must be idempotent and tolerate partial failures
- Upgrade paths for the operator itself matter as much as for the workload
- Prefer a maintained community or vendor operator over writing your own
kubectl get crds
kubectl get postgresclusters -n data
kubectl describe postgrescluster main -n data
kubectl get events -n data --sort-by=.metadata.creationTimestampThe cost is real: controllers are distributed systems with watches, retries, leader election, status conditions and versioned APIs. A fragile operator can be worse than a documented runbook. Start with automation scripts and a Helm chart, and build an operator only when the operational loop is stable and valuable enough to encode.
Follow-ups you should expect
Interviewers use these to check whether the first answer was understanding or memorisation.
- 1What is the difference between a CRD and an operator?
- 2When is an operator overkill?
- 3How do you test an operator's failure handling?
- 4What operational tasks would you automate first?
Say it in the interview
An operator is a CRD plus a controller that encodes operational knowledge for a workload. It reconciles custom resources toward a desired state, including tasks like backups, failover and upgrades. I only build one when those day-two operations are complex, stable and repeated, because controllers are distributed systems themselves. Otherwise a chart plus a runbook is cheaper and safer.
Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.
Related questions
Reading is step one
Now say it out loud.
Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live Kubernetes mock interview and get scored feedback on depth, clarity and confidence.