Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

how can get the hostIP in a pod #24657

Closed
Aleishus opened this issue Apr 22, 2016 · 36 comments
Closed

how can get the hostIP in a pod #24657

Aleishus opened this issue Apr 22, 2016 · 36 comments

Comments

@Aleishus
Copy link

@Aleishus Aleishus commented Apr 22, 2016

I want to get the hostIP in a pod through the downward API,but failed this my error:

“spec.template.spec.containers[0].env[2].valueFrom.fieldRef.fieldPath: invalid value 'status.hostIP', Details: error converting fieldPath”

@thockin

This comment has been minimized.

Copy link
Member

@thockin thockin commented Apr 22, 2016

It's not currently exposed, but we're gathering information about why
people want stuff like this, so we can find a good answer. What are you
hoping to do with that?

On Fri, Apr 22, 2016 at 3:17 AM, Aleishus notifications@github.com wrote:

I want to get the hostIP in a pod through the downward API,but failed this
my error:

“spec.template.spec.containers[0].env[2].valueFrom.fieldRef.fieldPath:
invalid value 'status.hostIP', Details: error converting fieldPath”


You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#24657

@Aleishus

This comment has been minimized.

Copy link
Author

@Aleishus Aleishus commented Apr 23, 2016

Thank you @thockin . I use logstash as a daemonset pod for log collection . I want to get more node's information from this pod and put them into logstash,so that I can know where the logs come from.

@therc

This comment has been minimized.

Copy link
Contributor

@therc therc commented Apr 27, 2016

The IP is not exposed, because it would e.g. prevent live migrations of pods one day, but perhaps daemonsets could be an exception, because of their very nature?

We have a monitoring daemon on every node and wanted pods to report to the local agent. We solved that by having them contact a static IP, whose traffic gets rerouted to the local agent through an iptables rule.

@Aleishus

This comment has been minimized.

Copy link
Author

@Aleishus Aleishus commented Apr 27, 2016

I know thanks

@Aleishus Aleishus closed this Apr 27, 2016
@jeremyong

This comment has been minimized.

Copy link

@jeremyong jeremyong commented Aug 23, 2016

Can we reopen this? I think pods that are known to be 1-1 with the host in high performance applications should be able to understand their own public IPs to publish if they want.

@thockin

This comment has been minimized.

Copy link
Member

@thockin thockin commented Aug 23, 2016

#27880 merged this week, so
1.4 will allow the node name to be known.

On Mon, Aug 22, 2016 at 8:03 PM, Jeremy Ong notifications@github.com
wrote:

Can we reopen this? I think pods that are known to be 1-1 with the host in
high performance applications should be able to understand their own public
IPs to publish if they want.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#24657 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFVgVCu5q8sA843_7JzSrIXT8UnrDGBhks5qimMBgaJpZM4INe6L
.

@jeremyong

This comment has been minimized.

Copy link

@jeremyong jeremyong commented Aug 23, 2016

Thanks for the response @thockin . Forgive my ignorance but even if I have the node name, how do I discover the public IP bound to the node? Is the instance metadata querying even available within the pod? Or are people in the issue you linked referring to a different API?

@thockin

This comment has been minimized.

Copy link
Member

@thockin thockin commented Aug 23, 2016

Sorry, you need the PUBLIC IP? you have to go through some
provider-specific API, such as metadata to get that...

On Mon, Aug 22, 2016 at 10:05 PM, Jeremy Ong notifications@github.com
wrote:

Thanks for the response @thockin https://github.com/thockin . Forgive
my ignorance but even if I have the node name, how do I discover the public
IP bound to the node? Is the instance metadata querying even available
within the pod? Or are people in the issue you linked referring to a
different API?


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#24657 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFVgVCP_VnKgwr97ljUYIrU1Totttv1-ks5qin-WgaJpZM4INe6L
.

@jeremyong

This comment has been minimized.

Copy link

@jeremyong jeremyong commented Aug 23, 2016

In the case when I am enabling host networking on the pod so that the underlying host's network stack is used, shouldn't the host IP be available? I just now found #6558 which describes some of the concerns (multiple network interfaces etc) but it seems like the decision was to just remove the feature altogether instead of moving forward and handling the edge cases.

What I'm opting to do instead is add an additional boostrapping step to each node to expose information like public ips in a file and mounting it as a volume but this really feels like an ugly workaround. I should mention (not that it matters necessarily) that I'm using GKE at the moment.

@thockin

This comment has been minimized.

Copy link
Member

@thockin thockin commented Aug 23, 2016

that issue was about the node's IP, but not necessarily a PUBLIC address.
If you use host networking you can just look at the interfaces and get the
IP?

On Mon, Aug 22, 2016 at 10:30 PM, Jeremy Ong notifications@github.com
wrote:

In the case when I am enabling host networking on the pod so that the
underlying host's network stack is used, shouldn't the host IP be
available? I just now found #6558
#6558 which describes
some of the concerns (multiple network interfaces etc) but it seems like
the decision was to just remove the feature altogether instead of moving
forward and handling the edge cases.

What I'm opting to do instead is add an additional boostrapping step to
each node to expose information like public ips in a file and mounting it
as a volume but this really feels like an ugly workaround. I should mention
(not that it matters necessarily) that I'm using GKE at the moment.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#24657 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFVgVIkDOZYPDU27IwT8yR6ek8jfDnsbks5qioVfgaJpZM4INe6L
.

@sirhopcount

This comment has been minimized.

Copy link

@sirhopcount sirhopcount commented Sep 7, 2016

I might also have a use case for this. I want containers to be able to reach the etcd (proxy) on the node they are running on. That way services in the containers can register them selfs with the etcd cluster.

I could use host networking but that seems overkill to me for exposing a service on the node.

What I really want to be able to do is to set an env var with the public ip of the node the pod is running on.

@thockin

This comment has been minimized.

Copy link
Member

@thockin thockin commented Sep 7, 2016

With kube 1.4 you can get the node's name, which is usually resolvable.
Sufficient?

On Wed, Sep 7, 2016 at 12:21 PM, Adrian van Dongen <notifications@github.com

wrote:

I might also have a use case for this. I want containers to be able to
reach the etcd (proxy) on the node they are running on. That way services
in the containers can register them selfs with the etcd cluster.

I could use host networking but that seems overkill to me for exposing a
service on the node.

What I really want to be able to do is to set an env var with the public
ip of the node the pod is running on.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#24657 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFVgVCOAKxizOaKiXijAmQVlOuvAZbDyks5qnw64gaJpZM4INe6L
.

@sirhopcount

This comment has been minimized.

Copy link

@sirhopcount sirhopcount commented Sep 8, 2016

Yes that would also fix my problem.

Just out of curiosity, what the reasoning for not exposing the entire API to a manifest? Don't really see the harm in exposing the same data as one is able to fetch via for example kubectl.

@Bregor

This comment has been minimized.

Copy link

@Bregor Bregor commented Sep 21, 2016

status.hostIP is valuable for DaemonSets, for example.
In my case, I want to listen with Prometheus's node_exporter and weave scope only on the hostIP which is a private address of the node.

@kayrus

This comment has been minimized.

Copy link
Contributor

@kayrus kayrus commented Sep 21, 2016

As soon as I understand it is enough to add extra value in this list:

var validFieldPathExpressionsEnv = sets.NewString("metadata.name", "metadata.namespace", "spec.nodeName", "spec.serviceAccountName", "status.podIP")

@thockin

This comment has been minimized.

Copy link
Member

@thockin thockin commented Sep 21, 2016

node name is available as DownwardAPI as of 1.4

On Wed, Sep 21, 2016 at 7:10 AM, kayrus notifications@github.com wrote:

As soon as I understand it is enough to add extra value in this list:
https://github.com/kubernetes/kubernetes/blob/
313ef63/pkg/api/validation/
validation.go#L1320


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#24657 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFVgVPDDPU-Tr8KhvBQzsbWqXvyI3CnSks5qsTrUgaJpZM4INe6L
.

@Bregor

This comment has been minimized.

Copy link

@Bregor Bregor commented Sep 21, 2016

@thockin but what is the reason not to add extra values to validFieldPathExpressionsEnv?

@thockin

This comment has been minimized.

Copy link
Member

@thockin thockin commented Sep 21, 2016

Just to make sure we curate that well.

On Wed, Sep 21, 2016 at 8:13 AM, Maxim Filatov notifications@github.com
wrote:

@thockin https://github.com/thockin but what is the reason not to add
extra values to validFieldPathExpressionsEnv?


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#24657 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFVgVDqXyYdgEfgHx13fvwuhHHLfftQfks5qsUmSgaJpZM4INe6L
.

brandoncole added a commit to brandoncole/kubernetes.github.io that referenced this issue Dec 8, 2016
There are a couple awesome enhancements that would benefit from being documented here:

1. `spec.nodeName` for obtaining the host name
2. `spec.serviceAccountName` for obtaining the name of the service account the pod is running under

Right now these enhancements are documented only in a couple of issues and pull requests:

1. kubernetes/kubernetes#27880
2. kubernetes/kubernetes#24657
3. kubernetes/kubernetes#21317

I have verified the functionality in the latest codebase:

1. https://github.com/kubernetes/kubernetes/blob/master/pkg/api/v1/conversion.go#L200
brandoncole added a commit to brandoncole/kubernetes.github.io that referenced this issue Jan 7, 2017
There are a couple awesome enhancements that would benefit from being documented here:

1. `spec.nodeName` for obtaining the host name
2. `spec.serviceAccountName` for obtaining the name of the service account the pod is running under

Right now these enhancements are documented only in a couple of issues and pull requests:

1. kubernetes/kubernetes#27880
2. kubernetes/kubernetes#24657
3. kubernetes/kubernetes#21317

I have verified the functionality in the latest codebase:

1. https://github.com/kubernetes/kubernetes/blob/master/pkg/api/v1/conversion.go#L200

Also updating downward-api/dapi-pod.yaml to add a concrete example.
brandoncole added a commit to brandoncole/kubernetes.github.io that referenced this issue Jan 7, 2017
There are a couple awesome enhancements that would benefit from being documented here:

1. `spec.nodeName` for obtaining the host name
2. `spec.serviceAccountName` for obtaining the name of the service account the pod is running under

Right now these enhancements are documented only in a couple of issues and pull requests:

1. kubernetes/kubernetes#27880
2. kubernetes/kubernetes#24657
3. kubernetes/kubernetes#21317

I have verified the functionality in the latest codebase:

1. https://github.com/kubernetes/kubernetes/blob/master/pkg/api/v1/conversion.go#L200

Also updating downward-api/dapi-pod.yaml to add a concrete example.
brandoncole added a commit to brandoncole/kubernetes.github.io that referenced this issue Jan 13, 2017
There are a couple awesome enhancements that would benefit from being documented here:

1. `spec.nodeName` for obtaining the host name
2. `spec.serviceAccountName` for obtaining the name of the service account the pod is running under

Right now these enhancements are documented only in a couple of issues and pull requests:

1. kubernetes/kubernetes#27880
2. kubernetes/kubernetes#24657
3. kubernetes/kubernetes#21317

I have verified the functionality in the latest codebase:

1. https://github.com/kubernetes/kubernetes/blob/master/pkg/api/v1/conversion.go#L200

Also updating downward-api/dapi-pod.yaml to add a concrete example.
@cemo

This comment has been minimized.

Copy link

@cemo cemo commented Feb 15, 2017

@thockin I don't want to open a new issue but I have some similar requirements as others. Our fluentd agent is collecting data from docker logs file but I would like to feed by socket. docker log files has docker id in filename but I need to access in k8s environment. Is there a way to get it?

@thockin

This comment has been minimized.

Copy link
Member

@thockin thockin commented Feb 15, 2017

@cemo

This comment has been minimized.

Copy link

@cemo cemo commented Feb 15, 2017

@thockin I was referring container-id. I think that you did not reply to me. :)

@thockin

This comment has been minimized.

Copy link
Member

@thockin thockin commented Feb 15, 2017

@cemo

This comment has been minimized.

Copy link

@cemo cemo commented Feb 15, 2017

I was looking this answer. Thank you so much.

@chen-anders

This comment has been minimized.

Copy link

@chen-anders chen-anders commented Feb 20, 2017

At this point, I guess I am open to adding status.hostIP

This would work for our use case (as local node names don't resolve in our local VM though they do in our AWS cluster). While it seems pretty trivial to add an additional value to pkg/api/validation/validation.go, I'm not exactly sure where the corresponding tests should be aside from an additional validator around here:

@thockin

This comment has been minimized.

Copy link
Member

@thockin thockin commented Feb 21, 2017

@andrewsykim

This comment has been minimized.

Copy link
Member

@andrewsykim andrewsykim commented Feb 27, 2017

Does hostIP refer to pod ip or node ip? If pod IP can we also consider supporting nodeIP via downward API? My use case is pushing metrics to a daemonset and having to know its IP to do so.

@thockin

This comment has been minimized.

Copy link
Member

@thockin thockin commented Feb 27, 2017

@andrewsykim

This comment has been minimized.

Copy link
Member

@andrewsykim andrewsykim commented Feb 27, 2017

@chen-anders were you working on a PR for this? If not I don't mind giving it a shot :)

@chen-anders

This comment has been minimized.

Copy link

@chen-anders chen-anders commented Feb 28, 2017

@andrewsykim - I haven't been able to get to this yet.

@andrewsykim

This comment has been minimized.

Copy link
Member

@andrewsykim andrewsykim commented Mar 8, 2017

@thockin opened #42717 for this. For the most part I took your advice and did a search for status.podIP and added status.hostIP where possible.

p.s. super excited for your talk at cloud next :)

@ajit-sarnaik

This comment has been minimized.

Copy link

@ajit-sarnaik ajit-sarnaik commented Mar 11, 2017

Any idea when host_ip will be supported please.

k8s-github-robot pushed a commit that referenced this issue Apr 3, 2017
Automatic merge from submit-queue

Support status.hostIP in downward API

**What this PR does / why we need it**:
Exposes pod's hostIP (node IP) via downward API. 

**Which issue this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close that issue when PR gets merged)*: 
fixes #24657

**Special notes for your reviewer**:
Not sure if there's more documentation that's needed, please point me in the right direction and I will add some :)
@yaronha

This comment has been minimized.

Copy link

@yaronha yaronha commented Jun 9, 2017

@thockin following our discussion this week, any update on getting status.hostIP via downward API?
we need it to try and connect to local Daemon if it exists, had to use host volume w hacks to get it

Yaron

@andrewsykim

This comment has been minimized.

Copy link
Member

@andrewsykim andrewsykim commented Jun 10, 2017

@ajit-sarnaik @yaronha support for status.hostIP was added in this PR #42717. It should be included in the 1.7 release.

@thockin

This comment has been minimized.

Copy link
Member

@thockin thockin commented Jun 10, 2017

@yaronha I told you I thought it was in :)

@rachlenko

This comment has been minimized.

Copy link

@rachlenko rachlenko commented Jun 11, 2017

@thockin How I've waited for this moment. Thank you :)

perotinus pushed a commit to kubernetes/cluster-registry that referenced this issue Sep 2, 2017
Automatic merge from submit-queue

Support status.hostIP in downward API

**What this PR does / why we need it**:
Exposes pod's hostIP (node IP) via downward API. 

**Which issue this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close that issue when PR gets merged)*: 
fixes kubernetes/kubernetes#24657

**Special notes for your reviewer**:
Not sure if there's more documentation that's needed, please point me in the right direction and I will add some :)
@oliverisaac

This comment has been minimized.

Copy link

@oliverisaac oliverisaac commented Jan 23, 2020

We have a monitoring daemon on every node and wanted pods to report to the local agent. We solved that by having them contact a static IP, whose traffic gets rerouted to the local agent through an iptables rule.

I needed to solve the same problem and was able to do so using the below daemonset. This daemonset adds an iptables rule to every node which causes all traffic sent to the Magic IP 192.168.168.168 to be re-routed back onto the node. I then exposed the node-local agent (apm-server in my case) as a NodePort and my clients can talk to their sibling DaemonSet pod/agent (running on the same node) by connecting to 192.168.168.168:$NODEPORT.

apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
  labels:
    app: add-iptables-rule
  name: add-iptables-rule
spec:
  selector:
    matchLabels:
      app: add-iptables-rule
  template:
    metadata:
      labels:
        app: add-iptables-rule
    spec:
      containers:
      - command:
        - /bin/bash
        - -c
        - |
          export CHECKPOINT_PATH="/tmp/$( echo "$STARTUP_SCRIPT" | sha256sum | awk '{print $1}' ).checkpoint"
          echo "PATH: $CHECKPOINT_PATH" >&2
          /bin/bash /manage-startup-script.sh
        env:
        - name: STARTUP_SCRIPT
          value: |
            #!/bin/bash

            set -o errexit
            set -o pipefail
            set -o nounset

            echo Starting >&2
            # Route all hits to 192.168.168.168 to the node. this allows us to have a static IP for each node
            if ! iptables-save 2>&1 | grep -q 192.168.168.168; then
              iptables -t nat -A PREROUTING -d 192.168.168.168/32 -p tcp -j KUBE-HOSTPORTS
            fi
            echo done >&2
        image: gcr.io/google-containers/startup-script:v1
        imagePullPolicy: Always
        name: startup-script-v2
        securityContext:
          privileged: true
      dnsPolicy: ClusterFirst
      hostPID: true
      restartPolicy: Always
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

You can’t perform that action at this time.