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:
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
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
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-operatorversion: 9.3.1repos:- name: stableurl: https://kubernetes-charts.storage.googleapis.comdestinations:- name: defaultpath: ./
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 versionversion: 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 usedcomment: "You can add comments"- name: fluent-bitrepo_name: lifenversion: 2.8.0# If you temporary want to stop syncing a specific chartno_sync: true- name: nginx-ingress# No repo_name is specified, stable will be usedversion: 1.35.0# Change the destination to another one (declared in destinations section)dest: customrepos:# Stable is the default one- name: stableurl: https://kubernetes-charts.storage.googleapis.com- name: jetstackurl: https://charts.jetstack.io- name: lifenurl: https://honestica.github.io/lifen-chartsdestinations:- name: defaultpath: /my/absolute/path- name: custompath: ./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
charts:- name: cert-managerversion: 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 version with a git diff
- One place to manage them all
- Works well with monorepo
- Declarative configuration (YAML file)
Hope it will help you as it helps us at Qovery