A county applies an operator manifest; afterward a controller continuously reconciles custom resources toward desired state. What is the operator’s essential role?
Select an answer to reveal the explanation.
Short Explanation
An operator is the tireless clerk who reads BackupSchedule (or similar) and keeps making the cluster match what the form says. Watch, compare, act—that reconcile loop is the heart of it. It does not replace the API server.
Full Explanation
After a county applies an operator manifest, the controller’s essential role is to watch custom resources and reconcile cluster state to match their specs. The tireless clerk reads BackupSchedule (or similar) and keeps making the cluster match the form—watch, compare, act. Operators do not replace kube-apiserver so requests bypass RBAC and admission. They are not only Jobs that exit after printing CRD OpenAPI once; they continuously reconcile. They should not disable the scheduler so custom resources pin Pods to control-plane nodes. Exam caveat: Operator = controller reconcile loop over CRs with RBAC to managed resources. Operational check: kubectl get/describe the CR, watch operator logs for reconcile, and confirm child Jobs/PVCs/config match the CR spec. 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. Keep the verification evidence—command output or config snippets—with the municipal runbook so audits can prove the control was applied as designed.