<p>I'm confused about why we use configMap versions. I'm seeing multiple versions of confimap in my k8s cluster that is attached to a deployment/sts. I was expecting if I apply some changes in my yaml it will get reflected in all of the configMap versions, but that is not happening. Can someone help with this.</p>
<p>I don't have any <code>subdir</code> in configmap.</p>
<p>Do you know much time for reflecting these changes in the mounted volumes? or what I'm missing here</p>
<p>example configmap output</p>
<pre><code>NAME                          DATA   AGE
ca-bundles                    4      3d17h
c-rules-alerts            1      3d17h
c-rules-alerts-v000       1      3d16h
c-rules-alerts-v001       1      50m
c-rules-metrics           1      3d17h
c-rules-metrics-v000      1      3d16h
c-rules-metrics-v001      1      50m
c-alertmanager        1      3d17h
c-alertmanager-v000   1      3d16h
c-server              3      3d17h
c-server-v000         3      3d16h
</code></pre>
<p>here is the mount config</p>
<pre><code>          volumeMounts:

            - name: config-metric-volume
              mountPath: /oracle_exporter
      volumes:
        - name: data-volume
          emptyDir:
            sizeLimit: 2Gi
        - name: config-metric-volume
          configMap:
            name: chron-rules-metrics
</code></pre>

<p>Kubernetes provides a way to store rollout information for some resources by default, one of those is deployments.</p>
<p>You can perform some commands providing a <code>--record</code> flag, which will record the current and new state of the deployment, allowing you to perform a <code>rollback</code></p>
<p>See <a href="https://stackoverflow.com/questions/62831410/usage-of-record-in-kubectl-imperative-commands-in-kubernetes">this answer</a> for more details</p>
<p>Other resources, don't have that feature and tools like <a href="https://helm.sh/docs/" rel="nofollow noreferrer">helm</a> and <a href="https://carvel.dev/kapp/" rel="nofollow noreferrer">kapp</a> create versions of the resources to allow you to rollback the deployment/statefulset/etc along with all of its related resources like secrets, configmaps, ingresses, etc.</p>
<p>Some tools store that information in annotations, others create a naming duplicate the current resource with a suffix following a convention.</p>
<hr />
<p>So, with that out of the way, we can talk about seeing the changes reflected on your deployments.</p>
<p>By default, again, if you change anything in a deployment(sts, ds, etc) spec that impacts the pods, kuberntes will trigger a rollout and will recreate all the pods to reflect the new spec.</p>
<p>That doesn't happen when you update secrets and config maps that are mapped to pods. There are arguments in favor and against that behaviour, some think that is useful, some think that this might lead to some huge chain reactions in the cluster.</p>
<p>Regardless of where this discussion ends, this is the behaviour today.</p>
<p>To see config map or secrets changes reflected on the pods, you must trigger a restart.</p>
<p><code>kubectl rollout restart deployment/my-awesome-app</code></p>
