Что такое helm chart
Практическое знакомство с пакетным менеджером для Kubernetes — Helm
Статья является логическим продолжение нашей недавней публикации об истории пакетного менеджера для Kubernetes — Helm. В этот раз мы снова затронем вопросы устройства и функционирования нынешнего Helm (версия 2.x), а также управляемых им чартов и репозиториев, после чего перейдём к практике: установке Helm в кластер Kubernetes и использованию чартов.
Вступление
Helm — инструмент для управления чартами.
Чарт описывает необходимый набор данных для создания экземпляра приложения в кластере Kubernetes. Он может иметь вложенные чарты и использоваться как для описания полноценных сервисов, состоящих из множества зависимых ресурсов, так и для описания отдельных независимых составляющих. К примеру, чарт stable/gitlab-ce описывает комплексное решение с использованием независимых чартов redis и postgresql.
Чарт может быть установлен неограниченное количество раз в одном и том же кластере. Таким образом, описание логики выката приложения в разные окружения может и должно храниться в одном чарте.
Клиентская часть Helm отвечает за формирование чарта и передачу вместе с пользовательскими параметрами находящемуся в кластере Kubernetes компоненту Tiller. В свою очередь, Tiller отвечает за жизненный цикл экземпляра запущенного чарта, релиза. (На всякий случай напомню, что в следующем крупном обновлении Helm — версии 3 — уже не будет Tiller.)
А теперь — обо всём по порядку.
Установка и обновление
Для работы с Helm требуется Kubernetes. Можно использовать локально установленный Minikube (см. также «Начало работы в Kubernetes с помощью Minikube») или любой другой доступный кластер.
Начнём с установки клиента: выбираем релиз, скачиваем и распаковываем архив для своей системы, переносим исполняемый файл…
Теперь Tiller установлен в кластер и готов к управлению релизами, взаимодействию с Kubernetes API.
Репозитории чартов
По умолчанию Helm использует официальный репозиторий чартов Kubernetes. Он содержит тщательно проработанные актуальные чарты для решения множества прикладных задач. Этот репозиторий именуется stable:
При необходимости создание собственного репозитория не составит никаких проблем. Требования к серверу — минимальные, поэтому, как и большинство публичных репозиториев чартов, его можно разместить на GitHub Pages. Подробнее про инструменты и необходимые для этого шаги можно почитать в документации.
При использовании репозиториев чартов они могут быть добавлены и удалены. Для того, чтобы версии чартов были актуальными, необходимо периодически обновлять индекс. Приведу пример для публичного репозитория bitnami, большая часть чартов которого используется в официальном репозитории Helm:
Далее — поиск по репозиториям. Вызов helm search без аргументов показывает все доступные чарты:
В необязательном поле keywords в Chart.yaml разработчики указывают теги, которые используются для упрощения поиска в репозиториях чартов:
Примечание: При использовании команды helm search можно столкнуться с нестабильной работой нескольких фильтров: наличие результата зависит от порядка указания и количества фильтров.
В официальном репозитории чарты прекрасно документированы и содержат примеры использования, а некоторые чарты — даже готовые конфигурации для production. К примеру, хороший readme представлен у stable/wordpress (для его вывода в консоли см. helm inspect readme stable/wordpress ).
Поиск — это хороший способ найти доступные пакеты. После того, как пакет найден, можно использовать его для установки приложения в кластер.
Первое приложение
Для примера выбран уже упомянутый чарт stable/wordpress.
Установим чарт с конфигурацией для production, поменяем название блога, отключим сохранение данных WordPress в PersistentVolumeClaim (подробнее про постоянные хранилища см. в документации Kubernetes):
В случае работы с полноценным кластером далее можно следовать рекомендациям из блока NOTES выше. Если же у вас Minikube — откройте сайт в браузере следующим образом:
Поздравляю, приложение в кластере!
Развёрнутый чарт с WordPress появился в списке всех релизов Helm:
Следующим шагом обновим наш релиз и изменим образ с блогом. Для примера будет использован другой тег из того же Docker-репозитория ( 4.9.8-ol-7 ):
Обратите внимание, что при обновлении Tiller сравнивает полученный чарт с параметрами с последним сохранённым и выполняет соответствующие запросы в Kubernetes API, а актуальное состояние ресурсов релиза не берётся в расчёт. Важно понимать эту особенность и не совершать ошибок:
Состояние компонентов релиза приложения в кластере всегда можно проверить следующим образом:
Helm позволяет откатываться до определённой ревизии релиза. На текущий момент ревизий две:
Откатим приложения к первоначальному состоянию:
Теперь история ревизий пополнилась на одну запись:
Статья подходит к концу и релиз больше не требуется?
А удалён ли он в действительности.
Команда удаляет Kubernetes-ресурсы, связанные с релизом, но не сам релиз. Вся информация о релизе остаётся доступной, в том числе и его история:
Примечание: По задумке, удалённый релиз можно откатывать к предыдущим версиям, но в последних версиях эта возможность не работает — подробности см. в issue #3722.
Резюмируя
В этой статье рассказано про базовую архитектуру Helm 2, его компоненты и их функций, а также об основных примитивах, чартах, релизах и репозиториях чартов. Мы установили Helm в кластер Kubernetes и получили понимание жизненного цикла релиза и основных команд для работы с ним.
Следующий материал из этого цикла будет посвящён теме создания собственного чарта — в нём я расскажу про структуру чарта, шаблонизацию и инструменты отладки. ОБНОВЛЕНО: Новая статья доступна по этой ссылке.
Погружение в Helm Package Manager. Часть первая
Helm — один из самых популярных пакетных менеджеров для Kubernetes. Познакомиться с ним полезно любому DevOps-инженеру и всем, кто сталкивается с задачами деплоя приложений. Эту мини-серию из двух статей можно рассматривать как краткое, но достаточно полное введение в Helm. В первой части поговорим об архитектуре Helm и некоторых типичных задачах, которые он позволяет решать. В частности, кастомизации приложения и переиспользвании кода.
Фрагменты кода в статье специально даны в виде картинок — это позволило выделить важные для нас строки. Но для вашего удобства я на всякий случай собрал все примеры в этом репозитории.
Назначение Helm
Современное приложение — сложный продукт с множеством внутренних компонентов и внешних связей.
При этом чаще всего у нас есть несколько рабочих окружений, которые могут достаточно сильно отличаться друг от друга и по количеству компонентов и связей, и по их качеству.
Кроме того, в современном мире микросервисов и распиленных монолитов у нас может быть гораздо больше одного проекта.
Управлять этим сложным хозяйством хочется максимально простым, универсальным и наименее затратным способом. Поэтому отношение к выбору подходящего инструмента для деплоя и построение технической дисциплины на его основе варируется от хорошей практики до необходимого условия выживания.
Таким тулингом для многих стал Helm Package Manager.
Возможности Helm
Список основных возможностей включают в себя:
Простую текстовую шаблонизацию (Go templates + Sprig framework).
Управление релизами (установка, апгрейд, откат, удаление).
Tracking выката релиза с возможностью отката в случае неудачи.
Для публикации последних создатели Helm даже запустили специальный сайт artifacthub.io. Там уже собрана и постоянно пополняется сообществом огромная коллекция чартов (в апреле 2021-го их было 3402, в сентябре — уже 5568).
Правда, как это бывает с опенсорс-наработками, их качество совершенно разное (я бы не рекомендовал использовать чарты с artifactshub без изменений). Более или менее сориентироваться в содержимом позволяют звезды, которые присваивают наработкам пользователи. Разумеется, вы также можете внести вклад в оценку.
В любом случае, даже если не найдете ничего подходящего, всегда можно взять готовый вариант за основу собственного проекта. Просто чтобы не начинать с нуля.
Альтернативы Helm
Конечно же, Helm — не единственное решение для деплоя в Kubernetes. У нас есть и другие:
Kustomize от авторов Kubernetes. Этакий «kubectl на стероидах», который, однако, слабо подходит для больших и сложных проектов.
Паттерн Kubernetes Operators, который в последнее время активно продвигает компания Red Hat. Она спонсируют опенсорсный Operators Framework и сайт operatorshub.io для публикации наработок. Более того, даже встроила в свою платформу OpenShift возможность установки операторов с этого сайта по клику. Но нужно понимать, что Kubernetes Operator — вещь в себе. Порой очень трудно разобраться, как он все-таки работает, а уж тем более внести в него изменения.
Ansible. Его используют многие, хотя, на мой взгляд, когда дело касается деплоя в Kubernetes, Ansible в сочетании с Jinja — прекрасный способ все запутать.
Terraform. С его помощью также можно строить деплой, используя какие-нибудь специализированные провайдеры, только вот красивых решений на его основе лично я до сих пор не видел.
Jsonnet — язык шаблонизации от Google, на котором построены некоторые инструменты. Например:
При выборе инструмента, безусловно, стоит учесть и его слабые стороны. Например, именно недостатки Helm и попытались преодолеть ребята из Grafana, создавая собственный продукт Tanka с использованием jsonnet.
Итак, основные недостатки Helm:
Только строковая шаблонизация. Мы строим деплой, ничего не зная о конечных примитивах, основываясь на хрупком YAML-синтаксисе.
Сложное расширение. Если вам чего-то не хватает в готовом чарте, скорее всего, придется его форкнуть и доработать самостоятельно.
Низкий уровень абстракции. Мы не можем описать объект, порождающий deployment, service и ingress, унаследоваться от него и переопределить deployment в StatefulSet.
Потенциальная запутанность. Конечные результаты генерации релиза могут очень сильно различаться в зависимости от значений, которые мы подали на вход.
Но несмотря на все недостатки Helm, я не знаю людей, сменивших его на что-то другое. А вот с обратными примерами сталкивался неоднократно. Например, мои знакомые сперва деплоили при помощи Terraform и Jsonnet provider, потом перешли на Ansible, но в итоге и его переписывают на Helm. Они объяснили это тем, что начали привлекать для описания деплоя в Kubernetes разработчиков, а Helm, покрывая большинство их потребностей, обеспечивает еще и низкий уровень входа.
Кстати, та же Tanka не так давно официально и с гордостью объявила о поддержке Helm charts.
Архитектура и основные понятия Helm
Сейчас актуальны версии Helm 2 и Helm 3, причем последняя, в отличии от предыдущей, не имеет серверного компонента (Tiller). Фактически это просто Go-бинарник, причем Helm 3 гораздо более легковесный и дружественный к разделению прав.
Архитектура Helm 3 представлена на схеме:
Работает же Helm 3 следующим образом:
Получает на вход Chart (локально или из репозитория, при этом чарты могут использовать друг друга) и генерирует манифест релиза.
Получает текст предыдущего релиза.
Получает текущее стостояние примитивов из namespace-релиза.
Сравнивает эти три вещи, делает patch и передает его в KubeAPI.
Дожидается выката релиза (опциональный шаг).
Эта схема называется 3-way merge. Таким образом Helm приведет конфигурацию приложения к состоянию, которое описано в git, но не тронет другие изменения. Т. е., если у вас в кластере есть какая-то сущность, которая трансформирует ваши примитивы (например, Service Mesh), то Helm отнесется к ним бережно.
Теперь пройдемся по основным понятиям Helm.
1. Helm chart
Фактически, папка определенной структуры с текстовыми файлами внутри. По команде helm create [chartname] будет создана заготовка, которую вы сможете развить нужным вам образом.
Файлы имеют разную структуру и назначение. Например, в Chart.yaml описаны основные параметры чарта. Перед вами официальный Chart.yaml minio:
В нем много произвольных описательных полей, однако необходимое и достаточное условие — указать только name и version. Если хотите копнуть глубже, вам сюда.
2. Репозиторий чартов
В принципе, управлять репозиторием можно вручную, используя команды Helm. Хотя существует и ПО, обеспечиващее быстрый старт и визуальные интерфейсы для облегчения работы. Например:
Копнуть глубже можно здесь.
3. Helm Release, Helm Values
Helm Release генерируется из чарта (Chart) с использованием входных значений (Values):
Chart + Values = Release
При помощи команды helm list мы можем просмотреть релизы, установленные в конкретном Kubernetes Namespace.
С релизами связано понятие Release backend — места, в котором Helm хранит и версионирует переданные на деплой релизы.
Это может быть configmap/secret/SQL. По умолчанию это secret — Helm создает объект этого типа (в котором хранится JSON, завернутый в gzip + Base64) на каждый релиз в Namespace, куда его и устанавливает. Хотя он может сделать это и, например, в SQL-базе.
Типовые задачи «YAML-девелопера»
Перейдем к задачам, которые наиболее часто возникают в процессе деплоя приложений в Kubernetes, и их реализции с помощью Helm. У меня получился вот такой короткий список:
Кастомизация приложения в разрезе окружений.
Управление блоками кода по условию.
Установка очередности запуска подов.
Расширение функциональности Helm.
Как видите, в список вошли и базовые, я бы даже сказал, экзистенциальные, задачи вроде переиспользования кода, и вполне практические, вроде отладки
1. Кастомизация приложения в разрезе окружений
У нас может быть достаточно много окружений, похожих в целом, но, в то же время, имеющих несколько важных отличий.
Среди последних можно выделить два типа:
Отличия, связанные с параметрами работы приложений (например, данные внешних систем, имена баз, очередей и т. п.).
Отличия в инфраструктуре (адреса ингрессов, количество реплик, включение или отключение инфраструктурных компонентов).
Согласно лучшим практикам, мы должны уметь передавать рабочие параметры в приложение как можно ближе к деплою. Если вы до сих пор устанавливаете их при сборке имиджа или запекаете в образ, не делайте так — этот подход чреват многими проблемами. Хороший способ управления рабочими параметрами — передавать их через переменные окружения или configmap, которые монтируются в под.
Управление инфраструктурными изменениями концептуально сходно с управлением рабочими параметрами приложения: в рамках Helm это изменение текстовых файлов в зависимости от набора входных значений.
Чтобы управлять входными значениями, в Helm есть механизм Values, расположенный в файле values.yaml:
Мы можем использовать values в templates.
Values.yaml представляет собой иерархическую древовидную структуру «ключ — значение».
С ее помощью мы можем создавать нужную группировку и мнемонику для наших входных величин.
Использовать values мы можем в файлах templates при помощи конструкций вида:
Здесь “.” означает текущую область значений (current scope), далее идет зарезервированное слово Values и путь до ключа. При рендере релиза сюда подставится значение, которое было определено по этому пути.
Но values.yaml — статический способ задания величин. Очевидно, что нам нужно менять некоторые values при деплое в конкретное окружение. В Helm для этого предусмотрено несколько способов:
или несколько директив set:
Передавать несколько значений через запятую в одной директиве set:
Передавать значения в списки:
1.1. Работа со списками
В примере values.yaml выше были описаны списки storageClass и persistentVolumeSize в секции app.storage. Они описывают параметры persistentVolume в зависимости от облака, куда мы производим деплой (aws или gcp). Такие списки очень удобны и встречаются достаточно часто. Есть несколько вариантов использования таких списков. При деплое нам прежде всего нужно определить value, характеризующее конкретный вариант. В примере выше это
Плохой способ использования списка — описать при помощи конструкции if все имеющиеся варианты:
Более правильный способ — использовать функции Go templates:
Функции Go templates, расширенные Sprig framework, позволяют делать код гораздо более красивым, функциональным и компактным. Если вы что-то делаете и чувствуете, что получается не очень-то хорошо, подумайте насчет использования Go templates.
Вот пара полезных ссылок на этот случай:
Говоря о values, нужно упомянуть стандартные значения Helm, которые формируются автоматически при каждом рендере релиза.
Они подробно описаны в документации по этой ссылке.
Если вы используете эти значения в своем коде
то при переносе его между чартами, код подхватит нужные значения и бесшовно, без изменений встроится в новый чарт.
2. Переиспользование кода
Допустим, у нас есть некоторое количество значений:
И эти значения нужны нескольким приложениям в нашем чарте:
Вполне очевидно, что дублировать секцию env: в описании каждого приложения совершенно некрасиво.
Для решения этой проблемы в Helm есть механизм “Named templates”.
Там мы можем определить секцию “define”…
…которую потом сможем подключить к нашим yaml при помощи директивы include:
Здесь мы видим, что в функцию include передается имя define и текущий контекст, потом текст, описанный в define, при помощи pipe передается в функцию indent, которая сдвигает его на 12 пробелов.
Для чего это может быть использовано? Для любых повторяющихся участков кода.
Определение общих labels:
Используйте templates и следуйте базовому правилу программирования “DRY”: DON’T REPEAT YOURSELF!
2.1. Использование циклов (range)
Примеры values.yaml и define, который был сделан для подключения его в yaml приложения, выглядят совсем некрасиво. Приходится описывать значение в values, потом описывать его же в define. Это явное дублирование.
Избавиться от него в Helm можно при помощи range.
Пример 1: range по заданному списку.
Пример 2: range по values.yaml
Допустим, у нас есть некоторое количество cronJob, которые различаются фактически только расписанием и командой запуска. Описываем их как список в values.yaml:
При этом мы делаем include переменных окружения из верхней области значений по аналогии с предыдущим примером (Строка 19).
Range — очень мощное средство шаблонизации, но оно требует повышенного внимания, не проявив его, можно запросто выстрелить себе в ногу.
Скажем, в Примере 2 допущена ошибка, которая приведет к тому, что из всего списка будет создан только последний cronJob. Дело в отсутствии yaml разделителя. Правильный вариант выглядит так (обратите внимание на Строку 2):
Каким же образом при помощи range мы можем улучшить эту конструкцию?
Итоговая конструкция получается гораздо проще и лаконичнее:
2.3. Хорошие практики values.yaml
Гораздо лучше описывать переменные списком в разрезе окружений. Т. о., базовое описание values…
Однако от окружения к окружению менять нужно не все величины, часть из них изначально описана как _default.
Код для разбора таких конструкций будет выглядеть так:
Если значения, соответствующего окружению, не найдено, то при помощи функции default подставляется значение из ключа _default.
Этот способ описания очень любят разработчики, поскольку оно достаточно простое и наглядное.
2.4. Лучшие практики
Если говорить о лучших практиках, в документации Helm есть набор рекомендаций и хаков, которые могут пригодиться при его использовании: Chart best practices, Chart tips and tricks.
Например, из подборки лучших практик вы можете узнать, что создатели Helm топят за использование camelCase. А в tips and tricks я недавно нашел такую штуку:
Здесь же мы делаем аннотацию подов в template, которая рассчитывается на основании хеш-функции от содержимого configmap. Configmap изменился, хеш пересчитался, анотация поменялась, поды перекатились, конфигурация применилась. На мой взгляд, решение очень остроумное.
На этом пункте я решил сделать перерыв, поскольку материал получается очень большим. Впрочем, обещаю не затягивать с выкатом продолжения, в котором речь пойдет о прочих типичных задачах, возникающих в ходе деплоя в Kubernetes: трекинге выката, отладке, управлении релизным циклом и т. д.
13 рекомендаций по использованию Helm
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.
Найдя репозиторий диаграмм, вы можете добавить его в свою локальную настройку следующим образом:
Затем вы можете искать диаграммы, например, MySQL:
2. Использование subcharts для управления своими зависимостями
Поскольку приложения, развернутые в Kubernetes, состоят из детализированных, взаимозависимых частей, их диаграммы Helm имеют различные шаблоны ресурсов и зависимости. Например, предположим, что ваш бэкэнд полагается на базу данных и очередь сообщений. База данных и очередь сообщений уже являются автономными приложениями (например, PostgreSQL и RabbitMQ). Поэтому рекомендуется создавать или использовать отдельные чарты для автономных приложений и добавлять их в родительские чарты. Зависимые приложения названы здесь в виде поддиаграмм.
Есть три основных элемента для создания и настройки subcharts:
Кроме того, в файле chart.yaml родительском чарте должны быть перечислены все зависимости и условия:
Наконец, вы можете установить или переопределить значения вложенных диаграмм в родительской диаграмме с помощью следующего файла values.yaml:
Создание и использование subcharts устанавливает уровень абстракции между родительским и зависимым приложениями. Эти отдельные чарты упрощают развертывание, отладку и обновление приложений в Kubernetes с их отдельными значениями и жизненными циклами обновления. Вы можете просмотреть структуру папок, зависимости и файлы значений в образце диаграммы, например bitnami / wordpress.
3. Использование Labels для простого нахождения ресурсов
Labels имеют решающее значение для внутренних операций Kubernetes и повседневной работы операторов Kubernetes. Почти каждый ресурс в Kubernetes предлагает метки для разных целей, таких как группировка, распределение ресурсов, балансировка нагрузки или планирование.
Одна команда Helm позволит вам установить несколько ресурсов. Но очень важно знать, откуда берутся эти ресурсы. Labels позволяют быстро находить ресурсы, созданные релизами Helm.
Затем вам нужно использовать функцию include с метками в шаблонах ресурсов:
4. Документирование чартов
Документация необходима для обеспечения поддерживаемости диаграмм Helm. Добавление комментариев в шаблоны ресурсов и README помогает командам в разработке и использовании диаграмм Helm.
Вы должны использовать следующие три варианта для документирования ваших диаграмм:
В конце команды helm install или helm upgrade Helm распечатывает содержимое NOTES.txt следующим образом:
5. Проверка чартов
Чарты Helm состоят из нескольких ресурсов, которые должны быть развернуты в кластере. Важно убедиться, что все ресурсы созданы в кластере с правильными значениями. Например, при развертывании базы данных вы должны убедиться, что пароли базы данных установлены правильно.
Предположим, вы развертываете WordPress с базой данных MariaDB. Чарт Helm, поддерживаемый Bitnami, имеет модуль для проверки соединения с базой данных со следующим определением:
Рекомендуется писать тесты для ваших чартов и запускать их после установки. Например, вы можете использовать команду helm test для запуска тестов. Тесты являются ценным активом для проверки и поиска проблем в приложениях, установленных вместе с Helm.
6. Обеспечение безопасности секретов
Конфиденциальные данные, такие как ключи или пароли, хранятся в Kubernetes как секреты. Хотя на стороне Kubernetes можно защитить секреты, они в основном хранятся в виде текстовых файлов как часть шаблонов и значений Helm.
Плагин helm-secrets предлагает секретное управление и защиту вашей важной информации. Он делегирует секретное шифрование Mozilla SOPS, который поддерживает AWS KMS, Cloud KMS на GCP, Azure Key Vault и PGP.
Предположим, вы собрали конфиденциальные данные в файл с именем secrets.yaml следующим образом:
Вы можете зашифровать файл с помощью плагина:
Теперь файл будет обновлен, и все значения будут зашифрованы:
Приведенные выше данные в файле secrets.yaml не были безопасными, а helm-secrets решает проблему хранения конфиденциальных данных как части диаграмм Helm.
7. Создание многоразовой диаграммы с помощью шаблонных функций
Helm поддерживает более 60 функций, которые можно использовать внутри шаблонов. Функции определены на языке шаблонов Go и библиотеке шаблонов Sprig. Функции в файлах шаблонов значительно упрощают работу Helm.
Давайте посмотрим на следующий файл шаблона в качестве примера:
Если значение среды не указано, функция шаблона будет использовать его по умолчанию. Проверив поле региона, вы увидите, что в шаблоне нет значения по умолчанию. Однако у поля есть другая функция, называемая upper, для преобразования предоставленного значения в верхний регистр.
Если запись пуста, рендеринг шаблона завершится ошибкой. Требуется имя. Функции шаблонов очень полезны при создании чартов Helm. Они могут улучшить создание шаблонов, уменьшить дублирование кода и могут использоваться для проверки значений перед развертыванием ваших приложений в Kubernetes.
8. Обновление развертываний (Deployments) при изменении ConfigMaps или секретов.
Обычно к контейнерам монтируются ConfigMaps или секреты. Хотя развертывания и образы контейнеров меняются с новыми выпусками, ConfigMaps или секреты меняются нечасто. Следующая аннотация позволяет развертывать новые развертывания (Deployments) при изменении ConfigMap:
Любое изменение в ConfigMap вычислит новую сумму sha256sum и создаст новые версии развертывания (Deployments). Это гарантирует, что контейнеры в развертываниях (Deployments) будут перезапущены с использованием нового ConfigMap.
9. Отказ от удаления ресурсов с помощью политик ресурсов.
В типичной настройке после установки Helm чартов, Helm создает несколько ресурсов в кластере. Затем вы можете обновить его, изменив значения и добавив или удалив ресурсы. Когда приложение больше не понадобится, его можно удалить, что приведет к удалению всех ресурсов из кластера. Однако некоторые ресурсы следует сохранить в кластере даже после выполнения удаления Helm. Предположим, вы развернули базу данных с PersistentVolumeClaim и хотите сохранить тома, даже если вы удаляете выпуск базы данных. Для таких ресурсов вам необходимо использовать аннотации политики ресурсов следующим образом:
Команды Helm, такие как удаление, обновление или откат, приведут к удалению указанного выше секрета. Но, используя политику ресурсов, как показано, Helm пропустит удаление секрета и позволит его осиротить. Поэтому аннотацию следует использовать с большой осторожностью и только для ресурсов, необходимых после удаления релизов Helm.
10. Полезные команды для отладки Helm-чартов.
Файлы шаблонов Helm содержат множество различных функций и несколько источников значений для создания ресурсов Kubernetes. Важная обязанность пользователя — знать, что развернуто в кластере. Следовательно, вам нужно научиться отлаживать шаблоны и проверять чарты. Для отладки можно использовать четыре основные команды:
11. Использование функций поиска, чтобы избежать регенерации секрета.
Функции Helm используются для генерации случайных данных, таких как пароли, ключи и сертификаты. Случайная генерация создает новые произвольные значения и обновляет ресурсы в кластере при каждом развертывании и обновлении. Например, он может заменять пароль вашей базы данных в кластере при каждом обновлении версии. Это приводит к тому, что клиенты не могут подключиться к базе данных после смены пароля.
Чтобы решить эту проблему, рекомендуется случайным образом генерировать значения и заменять те, которые уже находятся в кластере. Например:
12. Переход на Helm 3 для более простых и безопасных приложений Kubernetes.
Последний выпуск Helm — Helm 3, предлагает множество новых функций, которые делают его более легким и оптимизированным инструментом. Helm v3 рекомендуется из-за его повышенной безопасности и простоты. Это включает в себя:
Это небольшой, но полезный плагин с командами очистки, преобразования и перемещения, которые помогут вам перенести и очистить конфигурацию v2 и создать выпуски для v3.
13. Поддерживание идемпотентности ваших конвейеров непрерывной доставки
Ресурсы Kubernetes декларативны в том смысле, что их спецификация и статус хранятся в кластере. Точно так же Helm требуется для создания декларативных шаблонов и выпусков (release). Следовательно, вам необходимо разработать систему управления непрерывной доставкой и выпуском, которая будет идемпотентной при использовании Helm. Идемпотентная операция — это операция, которую можно применять много раз, не изменяя результат после первого запуска.
Необходимо соблюдать два основных правила:
Резюме
Helm — незаменимый инструмент для развертывания приложений в кластерах Kubernetes. Но только следуя передовому опыту, вы действительно ощутите преимущества Helm.
Лучшие практики, описанные в этой статье, помогут вашим командам создавать, использовать и обновлять распределенные приложения производственного уровня. Что касается разработки, ваши диаграммы Helm будет проще поддерживать и защищать. Что касается эксплуатации, вы получите удовольствие от автоматически обновляемых развертываний, сэкономите ресурсы от удаления и научитесь тестировать и отлаживать.
Официальное руководство по темам Helm — еще один хороший ресурс для проверки команд Helm и понимания их философии дизайна. С этими ресурсами, а также с лучшими практиками и примерами, изложенными в этом блоге, вы наверняка будете вооружены и готовы создавать и управлять приложениями Helm производственного уровня, работающими в Kubernetes.
Коллеги, пишите, если что-то переведено неправильно.