They watch for their CR changing and then act on it - usually by making requests to the API server to create/update/delete objects (e.g. a operator for a database might make Pod creation requests when it spots the FooDatabase CR being created)
In essence, a controller is like a general-purpose manager for built-in K8s resources, while an operator is a specialized manager tailored for specific applications and tasks. Operators are built on top of the controller pattern, so you can think of them as the next level up in the K8s automation!
but i will agree on that i have seen people develop controllers with the operator sdk where mostly the Kubernetes client libraries would have been more than enough.
They watch for their CR changing and then act on it - usually by making requests to the API server to create/update/delete objects (e.g. a operator for a database might make Pod creation requests when it spots the FooDatabase CR being created)