<p>I have a situation where i have an application for which i would like to run several set of instances configured differently. I guess from readying online, people would usually having several version of the same application in your clusters.</p>
<p>But let me somewhat describe the use case at the high level. The application is a component that takes as configuration a a dataset and a set of instructions stating how to process the dataset. The dataset is actually a datasource.</p>
<p>So in the same namespace, we would like for instance process 2 dataset.</p>
<p>So it is like having two deployments for the same application. Each dataset has different requirements, hence we should be able to have deployment1 scale to 10 instance and deployement 2 scale to 5 instance.</p>
<p>The thing is it is the same application and so far it is the same helm chart, and deployment definition.</p>
<p>The question is what are the different options that exist to handle that at this time.</p>
<p>examples, pointers, article are welcome.</p>
<p>So far i found the following article as the most promising:</p>
<p><a href="https://itnext.io/support-multiple-versions-of-a-service-in-kubernetes-using-helm-ce26adcb516d" rel="nofollow noreferrer">https://itnext.io/support-multiple-versions-of-a-service-in-kubernetes-using-helm-ce26adcb516d</a></p>
<p>Another thing i though about is duplicating the deployment chart into 2 sub-charts of which the folder name differ.</p>

<p>Helm supports this pretty straightforwardly.</p>
<p>In Helm terminology, you would write a <em>chart</em> that describes how to install one copy of your application.  This creates Kubernetes Deployments and other manifests; but it has templating that allows parts of the application to be filled in at deploy time.  One copy of the installation is a <em>release</em>, but you can have multiple releases, in the same or different Kubernetes namespaces.</p>
<p>For example, say you have a YAML template for a Kubernetes deployment:</p>
<pre class="lang-yaml prettyprint-override"><code>apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Release.Name }}-processor
spec:
  replicas: {{ .Values.replicas }}
  template:
    spec:
      containers:
        - env:
            - name: DATASET_NAME
              value: {{ .Values.dataset }}
          # and the other things that usually go into a container spec
</code></pre>
<p>When you go to deploy this, you can create a <em>values file</em>:</p>
<pre class="lang-yaml prettyprint-override"><code># a.yaml
replicas: 10
dataset: dataset-1
</code></pre>
<p>And you can deploy it:</p>
<pre class="lang-sh prettyprint-override"><code>helm install \
  one        \ # release name
  .          \ # chart location
  -f a.yaml    # additional values to use
</code></pre>
<p>If you use <code>kubectl get deployment</code>, you will see <code>one-processor</code>, and if you look at it in detail, you will see it has 10 replicas and its environment variable is set to <code>dataset-1</code>.</p>
<p>You can create a second deployment with different settings in the same namespace:</p>
<pre class="lang-yaml prettyprint-override"><code># b.yaml
replicas: 5
dataset: dataset-2
</code></pre>
<pre class="lang-sh prettyprint-override"><code>helm install two . -f b.yaml
</code></pre>
<p>Or in a different namespace:</p>
<pre class="lang-sh prettyprint-override"><code>helm install three . -n other-namespace -f c.yaml
</code></pre>
<p>It's theoretically possible to have a chart that only installs other subcharts (an <em>umbrella chart</em>), but there are some practical issues with it, most notably that Helm will want to install only one copy of a given chart no matter where it appears in the chart hierarchy.  There are other higher-level tools like <a href="https://github.com/Praqma/helmsman" rel="noreferrer">Helmsman</a> and <a href="https://github.com/roboll/helmfile" rel="noreferrer">Helmfile</a> that would allow you to basically describe these multiple <code>helm install</code> commands in a single file.</p>
