Kubernetes Helm Charts у 2026: Пакування, Розгортання та Питання на Співбесідах

Kubernetes Helm Charts спрощують розгортання додатків, пакуючи всі ресурси Kubernetes в єдиний версійований артефакт. Helm 3, поточна стабільна версія, усуває потребу в Tiller та вводить підтримку OCI реєстрів, роблячи розповсюдження чартів більш безпечним та стандартизованим. Цей посібник охоплює створення чартів, шаблонування, стратегії розгортання та найчастіші питання на технічних співбесідах.

Розуміння Структури та Компонентів Helm Chart

Helm chart — це директорія з попередньо визначеною структурою. Назва чарту стає назвою директорії, і кожен файл виконує певну функцію в процесі пакування та розгортання.

# Chart.yaml
apiVersion: v2
name: my-application
description: A production-ready web application
type: application
version: 1.0.0
appVersion: "2.1.0"
dependencies:
  - name: postgresql
    version: "15.x"
    repository: "https://charts.bitnami.com/bitnami"
    condition: postgresql.enabled

apiVersion: v2 вказує на сумісність з Helm 3. Поле version відстежує зміни чарту, тоді як appVersion відображає версію розгорнутого додатку. Залежності декларують інші чарти, необхідні для цього чарту, з опціональними умовами для їх увімкнення або вимкнення.

# values.yaml
replicaCount: 3

image:
  repository: myregistry.io/app
  tag: "2.1.0"
  pullPolicy: IfNotPresent

service:
  type: ClusterIP
  port: 8080

resources:
  limits:
    cpu: 500m
    memory: 512Mi
  requests:
    cpu: 100m
    memory: 128Mi

postgresql:
  enabled: true
  auth:
    database: appdb

Значення визначають конфігураційні налаштування за замовчуванням, які користувачі перевизначають під час встановлення. Групування значень під змістовними ключами підтримує конфігурації організованими та самодокументованими.

Створення Kubernetes Deployment за Допомогою Helm Шаблонів

Helm шаблони використовують Go шаблонування з функціями Sprig для динамічної генерації маніфестів Kubernetes. Об'єкт {{ .Values }} забезпечує доступ до вмісту values.yaml, тоді як {{ .Release }} містить метадані розгортання.

# templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "my-application.fullname" . }}
  labels:
    {{- include "my-application.labels" . | nindent 4 }}
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      {{- include "my-application.selectorLabels" . | nindent 6 }}
  template:
    metadata:
      labels:
        {{- include "my-application.selectorLabels" . | nindent 8 }}
    spec:
      containers:
        - name: {{ .Chart.Name }}
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
          imagePullPolicy: {{ .Values.image.pullPolicy }}
          ports:
            - containerPort: {{ .Values.service.port }}
          resources:
            {{- toYaml .Values.resources | nindent 12 }}

Функція nindent додає новий рядок та відступ, що є критичним для генерації YAML. Використання include з іменованими шаблонами (визначеними в _helpers.tpl) підтримує шаблони згідно з принципом DRY та легкими в обслуговуванні.

# templates/_helpers.tpl
{{- define "my-application.fullname" -}}
{{- if .Values.fullnameOverride }}
{{- .Values.fullnameOverride | trunc 63 | trimSuffix "-" }}
{{- else }}
{{- $name := default .Chart.Name .Values.nameOverride }}
{{- printf "%s-%s" .Release.Name $name | trunc 63 | trimSuffix "-" }}
{{- end }}
{{- end }}

{{- define "my-application.labels" -}}
helm.sh/chart: {{ include "my-application.chart" . }}
app.kubernetes.io/name: {{ include "my-application.name" . }}
app.kubernetes.io/instance: {{ .Release.Name }}
app.kubernetes.io/version: {{ .Chart.AppVersion | quote }}
app.kubernetes.io/managed-by: {{ .Release.Service }}
{{- end }}

Допоміжні шаблони стандартизують конвенції найменування та мітки для всіх ресурсів, забезпечуючи узгодженість з рекомендованими мітками Kubernetes.

Залежності та Підчарти Helm

Складні додатки часто залежать від баз даних, кешів або черг повідомлень. Залежності Helm дозволяють вбудовувати їх як підчарти, що автоматично керуються під час встановлення.

# Оновлення залежностей перед пакуванням
helm dependency update ./my-application

# Збірка залежностей (створює директорію charts/)
helm dependency build ./my-application

Команда helm dependency update завантажує залежності до директорії charts/. Умовні залежності використовують значення для перемикання включення:

# values.yaml
postgresql:
  enabled: true

redis:
  enabled: false

# Chart.yaml
dependencies:
  - name: postgresql
    version: "15.x"
    repository: "https://charts.bitnami.com/bitnami"
    condition: postgresql.enabled
  - name: redis
    version: "19.x"
    repository: "https://charts.bitnami.com/bitnami"
    condition: redis.enabled

Цей патерн дозволяє конфігурації, специфічні для середовища, де production використовує керовані сервіси, а development — бази даних всередині кластера.

Розгортання Helm Charts з Керуванням Релізами

Helm відстежує розгортання як релізи, забезпечуючи версійовані відкати та оновлення. Кожен реліз зберігає історію для аудиту та відновлення.

# Встановлення чарту з користувацькими значеннями
helm install my-release ./my-application \
  --namespace production \
  --create-namespace \
  --values production-values.yaml \
  --set image.tag=2.1.1

# Оновлення існуючого релізу
helm upgrade my-release ./my-application \
  --namespace production \
  --values production-values.yaml \
  --set image.tag=2.2.0 \
  --atomic \
  --timeout 5m

Прапорець --atomic забезпечує автоматичний відкат невдалих оновлень. Прапорець --timeout встановлює, як довго Helm чекає готовності ресурсів перед оголошенням невдачі.

# Перегляд історії релізу
helm history my-release -n production

# Відкат до попередньої ревізії
helm rollback my-release 2 -n production

# Видалення релізу
helm uninstall my-release -n production --keep-history

Прапорець --keep-history зберігає записи релізу навіть після видалення, що корисно для відповідності вимогам та налагодження.

Стратегії Тестування та Валідації Helm Charts

Тестування Helm charts перед розгортанням виявляє помилки шаблонів та проблеми конфігурації на ранніх етапах. Helm надає вбудовані інструменти для лінтингу та dry-run тестування.

# Лінтинг чарту на помилки та найкращі практики
helm lint ./my-application

# Рендеринг шаблонів локально без розгортання
helm template my-release ./my-application \
  --values production-values.yaml \
  > rendered-manifests.yaml

# Dry-run проти API кластера
helm install my-release ./my-application \
  --dry-run \
  --debug \
  --namespace production

Команда helm template рендерить маніфести локально, що корисно для CI пайплайнів, які валідують згенерований YAML. Прапорець --dry-run надсилає маніфести до API сервера Kubernetes для валідації без створення ресурсів.

# templates/tests/test-connection.yaml
apiVersion: v1
kind: Pod
metadata:
  name: "{{ include "my-application.fullname" . }}-test"
  labels:
    {{- include "my-application.labels" . | nindent 4 }}
  annotations:
    "helm.sh/hook": test
spec:
  containers:
    - name: curl
      image: curlimages/curl:8.7.1
      command: ['curl']
      args: ['{{ include "my-application.fullname" . }}:{{ .Values.service.port }}/health']
  restartPolicy: Never

Helm hooks з helm.sh/hook: test запускаються після helm test my-release, валідуючи правильну роботу розгортань після встановлення.

Просунуті Техніки Шаблонування Helm

Продакшн чарти вимагають умовної логіки, циклів та трансформації даних. Функції Sprig розширюють Go шаблони утилітами для маніпуляції рядками, кодування та керування потоком.

# templates/configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ include "my-application.fullname" . }}-config
data:
  {{- range $key, $value := .Values.config }}
  {{ $key }}: {{ $value | quote }}
  {{- end }}
  
  {{- if .Values.features.enabled }}
  FEATURE_FLAGS: {{ .Values.features.flags | join "," | quote }}
  {{- end }}

# templates/secrets.yaml
apiVersion: v1
kind: Secret
metadata:
  name: {{ include "my-application.fullname" . }}-secrets
type: Opaque
data:
  {{- range $key, $value := .Values.secrets }}
  {{ $key }}: {{ $value | b64enc }}
  {{- end }}

Функція range ітерує по maps та списках. Функція b64enc кодує значення в base64 для Kubernetes secrets. Оператори pipe зв'язують функції для трансформації даних.

Питання та Відповіді на Співбесідах про Helm Charts

Технічні співбесіди часто перевіряють знання Helm через концептуальні та практичні питання. Нижче наведено найпоширеніші теми.

Яка різниця між helm install та helm upgrade --install?

helm install створює новий реліз і завершується невдачею, якщо реліз вже існує. helm upgrade --install (з прапорцем --install) створює новий реліз, якщо його не існує, або оновлює його, якщо існує. CI/CD пайплайни зазвичай використовують helm upgrade --install для ідемпотентних розгортань.

Як передавати чутливі дані до Helm charts?

Існує три підходи: зовнішні менеджери секретів (Vault, AWS Secrets Manager), зашифровані файли values (SOPS, sealed-secrets) або Kubernetes secrets, створені поза Helm та референсовані в шаблонах. Уникайте зберігання секретів у відкритих файлах values.yaml, що комітяться в систему контролю версій.

Що таке Helm hooks і коли їх слід використовувати?

Hooks виконуються в певних точках життєвого циклу релізу: pre-install, post-install, pre-upgrade, post-upgrade, pre-delete, post-delete, pre-rollback, post-rollback та test. Типові застосування включають міграції баз даних перед оновленнями, надсилання сповіщень після розгортань або запуск інтеграційних тестів.

Як керувати версіонуванням чартів?

Поле version у Chart.yaml відстежує зміни чарту за допомогою семантичного версіонування. Поле appVersion відстежує версію розгорнутого додатку. Збільшуйте version для будь-якої модифікації чарту, навіть якщо версія додатку залишається незмінною.

Яке призначення .helmignore?

Подібно до .gitignore, .helmignore виключає файли з пакування чарту. Типові записи включають *.tgz (уникнення пакування попередніх збірок), .git/, документацію *.md, непотрібну під час виконання, та файли конфігурації CI.

Більше про підготовку до співбесід з Kubernetes можна дізнатися в модулях Kubernetes Основи та Kubernetes Просунутий на SharpSkill.

Висновок

Практичні висновки для роботи з Helm charts:

• Структуруйте чарти з чітким розділенням між метаданими Chart.yaml, значеннями за замовчуванням values.yaml та директорією templates, що містить маніфести Kubernetes
• Використовуйте допоміжні шаблони в _helpers.tpl для стандартизації найменування та міток для всіх ресурсів
• Керуйте залежностями через Chart.yaml з умовним увімкненням для конфігурацій, специфічних для середовища
• Тестуйте чарти за допомогою helm lint, helm template та helm install --dry-run перед розгортанням на production
• Відстежуйте релізи зі змістовними назвами та використовуйте прапорець --atomic для автоматичного відкату при невдалих оновленнях
• Зберігайте секрети в зовнішніх менеджерах замість відкритих файлів values