Practical familiarity with the package manager for Kubernetes - Helm

The article is a logical continuation of our recent publication on the history of the package manager for Kubernetes - Helm . This time we will again address the issues of the structure and functioning of the current Helm ( version 2.x ), as well as the charts and repositories it manages, and then we move on to the practice of installing Helm into the Kubernetes cluster and using the charts.

Introduction

Helm - a tool for managing charts.
')
The chart describes the required data set for creating an application instance in the Kubernetes cluster. It can have nested charts and be used both to describe full-fledged services consisting of many dependent resources, and to describe individual independent components. For example, the stable / gitlab-ce chart describes a comprehensive solution using independent redis and postgresql charts.

The chart can be set an unlimited number of times in the same cluster. Thus, the description of the application logic in different environments can and should be stored in one chart.

The client part of Helm is responsible for the formation of the chart and the transfer, together with the user parameters, to the Tiller component located in the Kubernetes cluster. In turn, Tiller is responsible for the life cycle of the instance of the launched chart, release. (Just in case, let me remind you that in the next major update of Helm - version 3 - Tiller will no longer be.)

And now - first things first.

Installation and Update

Kubernetes is required to work with Helm. You can use a locally installed Minikube (see also “ Getting Started in Kubernetes using Minikube ”) or any other available cluster.

Let's start with installing the client: choose the release , download and unpack the archive for your system, transfer the executable file ...

$ curl https://storage.googleapis.com/kubernetes-helm/helm-v2.10.0-linux-amd64.tar.gz | tar -zxv $ sudo mv linux-amd64/helm /usr/local/bin/helm 

Next, install Tiller in the cluster. By default, Tiller is installed in the kubectl context kubectl ( kubectl config current-context ), in the kube-system namespace , but this can be changed using the appropriate options and environment variables — they are described in the help ( helm init --help - help). Perform the installation and look at the created resources in the cluster:

 $ helm init $HELM_HOME has been configured at /home/habr/.helm. (Use --client-only to suppress this message, or --upgrade to upgrade Tiller to the current version.) Happy Helming! $ kubectl get all --selector=name=tiller --namespace kube-system NAME READY STATUS RESTARTS AGE po/tiller-deploy-df4fdf55d-h5mvh 0/1 Running 0 5s NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE svc/tiller-deploy 10.107.191.68 <none> 44134/TCP 5s NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE deploy/tiller-deploy 1 1 1 0 5s NAME DESIRED CURRENT READY AGE rs/tiller-deploy-df4fdf55d 1 1 0 5s 

Now Tiller is installed in a cluster and is ready for release management, interaction with the Kubernetes API.

Note : When installing and upgrading (the --upgrade option) Tiller, you can set a specific image instead of using the latest stable release by default. The name of an arbitrary image is determined by the --tiller-image option, and with the --canary-image option, a --canary-image will be used when Tiller rolls out. The canary image allows you to use Tiller, the version of which code corresponds to the master branch.

The service data is stored in a cluster in special resources, ConfigMaps , so deleting and reinstalling Tiller does not result in the loss of data from previously installed releases.

Chart repositories

Charts Repository - HTTP server for storing and distributing charts. Information about charts in the repository is stored in the index.yaml file. It also indicates where each chart can be loaded from. Most often, charts are stored with the index.yaml file, but nothing prevents you from placing them on another server. Usually the file structure is reduced to a flat form:

 . ├── index.yaml ├── artifactory-7.3.0.tgz ├── docker-registry-1.5.2.tgz ... └── wordpress-2.1.10.tgz 

By default, Helm uses the official Kubernetes charts repository . It contains carefully crafted topical charts for solving a variety of applied tasks. This repository is called stable :

 $ helm repo list NAME URL stable https://kubernetes-charts.storage.googleapis.com 

If necessary, creating your own repository will not be any problems. Server requirements are minimal, so, like most of the public repositories of charts, it can be placed on GitHub Pages. More information about the tools and the necessary steps for this can be found in the documentation .

When using the repositories of the charts, they can be added and deleted. In order for the versions of the charts to be relevant, it is necessary to periodically update the index. Let me give you an example for the public repository of bitnami , most of whose charts are used in the official Helm repository:

 $ helm repo add bitnami https://charts.bitnami.com/bitnami "bitnami" has been added to your repositories $ helm repo update Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "bitnami" chart repository ...Successfully got an update from the "stable" chart repository Update Complete. Happy Helming! $ helm repo remove bitnami "bitnami" has been removed from your repositories 

Next - search the repositories. Calling helm search with no arguments shows all available charts:

 $ helm search NAME CHART VERSION APP VERSION DESCRIPTION stable/acs-engine-autoscaler 2.2.0 2.1.1 Scales worker nodes within agent pools stable/aerospike 0.1.7 v3.14.1.2 A Helm chart for Aerospike in Kubernetes stable/anchore-engine 0.2.1 0.2.4 Anchore container analysis and policy evaluation engine s... stable/apm-server 0.1.0 6.2.4 The server receives data from the Elastic APM agents and ... stable/ark 1.2.1 0.9.1 A Helm chart for ark stable/artifactory 7.3.0 6.1.0 Universal Repository Manager supporting all major packagi... ... stable/weave-cloud 0.2.2 0.2.0 Weave Cloud is a add-on to Kubernetes which provides Cont... stable/weave-scope 0.9.3 1.6.5 A Helm chart for the Weave Scope cluster visualizer. stable/wordpress 2.1.10 4.9.8 Web publishing platform for building blogs and websites. stable/xray 0.4.1 2.3.0 Universal component scan for security and license invento... stable/zeppelin 1.0.1 0.7.2 Web-based notebook that enables data-driven, interactive ... stable/zetcd 0.1.9 0.0.3 CoreOS zetcd Helm chart for Kubernetes 

In the optional keywords field in Chart.yaml developers specify tags that are used to simplify searching in the charts repositories:

 $ helm search web NAME CHART VERSION APP VERSION DESCRIPTION stable/cerebro 0.3.1 0.8.1 A Helm chart for Cerebro - a web admin tool that replaces... stable/chronograf 0.4.5 1.3 Open-source web application written in Go and React.js th... stable/jasperreports 2.0.4 7.1.0 The JasperReports server can be used as a stand-alone or ... stable/joomla 2.0.9 3.8.12 PHP content management system (CMS) for publishing web co... stable/kubernetes-dashboard 0.7.2 1.8.3 General-purpose web UI for Kubernetes clusters stable/odoo 2.0.7 11.0.20180815 A suite of web based open source business apps. stable/phabricator 2.1.9 2018.34.0 Collection of open source web applications that help soft... stable/redmine 4.1.0 3.4.6 A flexible project management web application. stable/rethinkdb 0.1.4 0.1.0 The open-source database for the realtime web stable/schema-registry-ui 0.1.0 v0.9.4 This is a web tool for the confluentinc/schema-registry i... stable/superset 0.1.2 0.24.0 Apache Superset (incubating) is a modern, enterprise-read... stable/testlink 2.0.3 1.9.17 Web-based test management system that facilitates softwar... stable/tomcat 0.1.0 7 Deploy a basic tomcat application server with sidecar as ... stable/wordpress 2.1.10 4.9.8 Web publishing platform for building blogs and websites. ... $ helm search cms blog NAME CHART VERSION APP VERSION DESCRIPTION stable/drupal 1.1.3 8.5.6 One of the most versatile open source content management ... stable/joomla 2.0.9 3.8.12 PHP content management system (CMS) for publishing web co... stable/wordpress 2.1.10 4.9.8 Web publishing platform for building blogs and websites 

Note: When using the helm search command, you may encounter unstable operation of several filters: the presence of the result depends on the order of instructions and the number of filters.

After the search has narrowed down to several options, you can proceed to a more detailed analysis of the charts - using the helm inspect command. It displays the contents of the chart files Chart.yaml , values.yaml and README.md . Each section can be displayed separately with the corresponding arguments: chart , values and readme .

In the official repository charts are well documented and contain examples of use, and some charts even ready configurations for production . For example, a good readme is provided by stable / wordpress (for its output in the console, see helm inspect readme stable/wordpress ) .

Search is a good way to find available packages. After the package is found, you can use it to install the application into the cluster.

First application

For example, the already mentioned stable / wordpress chart is selected.

It uses the parameters described in the values.yaml file. You can override the parameters in the YAML file, and then transfer this file during installation (the -f , --values ). You can also override them directly on the command line (the --set , --set-string and --set-file ). All options are available for use any number of times; while redefinition in the command line takes precedence over files with parameters.

When setting the chart, you can give the release a name with the --name option or use a random name generated by Helm.

Let's set up the chart with the configuration for production , change the blog name, turn off WordPress data saving in PersistentVolumeClaim (for more information on permanent repositories, see the Kubernetes documentation ) :

 $ curl https://raw.githubusercontent.com/helm/charts/master/stable/wordpress/values-production.yaml --output values-production.yaml $ helm install --name habr --set "wordpressBlogName=Flant's Blog!" --set "persistence.enabled=false" -f values-production.yaml stable/wordpress NAME: habr LAST DEPLOYED: Fri Aug 31 15:17:57 2018 NAMESPACE: default STATUS: DEPLOYED RESOURCES: ==> v1/Secret NAME TYPE DATA AGE habr-mariadb Opaque 2 0s habr-wordpress Opaque 2 0s ==> v1/ConfigMap NAME DATA AGE habr-mariadb-init-scripts 1 0s habr-mariadb 1 0s habr-mariadb-tests 1 0s ==> v1/Service NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE habr-mariadb ClusterIP 10.111.7.232 <none> 3306/TCP 0s habr-wordpress ClusterIP 10.106.129.88 <none> 80/TCP,443/TCP 0s ==> v1beta1/Deployment NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE habr-wordpress 3 3 3 0 0s ==> v1beta1/StatefulSet NAME DESIRED CURRENT AGE habr-mariadb 1 1 0s ==> v1beta1/Ingress NAME HOSTS ADDRESS PORTS AGE wordpress.local-habr wordpress.local 80, 443 0s ==> v1/Pod(related) NAME READY STATUS RESTARTS AGE habr-wordpress-7955b95fd-hh7b9 0/1 ContainerCreating 0 0s habr-wordpress-7955b95fd-tgsxk 0/1 ContainerCreating 0 0s habr-wordpress-7955b95fd-xjz74 0/1 ContainerCreating 0 0s habr-mariadb-0 0/1 ContainerCreating 0 0s NOTES: 1. Get the WordPress URL: You should be able to access your new WordPress installation through https://wordpress.local/admin 2. Login with the following credentials to see your blog echo Username: user echo Password: $(kubectl get secret --namespace default habr-wordpress -o jsonpath="{.data.wordpress-password}" | base64 --decode) 

In the case of working with a full cluster, then you can follow the recommendations from the NOTES block above. If you have Minikube, open the website in the browser as follows:

 $ minikube service habr-wordpress Waiting, endpoint for service is not ready yet... Opening kubernetes service default/habr-wordpress in default browser... 

Congratulations, the application is in a cluster!



An extensive WordPress charts appear in the list of all Helm releases:

 $ helm list NAME REVISION UPDATED STATUS CHART APP VERSION NAMESPACE habr 1 Fri Aug 31 15:17:57 2018 DEPLOYED wordpress-2.1.10 4.9.8 default 

The next step is to update our release and change the image with the blog. For example, another tag from the same Docker repository ( 4.9.8-ol-7 ) will be used:

 $ helm upgrade habr --set "image.tag=4.9.8-ol-7" --set "wordpressBlogName=Flant's Blog!" --set "persistence.enabled=false" -f values-production.yaml stable/wordpress Release "habr" has been upgraded. Happy Helming! LAST DEPLOYED: Fri Aug 31 15:21:08 2018 NAMESPACE: default STATUS: DEPLOYED RESOURCES: ==> v1/Service NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE habr-mariadb ClusterIP 10.111.7.232 <none> 3306/TCP 3m habr-wordpress ClusterIP 10.106.129.88 <none> 80/TCP,443/TCP 3m ==> v1beta1/Deployment NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE habr-wordpress 3 4 2 0 3m ==> v1beta1/StatefulSet NAME DESIRED CURRENT AGE habr-mariadb 1 1 3m ==> v1beta1/Ingress NAME HOSTS ADDRESS PORTS AGE wordpress.local-habr wordpress.local 80, 443 3m ==> v1/Pod(related) NAME READY STATUS RESTARTS AGE habr-wordpress-66f4fd6b74-gqwhh 0/1 Pending 0 0s habr-wordpress-66f4fd6b74-mf6vj 0/1 Pending 0 0s habr-wordpress-7955b95fd-hh7b9 1/1 Running 2 3m habr-wordpress-7955b95fd-tgsxk 1/1 Running 2 3m habr-wordpress-7955b95fd-xjz74 0/1 Terminating 2 3m habr-mariadb-0 1/1 Running 0 3m ==> v1/Secret NAME TYPE DATA AGE habr-mariadb Opaque 2 3m habr-wordpress Opaque 2 3m ==> v1/ConfigMap NAME DATA AGE habr-mariadb-init-scripts 1 3m habr-mariadb 1 3m habr-mariadb-tests 1 3m NOTES: 1. Get the WordPress URL: You should be able to access your new WordPress installation through https://wordpress.local/admin 2. Login with the following credentials to see your blog echo Username: user echo Password: $(kubectl get secret --namespace default habr-wordpress -o jsonpath="{.data.wordpress-password}" | base64 --decode) 

Please note that when updating, Tiller compares the received chart with the parameters with the last saved one and executes the corresponding requests in the Kubernetes API, and the current state of the release resources is not taken into account . It is important to understand this feature and not make mistakes:

• The update is no different from the installation: the Helm-client sends Tiller a chart along with the parameters, so you need to be careful not to forget to specify the parameters and files with the parameters that were set during the installation (or the previous update) and which should not be ignored. In the example above, this is --set "wordpressBlogName=Flant's Blog!" --set "persistence.enabled=false" -f values-production.yaml --set "wordpressBlogName=Flant's Blog!" --set "persistence.enabled=false" -f values-production.yaml .
• Applications that roll out with Helm should only be serviced using Helm: changes made manually with kubectl will not be taken into account by Helm and may have irreversible consequences.

Hence the logical conclusion: the process should be automated , and changes should be made only through a commit in the Git repository, changes to the charts and the CI configuration file.

The status of application release components in a cluster can always be checked as follows:

 $ helm status habr LAST DEPLOYED: Fri Aug 31 15:21:08 2018 NAMESPACE: default STATUS: DEPLOYED RESOURCES: ==> v1/Secret NAME TYPE DATA AGE habr-mariadb Opaque 2 4m habr-wordpress Opaque 2 4m ==> v1/ConfigMap NAME DATA AGE habr-mariadb-init-scripts 1 4m habr-mariadb 1 4m habr-mariadb-tests 1 4m ==> v1/Service NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE habr-mariadb ClusterIP 10.111.7.232 <none> 3306/TCP 4m habr-wordpress ClusterIP 10.106.129.88 <none> 80/TCP,443/TCP 4m ==> v1beta1/Deployment NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE habr-wordpress 3 4 2 3 4m ==> v1beta1/StatefulSet NAME DESIRED CURRENT AGE habr-mariadb 1 1 4m ==> v1beta1/Ingress NAME HOSTS ADDRESS PORTS AGE wordpress.local-habr wordpress.local 80, 443 4m ==> v1/Pod(related) NAME READY STATUS RESTARTS AGE habr-wordpress-66f4fd6b74-gqwhh 0/1 Pending 0 1m habr-wordpress-66f4fd6b74-mf6vj 1/1 Running 0 1m habr-wordpress-7955b95fd-hh7b9 1/1 Running 3 4m habr-wordpress-7955b95fd-tgsxk 1/1 Running 3 4m habr-mariadb-0 1/1 Running 1 4m NOTES: 1. Get the WordPress URL: You should be able to access your new WordPress installation through https://wordpress.local/admin 2. Login with the following credentials to see your blog echo Username: user echo Password: $(kubectl get secret --namespace default habr-wordpress -o jsonpath="{.data.wordpress-password}" | base64 --decode) 

Helm allows you to roll back to a specific release revision . Currently there are two revisions:

 $ helm history habr REVISION UPDATED STATUS CHART DESCRIPTION 1 Fri Aug 31 15:17:57 2018 SUPERSEDED wordpress-2.1.10 Install complete 2 Fri Aug 31 15:21:08 2018 DEPLOYED wordpress-2.1.10 Upgrade complete 

Roll back the application to its original state:

 $ helm rollback habr 1 Rollback was a success! Happy Helming! 

Now the revision history is replenished with one entry:

 $ helm history habr REVISION UPDATED STATUS CHART DESCRIPTION 1 Fri Aug 31 15:17:57 2018 SUPERSEDED wordpress-2.1.10 Install complete 2 Fri Aug 31 15:21:08 2018 SUPERSEDED wordpress-2.1.10 Upgrade complete 3 Fri Aug 31 15:25:06 2018 DEPLOYED wordpress-2.1.10 Rollback to 1 

Article coming to an end and release is no longer required?

 $ helm delete habr release "habr" deleted 

Is it really deleted? ..

The command deletes the Kubernetes resources associated with the release, but not the release itself . All information about the release remains available, including its history:

 $ helm list --all NAME REVISION UPDATED STATUS CHART APP VERSION NAMESPACE habr 3 Fri Aug 31 15:25:06 2018 DELETED wordpress-2.1.10 4.9.8 default 

 $ helm history habr REVISION UPDATED STATUS CHART DESCRIPTION 1 Fri Aug 31 15:17:57 2018 SUPERSEDED wordpress-2.1.10 Install complete 2 Fri Aug 31 15:21:08 2018 SUPERSEDED wordpress-2.1.10 Upgrade complete 3 Fri Aug 31 15:25:06 2018 DELETED wordpress-2.1.10 Deletion complete 

Note : As planned, a remote release can be rolled back to previous versions, but in recent versions this feature does not work - see issue # 3722 for details.

To completely remove the release, use the --purge option:

 $ helm delete --purge habr release "habr" deleted 

Summarizing

This article describes the basic architecture of Helm 2, its components and their functions, as well as the basic primitives, charts, releases and repositories of charts. We installed Helm in the Kubernetes cluster and got an understanding of the release life cycle and the main commands for working with it.

The following material from this cycle will be devoted to the topic of creating your own charts - I will talk about the structure of the chart, templating and debugging tools in it.

PS

• “ Package Manager for Kubernetes - Helm: Past, Present, Future ”;
• " Practice with dapp. Part 2. Deploying Docker images in Kubernetes with the help of Helm ”;
• “ Build and heat applications in Kubernetes using dapp and GitLab CI ”;
• “ Best CI / CD practices with Kubernetes and GitLab ” (review and video of the report) .