[Cloud native K8s series special article] One article speed through the actual combat Helm management tool

This article is a special article of K8s, mainly the introduction, warehouse, practical application, etc. Through this article: We will learn the basics, introduction, warehouse, practical application of Helm, etc.

In the previous articles, I have introduced some knowledge of cloud native entry and simple practical combat. Interested students can go to my cloud native column to learn, any door: [cloud native learning column]

A quick guide to Helm’s introduction, warehouse, practical application, etc.

Opening words: What is Helm?

Students who have used Ubuntu and CentOS are no strangers. ap-get under Ubuntu or [yum] under CentOS are both package management tools under the Linux system. With these two management tools, developers can manage dependencies between application packages, publish applications, and users can find, install, upgrade, and uninstall applications in a simple way.

So by analogy, Helm is [Kubernetes] ‘ apt-get/yum. Helm is a package manager for kubernetes developed by Deis. Each package is called a Chart, and a Chart is a directory.

Application publishers can package applications through Helm, manage application [dependencies] , manage application versions, and publish applications to software repositories.

Users can use Helm but do not need to understand the [Yaml] syntax of K8s and write application deployment files. They can download and install the required applications on kubernetes through Helm. That is, through Helm, you can use a single command to deploy and install it in your own Kubernetes cluster. Helm can also provide functions such as software deployment, deletion, upgrade, and rollback of applications.

Mainstay: Why do you need Helm?

Let’s first take a look at the difficulties that may be encountered when deploying cloud services directly with Kubernetes?

Kubernetes uses yaml files to describe and manage the configuration and deployment requirements of various components in the service, and each component corresponds to a yaml file. Cloud services are usually composed of multiple components. How to configure and handle the association between these components, that is, multiple yaml files, has become a must for Kubernetes applications.

When the cloud service upgrade only involves one or a few modules, the relationship between the new yaml file of the upgraded module and the existing yaml file will become more complicated, making it more difficult to configure and manage the upgrade using Kubernetes.

In addition, Kubernetes records the configuration information of components directly into the yaml file. From the point of view of describing components, this method is indeed relatively clear. However, when the deployment of cloud services faces multiple environments, such as different development, testing, and production environments (currently more common application scenarios), how to deal with the differences between these environment configurations? Develop and maintain a different set of yaml files for each environment? This obviously adds a lot of work.

Moreover, the yaml file of Kubernetes itself has no concept of version. When a deployment fails and needs to be rolled back to the previous stable version, which set of yaml files should be selected for processing has also become an additional problem that needs to be solved.

Therefore, Helm can solve these problems very well. Helm describes and manages cloud services through packages called Helm Charts.

One against one hundred: A deep dive into the Helm architecture

The architecture of Helm consists of Helm client, Tiller server and Chart repository; Tiller is deployed in Kubernetes, Helm client obtains the Chart installation package from the Chart repository, and installs and deploys it to the Kubernetes cluster.

1. Helm client

Helm client: This is a command-line tool for end users, the client is responsible for the following tasks:

  • Local chart development, management warehouse
  • Interact with the Tiller server, such as sending charts to be installed, requesting information about releases, requesting updates or uninstalling installed releases

The Helm client is written in Go and interacts with the Tiller server via the gRPC protocol.

2. Tiller server

The Tiller service is deployed in the Kubernetes cluster, and the Helm client interacts with the Tiller server and finally the Kubernetes API server. The Tiller server is responsible for the following tasks:

  • Listen for requests from the Helm client
  • Combining charts and configurations to build a release
  • Install in Kubernetes and track subsequent releases
  • By interacting with Kubernetes, update or chart

The Tiller server is also written in Go, and it uses the Kubernetes client library to communicate with Kubernetes.


First simply create a chart:

helm create myapp

//chart directory structure
# tree myapp/
    ├── charts
    ├── Chart.yaml
    ├── templates
    │   ├── deployment.yaml
    │   ├── _helpers.tpl
    │   ├── ingress.yaml
    │   ├── NOTES.txt
    │   ├── serviceaccount.yaml
    │   ├── service.yaml
    │   └── tests
    │       └── test-connection.yaml
    └── values.yaml

  • Chart.yaml is used to describe the relevant information of this Chart, including name, description information and version.
  • values.yaml is used to store the values ​​of variables used in template files in the templates directory.
  • NOTES.txt is used to introduce some information after the Chart is deployed, such as: how to use this Chart, list

Core Concepts: Three Magic Weapons of Helm

In the function above, there are three important concepts to understand:

  • chart: The information collection for creating Kubernetes application instances, helm package, contains all the elements of a k8s app running, such as service, deployment, configmap, serviceaccount, rbac, etc., which exist in the form of template files, combined with the values ​​file , and finally render a yaml file that can be executed by k8s;
  • repository: is a collection of charts for easy sharing and distribution.
  • release: release is a running instance of the helm chart in kubernetes. The same chart can be installed multiple times with different release names. For example, when multiple redis instances are required in the cluster, different configuration files can be used to install the redis chart.

Then, the running process of helm is as follows:

First, get the chart from the chart repository, then the developer configures his own values ​​file, and modifies the values ​​according to his own operating environment, and then the default values ​​file and the user values ​​file will be merged to form the final values ​​file; use the final values ​​file The values ​​file, render the chart template, form the yaml that can be executed by kubernetes, and finally call kube apply to submit the yaml to kubernetes.

In the above process, users only need to understand a little knowledge of configuration to complete the operation, and it is not so difficult. This is also the core design concept of helm.

Rising Sun: Actual Helm Demo

    1. Install helm

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=3.4.2-1

    1. Add a warehouse and find the redis chart

Add repository: helm repo add stable https://charts.helm.sh/stable
View the repositories that have been added: helm repo list
What charts are in the search warehouse: helm search repo stable
Update the repository list to the local: helm repo update 
Search redis: helm search repo redis
View redis chart details: helm show chart stable/redis
View redis values ​​( values : the configuration file equivalent to chart): helm show  values ​​stable/redis

Leave a Comment

Your email address will not be published. Required fields are marked *