An open-data portal chooses an operator to manage a clustered datastore addon rather than only a raw Deployment manifest. What advantage are they seeking?
Select an answer to reveal the explanation.
Short Explanation
A datastore cluster needs more than “run three containers”—it needs membership, failover, and repair logic. Operators encode that day-2 brain on top of CRs. A bare Deployment rarely knows how to reconfigure a quorum.
Full Explanation
An open-data portal chooses an operator for a clustered datastore addon to gain day-2 logic for complex stateful components beyond a plain Deployment—membership, failover, and repair encoded against CRs. A bare Deployment rarely knows how to reconfigure a quorum. Operators do not eliminate the need for PersistentVolumes on stateful software. Raw Deployments do not automatically perform failover, backups, and topology-aware membership for datastores. Stateful addons are not required to run only as static Pods on the API server host. Exam caveat: Operators add domain-specific reconcile; Deployments only replicate Pods. Operational check: Compare a Helm operator install versus a raw Deployment for the datastore, exercise a failover/backup CR action in staging, and document why the portal standardized on the operator. In municipal platform operations, record the rationale in the change ticket so future on-call staff know which control was chosen and which failure modes the rejected options would create for city services. Re-validate after the next maintenance window that the same control still holds under the cluster’s current minor version and addon revisions used by the civic platform team.