Можно ли подключить окружение в Helm?

Развернутый ответ: Подключение окружения в Helm

Да, безусловно можно и нужно подключать окружение (environment) в Helm, и это одна из ключевых возможностей, делающих Helm мощным инструментом управления жизненным циклом приложений в Kubernetes. Под "окружением" обычно понимается набор специфичных конфигураций для разных стадий развертывания: разработка (development), тестирование (staging), производство (production).

Helm реализует эту идеологию через несколько основных механизмов, которые можно комбинировать.

Основные механизмы работы с окружениями в Helm

1. Использование разных values файлов

Стандартный и наиболее распространенный подход. Вы создаете базовый файл values.yaml с конфигурацией по умолчанию и переопределяете его для каждого окружения отдельными файлами (например, values-dev.yaml, values-staging.yaml, values-prod.yaml).

# Установка чарта с конфигурацией для production
helm install my-app ./my-chart -f values-prod.yaml

# Обновление релиза с staging конфигурацией
helm upgrade my-app ./my-chart -f values-staging.yaml

Структура values-файлов может выглядеть так:

# values-prod.yaml
replicaCount: 5
resources:
  requests:
    memory: "512Mi"
    cpu: "250m"
  limits:
    memory: "1Gi"
    cpu: "500m"
autoscaling:
  enabled: true
image:
  tag: "stable-v1.2.3"
database:
  host: "prod-db-cluster.example.com"

# values-dev.yaml
replicaCount: 1
resources:
  requests:
    memory: "128Mi"
    cpu: "100m"
autoscaling:
  enabled: false
image:
  tag: "latest"
database:
  host: "localhost"

2. Использование глобальных переменных и функции tpl

В шаблонах (templates/) вы можете использовать переменные окружения ОС или динамически генерировать конфигурации с помощью функции tpl.

# В шаблоне deployment.yaml можно сослаться на values
env:
  - name: "APP_ENVIRONMENT"
    value: "{{ .Values.environment }}"
  - name: "DB_HOST"
    value: "{{ .Values.database.host }}"
  - name: "EXTERNAL_API_KEY"
    value: "{{ .Values.externalApiKey | default (env "API_KEY") }}" # Использование переменной среды ОС

3. Каскадное переопределение values

Helm позволяет применять несколько файлов values, и их порядок важен. Последний указанный файл имеет наивысший приоритет. Это позволяет создавать сложные цепочки наследования.

# Сначала применяются дефолтные values.yaml, затем base.yaml, и поверх них prod-overrides.yaml
helm install my-app ./my-chart -f values.yaml -f base.yaml -f prod-overrides.yaml

4. Использование --set и --set-file для динамических параметров

Для передачи чувствительных данных или динамических значений прямо из командной строки CI/CD пайплайна.

helm upgrade my-app ./my-chart \
  -f values-prod.yaml \
  --set image.tag=$CI_COMMIT_SHA \
  --set database.password=$DB_PROD_PASSWORD

5. Создание отдельных Helm Release для каждого окружения

Лучшая практика — устанавливать один и тот же чарт под разными именами релизов в разные неймспейсы Kubernetes, что полностью изолирует окружения.

# Установка в namespace "dev"
helm install my-app-dev ./my-chart -f values-dev.yaml --namespace dev
# Установка в namespace "prod"
helm install my-app-prod ./my-chart -f values-prod.yaml --namespace prod

Расширенные практики и инструменты

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

  # helmfile.yaml
  releases:
    - name: my-app
      namespace: {{ .Environment.Name }}
      chart: ./charts/my-app
      values:
        - "values-{{ .Environment.Name }}.yaml"
  

• Плейсхолдеры в именах ресурсов: Динамическое именование ресурсов в зависимости от окружения внутри шаблонов.

  # В шаблоне
  name: {{ printf "%s-%s" .Release.Name .Chart.Name | trunc 63 }}
  

• Условные логические конструкции в шаблонах: Использование if/else для включения или отключения функциональности.

  {{- if .Values.autoscaling.enabled }}
  apiVersion: autoscaling/v2
  kind: HorizontalPodAutoscaler
  ...
  {{- end }}
  

Вывод

Helm не просто "можно" подключить к окружению, он для этого и создан. Его философия строится на разделении шаблона приложения (Chart) и конфигурации окружения (Values). Комбинируя values-файлы, пространства имен, функции шаблонов и флаги командной строки, вы достигаете полного контроля над конфигурацией приложения в любом окружении, соблюдая принципы Infrastructure as Code (IaC) и GitOps. Ключ к успеху — четкая структура values-файлов и понимание порядка их применения.