communication between namespaces

[Jo Ho]

Hi,

I have been looking at ways to have pods and services communicate with each other when they are in different namespaces. Is there an official way of doing this? I have looked at setting up services and external routes, but my preference is to minimise "knowledge leak" from the namespaces i.e. to not have to have the requirement for the orginating pod to have to have knowledge of the endpoint service (that is to say, it would be good to have the equest to be transparent)

Is this possible or does the orginating pod have to specify the fqdn of the service in the other namespace? is there a way of proxying the request so the originating pod can talk to the proxy and the proxy deals with the communication to the other service in the other namespace?

Thanks!

[Tim Hockin]

Pods should be able to communicate across namespaces by default. Can
you clarify what you tried that isn't working?

> --
> You received this message because you are subscribed to the Google Groups
> "Kubernetes user discussion and Q&A" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to kubernetes-use...@googlegroups.com.
> To post to this group, send email to kubernet...@googlegroups.com.
> Visit this group at https://groups.google.com/group/kubernetes-users.
> For more options, visit https://groups.google.com/d/optout.

[Daniel Smith]

I think the request is for e.g. a version of Ingress that runs within namespace A and exposes services running in namespace B under new DNS names. Or auto-populated headless services.

On Mon, Oct 10, 2016 at 8:23 AM, 'Tim Hockin' via Kubernetes user discussion and Q&A <kubernet...@googlegroups.com> wrote:

Pods should be able to communicate across namespaces by default.  Can
you clarify what you tried that isn't working?

On Mon, Oct 10, 2016 at 3:33 AM, Jo Ho <johnandr...@gmail.com> wrote:
> Hi,
> I have been looking at ways to have pods and services communicate with each
> other when they are in different namespaces. Is there an official way of
> doing this? I have looked at setting up services and external routes, but my
> preference is to minimise "knowledge leak" from the namespaces i.e. to not
> have to have the requirement for the orginating pod to have to have
> knowledge of the endpoint service (that is to say, it would be good to have
> the equest to be transparent)
> Is this possible or does the orginating pod have to specify the fqdn of the
> service in the other namespace? is there a way of proxying the request so
> the originating pod can talk to the proxy and the proxy deals with the
> communication to the other service in the other namespace?
> Thanks!
>
> --
> You received this message because you are subscribed to the Google Groups
> "Kubernetes user discussion and Q&A" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to kubernetes-users+unsubscribe@googlegroups.com.
> To post to this group, send email to kubernetes-users@googlegroups.com.

> Visit this group at https://groups.google.com/group/kubernetes-users.
> For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Kubernetes user discussion and Q&A" group.

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-users+unsubscribe@googlegroups.com.
To post to this group, send email to kubernetes-users@googlegroups.com.

[Jo Ho]

I am looking for a pod in namespace A to access a service in namespace B via a service in namespace A which proxies the request (so only the proxy service needs to know about namespace B etc)

Is this possible?

On Monday, October 10, 2016 at 6:33:44 PM UTC+1, Daniel Smith wrote:

I think the request is for e.g. a version of Ingress that runs within namespace A and exposes services running in namespace B under new DNS names. Or auto-populated headless services.

On Mon, Oct 10, 2016 at 8:23 AM, 'Tim Hockin' via Kubernetes user discussion and Q&A <kubernet...@googlegroups.com> wrote:

Pods should be able to communicate across namespaces by default.  Can
you clarify what you tried that isn't working?

On Mon, Oct 10, 2016 at 3:33 AM, Jo Ho <johnandr...@gmail.com> wrote:
> Hi,
> I have been looking at ways to have pods and services communicate with each
> other when they are in different namespaces. Is there an official way of
> doing this? I have looked at setting up services and external routes, but my
> preference is to minimise "knowledge leak" from the namespaces i.e. to not
> have to have the requirement for the orginating pod to have to have
> knowledge of the endpoint service (that is to say, it would be good to have
> the equest to be transparent)
> Is this possible or does the orginating pod have to specify the fqdn of the
> service in the other namespace? is there a way of proxying the request so
> the originating pod can talk to the proxy and the proxy deals with the
> communication to the other service in the other namespace?
> Thanks!
>
> --
> You received this message because you are subscribed to the Google Groups
> "Kubernetes user discussion and Q&A" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to kubernetes-use...@googlegroups.com.
> To post to this group, send email to kubernet...@googlegroups.com.

> Visit this group at https://groups.google.com/group/kubernetes-users.
> For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Kubernetes user discussion and Q&A" group.

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-use...@googlegroups.com.
To post to this group, send email to kubernet...@googlegroups.com.

[Rodrigo Campos]

I don't see the gain, really. It seems complicated with no good reason.

But sure, create a service in ns A named like the service in B you want to access (or whatever) and make a pod that proxies the service. If it's http, you can use nginx or something like that.

But why do you want that? Are you sure?

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-users+unsubscribe@googlegroups.com.
To post to this group, send email to kubernetes-users@googlegroups.com.

[Tim Hockin]

I agree that the intention isn't exactly clear, but I can throw out some options.  You could set up an ExternalName service in A, which produces a CNAME in DNS.  You could set up a proxy pod and Service which would do more than DNS.

[Matthias Rampke]

I want something like this too, for the following use case:

We create one namespace for each system (a collection of components) and environment (staging/production/green/blue). Now, the meaning of environment is specific to the system. Some systems create new ephemeral environments for each branch.

Currently, we use different service configurations to tell foo-pr-1234 to talk to bar-staging but foo-production to bar-production. There is not really a way to compose a test whether foo-pr-1235 works with baz-experimental-rewrite. Also, different configurations between staging and production mean potential for error that will only be caught too late.

What I would _like_ to do is, when putting together a namespace to test foo-pr-1235:

* deploy the web and worker component of foo into foo-pr-1235

* link foo-pr-1235 to bar-staging

* link foo-pr-1235 to baz-experimental-rewrite

* link foo-pr-1235 to theotherservice-production (because it has no staging)

* validate everything

* delete the foo-pr-1235 namespace

I think ExternalName would do what I want nicely, thank you for the tip :)

/MR

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-use...@googlegroups.com.

To post to this group, send email to kubernet...@googlegroups.com.
Visit this group at https://groups.google.com/group/kubernetes-users.
For more options, visit https://groups.google.com/d/optout.

[Rodrigo Campos]

Oh external Name is already in? Awesome! :-)

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-users+unsubscribe@googlegroups.com.
To post to this group, send email to kubernetes-users@googlegroups.com.

Visit this group at https://groups.google.com/group/kubernetes-users.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Kubernetes user discussion and Q&A" group.

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-users+unsubscribe@googlegroups.com.
To post to this group, send email to kubernetes-users@googlegroups.com.

Visit this group at https://groups.google.com/group/kubernetes-users.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Kubernetes user discussion and Q&A" group.

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-users+unsubscribe@googlegroups.com.
To post to this group, send email to kubernetes-users@googlegroups.com.

[Tim Hockin]

Keep in mind that ExternalName makes TLS more complicated.  If you can get past that, it should empower this sort of soft link. Manually managed services also exist, if you have an IP for the target, rather than a name.