<p>You have a collection of pods that all run the same application, but with slightly different configuration. Applying the configuration at run -time would also be desirable. What's the best way to achieve this?</p>
<p>a: Create a separate container image for each version of the application, each with a different configuration</p>
<p>b: Use a single container image, but create ConfigMap objects for the different Configurations and apply them to the different pods</p>
<p>c: Create persistent Volumes that contain each config files and mount then to different pods</p>

user16350039
<p>In my opinion, the best solution for this would be &quot;b&quot; to use ConfigMaps.
Apply changes to the ConfigMap and <strong>redeploy</strong> the image/pod. I use this approach very often at work.</p>
<p>Edit from @AndD: [...] ConfigMaps can contain small files and as such can be mounted as read only volumes instead of giving environment variables. So they can be used also instead of option c in case files are required.</p>
<p>My favorite command for this</p>
<pre><code>kubectl patch deployment &lt;DEPLOYMENT&gt; -p &quot;{\&quot;spec\&quot;: {\&quot;template\&quot;: {\&quot;metadata\&quot;: { \&quot;labels\&quot;: {  \&quot;redeploy\&quot;: \&quot;$(date +%s)\&quot;}}}}}&quot;
</code></pre>
<p>Patches a redeploy date to now in spec.template.metadata.labels.redeploy -&gt; date +%s</p>
<p>Option &quot;a&quot; seems to be evenly good, the downside is you have to build the new Image, push it, deploy it. You could build a Jenkins/GitLab/whatever Pipeline to automate this way. But, I think ConfigMaps are fairly easier and are more &quot;manageable&quot;. This approach is viable if you have very very many config files, which would be too much work to implement in ConfigMaps.</p>
<p>Option &quot;c&quot; feels a bit too clunky just for config files. Just my two cents. Best Practice is to not store config files in volumes. As you (often) want your Applications to be as &quot;stateless&quot; as possible.</p>
