<p>I have different sets of <code>environment</code> variables per deployment/microservice and <code>vaule</code> for each environment (dev/test/qa) are different.</p>
<p>Do I need <code>overlay</code> file for each deployment/microservice against each environment (dev/test/qa) or I can managed with single overlay per environment?</p>
<p>Deployment - <code>app-1.yaml</code>:</p>
<pre><code>apiVersion: apps/v1
kind: Deployment
metadata:
  name: example-1
spec:
  template:
    spec:
      containers:
        - name: example-1
        image: example:1.0
        env:
          -Name: &quot;A1&quot;
          -Value: &quot;B1&quot;
        env:
          -Name: &quot;D1&quot;
          -Value: &quot;E1&quot;
</code></pre>
<p>Deployment - <code>app-2.yaml</code>:</p>
<pre><code>apiVersion: apps/v1
kind: Deployment
metadata:
  name: example-2
spec:
  template:
    spec:
      containers:
        - name: example-2
        image: example:2.0
        env:
          -Name: &quot;X1&quot;
          -Value: &quot;Y1&quot;
        env:
          -Name: &quot;P1&quot;
          -Value: &quot;Q1&quot;
</code></pre>

<p>You can keep everything inside the single YAML file and divide the YAML as per need.</p>
<p>you can use the <code>---</code> to merge the YAML configuration files in one file like the below in the example.</p>
<p>In a single YAML file, you can add everything Secret, deployment, service and etc as per requirement.</p>
<p>However if for each environment you have a different cluster to manage then applying the single YAML file might create the issues, in that case, it's better to keep the files separate.</p>
<p>If you are planning to set up the CI/CD and automation for deployment i would suggest keeping the single deployment file with a variable approach.</p>
<pre><code>apiVersion: apps/v1
kind: Deployment
metadata:
  name: DEPLOYMENT_NAME
spec:
  template:
    spec:
      containers:
        - name: example-2
        image: IMAGE_NAME
        env:
          -Name: &quot;A1&quot;
          -Value: &quot;B1&quot;
</code></pre>
<p>using the ubuntu <code>sed</code> command you have to run time to replace the values of <code>IMAGE_NAME</code>, <code>DEPLOYMENT_NAME</code> and <code>A1</code> etc based on the environment and as soon as your file get ready you can apply from the CI/CD server</p>
<p>Single merged file :</p>
<p><strong>deployment.yaml</strong></p>
<pre><code>apiVersion: apps/v1
kind: Deployment
metadata:
  name: example-1
spec:
  template:
    spec:
      containers:
        - name: example-1
        image: example:1.0
        env:
          -Name: &quot;A1&quot;
          -Value: &quot;B1&quot;
        env:
          -Name: &quot;D1&quot;
          -Value: &quot;E1&quot;
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: example-2
spec:
  template:
    spec:
      containers:
        - name: example-2
        image: example:2.0
        env:
          -Name: &quot;X1&quot;
          -Value: &quot;Y1&quot;
        env:
          -Name: &quot;P1&quot;
          -Value: &quot;Q1&quot;
</code></pre>
<p><strong>EDIT</strong></p>
<p>If managing the environment is the only case you can also use the <strong>secret</strong> or <strong>configmap</strong> to manage the environment variables.</p>
<p><strong>secret.yaml</strong></p>
<pre><code>apiVersion: v1
kind: Secret
metadata:
  name: dev-env-sample
  annotations:
    kubernetes.io/service-account.name: &quot;sa-name&quot;
type: kubernetes.io/service-account-token
data:
  extra: YmFyCg==
  A1 : B1
  D1 : E1
</code></pre>
<p>this is a single secret file storing all the Dev environment variables.</p>
<p>inject all variables to the Dev deployment, add the below config to the deployment file so all your variables inside that <code>config map</code> or <code>secret</code> will get injected into the deployment.</p>
<pre><code>envFrom:
        - SecretRef:
            name: dev-env-sample
</code></pre>
<p><a href="https://kubernetes.io/docs/concepts/configuration/secret/" rel="nofollow noreferrer">https://kubernetes.io/docs/concepts/configuration/secret/</a></p>
<p><strong>configmap.yaml</strong></p>
<pre><code>kind: ConfigMap 
apiVersion: v1 
metadata:
  name: dev-configmap 
data:
  extra: YmFyCg==
  A1 : B1
  D1 : E1
</code></pre>
<p>and you can inject the configmap to deployment using the</p>
<pre><code>envFrom:
            - configMapRef:
                name: dev-configmap 
</code></pre>
<p>The difference between <strong>secret</strong> and <strong>configmap</strong> is that secret save the data in <strong>base64</strong> encoded format while configmap save in plain text.</p>
<p>You can also merge the multiple <code>secrets</code> or <code>config map</code> in single YAML file</p>
<pre><code>apiVersion: v1
    kind: Secret
    metadata:
      name: dev-env-sample
      annotations:
        kubernetes.io/service-account.name: &quot;sa-name&quot;
    type: kubernetes.io/service-account-token
    data:
      extra: YmFyCg==
      A1 : B1
      D1 : E1
---
apiVersion: v1
    kind: Secret
    metadata:
      name: stag-env-sample
      annotations:
        kubernetes.io/service-account.name: &quot;sa-name&quot;
    type: kubernetes.io/service-account-token
    data:
      extra: YmFyCg==
      A1 : B1
      D1 : E1
---
apiVersion: v1
    kind: Secret
    metadata:
      name: prod-env-sample
      annotations:
        kubernetes.io/service-account.name: &quot;sa-name&quot;
    type: kubernetes.io/service-account-token
    data:
      extra: YmFyCg==
      A1 : B1
      D1 : E1
</code></pre>
<p>inject the <strong>secret</strong> into deployment as per need per environment.</p>
<p><code>dev-env-sample</code> can be added in to the deployment file for <strong>dev</strong> environment.</p>
