Getty Images/iStockphoto
When to use Kubernetes operators vs. Helm charts
Not sure whether to use Helm charts or Kubernetes operators? Walk through examples to learn when to use each one, looking at factors like application complexity and team maturity.
Kubernetes operators and Helm charts are tools that stir up confusion in the industry -- they seem to fill the same role, but they do slightly different things. Depending on where your organization finds itself on its Kubernetes adoption roadmap, it might find that Helm charts are sufficient, but others might need to invite operators to the table.
To understand Helm charts and Kubernetes operators within a cluster ecosystem, we can imagine a theoretical scenario to understand various challenges a team faces while operating Kubernetes:
Your IT team has spun up a Kubernetes cluster within your organization's ecosystem; it could be either in the cloud or on premises, but it is ready for consumption. Engineers are ready to use the Kubernetes cluster for development, so you provision a namespace and provide access via role-based access control (RBAC). Now the engineers need a database for their application, or a reverse proxy. These tasks can be called "Day 0 Ops."
This scenario is akin to what an IT pro faces for even an OS installation. Then they need to install a few applications -- in this case, well-known package managers such as apt, yum or Chocolatey for the OS distro. With this analogy, think of the Kubernetes cluster as an OS; Helm is the tool that enables users to install an application on that Kubernetes cluster. Helm is a packaging format that works well with simple applications like stateless microservices and REST-based APIs with states stored externally in the cloud.
However, as time progresses and developer teams unlock the full potential of the platform, the application becomes complex and grows in tandem with its additional requirements -- like statefulness -- and requires more complex logic. This complexity creates challenges for authoring those Helm charts-templatized YAML manifests; at this point, it is time to adopt the powerful operator pattern supported in Kubernetes.
But teams can consider Kubernetes operators when trying to automate mundane tasks. Think of operators as scripts -- or as a configuration management tool like Chef or Puppet, which enables platform engineers to automate and extend the platform.
IT teams don't need to only choose between Kubernetes operators vs. Helm necessarily. Depending on the application, the use case and its complexity, organizations might find that the best option is, in fact, a pairing of the two tools.
What is Helm?
Helm is an open source project created by DeisLabs and donated to the Cloud Native Computing Foundation, which now maintains it. Helm is a package manager designed specifically for Kubernetes and improves the management of the YAML manifests required to create Kubernetes projects.
At the heart of Helm is the packaging format called charts. Each chart comprises one or more Kubernetes manifests -- and a given chart can have child charts and dependent charts, as well.
Thus, Helm can tackle the complexities of dependency management for a Kubernetes project. Rather than an IT admin simply listing the files to install via kubectl, a single command can install an entire application, and Helm will pull the required dependencies and apply the manifests.
Charts enable IT admins to version manifest files, like with Python packages or NuGet libraries, for example. IT admins can install specific chart versions, which keeps specific configurations for the infrastructure in the form of code. Helm charts can be shared across an organization by hosting them on a private repository, using multiple cloud services, such as GitHub pages, JFrog Artifactory or using cloud storage back ends.
Helm also retains a release history of all deployed charts, so IT teams can go back to a previous release if something goes wrong.
What are Kubernetes operators?
Helm solved a lot of problems around templatizing YAML manifests. But, in reality, there are cases where the application's complex requirements are difficult to express in YAML manifests using templates. To be fair, most applications will not have these complex requirements for operation on Kubernetes. But if there are such applications your organization does need to support, teams should use Kubernetes operators. Operators enable IT teams to encapsulate this knowledge of running applications via general-purpose programming languages like Go, Python and Java, and run it natively on the Kubernetes platform.
Operators are geared toward site reliability engineering teams to manage the complex runbooks that orchestrate the deployment of a complex application, along with automating mundane tasks for the Kubernetes platform.
Kubernetes operators build on custom resources and controllers. In plain terms, an IT admin can define their resources in Kubernetes and publish logic -- via an operator -- that can handle CRUD operations for the custom resource. These custom resources can model a complex application or a standard templatized application; the operators maintain the resource's lifecycle.
There are several available frameworks that facilitate operator development:
- Juju, a Charmed Operator Framework
- kubebuilder
- KUDO (Kubernetes Universal Declarative Operator)
- Metacontroller, along with user-implemented webhooks
- Operator Framework
- shell-operator
Kubernetes operators vs. Helm
On a very high level, both Helm charts and Kubernetes operators do the same thing, more or less, but their adoption depends on various conditions such as cluster adoption, team maturity and application requirements.
For teams just beginning to run Kubernetes clusters that want to deliver simple applications to users, packaging these applications via Helm charts provides benefits for simpler templatized YAML manifests. Helm charts enable the IT ops team to package, version and share the applications with their dependencies, which enables rapid application delivery. Authoring Helm charts requires familiarity with YAML and uses the Go template engine along with the Sprig template library.
As teams and the Kubernetes cluster usage matures, there might be mundane tasks and complicated requirements for applications to run. This is the point at which the IT ops team should add Kubernetes operators to the mix. And authoring Kubernetes operators means that the team must maintain this codebase over time.
In general, Helm charts are most useful when first setting up a Kubernetes cluster to deploy simple applications. Helm charts can handle the install-update-delete lifecycle for the applications deployed to the cluster.
Operators come in handy when teams want to implement a complex, custom configuration or deploy a special application that involves a lot of operational expertise.
