Kubernetes Operators vs. Helm Charts: Which to Use and When

In Kubernetes, Helm charts and operators are both handy tools for automating tasks that would otherwise require a great deal of manual effort. But although they do similar things, they are not exactly interchangeable tools. Here’s a breakdown of how Helm charts work, how Kubernetes operators work, and when you should use one or the other.

The Need for Helm Charts and Kubernetes Operators

Helm charts and Kubernetes operators exist to solve similar types of problems (although not the same exact problem) in Kubernetes: Writing YAML files by hand is not a lot of fun for most people, and it is not practical to write custom YAML manually every time you need to deploy an app or modify a configuration setting within your Kubernetes cluster.

Helm charts and Kubernetes operators solve this challenge by providing an easy way for admins to deploy applications and/or configurations into a Kubernetes cluster. In this way, they double-down on the automation features that Kubernetes enables.

Kubernetes Operators vs. Helm charts

That said, whether you should use Kubernetes operators vs. Helm charts depends on what kind of application you are deploying and how much special configuration it requires. To understand the difference, let’s look at how the use cases for Helm charts and operators are different.

Use cases for Helm

Helm is a package management system for Kubernetes. Using a packaging format called charts, someone can package an application--like Kafka or Apache HTTP, for example--in a format that anyone else can deploy on a Kubernetes cluster with just a few commands, while making few or no manual changes to YAML files.

If you’re familiar with package management in the context of Linux, Helm charts should be pretty easy to understand. They’re analogous to Debian or RPM packages, while Helm itself is like apt or dnf. Just as you can apt-get install [some package] on Ubuntu, you can helm install [some package] on Kubernetes to get an application up and running quickly.

Use cases for Kubernetes operators

Kubernetes operators also package applications into easy-to-deploy formats, but they do much more than that. Using Kubernetes custom resources, operators also make it possible to include a great deal of complex configuration data within the package.

Thus, you can use Kubernetes operators to do things like deploy a stateful application and its database schema in a completely automatic way, or deploy an application across a cluster that is configured in a particular way to achieve high availability. Indeed, you don’t even need to deploy an application when using an operator; you can use operators to automate other tasks, like performing backups or configuring your cluster in a special way based on predefined templates.

Unlike Helm charts, Kubernetes operators don’t have any direct analogies from other platforms, although they are comparable to other types of tools. You can think of operators in some respects as being like a Bash script that you deploy on a Linux server to modify the server’s configuration, although operators are packaged and deployed in a cleaner, more discrete way than a generic Bash script.

Kubernetes operators are perhaps also analogous in some ways to an operating system image file, which you could use to deploy copies of an operating system environment that is set up in a specific way. However, operators are easier to modify and deploy than an image file. If you want to deploy an OS image, you have to build a new OS from scratch. In contrast, operators can be deployed on an existing Kubernetes cluster, where they will change only the parts of the cluster configuration that they are designed to change.

When to use Helm charts and when to use operators

So, when should you use Helm, and when are Kubernetes operators a better solution? The answer depends on a few factors:

The bottom line is that most teams will use both Helm charts and Kubernetes operators at different points to achieve different goals. They are complementary, rather than competing, technologies. They both help to automate Kubernetes workflows, as well as to share Kubernetes applications and configurations with other people, but they address different types of use cases.