На официальной странице Helm называет сам себя «The package manager for Kubernetes«, но на деле Helm нечто большее, чем просто менеджер пакетов для Kubernetes — скорее это система управления приложениями в Kubernetes, позволяющая выполнять их установку, отслеживать состояние, выполнять обновление, удаление.
В этом посте рассмотрим основные понятия и компоненты Helm, работу с чартами, шаблонами, переменными и репозиториями.
Пост больше обзорный, и не затрагивает многих нюансов, например — работу с версинированием релизов, зависимостями и т.д.
В отличии от самого Kubernetes — у Helm отличная документация.
Содержание
Архитектура Helm
Helm оперирует пакетами приложений для запуска в Kubernetes, которые в терминологии самого Helm называются chart (схема, или чертёж), и позволяет:
создавать новые чарты с нуля
упаковавать чарты в архив (tgz)
вести совместную работу с чартами, используя общие репозитории
устанавливать и удалять чарты в кластере Kubernetes
управлять релизами установленных в кластере чартов
Концепты Helm
Три основных концепта Helm:
chart: пакет информации, необходимой для создания приложения к кластере Kubernetes
config: информация о настройках и параметрах, которые использутся chart-ом для создания инстанса приложения и управления его релизами
release: работающий инстанс chart-а, связанный с определённым config-ом
Компоненты Helm
Helm можно разделить на две основных части — клиент, и набор библиотек.
Helm client: утилита командной строки (весь Helm написан на Go), отвечает за локальную разработку чартов, взаимодействие с репозиториями чартов, управление релизами, и взаимодействие с библиотекой Helm — отправка новых чартов для установки, управление релизами запущенных приложений
Helm library: предоставляет логику работы Helm, отвечает за взаимодействие с API Kubernetes-кластера, управляет чартами и их конфигами, релизами, установкой чартов в кластер, их обновление и удаление
Helm Charts
Итак, chart, чарт — набор файлов, описывающий определённый набор ресурсов Kubernetes, с помощью которого можно выполнить запуск пода с одним сервисом, например веб-сервер, или полноценное приложение, включающее в себя и веб-сервер, и приложения фронтента, бекнда, баз данных, систем кеширования и т.д.
Структура файлов
Чарты организованы в виде каталогов и файлов, где имя каталога верхнего уровня, содержащего другие директории и файлы будет именем такого чарта.
Например:
tree example-chart/
example-chart/
|-- Chart.yaml
|-- charts
|-- templates
| |-- NOTES.txt
| |-- _helpers.tpl
| |-- deployment.yaml
| |-- hpa.yaml
| |-- ingress.yaml
| |-- service.yaml
| |-- serviceaccount.yaml
| `-- tests
| `-- test-connection.yaml
`-- values.yaml
Тут:
example-chart — каталог, имя чарта
Chart.yaml — файл с метаданными чарта, описывающий что это за чарт, содержащий информацию о версиях, зависимостях, авторе чарта и так далее
charts: чарт может содержать subcharts — они будут располагатьсяв этом каталоге
templates — содержит файлы шаблонов, которые будут применены к кластеру для запуска приложения, используя шаблонизатор Go
NOTES.txt — help-текст, который будет отображаться пользователям
deployment.yaml — пример манифеста с ресурсом Kubernetes Deployment
service.yaml — пример манифеста с ресурсом Kubernetes Service
values.yaml — содержит значения по-умолчанию для шаблонов — Services, Deployments, и т.д.
🏄 Done! kubectl is now configured to use "minikube"
Проверяем:
kubectl cluster-info
Kubernetes master is running at https://192.168.99.100:8443
KubeDNS is running at https://192.168.99.100:8443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
Ноды кластера:
kubectl get nodes
NAME STATUS ROLES AGE VERSION
minikube Ready master 4m16s v1.18.0
Установка Helm
Arch Linux — из репозитория:
sudo pacman -S helm
macOS — Homebrew:
brew install helm
Debian, etc — с помощью Snap:
sudo apt install snapd
sudo snap install helm --classic
И отличнейшная подсказка по helm help:
Создание Helm Chart
Далее — создадим свой чарт, обновим в нём шаблоны, и задеплоим какое-то приложение в Kubernretes.
Создаём новый чарт:
helm create example-chart
Creating example-chart
Его содержимое мы уже видели выше:
tree example-chart/
example-chart/
|-- Chart.yaml
|-- charts
|-- templates
| |-- NOTES.txt
| |-- _helpers.tpl
| |-- deployment.yaml
| |-- hpa.yaml
| |-- ingress.yaml
| |-- service.yaml
| |-- serviceaccount.yaml
| `-- tests
| `-- test-connection.yaml
`-- values.yaml
3 directories, 10 files
Содержимое его деплоймента:
cat example-chart/templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: {{ include "example-chart.fullname" . }}
labels:
{{- include "example-chart.labels" . | nindent 4 }}
spec:
{{- if not .Values.autoscaling.enabled }}
replicas: {{ .Values.replicaCount }}
{{- end }}
...
И Values:
cat example-chart/values.yaml
Default values for example-chart.
This is a YAML-formatted file.
Declare variables to be passed into your templates.
replicaCount: 1
...
Тут всё достаточно очевидно — для replicas: {{ .Values.replicaCount }} в templates/deployment.yaml будет использовано значение replicaCount: 1 из values.yaml.
Но мы эти шаблоны использовать не будем — а напишем свой велосипед чарт.
Удаляем их:
rm -rf example-chart/templates/*
Далее добавим свой ConfigMap.
Добавление template
Создадим файл example-chart/templates/configmap.yaml, а в нём — содержимое для файла index.html:
Для того, что бы создать свой репозиторий — достаточно выполнить helm package чарта, после чего сгенерировать файл index.yaml в каталоге, который хранит архив.
В качестве бекенда для репозиториев может быть что угодно — от Github Pages, до AWS S3, см. The Chart Repository Guide.
Тут пример локального репозитория.
Создаём каталог, переносим в него архив:
mkdir helm-local-repo
mv example-chart-0.1.0.tgz helm-local-repo/
Инициализируем репозиторий:
helm repo index helm-local-repo/
Содержимое:
tree helm-local-repo/
helm-local-repo/
|-- example-chart-0.1.0.tgz
`-- index.yaml
Что бы получить к нему доступ — запустим простой NGINX:
sudo docker run -ti -v $(pwd)/helm-local-repo/:/usr/share/nginx/html -p 80:80 nginx