<p>I have a containerized daemon that I need to run one instance of for every <em>thing</em>. Each <em>thing</em> has a unique set of configs associated with it, but the container image is the same. The configs can be set simply as environment variables. I have a list of the configs, and I need to define the desired state as having exactly 1 pod running for each <em>thing</em>. <strong>What is the appropriate way to construct this in Kubernetes with or without Helm?</strong></p>

<p>My understanding is that ReplicaSets and Deployments work on identical containers, in other words they would all be spun up with the same environment variables? I understand that StatefulSet may be able to represent this, but the deamons do not need to hold state really, they do not need persistent storage, they can be killed at will, so long as another with the same configs comes up soon afterwards.</p>

<p>One clue I was given by somebody was to use Helmfile or Helm partials. That is the extent of what they told me. I have not yet investigated whether those are appropriate or not.</p>

d946fc96c0a12b31fe1b50046bfddc
<p>You are correct saying that Deployment and ReplicaSets are running on identical containers, so the way I see it you have 2 options:</p>

<p>Deploy multiple deployments with different configs defined in the values file:</p>

<ol>
<li><p>You can see an example <a href="https://github.com/sapcc/helm-charts/blob/master/openstack/limes/templates/collect-deployment.yaml" rel="nofollow noreferrer">here</a>, where multiple configs are set in the values file and using <a href="http://deploymentshttps://helm.sh/docs/chart_template_guide/control_structures/" rel="nofollow noreferrer">{{ range }}</a> to iterate and create multiple deployments</p></li>
<li><p>Iterate over you configurations names/files using scripting language of your choice and create separate release for each of your configuration via the command line for example: <code>--set configName=</code></p></li>
</ol>

<p>Personally, I would go with the 2nd option since multiple helm releases can harness the helm cli to better understand what is running and it's state. also, any CRUD action you would like to do would be less dangerous since the deployments are decoupled</p>
