kiali must be in istio's namespace

[John Mazzitelli]

FWIW: Kiali canNOT be deployed in another namespace. It has to be with Istio in istio-system.

I just tried to deploy Kiali to myproject namespace and got an error trying to query Prom:

Cannot load the graph: Get http://prometheus:9090/api/v1/query?query=round%28sum%28rate%28istio_request_count%7Bsource_service%21~%22.%2A%5C%5C.default%5C%5C..%2A%22%2Cdestination_service%3D~%22.%2A%5C%5C.default%5C%5C..%2A%22%2Cresponse_code%3D~%22%5B2345%5D%5B0-9%5D%5B0-9%5D%22%7D+%5B60s%5D%29%29+by+%28source_service%29%2C0.001%29&time=2018-06-12T21%3A06%3A39Z: dial tcp: lookup prometheus on 172.30.0.1:53: server misbehaving

Which makes sense - we are trying to go to the "prometheus" service - we don't have a route to get to it from outside the namespace.

Perhaps there is some Kiali config in the configmap (or env var) we can override to fix this (assuming Prom is available from another namespace) - but I don't know what else would break.

In any case, the point is out-of-box the default behavior is that Kiali must be in the same namespace as Istio.

[Caina Costa]

What if we do use the fqdn for the service instead of only the service name (like `service.namespace.svc.cluster.local`)? It should be accessible inside the cluster even on a different namespace.

--
You received this message because you are subscribed to the Google Groups "kiali-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kiali-dev+unsubscribe@googlegroups.com.
To post to this group, send email to kial...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kiali-dev/1451848669.26110538.1528837856172.JavaMail.zimbra%40redhat.com.
For more options, visit https://groups.google.com/d/optout.

[Kevin Conner]

On 12 June 2018 at 19:53, Caina Costa <cac...@redhat.com> wrote:

What if we do use the fqdn for the service instead of only the service name (like `service.namespace.svc.cluster.local`)? It should be accessible inside the cluster even on a different namespace.

You should be able to get away with service.namespace, I don't think you need the FQDN.

   Kev

[Lucas Ponce]

I think it will simplify things if we assume as pre-requisite to install Kiali in namespace as Istio.

Perhaps, networking issues is something potentially fixed and it could work, but I don't see the rationale to introduce more complexity.

I.e. perhaps also istio could work if prometheus is installed in a different namespace, it could be a discussion in the future, but in terms of timeline, today I don't see it a priority. I think with kiali we have same scenario.

[Joel Takvorian]

Perhaps there is some Kiali config in the configmap (or env var) we can override to fix this (assuming Prom is available from another namespace) - but I don't know what else would break.

Mazz, indeed, you can override the Prometheus URL in the config yaml: 

external_services:
  prometheus_service_url: VALUE

But as Kevin said if we can generalize using service.namespace it's even better.

[Heiko W. Rupp]

On 13 Jun 2018, at 9:11, Lucas Ponce wrote:

> I.e. perhaps also istio could work if prometheus is installed in a

Actually - is there a way to query Istio (or its config) where it expects
Prometheus and Jaeger and use this?

[Juraci Paixão Kröhling]

On Tue, 2018-06-12 at 17:10 -0400, John Mazzitelli wrote:
> Which makes sense - we are trying to go to the "prometheus" service -
> we don't have a route to get to it from outside the namespace.

Not sure if you mean this in Kiali's specific case, or in a more
general case. In general, it's certainly possible to access services
from another namespace:

https://kubernetes.io/docs/concepts/services-networking/dns-pod-service

Quote:
Assume a Service named foo in the Kubernetes namespace bar. A Pod
running in namespace bar can look up this service by simply doing a DNS
query for foo. A Pod running in namespace quux can look up this service
by doing a DNS query for foo.bar.

Note:
IIRC, OpenShift has inter-namespace connectivity disabled by default,
as it assumes each namespace is a tenant, so, one tenant cannot access
resources from another tenant.

- Juca.

[Simon Pasquier]

Correct when using the ovs-multitenant plugin [1]. It is still possible to allow access from one project to all projects [2].

For "oc cluster up" deployments, there's no isolation though.

[1] https://docs.openshift.org/latest/architecture/networking/sdn.html#overview

[2] https://docs.openshift.org/latest/admin_guide/managing_networking.html#making-project-networks-global

 

- Juca.

--
You received this message because you are subscribed to the Google Groups "kiali-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kiali-dev+unsubscribe@googlegroups.com.
To post to this group, send email to kial...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kiali-dev/527dcf4ce2918706f8687a0e31f0e6987d3be96d.camel%40redhat.com.

[Joel Takvorian]

I created this ticket: https://issues.jboss.org/browse/KIALI-947

It would fix the url for prometheus. Then maybe we'll have other issues beyond that, while fetching kube/istio apis

To view this discussion on the web visit https://groups.google.com/d/msgid/kiali-dev/CAM6RFu6d%3DhNwS5XuxUyB3gnwcU1uFrbxuaQmKbwU8siTUB_oEg%40mail.gmail.com.