Как стать автором
Обновить

13 рекомендаций по использованию Helm

Время на прочтение 12 мин
Количество просмотров 7.6K
Автор оригинала: Kentaro Wakayama

Helm — незаменимый инструмент для развертывания приложений в кластерах Kubernetes. Но только следуя передовому опыту, вы действительно ощутите преимущества Helm. Вот 13 рекомендаций, которые помогут вам создавать, использовать и обновлять приложения с помощью Helm.


Коллеги, пишите, если что-то переведено неправильно.


Поднимите свои Helm Charts на новый уровень


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


Предположим, вы развертываете базу данных с Kubernetes, включая несколько развертываний, контейнеров, секретов, томов и служб. Helm позволяет установить одну и ту же базу данных с помощью одной команды и одного набора значений. Его декларативные и идемпотентные команды делают Helm идеальным инструментом для непрерывной доставки (CD).


Helm — это проект Cloud Native Computing Foundation (CNCF), созданный в 2015 году и завершенный в апреле 2020 года. С последней версией Helm 3 он стал еще более интегрированным в экосистему Kubernetes.


В этой статье представлены 13 рекомендаций по созданию диаграмм Helm для управления вашими приложениями, работающими в Kubernetes.


1. Использование преимуществ экосистемы Helm


Helm дает вам доступ к обширному опыту сообщества — возможно, самое большое преимущество инструмента. Он собирает чарты от разработчиков со всего мира, которые затем передаются через репозитории диаграмм. Вы можете проверить в Artifact Hub доступные репозитории диаграмм Helm.


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


$ helm repo add bitnami https://charts.bitnami.com/bitnami

Затем вы можете искать диаграммы, например, MySQL:


$ helm search hub mysql

URL                                                     CHART VERSION   APP VERSION     DESCRIPTION                                       
https://hub.helm.sh/charts/bitnami/mysql                8.6.3           8.0.25          Chart to create a Highly available MySQL cluster

2. Использование subcharts для управления своими зависимостями


Поскольку приложения, развернутые в Kubernetes, состоят из детализированных, взаимозависимых частей, их диаграммы Helm имеют различные шаблоны ресурсов и зависимости. Например, предположим, что ваш бэкэнд полагается на базу данных и очередь сообщений. База данных и очередь сообщений уже являются автономными приложениями (например, PostgreSQL и RabbitMQ). Поэтому рекомендуется создавать или использовать отдельные чарты для автономных приложений и добавлять их в родительские чарты. Зависимые приложения названы здесь в виде поддиаграмм.


Есть три основных элемента для создания и настройки subcharts:


  • Структура чарта. Структура папок должна быть в следующем порядке:

backend-chart
  - Chart.yaml
  - charts
      - message-queue
          - Chart.yaml
          - templates
          - values.yaml
      - database
          - Chart.yaml
          - templates
          - values.yaml
  - values.yaml

  • Chart.yaml

Кроме того, в файле chart.yaml родительском чарте должны быть перечислены все зависимости и условия:


apiVersion: v2
name: backend-chart
description: A Helm chart for backend
...
dependencies:
  - name: message-queue
    condition: message-queue.enabled
  - name: database
    condition: database.enabled

  • values.yaml

Наконец, вы можете установить или переопределить значения вложенных диаграмм в родительской диаграмме с помощью следующего файла values.yaml:


message-queue:
  enabled: true
  image:
    repository: acme/rabbitmq
    tag: latest
database:
  enabled: false

Создание и использование subcharts устанавливает уровень абстракции между родительским и зависимым приложениями. Эти отдельные чарты упрощают развертывание, отладку и обновление приложений в Kubernetes с их отдельными значениями и жизненными циклами обновления. Вы можете просмотреть структуру папок, зависимости и файлы значений в образце диаграммы, например bitnami / wordpress.


3. Использование Labels для простого нахождения ресурсов


Labels имеют решающее значение для внутренних операций Kubernetes и повседневной работы операторов Kubernetes. Почти каждый ресурс в Kubernetes предлагает метки для разных целей, таких как группировка, распределение ресурсов, балансировка нагрузки или планирование.


Одна команда Helm позволит вам установить несколько ресурсов. Но очень важно знать, откуда берутся эти ресурсы. Labels позволяют быстро находить ресурсы, созданные релизами Helm.


Самый распространенный метод — определить метки в helpers.tpl, например:


{{/*
Common labels
*/}}

{{- define "common.labels" -}} 
app.kubernetes.io/instance: {{ .Release.Name }}
app.kubernetes.io/managed-by: {{ .Release.Service }}
{{- end -}}

Затем вам нужно использовать функцию include с метками в шаблонах ресурсов:


apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-queue
  labels:
{{ include "common.labels" . | indent 4 }}
...

Теперь вы должны иметь возможность перечислить все ресурсы с помощью селекторов меток. Например, вы можете перечислить все модули развертывания my-queue с помощью команды kubectl get pods -l app.kubernetes.io/instance=[Name of the Helm Release]. Этот шаг важен для поиска и отладки тех ресурсов, которыми управляет Helm.


4. Документирование чартов


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


Вы должны использовать следующие три варианта для документирования ваших диаграмм:


  • Комментарии: Файлы шаблонов и значений являются файлами YAML. Вы можете добавлять комментарии и предоставлять полезную информацию о полях в файлах YAML.
  • README: README диаграммы — это файл уценки, в котором объясняется, как использовать диаграммы. Вы можете проверить содержимое файла README с помощью следующей команды: helm show readme [Name of the Chart]
  • NOTES.txt: это специальный файл, расположенный по адресу templates/NOTES.txt, который предоставляет полезную информацию о развертывании выпусков. Для содержимого файла NOTES.txt также можно использовать шаблоны функций и значений, аналогичные шаблонам ресурсов:

You have deployed the following release: {{ .Release.Name }}.
To get further information, you can run the commands:
  $ helm status {{ .Release.Name }}
  $ helm get all {{ .Release.Name }}

В конце команды helm install или helm upgrade Helm распечатывает содержимое NOTES.txt следующим образом:


RESOURCES:
==> v1/Secret
NAME        TYPE      DATA      AGE
my-secret   Opaque    1         0s

==> v1/ConfigMap
NAME           DATA      AGE
db-configmap   3         0s

NOTES:
You have deployed the following release: precious-db.
To get further information, you can run the commands:
  $ helm status precious-db
  $ helm get all precious-db

5. Проверка чартов


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


К счастью, Helm предлагает функцию тестирования для запуска некоторых контейнеров в кластере для проверки приложений. Например, шаблоны ресурсов, помеченные как "helm.sh/hook": test-success, запускаются Helm как тестовые примеры.


Предположим, вы развертываете WordPress с базой данных MariaDB. Чарт Helm, поддерживаемый Bitnami, имеет модуль для проверки соединения с базой данных со следующим определением:


...
apiVersion: v1
kind: Pod
metadata:
  name: "{{ .Release.Name }}-credentials-test"
  annotations:
    "helm.sh/hook": test-success
...
      env:
        - name: MARIADB\_HOST
          value: {{ include "wordpress.databaseHost" . | quote }}
        - name: MARIADB\_PORT
          value: "3306"
        - name: WORDPRESS\_DATABASE\_NAME
          value: {{ default "" .Values.mariadb.auth.database | quote }}
        - name: WORDPRESS\_DATABASE\_USER
          value: {{ default "" .Values.mariadb.auth.username | quote }}
        - name: WORDPRESS\_DATABASE\_PASSWORD
          valueFrom:
            secretKeyRef:
              name: {{ include "wordpress.databaseSecretName" . }}
              key: mariadb-password
      command:
        - /bin/bash
        - -ec
        - |
          mysql --host=$MARIADB\_HOST --port=$MARIADB\_PORT --user=$WORDPRESS\_DATABASE\_USER --password=$WORDPRESS\_DATABASE\_PASSWORD
  restartPolicy: Never
{{- end }}
...

Рекомендуется писать тесты для ваших чартов и запускать их после установки. Например, вы можете использовать команду helm test <RELEASE_NAME> для запуска тестов. Тесты являются ценным активом для проверки и поиска проблем в приложениях, установленных вместе с Helm.


6. Обеспечение безопасности секретов


Конфиденциальные данные, такие как ключи или пароли, хранятся в Kubernetes как секреты. Хотя на стороне Kubernetes можно защитить секреты, они в основном хранятся в виде текстовых файлов как часть шаблонов и значений Helm.


Плагин helm-secrets предлагает секретное управление и защиту вашей важной информации. Он делегирует секретное шифрование Mozilla SOPS, который поддерживает AWS KMS, Cloud KMS на GCP, Azure Key Vault и PGP.


Предположим, вы собрали конфиденциальные данные в файл с именем secrets.yaml следующим образом:


$ helm secrets enc secrets.yaml
Encrypting secrets.yaml
Encrypted secrets.yaml

Вы можете зашифровать файл с помощью плагина:


postgresql:
    postgresqlUsername: ENC\[AES256\_GCM,data:D14/CcA3WjY=,iv...==,type:str\]
    postgresqlPassword: ENC\[AES256\_GCM,data:Wd7VEKSoqV...,type:str\]
    postgresqlDatabase: ENC\[AES256\_GCM,data:8ur9pqDxUA==,iv:R...,type:str\]
sops:
  ...

Теперь файл будет обновлен, и все значения будут зашифрованы:


postgresql:
    postgresqlUsername: ENC\[AES256\_GCM,data:D14/CcA3WjY=,iv...==,type:str\]
    postgresqlPassword: ENC\[AES256\_GCM,data:Wd7VEKSoqV...,type:str\]
    postgresqlDatabase: ENC\[AES256\_GCM,data:8ur9pqDxUA==,iv:R...,type:str\]
sops:
  ...

Приведенные выше данные в файле secrets.yaml не были безопасными, а helm-secrets решает проблему хранения конфиденциальных данных как части диаграмм Helm.


7. Создание многоразовой диаграммы с помощью шаблонных функций


Helm поддерживает более 60 функций, которые можно использовать внутри шаблонов. Функции определены на языке шаблонов Go и библиотеке шаблонов Sprig. Функции в файлах шаблонов значительно упрощают работу Helm.


Давайте посмотрим на следующий файл шаблона в качестве примера:


apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ .Release.Name }}-configmap
data:
  environment: {{ .Values.environment | default "dev" | quote }}
  region: {{ .Values.region | upper | quote }}

Если значение среды не указано, функция шаблона будет использовать его по умолчанию. Проверив поле региона, вы увидите, что в шаблоне нет значения по умолчанию. Однако у поля есть другая функция, называемая upper, для преобразования предоставленного значения в верхний регистр.


Требуется еще одна важная и полезная функция — required. Она позволяет вам установить значение, необходимое для рендеринга шаблона. Например, предположим, что вам нужно имя для вашей ConfigMap со следующим шаблоном:


...
metadata:
  name: {{ required "Name is required" .Values.configName }}
...

Если запись пуста, рендеринг шаблона завершится ошибкой. Требуется имя. Функции шаблонов очень полезны при создании чартов Helm. Они могут улучшить создание шаблонов, уменьшить дублирование кода и могут использоваться для проверки значений перед развертыванием ваших приложений в Kubernetes.


8. Обновление развертываний (Deployments) при изменении ConfigMaps или секретов.


Обычно к контейнерам монтируются ConfigMaps или секреты. Хотя развертывания и образы контейнеров меняются с новыми выпусками, ConfigMaps или секреты меняются нечасто. Следующая аннотация позволяет развертывать новые развертывания (Deployments) при изменении ConfigMap:


kind: Deployment
spec:
  template:
    metadata:
      annotations:
        checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") . | sha256sum }}
...

Любое изменение в ConfigMap вычислит новую сумму sha256sum и создаст новые версии развертывания (Deployments). Это гарантирует, что контейнеры в развертываниях (Deployments) будут перезапущены с использованием нового ConfigMap.


9. Отказ от удаления ресурсов с помощью политик ресурсов.


В типичной настройке после установки Helm чартов, Helm создает несколько ресурсов в кластере. Затем вы можете обновить его, изменив значения и добавив или удалив ресурсы. Когда приложение больше не понадобится, его можно удалить, что приведет к удалению всех ресурсов из кластера. Однако некоторые ресурсы следует сохранить в кластере даже после выполнения удаления Helm. Предположим, вы развернули базу данных с PersistentVolumeClaim и хотите сохранить тома, даже если вы удаляете выпуск базы данных. Для таких ресурсов вам необходимо использовать аннотации политики ресурсов следующим образом:


kind: Secret
metadata:
  annotations:
    "helm.sh/resource-policy": keep
...

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


10. Полезные команды для отладки Helm-чартов.


Файлы шаблонов Helm содержат множество различных функций и несколько источников значений для создания ресурсов Kubernetes. Важная обязанность пользователя — знать, что развернуто в кластере. Следовательно, вам нужно научиться отлаживать шаблоны и проверять чарты. Для отладки можно использовать четыре основные команды:


  • helm lint: инструмент линтер проводит серию тестов, чтобы убедиться, что ваш чарт сформирован правильно.
  • helm install --dry-run --debug: эта функция отображает шаблоны и показывает полученные манифесты ресурсов. Вы также можете проверить все ресурсы перед развертыванием и убедиться, что значения установлены, а функции шаблонов работают должным образом.
  • helm get manifest: эта команда извлекает манифесты ресурсов, установленных в кластере. Если выпуск (release) не работает должным образом, это должна быть первая команда, которую вы используете, чтобы узнать, что работает в кластере.
  • helm get values: эта команда используется для получения значений выпуска (release), установленных в кластере. Если у вас есть какие-либо сомнения относительно вычисленных значений или значений по умолчанию, это обязательно должно быть в вашем наборе инструментов.

11. Использование функций поиска, чтобы избежать регенерации секрета.


Функции Helm используются для генерации случайных данных, таких как пароли, ключи и сертификаты. Случайная генерация создает новые произвольные значения и обновляет ресурсы в кластере при каждом развертывании и обновлении. Например, он может заменять пароль вашей базы данных в кластере при каждом обновлении версии. Это приводит к тому, что клиенты не могут подключиться к базе данных после смены пароля.


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


{{- $rootPasswordValue := (randAlpha 16) | b64enc | quote }}
{{- $secret := (lookup "v1" "Secret" .Release.Namespace "db-keys") }}
{{- if $secret }}
{{- $rootPasswordValue = index $secret.data "root-password" }}
{{- end -}}
apiVersion: v1
kind: Secret
metadata:
  name: db-keys
  namespace: {{ .Release.Namespace }}
type: Opaque
data:
  root-password: {{ $rootPasswordValue}}

Приведенный выше шаблон сначала создает 16-символьное значение randAlpha, затем проверяет кластер на секрет и соответствующее ему поле. Если он найден, он переопределяет и повторно использует rootPasswordValue в качестве пароля root.


12. Переход на Helm 3 для более простых и безопасных приложений Kubernetes.


Последний выпуск Helm — Helm 3, предлагает множество новых функций, которые делают его более легким и оптимизированным инструментом. Helm v3 рекомендуется из-за его повышенной безопасности и простоты. Это включает в себя:


  • Удаление Tiller: Tiller был серверным компонентом Helm, но был удален из v3 из-за наличия исчерпывающих разрешений, необходимых для внесения изменений в кластер в более ранних версиях. Это также создало угрозу безопасности, поскольку любой, кто получит доступ к Tiller, будет иметь чрезмерные разрешения для вашего кластера.
  • Улучшенная стратегия обновления чартов: Helm v2 полагается на двусторонний стратегический патч слияния (two-way strategic merge patch, как правильно перевести?). Он сравнивает новую версию с версией в хранилище ConfigMap и применяет изменения. И наоборот, Helm v3 сравнивает старый манифест, состояние в кластере и новый выпуск (release). Таким образом, внесенные вами вручную изменения не будут потеряны при обновлении выпусков Helm. Это упрощает процесс обновления и повышает надежность приложений.

Существует плагин helm-2to3, который вы можете установить с помощью следующей команды:


$ helm3 plugin install https://github.com/helm/helm-2to3

Это небольшой, но полезный плагин с командами очистки, преобразования и перемещения, которые помогут вам перенести и очистить конфигурацию v2 и создать выпуски для v3.


13. Поддерживание идемпотентности ваших конвейеров непрерывной доставки


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


Необходимо соблюдать два основных правила:


  • Всегда используйте команду helm upgrade --install. Он устанавливает диаграммы, если они еще не установлены. Если они уже установлены, он обновляет их.
  • Используйте флаг --atomic для отката изменений в случае неудачной операции во время обновления Helm. Это гарантирует, что выпуски Helm не застрянут в состоянии сбоя.

Резюме


Helm — незаменимый инструмент для развертывания приложений в кластерах Kubernetes. Но только следуя передовому опыту, вы действительно ощутите преимущества Helm.


Лучшие практики, описанные в этой статье, помогут вашим командам создавать, использовать и обновлять распределенные приложения производственного уровня. Что касается разработки, ваши диаграммы Helm будет проще поддерживать и защищать. Что касается эксплуатации, вы получите удовольствие от автоматически обновляемых развертываний, сэкономите ресурсы от удаления и научитесь тестировать и отлаживать.


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


Коллеги, пишите, если что-то переведено неправильно.


Немного рекламы: На платформе https://rotoro.cloud/ вы можете найти курсы с практическими занятиями:


Теги:
Хабы:
Если эта публикация вас вдохновила и вы хотите поддержать автора — не стесняйтесь нажать на кнопку
+9
Комментарии 5
Комментарии Комментарии 5

Публикации

Истории

Работа

DevOps инженер
39 вакансий

Ближайшие события

Московский туристический хакатон
Дата 23 марта – 7 апреля
Место
Москва Онлайн
Геймтон «DatsEdenSpace» от DatsTeam
Дата 5 – 6 апреля
Время 17:00 – 20:00
Место
Онлайн
PG Bootcamp 2024
Дата 16 апреля
Время 09:30 – 21:00
Место
Минск Онлайн
EvaConf 2024
Дата 16 апреля
Время 11:00 – 16:00
Место
Москва Онлайн