What is the difference between a Kubernetes Controller and a Kubernetes Operator?

Question

As I understand the purpose of the Kubernetes Controller is to make sure that current state is equal to the desired state. Nevertheless, Kubernetes Operator does the same jo

Answer 1

I believe the term "kubernetes operator" was introduced by the CoreOS people here

An Operator is an application-specific controller that extends the Kubernetes API to create, configure and manage instances of complex stateful applications on behalf of a Kubernetes user. It builds upon the basic Kubernetes resource and controller concepts, but also includes domain or application-specific knowledge to automate common tasks better managed by computers.

So basically, a kubernetes operator is the name of a pattern that consists of a kubernetes controller that adds new objects to the Kubernetes API, in order to configure and manage an application, such as Prometheus or etcd.

In one sentence: An operator is a domain specific controller.

Update

There is a new discussion on Github about this very same topic, linking to the same blog post. Relevant bits of the discussion are:

All Operators use the controller pattern, but not all controllers are Operators. It's only an Operator if it's got: controller pattern + API extension + single-app focus.

Operator is a customized controller implemented with CRD. It follows the same pattern as built-in controllers (i.e. watch, diff, action).

Update 2

I found a new blog post that tries to explain the difference as well.

Answer 2

In Kubernetes, most of the operations happen in an asynchronous manner.

For instance, when one creates a ReplicaSet object (picking a simpler object), this is the sequence that happens:

1. We send the request to the Kube api-server.
2. The kube-api server has a complex validation
   • Ensures that the user has the RBAC credential to create the RS in the given namespace
   • The request is validated by all the configured admission controllers
3. Finally the object is just written to ETCD - nothing more nothing less

Now, it is the responsibility of the various Kubernetes controllers to watch the ETCD changes and actually execute the necessary operations. In this case, the ReplicaSet controller would be watching for the changes in ETCD (e.g. CRUD of ReplicataSets) and would create the Pods as per the replica count etc.

Now, coming to Operators, conceptually they are very similar to Kubernetes controllers. But they are used with third-party entities. In Kubernetes, there is a concept of CRDs, where vendors can define their own CRD which is nothing but a custom (e.g. Vendor specific) kubernetes object type. Very similar to the manner in which Kubernetes controllers read to the CRUD of Kubernetes objects, these operators respond to the operations on the corresponding CRDs. E.g. Kong operator can create new API entries in the Kong API server when a new API CRD object is created in the Kubernetes cluster.

Answer 3

I'm doing a course from Linux Foundation to prepare for a CKA certification and just now I read in a simple words:

For example, a deployment (aka deploy) is an operator (or controller), a stateful (aka sts) is another operator (or controller) and so on. So, if someone build an operator (or controller) for an etcd, then you will be able use commands like these kubectl get etcd and kubectl delete etcd my-etcd.

In other words, according to the Linux Foundation, the terms Operator and Controller can be considered synonyms.