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 complete 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.
Helm client part responsible for the formation and transfer chart with custom parameters being in the cluster Kubernetes component Tiller . 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 - everything in order.
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 context cluster
kubectl ( kubectl config current-context), in the namespacekube-system , but this can be changed using the appropriate options and environment variables — they are described in the help ( helm init --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 (optional
--upgrade) 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 option --tiller-image, and with the option --canary-imagewhen rolling out Tiller a canary-image will be used. 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,
ConfigMapstherefore, 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 the charts in the repository is stored in a file
index.yaml. It also indicates where each chart can be loaded from. Most often, the charts are stored with the file index.yaml, but nothing prevents to place 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 charts repositories, it can be hosted on GitHub Pages. More information about the tools and the necessary steps for this can be found in the documentation .
With the use of charts repositories they can be added and deleted. In order for the versions of the charts to be relevant, you need to periodically update the index. I will give an example for the public repository of bitnami , most of which 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 through repositories. A call
helm searchwith 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 field
keywordsin the Chart.yamldevelopers indicate the tags that are used to simplify the search in the repositories of charts:$ 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 websitesNote: When using the command,
helm searchyou 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 - with the help of the command
helm inspect. It displays the contents of the chart filesChart.yaml,values.yamlandREADME.md. Each section can be separately withdrawn from the respective arguments:chart,valuesandreadme. In the official repository charts are well documented and contain examples of use, and some charts even ready configurations for production . For example, good
readmeis presented at 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 file
values.yaml. You can override the parameters in the YAML file, and then transfer this file during installation (options -f, --values). In addition, they can be overridden directly on the command line (options --set, --set-stringand --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 you install the chart, you can set the name of the release option
--nameor use a random name generated by Helm. Install the chart with the configuration for production, change the name of the blog, turn off WordPress data storage in
PersistentVolumeClaim(for more information on permanent storage, 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)
If you work with a full cluster, 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 appeared 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 and do not 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. - Applications that roll out with Helm should only be serviced using Helm: changes made manually with the help
kubectlwill not be taken into account by Helm and may lead to 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 state 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 revision of the release . 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 has been 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 team 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 option
--purge:$ helm delete --purge habr
release "habr" deleted
Summarizing
This article talks about 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) .