<p>Based on <a href="https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/" rel="noreferrer">this</a> it is possible to create environment variables that are the same across all the pods of the deployment that you define.</p>

<p>Is there a way to instruct Kubernetes deployment to create pods that have different environment variables?</p>

<p>Use case:</p>

<p>Let's say that I have a monitoring container and i want to create 4 replicas of it. This container has a service that is mailing if an environment variables defines so. Eg, if the env var IS_MASTER is true, then the service proceeds to send those e-mails.</p>

<pre><code>apiVersion: v1
kind: Deployment
metadata:
  ...
spec:
  ...
  replicas: 4
  ...
  template:
    ...
    spec:
      containers:
      -env: 
        -name: IS_MASTER
         value: &lt;------------- True only in one of the replicas
</code></pre>

<p>(In my case I'm using helm, but the same thing can be without helm as well)</p>

<p>What you are looking for is, as far as I know, more like an anti-pattern than impossible.</p>

<p>From what I understand, you seem to be looking to deploy a scalable/HA monitoring platform that wouldn't mail X times on alerts, so you can either make a sidecar container that will talk to its siblings and "elect" the master-mailer (a StatefulSet will make it easier in this case), or just separate the mailer from the monitoring and make them talk to each other through a Service. That would allow you to load-balance both monitoring and mailing separately.</p>

<pre><code>monitoring-1 \                 / mailer-1
monitoring-2 --- &gt; mailer.svc -- mailer-2
monitoring-3 /                 \ mailer-3
</code></pre>

<p>Any mailing request will be handled by one and only one mailer from the pool, but that's assuming your Monitoring Pods aren't all triggered together on alerts... If that's not the case, then regardless of your "master" election for the mailer, you will have to tackle that first.</p>

<p>And by tackling that first I mean adding a master-election logic to your monitoring platform, to orchestrate master fail-overs on events, there are a few ways to do so, but it really depends on what your monitoring platform is and can do...</p>

<p>Although, if your replicas are just there to extend compute power somehow and your master is expected to be static, then simply use a StatefulSet, and add a one liner at runtime doing <code>if hostname == $statefulset-name-0 then MASTER</code>, but I feel like it's not the best idea.</p>
