{{announcement.body}}
{{announcement.title}}

Introduction to Kubernetes Deployment Using Helm

DZone 's Guide to

Introduction to Kubernetes Deployment Using Helm

Check out this guide on how to use Helm and Helm charts to help with a Kubernetes deployment, including how to install, upgrade, and rollback charts.

· Cloud Zone ·
Free Resource

Get things done with this guide on Helm charts

Helm is a Kubernetes package manager and is used to manage Kubernetes applications. With the help of Helm, you can define, install, and upgrade a Kubernetes application. It can be used for reproducible builds of your Kubernetes application. It is like apt/yum/homebrew for Kubernetes.

To use Helm, you must have Kubernetes installed for using Helm charts and you should have knowledge about Kubernetes.

Installing Helm

Different ways to install Helm

  1. Download binaries from here based on your OS and add Helm to the path or navigate to folder containing Helm in terminal
  2. Using package managers

MacOS:

Shell




xxxxxxxxxx
1


 
1
$ brew install helm


Windows:

Using Chocolatey:

Shell




xxxxxxxxxx
1


 
1
> choco install kubernetes-helm


Shell




xxxxxxxxxx
1


 
1
$ curl https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 | bash


You can verify the successful installation of Helm by using the below command on the terminal:

Shell




xxxxxxxxxx
1


 
1
$ helm version


This command will give you version of Helm in below format:

Shell




xxxxxxxxxx
1


 
1
version.BuildInfo{Version:”v3.0.2", GitCommit:”19e47ee3283ae98139d98460de796c1be1e3975f”, GitTreeState:”clean”, GoVersion:”go1.13.5"}
2
 
          


Initialize Helm Charts

Charts are the packaging format used in Helm. A Chart is a collection of multiple files, folders, and templates to define multiple Kubernetes resources. Templates are the Kubernetes resource definitions and you can use the same chart for multiple different releases by injecting your dynamic values to the template. A template consists of various directives and you can customize them based on your need and inject values which are unique to your release. By this, you can reuse the same chart for all your releases by injecting dynamic values to the template which are specific to your release like Docker image name, replica count of that instance, and so on.

You may also enjoy: Deploy to Kubernetes With Helm

You can initialize the Helm chart repository with the official Helm chart repository or with any other repository by adding various Helm chart repository available:

Shell




xxxxxxxxxx
1


 
1
$ helm repo add stable https://kubernetes-charts.storage.googleapis.com/


You can update the above repo for changes by using:

Shell




xxxxxxxxxx
1


 
1
$ helm repo update
2
 
          


You can list down all the stable charts available in above repository by using below command, you can use any chart from them as base chart:

Shell




xxxxxxxxxx
1


 
1
$ helm search repo stable


Helm

Helm is used to install and manage applications on Kubernetes, so for using Helm, the Kubernetes cluster should be up and running. You can use minikube single node cluster for Kubernetes on a local machine or you can run Kubernetes single node cluster from Docker for desktop. If you are using Docker desktop on Windows you can right-click on the Docker icon in the system tray and go to settings and then navigate to Kubernetes and enable Kubernetes on the Docker desktop startup. This will enable a single-node Kubernetes cluster and you can verify by using below command:

Shell




xxxxxxxxxx
1


 
1
$ kubectl version


(Open new terminal after enabling Kubernetes)

Helm Charts

Helm chart contains all the definitions of all the resources required for running applications on Kubernetes. It contains definition templates for deployment, service, ingress, etc. A repository is a place where all the published charts are stored. You can add multiple repositories to Helm just like we did earlier in this tutorial.

The release is an instance of chart, and a new release is created when you install any chart. With every install of chart, a new release will be created with different release name.

Helm installs Kubernetes resources available in particular chart into Kubernetes cluster.

Searching Charts

There are two ways to find charts, one from the public Helm hub which contains charts from multiple repositories. You can search in Helm hub by using the below command by providing the complete name or partial name of the chart you want to find and this command will list down all the matching charts with that name. For example, if you want to search for MySQL chart

Shell




xxxxxxxxxx
1


 
1
$ helm search hub mysql


Another way is to search in the repos which you have already added to Helm. You can first list down all the repos added by you to Helm by using below command, this will list down all the repos configured in your Helm

Shell




xxxxxxxxxx
1


 
1
$ helm repo list
2
 
          


To search within all the repos listed by the above command, you can use this command:

Shell




xxxxxxxxxx
1


1
$ helm search repo mysql
2
 
          


Helm Install

You can install any Helm chart from the list provided by the Helm repositories.

Shell




xxxxxxxxxx
1


 
1
$ helm install <release-name> <chart-name>


Here, release-name  is optional. It is the name you want to give to your release and if you don’t provide the release-name  then you have to provide an another flag “— generate-name ”, then Helm automatically chooses release name for you and will print in the outcome of this command. The second option is the chart name. It is the name of the chart you want to install and you can find this name by searching on Helm hub or in configured repositories.

This command will create a new release with the name provided and install it on the Kubernetes cluster which means a new MySQL instance will be released on the Kubernetes cluster if you install a MySQL chart. If you want to release two MySQL databases, then install MySQL chart twice. It will release various resources like deployment pod, services, ingress and more, which are present in that chart to Kubernetes cluster. You can use any Kubernetes kubectl commands ( kubectl get pods — — to list all the released pods in Kubernetes cluster) to list the pods or you can use Helm commands to list releases. This is similar to installing all resources to Kubernetes one by one using kubectl APIs.

You can see all your releases with

Shell




xxxxxxxxxx
1


 
1
$ helm list
2
 
          


By installing using above command you are releasing default charts. If you want to modify the config, you can use the below command which will list all the configurations of that chart and you can modify any variable by providing a YAML formatted file during installation.

Shell




xxxxxxxxxx
1


1
$ helm show values stable/mysql
2
 
          


This will list down all the configuration and you can modify any by:

Shell




xxxxxxxxxx
1


 
1
$ echo '{mysqlPassword: admin, mysqlUser: admin}' > test.yaml $ helm install -f test.yaml stable/mysql


You can also use the “  — set ” flag instead of “ f-f ” for modifying variables on command line by providing multiple variables separated by comma. For example,

Shell




xxxxxxxxxx
1


 
1
$ helm install --set mysqlPassword=admin,mysqlUser=admin stable/mysql
2
 
          


So by Helm install, you can release all the resources available on chart definition on one go. If you want the same configuration to be repeated you can publish your charts and anyone can use that chart to release with the similar configuration on Kubernetes.

Helm Upgrade and Rollback

When you want to change the configuration of an existing release, then you can use the Helm upgrade command. This command will be used to update an existing release based on the new configuration you provide. Helm will only update those resources which are modified according to new config and left other resources in release unchanged. In this new config YAML file, you can update the value to any variable, you can provide a new Docker image or tag if you want to update release with newer image.

Shell




xxxxxxxxxx
1


 
1
$ helm upgrade -f newConfig.yaml <release-name> <chart-name>
2
 
          


You can list down all the values and check whether your new values are applied to release or not

Shell




xxxxxxxxxx
1


 
1
$ helm get values <release-name>
2
 
          


If something goes wrong and you want to roll back to some earlier version then it is very simple. You can first check the history of your releases by using the history command and, after choosing the right rollback revision from the history, you can rollback to that particular release using thesecommands:

Shell




xxxxxxxxxx
1


 
1
$ helm history <release-name> $ helm rollback <release-name> <release-version-number>
2
 
          


The release version number is the number corresponding to the release to which you want to rollback. The release number will have an increment of 1 every time you upgrade or rollback a release starting from one when you first install a release.

The Helm install command will finish without waiting for pods to come up, but if you want the command to wait for pods to come up and service to have an IP address then you can use below flag while installing

Shell




xxxxxxxxxx
1


 
1
--wait
2
 
          


You can also use timeout duration in seconds and the release will fail if Helm takes longer time while waiting for release to finish in Kubernetes cluster:

Shell




xxxxxxxxxx
1


 
1
--timeout=300
2
 
          


Helm Uninstall

If you want to uninstall a release from Kubernetes you can use Helm to uninstall it. By default Helm doesn’t keep the history of any uninstalled release.

Shell




xxxxxxxxxx
1


1
$ helm uninstall <release-name>


If you want to keep a history of any uninstalled release then you can do so by below flag while uninstalling

Shell




xxxxxxxxxx
1


 
1
$ helm uninstall --keep-history <release-name>
2
 
          


Using the “uninstalled” flag in the Helm list command, you can see all releases which were uninstalled using “keep history” flag and you can also use “all” flag to list all releases whether active or uninstalled with the “keep history” flag.

Shell




xxxxxxxxxx
1


 
1
$ helm list --uninstalled $ helm list --all
2
 
          


Create Your Own Chart

We've been working on predefined charts provided by Helm hub, but what if we want to create our own chart? To create your own chart Helm, provide a utility that will initialize your basic structure of chart.

Shell




xxxxxxxxxx
1


 
1
$ helm create customchart
2
 
          


This will create a folder named "customchart" and that folder will have below structure:

Plain Text




xxxxxxxxxx
1


 
1
customchart/ .helmignore Chart.yaml values.yaml charts/ templates/
2
 
          


Chart.yaml contains a description about the chart.

"charts/ folder" can contains other sub-charts and this folder is empty by default.

"values.yaml" is the YAML file that contains key-value pairs for the default values for the release configuration. It contains values for  replicacount (number of pods you want to instantiate in Kubernetes), image name, resource configurations (memory and CPU limits). You can override them by providing your custom config YAML file at the time of Helm install or upgrade as we discussed earlier while working with predefined charts.

"templates/ folder" contains multiple template files for deployment, services, ingress, etc. Helm evaluates all the template file by template rendering engine by combining them with default config values provided or with the custom values provided at the time of install. You can consider these files as static templates to Kubernetes resources which accepts dynamic values like docker image name, the number of replicas of any pod needed, etc. from values.yaml or at runtime and provide the resultant resource file to Kubernetes.

Deployment template in charts is a YAML file for deployment of a pod in Kubernetes. It is a template and accepts a Docker image name, replica count and other details related to pod deployment.

Service template is for setting up a service resource in Kubernetes which is used to allow load balancing between multiple pods of similar functionality and defines a policy by which to access pods. Service resource uses a selector to target a particular set of pods only. Selectors are nothing but the labels defined in pod deployments.

Ingress template is a template for ingress. Ingress helps to route HTTP and HTTPS requests from outside the cluster to services within the cluster. Traffic routing is controlled by rules defined on the Ingress resource.

You can delete all the templates and create your own from scratch as well only for the Kubernetes resources you want to release. You can install the above chart by navigating to the directory containing chart folder in terminal and by using the below command to install everything present in that chart. This will create a new release in Kubernetes based on all the configuration provided in the chart.

Shell




xxxxxxxxxx
1


 
1
$ helm install ./customchart
2
 
          


It will assign a name for a Kubernetes release and will show you this name in the outcome of the above command. You can check the actual template for each Kubernetes resources which are released on Kubernetes by using below command with the release name.

Shell




xxxxxxxxxx
1


 
1
$ helm get manifest <release-name>
2
 
          


You can uninstall any release by the same release name using below command.

Shell




xxxxxxxxxx
1


 
1
$ helm uninstall <release-name>
2
 
          


When you provide name of any resource in template file, consider it to be a unique. To make it unique you can append the name of the release along with the resource type to make it unique in Kubernetes cluster. This name field in Kubernetes is restricted to 63 characters only, so plan your release name accordingly.

Shell




xxxxxxxxxx
1


1
name: {{ .Release.Name }}-deployment


You can use any template directive by enclosing it in {{ and }} blocks

The above template directive will inject a name of release and append “ -deployment ” after it to make a name of a deployment resource in deployment template. “ Release ” object is a built in object in Helm and we are accessing “ Name ” from that object by using “ . ” operator. The initial “ . ” before “Release” signifies that this is a top-level object.

You can use any value from values.yaml file by using  {{ .Values.fieldname }}  directive in template file to inject any dynamic value into template.

Sometimes you are not sure what this template will become after rendering, so you can use the “debug” flag to just see the final template without installing anything to Kubernetes. You can use below command and this command will not install anything to the Kubernetes but will print final template after Helm rendering and injecting values into template.

Shell




xxxxxxxxxx
1


 
1
$ helm install --debug --dry-run ./customchart


If you want to use a single command for upgrade and install, which means install a release with this name if not already exists and upgrade otherwise using single command then you can use,  — install  flag, which directs Helm that if a release by this name doesn’t already exist, run an install, you can also use — force flag to replace any failed release.

Shell




xxxxxxxxxx
1


 
1
$ helm upgrade --install --force <release-name> ./customchart


You can check various directives and built-in objects in Helm and practice by creating your own charts or follow the auto-generated templates by Helm for basic structure of Helm release templates.

Further Reading

15+ Useful Helm Charts Tools

The Art of the Helm Chart: Patterns from the Official Kubernetes Chart

Topics:
kubernetes ,helm ,helm chart ,container deployment ,docker ,deployment automation

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}