Можно добавить свой созданный репозиторий с чартами или репозиторий из Интернет, искать на https://artifacthub.io/
helm repo add bitnami https://charts.bitnami.com/bitnami
— добавили репозиторий с локальными именем bitnami, далее указан адрес репозитория
helm repo list
— список локальныех репозиториев
helm repo update
— получить (обновить) информацию о доступных чартах из соответствующих репозиториев чартов. Информация кешируется локально, потом может использоваться командой поиска.
helm search repo
— список всех чартов во всех установленных репозиториях
helm search repo -l
— список всех чартов во всех установленныx репозиториях, отображать все версии каждого чарта
helm search repo nginx
— поиск во всех добавленных репозиториях чартов со словом nginx в названии или описании. Регистр букв не учитывается. CHART VERSION
— версия самого чарта. APP VERSION
— версия приложения (например nginx), которое разворачивает чарт.
helm search repo -l nginx
или helm search repo --versions nginx
— то же, но покажет все возможные версии чартов в репозитории (не только последняя).
helm search repo -l "nginx server"
— то же, но ищем в по наличию словосочетания «nginx server» в описании чарта.
Пример:
$ helm search repo nginx
NAME CHART VERSION APP VERSION DESCRIPTION
bitnami/nginx 9.9.3 1.21.6 NGINX Open Source is a web server that can be a...
bitnami/nginx-ingress-controller 9.1.11 1.1.2 NGINX Ingress Controller is an Ingress controll...
bitnami/nginx-intel 0.1.5 0.4.7 NGINX Open Source for Intel is a lightweight se...
bitnami/kong 5.0.2 2.7.0 Kong is a scalable, open source API layer (aka ...
helm pull bitnami/nginx
— скачать чарт, сохранится в текущем каталоге в виде архива .tgz
helm package amq
— заархивировать чарт, который находится в текущем каталоге amq. Имя созданного архива будет содержать имя и версию чарта, например amq-0.1.2.tgz
,т.к. имя не зависит от названия самого каталога. Все файлы, отмеченные в .helmignore
, в чарт не включаются.
helm install nginx01 bitnami/nginx
— установили новый релиз, дали ему имя nginx01, использовали чарт bitnami/nginx, при установке были использованы переменные по умолчанию из самого чарта, свои переменные не добавляли.
helm install bitnami/nginx --generate-name
— имя релиза автоматически генерируется. Например в шаблоне чарта у нас имя релиза nginx. Тогда при установке релиза несколько раз будут добавляться уникальные суффиксы, например nginx-165948675
helm install nginx01 -n apps bitnami/nginx --create-namespace
— установит релиз nginx01 не в текущем namespace, а в app. Дополнительный флаг можно использовать для автоматического создания namespace, если такого нет (на работе не используем автосоздание namespace). Проверка: kubectl get ns
Обновление релиза происходит при обновлении переменных из файла .yml
, при обновлении переменных непосредственно из командной строки, при обновлении или изменении версии чарта:
helm upgrade nginx01 --set service.type=NodePort --set service.port=8080 bitnami/nginx
— обновили две переменные в релизе nginx01
(через точку указано, что переменные второго уровня, т.е. внутри service
). Имя чарта bitnami/nginx
. Например были переменные в values.yaml
внутри чарта, которые использовались по умолчанию:
service:
type: LoadBalancer
port: 80
А мы их перезаписали непосредственно из командной строки.
helm upgrade nginx01 -f values.yaml bitnami/nginx
— обновили переменные релиза nginx01 из файла values.yaml
, который находится в текущем каталоге. Имя чарта bitami/nginx
.
helm upgrade -i nginx01 -f values.yaml bitnami/nginx
— то же самое. Но обычно мы в Gitlab используем флаг -i
(или --install
), что позволяет установить релиз, если он ещё не был установлен.
helm upgrade -i nginx01 -f values.yaml bitnami/nginx --wait --timeout 10s
— обычно добавляем флаг ожидания. По умолчанию ждет 300 секунд (5 минут), пока все поды, PVCs (запрос дисков), сервисы и минимальное число подов для Deployment, StatefulSet или ReplicaSet не будут в статусе готовности, прежде чем сделать релиз успешным. Здесь перезаписали таймаут на 10 секунд, подбирать индивидуально. Флаг ожидания очень важен. Если него нет, состояние релиза будет failed
только если API-сервер Kubernetes-а не сможет обработать ошибочные манифесты Helm-a, но даже если под не поднялся, будет deployed
, что не даст верной картины. Флаг добавит проверку статус подов и пр., результат проверки повлияет на статус релиза.
helm upgrade nginx01 --dry-run -f values.yaml bitnami/nginx
— флаг --dry-run
позволяет имитировать обновление релиза для тестов, т.е. мы увидим манифесы, которые будут получены в результате, но на самом деле ничего не будет обновлено.
helm upgrade nginx01 --version 9.3.5 bitnami/nginx
— обновляем релиз nginx01
, но меняем саму версию чарта. Причем можем откатиться на более старую версию чарта. По умолчанию, если версия чарта не указана, используется самая свежая. Вместо указания конкретной версии можно указать диапазон, например ^2.0.0
— версия чарта выше 2.0.0.
helm upgrade nginx01 --version 9.3.5 --reuse-values bitnami/nginx
— сделали «дегрейд» версии чарта на 9.3.5, в ней могут быть свои значения переменных по умолчанию, а мы уже например меняли значения, перезаписывая их. Добавив --reuse-values
мы гарантируем, что будут переиспользованы все значения переменных из самого последнего релиза, и они будут совмещены со значениями, которые мы добавляем в командной строке через --set
и -f
(т.е. значения, добавленные с командной строке, имеют приоритет). При указании параметра --reset-values
, параметр --reuse-values
буде проигнорирован.
helm list
— список релизов в текущем namespace
helm list -n имя_namespace
— список релизов в указанном namespace.
helm list -A
илиhelm list --all-namespaces
— список релизов во всех namespace
helm history имя_релиза
— история конкретного релиза. Возможные статусы:
pending-install
— манифесты готовы, но ещё не были отправлены в Kubernetes. Видно при использовании флага--dry-run
.deployed
— манифесты были отправлены в Kubernetes и были приняты. Ещё не значит, что приложение уже работает.pending-upgrade
— манифесты обновления готовы, но ещё не отправлены в Kubernetes.superseded
— релиз успешно обновлен.pending-rollback
— сгенерированы манифесты отката на одну из предыдущих версий, но ещё не отправлены в Kubernetes.uninstalling
— текущий (самый последний и свежий) релиз в процессе удаления.uninstalled
— если история сохранена, это статус последнего удаленного релиза.failed
— Kubernetes не принимает манифесты, отправленные ему Helm-ом во время любой операции. Смотри также флаг--wait
, который более точно позволит проверить реальное состояние деплоя.
helm rollback имя_релиза номер
— откат на одну из версий из helm history имя_релиза
. Если версию не указывать, то откат на предыдущую.
Удаление релиза:
helm uninstall имя_релиза
— удаляет релиз из текущего namespace, в котором мы находимся. Имя чарта при удалении не нужно.
helm uninstall имя_релиза -n имя_namespace
— удаляет релиз из заданного namespace
helm uninstall имя_релиза --keep-history
— удаляет релиз, но сохраняет helm history.
Позволит восстановить удаленный релиз через rollback
.
При создании шаблона чарта создается чарт nginx. При установке релиза из локального чарта, который находится в каталоге myapp, указывать только имя каталога (ранее указывали имя репозитория, слеш, имя чарта)
$ mkdir mycharts
$ cd mycharts/
~/mycharts$ helm create myapp
Creating myapp
# структура каталога чарта
~/mycharts$ tree myapp
myapp
├── charts
├── Chart.yaml
├── templates
│ ├── deployment.yaml
│ ├── _helpers.tpl
│ ├── hpa.yaml
│ ├── ingress.yaml
│ ├── NOTES.txt
│ ├── serviceaccount.yaml
│ ├── service.yaml
│ └── tests
│ └── test-connection.yaml
└── values.yaml
3 directories, 10 files
# установка чарта
$ helm install myapp01 myapp
# если мы находимся в каталоге чарта, вместо имени чарта указать точку
# проверим, какие манифесты создадутся, без реальной установки приложения
$ cd myapp
$ helm install myapp01 --dry-run .
# проверка, смотрим имя пода
$ kubectl get pods
$ kubectl get svc
# для доступа к чарту из браузера по адресы localhost:8080 настроить переадресацию порта
kubectl port-forward имя_пода 8080:80