Должен ли я использовать configMap для каждой переменной окружения?

Я использую штурвал прямо сейчас. Мой проект такой:

values.yaml:

environmentVariables:
  KEY1: VALUE1
  KEY2: VALUE2

configmap.yaml:

apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ template "myproject.fullname" . }}
data:
{{- range $k, $v := .Values.environmentVariables }}
  {{ $k }}: {{ $v | quote }}
{{- end }}

deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ template "myproject.fullname" . }}
spec:
  template:
    spec:
      containers:
        - name: {{ .Chart.Name }}
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
          imagePullPolicy: {{ .Values.image.pullPolicy }}
          env:
{{- range $k, $v := .Values.environmentVariables }}
            - name: {{ $k }}
              valueFrom:
                configMapKeyRef:
                  name: {{ template "myproject.fullname" $ }}
                  key: {{ $k }}
{{- end }}
...

Но сейчас я действительно в замешательстве. Мне действительно нужна эта конфигурационная карта? Есть ли польза от использования configmap для переменных окружения?


kubernetes kubernetes-helm
person yozel    schedule 27.11.2018    source источник

Ответы (3)


arrow_upward
10
arrow_downward

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

Тем не менее, это добавляет немного дополнительной сложности, и может быть большой элемент предпочтения относительно того, когда использовать ConfigMap. Поскольку ваши ключи ConfigMap - это имена переменных среды , вы можете немного упростить развертывание, используя envFrom

person Ryan Dawson    schedule 01.12.2018
comment
Я не знал, что существует envFrom. Я использую свою ConfigMap с другими модулями, и это отличный способ сделать это. Спасибо. - person yozel; 03.12.2018
comment
сделайте значения переменных доступными для других модулей или приложений, которые не обязательно являются частью вашей диаграммы, что не очень хорошо по соображениям безопасности. Если бы целью было совместное использование, то можно было бы создать отдельную диаграмму только с ConfigMap, которая будет использоваться всеми модулями. - person abbas; 08.06.2020

arrow_upward
6
arrow_downward

Это будет работать, даже если вы не используете configmap, но у него есть некоторые преимущества:

  • Вы можете обновить значения во время выполнения, не обновляя развертывание. Это означает, что вам может не понадобиться перезапускать приложение (поды). Если вы не используете карту конфигурации, каждый раз, когда вы обновляете значение, ваше приложение (или модуль) будет воссоздаваться.
  • Разделение проблем, т. Е. Разделение конфигурации развертывания и внешних значений
person Hazim    schedule 27.11.2018
comment
Я не думаю, что могу обновлять значения во время выполнения. Переменные среды в модуле не могут быть обновлены без перезапуска. Но разделение интересов - это хороший момент. - person yozel; 03.12.2018
comment
Релиз включает приложение и его конфигурацию. Если вы развертываете конфигурацию отдельно, как вы собираетесь отслеживать версии приложения и как при необходимости выполнять откат к предыдущему состоянию. - person abbas; 08.06.2020
comment
Это зависит от практики, которой вы следуете. Я заметил, что сейчас довольно часто случается, что простые изменения конфигурации не рассматриваются как часть выпуска. Да, в этом случае вам нужно будет отменить обе версии приложения и конфигурации, но процесс CI / CD может справиться с этим. - person Hazim; 08.06.2020

arrow_upward
3
arrow_downward

Я чувствую, что это во многом дело вкуса; но я обычно избегаю ConfigMaps для подобных случаев.

env:
{{- range $k, $v := .Values.environmentVariables }}
  - name: {{ quote $k }}
    value: {{ quote $v }}
{{- end }}

Обычно вам нужен единый источник правды, и Helm может быть таким: вы не хотите оказаться в ситуации, когда кто-то редактировал ConfigMap вне Helm, а повторное развертывание нарушает локальные изменения. Так что нет большого значения в том, что ConfigMap "более редактируемый", чем спецификация развертывания.

В принципе (как отмечает @Hazim) вы можете обновить содержимое ConfigMap без перезапуска контейнера, но это по сути не может обновлять переменные среды в запущенных контейнерах, а перезапуск контейнеров настолько рутинен, что выполнение этого один раз не имеет большого значения.

person David Maze    schedule 01.12.2018