Введение

Цель этой серии статей — представить особенности и объяснить функциональность универсальной библиотеки Helm Universal Layer Library — сокращенно HULL. Это схема библиотеки Helm, которая может помочь в эффективном создании и управлении приложениями в Kubernetes. Проект HULL имеет открытый исходный код, и вы можете найти его на GitHub:

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

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

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

Проектирование диаграмм с помощью Helm

Объекты Kubernetes обычно определяются как файлы YAML, и передача этих YAML-файлов в Kubernetes API (например, с помощью команд kubectl) создает их как объекты в кластере Kubernetes. Приложение обычно состоит из нескольких объектов, таких как Deployments, ConfigMaps, Ingresses и так далее. Helm ожидает, что все YAML-файлы, необходимые для развертывания, будут созданы в папке /templates развертываемого графика Helm.

Построение диаграммы Helm теперь начинается с определения того, какие объекты Kubernetes должны быть созданы и какие средства для их адаптации должны быть предоставлены, чтобы иметь возможность запускать ваше приложение в различных условиях. Диаграммы Helm должны быть развертываемыми в различных средах, таких как разработка, staging или production, где различные конечные точки, учетные данные, размеры ресурсов и т.д. должны быть настраиваемыми. Или просто подумайте об облачных и локальных системах, где действуют разные правила в плане сетевого взаимодействия, балансировки нагрузки и масштабирования. Все эти аспекты должны быть настраиваемыми в диаграмме Helm вашего приложения, если ваше приложение предназначено для широкого использования.

В обычном Helm технически все объекты, которые могут быть созданы по определенному сценарию, должны быть собраны в папке /templates в виде файлов Kubernetes YAML. Чтобы точно контролировать логику того, какие файлы должны быть развернуты и какие значения должны быть изменены в конкретной системе, Helm интегрирует язык шаблонов (в данном случае шаблоны Go). Используя шаблонирующие выражения в YAML-файлах Kubernetes, становится возможным влиять на логику шаблонирования и создавать корректные YAML-файлы Kubernetes для конкретного сценария (учитывая, что сценарий был учтен при разработке диаграммы).

Внешним источником для управления логикой шаблонизации на первом этапе является так называемый файл values.yaml, который содержится в каждом графике Helm. В действительности он служит нескольким целям:

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

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

Для наглядности рассмотрим несколько примеров отображения фиктивной диаграммы Helm с одним развертыванием и конфигурационной картой в папке /templates:

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

• чем больше объектов требуется моему приложению, тем больше файлов шаблонов необходимо создать
• с каждым файлом шаблона необходимо создать значительное количество кодовой структуры YAML
• чем больше аспектов объектов, которые требуют контроля, тем больше сопоставлений необходимо определить вручную
• нет фиксированной связи именования между исходными значениями в values.yaml и целевыми значениями в шаблонах.

Хороший

Гибкость

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

• несколькими объектами с одним значением конфигурации (1:n)
• одиночные объекты с комбинацией нескольких значений конфигурации (n:1)
• множественные объекты с комбинацией нескольких значений конфигурации (n:n).

В принципе, все возможно, но должно быть явно реализовано путем написания логики шаблонирования — даже самые простые проекции 1:1. Каждый график Helm имеет в этом смысле свой собственный индивидуальный API, который может быть адаптирован к использованию приложения.

Плохой

Реализация

В то время как гибкость отображения Helm проявляется, когда требуются сложные конфигурации приложения, с другой стороны, она не может работать без существования явных отображений. Учитывая, что в обычной диаграмме Helm обычно значительное количество реализованных отображений — это простые отображения 1:1 между свойствами values.yaml и отдельными полями объекта, не требующие никакой дополнительной логики, подход Helm mapping добавляет заметные накладные расходы на написание диаграммы. Для каждого отображения или проекции необходимо создать файлы шаблонов для объектов, правильно вставить логику шаблонирования и обновить values.yaml, чтобы указать отображаемое свойство и документировать логику, лежащую в основе.

Обслуживание

Как видно, при разработке и поддержке диаграммы Helm таким способом требуется значительное количество ручного ухода. Рассмотрим реальную диаграмму Helm, имеющую десятки объектов с сотнями строк YAML, где многие отображаемые значения в шаблонах могут нуждаться в настройке. Более того, часто настраиваемые параметры объектов изначально не учитываются, потому что они либо не так важны для создателя диаграммы, как другие, либо из лени. Если кому-то нужно настроить такую опцию для своего сценария развертывания, диаграмма должна быть адаптирована путем подачи запроса на исправление, локального форка или любым другим подобным способом.

Непрозрачность

С точки зрения человека, хорошо знакомого с Kubernetes, часто бывает излишне непонятно, как добиться желаемой конфигурации объектов Kubernetes без изучения связок между values.yaml и шаблонами. В этом смысле каждая диаграмма Helm имеет свой собственный уникальный API, который требует анализа, чтобы понять, как изменения конфигурации в values.yaml влияют на шаблоны. Документация этого интерфейса, комментарии values.yaml, часто не объясняет, как установка конкретного свойства влияет на генерируемые шаблоны. Между тем, были установлены определенные соглашения, которые можно найти в нескольких графиках, но нет гарантии, что идентично названное свойство в values.yaml будет иметь одинаковый эффект в разных графиках.

В чем разница при использовании HULL?

Библиотека HULL библиотеки Helm chart предоставляет единый общий интерфейс для указания объектов Kubernetes в Helm Charts. Сам интерфейс основан на схеме API Kubernetes, которая интегрирована в диаграмму HULL в виде схемы JSON. Поскольку все объекты определяются непосредственно в values.yaml под ключом hull, нет необходимости создавать и поддерживать пользовательские файлы шаблонов при создании объектов с помощью HULL, все происходит в values.yaml.

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

Возможность напрямую манипулировать свойствами любого объекта выгодна тем, что избавляет от необходимости реализации явных отображений, но одного этого недостаточно для моделирования более сложных аспектов, таких как упомянутые отображения 1:n, n:1 или n:n. Для решения этой проблемы в HULL встроен уникальный механизм под названием HULL transformations, позволяющий интегрировать выражения Go Templating в сам values.yaml без нарушения ограничения, что файл values.yaml должен быть корректным YAML.

Это означает, что вам доступен практически тот же набор инструментов, что и при обычном рабочем процессе Helm chart, но вы можете ограничиться моделированием конфигурационных отношений только там, где это полезно или необходимо. Нет необходимости моделировать все открытые свойства объектов в явном виде, что приводит к значительному сокращению объема кода, который необходимо поддерживать в диаграмме Helm. В зависимости от структуры приложения при построении диаграммы Helm с помощью HULL можно сэкономить более 50% от общего количества строк кода конфигурации.

Так почему же вы должны выбрать использование HULL?

Сильными сторонами подхода, основанного на HULL, являются:

• меньше работы при создании или обслуживании большого количества диаграмм Helm, поскольку диаграммы на основе HULL сводят к минимуму «нагромождение» файлов шаблонов. Явное моделирование только того, что вы действительно хотите или должны моделировать, экономит время и усилия при создании диаграмм.

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

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

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

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

Подведение итогов

Спасибо, что прочитали и надеемся, что это вызвало у вас интерес. Если вы хотите, пожалуйста, перейдите к учебнику по построению диаграмм с помощью HULL, где популярная диаграмма kubernetes-dashboard Helm будет «переосмыслена» с помощью HULL, чтобы продемонстрировать ее применимость в реальных случаях использования!