<p>I'm trying to configure a pod that can run in several nodes of my kubernetes cluster.</p>

<p>Depending on the node chosen to schedule/run the pod, the configuration needed by the pod is different.</p>

<p>For example, if the pod ends up running in node1, configuration value (e.g. a username to connect to some outside service) needs to be "user-node1".
If the same pod ends up running in node2, I need that configuration value to be different (e.g. "user-node2".</p>

<p>Ideally, my cluster/app configuration will be just one, where both user-node1 and user-node2 are present somewhere, and when my pod is scheduled to run in node1 or node2 then the appropriate configuration is passed to the pod (I'm trying to have the pod unaware of the fact there are multiple per-node configurations).</p>

<p>Is there any way to achieve this?</p>

user2987504
<p>It's quite specific scenario. You can try to use one of <a href="https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers" rel="nofollow noreferrer">Admission Controllers</a> - <a href="https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook" rel="nofollow noreferrer">MutatingAdmissionWebhook</a>.</p>
<blockquote>
<p>An admission controller is a piece of code that intercepts requests to the Kubernetes API server prior to persistence of the object, but after the request is authenticated and authorized. The controllers consist of the list below, are compiled into the kube-apiserver binary, and may only be configured by the cluster administrator. In that list, there are two special controllers: MutatingAdmissionWebhook and ValidatingAdmissionWebhook. These execute the mutating and validating (respectively) admission control webhooks which are configured in the API.</p>
</blockquote>
<blockquote>
<p>Admission controllers may be &quot;validating&quot;, &quot;mutating&quot;, or both. <strong>Mutating controllers may modify the objects they admit</strong></p>
</blockquote>
<p>In this option you would need to inject some <a href="https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/" rel="nofollow noreferrer">lables</a> or <a href="https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/" rel="nofollow noreferrer">annotations</a> to pod and then specify them also in your <a href="https://kubernetes.io/docs/concepts/configuration/configmap/" rel="nofollow noreferrer">configmap</a>.
This solution is used for example in <a href="https://istio.io/latest/docs/setup/additional-setup/sidecar-injection/" rel="nofollow noreferrer">Istio</a> and was mentioned in <a href="https://stackoverflow.com/questions/36690446/inject-node-labels-into-kubernetes-pod">this case</a>.</p>
<p>Another option is to create some kind of <code>Operator</code> which will monitor events in <code>namespaces</code> and will modify <code>pod</code>.</p>
<p>This solution would look like in <a href="https://banzaicloud.com/blog/pipeline-node-labelling/#node-pool-label-set-operator" rel="nofollow noreferrer">this article</a> but instead of monitoring <code>nodes</code> in <code>nodepool</code>, it would need to monitor <code>pods</code> in <code>namespaces</code>.</p>
