Stop Writing Operators

by default ^

Joe Thompson

Senior Solutions Engineer, HashiCorp

In IT since my first job helping out with computers in my high school in 1994

Past employers: Mesosphere, Capital One, CoreOS, Red Hat, among others

Exposed to Kubernetes in early 2015 and working with it full-time since late 2015

Currently a Solutions Engineer for (we're hiring!)

Pronouns: he/him
Blood type: Caffeine-positive

Contact info:

Everybody's thinking it...


28 Jun 2020

Talk submitted

12 Sep 2020

Devan Goodwin: When Not to Write a Kubernetes Operator

29 Sep 2020

Talk accepted!

Pre-Operator Checklist


  • Should this operator be written at all?

  • Should I write it?

  • What functions should my operator perform?

  • What API permissions will my operator need to perform those functions?

  • What framework should I write my operator in?

Injunction vs. information


Are you serious?

- Pretty serious

- Not like, we-can't-be-friends-unless serious though

Are you saying operators are bad?

- No! Operators are good! the proper places

What an operator is and isn't

Operators vs. controllers


2016 -- CoreOS: Introducing Operators: Putting Operational Knowledge into Software

"...application-specific operational knowledge encoded into software that leverages the powerful Kubernetes abstractions to run and manage the application correctly..."


Meant for managing stateful apps

- All operators are controllers but NOT all controllers are operators!

- A controller that does nothing stateful is just a controller (and that's OK)

Deciding if you want an operator

Case #1: No state needs managing


No statefulness

- or-

Kubernetes has all the necessary state handling

Case #2: Apps you maintain


Creating an operator is over-abstracting the problem

You now have an extra component susceptible to failure

Case #2: Apps you maintain


Isn't an operator just another microservice?

- No: microservices remain abstracted from one another. Operators inherently don't.

Operators (and CRD controllers) make your security burden heavier

Alternatives to operators

CRD controller


Not trying to manage state at all is easier to do safely

(source: XKCD #1205)

Do nothing

- Automation isn't worth it if you aren't saving time

No-code operator frameworks


Top-level controller implements the management primitives

You write declarative config to implement your operator logic

Run outside the cluster


No longer limited in scale or architecture by needing to fit into the cluster

- But you will still have to manage RBAC, and handle authentication

When operators are needed

Case #1: Someone else's app


...and its state has to be managed inside Kubernetes

Definitely not ideal

Engage the app maintainers as early and often as possible

- They might even be willing to take on smaller state-handling feature requests

Case #2: Compatibility shims


Your app can take fuller advantage of Kubernetes features

- The operator provides state handling to run your app in older versions of k8s

- The operator provides functions for your app that have not landed in Kubernetes yet

This is fine on a temporary basis

You need an operator... but maybe you shouldn't write it

Case #1: You don't have a map yet


You should not write an operator for things until:

- you've spent as long recovering from failure or dealing with lack of management

- as it would reasonably take you to write the operator

Failure is where we learn

- Learning from failure is even more critical when we automate

What about routine operations?


Is that all you're doing?

- If so, look at some of the non-operator methods of handling these tasks first

Case #2: 0.x app versions


An operator with no forward compatibility assurance is a time sink waiting to happen

Don't assume 1.x means SemVer-level stability is in effect

Case #3: Did you talk to the owner?


The app owner knows their app better than anyone fact, they might already be writing what you need

I'm writing an operator, now what?

Pre-Operator Checklist (continued)


Choosing to use a framework


  • Can you write in one of your preferred languages?

  • Does its model fit both into your environment and into your head?

  • Does the framework maintainer provide framework-related services you want to use?

Final thoughts

When you write that operator:


  • Maintain loose coupling

  • Remember, no code is often better

  • Write what you know (then stop)

More info



Devan Goodwin: When Not to Write a Kubernetes Operator

The New Stack: Kubernetes: When to Use, and When to Avoid, the Operator Pattern

CoreOS: Introducing Operators: Putting Operational Knowledge into Software

WeaveWorks: GitOps - Operations by Pull Request

Kubernetes: Custom Resources, Operator Pattern

Further reading:

WeaveWorks: What Is GitOps

Matt Butcher: Is there a Helm and Operators showdown?