Установка Helm 3

Установка helm 3 ничем не отличается от helm 2. Это всё такой же статически слинкованный бинарный файл. Т.е. достаточно его просто скачать и давить к себе в $PATH или создать символическую ссылку в /usr/bin. Для пользователей Ansible мы создали роль, которая этот процесс автоматизирует.

Удаление Tiller

Вы наверняка и так знаете, что helm 3 is tiller less. Действительно tiller окончательно и безвозвратно удален. Теперь helm использует Kubernetes API напрямую, применяя ваши полномочия, что несомненно более безопасно, но так ли это удобно?

С одной стороны да - вам больше не нужно делать утомительный helm init, а потом 3 часа ковыряться в Kubernetes RBAC, потому что ничего не работает. Плюс меньше нагрузка, особенно если вы используете стратегию один namespace - один tiller.

С другой стороны, helm теперь нэймспэйсится из коробки. А это значит две вещи: первое, пространство имен (namespace) в Kubernetes должно существовать до того, как вы начнете что-то деплоить. Как именно вы это будете решать helm не интересует - вы больше не можете создавать нэймспэйсы, используя helm, точка. Второе, выполнять листинг чартов, обновления и т.д. надо обязательно указывая --namespace, так как helm теперь хранит состояние релиза (state) в том же самом namespace, а не как это было раньше в kube-system. Т.е. нагрузка на пальцы немного возрасла

Стоит также упомянуть, что теперь хранилище по-умолчанию для релизов - Kubernetes Secrets, а не ConfigMap как это было в helm 2. Вы все еще можете использовать ConfigMap, если хотите, но для этого придется экспортирвать переменную

$ export HELM_DRIVER=configmap

Трех сторонний патч

Что действительно приятно, так это то, что helm v3 теперь учитывает изменения, сделанные руками после установки чарта. Т.е. если  кто-то руками поменял какой-то параметр, helm 2 при выполнении обновления не почешется, если он не изменился относительно сохраненного state'а. Helm 3 же проверит, а матчится ли то, что его просят сделать с тем, что есть в реальности и в state. И это очень круто

Поддержка верификации переменных

Helm 3 дает возможность определить схему для переменных, чтобы уведомить пользователя, если он делает что-то, что разработчик чарта не предполагал. Например, можно указать, какие переменные обязательно должны быть определены, какой у низ должен быть тип данных и т.д. Например, если положить в каталог с чартом файл "values.schema.json" следующего содержания

{
  "$schema": "https://json-schema.org/draft-07/schema#",
  "title": "Values",
  "type": "object",
  "properties": {
    "image": {
      "type": "object",
      "description": "Container Image",
      "properties": {
        "name": { "type": "string" },
        "tag": { "type": "string" }
      }
    },
    "replicaCount": {
      "description": "Number Of replicas",
      "minimum": 1,
      "type": "integer"
    }
  },
  "required": [
    "replicaCount"
  ]
}

то при инсталляции, если пользователь не определил переменную "replicaCount", будет выведено сообщение об ошибке

Error: values don't meet the specifications of the schema(s) in the following chart(s):
nginx:
- (root): replicaCount is required

Само собой эта функция работает только в helm v3, helm v2 схему просто игнорирует

Поддержка Docker Registry

Helm 3 обзавелся поддержкой docker registry. Что это значит? Это значит, что вам больше не нужно искать себе отдельный helm repository (репозиторий), такой как ChartMuseum. ChartMuseum был хорошим вариантом для централизованного хранения чартов, однако он также выступал дополнительным слоем в вашей инфраструктуре, требуя обновлений, мониторинга, управлением доступом и т.д. Поддержка же helm repository со стороны сервисов, таких как Nexus, AWS и т.д. так и не добралась до масс. Теперь же вы можете хранить чарты прямо в docker репозиториях. Это к примеру прекрасно работает с ванильным Docker Registry или GitLab Registry. Люди говорят, что они также пушат в GCR без проблем

Как это все делается? Сперва, нужно включить эту функцию явно, так как на середину 2020-ого она все еще остается экспериментальной. Делаем

export HELM_EXPERIMENTAL_OCI=1

Дальше необходимо залогиниться в ваш репозиторий. Заметьте, Helm не использует конфигурацию сгенерированную командой docker login! Предположим, вы используете GitLab

$ helm registry login registry.gitlab.com
Username: XXXX
Password: XXXX
Login succeeded

Далее создаем пакет и пушим его в helm repository. Создание пакета включает в себя тэгирование, точно так как это происходит в процессе docker build.

$ helm creat nginx
$ helm chart save \
nginx/  registry.gitlab.com/hippolab/helm-charts/nginx:0.0.1
$ helm chart push \
registry.gitlab.com/hippolab/helm-charts/nginx:0.0.1
The push refers to repository
ref:     registry.gitlab.com/hippolab/helm-charts/nginx:0.0.1
digest:  de77123c5fc63e0443bc0357aa25e7a0bfc725cb40
size:    9.1 KiB
name:    nxing
version: 0.0.1

К сожалению, на данный момент делать helm install таких чартов напрямую нельзя, т.е., если вы деплоите из пайплайна, то вам сначала надо будет спулить чарт, а затем экспортирвать

$ helm chart pull \
registry.gitlab.com/hippolab/helm-charts/nginx:0.0.1
$ helm chart export \
registry.gitlab.com/hippolab/helm-charts/nginx:0.0.1

После чего в вашей текущей директории появится папка "nginx" содержащая nginx helm chart, которую уже можно будет деплоить

Понравилась статья? Поддержите HippoLab в социальных сетях!