Using Pod fields as values for environment variables about workflow HOT 8 OPEN

From @bacongobbler on March 6, 2017 15:27

It is not possible to reference the downward API today with pods. However, you can infer the pod namespace by the application name, which is available in the environment. The pod IP and others are currently unavailable, however we've generally pushed back on that due to concerns of exposing the cluster to the application developer (most multi-tenant systems like Heroku do not give you host information, for example).

If you'd like to take a tackle at this, you probably will want to make a proposal or write documentation that comes up with a couple use cases for this as well as how it'd look in the CLI, then write a PR against that doc.

Hope this helps!

from workflow.

From @gottfrois on March 6, 2017 15:45

thanks @bacongobbler for the quick answer. Being able to know POD IP as well as the host the POD is running on might be valuable information in order to force services communication to go through a service mesh running as a DaemonSet on the same host the POD is running.

I'm using linkerd to abstract services communication and the way it is setup is by having all http requests proxy through the linkerd instance running on the same host as the POD.

Here is the k8s POD configuration:

env:
- name: NODE_NAME
  valueFrom:
    fieldRef:
      fieldPath: spec.nodeName
- name: POD_IP
  valueFrom:
    fieldRef:
      fieldPath: status.podIP
- name: http_proxy
  value: $(NODE_NAME):4140

The POD_IP is really just to ensure load balancing is working while testing my setup but the NODE_NAME is used to make sure we proxy http requests through the local instance of linkerd.

Hope it helps to understand the usecase better.
Do you see any workaround for the moment?

from workflow.

From @gottfrois on March 6, 2017 16:2

The workaround I see is to manually query the k8s api within the POD using the following command:

$ KUBE_TOKEN=$(< /var/run/secrets/kubernetes.io/serviceaccount/token)
$ curl -sk -H "Authorization: Bearer $KUBE_TOKEN" https://$KUBERNETES_SERVICE_HOST:$KUBERNETES_SERVICE_PORT/api/v1/namespaces/default/pods/$HOSTNAME | jq '.status.hostIP' | sed 's/"//g'
10.240.0.5

from workflow.

From @gottfrois on March 6, 2017 16:13

It would then be possible to execute a bash script to populate the HTTP_PROXY env variable:

command:
- "/bin/bash"
- "-c"
- "HTTP_PROXY=`./hostIP.sh`:4140 ..."

but is there a way to execute arbitraty commands on deis? Maybe in the Procfile directly!?

web: HTTP_PROXY=`./hostIP.sh`:4140 bundle exec puma -C config/puma.rb

from workflow.

From @robholland on March 29, 2017 8:51

@gottfrois Could you not have your config/puma.rb set the variable?

from workflow.

From @gottfrois on March 29, 2017 10:4

using a shell script called from the procfile worked, i guess it could be done in puma config as well yes

from workflow.

I'm guessing this could also be accomplished using a webhook and a MutatingWebhookConfiguration. I'm currently experimenting with that approach.

from workflow.

Let us know if you figure out a more elegant way @lshemesh ! 👍 There is also the lifecyclehooks as we talked about which are there but not really documented anywhere yet.

from workflow.