Deploying workloads using Helm charts

In this section, we will show you how to use Helm charts in Kubernetes. Helm is the package manager for Kubernetes, which helps developers and SREs to easily package, configure, and deploy applications.

You will learn how to install Helm on your cluster and use Helm to manage the life cycle of third-party applications.

Getting ready

Make sure you have a Kubernetes cluster ready and kubectl configured to manage the cluster resources.

How to do it…

This section is further divided into the following subsections to ease the process:

• Installing Helm 2.x
• Installing an application using Helm charts
• Searching for an application in Helm repositories
• Updating an application using Helm
• Rolling back an application using Helm
• Adding new Helm repositories
• Deleting an application using Helm
• Building a Helm chart

Installing Helm 2.x

Let's perform the following steps to configure the prerequisites and install Helm:

1. Create a ServiceAccount by using the following command:

$ cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: ServiceAccount
metadata:
  name: tiller
  namespace: kube-system
EOF

2. Create a ClusterRoleBinding by using the following command:

$ cat <<EOF | kubectl apply -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: tiller
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
  - kind: ServiceAccount
    name: tiller
    namespace: kube-system
EOF

3. Download the Helm installation script. This install-helm.sh script will detect the architecture of your system and get the latest correct binaries to install Helm:

$ curl https://raw.githubusercontent.com/kubernetes/helm/master/scripts/get > install-helm.sh

4. Run the script to install Helm. The following command will install the two important binaries, Helm and Tiller, required to run Helm:

$ chmod u+x install-helm.sh && ./install-helm.sh

5. Run the init parameter to configure Helm with the service account we created in step 1. The --history-max parameter is used to purge and limit the Helm history, since without this setting the history can grow indefinitely and cause problems:

$ helm init --service-account tiller --history-max 200

This process with install the Helm server-side component Tiller in your cluster.

6. Confirm the Helm version by running the following command:

$ helm version --short

At the time of writing this recipe, the latest stable version of Helm was v2.15.1 and the next version, Helm 3, was still in beta. In the following chapters and recipes, we will base our instruction on the Helm 2.x version.

Installing an application using Helm charts

Let's perform the following steps to install a Helm chart from the official Helm repository location:

1. Before you install a chart, always sync the repository to pull the latest content. Otherwise, you may end up with the old version of the Helm charts:

$ helm repo update

2. Install an example chart, in this case, stable/mysql:

$ helm install --name my-mysqlrelease stable/mysql

Similarly, you can install other applications from the Helm charts stable repository or add your own repositories for custom charts.

Every time you install a chart, a new release with a random name is created unless specified with the --name parameter. Now, list the releases:

$ helm ls
NAME            REVISION UPDATED                 STATUS   CHART         APP VERSION NAMESPACE
my-mysqlrelease 1        Thu Aug 8 02:30:27 2019 DEPLOYED mysql-1.3.0 5.7.14        default

3. Check the status in the release, in our example, my-mysqlrelease:

$ helm status my-mysqlrelease

You will get the Deployment status and information on all resources.

Searching for an application in Helm repositories

Let's perform the following steps to search for an application you would like to deploy on Kubernetes from the Helm chart repositories:

1. Search for a chart in the repository. The following command will look for your search words in the Helm repositories that you have access to:

$ helm search redis
NAME CHART VER APP VER DESCRIPTION 
stable/prometheus-redis-exporter 3.0.0 1.0.3 Prometheus export
stable/redis 9.0.1 5.0.5 Open source, adva
stable/redis-ha 3.6.2 5.0.5 Highly available 
stable/sensu 0.2.3 0.28 Sensu monitoring 

2. Your search keyword doesn't have to be the exact name of the project. You can also search for keywords such as Storage, MQ, or Database:

$ helm search storage
NAME                 CHART VERSION APP VERSION DESCRIPTION ...
stable/minio         2.5.4 RELEASE.2019-07-17T22-54-12Z MinIO is a hi
stable/nfs-server-pr 0.3.0 2.2.1-k8s1.12 nfs-server-provisioner is an
stable/openebs       1.0.0 1.0.0 Containerized Storage for Containers

By default, your repository list is limited to the helm/stable location but later, in the Adding new Helm repositories recipe, you will also learn how to add new repositories to extend your search coverage to other repositories.

Upgrading an application using Helm

There are a couple of ways to use an upgrade. Let's perform the following steps:

1. Upgrade the release, in our case, my-mysqlrelease, with a newer chart version when available:

$ helm upgrade my-mysqlrelease stable/mysql

2. In the future, you may find a specific version of the application that is more stable in your environment or keep the installations identical in multiple clusters. In that case, you can update the chart version with your preferred chart version using the following command:

$ helm upgrade my-mysqlrelease stable/mysql --version 1.2.0

3. Confirm the chart version change using the following command. After upgrading the version in step 2, you should expect to see mysql --version 1.2.0:

$ helm ls
NAME            REVISION UPDATED                  STATUS   CHART       APP VERSION NAMESPACE
my-mysqlrelease 3        Tue Jul 30 22:44:07 2019 DEPLOYED mysql-1.2.0 5.7.14      default

4. See the history of revisions using the following command. Since we recently updated the chart version, you should see at least two revisions in the history:

$ helm history my-mysqlrelease stable/mysql
REV UPDATED             STATUS     CHART       DESCRIPTION
1   Oct 1 22:47:37 2019 SUPERSEDED mysql-1.3.3 Install complete
2   Oct 1 22:57:32 2019 SUPERSEDED mysql-1.3.3 Upgrade complete
3   Oct 1 23:00:44 2019 DEPLOYED   mysql-1.2.0 Upgrade complete

5. Use the helm upgrade function to update a parameter on an existing release by specifying a parameter using the --set key=value[,key=value] argument. The following command will set two MySQL password using the --set mysqlRootPassword parameter:

$ helm upgrade my-mysqlrelease stable/mysql --version 1.2.0 --set mysqlRootPassword="MyNevvPa55w0rd"

6. Confirm that the password is actually updated. You should expect to get the same password you set in step 4:

$ kubectl get secret --namespace default my-mysqlrelease -o jsonpath="{.data.mysql-root-password}" | base64 --decode; echo
MyNevvPa55w0rd

Now you have learned how to upgrade a Helm release with new parameters.

Rolling back an application using Helm

Let's perform the following steps to recall an upgrade and bring your application status to a previous revision:

1. List the revision history for your release, in our example, coy-jellyfish:

$ helm history my-mysqlrelease
REV UPDATED                 STATUS     CHART       DESCRIPTION
1   Tue Oct 1 22:47:37 2019 SUPERSEDED mysql-1.3.3 Install complete
2   Tue Oct 1 22:57:32 2019 SUPERSEDED mysql-1.3.3 Upgrade complete
3   Tue Oct 1 23:00:44 2019 SUPERSEDED mysql-1.2.0 Upgrade complete
4   Tue Oct 1 23:07:23 2019 SUPERSEDED mysql-1.3.3 Upgrade complete
5   Tue Oct 1 23:10:39 2019 DEPLOYED   mysql-1.2.0 Upgrade complete

2. Let's say you need to roll back from the last upgrade to revision 4. Roll back to a specific revision:

$ helm rollback my-mysqlrelease 4
Rollback was a success.

3. The revision history will be updated to reflect your rollback:

$ helm history my-mysqlrelease
 REV UPDATED                  STATUS     CHART       DESCRIPTION
...
 5   Tue Jul 30 22:44:07 2019 SUPERSEDED mysql-1.2.0 Upgrade complete
 6   Tue Jul 30 23:11:52 2019 DEPLOYED   mysql-1.3.0 Rollback to 4

Now you have learned how to review the release history and roll back a Helm release when needed.

Deleting an application using Helm

Let's perform the following steps to remove an application deployed with Helm from your Kubernetes cluster:

1. Use the helm ls command with the --all parameter to list all the releases, including deleted revisions:

helm ls --all
NAME REVISION UPDATED STATUS CHART APP VERSION NAMESPACE
my-mysqlrelease 6 Thu Aug 8 02:34:13 2019 DEPLOYED mysql-1.3.0 5.7.14 default

2. Delete a release using the --purge parameter. The following command will completely remove the application from your cluster:

helm delete --purge my-mysqlrelease

The preceding command will immediately terminate the Deployment and remove the Helm release from your cluster.

Adding new Helm repositories

By default, Helm only uses the official Helm/stable repository for lookups and often in the following chapters, we will need to add additional repositories from third-party vendors using the method explained in this recipe.

Let's perform the following steps to add additional Helm repositories to your source list:

1. Check the list of existing repositories. You should only see stable and local on the list:

$ helm repo list
 NAME   URL
 stable https://kubernetes-charts.storage.googleapis.com
 local  http://127.0.0.1:8879/charts

2. We need a persistent volume and authentication configured for our repository server. Create a file called customhelmrepo.yaml using the following content:

cat <<EOF >customhelmrepo.yaml
env:
 open:
 STORAGE: local
persistence:
 enabled: true
 accessMode: ReadWriteOnce
 size: 10Gi
 secret:
    BASIC_AUTH_USER: helmcurator
    BASIC_AUTH_PASS: myhelmpassword
EOF

3. Create a repository server using a persistent volume:

$ helm install --name my-chartmuseum -f customhelmrepo.yaml stable/chartmuseum

4. Get the service IP for chartmuseum. The following command will return an IP address, in our example, 10.3.0.37:

$ kubectl get svc --namespace default -l "app=chartmuseum" -l \
"release=my-chartmuseum" -o jsonpath="{.items[0].spec.clusterIP}"; echo
10.3.0.37

5. Add the new Helm repository to your list of repositories; in our case, the IP is 10.3.0.37:

$ helm repo add chartmuseum http://10.3.0.37:8080

6. Check the list of existing repositories:

$ helm repo list
NAME        URL
stable      https://kubernetes-charts.storage.googleapis.com
local       http://127.0.0.1:8879/charts
chartmuseum http://10.3.0.37:8080

There are many options available to host your chart repository. You can deploy a local repository using an open source Helm repository server called ChartMuseum, on an S3 bucket, GitHub pages, or a classic web server. For simplicity, we used Helm itself to deploy a server. You can find alternative hosting methods for Helm charts under the See also section.

Building a Helm chart

Let's perform the following steps to build a custom Helm chart to be published in your local chartmuseum repository:

1. Create a chart called mychart:

$ helm create mychart

2. Edit your chart structure as you like and test the templates for possible errors:
   

$ helm lint ./mychart
==> Linting ./mychart
[INFO] Chart.yaml: icon is recommended
1 chart(s) linted, no failures

3. Test your application using --dry-run:

$ helm install ./mychart --debug --dry-run

4. Build the Helm chart. By running the following command, you will generate a tarball package of your Helm repository from the mychart location:

$ helm package .

5. Replace the Helm repository server address with your Helm server and upload this Helm chart package using a URL:

$ cd mychart && curl --data-binary "@mychart-0.1.0.tgz" http://10.3.0.37:8080/api/charts

Now you have learned how to create, lint, test, package, and upload your new chart to your local ChartMuseum-based Helm repository.

How it works...

This recipe showed you how to install the Helm package manager and build your first Helm chart.

When we built the Helm chart in the Building a Helm chart recipe, in step 1, the helm create command created a couple of files as a template under the chart folder. You can start by editing these files or create them from scratch when you become more comfortable with the structure.

The helm create command creates the templates that construct our Helm chart. The contents and their functionality are explained here:

mychart 
├── Chart.yaml          --> Description of the chart
├── charts              --> Directory for chart dependencies
├── mychart-0.1.0.tgz   --> Packaged chart following the SemVer 2 standard
├── templates           --> Directory for chart templates
│   ├── NOTES.txt       --> Help text displayed to users
│   ├── _helpers.tpl    --> Helpers that you can re-use 
│   ├── deployment.yaml --> Application - example deployment
│   ├── service.yaml    --> Application - example service endpoint
└── values.yaml         --> Default values for a chart

In the Building a Helm chart recipe, in step 3, helm install, when used along with the --dry-run parameter, sends the chart to the server and returns the rendered template only instead of installing it. This is usually used for testing Helm charts.

In the same recipe, in step 4, the helm package command packages your complete chart into a chart archive, basically a tarball.

In step 5, we used the curl command to send the packaged tarball binary to our ChartMuseum server, an HTTP server, so it can serve our Helm chart archives when it receives GET requests from the helm command.

Now you have learned how to install Helm charts and create your Helm charts in your local repositories, you will be able to install the third-party charts required in the next chapters, as well as building your own artifacts in your CI/CD pipelines.

See also

• The Helm documentation: https://docs.helm.sh
• Alternative hosting methods for Helm charts: https://v2.helm.sh/docs/chart_repository/
• Getting started with a chart template: https://helm.sh/docs/chart_template_guide/
• Fields required to build the Chart.yaml file: https://v2.helm.sh/docs/chart_template_guide/

• J-Frog Container Registry, a powerful Hybrid Docker and Helm registry: https://jfrog.com/container-registry/