K
Q

Advantage of using configmaps for environment variables with Kubernetes/Helm

12/6/2018

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?

-- joz
kubernetes
kubernetes-helm

Similar Questions

GKE Ingress controller multipath
Why does Grafana return different values for a counter metric on different ranges
Setting up Kubernetes - API not reachable from Pods
How can I get the number of running pods for an app using Python Kubernetes Package

2 Answers

12/6/2018

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.

-- Ryan Dawson
Source: StackOverflow
12/6/2018

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

-- Prafull Ladha
Source: StackOverflow