<p>I have my microservice and ConfigMap deployed in cluster.</p>
<p>I have a need to update the value of variable defined in <code>ConfigMap</code> object on the fly. I can re-start the microservice programmatically (like re-create the service pod). The main thing is to keep the <code>ConfigMap</code> object in the cluster and only update the value in it.</p>
<p>My current idea is to define env variables in an external file:</p>
<pre><code>key1: foo
key2: bar
</code></pre>
<p>and in ConfigMap manifest mount the file:</p>
<pre><code>spec:
  containers:
    image: ...
    volumeMounts:
    - mountPath: /clusters-config
      name: config-volume
  volumes:
    - configMap:
        name: my-env-file
      name: config-volume
</code></pre>
<p>I wonder if using this approach, what is the main pitfalls/cons I should consider?</p>
<p>Is there an better option/solution if not using the volume mounted <code>ConfigMap</code> but keep variables inside ConfigMap manifest?</p>

user842225
<p><strong>4 ways</strong> that you can use a <code>ConfigMap</code> to configure a container inside a Pod:</p>
<ol>
<li>Inside a container command and args</li>
<li>Environment variables for a container</li>
<li>Add a file in read-only volume, for the application to read</li>
<li>Write code to run inside the Pod that uses the Kubernetes API to read a ConfigMap</li>
</ol>
<p>===========================================================</p>
<p>You choose the <strong>3rd way</strong>. As to your questions:</p>
<blockquote>
<p>I wonder if using this approach, what is the main pitfalls/cons I should consider?</p>
</blockquote>
<p>One possible pitfall: When a <code>ConfigMap</code> currently consumed in a volume is updated, projected keys are eventually updated as well. This means that your <strong>external file containing the variables will be eventually updated in the container</strong>. However, the total delay varies for different kubelet configuration, which may affect application supporting hot reloading(reloading the config file on the fly). <em>If you always re-create new pods after modifying the <code>ConfigMap</code>, the pitfall does not exist.</em></p>
<blockquote>
<p>Is there an better option/solution if not using the volume mounted ConfigMap but keep variables inside ConfigMap manifest?</p>
</blockquote>
<p>Yes, use the <strong>1st or 2nd approach</strong>, like the example below:</p>
<pre class="lang-yaml prettyprint-override"><code>apiVersion: v1
kind: ConfigMap
metadata:
  name: game-demo
data:
  # property-like keys; each key maps to a simple value
  key1: &quot;foo&quot;
  key2: &quot;bar&quot;
---
apiVersion: v1
kind: Pod
metadata:
  name: configmap-demo-pod
spec:
  containers:
  - name: demo
    image: alpine
    command: [&quot;sleep&quot;, &quot;3600&quot;]
    env:
    # Define the environment variable
    - name: ENV_KEY1  # Notice that the case is different here
                      # from the key name in the ConfigMap.
      valueFrom:
        configMapKeyRef:
          name: game-demo  # The ConfigMap this value comes from.
          key: key1  # The key to fetch.
    - name: ENV_KEY2
      valueFrom:
        configMapKeyRef:
          name: game-demo
          key: key2
</code></pre>
<p><strong>Note</strong>: ConfigMaps consumed as environment variables are not updated automatically and require a pod restart.</p>
