mail

A very interesting topic that has come up lately is the fact that kubernetes operators come with a number of difficulties that make them hard to code and use. This article summarizes some of those concerns. You will find when and how to avoid them as well as the alternatives approaches you can use. Afterall, the best operator may be no operator.

We are fashion victims! Knowing about operators, we are using them a lot. We are even developing some. So when someone reminds us that the best operator is no operator, it is worth listening. So I cannot agree more with When Not to Write a Kubernetes Operator, When to Use, and When to Avoid, the Operator Pattern and Kubecon Stop Writing Operators by Joe Thompson, HashiCorp.

This article summarizes the alternatives, challenges and benefits of operators.

You need no-operator

Operators are packaged components relying on CRDs and Controllers to automate operations of third party applications like MySQL. What is not told, yet very true about operators, is that:

  • If your application has been built to leverage Kubernetes, you probably do not need operators;
  • If the components you manage are outside Kubernetes, it is very likely you can also manage them without any operators, outside Kubernetes;
  • If your application is stateless or it can recover from the loss of its state... you do not need any operators;
  • If you plan to manage thousands of components, you might not want to rely on CRDs and etcd as well as you might not want to rely on operators;
  • Depending on how you plan to restart your workload in the event of a failure, you might want to externalize your application state out of your cluster and not rely on any operators
  • There are some more lightweight models than operators, including some higher level abstraction like kudo

Consider, no operator is the best solution, before even considering using an operator.

Operators are hard

So if, despite what you've just read, you still consider writing an operator, think about it twice; operators are tricky:

  • You might want to be experienced to write an operator. This includes with frameworks, toolings and kubernetes. For instance, do not write an operator with a language you do not know.
  • You need to know very well the application you want to operate. If not, there is a good chance you mess around with it at some point. The least you should do it talk and get support from the application development team. They might very well have plan to support Kubernetes.
  • You should understand the problem you are dealing with, the limits. You should have failed and know what the pitfalls are.
  • You should not write an operator for an application that is not mature.
  • You should not write an operator to automate something that is not worth it, i.e. that is not a frequent issue. You should not write something that is too hard to automate.
  • You might want to keep your code minimum and not change your operator with every change of the managed application.
  • Operators need privileges, they increase the attack surface and are an additional challenge for security teams.
  • Operators need to be operated.

Code is a liability and you should not consider writing operators lightly.

Operators or no-operator

Do not get me wrong, operators are powerful and very useful. You will find strong cases for writing one. The most valuable being, I think, because it is the best way to understand how Kubernetes works. It is also the best way to adapt a stateful application that has not been written for Kubernetes to Kubernetes. Operators are good solutions to integrate new Kubernetes features as a temporary solution. They can provide backward compatibility features with older Kubernetes releases.

There are plenty of management tools out there, like the ones implementing GitOps. You can find simpler models. You might very well also want your application to directly integrate Kubernetes rather than relying on an external component like an Operator. Operators should not be the default way of thinking. That is my point.