Since the beginning of Kubernetes, a lot of different tools emerged to manage Kubernetes deployments. They all propose their own mindset, workflow, and usage.

Here is a small list of the most well-known:

• Helm
• Kustomize
• Skafold
• ArgoCD

Dozens of solutions exist, they all have their pros and cons, but Helm and Kustomize look to be the two favorites chosen by the community.

Kustomize has been integrated directly into kubectl binary and allows to directly override some part of existing Kubernetes YAML files since 1.14 version. Helm allows creating “Charts” (a set of Kubernetes YAML template files) to ease the deployment process and easily share them with community members with Helm Hub (https://hub.helm.sh/).

The pain of managing helm charts

More than 1k Helm repositories and charts exist. Such a large amount of Helm configuration files is painful to maintain for a DevOps team. More especially when this team starts to use a couple of them. In my previous experiences I saw many ways of managing Helm Charts. Often as git submodules, coping the whole chart content in a git repo, or having a custom script to manage them.

In any case, a tool was missing to maintain them easily. With Helm, you can manage dependencies in a given chart, but not pin the chart version you want to use. Like what we can do in most of the programming languages. Here is an example in Rust with Cargo (the dependency manager):

[dependencies]
chrono = "0.4.11"
cmd_lib = "0.7.8"
git2 = "0.13.8"
walkdir = "2.3.1"
itertools = "0.9.0"
base64 = "0.12.3"
...

E.g: here we are using a lib called “base64” in “0.12.3” version. Everything is explicit and no surprises can happen.

Plus, combined with a VCS like Git, it helps to track changes over time. Which is convenient in case of non-working/not expected (delete as appropriate) changes.

Helm-freeze to the rescue

I created helm-freeze to seamlessly manage Helm Charts and repositories.

The project is Open Source for anyone who is experiencing the same problem as us. Feel free to contribute.

Helm-freeze in action

You can install helm-freeze with Brew (MacOSx), with Yay (Arch Linux), or directly downloading the binary on GitHub.

Then, to initialize it and create its configuration file in the repository you want your charts to be stored in, run init:

helm-freeze init

The configuration file will look like this:

charts:
  - name: prometheus-operator
    version: 9.3.1

repos:
  - name: stable
    url: https://kubernetes-charts.storage.googleapis.com

destinations:
  - name: default
    path: ./

In three points:

• charts: list of charts with their associated version
• repos: name of repos, and their URL (stable is the default one)
• destination: the path where you want your charts to be stored

Now see a complete configuration example:

charts:
    # Chart name
  - name: cert-manager
    # Chart version
    version: v0.16.0
    # The repo to use (declared below in the repos section)
    repo_name: jetstack
    # No destinations is declared, the default one will be used
    comment: "You can add comments"
  - name: fluent-bit
    repo_name: lifen
    version: 2.8.0
    # If you temporary want to stop syncing a specific chart
    no_sync: true
  - name: nginx-ingress
    # No repo_name is specified, stable will be used
    version: 1.35.0
    # Change the destination to another one (declared in destinations section)
    dest: custom

repos:
    # Stable is the default one
  - name: stable
    url: https://kubernetes-charts.storage.googleapis.com
  - name: jetstack
    url: https://charts.jetstack.io
  - name: lifen
    url: https://honestica.github.io/lifen-charts

destinations:
  - name: default
    path: /my/absolute/path
  - name: custom
    path: ./my/relative/path

The remaining command to sync locally the charts is:

helm-freeze sync

That’s it. You can now commit everything to keep track of changes. To get a new version of a chart, update the version number and run again helm-freeze sync.

charts:
  - name: cert-manager
    version: v0.16.1

Conclusion

Managing charts is now easy with helm-freeze. In our day to day job, it solves several issues we encountered in the past:

• Follow GitOps philosophy
• Know exactly what has changed between 2 charts version with a git diff
• One place to manage them all
• Works well with monorepo
• Declarative configuration (YAML file)

See helm-freeze on Github

Hope it will help you as it helps us at Qovery

Engineering