<p>Trying to decide where to store some critical sharding configs, and I have not yet found sufficient documentation around the reliability of Kube ConfigMaps to ease my mind.</p>

<p>Say I have a single-cluster kube pod spec that injects an environment variable with the value of a configmap entry at pod start (using <a href="https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/#define-container-environment-variables-using-configmap-data" rel="nofollow noreferrer">configMapKeyRef</a>). I have many pods running based on this spec.</p>

<ol>
<li>I <code>kubectl edit</code> the configmap entry and wait for the operation to succeed.</li>
<li>I restart the pods.</li>
</ol>

<p>Are these pods guaranteed to see the new configmap value? (Or, failing that, is there a window of time I'd need to wait before restarting the pods to ensure that they get the new value?)</p>

<p>Similarly, are all pods guaranteed to see a consistent value, assuming there are no configmap edits during the time they are all restarting?</p>

<p>Kubernetes is an eventual consistency system. It is <a href="https://github.com/kubernetes-sigs/kustomize/blob/master/examples/configGeneration.md" rel="nofollow noreferrer">recommended</a> to <em>create a new ConfigMap</em> when you want to change the value.</p>
<blockquote>
<p>Changing the data held by a live configMap in a cluster is considered bad practice. Deployments have no means to know that the configMaps they refer to have changed, so such updates have no effect.</p>
</blockquote>
<p>Using <a href="https://kubernetes.io/docs/tasks/manage-kubernetes-objects/kustomization/" rel="nofollow noreferrer">Declarative config management with Kustomize</a>, this is easier to do using <a href="https://kubernetes.io/docs/tasks/manage-kubernetes-objects/kustomization/#configmapgenerator" rel="nofollow noreferrer">configMapGenerator</a></p>
<blockquote>
<p>The recommended way to change a deployment's configuration is to</p>
<ol>
<li>create a new configMap with a new name,</li>
<li>patch the deployment, modifying the name value of the appropriate configMapKeyRef field.</li>
</ol>
</blockquote>
<p><strong>Deployment</strong></p>
<p>When using Kustomize for both <code>Deployment</code> and <code>ConfigMap</code> using the <em>configMapGenerator</em> the name of <code>ConfigMap</code> will be generated based on content and the references to the <code>ConfigMap</code> in <code>Deployment</code> will be updated with the generated name, so that a new <em>rolling deployment</em> will be triggered.</p>
