The basics of Helm
What is Helm?
Helm calls itself the package manager for Kubernetes. That’s true, but I think I can help simplify: Helm provides a way to package multiple Kubernetes resource templates that can be released, upgraded and rolled back together. It allows you to define a much larger and cohesive atomic deployment unit as a collection of multiple resources and dependencies.
Packaging Kubernetes resources with Helm
Helm requires a specific filesystem structure in order to work correctly. As of the time of writing, the following is the structure of a Helm chart:
Chart.yaml # A YAML file containing information about the chart
LICENSE # OPTIONAL: A plain text file containing the license for the chart
README.md # OPTIONAL: A human-readable README file
requirements.yaml # OPTIONAL: A YAML file listing dependencies for the chart
values.yaml # The default configuration values for this chart
charts/ # A directory containing any charts upon which this chart depends.
templates/ # A directory of templates that, when combined with values,
# will generate valid Kubernetes manifest files.
templates/NOTES.txt # OPTIONAL: A plain text file containing short usage notes
Let’s use a true example - this post is based on the following GitHub repository, specifically this Helm chart: https://github.com/brbarnett/much-todo-about-containers/tree/master/helm-charts/src/todo-app
There is a collection of Kubernetes resource manifest files in the
./templates directory that will all get deployed at the same time as a release.
Before we get started, make sure
kubectl is pointing at the correct Kubernetes instance with
kubectl config current-context, then initialize Helm:
helm init --upgrade --service-account default # required, otherwise you get a 'no available release name' error
helm repo update
Creating a new release
When creating a new Helm release in Kubernetes, you can pass in either a known chart name (e.g.,
stable/nginx-ingress) or a local chart directory. Since I’m just testing this from my local machine on an AKS cluster, I’ll use the directory here.
helm install ./helm-charts/src/todo-app \
--name todo-release \
What’s with the
--set web.replicas=6? Helm templates are not exactly Kubernetes resource manifests, but rather templates for them. It allows you to pass in configurable variables that dynamically render in final manifests prior to release. In this case, I have a value in my
values.yaml file that the
--set keyword is overriding.
Upgrading a release
As you upgrade your container images, rolling out changes atomically is easy - simply run the following
helm upgrade todo-release ./helm-charts/src/todo-app
The application and its dependencies you have deployed will upgrade atomically to the latest version based on your deployment strategy.
Rolling back a release
Now for some real power. Let’s say that a change made in this upgrade degraded system performance. No problem: roll back the upgrade with a simple
# get revision number from release history
helm history todo-release
# roll back to revision number 1
helm rollback todo-release 1
Here’s what the release history looks like after rollback:
This is obviously a very simple example - I’ll do a future post on deploying Kubernetes resources and Helm charts using VSTS Build & Release.
Share this post!