Summary
ref Custom Kubernetes controller.
A 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.
It builds upon the basic Kubernetes resource and controller concepts, but includes domain or application-specific knowledge to automate the entire life cycle of the software it manages.
In Kubernetes, controllers of the control plane implement control loops that repeatedly compare the desired state of the cluster to its actual state. If the cluster’s actual state doesn’t match the desired state, then the controller takes action to fix the problem.
An operator is a custom Kubernetes controller that uses custom resources (CR) to manage applications and their components. High-level configuration and settings are provided by the user within a CR. The Kubernetes operator translates the high-level directives into the low level actions, based on best practices embedded within the operator’s logic.
Kubernetes can manage and scale stateless applications, such as web apps, mobile backends, and API services, without requiring any additional knowledge about how these applications operate. The built-in features of Kubernetes are designed to easily handle these tasks.
However, stateful applications, like databases and monitoring systems, require additional domain-specific knowledge that Kubernetes doesn’t have . It needs this knowledge in order to scale, upgrade, and reconfigure these applications.
The function of the operator pattern is to capture the intentions of how a human operator would manage a service. A human operator needs to have a complete understanding of how an app or service should work, how to deploy it, and how to fix any problems that may occur. E.g.: Elastic operator will have the complete domain knowlege to automate the installation of ECK components.
Difference between Operator and Controller
https://stackoverflow.com/a/55772035 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:
We send the request to the Kube api-server. 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 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.