As we have seen, Kubernetes is a powerful and popular container-orchestration system. But as we’ve also seen, migrating to and setting up your applications on Kubernetes can be a complex, daunting task. Setting up a single application can involve creating multiple interdependent Kubernetes components – pods, services, deployments, and replica sets, and each component requires you to write a detailed YAML manifest file.
Enter Helm. Just like apt for Ubuntu or yum and rpm for Red Hat, Helm is a package manager for Kubernetes that allows you as a developer or an admin to more easily package, configure, and deploy applications and services into your Kubernetes clusters.
Helm is now an official Kubernetes project and is part of the Cloud Native Computing Foundation, a non-profit, open-source software foundation that promotes the adoption of cloud-native computing.
Helm Tasks and Components
Like any good package manager, Helm does all the following tasks:
-
Fetches applications and software packages from repositories
-
Installs apps and packages in the Kubernetes cluster
-
Automatically installs those apps’ dependencies
-
Upgrades the apps and their dependencies
Helm does all these using the following components:
-
Helm: a command line tool that offers a user interface to all Helm functionality.
-
Tiller(only in the previous version Helm2, now deprecated in Helm3): the server component that ran on the Kubernetes cluster.
Tiller listened for commands from Helm then executed the configuration/ upgrade/ deployment tasks on the cluster. But from Helm3, all this functionality is now handled directly by the Helm tool.
-
Charts: the Helm packaging format. We will dig into Charts in more detail in the next section
-
Charts Repo: the official repo for Helm charts. It is located in https://github.com/helm/charts
Helm Charts
Packages in Helm are called charts. A chart consists of a few YAML configuration files and some templates that are then changed into Kubernetes manifest files. The basic directory structure of a Helm chart is below, and you are advised to stick to this structure unless you are a pro and have good reasons for deviating from it:
chart-name/
charts/
crds/
templates/
chart.yaml
LICENSE
README.md
requirements.yaml
values.yaml
These files and directories are explained below:
-
chart-name/: this is the ‘root’ directory of the chart/ package within Helm (not within the OS). All the other directories and files are located inside this root. It’s name is usually simply the name of the software or application to be installed, e.g. ‘wordpress/’ or ‘nginx/’ or ‘postgres/’
-
charts/: this directory is typically used to store chart dependencies that are managed manually. However, it is advisable to rely more on the requirements.yaml to define and dynamically link dependencies.
-
crds/: this directory contains any Custom Resource Definitions
-
templates/: this directory contains template files that can be combined with configuration values taken from values.yaml and/ or the Helm command line. When Helm evaluates a chart, it will send all of the files in the templates/ directory to the template rendering engine. It then collects the results of those templates and sends them on to Kubernetes to create manifest files.
-
chart.yaml: a YAML file with metadata about the chart – chart name and version, maintainer information, the originating website, search keywords, etc. Read more about the chart.yaml’s contents and structure in the official documentation.
-
LICENSE: (optional) a plain-text license file for the chart.
-
README.md (optional) a readme file with useful information for users
-
requirements.yaml: a YAML file that lists the chart’s dependencies.
-
values.yaml: a YAML file containing the chart’s default configuration values
Note that ‘charts/’, ‘crds/’ and ‘templates/’ are reserved keywords within Helm. You cannot give these names to your objects.
Another important concept in Helm is release. A release is a single instance of a chart running in a Kubernetes cluster. You see, one chart (package) can be installed multiple times in the same cluster. And each time it is installed, a new release is created. So why would you install the same chart multiple times? The most common reason and use case is because you need to utilize different versions of the same software or application, for example, if you need to test your webserver on two nginx versions – 1.16 and 1.17.
Helm Installation
Helm is available for the 3 major OS’s – Linux, Windows and MacOS. There are 2 different ways to install Helm. We will only list these 2 ways here, since they are explained in detail in the official documentation guide:
- From the Helm Project, either as a binary release or as a script.
- Using package managers such as apt for Ubuntu, Chocolatey for Windows, or Homebrew for MacOS
That said, the most common installation method is via a package manager. The quick steps for installation on Ubuntu using apt are given below. The apt package for Helm can be found here, and the commands for installation are:
curl https://baltocdn.com/helm/signing.asc | sudo apt-key add -
sudo apt-get install apt-transport-https --yes
echo "deb https://baltocdn.com/helm/stable/debian/ all main" |
sudo tee /etc/apt/sources.list.d/helm-stable-debian.list
sudo apt-get update
sudo apt-get install helm
Conclusion
If you are using Kubernetes, you will certainly need the power of Helm when your project grows and when you’ll need to manage different configurations with rules and advanced features. This first part is the introduction to using Helm, as we introduced the tool and how to install it. In the second part (Everything you need to know about Helm – Part II), we are going to dive deep into more concepts like Helm versions and commands. We will also go through a sample installation and deployment of Nginx using Helm, so you can get an idea of how all these commands are used. We will use Ubuntu for this exercise and assume you already have Kubernetes and Helm3 installed.
Asad Faizi
Founder CEO
CloudPlex.io, Inc