K
Q

Should I use configMap for every environment variable?

11/27/2018

I am using helm right now. My project is like that:

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 }}
...

But right now, I'm really confused. Am I really need this configmap? Is there any benefit to use configmap for environment variables?

-- yozel
kubernetes
kubernetes-helm

Similar Questions

Schema Registry on Kubernetes, publicly accesible
eks worker node public ip assignment
Why do pods remain in 'pending' status?
Cannot configure context/ get kubectl working on node01 at Katacoda playground
K8s deployment error: `selector` does not match template `labels`
Ingress for ECK Kibana

3 Answers

12/1/2018

Aside from the points about separation of config from pods, one advantage of a ConfigMap is it lets you make the values of the variables accessible to other Pods or apps that are not necessarily part of your chart.

It does add a little extra complexity though and there can be a large element of preference about when to use a ConfigMap. Since your ConfigMap keys are the names of the environment variables you could simplify your Deployment a little by using 'envFrom'

-- Ryan Dawson
Source: StackOverflow
11/27/2018

It would work even if you don't use a configmap, but it has some advantages:

  • You can update the values at runtime, without updating a deployment. Which means you might not need to restart your application (pods). If you don't use a config map, everytime you update the value, your application (or pod) will be recreated.
  • Separation of concerns, i.e. deployment configuration and external values separated
-- Hazim
Source: StackOverflow
12/1/2018

I feel like this is largely a matter of taste; but I've generally been avoiding ConfigMaps for cases like these.

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

You generally want a single source of truth and Helm can be that: you don't want to be in a situation where someone has edited a ConfigMap outside of Helm and a redeployment breaks local changes. So there's not a lot of value in a ConfigMap being "more editable" than a Deployment spec.

In principle (as @Hazim notes) you can update a ConfigMap contents without restarting a container, but that intrinsically can't update environment variables in running containers, and restarting containers is so routine that doing it once shouldn't matter much.

-- David Maze
Source: StackOverflow