hull
hull-demo-1.31.2
Этот репозиторий содержит диаграмму библиотеки Hull Helm. Он предназначен для облегчения построения, поддержания и настройки объектов Kubernetes в диаграммах Helm и может быть добавлен в любую диаграмму Helm в качестве аддона для повышения функциональности без какого -либо риска разрыва существующих конфигураций диаграммы Helm.
Сама диаграмма и вся документация, связанная с ней, можно найти в папке hull , которая является корневой папкой диаграммы шляпа библиотеки корпуса.
Схемы Kubernetes API JSON хранятся в папке kubernetes-json-schema .
Ниже приведена диаграммы Hull README.md :
Необходимо поддерживать абстракции - Келси Хайтауэр
Одним из основных дизайнерских аспектов управления является то, что он заставляет пользователя создавать отдельные абстракции конфигурации приложений Kubernetes. Для каждой отдельной диаграммы руля, которая реализована в форме шаблонов YAML в папке Helm Hards /templates . Эти шаблонные файлы, содержащие кодовые блоки Coberplate Kubernetes YAML, с одной стороны, и пользовательские сопоставления конфигурации с использованием выражений шаблонов GO, с другой стороны, предоставьте клей между конфигурацией приложения через центральные values.yaml Полем Возможно, этот подход абстракции с приложением хорошо подходит для создания пакетов конфигурации хвормейных конфигурации даже для самых специализированных приложений, но стоит за счет наличия больших накладных расходов для более простых, повторяющихся и готовых приложений. Создание, поддержание и (часто) понимание абстракций, представленных диаграммами Helm - особенно при столкновении с большим количеством отдельных диаграмм руководителей из различных источников - может стать утомительным и сложным.
Основной особенностью библиотеки корпуса является возможность удалить индивидуальные файлы шаблонов YAML полностью из рабочих процессов диаграммы Helm и, таким образом, позволяя удалить уровень абстракции. Используя диаграмму библиотеки корпуса, объекты Kubernetes, включая все их свойства, могут быть полностью и прозрачно указаны в values.yaml . Сама диаграмма библиотеки корпуса обеспечивает единый слой для оптимизации спецификации, конфигурации и рендеринга диаграмм Helm для достижения этого. Вы также можете думать об этом как о тонком слое поверх API Kubernetes, чтобы избежать среднего уровня между конфигурацией Helm и конфигурации объекта API Kubernetes, но обеспечивая гибкость, когда требуется настройка отдельных параметров конфигурации вместо того, чтобы добавить каждый переключатель конфигурации вручную к шаблонам. Валидация схемы JSON на основе функции проверки json json (через values.schema.json ) помогает в написании API Kubernetes, соответствующие объектам с самого начала при использовании IDE, который поддерживает проверку схемы Live JSON. Дополнительные преимущества (однородные наследуемые метаданные объекта, упрощенное включение конфигураций/секретов, значения перекрестных ссылок в values.yaml . Но, возможно, самое главное, библиотека корпуса может быть добавлена в качестве зависимости от любой существующей диаграммы Helm и использоваться бок о бок без лома существующих функций Helm Charts, см. Добавление диаграммы библиотеки корпуса в диаграмму Helm для получения дополнительной информации. И, наконец, будучи самой библиотечной диаграммой, все работает на 100% в рамках функциональности, которую предлагает простой руль - никаких дополнительных инструментов не введено и не задействовано.
Ваш отзыв о этом проекте ценится, поэтому, пожалуйста, прокомментируйте или начните обсуждение в разделе Issues или создайте пожелания функций и отчеты об ошибках. Спасибо!
Идея диаграммы библиотеки корпуса частично вдохновлена концепцией общей диаграммы Helm и для тестирования
Полем
hull-demo Прежде чем погрузиться в детали корпуса, вот первый взгляд на то, как он работает. Вы можете просто загрузить последнюю версию диаграммы hull-demo Helm из раздела релизов этой страницы, у нее есть все, что загружено для тестирования корпуса или настройки новой диаграммы Helm на основе корпуса с минимальными усилиями.
Диаграмма hull-demo охватывает вымышленное приложение myapp с парой развертывания и сервисного backend frontend Существует файл конфигурации для конфигурации сервера, который установлен на backend -стручках. frontend стручки должны знать об backend адресе сервиса через переменные среды. Более того, настройка должна быть легко переключена с настройки debug (используя Nodeport для доступа к фронте) на производственную настройку (с использованием сервиса кластера и входа).
Голая структура по умолчанию, чтобы захватить эти аспекты, может выглядеть так (с добавленными комментариями к объяснению):
hull : # HULL is configured via subchart key 'hull'
config : # chart setup takes place here for everything besides object definitions
specific : # central place for shared values specific to this chart
debug : true # a switch influencing creation of objects in this chart
application_version : v23.1 # a shared image tag for multiple container
myapp : # some exemplary configuration settings for the app, exposed here for transparency
rate_limit : 100
max_connections : 5
objects : # all objects to create are defined here
deployment : # create deployments
myapp-frontend : # the base part of the object name for frontend deployment
pod : # configure pod-related aspects
containers : # non-init containers
main : # one main container
image : # provide image reference
repository : mycompany/myapp-frontend # repository
tag : _HT*hull.config.specific.application_version # reference to central tag value above
ports : # exposed ports
http : # port name is http
containerPort : 80 # the port number
env : # environment variables
SERVER_HOSTNAME : # name of variable
value : _HT^myapp-backend # value is dynamically rendered reference to myapp-backend service name
SERVER_PORT : # name of variable
value : " 8080 " # backend service port
myapp-backend : # the base part of the object name for backend deployment
pod : # configure pod-related aspects
containers : # non-init containers
main : # one main container
image : # image reference
repository : mycompany/myapp-backend # repository
tag : _HT*hull.config.specific.application_version # reference to central tag value above
ports : # exposed ports
http : # port name is http
containerPort : 8080 # the port number
volumeMounts : # mounts of the container
appconfig : # context key is appconfig
name : myappconfig # the name needs to match a volume
mountPath : /etc/config/appconfig.json # mountPath
subPath : backend-appconfig.json # subPath
volumes : # volumes that may be mounted
myappconfig : # key matching a volumeMounts name
configMap : # configmap reference
name : myappconfig # the configmap to load, simply referenced by key name
configmap : # create configmaps
myappconfig : # the backend configuration
data : # data section
backend-appconfig.json : # key name is file name
serialization : toPrettyJson # serialize the dictionary content of inline to pretty Json
inline : # define the contents of the file as a dictionary for convenience
rate-limit : _HT*hull.config.specific.myapp.rate_limit
max-connections : _HT*hull.config.specific.myapp.max_connections
debug-log : _HT!{{ if _HT*hull.config.specific.debug }}true{{ else }}false{{ end }}
service : # create services
myapp-frontend : # frontend service, automatically matches pods with identical parent object's key name
ports : # definition of service ports
http : # http port for type=ClusterIP
enabled : _HT?not _HT*hull.config.specific.debug # bind rendering to debug: false condition, use embedded transformation to reference field
port : 80 # regular port
targetPort : http # targetPort setting
http_nodeport : # http port for type=NodePort
enabled : _HT?_HT*hull.config.specific.debug # bind rendering to debug: true condition
port : 80 # regular port
nodePort : 31111 # the node port
targetPort : http # targetPort setting
type : |- # dynamically switch type based on hull.config.specific.debug setting
_HT!
{{- if _HT*hull.config.specific.debug -}}
NodePort
{{- else -}}
ClusterIP
{{- end -}}
myapp-backend : # backend service, automatically matches pods with identical parent object's key name
ports : # definition of service ports
http : # http port
port : 8080 # regular port
targetPort : http # targetPort setting
type : ClusterIP # in cluster service
ingress : # create ingresses
myapp : # the central frontend ingress
enabled : _HT?not _HT*hull.config.specific.debug # rendering bound to debug: false
rules : # the ingress rules
myapp : # key-value dictionary of rules
host : SET_HOSTNAME_HERE # change the host at deployment time to actual one
http : # http settings
paths : # paths definition
standard : # a standard path definition
path : / # could be changed at deployment time
pathType : ImplementationSpecific # path type
backend : # backend config
service : # service targeted
name : myapp-frontend # key name suffices to reference service created in this chart
port : # target port
name : http # target port name Это пример, составляющий как values.yaml hull-demo hull-demo
helm template hull-demo-<version>.tgz
он отдает набор объектов на основе вышеуказанных values.yaml Ямл, содержащий:
myapp-frontend , которое имеет набор tag изображения в центре (по умолчанию v23.1 ), а также переменные среды, указывающие на сервис myapp-backend в кластере.myapp-backend , которое имеет набор tag изображения, настроенный в центре (по умолчанию v23.1 ) и конфигурация, установленная из myappconfig ConfigMapmyappconfig ConfigMap с файлом JSON, который динамически создан путем включения выражений шаблонов и ссылок, определяемых в других местах в values.yamlmyapp-backenddebug myapp на ClusterIP myapp-frontend debug NodePortmyapp , который отображается/создается только в случае, если debug: false значение установлено Каждый аспект этой конфигурации может быть изменен или перезаписан во время развертывания с использованием дополнительных values.yaml Например: yaml:
debug и до отладки. Настройки debug: true или debug: falserate_limit исходных max_connections myapp Configmap Все объекты и логика были созданы с сотнями строк общего кода конфигурации в values.yaml hull-demo . Вы можете проверить все вышеперечисленные аспекты или helm template экспериментировать, добавив дополнительные values.yaml Для начальной загрузки name собственной диаграммы Helm просто опустошите конфигурацию values.yaml Chart.yaml
Это первая демонстрация того, как можно использовать корпус, но есть гораздо больше функциональности и поддерживаемых случаев использования. Проверьте ключевые функции и подробную документацию для получения дополнительной информации.
Как отмечено выше, при включении в диаграмму рулевой диаграммы, диаграмма библиотеки корпуса может взять на себя задачу динамического визуализации объектов Kubernetes из их заданных спецификаций из файла values.yaml . С помощью конструкции объекта YAML, отложенной на функции шаблона библиотеки корпуса вместо пользовательских шаблонов YAML в папке /templates вы можете применять лучшие практики.
Сконцентрируйтесь на том, что необходимо, чтобы указать объекты Kubernetes, не добавляя отдельные шаблоны yaml в вашей диаграмме. Это удаляет общий источник ошибок и технического обслуживания из обычного рабочего процесса управления. Для того, чтобы оборудованный вывод, соответствовал спецификации API Kubernetes, большое количество модульных тестов подтверждает, что корпус визуализируется на выходе против схемы API JSON Kubernetes.
Для получения более подробной информации см. Документацию по проверке схемы JSON.
Для всех типов объектов Kubernetes, поддерживаемых Hull, полный конфигурационный доступ к свойствам типов объектов Kubernetes доступен непосредственно . Это освобождает содействий диаграммам от необходимости добавлять отсутствующие параметры конфигурации один за другим, а пользователи Helm диаграммы - разбрызгивание диаграммы Helm, чтобы добавить только те свойства, которые им нужны для их конфигурации. Требуется только обновление диаграммы корпуса для более новой версии с соответствующей версией API Kubernetes, чтобы включить конфигурацию свойств, добавленных в объекты Kubernetes, тем временем в новых версиях API. Диаграммы корпуса версии, чтобы отразить минимальные версии API Kubernetes, поддерживаемые ими.
Для получения более подробной информации см. Документацию по обзору архитектуры.
Единый интерфейс библиотеки корпуса используется как для создания, так и настройки объектов в диаграммах для развертывания. Это способствует взаимному пониманию создателей/содействий диаграмм и потребителей того, как на самом деле работает диаграмма и что он содержит. Копание в папке /templates , чтобы понять, что последствия для диаграмм руля больше не требуются. Чтобы избежать какой -либо неправильной конфигурации, интерфейс к библиотеке - values.yaml . При использовании IDE, поддерживающей валидацию схемы Live JSON (например, VSCODE), вы можете получить руководство IDE при создании объектов корпуса. Перед рендерингом соответствие схемы JSON подтверждается библиотекой Халла.
Для получения более подробной информации см. Документацию по проверке схемы JSON.
Разнообразные и богатые метаданные автоматически прикрепляются ко всем объектам, созданным библиотекой корпуса.
Для получения более подробной информации о перезаписании метаданных см. В приведенном ниже примере.
Гибкая обработка конфигурации и секретного ввода путем выбора между встроенной спецификацией содержания в values.yaml YAML или импорт из внешних файлов для содержимого больших размеров. При импорте данных из файлов данные могут быть либо запускаться через шаблон, либо импортированный неэлемент », как это« если они уже содержат выражения шаблона, которые должны передаваться поглощающему приложению. С акцентом на удобную обработку стандартных сценариев вы также можете определить содержимое файла как обычную структуру YAML в values.yaml . Халл заботится о кодировании Secrets Base64, поэтому написание конфигураций и секретов работает точно так же, а добавление ConfigMaps или Secrets в ваше развертывание требует лишь нескольких строк кода.
Для получения более подробной информации см. Документацию по конфигурации и секретам.
Обширные возможности дефолта для создания экземпляров объектов. Независимо от того, хотите ли вы иметь все экземпляры объекта или группы экземпляров, которые делятся определенными аспектами, такими как метки или аннотации, переменные контейнера или установленные объемы, Hull обеспечивает поддержку для эффективного определения значений по умолчанию для поля экземпляра объекта, избегая ненужных повторений конфигурации.
Для получения более подробной информации см. Дизайн диаграммы.
Для более сложных сценариев, в которых фактические значения в целевом YAML подлежат конфигурациям в values.yaml YAML, существует поддержка динамически заполненных значений путем инъекции выражений шаблона GO, определенных вместо значения в значениях. values.yaml . Например, если ваши конкретные контейнерные аргументы зависят от различных других настроек в values.yaml YAML вы можете ввести условия в расчет аргументов или просто ссылаться на другие поля в values.yaml .
Для получения более подробной информации см. Документацию по преобразованию.
Включите автоматическое хэширование ссылочных конфигураций и секретов, чтобы облегчить перезагрузку POD при изменениях конфигурации при необходимости.
Для получения более подробной информации см. Документацию по стручкам.
Чтобы узнать больше об общей архитектуре и особенностях библиотеки Халла, см. Обзор архитектуры
Некоторые важные вещи, которые нужно упомянуть в первую очередь, прежде чем посмотреть на библиотеку более подробно:
/templates , полностью не зависит от интеграции диаграммы библиотеки корпуса. Иногда у вас могут быть очень конкретные требования к вашей конфигурации или спецификации объектов, которые библиотека корпуса не соответствует, чтобы вы могли использовать для них обычный рабочий процесс руля и библиотеку корпуса для ваших более стандартных потребностей - легко параллельно в той же диаграмме руля.
hull.yaml , должен быть скопирован «As-IS» без каких-либо модификации из корневой папки встроенных диаграмм в папку родительских диаграмм /templates , чтобы иметь возможность рендерировать любую YAML через корпус. Он содержит код, который инициирует трубопровод рендеринга корпуса, см. Добавление диаграммы библиотеки корпуса в диаграмму руля для более подробной информации!
3.0.x не совместимы с корпусом, все другие существующие в настоящее время не бета и не альфа-версии совместимы.
1.29 и 1.30 и 1.31 имеют соответствующий и поддерживаемый выпуск корпуса.
Если вам нравится подход, вас приглашают взглянуть на новую серию учебных пособий в Dev.to! Учебное пособие по части Eigth начнется с самого начала настройки руля и создания таблицы на основе корпуса для окончания реальной диаграммы Hull Hull Hull шаг за шагом. Чтобы подчеркнуть различия в обычном рабочем процессе диаграммы Helm, учебные пособия принимают популярную диаграмму Helm kubernetes-dashboard в качестве источника и переносят его в функционально эквивалентный диаграмму шляпа на основе корпуса. В конце концов, это показывает, что сокращение линий конфигурации для создания и поддержания может быть уменьшено более чем на 50% при использовании подхода на основе корпуса вместо обычного стиля управления написания!
Задачи создания и настройки хлевовой диаграммы на основе корпуса можно рассматривать как две стороны одной монеты. Обе стороны взаимодействуют с одним и тем же интерфейсом (библиотека корпуса), чтобы указать объекты, которые должны быть созданы. Задача с точки зрения создателей/сопровождающих, прежде всего, чтобы обеспечить структуру земли для объектов, которые составляют конкретное применение, которое должно быть обернуто в диаграмму руля. Потребительнице диаграммы поручено надлежащим образом добавить свой системный контекст в структуру основной структуры, где он имеет свободу изменения и даже добавлять или удалять объекты по мере необходимости для достижения своих целей. Во время развертывания базовая структура создателей объединяется с системой системного файла потребителей для создания полной конфигурации. Взаимодействие с помощью одного и того же библиотечного интерфейса способствует общему пониманию того, как работать с библиотекой с обеих сторон и может устранить большинство утомительных процессов создания и вставки копии и вставки.
Таким образом, все, что необходимо для создания диаграммы Helm на основе корпуса, - это стандартная структура каталогов Helm Helm. Добавьте диаграмму библиотеки корпуса в качестве подпозиции, скопируйте hull.yaml из диаграммы библиотеки корпуса в папку /templates Hull Hull. Затем просто настройте объекты по умолчанию для развертывания через values.yaml , и вы закончите. Нет ограничений относительно того, сколько объектов, из какого типа вы создаете для своего пакета развертывания.
Но помимо того, что позволить определять более сложные приложения с помощью корпуса, вы также можете использовать его для обертывания простых объектов Kubernetes, которые вы бы в противном случае были бы развертываны через kubectl (выходящее из линии с точки зрения управления с выпусками руля), либо должны написать значительное количество Шаблоны шлепов для достижения этого.
Основная структура values.yaml , понятая Халлом, приведена здесь в следующем разделе. Это по существу формирует единственный интерфейс для производства и потребления диаграмм на основе корпуса. Любой объект создается только в случае, если он определяется и включен в values.yaml .
На верхнем уровне структуры YAML корпус различает config и objects . В то время как суб-конфигурация config предназначена для работы с настройками, специфичными для таблицы, такими как метаданные и настройки продукта, подводные объекты Concrete Kubernetes определены в ключе objects . Дополнительный ключ третьего уровня верхнего уровня также разрешен, когда она устанавливается на version диаграмм Hull, например, во время конвейера выпуска Parent Helm, она автоматически заполняет этикетку vidispine.hull/version на все объекты, указывающие версию корпуса Это использовалось для визуализации объектов.
config В разделе config вы можете настроить общие настройки для вашей диаграммы Helm. Он делится на два подраздела, config.general и config.specific .
config.general раздел В отличие от раздела config.specific , который должен быть заполнен произвольным данным, которые являются специфическими только для одной диаграммы руля, config.general определения всего, что не является уникальным применением. С одной стороны, он содержит параметры конфигурации, которые имеют отношение к всем диаграммам на основе корпуса, но также оставляют место под настройкой config.general.data для определения ваших собственных полей данных, которые в идеале смоделированы одинаково в других диаграммах Helm. Например, если несколько приложений в наборе продуктов зависят от одних и тех же конечных точек, вы можете моделировать эти конечные точки равномерно под свойством general.data во всех соответствующих диаграммах и, таким образом, иметь интерфейс ваших карт рулевых диаграмм одинаково с помощью непрерывного трубопровода развертывания.
config.general имеет только следующие подполя:
nameOverride
fullnameOverride
namespaceOverride
noObjectNamePrefixes
createImagePullSecretsFromRegistries
globalImageRegistryServer
globalImageRegistryToFirstRegistrySecretServer
debug
rbac
data
serialization
postRender
errorChecks
metadata
| Параметр | Описание | По умолчанию | Пример |
|---|---|---|---|
nameOverride | Переопределение имени применяется к значениям метаданной метки app.kubernetes.io/name . Если установить это эффективно заменяет имя диаграммы здесь. | ||
fullnameOverride | Если установить значение, переопределение FullName применяется в качестве префикса ко всем именам объектов и заменяет стандартный рисунок <release>-<chart> префикс в именах объектов. | myapp | |
namespaceOverride | Если установлено значение, пространство имен всех созданных объектов устанавливается на это значение. Если это не определено, пространство имен всех экземпляров объекта по умолчанию в пространство имен выпуска, предоставленное соответствующей команде Helm. | my-namespace | |
noObjectNamePrefixes | Если установлено, клавиши экземпляра объекта непосредственно служат именами для созданных объектов Kubernetes и никогда не префиксируются. Это технически эквивалентно установке staticName True на каждом объекте. Обратите внимание, что, установив это на true значение config.general.fullnameOverride становится неактуальным. | false | true |
createImagePullSecretsFromRegistries | Если это правда, секреты обращения изображений создаются из всех реестров, определенных на этой диаграмме Helm, и добавляются ко всем стручкам. | true | false |
globalImageRegistryServer | Если не опустошить поле registry всех полей image контейнеров, установлено значение, указанному здесь. Настройка config.general.globalImageRegistryToFirstRegistrySecretServer игнорируется, если это поле не является пустым. Все определенные явные настройки registry для image перезаписаны этим значением.Предполагаемое использование этого-удобно иметь все изображения, вытащенные из центрального реестра докеров в случае сценариев развертывания, таких как развертывание. Вопреки установке globalImageRegistryToFirstRegistrySecretServer true , в данном случае секрет реестра обычно определяется за пределами этой диаграммы Helm, а на сервере Secort Secret ссылается его имя напрямую. Если вы используете эту функцию и определяете секрет Docker Registry Secret за пределами этой диаграммы Helm, вам может потребоваться добавить imagePullSecrets в ваши стручки в случае, если реестр Docker, приведенный в соответствие, не является небезопасным. | "" | mycompany.docker-registry.io |
globalImageRegistryToFirstRegistrySecretServer | Если True и globalImageRegistryServer пуст, поле registry всех полей image контейнеров устанавливается в поле server первого найденного объекта registry . Обратите внимание, что это реестр с самым низким буквенно -цифровым ключевым именем, если вы предоставляете несколько registry . Обычно следует использовать вместе с установкой createImagePullSecretsFromRegistries от true чтобы получить выгоду от автопапулированных imagePullSecrets и, соответственно, установить registry . Явные настройки registry для image перезаписываются этим значением.Предполагаемое использование этой обстановки-удобно иметь все изображения, вытянутые из центрального реестра докеров в случае сценариев развертывания, таких как развертывание. | false | true |
errorChecks | Параметры, которые определяют, в каких случаях корпус будет генерировать ошибку при helm install или helm template . Для получения более подробной информации см. Также подробную документацию по настройке проверки ошибокИмеет только следующие суб-поля: objectYamlValidhullGetTransformationReferenceValidcontainerImageValidvirtualFolderDataPathExistsvirtualFolderDataInlineValid | ||
errorChecks.objectYamlValid | Убедитесь, что не разбитый ямл не отображается | true | |
errorChecks.hullGetTransformationReferenceValid | Убедитесь, что все ссылки _HT* указывают на существующий ключ в values.yaml | true | |
errorChecks.containerImageValid | Убедитесь, что существуют все containers и pod и initContainers image есть, по крайней мере, набор repository | true | |
errorChecks.virtualFolderDataPathExists | Убедитесь, что все файлы, упоминаемые в конфигурации и полете Data data path | true | |
errorChecks.virtualFolderDataInlineValid | Убедитесь, что null значения или отсутствующие значения (которые преобразуются в пустые строки) не установлены для inline полей data ConfigMap и Secret Data | false | |
debug | Варианты, которые могут помочь в отладке задач диаграммы. В основном устаревшие и заменены сообщениями об ошибках по умолчанию, настроенным в errorChecks .Имеет только следующие суб-поля: renderBrokenHullGetTransformationReferencesrenderNilWhenInlineIsNilrenderPathMissingWhenPathIsNonExistent | ||
debug.renderBrokenHullGetTransformationReferences | Глобальный переключатель, который, если включен, будет распечатать строку:HULL failed with error BROKEN-HULL-GET-TRANSFORMATION-REFERENCE: Element <y> in path <xyz> was not foundВключая _HT*/hull.util.transformation.get ссылка ( xyz ) и отсутствующий ключ ( y ), если преобразование ссылается на отсутствие существующего словарного ключа. Это полезно для отладки рендеринга диаграммы и снижения поиска сломанных ссылок, потому что обычно установка прерывается с ошибкой по разбитым ссылкам (что может затруднить точку зрения задачи проблемной ссылки).ПРИМЕЧАНИЕ: К настоящему времени по умолчанию любая нарушенная ссылка GET будет сигнализироваться по ошибке выступления руля, поэтому этот переключатель в основном устарел для отладки нарушенных ссылок. Он рекомендуется отключить эту опцию и не сбой в сломанных ссылках и анализирует проблемы непосредственно из сообщения об ошибке. | false | true |
debug.renderNilWhenInlineIsNil | Глобальный переключатель, который, если включен, будет распечатать строку:<nil>В качестве значения поля data , когда inline спецификация ссылается на указатель nil в конфигурации или секрете. Если установлено значение FALSE, значение nil будет напечатано как пустая строка в поле ConfigMap или секретном data .ПРИМЕЧАНИЕ: К настоящему времени по умолчанию по умолчанию по умолчанию по умолчанию по умолчанию по умолчанию по умолчанию по true сигнализируют ошибку говорящего по hull.config.general.errorChecks.virtualFolderDataInlineValid . Включение этого переключателя в основном устаревает для отладки, и он рекомендуется отключить эту опцию и сбой в неверных встроенных полях. | false | true |
debug.renderPathMissingWhenPathIsNonExistent | Глобальный переключатель, который, если включен, будет распечатать строку:<path missing: the_missing_path>В значении поля данных ConfigMap или секретного значения data , включая значение the_missing_path , которое не разрешается для файла. Если false, значение поля data разрешит пустую строку.ПРИМЕЧАНИЕ: К настоящему времени любой несуществующий файл, упомянутый в поле пути, по умолчанию будет сигнализировать об ошибке выступающего руля (то есть hull.config.general.errorChecks.virtualFolderDataPathExists -это true ). Включение этого переключателя в основном устаревает для отладки, и он рекомендуется отключить эту опцию и усердно сбое при несуществующих ссылках на путь файла. | false | true |
render | Варианты, чтобы влиять на то, как Халл выдает объекты как YAML. Имеет только следующие суб-поля: emptyAnnotationsemptyLabelsemptyHullObjects | ||
render.emptyAnnotations | Если true , Hull отображает annotations: {} если аннотации не существует для объекта, если false ключ annotations опущена. | false | true |
render.emptyLabels | Если true , Hull отображает labels: {} если для объекта не существует метки, если false клавиша labels опущен. | false | true |
render.emptyTemplateAnnotations | Если true , Hull отображает annotations: {} в template POD, если аннотации не существует для объекта, если false annotations Key опущен. | false | true |
render.emptyTemplateLabels | Если true , Hull отображает labels: {} в template стручков if no labels exist for an object, if ключ the , ключ метки. | false | true |
render.emptyHullObjects | Если true , Халл отображает массивы в виде пустых массивов, если для некоторых полей нет элементов, обрабатываемых Халлом. Если неверно, пара ключевых значений-это коммерческая.Это влияет на поля, которые отображаются из словаря в конфигурации корпуса в массив Kubernetes в визуализированной YAML. Ниже приведен список затронутых полей в конфигурации объекта Халла:
| false | true |
postRender | После того, как корпус полностью сделан объектом, можно манипулировать полученной строкой YAML. Возможности для этого предоставляются в качестве postRender действий здесь.ПРЕДУПРЕЖДЕНИЕ: Используйте с осторожностью, так как это может испортить структуру YAML! | ||
postRender.globalStringReplacements | Словарь возможностей для замены, который может быть применен к YAML из визуализированного объекта. Основной вариант использования для этого заключается в сочетании с обширным дефолтом в _HULL_OBJECT_TYPE_DEFAULT_ и экземплярах объектов sources , где он позволяет вводить конкретные строки экземпляра в невыполненные ямлы. Предварительно настроенные отображения могут быть enabled: true по требованию. Каждое отображение состоит из следующих полей:
| ||
postRender.globalStringReplacements.instanceKey | Если enabled , string значение будет заменено фактическим объектом instance_key как в hull.objects.<object_type>.<instance_key> Значение replacement - это OBJECT_INSTANCE_KEY для этого отображения. | instanceKey:enabled: falsestring: _HULL_OBJECT_TYPE_DEFAULT_replacement: OBJECT_INSTANCE_KEY | |
postRender.globalStringReplacements.instanceKeyResolved | Если enabled , string значение будет заменено на фактический объект instance_key , как в hull.objects.<object_type>.<instance_key> или by hull.objects.<object_type>.<instance_key>.metadataNameOverride если это определено. Значение replacement - это OBJECT_INSTANCE_KEY_RESOLVED для этого отображения. | instanceKeyResolved:enabled: falsestring: _HULL_OBJECT_TYPE_DEFAULT_replacement: OBJECT_INSTANCE_KEY_RESOLVED | |
postRender.globalStringReplacements.instanceName | Если enabled , string значение будет заменено на фактические рендерированные metadata.name . Значение replacement - это OBJECT_INSTANCE_NAME для этого отображения. | instanceName:enabled: falsestring: _HULL_OBJECT_TYPE_DEFAULT_replacement: OBJECT_INSTANCE_NAME | |
serialization | Общие варианты сериализации. | ||
serialization.configmap.enabled | Если enabled , снопленные расширения файла в соответствии с fileExtensions сериализуются с помощью данного метода сериализации по умолчанию. Если клавиша data заканчивается одним из картинных расширений, метод сериализации в значении используется для записи содержимого в строку. Конкретное поле serialization в вводе data ConfigMaps перезаписывает любые настройки по умолчанию. | true | |
serialization.configmap.fileExtensions | Словарь сопоставлений от расширений файлов до методов сериализации. | fileExtensions:json: toPrettyJsonyaml: toYamlyml: toYaml | |
serialization.secret.enabled | Если enabled , снопленные расширения файла в соответствии с fileExtensions сериализуются с помощью данного метода сериализации по умолчанию. Если клавиша data заканчивается одним из картинных расширений, метод сериализации в значении используется для записи содержимого в строку. Конкретное поле serialization в регистрации data в секретах перезаписывает любые настройки по умолчанию. | true | |
serialization.secret.fileExtensions | Словарь сопоставлений от расширений файлов до методов сериализации. | fileExtensions:json: toPrettyJsonyaml: toYamlyml: toYaml | |
config.general.rbac | Глобальный коммутатор, который позволяет объектам RBAC для установки. Если true All включенные объекты RBAC развернуты в кластере, если false создаются объекты rbac.Объекты RBAC развертываются: rolesrolebindingsclusterrolesclusterrolebindings | true | false |
config.general.data | Поле свободной формы, тогда как подполя этого поля должны иметь четко определенное значение в контексте вашего продукта. Например, предположим, что все ваши продукты или микросервисы (каждая из которых появляется в виде отдельной диаграммы хлеба), зависит от тех же заданных конечных точек (аутентификация, конфигурация, ...). У вас может быть общая работа Kubernetes, выполненная каждой диаграммой Helm, которая нацелена на эти конечные точки. Теперь вы можете указать values.yaml внешнего корпуса. YAML, содержащий спецификацию задания, и определение конечной точки здесь так, как вы видите, и создаете values.yaml наложения. YAML, отображаемый поверх каждого развертывания и имеет единый механизм. | {} | |
config.general.metadata | Определенные поля метаданных здесь будут автоматически добавлены во все метаданные объекта. Имеет только следующие суб-поля: labelsannotations | ||
config.general.metadata.labels | Метки, которые добавляются ко всем объектам. common этикетки относятся к общим мечениям Kubernetes, и могут быть свободно указаны custom этикетки.Имеет только следующие суб-поля: commoncustom | ||
config.general.metadata.labels.common | Спецификация общих меток, как определено в https://helm.sh/docs/chart_best_practices/labels/ и https://kubernetes.io/docs/concepts/overview/working-bith-objects/common-labels/. Если специально не переписано с пустыми значениями ( '' ), все этикетки метаданных автоматически добавляются ко всем объектам в соответствии с их определением по умолчанию. Следует рассмотреть возможность установить значение для config.general.metadata.labels.common.'app.kubernetes.io/part-of' если диаграмма Helm является частью набора продуктов. | ||
config.general.metadata.labels.common.'app.kubernetes.io/managed-by' | Управляется метаданными. | {{ .Release.Service }} | |
config.general.metadata.labels.common.'app.kubernetes.io/version' | Версия метаданные. | {{ .Chart.AppVersion }} | |
config.general.metadata.labels.common.'app.kubernetes.io/part-of' | Часть метаданных. | "unspecified" | |
config.general.metadata.labels.common.'app.kubernetes.io/name' | Название метаданных. | {{ printf "%s-%s" .ChartName <hullObjectKey> }} | |
config.general.metadata.labels.common.'app.kubernetes.io/instance' | Метаданные экземпляра. | {{ .Release.Name }} | |
config.general.metadata.labels.common.'app.kubernetes.io/component' | Компонентные метаданные. | <hullObjectKey> | |
config.general.metadata.labels.common.'helm.sh/chart' | Управляя метаданные. | `{{(printf"%s-%s ".chart.name .chart.version) | заменить "+" "_"}} ` |
config.general.metadata.labels.custom | Все указанные пользовательские этикетки автоматически добавляются ко всем объектам этой диаграммы Helm. | {} | |
config.general.metadata.annotations | Аннотации, которые добавляются ко всем объектам. custom этикетки могут быть свободно указаны.Имеет только следующие суб-поля: custom . | ||
config.general.metadata.annotations.custom | Все указанные пользовательские аннотации автоматически добавляются ко всем объектам этой диаграммы Helm. | {} | |
config.specific | Поле бесплатной формы, в котором содержится параметры конфигурации, специфичные для конкретного продукта, содержащегося в диаграмме Helm. Как правило, значения, указанные здесь, должны использоваться для заполнения содержимого файлов конфигурации, которые конкретные приложения читают свою конфигурацию из At Startup. Следовательно, config.specific поля обычно потребляются в конфигурации или секретах. | {} | maxDatepickerRange: 50defaultPoolColor: "#FB6350"updateInterval: 60000 |
objects Типы объектов верхнего уровня под hull.objects представляют собой поддерживаемые типы объектов Kubernetes, из которых вы можете создать экземпляры. Каждый тип объекта - это словарь, где значения записей являются свойствами объектов, и каждый объект имеет свой собственный ключ, который является уникальным для типа объекта, которому он принадлежит. Дальнейшие типы объектов K8S могут быть добавлены по мере необходимости в библиотеку, чтобы его можно было легко расширить.
Одним из важных аспектов является то, что для всех типов объектов верхнего уровня экземпляры конкретного типа всегда идентифицируются ключом, который является уникальным для комбинации экземпляра и типа объекта. Однако один и тот же ключ можно использовать для экземпляров разных типов объектов.
Имея ключи, которые определяют случаи, которые вы можете:
Сделайте многослойное объединение свойств объекта путем укладки values.yaml . Вы можете начать с определения структуры объекта по умолчанию приложения или микро службы, определенной в данной диаграмме Helm. Затем вы можете добавить слой values.yaml для конкретной среды, такой как постановка или производство. Затем вы можете добавить слой values.yaml для учетных данных. И так далее. By uniquely identifying the instances of a particular K8s object type it becomes easy to adjust the objects properties through a multitude of layers.
use the key of an instance for naming the instance. All instance names are constructed by the following ground rule: {{ printf "%s-%s-%s" .Release.Name .Chart.Name key }} . This generates unique, dynamic names per object type and release + instance key combination.
For example, assuming the parent Helm chart is named my_webservice and the release named staging and given this specification in values.yaml :
hull :
objects :
deployment :
nginx :
pod :
containers :
nginx :
repository : nginx
tag : 1.14.2 a Kubernetes deployment object with the following metadata.name is created:
my_webservice-staging-nginx
Note that you can opt to define a static name for instances you create by adding a property
staticName: trueto your objects definition. If you do so the objects name will exactly match the key name you chose.
each particular instance can have an enabled sub-field set to true or false . This way you can predefine instances of object types in your helm charts values.yaml but not deploy them in a default scenario. Or enable them by default and refrain from deploying them in a particular environment by disabling them in an superimposed system specific values.yaml . Note that unless you explicitly specify enabled: false each instance you define will be created by default, a missing enabled key is equivalent to enabled: true .
cross-referencing objects within a helm chart by the instance key is a useful feature of the HULL library. This is possible in these contexts:
Note that you can in these cases opt to refer to a static name instead too. Adding a property
staticName: trueto the dictionary with your reference will force the referenced objects name to exactly match the name you entered.
The values of object instance keys reflects the Kubernetes objects to create for the chart. To specify these objects efficiently, the available properties for configuration can be split into three groups:
Basic HULL object configuration with hull.ObjectBase.v1 whose properties are available for all object types and instances. These are enabled , staticName , annotations and labels .
Given the example of a deployment named nginx you can add the following properties of hull.ObjectBase.v1 to the object instance:
hull :
objects :
deployment :
nginx : # unique key/identifier of the deployment to create
staticName : true # property of hull.ObjectBase.v1
# forces the metadata.name to be just the <KEY> 'nginx'
# and not a dynamic name '<CHART>-<RELEASE>-<KEY>' which
# would be the better default behavior of creating
# unique object names for all objects.
enabled : true # property of hull.ObjectBase.v1
# this deployment will be rendered to a YAML object if enabled
labels :
demo_label : " demo " # property of hull.ObjectBase.v1
# add all labels here that shall be added
# to the object instance metadata section
annotations :
demo_annotation : " demo " # property of hull.ObjectBase.v1
# add all annotations here that shall be added
# to the object instance metadata section
pod :
... # Here would come the hull.PodTemplate.v1 definition
# see below for details
Specialized HULL object properties for some object types. Below is a reference of which object type supports which special properties in addition to the basic object configuration.
Again given the example of a deployment named nginx you would want to add properties of the HULL hull.PodTemplate.v1 to the instance. With them you set the pod property to define the pod template (initContainers, containers, volumes, ...) and can add templateLabels and templateAnnotations just to the pods created metadata and not the deployment objects metadata section:
hull :
objects :
deployment :
nginx :
staticName : true
enabled : true
labels :
demo_label : " demo "
annotations :
demo_annotation : " demo "
templateLabels : # property of hull.PodTemplate.v1 to define
# labels only added to the pod
demo_pod_label : " demo pod "
templateAnnotations : # property of hull.PodTemplate.v1 to define
# annotations only added to the pod
demo_pod_annotation : " demo pod "
pod : # property of hull.PodTemplate.v1 to define the pod template
containers :
nginx : # all containers of a pod template are also referenced by a
# unique key to make manipulating them easy.
image :
repository : nginx # specify repository and tag
# separately with HULL for easier composability
tag : 1.14.2
... # further properties (volumeMounts, affinities, ...)
Kubernetes object properties. For each object type it is basically possible to specify all existing Kubernetes properties. In case a HULL property overwrites a identically named Kubernetes property the HULL property has precedence. Even if a HULL property overrides a Kubernetes property it is intended to provide the same complete configuration options, even if sometimes handled differently by HULL.
Some of the typical top-level Kubernetes object properties and fields don't require setting them with HULL based objects because they can be deducted automatically:
apiVersion and kind are determined by the HULL object type and Kubernetes API version and don't require to be explicitly set (except for objects of type customresource ).metadata dictionary on objects is handled by HULL via the annotations and labels fields and the naming rules explained above. So the metadata field does not require configuration and is hence not configurable for any object.Some lower level structures are also converted from the Kubernetes API array form to a dictionary form or are modified to improve working with them. This also enables more sophisticated merging of layers since arrays don't merge well, they only can be overwritten completely. Overwriting arrays however can make it hard to forget about elements that are contained in the default form of the array (you would need to know that they existed in the first place). In short, for a layered configuration approach without an endless amount of elements the dictionary is preferable for representing data since it offers a much better merging support.
So again using the example of a deployment named nginx you can add the remaining available Kubernetes properties to the object instance which are not handled by HULL as shown below. For a deployment specifically you can add all the remaining properties defined in the deploymentspec API schema from deploymentspec-v1-apps which are minReadySeconds , paused , progressDeadlineSeconds , replicas , revisionHistoryLimit and strategy . If properties are marked as mandatory in the Kubernetes JSON schema you must provide them otherwise the rendering process will fail:
hull :
objects :
deployment :
nginx :
staticName : true
enabled : true
labels :
demo_label : " demo "
annotations :
demo_annotation : " demo "
pod :
... # Here would come the hull.PodTemplate.v1 definition
# see above for details
replicas : 3 # property from the Kubernetes API deploymentspec
strategy : # property from the Kubernetes API deploymentspec
type : Recreate
... # further Kubernetes API deploymentspec options
Here is an overview of which top level properties are available for which object type in HULL. The HULL properties are grouped by the respective HULL JSON schema group they belong to. A detailed description of these groups and their properties is found in the documentation of this helm chart and the respective linked documents.
Workloads APIs
| HULL Object Type | HULL Характеристики | Kubernetes/External Характеристики |
|---|---|---|
deployment | hull.ObjectBase.v1enabledannotationslabelsstaticNamehull.PodTemplate.v1 templateAnnotationstemplateLabelspod | deploymentspec-v1-appsminReadySecondspausedprogressDeadlineSecondsreplicasrevisionHistoryLimitstrategy |
job | hull.ObjectBase.v1enabledannotationslabelsstaticNamehull.PodTemplate.v1 templateAnnotationstemplateLabelspod | jobspec-v1-batchactiveDeadlineSecondsbackoffLimitcompletionModecompletionsmanualSelectorparallelismselectorsuspendttlSecondsAfterFinished |
daemonset | hull.ObjectBase.v1enabledannotationslabelsstaticNamehull.PodTemplate.v1 templateAnnotationstemplateLabelspod | daemonsetspec-v1-appsminReadySecondsrevisionHistoryLimitupdateStrategy |
statefulset | hull.ObjectBase.v1enabledannotationslabelsstaticNamehull.PodTemplate.v1 templateAnnotationstemplateLabelspod | statefulsetspec-v1-appspodManagementPolicyreplicasrevisionHistoryLimitserviceNameupdateStrategyserviceNamevolumeClaimTemplates |
cronjob | hull.ObjectBase.v1enabledannotationslabelsstaticNamehull.Job.v1 job | cronjobspec-v1-batchconcurrencyPolicyfailedJobsHistoryLimitschedulestartingDeadlineSecondssuccessfulJobsHistoryLimitsuspend |
Service APIs
| HULL Object Type | HULL Характеристики | Kubernetes/External Характеристики |
|---|---|---|
endpoints | hull.ObjectBase.v1enabledannotationslabelsstaticName | endpoints-v1-coresubsets |
endpointslice | hull.ObjectBase.v1enabledannotationslabelsstaticName | endpointslice-v1-discovery-k8s-ioaddressTypeendpointsports |
service | hull.ObjectBase.v1enabledannotationslabelsstaticNamehull.Service.v1 ports | servicespec-v1-coreallocateLoadBalancerNodePortsclusterIPclusterIPsexternalIPsexternalNameexternalTrafficPolicyhealthCheckNodePortinternalTrafficPolicyipFamiliesipFamilyPolicyloadBalancerClassloadBalancerIPloadBalancerSourceRangespublishNotReadyAddressesselectorsessionAffinitysessionAffinityConfigtopologyKeystype |
ingress | hull.ObjectBase.v1enabledannotationslabelsstaticNamehull.Ingress.v1 tlsrules | ingressspec-v1-networking-k8s-iodefaultBackendingressClassName |
ingressclass | hull.ObjectBase.v1enabledannotationslabelsstaticName | ingressclassspec-v1-networking-k8s-iocontrollerparameters |
Config and Storage APIs
| HULL Object Type | HULL Характеристики | Kubernetes/External Характеристики |
|---|---|---|
configmap | hull.ObjectBase.v1enabledannotationslabelsstaticNamehull.VirtualFolder.v1 data | configmap-v1-corebinaryDataimmutable |
secret | hull.ObjectBase.v1enabledannotationslabelsstaticNamehull.VirtualFolder.v1 data | secret-v1-coreimmutablestringDatatype |
registry | hull.ObjectBase.v1enabledannotationslabelsstaticNamehull.Registry.v1 serverusernamepassword | secret-v1-core |
persistentvolumeclaim | hull.ObjectBase.v1enabledannotationslabelsstaticName | persistentvolumeclaimspec-v1-coreaccessModesdataSourceresourcesselectorstorageClassNamevolumeModevolumeName |
storageclass | hull.ObjectBase.v1enabledannotationslabelsstaticName | storageclass-v1-storage-k8s-ioallowVolumeExpansionallowedTopologiesmountOptionsparametersprovisionerreclaimPolicyvolumeBindingMode |
Metadata APIs
| HULL Object Type | HULL Характеристики | Kubernetes/External Характеристики |
|---|---|---|
customresource | hull.ObjectBase.v1enabledannotationslabelsstaticNamehull.CustomResource.v1 apiVersionkindspec | |
limitrange | hull.ObjectBase.v1enabledannotationslabelsstaticName | limitrange-v1-corelimits |
horizontalpodautoscaler | hull.ObjectBase.v1enabledannotationslabelsstaticNamehull.HorizontalPodAutoscaler.v1 scaleTargetRef | horizontalpodautoscalerspec-v2-autoscalingbehaviormaxReplicasmetricsminReplicas |
mutatingwebhookconfiguration | hull.ObjectBase.v1enabledannotationslabelsstaticNamehull.MutatingWebhook.v1 webhooks | |
poddisruptionbudget | hull.ObjectBase.v1enabledannotationslabelsstaticName | poddisruptionbudgetspec-v1-policymaxUnavailableminAvailableselector |
validatingwebhookconfiguration | hull.ObjectBase.v1enabledannotationslabelsstaticNamehull.ValidatingWebhook.v1 webhooks | |
priorityclass | hull.ObjectBase.v1enabledannotationslabelsstaticName | priorityclass-v1-scheduling-k8s-iodescriptionglobalDefaultpreemptionPolicyvalue |
Cluster APIs
| HULL Object Type | HULL Характеристики | Kubernetes/External Характеристики |
|---|---|---|
clusterrole | hull.ObjectBase.v1enabledannotationslabelsstaticNamehull.Rule.v1 rules | clusterrole-v1-rbac-authorization-k8s-ioaggregationRule |
clusterrolebinding | hull.ObjectBase.v1enabledannotationslabelsstaticName | clusterrolebinding-v1-rbac-authorization-k8s-ioroleRefsubjects |
namespace | hull.ObjectBase.v1enabledannotationslabelsstaticName | namespace-v1-corespecstatus |
persistentvolume | hull.ObjectBase.v1enabledannotationslabelsstaticName | persistentvolumespec-v1-coreaccessModesawsElasticBlockStoreazureDiskazureFilecapacitycephfscinderclaimRefcsifcflexVolumeflockergcePersistentDiskglusterfshostPathiscsilocalmountOptionsnfsnodeAffinitypersistentVolumeReclaimPolicyphotonPersistentDiskportworxVolumequobyterbdscaleIOstorageClassNamestorageosvolumeModevsphereVolume |
role | hull.ObjectBase.v1enabledannotationslabelsstaticNamehull.Rule.v1 rules | role-v1-rbac-authorization-k8s-io |
rolebinding | hull.ObjectBase.v1enabledannotationslabelsstaticName | rolebinding-v1-rbac-authorization-k8s-ioroleRefsubjects |
serviceaccount | hull.ObjectBase.v1enabledannotationslabelsstaticName | serviceaccount-v1-coreautomountServiceAccountTokenimagePullSecretssecrets |
resourcequota | hull.ObjectBase.v1enabledannotationslabelsstaticName | resourcequotaspec-v1-corehardscopeSelectorscopes |
networkpolicy | hull.ObjectBase.v1enabledannotationslabelsstaticName | networkpolicyspec-v1-networking-k8s-ioegressingresspodSelectorpolicyTypes |
Other APIs
| HULL Object Type | HULL Характеристики | Kubernetes/External Характеристики |
|---|---|---|
servicemonitor | hull.ObjectBase.v1enabledannotationslabelsstaticName | ServiceMonitor CRDspec |
To test or install a chart based on HULL the standard Helm v3 tooling is usable. See also the Helm documentation at the Helm website.
To inspect the outcome of a specific values.yaml configuration you can simply render the templates which would be deployed to Kubernetes and inspect them with the below command adapted to your needs:
<PATH_TO_HELM_V3_BINARY> template --debug --namespace <CHART_RELEASE_NAMESPACE> --kubeconfig <PATH_TO_K8S_CLUSTER_KUBECONFIG> -f <PATH_TO_SYSTEM_SPECIFIC_VALUES_YAML> --output-dir <PATH_TO_OUTPUT_DIRECTORY> <PATH_TO_CHART_DIRECTORY>
Installing or upgrading a chart using HULL follows the standard procedures for every Helm chart:
<PATH_TO_HELM_V3_BINARY> upgrade --install --debug --create-namespace --atomic --namespace <CHART_RELEASE_NAMESPACE> --kubeconfig <PATH_TO_K8S_CLUSTER_KUBECONFIG> -f <PATH_TO_SYSTEM_SPECIFIC_VALUES_YAML> <RELEASE_NAME> <PATH_TO_CHART_DIRECTORY>
Using the nginx deployment example from the Kubernetes documentation https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#creating-a-deployment as something we want to create with our HULL based Helm chart:
apiVersion : apps/v1
kind : Deployment
metadata :
name : nginx
labels :
app : nginx
spec :
replicas : 3
selector :
matchLabels :
app : nginx
template :
metadata :
labels :
app : nginx
spec :
containers :
- name : nginx
image : nginx:1.14.2
ports :
- containerPort : 80 To render this analogously using the HULL library your chart needs to be setup for using HULL. In the following section we assume the parent Helm chart is named hull-test and we use the helm template command to test render the values.yaml 's.
A minimal example of creating the expected result from above would be to create a values.yaml like below in your parent chart (commented with some explanations). Note that some default features of HULL such as RBAC and dynamic naming are explicitly disabled here to obtain the output matching the above example closely:
hull :
config :
general :
rbac : false # Don't render RBAC objects. By default HULL would provide
# a 'default' Role and 'default' RoleBinding associated with
# a 'default' ServiceAccount to use for all pods.
# You can modify this as needed. Here we turn it off to not
# render the default RBAC objects.
objects :
serviceaccount :
default :
enabled : false # The release specific 'default' ServiceAccount created
# for a release by default is disabled here. In this case
# it will not be rendered out and automatically used as
# 'serviceAccountName' in the pod templates.
deployment :
nginx : # all object instances have a key used for naming the objects and
# allowing to overwrite properties in multiple values.yaml layers
staticName : true # forces the metadata.name to be just the <KEY> 'nginx'
# and not a dynamic name '<CHART>-<RELEASE>-<KEY>' which
# would be the better default behavior of creating
# unique object names for all objects.
replicas : 3
pod :
containers :
nginx : # all containers of a pod template are also referenced by a
# unique key to make manipulating them easy.
image :
repository : nginx
tag : 1.14.2
ports :
http : # unique key per container here too. All key-value structures
# which are finally arrays in the K8S objects are converted to
# arrays on rendering the chart.
containerPort : 80 This produces the following rendered deployment when running the helm template command (commented with some brief explanations):
apiVersion : apps/v1 # derived from object type 'deployment'
kind : Deployment # derived from object type 'deployment'
metadata :
annotations : {}
labels : # standard Kubernetes metadata is created always automatically.
app.kubernetes.io/component : nginx
app.kubernetes.io/instance : release-name
app.kubernetes.io/managed-by : Helm
app.kubernetes.io/name : hull-test
app.kubernetes.io/part-of : undefined
app.kubernetes.io/version : 1.31.0
helm.sh/chart : hull-test-1.31.0
name : nginx # default name would be 'release-name-hull-test-nginx'
# but with staticName: true in the HULL spec it is just the key name
spec :
replicas : 3
selector : # selector is auto-created to match the unique metadata combination
# found also in the in the object's metadata labels.
matchLabels :
app.kubernetes.io/component : nginx
app.kubernetes.io/instance : release-name
app.kubernetes.io/name : hull-test
template :
metadata :
annotations : {}
labels : # auto-created metadata is added to pod template
app.kubernetes.io/component : nginx
app.kubernetes.io/instance : release-name
app.kubernetes.io/managed-by : Helm
app.kubernetes.io/name : hull-test
app.kubernetes.io/part-of : undefined
app.kubernetes.io/version : 1.31.0
helm.sh/chart : hull-test-1.31.0
spec :
containers :
- env : []
envFrom : []
image : nginx:1.14.2
name : nginx
ports :
- containerPort : 80
name : http # name 'http' derived from the key of the port
# object defined in the values.yaml
volumeMounts : []
imagePullSecrets : {}
initContainers : []
volumes : [] Now to render the nginx deployment example showcasing extra features of the HULL library you can could create the below values.yaml file in your parent chart. Note that this is a very advanced example of what is possible using this library chart.
This example highlights:
hull :
config :
general : # This time we are not setting rbac: false
# so RBAC default objects are created.
# If the default objects don't match the use-case
# you can tweak all aspects individually if needed
metadata :
labels :
custom : # Additional labels added to all K8S objects
general_custom_label_1 : General Custom Label 1
general_custom_label_2 : General Custom Label 2
general_custom_label_3 : General Custom Label 3
annotations :
custom : # Additional annotations added to all K8S objects
general_custom_annotation_1 : General Custom Annotation 1
general_custom_annotation_2 : General Custom Annotation 2
general_custom_annotation_3 : General Custom Annotation 3
specific : # Put configuration options specific to this chart here
nginx_tag : 1.14.2 # You can also use entries here to globally
# define values that are referenced in multiple
# places in your chart. See how this field
# is accessed below in the deployment.
objects :
deployment :
_HULL_OBJECT_TYPE_DEFAULT_ : # A special object key available for
# all object types allowing defining
# defaults for properties of all object
# type instances created.
annotations :
default_annotation_1 : Default Annotation 1
default_annotation_2 : Default Annotation 2
general_custom_annotation_2 : Default Annotation 2 # overwriting this
# general annotation for
# all deployments
labels :
default_label_1 : Default Label 1
default_label_2 : Default Label 2
general_custom_label_2 : Default Label 2 # overwriting this
# general label for
# all deployments
nginx : # specify the nginx deployment under key 'nginx'
# This time we're not setting the metadata.name to be static so
# name will be created dynamically and will be unique
annotations :
general_custom_annotation_3 : Specific Object Annotation 3 # overwrite a
# general annotation
default_annotation_2 : Specific Object Annotation 2 # overwrite a default annotation
specific_annotation_1 : Specific Object Annotation 1 # add a specific annotation
# to the all this object's metadata
labels :
general_custom_label_3 : Specific Object Label 3 # overwrite a
# general label
default_label_2 : Specific Object Label 2 # overwrite a default label
specific_label_1 : Specific Object Label 1 # add a specific label
# to the all this object's metadata
templateAnnotations :
specific_annotation_2 : Specific Template Annotation 2 # this annotation will only appear
# in the pod template metadata
templateLabels :
specific_label_2 : Specific Template Label 2 # this label will only appear
# in the pod template metadata
replicas : 3
pod :
containers :
nginx : # all containers of a pod template are also referenced by a
# unique key to make manipulating them easy.
image :
repository : nginx
tag : _HT!{{ (index . "$").Values.hull.config.specific.nginx_tag }}
# Applies a tpl transformation allowing to inject dynamic data based
# on values in this values.yaml into the resulting field (here the tag
# field of this container).
# _HT! is the short form of the transformation that applies tpl to
# a given value. This example just references the value of the field
# which is specified further above in the values.yaml and will
# produce 'image: nginx:1.14.2' when rendered in the resulting
# deployment YAML but complex conditional Go templating logic is
# applicable too.
# There are some limitations to using this approach which are
# detailed in the transformation.md in the doc section.
ports :
http : # unique key per container here too. All key-value structures
# which are array in the K8S objects are converted to arrays
# on rendering the chart.
containerPort : 80
configmap : # this is to highlight the secret/configmap inclusion feature
nginx_configmap : # configmap objects have keys too
data : # specify for which contents a data entry shall be created
# within only a few lines of configuration. Contents can come from ...
an_inline_configmap.txt : # ... an inline specified content or ...
inline : |-
Top secret contents
spread over
multiple lines...
contents_from_an_external_file.txt : # ... something from an external file.
path : files/my_secret.txt
This produces the following rendered objects when running the helm template command (commented with some brief explanations):
---
# Source: hull-test/templates/hull.yaml
apiVersion : v1
kind : ServiceAccount
metadata :
annotations :
general_custom_annotation_1 : General Custom Annotation 1 # All objects share the general_custom_annotations
general_custom_annotation_2 : General Custom Annotation 2 # if they are not overwritten for the object type's
general_custom_annotation_3 : General Custom Annotation 3 # default or specific instance
labels :
app.kubernetes.io/component : default
app.kubernetes.io/instance : release-name
app.kubernetes.io/managed-by : Helm
app.kubernetes.io/name : hull-test
app.kubernetes.io/part-of : undefined
app.kubernetes.io/version : 1.31.0
general_custom_label_1 : General Custom Label 1 # All objects share the general_custom_labels
general_custom_label_2 : General Custom Label 2 # if they are not overwritten for the object type's
general_custom_label_3 : General Custom Label 3 # default or specific instance
helm.sh/chart : hull-test-1.31.0
name : release-name-hull-test-default # This is the default ServiceAccount created for this chart.
# As all object instances by default it will be assigned a
# dynamically created unique name in context of this object type.
# In the simple example we disabled this rendering by
# setting enabled: false for this object's key.
---
# Source: hull-test/templates/hull.yaml
apiVersion : rbac.authorization.k8s.io/v1
kind : Role
metadata :
annotations :
general_custom_annotation_1 : General Custom Annotation 1
general_custom_annotation_2 : General Custom Annotation 2
general_custom_annotation_3 : General Custom Annotation 3
labels :
app.kubernetes.io/component : default
app.kubernetes.io/instance : release-name
app.kubernetes.io/managed-by : Helm
app.kubernetes.io/name : hull-test
app.kubernetes.io/part-of : undefined
app.kubernetes.io/version : 1.31.0
general_custom_label_1 : General Custom Label 1
general_custom_label_2 : General Custom Label 2
general_custom_label_3 : General Custom Label 3
helm.sh/chart : hull-test-1.31.0
name : release-name-hull-test-default # A default Role for RBAC.
rules : []
---
# Source: hull-test/templates/hull.yaml
apiVersion : rbac.authorization.k8s.io/v1
kind : RoleBinding
metadata :
annotations :
general_custom_annotation_1 : General Custom Annotation 1
general_custom_annotation_2 : General Custom Annotation 2
general_custom_annotation_3 : General Custom Annotation 3
labels :
app.kubernetes.io/component : default
app.kubernetes.io/instance : release-name
app.kubernetes.io/managed-by : Helm
app.kubernetes.io/name : hull-test
app.kubernetes.io/part-of : undefined
app.kubernetes.io/version : 1.31.0
general_custom_label_1 : General Custom Label 1
general_custom_label_2 : General Custom Label 2
general_custom_label_3 : General Custom Label 3
helm.sh/chart : hull-test-1.31.0
name : release-name-hull-test-default
roleRef :
apiGroup : rbac.authorization.k8s.io/v1
kind : Role
name : release-name-hull-test-default
subjects :
- apiGroup : rbac.authorization.k8s.io/v1
kind : ServiceAccount
name : release-name-hull-test-default # A default RoleBinding for RBAC. It connects the
# default ServiceAccount with the default Role.
# By default RBAC is enabled in charts.
---
# Source: hull-test/templates/hull.yaml
apiVersion : apps/v1
kind : Deployment
metadata :
annotations :
default_annotation_1 : Default Annotation 1 # non-overwritten default_annotation
default_annotation_2 : Specific Object Annotation 2 # overwritten default_annotation by instance
general_custom_annotation_1 : General Custom Annotation 1 # non-overwritten general_custom_annotation
general_custom_annotation_2 : Default Annotation 2 # overwritten general_custom_annotation
# by default_annotation
general_custom_annotation_3 : Specific Object Annotation 3 # overwritten general_custom_annotation
# by specific_annotation
specific_annotation_1 : Specific Object Annotation 1 # added annotation for instance metadata only
labels :
app.kubernetes.io/component : nginx
app.kubernetes.io/instance : release-name
app.kubernetes.io/managed-by : Helm
app.kubernetes.io/name : hull-test
app.kubernetes.io/part-of : undefined
app.kubernetes.io/version : 1.31.0
default_label_1 : Default Label 1 # non-overwritten default_label
default_label_2 : Specific Object Label 2 # overwritten default_label by instance
general_custom_label_1 : General Custom Label 1 # non-overwritten general_custom_label
general_custom_label_2 : Default Label 2 # overwritten general_custom_label by default_label
general_custom_label_3 : Specific Object Label 3 # overwritten general_custom_label
# by specific_label
helm.sh/chart : hull-test-1.31.0
specific_label_1 : Specific Object Label 1 # added label for instance metadata only
name : release-name-hull-test-nginx
spec :
replicas : 3
selector :
matchLabels :
app.kubernetes.io/component : nginx
app.kubernetes.io/instance : release-name
app.kubernetes.io/name : hull-test
template :
metadata :
annotations :
default_annotation_1 : Default Annotation 1
default_annotation_2 : Specific Object Annotation 2
general_custom_annotation_1 : General Custom Annotation 1
general_custom_annotation_2 : Default Annotation 2
general_custom_annotation_3 : Specific Object Annotation 3
specific_annotation_1 : Specific Object Annotation 1
specific_annotation_2 : Specific Template Annotation 2 # this annotation was added only
# for the pod template's metadata
labels :
app.kubernetes.io/component : nginx
app.kubernetes.io/instance : release-name
app.kubernetes.io/managed-by : Helm
app.kubernetes.io/name : hull-test
app.kubernetes.io/part-of : undefined
app.kubernetes.io/version : 1.31.0
default_label_1 : Default Label 1
default_label_2 : Specific Object Label 2
general_custom_label_1 : General Custom Label 1
general_custom_label_2 : Default Label 2
general_custom_label_3 : Specific Object Label 3
helm.sh/chart : hull-test-1.31.0
specific_label_1 : Specific Object Label 1
specific_label_2 : Specific Template Label 2 # this label was added only
# for the pod template's metadata
spec :
containers :
- env : []
envFrom : []
image : nginx:1.14.2
name : nginx
ports :
- containerPort : 80
name : http
volumeMounts : []
imagePullSecrets : {}
initContainers : []
serviceAccountName : release-name-hull-test-default # the dynamically created name
volumes : []
---
# Source: hull-test/templates/hull.yaml
apiVersion : v1
data :
an_inline_configmap.txt : " Top secret contents n spread over n multiple lines... "
contents_from_an_external_file.txt : " Whatever was in this file ... "
kind : ConfigMap
metadata :
annotations :
general_custom_annotation_1 : General Custom Annotation 1 # All objects share the general_custom_annotations
general_custom_annotation_2 : General Custom Annotation 2 # if they are not overwritten for the object type's
general_custom_annotation_3 : General Custom Annotation 3 # default or specific instance
labels :
app.kubernetes.io/component : nginx_configmap
app.kubernetes.io/instance : release-name
app.kubernetes.io/managed-by : Helm
app.kubernetes.io/name : hull-test
app.kubernetes.io/part-of : undefined
app.kubernetes.io/version : 1.31.0
general_custom_label_1 : General Custom Label 1 # All objects share the general_custom_labels
general_custom_label_2 : General Custom Label 2 # if they are not overwritten for the object type's
general_custom_label_3 : General Custom Label 3 # default or specific instance
helm.sh/chart : hull-test-1.31.0
name : release-name-hull-test-nginx_configmapRead the additional documentation in the documentation folder on how to utilize the features of the HULL library to the full effect.
