Tools You Can Use To Manage Your Helm Releases Declaratively

Tue, Apr 19, 2022

We regularly get questions from people who want tools or methods to manage their Helm releases in an environment. This post provides some insight and direction to help people get started.

Why Helm Doesn't Have Tools To Do This

You might wonder, why doesn't Helm provide tools to do this out of the box?

Helm is a package manager. We often compare it to package managers for other platforms like apt, yum, zipper, homebrew, and others. All of these projects, Helm included, keep their scope within the realm of package management.

Managing how instances of packages are run in an environment is a separate concern and one people have varying ideas about. For example, some people use Ansible, others use Terraform, some use both, and some use something entirely different. Different tools can even use different methods (e.g. some are push based and others pull based). All of these are able work with the same package managers.

The Helm project strives to provide a package manager that works well with various other tools that can use a variety of different methods to manage releases.

Declarative and Imperative

In the Kubernetes space we talk about declarative management. If you're not familiar with the concept, here is a brief explanation.

With declarative management you declare to the system what you want the end state to look like. For example, that you want X number of instances of your workload to be running. The system then works to make this a reality and usually reports status on the progress of making the declared status a reality. Over time, the way the system makes the declared state a reality can change without the need for what you declare or the status of the progress to change.

Imperative management has to do with telling the system what to do step by step. Instead of declaring what you want you tell the system each step to take to achieve the end goal.

Kubernetes provides a means to do both declarative and imperative management of resources. As the Kubernetes community tends to prefer declarative management, when possible, the rest of this post is going to focus on declarative tools you can use with Helm.

Tools

The Kubernetes ecosystem has produced numerous projects of various styles to help you declaratively manage your Helm releases. To illustrate the options we will look at sister projects to Helm in the Cloud Native Computing Foundation (CNCF) and some more general open source projects. You can find more options in the CNCF Landscape.

CNCF Projects

The scope of this section is limited to graduated and incubating CNCF projects. There are over 100 CNCF projects and many of them are sandbox projects. You can learn more about the differences between types of projects in the maturity level explanation. The following projects are worth looking at:

• Flux Helm Controller - Flux is a collection of projects that enable GitOps. One of the components provides a GitOps method to manage Helm releases. Flux natively supports Helm.
• Argo CD - The Argo project defines itself as providing "Open source tools for Kubernetes to run workflows, manage clusters, and do GitOps right." Argo CD is focused on declarative continuous delivery and has the ability to work with Helm charts.

Other Projects

There are many projects beyond the CNCF projects you can use to help you manage your Helm releases. The following set is an example and not exhaustive.

• Helmfile - A declarative spec for deploying Helm charts.
• Captain - A Helm controller.
• Terraform Helm provider - Enables you to manage Helm charts through Terraform.
• Orkestra - Built on other tools in this list, Orkestra adds a robust dependency graph for a related group of Helm releases and their subcharts, as well as a reverse DAG for specifying dependency requirements for rollbacks.
• Fleet - A GitOps tool chain that works with Kubernetes manifests, Helm charts, and Kustomize.

High-Level Tool Comparison

There are some differences between the tools we've looked at so far. The following table provides some insight into their differences. This is not exhaustive and you should evaluate any tools you use yourself.

Note, this comparison is from when the blog post was published. Projects change over time and the feature set may change over time. You should evaluate the projects in their current state before choosing one.

Conclusion

If you want to use a configuration manager with your Helm and Kubernetes configuration there are many choices. While the Helm project doesn't endorse one project over another, we do suggest using a configuration manager when it's appropriate.

Scott Rigby, Matt Farina
@scottrigby, @mattfarina