<p>A Usecase where one of the service must be scaled to 10 pods.</p>

<p>BUT, <strong>one of the pod must have different env variables</strong>. (kind of doing certain actions like DB actions and triggers handling, don't want 10 triggers to be handled instead of 1 DB change), for example 9 pods have  env variable  CHANGE=0  but one of the pod has env variable CHANGE=1</p>

<p>Also i am resolving by service name, so changing service name is not what i am looking for.</p>

shrw
<p>The easiest way to do what you describe is to have two separate Services.  One attaches to any "web" pod:</p>

<pre><code>apiVersion: v1
kind: Service
metadata:
  name: myapp-web
spec:
  selector:
    app: myapp
    tier: web
</code></pre>

<p>The second attaches to only the master pod(s):</p>

<pre><code>apiVersion: v1
kind: Service
metadata:
  name: myapp-master
spec:
  selector:
    app: myapp
    tier: web
    role: master
</code></pre>

<p>Then have two separate Deployments.  One has the single master pod, and one replica; the other has nine server pods.  Your administrative requests go to <code>myapp-master</code> but general requests go to <code>myapp-web</code>.</p>

<p>As @omricoco <a href="https://stackoverflow.com/a/61769574/10008173">suggests</a> you can come up with a couple of ways to restructure this.  A job queue like RabbitMQ will have the property that each job is done once (with retries if a job fails), so one setup is to run a queue like this, allow any server to accept administrative requests, but have their behavior just be to write a job into the queue.  Then you can run a worker process (or several) to service these.</p>
