[darren0]

I’m not sure why this is a top post. The definitions of controller and operator are completely wrong. The example code is for creating a custom api server which is only done in the most advanced of advanced use cases. The implementation of the apiserver is too naive to demonstrate they have any understanding of the complexity that supporting watch will cause.

[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.

[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.

[timelapse]

> The definitions of controller and operator are completely wrong.

mind clarifying?