Kubernetes Operator
A custom controller that encodes operational knowledge for a specific application, reconciling a custom resource towards a desired state the same way built-in controllers do.
Kubernetes' core idea is the reconciliation loop: declare desired state, and a controller works continuously to close the gap. An operator extends that model to things Kubernetes does not know about — a database cluster, a message broker, a certificate.
Instead of a runbook saying "to add a replica, do these nine steps", you change a field on a custom resource and the operator performs the steps, including the awkward parts: ordered rolling upgrades, backup before migration, leader failover, and recovery when a step fails halfway.
Where operators earn their cost: stateful workloads with genuinely complex operational procedures. Running Postgres, Kafka or Elasticsearch on Kubernetes is impractical without one.
Where they do not: wrapping a stateless application that a Deployment already handles. An operator is a distributed control loop with permissions over your cluster, and a badly-written one can delete things convincingly.
Two evaluation criteria for adopting a third-party operator. What does it do on failure — a reconciliation loop that recreates a resource it cannot find is dangerous if it misreads a transient API error. And what permissions does it need — many request cluster-wide privileges, which makes the operator a high-value target and part of your security boundary.