Advantage of using configmaps for environment variables with Kubernetes/Helm

4
votes

When creating deployments, I am currently trying to find a reason why one should externalize the environment variables for a container into a configmap. So instead of defining environment variables with 

    env:
    - name: LANGUAGE
      value: "English"

in the deployment.yaml use

    env:
    - name: LANGUAGE
      valueFrom:
        configMapKeyRef:
          name: language
          key: LANGUAGE

or 

      envFrom:
      - configMapRef:
          name: env-configmap

with an additional configmap.yaml like so: 

apiVersion: v1
kind: ConfigMap
metadata:
  name: env-configmap
data:
  LANGUAGE: English

Of course, when using confidential values, they should be read from a secret, but that does not apply to non-confidential variables. The only advantage I see is that I can reuse these configmaps, but apart from that it only makes the chart more complicated as I now have to ensure that the pods are restarted etc...

So: What are other advantages when using ConfigMaps to read the environment variables?

2
kuberneteskubernetes-helm

2 Answers

4
votes

As you point out, you can re-use the ConfigMap so that other parts of your chart can easily re-use the same environment variables. How useful this is can depend on how many variables you have and how many places they are used in.

A ConfigMap is also available as an Object in the cluster that other Pods can make use of, including ones that are not part of your chart. This could mean your configmap getting referenced by other apps getting installed in the same cluster, or it could be that you choose to publish your chart and then it might get packaged as a dependency within another chart. If your chart is to be used as a dependency in another chart then it makes things a bit easier/cleaner for the chart that is building on top of yours to reference parts of your configuration from a ConfigMap. So the usefulness can also depend on how you intend your chart to be used. The official charts use a lot of ConfigMaps but they do sometimes use environment variables directly and they use ConfigMaps in a variety of ways for different purposes.

3
votes

By using configmap you're separating the configs from the pod definition. 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.

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.

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 can use the envForm to simplyfy your deployment as shown here