Re: Operator Definition

Marc Campbell

The qualification of "Stateful application" feels restrictive to me also. We've built operators that don't manage any state, but still call them "operators" because they codify and package a domain or application-specific knowledge. 


On Wed, Nov 06, 2019 at 9:56 AM, Nicolas Trangez <> wrote:


On Wed, 2019-11-06 at 12:46 -0500, Matt Farina wrote:

In the TOC meeting yesterday (11/5) there was a question about the definition of an operator that was kicked back to SIG App Delivery. In the app delivery call today, at least before I had to drop, no definition had been proposed but the topic was discussed. So, I would like to propose a definition.

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.

Why would this only be for 'stateful' applications, or even
'applications' in general?

Some cases I have in mind:

Non-stateful applications:
- An operator that deploys some application which itself doesn't have any stateful components, but can be configured to connect to some existing/external system for persistence where needed.
- An operator that deploys some application which itself *does* come with a stateful component, but delegates the job of managing this stateful component (say, a database) to *another* operator (using its CR(D)s) which in turn does whatever is needed.

- Maybe a bit of a corner-case which doesn't necessarily *must* fall under the 'operator' definition: we have a system in place which, given CR instances, performs operations fully outside of Kubernetes at first
(provisioning certain hardware), then inside Kubernetes (making this hardware available to the in-cluster workloads). Not strictly related to app-delivery, but if there's some definition of 'operator', it shouldn't only cover what app-delivery expects from them.

A similar case would be ClusterAPI implementations that launch VMs or whatnot.

This is taken directly from the original introduction to operators by CoreOS <> when they documented the concept.

In general, I think the concept has grown beyond the initial scope/goal...

The Kubernetes documentation has a long description of operators <>but I think the original definition is fairly clear and concise. For a definition I would suggest something short and to the point.



Join to automatically receive all group messages.