deislabs/osiris

osiris-proxy sidecar cannot serve connections

jjtroberts opened this issue · 1 comments

Environment:

  • Kubernetes distribution (e.g. AKS, ACS Engine, GKE, EKS, etc.): GKE 1.13.6-gke.13
  • Kubernetes version (use kubectl version): v1.13.7
  • Osiris version (specify by SHA or semver): osiris-edge-0.0.1-2019.07.31.16.58.30-0e6ffe9
  • Install method (specify exact helm install command used):
    helm install osiris/osiris-edge --name osiris --namespace osiris-system --devel

What happened?
After installing the chart and annotating both the service and the deployment, the osiris-proxy sidecar log shows that it cannot serve connections as the connection is not recognized as being used for HTTP or TLS.

kubectl logs -f wordpress-c666cd99b-fhl7s -c osiris-proxy
I0821 13:02:25.386322       1 proxy.go:12] Starting Osiris Proxy -- version devel -- commit 0e6ffe9
I0821 13:02:25.386544       1 proxy.go:115] Healthz and metrics server is listening on :5002
E0821 13:02:56.990789       1 dynamic_proxy.go:116] Error serving connection: Connection not recognized as being used for HTTP or TLS
E0821 13:03:01.990571       1 dynamic_proxy.go:116] Error serving connection: Connection not recognized as being used for HTTP or TLS
E0821 13:03:06.990499       1 dynamic_proxy.go:116] Error serving connection: Connection not recognized as being used for HTTP or TLS
E0821 13:03:11.990673       1 dynamic_proxy.go:116] Error serving connection: Connection not recognized as being used for HTTP or TLS
E0821 13:03:16.990511       1 dynamic_proxy.go:116] Error serving connection: Connection not recognized as being used for HTTP or TLS
E0821 13:03:21.990754       1 dynamic_proxy.go:116] Error serving connection: Connection not recognized as being used for HTTP or TLS
...

What you expected to happen?
I expected not to see errors in the osiris-proxy logs.

How to reproduce it (as minimally and precisely as possible):
See attached service and deployment yaml.
osiris-test.yaml.zip

Anything else that we need to know?

I see there's an ingress resource involved in the example manifests you linked to. What I would recommend, for the purposes of troubleshooting, is taking that out of the equation and directing requests to the service directly. This will help determine if misconfiguration of your ingress resource or ingress controller is the culprit. Once that is ruled out, I can look at this in a little more depth.