After further investigation I think this might be a bug in the Kubernetes API server component. I have filed a bug on the Kubernetes GitHib page: https://github.com/GoogleCloudPlatform/kubernetes/issues/7517
Cheers, Satnam On Wednesday, April 29, 2015 at 7:57:16 AM UTC-7, Satnam Singh wrote: > > 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/fbecfa3a-a39a-4f0e-a58c-f52d987ee497%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
