helm-freeze - manage Helm Charts and Repositories with ease
Since the beginning of Kubernetes, a lot of different tools have emerged to manage Kubernetes deployments. They all propose their mindset, workflow, and usage.
Pierre MavroSeptember 24, 2020 · 3 min read
Pierre is an SRE and CTO of Qovery. He has 15+ years of experience in R&D, from the financial to the Ad-Tech industry; he has a strong knowledge of distributed and highly-reliable systems. He's also the MariaDB High-Performance book author.See all articles
Here is a small list of the most well-known:
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 override some part of existing Kubernetes YAML files since the 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 the "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 manage Helm Charts and repositories seamlessly.
The project is Open Source for anyone who is experiencing the same problem as us. Feel free to contribute.
Helm-freeze in action
Then, to initialize it and create its configuration file in the repository you want your charts to be stored in, run 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:
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
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 versions with a git diff
- One place to manage them all
- Works well with monorepo
- Declarative configuration (YAML file)
I hope it will help you as it helps us at Qovery