is anyone using PodStatus.HostIP?

[David Oppenheimer]

Is anyone using PodStatus.HostIP? We'd like to eliminate this field (see #6558 for background).

[Lv Lv]

I think flocker use that, see

https://github.com/kubernetes/kubernetes/blob/master/pkg/volume/flocker/plugin.go#L146

On Sat, Jan 30, 2016 at 5:38 AM, 'David Oppenheimer' via kubernetes-dev <kuberne...@googlegroups.com> wrote:

Is anyone using PodStatus.HostIP? We'd like to eliminate this field (see #6558 for background).

--
You received this message because you are subscribed to the Google Groups "kubernetes-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-de...@googlegroups.com.
To post to this group, send email to kuberne...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CAOU1bzcpMhzMSL_nVPP%3DTsSq4NEgC58swZYtyXszvU9TDKZTNw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Brian Akins]

We use it as we have a monitoring agent that runs in host network namespace. A few apps use HostIP for statsd endpoint the agent provides. If HostIP was removed from pod status, we could get it with an additional call to API, I suppose.

On Fri, Jan 29, 2016 at 4:38 PM, 'David Oppenheimer' via Containers at Google <google-c...@googlegroups.com> wrote:

Is anyone using PodStatus.HostIP? We'd like to eliminate this field (see #6558 for background).

--
You received this message because you are subscribed to the Google Groups "Containers at Google" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-contain...@googlegroups.com.
To post to this group, send email to google-c...@googlegroups.com.
Visit this group at https://groups.google.com/group/google-containers.

[Martin Nally]

We are also using this. Our scenario is the following:

We have a DaemonSet that puts an instance of App1 on every node. We want other apps to access the instance of App1 running on the same node they are on. We have not found a good way to do this. Our current solution is to add a hostPort to the deployment of App1, and have the other apps send requests to the their Host's IP address and the nodePort of App1. This is a rather roundabout way of getting what we want, but its the best we have found.

Why do we want this Node affinity? App1 has similar function to Netfix's Prana or AirBnB's Synapse. It's job is to allow clients to make 'safe' network calls, by implementing timeouts, circuit-breaker, stats, logging etc. In order to protect clients from unsafe network calls, it has to be, by definition, on the same Node as the client. We could deploy it as another container in the pod of each client, but that would be a) wasteful b) invasive on the clients. We cannot deploy it as K8S service, because we cannot then guarantee that the client request will not leave the node.

Martin

[Mark Petrovic]

We use shell scripts as container entrypoints for all our microservices.  Through the Downward API, we flow status.podIP into the entrypoint, whereupon we export a URL based on this IP that the app uses to register in our service discovery fabric.

On Friday, January 29, 2016 at 1:38:08 PM UTC-8, David Oppenheimer wrote:

[Mark Petrovic]

Whoa, wait a second.  I thought you were interested in removing status.PodIP, which I do use.  We do not use status.HostIP.

Sorry for the noise.

[Brian Grant]

This proposal is intended to cover that case:

https://github.com/kubernetes/kubernetes/issues/28610

--
You received this message because you are subscribed to the Google Groups "Kubernetes developer/contributor discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-dev+unsubscribe@googlegroups.com.
To post to this group, send email to kubernetes-dev@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/97dbc2b6-3704-4690-922a-2acf0c6eff3e%40googlegroups.com.