Ответ
Helm использует шаблоны Go (Go templates) для генерации Kubernetes-манифестов. Шаблоны хранятся в директории templates/ чарта.
Основные элементы:
- Переменные:
{{ .Values.param }}(берутся изvalues.yaml) - Условия:
{{ if .Values.enabled }} ... {{ end }} - Циклы:
{{ range .Values.items }} ... {{ end }} - Функции и хелперы:
{{ include "helper.tpl" . | indent 4 }}
Пример шаблона Deployment:
# templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: {{ .Release.Name }}-app
spec:
replicas: {{ .Values.replicaCount }}
selector:
matchLabels:
app: {{ .Release.Name }}-app
template:
metadata:
labels:
app: {{ .Release.Name }}-app
spec:
containers:
- name: app
image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
ports:
- containerPort: {{ .Values.service.port }}
Типичный рабочий процесс:
- Определяю параметры в
values.yaml. - Проверяю рендеринг шаблонов командой
helm template .илиhelm install --dry-run --debug .. - Устанавливаю или обновляю релиз:
helm upgrade --install my-release ..
Шаблоны Helm — это ключевой инструмент для параметризации, устранения дублирования и управления сложными наборами Kubernetes-ресурсов в рамках одного чарта.
Ответ 18+ 🔞
Давай разберём эту тему без соплей, по-рабочему. Helm, этот самый, использует шаблоны Go, чтобы из одной заготовки наштамповать кучу манифестов для кубера. Всё это добро лежит в папке templates/, и выглядит так, будто кто-то взял обычный YAML и накидал туда магических заклинаний в фигурных скобках.
Что там внутри обычно творится:
- Переменные:
{{ .Values.param }}— это типа «подставь сюда значение из того самого файликаvalues.yaml». Без этого вообще никак, иначе какой смысл? - Условия:
{{ if .Values.enabled }} ... {{ end }}— классика. Если галочка стоит — рендерим этот кусок, если нет — выкидываем нахуй. Очень удобно для фич, которые могут быть выключены. - Циклы:
{{ range .Values.items }} ... {{ end }}— когда тебе нужно, например, нагенерить кучу однотипных конфигов или переменных окружения. Проходишь по списку и штампуешь. - Функции и хелперы:
{{ include "helper.tpl" . | indent 4 }}— вот это уже для красоты и чтобы не повторяться. Выносишь общий кусок в отдельный файл и потом вставляешь его, где надо, с нужным отступом. Удобно, ёпта.
Вот смотри, как выглядит типичный деплоймент в таком шаблоне:
# templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: {{ .Release.Name }}-app
spec:
replicas: {{ .Values.replicaCount }}
selector:
matchLabels:
app: {{ .Release.Name }}-app
template:
metadata:
labels:
app: {{ .Release.Name }}-app
spec:
containers:
- name: app
image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
ports:
- containerPort: {{ .Values.service.port }}
Видишь? Всё параметризовано. Имя релиза, количество реплик, тег образа — всё вынесено наружу. Красота же!
А работать с этим надо так, чтобы не обосраться:
- Описываешь параметры в
values.yaml. Твоя главная панель управления. Там всё настраивается. - Проверяешь, что нагенерится. Перед тем как это всё в кластер пихать, обязательно смотришь командой
helm template .илиhelm install --dry-run --debug .. Это чтобы не получить волнение ебать, когда хелм начнёт создавать какую-то пиздопроебибну из-за опечатки. - Ставишь или обновляешь. Когда уверен, что шаблоны рендерятся как надо, делаешь
helm upgrade --install my-release .. И всё, понеслась.
Если коротко: шаблоны Helm — это такая хитрая жопа, которая превращает один чарт в универсальную фабрику по производству конфигов под разные окружения. Без них пришлось бы копипастить YAML-ы, а это, я тебе скажу, прямой путь в ад и к ошибкам на ровном месте.