Kubernetes Helm charts and operators share a little in common – starting with the fact that both terms are poster children for non-self-explanatory jargon. Even for folks with programming experience, the term operator in the context of Kubernetes might not make a lot of sense because it has nothing to do with operators in coding.
As for Helm charts, you literally need to speak Greek – or at least know that Kubernetes is derived from a Greek word meaning navigator – and you have to have an appreciation for cheeky, self-referential jargon to have any idea why a Helm chart is called what it is. (In case it's still not clear, the answer is that a Helm chart helps "steer" Kubernetes, just as a Helm steers a ship.)
But beyond their shared affinity for being terms that don't make a lot of sense to the uninitiated, operators and Helm charts don't share much in common. True, they both serve the same basic goal of helping to install and configure apps in Kubernetes. But they do so in different ways. Depending on factors like how much control you want and how important ongoing application lifecycle management is, an operator might be better than a Helm chart, or vice versa.
With that reality in mind, keep reading for a detailed comparison of Kubernetes operators and Helm charts, along with tips on which solution to use and when.
What is a Kubernetes operator?
In Kubernetes, an operator is a type of controller that can install and manage applications using Kubernetes custom resources. To explain what that means in a bit more detail, let's unpack two keywords from that definition: Controller and customer resource.
A controller in Kubernetes is a routine that monitors the state of Kubernetes configurations, as well as the actual state of Kubernetes cluster resources. When it detects a deviation between the desired and actual states of a given resource – which may occur either because an admin modified the configuration or due to some kind of failure inside your Kubernetes clusters – the controller attempts to bring the desired and actual states back into alignment.
So, if you deploy a configuration that describes how you want an application to behave, a controller will detect the configuration and then apply it (assuming it's possible to apply given the state of your Kubernetes clusters as a whole).
A custom resource in Kubernetes is an extension of the Kubernetes API that makes it possible to add functionality to a Kubernetes cluster that is not available by default. You can do this by creating a custom resource definition, or CRD.
If you want to install or manage an app using Kubernetes operators, you can create a CRD that implements whichever functionality the app needs to support. If you then accompany the CRD with a controller as part of an operator, the Kubernetes controller routine will detect and deploy it.
Kubernetes operators example
For those looking for a basic Kubernetes operator example, the hello-operator2 code (courtesy of Deepak Sharma) is a good sample. We won't copy all of it here, but let's show some of the key components.
First, the operator defines some basic contextual parameters:
Then, it implements a function that checks the deployment status: