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 job.
The list of controller in the Control-plane:
From the Google Search, I found out that there are K8s Operators such as
However, I was not able to understand why it cannot be done using Controller?
Is Operator complementing the Controllers?
What's the difference between these two design as a purpose and functionality.
What certain things need to keep in mind to choose between Controller and Operator? ?
A Kubernetes operator is an application-specific controller that extends the functionality of the Kubernetes API to create, configure, and manage instances of complex applications on behalf of a Kubernetes user.
In Kubernetes, controllers are control loops that watch the state of your cluster, then make or request changes where needed. Each controller tries to move the current cluster state closer to the desired state.
The KubernetesPodOperator uses the Kubernetes API to launch a pod in a Kubernetes cluster. By supplying an image URL and a command with optional arguments, the operator uses the Kube Python Client to generate a Kubernetes API request that dynamically launches those individual pods.
Helm is geared towards performing day-1 operations of templatization and deployment of Kubernetes YAMLs — in this case Operator deployment. Operator is geared towards handling day-2 operations of managing application workloads on Kubernetes. You will need both when running stateful / complex workloads on Kubernetes.
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.
The application is created by running a single Pod in the Kubernetes cluster. If the application crashes then the Pod will die. If the Pod dies then the user losses access to the application. This will create a big problem among the users. Users do not use the application which fails frequently. So we need a controller to watch the Pod status.
The thermostat acts to bring the current state closer to the desired state, by turning equipment on or off. In Kubernetes, controllers are control loops that watch the state of your cluster, then make or request changes where needed. Each controller tries to move the current cluster state closer to the desired state.
You can use Kubernetes to automate deploying and running workloads, and you can automate how Kubernetes does that. Kubernetes' operator pattern concept lets you extend the cluster's behaviour without modifying the code of Kubernetes itself by linking controllers to one or more custom resources.
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.
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).
I found a new blog post that tries to explain the difference as well.
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:
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.
TL;DR:
Change my mind but in my opinion the difference is negligible and the terms rather confuse people then actually adding value to a discussion. I therefore would use them interchangeablely.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With