Статья является логическим продолжение нашей недавней публикации об истории пакетного менеджера для 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.
- «Пакетный менеджер для Kubernetes — Helm: прошлое, настоящее, будущее»;
- «Практика с dapp. Часть 2. Деплой Docker-образов в Kubernetes с помощью Helm»;
- «Сборка и дeплой приложений в Kubernetes с помощью dapp и GitLab CI»;
- «Лучшие практики CI/CD с Kubernetes и GitLab» (обзор и видео доклада).
Автор: Алексей Игрычев
