As more organizations start to prepackage their applications to be easily deployed on Kubernetes clusters, Helm is positioned to be the tool of choice. As apt/yum/dnf is to Linux, Helm is to Kubernetes.
Introduction
Helm is the official project of the Cloud Native Computing Foundation (CNCF), and provides a method of packaging the configuration around Kubernetes resources, including managing dependencies as applications. These configuration packages are called charts.
Helm actually has a nice description of its project goal on its main site: “Helm charts helps you define, install, and upgrade even the most complex Kubernetes application.”
To use Helm to deploy charts into a Kubernetes cluster, you need to deploy the server-side part of the project, called Tiller, into your cluster. Then you manage charts via the client side tool, which is called Helm (just like the main project).
Installation can be as simple as running one command. It does get more complicated if you have multiple security contexts and want the Tiller side to have a proper authentication setup.
$ helm init
Contents of a Chart
Instead of walking through all the steps to create a new chart, which is covered in Helm’s chart documentation, I thought it would be better to just walk through what is included in an existing package to show what is and isn’t in a chart.
The first thing to note is that a chart does not include any actual binaries—It is the metadata needed to install and configure one or more Kubernetes resources to work.
The directory structure is fairly straightforward. The top-level directory is the name of the package, and there are only two required files. Those files are Chart.yaml, which includes all the information about the chart, and values.yaml which is the default configuration values like memory size, or tags to have on the pod.
Sample entries in Charts.yaml
# name and version are all that is required
name: sweetcode-chart
version: 1.2.3 # Version of the chart
# the rest are optional
description: A simple short description.
keywords:
- A list of keywords about this project (optional)
home: http://projects.home.page/
sources:
- https://github.com/source/code
maintainers:
- name: John Doe
email: [email protected]
url: http://example.com
engine: gotpl # gotpl is the default template engine if none are specified
icon: https://dev.w3.org/SVG/tools/svgweb/samples/svg-files/w3c.svg
appVersion: 1.2.3 # version of the app doesn’t need to match chart version
deprecated: false
tillerVersion: ">2.0.0"
While the values.yaml file is required, there are no default configuration values that are required. It really depends on the application that is being referenced.
To actually have something deployed by the chart when it is installed by Helm, there will need to be files in the templates directory which combine to form the configuration information for the actual pod that Kubernetes is running, including what containers to load, as shown in the example.
Example file structure that is the MongoDB chart maintained by Bitnami
$ find ./mongodb -type f ./mongodb/Chart.yaml ./mongodb/.helmignore ./mongodb/README.md ./mongodb/OWNERS ./mongodb/templates/deployment.yaml ./mongodb/templates/svc.yaml ./mongodb/templates/NOTES.txt ./mongodb/templates/secrets.yaml ./mongodb/templates/pvc.yaml ./mongodb/templates/_helpers.tpl ./mongodb/values.yaml
As you can see, there are additional files I did not describe that can be included to provide an even more robust application. All the files listed above (plus a couple more) are covered in the developing charts documentation on Helm’s site.
Installing a Chart
There is an hub on KubeApps which is the default location for people and companies to link to existing Kubernetes applications that are packaged for use by Helm.
The first step is to ensure you have the latest list of applications in the hub.
$ helm repo update
The next step is to install something. Pulling from stable is always a safe place to start.
$ helm install stable/mysql
At this point, if you want to get a basic list of features in the stable/mysql package, you can inspect it.
$ helm inspect stable/mysql
Every time you install an app, it creates an independent release, so multiple copies of the same application can be deployed and running. To review how to list releases and many of the other options available to work with applications (charts), check out the Using Helm section of the documentation site.
Conclusion
Prepackaged applications in the Kubernetes space are a key feature that will aide in Kubernetes adoption in more conservative and risk-averse organizations. Package management was a key ingredient in the success of Linux, and a central hub of preconfigured applications was key to containers taking off in popularity as Docker brought them into the mainstream.
