Hello Nils. Thank you. Yes, I should have made it clearer that I have defined a Kubernetes service for Elasticsearch and Kibana. That's why they can be accesses via the service proxy running at the master. The operation that does not work is https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/elasticsearch/.kibana I am surprised to see this path to access Elasticsearch -- I was expecting http://elasticsearch-logging:9200/.kibana which is the DNS name of the service and that's what I expect the Kibana server running in the cluster to use because elasticsearch_preserve_host = true . If I type https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/elasticsearch/.kibana into my browser I observe it works (the browser has the certs needed for the https call). I wonder if there is a bug that is making elasticsearch_preserve_host = true not respected?
As for exposing an IP of the minion -- I don't want to do this because from a conceptual viewpoint it is not the right thing to do (access via the service proxy to Kibana should work, and the Kibana server should be able to access Elasticsearch via DNS) -- and not all clouds allow the IPs on minions to be exposed in this way. I will experiment with a reverse proxy running in a different container in the same pod which can terminate the SSL connection from the browser (Kibana) to port :80 and then proxy pass them as HTTP calls to port :5601 which is being served in a different container running the Kibana service. However, I feel that (in this situation) I should not beed a reverse proxy and I worry that there is a bug somewhere in Kibana. Cheers, Satnam On Wednesday, April 29, 2015 at 5:59:51 AM UTC-7, Nils Dijk wrote: > > Hi, > > Have you tried defining a kubernetes service for Kibana? You can add a > public IP of one of your minions to this service so that you can reach it > easier from outside of the cluster. > > Here is an example from k8s on how to set this up: > https://github.com/GoogleCloudPlatform/kubernetes/tree/master/examples/guestbook#step-six-create-the-guestbook-service > > -- Nils > > On Tuesday, April 28, 2015 at 11:31:05 PM UTC+2, Satnam Singh wrote: >> >> Hello, >> >> I've upgraded to Elasticsearch 1.5.2 and Kibana 4.0.2 which I am >> deploying in a Kubernetes <http://kubernetes.io/> cluster. >> Specifically, I am running Elasticsearch in one "pod" (a Kubernetes >> container with its own IP) and I am running Kibana in another pod (again >> with a distinct IP address). >> The Kubernetes cluster runs a DNS service which will map the name >> "elasticsearch-logging.default:9200" to the pod running Elasticsearch. >> This works fine: I can exec into any Docker container in a pod and run >> "curl http://elasticsearch-logging.default:9200"; and the right thing >> happens. >> I've configured Kibana to let it know where Elasticsearch is running: >> >> elasticsearch_url: "http://elasticsearch-logging.default:9200"; >> elasticsearch_preserve_host: true >> >> Since I want to access Kibana from outside the cluster I use a proxy >> running on the master node of the cluster (after adding certificates to my >> browser for the SSL connection) e.g. >> >> >> https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/ >> >> Sadly, this does not work. I get the error: >> >> Error: Unable to check for Kibana index ".kibana" >> Error: unknown error >> at respond >> (https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/index.js?_b=6004:81693:15) >> at checkRespForFailure >> (https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/index.js?_b=6004:81659:7) >> at >> https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/index.js?_b=6004:80322:7 >> at deferred.promise.then.wrappedErrback >> (https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/index.js?_b=6004:20897:78) >> at deferred.promise.then.wrappedErrback >> (https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/index.js?_b=6004:20897:78) >> at deferred.promise.then.wrappedErrback >> (https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/index.js?_b=6004:20897:78) >> at >> https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/index.js?_b=6004:21030:76 >> at Scope.$get.Scope.$eval >> (https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/index.js?_b=6004:22017:28) >> at Scope.$get.Scope.$digest >> (https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/index.js?_b=6004:21829:31) >> at Scope.$get.Scope.$apply >> (https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/index.js?_b=6004:22121:24) >> >> >> And this is what the console shows: >> >> >> <https://lh3.googleusercontent.com/-hvUxjiNbpWU/VT_7XwsyMXI/AAAAAAAATYk/8ttLRY4rE58/s1600/Screenshot%2Bfrom%2B2015-04-28%2B14%3A27%3A40.png> >> >> Visiting >> https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/kibana-logging/elasticsearch >> >> works (i.e. returns the status of Elasticsearch). >> So does visiting Elasticsearch via the proxy i.e. >> https://104.197.26.147/api/v1beta3/proxy/namespaces/default/services/elasticsearch-logging/ >> >> I wonder if anyone has some advice about what is going wrong here? >> Thank you kindly. >> >> Cheers, >> >> Satnam >> >> >> >> -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/4a3701b3-2f90-4c10-aecf-2da0eed222ef%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
