<p>I'm looking for a way to mount configs based on label selector.</p>

<p>I will have new configmap's created over time, which I will label with "intendeedtarget"="MainApp".
The configs are created from json file, with filename as key.</p>

<p>E.g. a yml something like this (but working):</p>

<pre><code>    volumeMounts:
      - name: appconfigs
        mountPath: /appconfigs
  volumes:
  - name: appconfigs
    configMap:
      selector:
        matchLabels:
          intendeedtarget: MainApp
</code></pre>

<p>That is new configs will be auto mounted in the running pods for the "MainApp" over time.</p>

<p>I have already gotten it to mount individual configs as files in the running pods with:</p>

<pre><code>containers:
      - name: {{Name}}
        image: {{Image}}
        ports:
        - containerPort: 80
        volumeMounts:
          - name: appconfigs
            mountPath: /appconfigs
      volumes:
      - name: appconfigs
        configMap:
          name: {{ConfigName}}
</code></pre>

<p>This mounts the json applied to the configmap, as a separate file in the /appconfigs folder.</p>

<p>My goal now is to mount all configmaps with the label "intendeedtarget" = "MainApp" in /appconfigs.</p>

<p>Any suggestions?</p>

<p>A bonus question, does anyone know how to label a configmap as one command, i.e. when creating the configmap?</p>

<p>BR</p>

<p>So the short version is no, one cannot specify a whole range of volumeMounts, but there is a work-around available to you: <code>initContainers:</code></p>

<p>I believe it would work like this:</p>

<ol>
<li>The Pod would declare a <code>volume</code> of type <code>emptyDir</code>, named <code>appconfigs</code> <em>(just to make discussing it easy, the name isn't important)</em> mounted where you wish. It is of type <code>emptyDir</code> because we only care about having some shared disk space between the <code>initContainer</code> and the "main" <code>containers</code>, and that shared space should evaporate when the Pod does</li>
<li>The <code>initContainer</code> would either have a <code>kubectl</code> binary in it, or download one, or use one of the many, many kubernetes api client libraries, or even just a copy of <code>curl</code> in it

<ol>
<li>using the <code>ServiceAccount</code> token, it queries for the <code>ConfigMap</code>s of your choosing. It is absolutely possible to put the label criteria into an environment variable of the <code>initContainer</code>, or the <code>initContainer</code> can even use the metadata of its own Pod for introspection, if you prefer that</li>
<li>It extracts their payloads, massages them as you wish, and writes the files into the mount point of <code>appconfigs</code></li>
</ol></li>
<li>Now the <code>containers:</code> will start, but it will find the config files in the shared volume mount, just as you specified</li>
</ol>
