[mfer]

The article has a description of what an operator is wrong. The definition of an operator originally was...

> 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 includes domain or application-specific knowledge to automate common tasks.

This is the original definition of an operator [1]. People no use them for stateless things and domain specific work has taken off.

You can look at the Kubernetes docs [2] to see refinements on it...

> 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. Operators are clients of the Kubernetes API that act as controllers for a Custom Resource.

[1] https://web.archive.org/web/20190113035722/https://coreos.co...

[2] https://kubernetes.io/docs/concepts/extend-kubernetes/operat...

[richardwhiuk]

You don't need to implement a custom API server to implement an operator - you can just watch a CR.

[jhoelzel]

for an operator you do, what you mean is a controller =)

[richardwhiuk]

No, you don't. You can have a CR, and implement an Operator which just watches the CR and acts upon it.

[jhoelzel]

a controller is an operator without crd. its in the name control and operate.

controlling refers to directing or regulating the behavior of something, while operating refers to the actual execution or manipulation.

[richardwhiuk]

Most operators don't implement the API server.

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)

[jhoelzel]

or some operators are wrongly named =)

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.

[oso2k]

Conceptually, an Operator is intended to embody the knowledge and processes of a human operator for a given functionality. Extending the Kubernetes API might be an implementation detail but it’s entirely optional to extend it. Most Operators do extend it in practice, however.