pass different configmap or env property to pod depending on which node it's running on

6/15/2020

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

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

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".

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).

Is there any way to achieve this?

-- user2987504
configuration
kubernetes

1 Answer

7/8/2020

It's quite specific scenario. You can try to use one of Admission Controllers - MutatingAdmissionWebhook.

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.

Admission controllers may be "validating", "mutating", or both. Mutating controllers may modify the objects they admit

In this option you would need to inject some lables or annotations to pod and then specify them also in your configmap. This solution is used for example in Istio and was mentioned in this case.

Another option is to create some kind of Operator which will monitor events in namespaces and will modify pod.

This solution would look like in this article but instead of monitoring nodes in nodepool, it would need to monitor pods in namespaces.

-- PjoterS
Source: StackOverflow