aigrychev Sep 3 2018 at 09:16

Практическое знакомство с пакетным менеджером для Kubernetes — Helm

11 min

78K

Флант corporate blogDevOps*Kubernetes*Open source*System administration*

Статья является логическим продолжение нашей недавней публикации об истории пакетного менеджера для Kubernetes — Helm. В этот раз мы снова затронем вопросы устройства и функционирования нынешнего Helm (версия 2.x), а также управляемых им чартов и репозиториев, после чего перейдём к практике: установке Helm в кластер Kubernetes и использованию чартов.

Вступление

Helm — инструмент для управления чартами.

Чарт описывает необходимый набор данных для создания экземпляра приложения в кластере Kubernetes. Он может иметь вложенные чарты и использоваться как для описания полноценных сервисов, состоящих из множества зависимых ресурсов, так и для описания отдельных независимых составляющих. К примеру, чарт stable/gitlab-ce описывает комплексное решение с использованием независимых чартов redis и postgresql.

Чарт может быть установлен неограниченное количество раз в одном и том же кластере. Таким образом, описание логики выката приложения в разные окружения может и должно храниться в одном чарте.

Клиентская часть Helm отвечает за формирование чарта и передачу вместе с пользовательскими параметрами находящемуся в кластере Kubernetes компоненту Tiller. В свою очередь, Tiller отвечает за жизненный цикл экземпляра запущенного чарта, релиза. (На всякий случай напомню, что в следующем крупном обновлении Helm — версии 3 — уже не будет Tiller.)

А теперь — обо всём по порядку.

Установка и обновление

Для работы с Helm требуется Kubernetes. Можно использовать локально установленный Minikube (см. также «Начало работы в Kubernetes с помощью Minikube») или любой другой доступный кластер.

Начнём с установки клиента: выбираем релиз, скачиваем и распаковываем архив для своей системы, переносим исполняемый файл…

$ 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

Далее установка Tiller в кластер. По умолчанию Tiller устанавливается в кластер контекста kubectl (kubectl config current-context), в пространство имён kube-system, но это можно изменить, используя соответствующие опции и переменные окружения — они описаны в справке (helm init --help). Выполним установку и посмотрим на созданные ресурсы в кластере:

$ 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

Теперь Tiller установлен в кластер и готов к управлению релизами, взаимодействию с Kubernetes API.

Примечание: При установке и обновлении (опция --upgrade) Tiller'а можно задавать конкретный образ вместо использования последнего стабильного релиза по умолчанию. Имя произвольного образа определяется опцией --tiller-image, а с опцией --canary-image при выкате Tiller будет использован canary-образ. Сanary-образ позволяет использовать Tiller, версия кода которого соответствует ветке master.

Служебные данные хранятся в кластере в специальных ресурсах, ConfigMaps, поэтому удаление и переустановка Tiller'а не приводят к потере данных установленных ранее релизов.

Репозитории чартов

Репозиторий чартов — HTTP-сервер для хранения и распространения чартов. Информация о чартах в репозитории хранится в файле index.yaml. В нём же указывается, откуда каждый чарт может быть загружен. Чаще всего чарты хранятся вместе с файлом index.yaml, но ничего не мешает разместить их на другом сервере. Обычно файловая структура сводится к плоской форме:

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

По умолчанию Helm использует официальный репозиторий чартов Kubernetes. Он содержит тщательно проработанные актуальные чарты для решения множества прикладных задач. Этот репозиторий именуется stable:

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

При необходимости создание собственного репозитория не составит никаких проблем. Требования к серверу — минимальные, поэтому, как и большинство публичных репозиториев чартов, его можно разместить на GitHub Pages. Подробнее про инструменты и необходимые для этого шаги можно почитать в документации.

При использовании репозиториев чартов они могут быть добавлены и удалены. Для того, чтобы версии чартов были актуальными, необходимо периодически обновлять индекс. Приведу пример для публичного репозитория bitnami, большая часть чартов которого используется в официальном репозитории Helm:

$ 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

Далее — поиск по репозиториям. Вызов helm search без аргументов показывает все доступные чарты:

$ 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

В необязательном поле keywords в Chart.yaml разработчики указывают теги, которые используются для упрощения поиска в репозиториях чартов:

$ 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

Примечание: При использовании команды helm search можно столкнуться с нестабильной работой нескольких фильтров: наличие результата зависит от порядка указания и количества фильтров.

После того, как круг поисков сузился до нескольких вариантов, можно перейти к более детальному анализу чартов — с помощью команды helm inspect. Она выводит содержимое файлов чарта Chart.yaml, values.yaml и README.md. Каждый раздел по отдельности можно вывести с соответствующими аргументами: chart, values и readme.

В официальном репозитории чарты прекрасно документированы и содержат примеры использования, а некоторые чарты — даже готовые конфигурации для production. К примеру, хороший readme представлен у stable/wordpress (для его вывода в консоли см. helm inspect readme stable/wordpress).

Поиск — это хороший способ найти доступные пакеты. После того, как пакет найден, можно использовать его для установки приложения в кластер.

Первое приложение

Для примера выбран уже упомянутый чарт stable/wordpress.

В нём используются параметры, описанные в файле values.yaml. Параметры можно переопределить в YAML-файле, а затем передать этот файл во время установки (опции -f, --values). Кроме того, их можно переопределить непосредственно в командной строке (опции --set, --set-string и --set-file). Все опции доступны для использования произвольное количество раз; при этом переопределение в командной строке имеет больший приоритет над файлами с параметрами.

При установке чарта можно задать имя релизу опцией --name или использовать случайное имя, сгенерированное Helm.

Установим чарт с конфигурацией для production, поменяем название блога, отключим сохранение данных WordPress в PersistentVolumeClaim (подробнее про постоянные хранилища см. в документации Kubernetes):

$ 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)

В случае работы с полноценным кластером далее можно следовать рекомендациям из блока NOTES выше. Если же у вас Minikube — откройте сайт в браузере следующим образом:

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

Поздравляю, приложение в кластере!

Развёрнутый чарт с WordPress появился в списке всех релизов Helm:

$ 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

Следующим шагом обновим наш релиз и изменим образ с блогом. Для примера будет использован другой тег из того же Docker-репозитория (4.9.8-ol-7):

$ 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)

Обратите внимание, что при обновлении Tiller сравнивает полученный чарт с параметрами с последним сохранённым и выполняет соответствующие запросы в Kubernetes API, а актуальное состояние ресурсов релиза не берётся в расчёт. Важно понимать эту особенность и не совершать ошибок:

Обновление ничем не отличается от инсталяции: Helm-клиент отправляет Tiller чарт вместе с параметрами, поэтому надо быть внимательнее и не забыть указать параметры и файлы с параметрами, которые задавались при инсталяции (или при предыдущем обновлении) и которые не должны быть проигнорированы. В примере выше — это --set "wordpressBlogName=Flant's Blog!" --set "persistence.enabled=false" -f values-production.yaml.
Приложения, которые выкатываются при помощи Helm, должны обслуживаться только с использованием Helm: изменения, сделанные вручную при помощи kubectl, не будут учтены Helm и могут приводить к необратимым последствиям.

Отсюда логичное заключение: процесс должен быть автоматизирован, а изменения должны выполняться только через коммит в Git-репозиторий, изменения файлов чарта и конфигурационного файла CI.

Состояние компонентов релиза приложения в кластере всегда можно проверить следующим образом:

$ 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 позволяет откатываться до определённой ревизии релиза. На текущий момент ревизий две:

$ 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

Откатим приложения к первоначальному состоянию:

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

Теперь история ревизий пополнилась на одну запись:

$ 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

Статья подходит к концу и релиз больше не требуется?

$ helm delete habr
release "habr" deleted

А удалён ли он в действительности?..

Команда удаляет Kubernetes-ресурсы, связанные с релизом, но не сам релиз. Вся информация о релизе остаётся доступной, в том числе и его история:

$ 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

Примечание: По задумке, удалённый релиз можно откатывать к предыдущим версиям, но в последних версиях эта возможность не работает — подробности см. в issue #3722.

Для полного удаления релиза используется опция --purge:

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

Резюмируя

В этой статье рассказано про базовую архитектуру Helm 2, его компоненты и их функций, а также об основных примитивах, чартах, релизах и репозиториях чартов. Мы установили Helm в кластер Kubernetes и получили понимание жизненного цикла релиза и основных команд для работы с ним.

Следующий материал из этого цикла будет посвящён теме создания собственного чарта — в нём я расскажу про структуру чарта, шаблонизацию и инструменты отладки. ОБНОВЛЕНО: Новая статья доступна по этой ссылке.

P.S.

Tags:

Hubs: