Helm 3: A More Secured and Simpler Kubernetes Package Manager
What is Helm?
Helm helps you manage Kubernetes applications. Helm Charts helps developers and operators to easily define, install, and upgrade even the most complex Kubernetes application.
Below are the three big concepts regarding Helm.
- Chart — A chart is a Helm package. It contains all resource definitions necessary to run an application, tool or service inside the Kubernetes cluster.
- Repository — A repository is a place where charts can be collected and shared.
- Release — Release is an instance of a chart running in a Kubernetes cluster. One chart can often be installed many times in the same cluster and each time it is installed, a new release is created.
Registry — Helm Registry stores Helm charts in a hierarchy storage structure and provides a function to orchestrate charts from the existing charts. To deploy and configure registry, refer to this.
- It helps to find and use popular software packaged as Kubernetes charts
- Share your own applications as Kubernetes charts
- Manage releases of Helm packages
- Create reproducible builds of your Kubernetes applications
Changes since Helm2
Helm3 includes following major changes:
1. Client-only architecture
Helm 2 is a client-server architecture with the client called as Helm and the server called as Tiller. The client interacts with the Tiller and the chart repository. Tiller interacts with the Kubernetes API server. It renders Helm template files into Kubernetes manifest files, which it uses for operations on the Kubernetes cluster through the Kubernetes API.
Helm 3 has a client-only architecture with the client still called as Helm. It operates similar to Helm 2 client, but the client interacts directly with the Kubernetes API server. The in-cluster server Tiller is removed in Helm 3.
2. No need to initialize Helm
Initializing Helm is obsolete in version 3. i.e. Helm init was removed and you don’t need to install Tiller in the cluster and set up a Helm state before using Helm. A Helm state is created automatically whenever required.
3. Chart dependency updated
In Helm 2, chart dependencies are declared in requirements.yaml, as shown in the following example:
- name: mysql
Chart dependencies are consolidated in Helm 3, hence moving the dependency definitions to Chart.yaml.
4. Chart value validation
In Helm 3, values passed to a chart during any Helm commands can be validated against a JSON schema. This validation is beneficial to help chart consumers avoid setting incorrect values and help improve chart usability. To enable consumers to avoid setting incorrect values, add a schema file named values.schema.json in the chart folder.
Following commands call the validation:
5. Helm test framework updates
Helm 3 includes following updates to the test framework (helm test):
- Users can define tests as job resources.
- The test-failure hook was removed.
- The test-success hook was renamed to test, but the alias remains for test-success.
- You can dump logs from test pods with — logs flag.
Helm 3 is more than just removing Tiller. It has a lot of new capabilities. There is little or no difference from CLI or usage point of view in Helm 3 when compared with Helm 2.
- A running Kubernetes cluster.
- The Kubernetes cluster API endpoint should be reachable from the machine you are running Helm commands.
- Download binary from here.
- Unpack it (tar -zxvf helm-v3.0.0-linux-amd64.tgz)
- Find the helm binary and move it to its desired destination (mv linux-amd64/helm /usr/local/bin/helm)
From there, you should be able to run the client command: ‘helm help’.
Note: We will be using Helm version 3.0.0
Deploy a sample Helm Chart
Use below command to create new chart named mysql in a new directory
After running above command, Helm creates a directory with the following layout:
It creates a Chart.yaml file containing global variables for the chart such as version and description.
Then comes templates directory. There you put all the *.yaml files for Kubernetes. Helm uses Go template markup language to customize *.yaml files. Helm creates three default file types: deployment, service, ingress. All the files in this directory are skeletons, which are filled with the variables from the values.yaml when you deploy your Helm chart. File _helpers.tpl contains your custom helper functions for variable calculation.
By default, Helm creates an nginx deployment. We will customize it to create a Helm Chart to deploy mysql on Kubernetes cluster. Add new deployment to the templates directory.
Also, let’s create PVC which is used in deployment by just adding below file to the templates directory.
Helm runs each file in the templates directory through Go template rendering engine. Let’s create service.yaml for connecting to mysql instance.
Update values.yaml to populate the above chart’s templates.
After adding above deployment files, directory structure will look like:
To render chart templates locally and display the output to check if everything is correct:
Execute the following helm install command to deploy our mysql chart in the Kubernetes cluster.
Now the chart is installed. Note that installing a Helm chart creates a new release object. The release above is named mysql-release.
To keep a track of a release’s state, or to re-read configuration information, you can use Helm status:
Additionally, to create a package, use below command which requires path for chart (which must contain a Chart.yaml file) and then package that directory
This command creates an archive like mysql-0.1.0.tgz, with which you can share your chart with others. For instance, you can upload this file to the Helm repository.
You can also delete the sample deployment using delete command. For example,
Upgrade a release
Helm provides a way to perform an install or an upgrade as a single command. Use Helm upgrade with the — install command. This will help Helm to see if the release is already installed. If not, it will run an install. If it is, then the existing release will be upgraded.
Originally published at https://www.velotio.com.