In November 2016, Operators came on the scene. They have since been embraced by the Kubernetes community for many use cases where there are frameworks and ecosystems surrounding them.

In the years after the announcement, CoreOS, the company that started the operator craze, has been bought and that company has been bought. The CoreOS website and docs, where all of this came out, are no longer available on the general Internet and can’t be found in search engines.

In place of what CoreOS shared we have marketing and docs from frameworks and companies. While that marketing and documentation can excel at pointing people to those frameworks and companies, the simple explanations of what an operator is can be easily lost.

With that in mind, let’s go back and take a look at the simple definition from Brandon Philips, then CTO at CoreOS, who shared the idea of operators with the world.

The opening to the original announcement (which can still be found in the Internet Archive) contains a simple straight forward definition that still holds true today:

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.

The original post covers Site Reliability Engineers (SRE) encoding operational business logic, looks at why there is a need for stateful applications, and provides examples for how this works. It goes far beyond the basic definition.

This simple two sentence definition cuts through the marketing to provide a clear definition.