Хорошая практика
Helm Chart - Руководство по разработке
Написание поддерживаемых и надежных диаграмм с помощью нескольких уловок
Только что решили написать свою первую схему управления штурвалом? Ищете подсказки, как начать? Прокрутка документации руля весь день? Случайно нажимая на статьи на носителе?
Вы попали в идеальное место, чтобы организовать свои мысли и познакомиться с некоторыми передовыми практиками.
Helm - мощный инструмент для применения, обновления и управления приложениями в Kubernetes. Сообщество Helm создает множество диаграмм с открытым исходным кодом. Вы можете развернуть Redis, Nginx или Prometheus-operator с помощью одной команды. И они поставляются со всем, что нам нужно, например, сервисами, ingress.
Helm позволяет сосредоточиться на самых важных ценностях
В этом руководстве я опишу самый быстрый способ создания базовой диаграммы, представлю полезные команды и покажу лучшие практики, которые сделают процесс создания диаграммы более приятным. Я не буду останавливаться на аспектах языка шаблонов go, потому что большинство из них описано в документации по helm. Это руководство предназначено для более абстрактных аспектов и представляет идеи по улучшению вашего рабочего процесса.
Начните с предварительной диаграммы
Начало матча одной командой:
$ helm create basic Creating basic $ tree basic basic/ ├── charts ├── Chart.yaml ├── templates │ ├── deployment.yaml │ ├── _helpers.tpl │ ├── ingress.yaml │ ├── NOTES.txt │ ├── serviceaccount.yaml │ ├── service.yaml │ └── tests │ └── test-connection.yaml └── values.yaml
Вот и все, чтобы создать готовую к развертыванию диаграмму! Такая диаграмма позволяет развернуть приложение со всеми необходимыми компонентами. Если вы заглянете в values.yaml, вы увидите, что это приложение будет развертывать Nginx. Развернуть диаграмму так же просто, как создать:
$ helm install basic
Команда шаблона - ваш лучший друг
Непосредственно перед установкой и после того, как что-то изменили в диаграмме, вы должны проверить, все ли обрабатывается в шаблонах должным образом. Чтобы проверить, что будет развернуто в кластере, используйте команду:
$ helm template basic
Это выведет каждый yaml, созданный всеми шаблонами. Если вы хотите увидеть результат только одного шаблона, используйте:
$ helm template basic -x templates/service.yaml
Результат должен быть похож на:
Более того, чтобы протестировать шаблон с пользовательскими значениями, используйте:
$ helm template basic -x templates/service.yaml -f \ mypath/tocustomvalues.yaml
Сгенерированный шаблон можно протестировать на кластере с:
$ helm install basic --dry-run --debug
Lint это вверх
Перед отправкой в репозиторий вы можете добавить еще один шаг для четкой проверки кода - линтинг.
$ helm lint basic/ ==> Linting basic/ [INFO] Chart.yaml: icon is recommended 1 chart(s) linted, no failures
Helm имеет функции
Когда мы заглядываем в каталог диаграмм шаблонов, мы можем найти _helpers.tpl. Здесь вы можете добавить больше функций, которые доступны по всему графику. Пример функции может выглядеть так:
А использование функции в шаблоне может быть достигнуто с помощью функции include:
Metalabels, сын
Важная часть Kubernetes - это правильная разметка. Это еще более важно, когда вы используете helm для развертывания множества манифестов, управляемых выпуском helm. Чтобы легко добавить метки, которые позволят находить ресурсы, управляемые нашим выпуском helm, мы можем использовать упомянутый ранее поток функций:
А теперь добавление нескольких меток к диаграмме - это детская игра:
Если мы когда-нибудь захотим найти сервисы, созданные с помощью этой диаграммы, мы воспользуемся командой:
$ kubectl get svc -l helm.sh/chart=basic-0.1.0
Комментарии могут спасти вам жизнь
Возможны два типа комментариев:
- # - простой комментарий, но преобразованный с помощью шаблонизатора
- {{- / *… * / -}} - комментарий шаблона менее понятен, но опущен механизмом шаблонов
Вывод шаблона будет выглядеть так:
# app files volume
- name: app-notification-files
configMap:
name: app-notification-files
Как видим, сгенерированный манифест содержит только комментарий простого типа. Когда вы хотите использовать один из типов, решать вам. Комментарии к шаблонам полезны при описании функций и более сложных конвейеров / зависимостей в yaml.
Важно знать, что # комментариев также анализируются - поэтому, если вы поместите структуру шаблона go в комментарий - он будет проанализирован. Так что комментарии тоже могут быть шаблонами.
Документы могут спасти нашу жизнь
Документы для диаграмм незаменимы - особенно для диаграмм, которые вы хотите опубликовать. Самый простой способ создавать и поддерживать документы - использовать пакет Golang с именем helm-docs. С помощью helm-docs вы можете создать README.md, содержащий таблицы значений, версий и описания, взятые из values.yaml и Chart.yaml (или используйте больше пользовательских файлов). Пример:
Как видите, добавление имени с - приводит к одной строке в таблице. Кроме того, с таблицей идет дополнительная информация, такая как описание диаграммы, имя и версия. Helm-docs можно интегрировать в pre-commit вместе с линтингом. Использовать это так же просто, как написать:
$ helm-docs INFO[2020-07-23T15:30:38+02:00] Found Chart directories [.] INFO[2020-07-23T15:30:38+02:00] Generating README Documentation for chart .
Подграфик магии
Когда ваша диаграмма становится монстром, который создает всю архитектуру, лучше всего разделить некоторые компоненты диаграммы на более мелкие диаграммы, называемые поддиаграммами (или дочерними диаграммами). Подграфикы развертываются с основной диаграммой одновременно. Значения для вложенных диаграмм могут быть предоставлены в том же файле values.yaml для основной диаграммы. Подграфик можно включить в GitHub, но для целей статьи я создам подграфик локально. Чтобы начать с новой диаграммы, которая будет зависимой, создайте каталог диаграмм внутри папки диаграмм. Затем создайте базовую диаграмму:
$ mkdir charts $ cd charts $ helm create subbasic
Чтобы включить определение изменения поддиаграммы родительской диаграммы:
Теперь каждый раз, когда вы запускаете команду helm install, будет разворачиваться под-диаграмма. Чтобы переопределить одно из значений ссылочного имени вложенной диаграммы дочерней диаграммы в родительской диаграмме values.yaml:
subbasic:
service:
type: NodePort
nameOverride: "jojo"
Затем запустите команду шаблона и проверьте измененный вывод службы подграфов:
Как видите - вид услуги изменился вместе с названием.
Важное примечание - вложенные диаграммы не могут принимать значения из родительской диаграммы.
Не такой известный или забытый
Несколько фактов, которые стоит упомянуть:
- Имена ресурсов не могут быть длиннее 63 символов.
- Имена ресурсов могут включать только буквенно-цифровые символы в нижнем регистре, "-" или "."
- Размер диаграммы не может быть больше 1 МБ - это особенно важно, если вы используете прикрепление файлов.
- В диаграмме есть функция для анализа
.tpl. - Вы можете оставить некоторые ресурсы, даже если helm удалит выпуск.
И ты готов к работе
Пройдя через все эти функции и практики, вы сможете без проблем написать свою первую диаграмму. Стоит упомянуть о прикреплении файлов - диаграмма управления не подходит для добавления файлов и сохранения их структуры в каталогах. Не ждите, что руль все сделает. Хотя у Helm есть страница Лучшие практики, вы не найдете ответов о том, что следует держать в диаграмме, а что нет. Это еще довольно молодой инструмент, но с большим потенциалом. Не забывайте, что линтинг, создание документации и даже сухие шаблоны в кластере могут быть частью CI. Для Github уже доступны рабочие процессы руля.
Счастливого Хелминга!
