Question ❓

K8s is known to be an excellent platform for supporting cloud native applications, with many resource types pod, Deployment, Service, ingress, Namespace, etc. In addition, the deployment mode of K8S is declarative, which means that when we use K8S deployment service, we have to specify resource specifications (spec), such as resource name, expected number of copies, file mount, etc. These specifications and meta information are written into the deployment file (usually in YML format). With so many resource types and so many specification conventions, it is possible to often involve complex yML files (sometimes both physically and mentally) when deploying K8S services. So is there a tool that can help us get as much relief as possible 🤔?

An overview of

What is Helm?

Helm is a Kubernetes package manager that manages our applications through a concept called “Helm Charts” to help you define, install and upgrade even the most complex Kubernetes applications. As the problem described at the beginning of this article, using Helm is a good way to manage application deployment when many resource files are involved in our application deployment in K8s.

The characteristics of the Helm

In summary, Helm has four features to help us manage K8S applications more easily: complexity management, easy upgrade, easy distribution, and rollback.

Complexity management

Even k8S applications that are very complex or involve many resource files can use Helm to define corresponding Charts (Helm Charts), and the Helm makes the installation/deployment of the application repeatable, ensuring that the same operation is performed whenever the application is deployed. We can even use Helm as the only deployment mode to achieve the simplification of permissions, security, and ease of management.

Easy to upgrade

Helm also provides very simple application upgrade operations, and the Helm automatically maintains the version history of the application during the upgrade process, which makes it easy to manage and view the version history information of the application.

Distribution of simple

Helm also provides the management of the Charts of the application, which can be distributed to a dedicated Charts repository (Harbor, remote file system, etc.) for versioning and unified management.

The rollback

Helm stores the deployed version history of our application, and on top of that, Helm also supports easier application rollback operations that can be easily rolled back to older versions of the application distribution using Helm Rollback.

Helm installation

👇 👇 👇

The helm is currently available in two major versions, Helm2 and Helm3. Helm2 architecture is more complex (involving client and server and the installation of the two interactive components), but Helm3 is simplified, in the process of using Helm3 only need to involve the client, and now Helm3 has gradually become the mainstream, so this article mainly introduces the installation and use of Helm3.

The Helm provides a variety of installation methods. This article mainly describes how to use themScript installationAnd on Mac and Windows.

Script Installation (Linux operating system)

Helm now has an installation script that automatically pulls the latest version of Helm and installs it locally. You can grab this script and execute it locally. Its good documentation will let you know what the script does before it executes.

$ curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3
$ chmod 700 get_helm.sh
$ ./get_helm.sh
Copy the code

If you want to directly perform the installation, run curl https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 | bash.

Install Helm on the Mac

Members of the Helm community contribute a scenario for building Helm at Homebrew, which is usually up to date.

brew install helm
Copy the code

Install the Helm in Windows

Installing Helm on a Windows system first requires making sure you have Chocolatey installed (see here for details on how to install Chocolatey). Members of the Helm community contribute a Helm package to build in Chocolatey, and the package is usually up to date.

choco install kubernetes-helm
Copy the code

For more installation methods, see the official documentation of the Helm.Helm. Sh/useful/docs/int…

Try a Helm

Create a Helm Charts

We know that Helm manages all the resource files that we want to deploy the service to, so it would be a hassle to just manually create templates for all the resource files, but Helm provides commands to help us quickly generate Helm Charts templates. Run the following command to create a Template for Helm Charts:

helm create NAME [flags]

Create a helm Charts

As shown above, we created a Helm Charts template with releaseName named TechFlower.

An overview of the charts

After creating charts, we can see that a new folder with releaseName has been created under the current directory of the run name, which is the Helm Charts file. Let’s take a look at the internal structure of charts:

Internal structure of Charts

The Charts folder is divided into four main sections:

Chart.yml:

This file contains the chart’s description and meta information:

Charts. Yaml file contents

Charts directory

Charts/directories can contain other charts (called subcharts).

The template directory

The templates/ directory contains template files. When Helm installs Chart, all files are sent to the Templates/directory through the template rendering engine. Then collect the results of the template and send them to Kubernetes:

Template file for the service resource

There are a number of resource template files in the Templates directory, such as the Service template file shown above, where key fields are replaced with placeholder text. This is a key part of the template file. Define a basic framework for the resource, and then specify parameters to replace placeholder text in the templates when you install Charts.

values.yaml

The values. Yaml file defines a set of default template parameters. If the template parameters are not specified when installing Charts, helm will replace the placeholder text declared in the template file with the values in this file as the default values.

Values. Yaml File contents

Install the helm charts

Helm provides installation commands that allow us to quickly install Charts into the K8s cluster. The charts we created can be installed with the following command:

helm install [NAME] [CHART] [flags]

As shown above, helm Charts is installed using the helm install command. In the command, there is a –wait parameter, which means that the command will block until all K8s resources are successfully started (see the official helm command line documentation for more parameters).

See the resources

After installing the Helm Charts resources, we can verify the installation by looking at the resources in the K8s cluster:

As you can see, the resource files defined in our Charts file are already installed in the K8s cluster.

In addition to helping us install charts into THE K8s cluster, Helm also manages a series of versions of the installed charts (releaseName), through which we can perform some o&M operations on Helm application. To view the version records of installed Charts in K8S, run the following command:

helm history RELEASE_NAME [flags]

As shown above, we see the version history of the Charts we installed, and since we only installed once, there is only one record in the version history.

Upgrade release

We know that after installing Helm Charts, Helm itself will maintain a charts release history list. When we modify the files in charts and want to reinstall (upgrade) charts, we can use the following command to upgrade the installed Charts:

helm upgrade [RELEASE] [CHART] [flags]

In the following output, we can see that the current Revision of Release is 2. Use the helm History command again to check the historical version of Release:

We can see that there are currently two histories for Release.

Roll back the release

With the version history of the installed Charts, Helm also provides a convenient release rollback, which can be done with the following command:

helm rollback [REVISION] [flags]

As shown above, we roll back the current release version to 1. Then we’ll look at the history of release again:

We can see that a new history is added to the Release history and is described as a rollback operation. Thus, Helm provides a better rollback mechanism.

Remove the release

helm history RELEASE_NAME [flags]

Helm also provides the operation to delete release by using the following command to delete release and all K8s resources defined in charts together:

After the deletion, we can verify that the previously installed resources still exist:

As you can see, both the release history and the K8s resources have been deleted by us.

Common Commands

In addition to the few commands described above, Helm provides many other efficient commands.

View the render result of the Helm template

helm template [NAME] [CHART] [flags]

You can see the output of the parameter rendered helm template.

Get the resource Yml that is released in the cluster

helm get manifest RELEASE_NAME [flags]

As shown above, the resource YML in Release is currently deployed in the cluster. We can also print the Yml description of the release of the specified historical version with — Revision int, for example: helm Get manifest Techflower — Revision 1

Commands like helm get manifest are: helm get all, helm get extension, helm get annotation, helm get hook.

conclusion

The appearance of Helm enables us to manage our K8s resource files more conveniently, and our K8s resource deployment has the effect of versioning, from which we can see the resource details of historical versions, and we can quickly roll back online resources through the versioning provided by Helm. In addition, there are many tools around Helm to manage Charts files, such as Harbor, which allows centralized and versioned management of Charts files. For details, see the Helm warehouse.