An operator is a controller that encodes how to run a specific piece of software: install it, upgrade it, take backups, handle failover. It is the mechanism by which “somebody who knows how to run PostgreSQL” becomes software.
When it works it is the best idea in the ecosystem. The problem is that installing one is a click and maintaining one is a commitment, and only one of those is visible at the time.
The three kinds
Vendor operators for products you pay for. The storage driver, the database from a commercial vendor, the monitoring stack from your platform supplier. These have a support contract behind them and a lifecycle you can plan against. Treat them as product components.
Community operators from a public catalogue. Quality ranges from excellent to abandoned, and the catalogue entry looks identical in both cases. Some are maintained by large projects with real release discipline. Some were a side project that has not seen a commit in two years.
Operators you write. More common than people expect, because eventually you have an internal thing that needs the same lifecycle treatment.
The audit that is worth an afternoon
List every operator in every cluster. For each one:
- Who installed it, and when?
- What depends on it?
- When was the last upstream release?
- Does its compatibility matrix cover the platform version you will be on in six months?
- If it stopped working tomorrow, what breaks and who fixes it?
That last question is the one that produces uncomfortable silences. I have yet to see this audit run without finding at least one entry where the honest answer is “nobody, and something important”.
The abandonment problem
An operator that stops being maintained does not fail. It keeps working, until a platform upgrade moves past its compatibility range, at which point you have a blocked upgrade and a decision: fork it, replace the software it manages, or stay on an unsupported platform version.
None of those is cheap, and all of them arrive with an upgrade deadline attached. The prevention is the quarterly review, which is boring and takes an hour.
Before you install one
Check the release history, not the README. Steady releases over a couple of years means somebody is home. A burst of activity ending eighteen months ago means the maintainer moved on.
Check whether it is the project’s official operator or a third party’s packaging of it. Both exist, they are not equivalent, and the catalogue does not always make it obvious.
Check what permissions it wants. Some ask for cluster-wide privileges they do not need, and an abandoned operator with broad permissions is a security problem as well as a lifecycle one.
Writing your own
The frameworks make the mechanics accessible, and the mechanics are not the hard part. The hard part is that you are writing a control loop that must be correct under partial failure, handle its own upgrades, and not destroy data when something unexpected happens.
Write one if you have a genuinely repeated operational burden that is expensive in human time, and be honest that you now own software with a lifecycle. Do not write one to avoid documenting a procedure.
The best question to ask before starting: if the person writing this leaves, who maintains it? If there is no answer, write a runbook instead. A runbook that is followed beats an operator that nobody understands.