-
Notifications
You must be signed in to change notification settings - Fork 1.9k
502 error when accessing ingress #156
Comments
HEllo to kibana.yml config jeff |
That worked, thanks Jeff! You might want to add this setting to the kibana yaml file automatically when the ingress is enabled. |
This is working for me (on GKE) without anything set for
Can you check whether it works properly when removing this altogether? The default value is Which ingress controller are you using? That could also potentially cause differences. |
Hello, Jeff |
I was trying that a troubleshooting step. Originally I had nothing in there. Didn't realize I left that in there. I am using KOPS on AWS. When my kibana.yaml file is this: kibana.yml: I get the 502 error. I am using nginx: |
Ahh I see the problem now. The default docker images comes with I'll whip up a PR now to set this via an environment variable to make sure it is always set. |
Fixes: #156 The Kibana docker image comes with [server.host](https://github.com/elastic/kibana/blob/3a1d4ad0acd986f55b7da532878e842dd62a1237/src/dev/build/tasks/os_packages/docker_generator/templates/kibana_yml.template.js#L30) set in the default `kibana.yml`. This setting is needed to make sure that services and ingress work correctly. If someone overrides the kibana.yml with custom configuration this setting changes back to the kibana default which is `localhost`. This keeps the setting consistent for the default helm install with default values and for anyone customising `kibana.yml`
With the default install on GKE 1.13 the default bound port is now ipv4 instead of ipv6. There is an open issue in goss goss-org/goss#149 to allow testing for situations like this where it is listening on both ports. However the only important thing to test is to make sure that this this port is listening publicly and that the service actually works. Also switched the security example to test against the service to make sure we don't hit the same kibana bug as in #156
With the default install on GKE 1.13 the default bound port is now ipv4 instead of ipv6. There is an open issue in goss goss-org/goss#149 to allow testing for situations like this where it is listening on both ports. However the only important thing to test is to make sure that this this port is listening publicly and that the service actually works. Also switched the security example to test against the service to make sure we don't hit the same kibana bug as in #156
Chart version:
Release 7.1.1
Kubernetes version:
Client Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.1", GitCommit:"eec55b9ba98609a46fee712359c7b5b365bdd920", GitTreeState:"clean", BuildDate:"2018-12-13T10:39:04Z", GoVersion:"go1.11.2", Compiler:"gc", Platform:"windows/amd64"}
Server Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.6", GitCommit:"a21fdbd78dde8f5447f5f6c331f7eb6f80bd684e", GitTreeState:"clean", BuildDate:"2018-07-26T10:04:08Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}
Kubernetes provider: E.g. GKE (Google Kubernetes Engine)
KOPS on AWS
Helm Version:
Client: &version.Version{SemVer:"v2.11.0", GitCommit:"2e55dbe1fdb5fdb96b75ff144a339489417b146b", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.11.0", GitCommit:"2e55dbe1fdb5fdb96b75ff144a339489417b146b", GitTreeState:"clean"}
helm get release
outputDescribe the bug:
When I try access the ingress that is created above I get a 502 error from nginx.
Steps to reproduce:
Expected behavior:
Able to access kibana from the above ingress
Provide logs and/or server output (if relevant):
Any additional context:
Kibana appears to be working and connects to the Elastic. All my pods are green. When I do a port forward to the service or the deployment it loads fine.
kubectl -n logging port-forward svc/kibana-kibana 5601
It's the ingress that isn't working. If I try a curl from inside a pod, I also get a connection refused.
curl kibana-kibana.logging.svc.cluster.local:5601
curl: (7) Failed to connect to kibana-kibana.logging.svc.cluster.local port 5601: Connection refused
The text was updated successfully, but these errors were encountered: