[Question] Is it possible to expose k8s pod information to deployed functions?

vojtechtoman commented 3 years ago

Expected Behaviour

I work at BRYTER where we use OpenFaaS as part of our integrations platform (3rd-party integrations are operated as OpenFaaS functions). We are using Datadog APM for distributed tracing and application monitoring in our product and we would like to enable the same for our (OpenFaaS-based) integrations. The Datadog documentation suggests that we need to 'configure application pods to pull the host IP in order to communicate with the Datadog Agent', namely point the DD_AGENT_HOST environment variable to status.hostIP, like in the following example:

apiVersion: apps/v1
kind: Deployment
 # ...
    spec:
      containers:
      - name: "<CONTAINER_NAME>"
        image: "<CONTAINER_IMAGE>"/"<TAG>"
        env:
          - name: DD_AGENT_HOST
            valueFrom:
              fieldRef:
                fieldPath: status.hostIP

Is there a way, at function deploy time, to achieve something similar to the above?

Current Behaviour

Are you a GitHub Sponsor (Yes/No?)

Check at: https://github.com/sponsors/openfaas

[ ] Yes
[x] No

List All Possible Solutions and Workarounds

Which Solution Do You Recommend?

Steps to Reproduce (for bugs)

Context

See the description above.

Your Environment

FaaS-CLI version ( Full output from: faas-cli version ):
Docker version docker version (e.g. Docker 17.0.05 ):
What version and distribution of Kubernetes are you using? kubectl version: v1.21.2-eks-0389ca3, faas-netes 0.13.5, faas 0.21.1
Operating System and version (e.g. Linux, Windows, MacOS):
Link to your project or a code example to reproduce issue:
What network driver are you using and what CIDR? i.e. Weave net / Flannel

alexellis commented 3 years ago

Hi @vojtechtoman you will need to fill out the whole issue template here, otherwise we won't be able to look into your request.

You are missing a just about all the context necessary to help us understand and triage your needs.

https://raw.githubusercontent.com/openfaas/faas/master/.github/ISSUE_TEMPLATE.md

Alex

alexellis commented 3 years ago

/add label: invalid

vojtechtoman commented 3 years ago

@alexellis my apologies, I have updated the issue to use the template.

alexellis commented 3 years ago

@vojtechtoman this is still so light on context and detail that it's hard to understand the use-case, and the problem.

All you've done is very briefly outlined a solution that you came up with.

The intent is to make the function aware of the (dynamic, possibly changing between pod restarts) node IP address.

For what purpose? What is the workload? What else have you thought of as solutions?

Alex

vojtechtoman commented 3 years ago

In our specific case, we want to enable Datadog tracing for the deployed functions. The challenge is that for that to work, we need to set the DD_AGENT_HOST environment variable on the deployment so that it points to the node IP provided by K8s. As far as I can tell, there is no way to pass an equivalent of:

  env:
    - name: DD_AGENT_HOST
      valueFrom:
        fieldRef:
          fieldPath: status.hostIP

when deploying the function via the /system/functions endpoint - or is there? That's what my question is about - or if there is another way of accessing status.hostIP on the deployment level.

LucasRoesler commented 3 years ago

@vojtechtoman one other option that you can consider is deploying the datadog agent as a daemonset and then exposing a Service. If you name the Service datadog-agent and it exposes the default 8126, then you can set DD_TRACE_AGENT_URL: http://datadog-agent:8126 for your function and get the same result.

Currently, there is no way to access the equivalent of status.hostIP via the function configuration.

alexellis commented 3 years ago

Hi @vojtechtoman one of the things you said was "we need", but we haven't been introduced.

Who is this for? See also: First impressions - introducing yourself and your use-case

You also haven't explained what happens if you don't have this feature? Have you considered the approach that @LucasRoesler has given you?

Alex

vojtechtoman commented 3 years ago

@LucasRoesler and @alexellis, many thanks for your responses and my apologies for a delayed reply. (Also thanks for making me aware of the contributing guidelines - I have updated the initial question, I hope it provides more context now.)

We have discussed the daemonset approach internally, but it probably means that an OpenFaaS function will be unlikely to hit the Datadog on the same host that it's running on, which will result in some of the information recorded with the log events (hostId, instanceId, etc.) to be wrong, which in turn may lead to chaos when inspecting the logs. So it's probably not going to work for us.

Meanwhile, I also became aware of Datadog Admission Controller, which might be exactly what we need to work around the current limitations of the function configuration - we will give it a try and if it works, I think this issue/question can be closed.

alexellis commented 3 years ago

Fair warning: the admission controller may battle with our operator to set values on the pods managed by OpenFaaS. Even if it looks like it works, it may fall into edge cases and break in unexpected ways. As C developers used to say: "avoid due to undefined behaviour".

That said, I will raise this on the contributors' weekly call this week.

kevin-lindsay-1 commented 2 years ago

I have this exact same need; valueFrom is built specifically for this, and AFAIK there's no good alternative, because it does the job exactly as it needs to.

openfaas / faas-netes