Deploying applications to Kubernetes can be complex as you may be required to create multiple interdependent resources. This blog explains how Helm can help software professionals to package, configure and deploy applications onto Kubernetes.
Table of Contents:
What is Helm and why do we need it?
Helm is an open-source package manager for Kubernetes. Most software development processes need a package manager which can simplify installation and maintenance. However, with an increase in the number of components in an infrastructure, managing clusters in Kubernetes can become very complicated. This is where Helm comes into the picture as it wraps up all the components in a single package. It also helps automate software installation, configure software deployments and fetch relevant data. Let's take an example of an app that needs:
Deployments
Service to expose the application
Persistent volume to store data
Secrets to hold confidential data.
Now, every object of the application requires a separate 'yaml' file. To create these objects, we need to run the 'kubectl' command. Complications may arise in situations where a bug is introduced or we need to modify the value of secrets. In these situations, we need to rollback, which requires revisiting every file individually to keep them in a particular order.
This problem can be solved by creating one huge file and defining all the object resources in it. By doing this, we can avoid frequent rollbacks. But think in terms of the need to modify values in a large file. For example, what if we need to modify the persistent volume size from 10GB to 100GB?. Given the size of the file, we would need to make sure we are making changes in the right place, and also not introduce any new bugs.
Let's take the example of rpm. An application consists of configuration files, binary files, etc. Rather than placing all these files in an individual directory of our system, we can run one rpm command, which will take care of installing all configuration and binary files in an appropriate directory. Helm takes a similar approach to solve this problem in the previous scenario.
It wraps together all the necessary components (deployments, services, secrets, persistent volume) in a single package. Whenever we need to install these resources, we just need to trigger the requirement in Helm to install a package, and it will install all the corresponding resources. Also, we only need to modify a single file (values.yaml) to update all the resources that are packaged using Helm.
Advantages of using Helm
Application installation with a single command (helm install <application name>) even if it consists of thousands of objects.
One place to update/modify the resource values (values.yaml).
Upgrade your application with a single command (helm upgrade <application name>). Helm keeps track of individual objects that require updates.
Single command to rollback your application (helm rollback <application name>). It maintains records of updates made to the application, so it can rollback to the previous versions.
Single command to uninstall the app (helm uninstall <application name>). It keeps track of all the objects and knows which object needs to be removed.
Helm Installation
Prerequisites
A running Kubernetes cluster (For more info, refer here)
To install Helm on all the supported platforms, check the following documentation.
Helm Internals
Helm uses a command-line utility on your local system to perform Helm actions like install, upgrade, or rollback charts. Let us first understand what is a chart? Helm bundles all your related manifests into a chart, such as deployments, services, and pods. This chart contains all of Helm's instructions to create a Kubernetes object in your cluster.
When you install a chart, a release is created. Within each release, you can have multiple revisions. This chart is then passed to Helm, and it connects to Kubernetes API using kubeconfig (~/.kube/config) to create Kubernetes objects. Now, the next question is where does Helm store the metadata information (such as the installed release, the chart used, revision state), and the answer to that question is inside your Kubernetes cluster in the form of a secret.
To verify the installation, use the ‘helm list’ command to list all the releases. As discussed earlier, once the chart is installed, it’s deployed as a release.
If you want to uninstall the release, use the ‘helm uninstall’ command followed by the release name. Helm will take care of removing all the objects. If you wish to do it manually on the command line, then you will need to remove all the objects one by one.
Previously, we installed the chart using the default value. But that may not be your requirement all the time. Hence, you may also pull the chart and then modify 'values.yaml' file according to your requirements.
So far you have learned how to install an existing chart from ArtifactHUB and modify the values in those charts. In the next section, we will learn how to build our chart from scratch.
Building your first chart
In previous steps you have installed or modified a chart created by someone else, which is fine in most scenarios. But in cases where you have a custom application, or you need to customize your chart, you will be required to create your own custom chart.
The easiest way to get started with charts is by using ‘helm create’ command. This will create a chart structure for you.
First, start with the 'Chart.yaml' file. It contains metadata such as chart application version, etc.
apiVersion: When Helm3 was introduced, it came as a field 'apiVersion' to differentiate between Helm v2 vs. Helm v3 chart. For example, Helm v3 has field dependencies not present in Helm v2. So the general rule now is, all the charts built for Helm2 have the field set to v1 and for Helm3 it is v2.
appVersion: This is the version of the application that's inside your chart. For example, if you are installing MySQL, it is the version of the MySQL database. This field is for informational purposes only.
version: The version field holds the value of a chart's version which is independent of the app's version that you have deployed. This is independent of the version of the app you have deployed. This field helps you to keep track of the changes in the chart.
name: This field represents the name of the chart.
description: This field holds the description of your chart.
type: There are two types of charts: applications (default) and library. The application chart is used to build applications, whereas the library chart is used to provide utilities that help build charts.
This is all we need at this stage. Our Helm chart is ready to go. But before that, let's verify the files we created in the earlier steps, for example, 'deployments.yaml'. As you can see in deployments, all the values are static, for example, name: nginx, replicas: 1, or image, name: nginx.
As you can imagine, hardcoding these values is not a good solution, instead, we can fix this problem in Helm, by templating it. The way we can solve this problem is by using Helm templating language.
The first thing we will do is templatize the name, where we use Helm, to use deployment's name based on what user chose to name their release.
If we try to install Helm chart, then in this case the name should be picked from the release name which is 'my-demo-chart', so the name is 'my-demo-chart-nginx' (as you have appended -nginx in the end)
To templatize something we should add two curly brackets {{ }} and add something between these two curly brackets and this is called a 'template directive' which is a part of the Go Programming template language. For more information please check here.
To parameterize other variables we can use 'values.yaml' file. The 'values.yaml' file contains all the parameterized values.
To refer to these values we need to use 'Values' followed by key names. So for 'replicaCount', we will use 'Values.replicaCount' and 'Values.image.repository'.
By now you must be eager to run your first Helm chart but before doing that, check if your chart is working as expected. There are three ways of doing that:
helm lint: Linting helps you verify if the chart and yaml format are correct. Some common errors that linting helps with are, not enough white space or typo mistakes in the file. To do that, you need to pass the chartname (for example: mydemochart) to the ‘helm lint’ command, and it will give you a file, and tell you which file or line has the errors. Also, it recommends some of the best practices like using icons in the 'Chart.yaml'.
helm template: Ensures that the templating part is working as expected. With lint, you have verified there are no typing mistakes; By using templates, we can ensure that the templating stuff you have added in the 'deployment.yaml' is generating the correct output as expected i.e. 'Release.Name' is translating to the actual release name. The way it works is, it renders the chart template locally and displays the output.
--dry-run: 'helm lint' and 'helm template' command are enough to catch errors and ensure functioning of Helm with Kubernetes. However if there is an issue with the Kubernetes manifest file, it will pretend to install packages in a cluster and will catch the issue shown by Kubernetes during the actual run. This is a handy way to verify it before running the actual chart.
Once the chart is ready, we can share it with other team members or even globally, to promote collaboration. Developers on a global scale can help enhance the chart and fix bugs. In the next section, we will learn how to package a chart.
Packaging Chart
We have our chart ready, but if you want to share it with the rest of the team or the rest of the world, you need to package it.
To package your chart use the ‘helm package’ command. This command packages the chart in archive format (for example, mydemochart-0.1.0.tgz). The version number '0.1.0' is picked from the 'Chart.yaml' file.
Now that we have packaged our chart, it’s time to upload it to online repositories like GitHub or a bucket in S3, etc. These are the steps we need to follow:
Create a directory and then copy the file we have created.
The above command is going to generate the 'index.yaml' file. The file will contain information about the chart repository. The chart contains, a checksum, and a description of the chart. This is the file that Helm will read when we run a command like ‘helm repo’. It adds and points it to the chart repository.
In this blog, we have learned the basics of Helm and how to create a Helm chart. Helm is a powerful tool, and it greatly simplifies how package management works with Kubernetes.
Squadcast is an incident management tool that’s purpose-built for SRE. Your team can get rid of unwanted alerts, receive relevant notifications, work in collaboration using the virtual incident war rooms, and use automated tools like runbooks to eliminate toil.
What you should do now
Schedule a demo with Squadcast to learn about the platform, answer your questions, and evaluate if Squadcast is the right fit for you.
Curious about how Squadcast can assist you in implementing SRE best practices? Discover the platform's capabilities through our Interactive Demo.
Deploying applications to Kubernetes can be complex as you may be required to create multiple interdependent resources. This blog explains how Helm can help software professionals to package, configure and deploy applications onto Kubernetes.
What is Helm and why do we need it?
Helm is an open-source package manager for Kubernetes. Most software development processes need a package manager which can simplify installation and maintenance. However, with an increase in the number of components in an infrastructure, managing clusters in Kubernetes can become very complicated. This is where Helm comes into the picture as it wraps up all the components in a single package. It also helps automate software installation, configure software deployments and fetch relevant data. Let's take an example of an app that needs:
Deployments
Service to expose the application
Persistent volume to store data
Secrets to hold confidential data.
Now, every object of the application requires a separate 'yaml' file. To create these objects, we need to run the 'kubectl' command. Complications may arise in situations where a bug is introduced or we need to modify the value of secrets. In these situations, we need to rollback, which requires revisiting every file individually to keep them in a particular order.
This problem can be solved by creating one huge file and defining all the object resources in it. By doing this, we can avoid frequent rollbacks. But think in terms of the need to modify values in a large file. For example, what if we need to modify the persistent volume size from 10GB to 100GB?. Given the size of the file, we would need to make sure we are making changes in the right place, and also not introduce any new bugs.
Let's take the example of rpm. An application consists of configuration files, binary files, etc. Rather than placing all these files in an individual directory of our system, we can run one rpm command, which will take care of installing all configuration and binary files in an appropriate directory. Helm takes a similar approach to solve this problem in the previous scenario.
It wraps together all the necessary components (deployments, services, secrets, persistent volume) in a single package. Whenever we need to install these resources, we just need to trigger the requirement in Helm to install a package, and it will install all the corresponding resources. Also, we only need to modify a single file (values.yaml) to update all the resources that are packaged using Helm.
Advantages of using Helm
Application installation with a single command (helm install <application name>) even if it consists of thousands of objects.
One place to update/modify the resource values (values.yaml).
Upgrade your application with a single command (helm upgrade <application name>). Helm keeps track of individual objects that require updates.
Single command to rollback your application (helm rollback <application name>). It maintains records of updates made to the application, so it can rollback to the previous versions.
Single command to uninstall the app (helm uninstall <application name>). It keeps track of all the objects and knows which object needs to be removed.
Helm Installation
Prerequisites
A running Kubernetes cluster (For more info, refer here)
To install Helm on all the supported platforms, check the following documentation.
Helm Internals
Helm uses a command-line utility on your local system to perform Helm actions like install, upgrade, or rollback charts. Let us first understand what is a chart? Helm bundles all your related manifests into a chart, such as deployments, services, and pods. This chart contains all of Helm's instructions to create a Kubernetes object in your cluster.
When you install a chart, a release is created. Within each release, you can have multiple revisions. This chart is then passed to Helm, and it connects to Kubernetes API using kubeconfig (~/.kube/config) to create Kubernetes objects. Now, the next question is where does Helm store the metadata information (such as the installed release, the chart used, revision state), and the answer to that question is inside your Kubernetes cluster in the form of a secret.
To verify the installation, use the ‘helm list’ command to list all the releases. As discussed earlier, once the chart is installed, it’s deployed as a release.
If you want to uninstall the release, use the ‘helm uninstall’ command followed by the release name. Helm will take care of removing all the objects. If you wish to do it manually on the command line, then you will need to remove all the objects one by one.
Previously, we installed the chart using the default value. But that may not be your requirement all the time. Hence, you may also pull the chart and then modify 'values.yaml' file according to your requirements.
So far you have learned how to install an existing chart from ArtifactHUB and modify the values in those charts. In the next section, we will learn how to build our chart from scratch.
Building your first chart
In previous steps you have installed or modified a chart created by someone else, which is fine in most scenarios. But in cases where you have a custom application, or you need to customize your chart, you will be required to create your own custom chart.
The easiest way to get started with charts is by using ‘helm create’ command. This will create a chart structure for you.
First, start with the 'Chart.yaml' file. It contains metadata such as chart application version, etc.
apiVersion: When Helm3 was introduced, it came as a field 'apiVersion' to differentiate between Helm v2 vs. Helm v3 chart. For example, Helm v3 has field dependencies not present in Helm v2. So the general rule now is, all the charts built for Helm2 have the field set to v1 and for Helm3 it is v2.
appVersion: This is the version of the application that's inside your chart. For example, if you are installing MySQL, it is the version of the MySQL database. This field is for informational purposes only.
version: The version field holds the value of a chart's version which is independent of the app's version that you have deployed. This is independent of the version of the app you have deployed. This field helps you to keep track of the changes in the chart.
name: This field represents the name of the chart.
description: This field holds the description of your chart.
type: There are two types of charts: applications (default) and library. The application chart is used to build applications, whereas the library chart is used to provide utilities that help build charts.
This is all we need at this stage. Our Helm chart is ready to go. But before that, let's verify the files we created in the earlier steps, for example, 'deployments.yaml'. As you can see in deployments, all the values are static, for example, name: nginx, replicas: 1, or image, name: nginx.
As you can imagine, hardcoding these values is not a good solution, instead, we can fix this problem in Helm, by templating it. The way we can solve this problem is by using Helm templating language.
The first thing we will do is templatize the name, where we use Helm, to use deployment's name based on what user chose to name their release.
If we try to install Helm chart, then in this case the name should be picked from the release name which is 'my-demo-chart', so the name is 'my-demo-chart-nginx' (as you have appended -nginx in the end)
To templatize something we should add two curly brackets {{ }} and add something between these two curly brackets and this is called a 'template directive' which is a part of the Go Programming template language. For more information please check here.
To parameterize other variables we can use 'values.yaml' file. The 'values.yaml' file contains all the parameterized values.
To refer to these values we need to use 'Values' followed by key names. So for 'replicaCount', we will use 'Values.replicaCount' and 'Values.image.repository'.
By now you must be eager to run your first Helm chart but before doing that, check if your chart is working as expected. There are three ways of doing that:
helm lint: Linting helps you verify if the chart and yaml format are correct. Some common errors that linting helps with are, not enough white space or typo mistakes in the file. To do that, you need to pass the chartname (for example: mydemochart) to the ‘helm lint’ command, and it will give you a file, and tell you which file or line has the errors. Also, it recommends some of the best practices like using icons in the 'Chart.yaml'.
helm template: Ensures that the templating part is working as expected. With lint, you have verified there are no typing mistakes; By using templates, we can ensure that the templating stuff you have added in the 'deployment.yaml' is generating the correct output as expected i.e. 'Release.Name' is translating to the actual release name. The way it works is, it renders the chart template locally and displays the output.
--dry-run: 'helm lint' and 'helm template' command are enough to catch errors and ensure functioning of Helm with Kubernetes. However if there is an issue with the Kubernetes manifest file, it will pretend to install packages in a cluster and will catch the issue shown by Kubernetes during the actual run. This is a handy way to verify it before running the actual chart.
Once the chart is ready, we can share it with other team members or even globally, to promote collaboration. Developers on a global scale can help enhance the chart and fix bugs. In the next section, we will learn how to package a chart.
Packaging Chart
We have our chart ready, but if you want to share it with the rest of the team or the rest of the world, you need to package it.
To package your chart use the ‘helm package’ command. This command packages the chart in archive format (for example, mydemochart-0.1.0.tgz). The version number '0.1.0' is picked from the 'Chart.yaml' file.
Now that we have packaged our chart, it’s time to upload it to online repositories like GitHub or a bucket in S3, etc. These are the steps we need to follow:
Create a directory and then copy the file we have created.
The above command is going to generate the 'index.yaml' file. The file will contain information about the chart repository. The chart contains, a checksum, and a description of the chart. This is the file that Helm will read when we run a command like ‘helm repo’. It adds and points it to the chart repository.
In this blog, we have learned the basics of Helm and how to create a Helm chart. Helm is a powerful tool, and it greatly simplifies how package management works with Kubernetes.
Squadcast is an incident management tool that’s purpose-built for SRE. Your team can get rid of unwanted alerts, receive relevant notifications, work in collaboration using the virtual incident war rooms, and use automated tools like runbooks to eliminate toil.
What you should do now
Schedule a demo with Squadcast to learn about the platform, answer your questions, and evaluate if Squadcast is the right fit for you.
Curious about how Squadcast can assist you in implementing SRE best practices? Discover the platform's capabilities through our Interactive Demo.
